IRC channel logs


back to list of logs

<paroneayea>I'm trying to install guixsd on this old desktop
<paroneayea>it's struggling :\\
<paroneayea>failing to detect the partition (tried both via label and uuid)
<paroneayea>and when it hits the repl prompt
<paroneayea>keyboard doesn't give input! even though it does via the usb installer image
<paroneayea>very strange
<paroneayea>maybe that is it
<habs>Hi, is it possible to choose an arbitrary target triplet when building a package? When I try to do 'guix build --target=i686-elf binutils', I get the error 'dynamic linker name not known for this system "i686-elf"'.
<retroj>anybody know about getting hg largefiles in guix? the mercurial package doesn't seem to provide it
<retroj>nm, got it.. just had to enable it in my ~/.hgrc. though if anybody can advise me about the system-wide config file for mercurial, please let me know
<paroneayea>anyway, for posterity
<paroneayea>that was indeed it
<paroneayea>I added the kernel module for nv_sata or whatever it was
<paroneayea>I extended the base-initrd field to add the module.
<retroj>is it possible to include a guix package definition with the source code of a program, for direct installation?
***cmass is now known as cbacon
<cbacon>Hi, is there a way to have a local copy of the guix lib available in a guile repl? (I'm testing some package defs)
<efraim>./pre-inst-env guile
<cbacon>would I achieve the same thing running >guix environment guile?
***frafra_ is now known as frafra
***frafra_ is now known as frafra
<lashdu>Hi! What is the attitude towards automatic updates in Guix SD? In Parabola (and Arch) GNU/Linux it is not recommended due to possible user manual intervention.
<OriansJ>lashdu: Because any user can rollback to previous states for the applications that they use
<lashdu>OrainsJ: I think you mean guix on a foreign system. I was referring to pacman versus guix.
<lashdu>Setting aside user profiles in guix. Is it sane to somehow automate update of packages in the root profile?
<OriansJ>well assuming that the update mechanism to extensively tested prior to update and the rollback mechanism is reliable, the risk is within acceptable margins and can be corrected in a reasonable level of effort.
***frafra_ is now known as frafra
<csanchez>guix pull give me internal server error all the time... I don't remember when it worked last for me :S
<csanchez>has anyone done it recently?
<quigonjinn>csanchez: i'm doing it right now on a vm from the usb image. it's currently compiling
<csanchez>quigonjinn: thanks! strange that it fails for me then, hmm
<csanchez>trying to access the snapshot from my browser also fails... maybe some network setting here
<csanchez>URL still right?
<csanchez>or has it changed in 0.11?
<iyzsong>csanchez: yes, it not changed. it's just the latest tarball of the git repository.
<csanchez>that's what I thought. I don't what happens :S
<csanchez>browsing savannah cgit with the browser works, but when I try to get a snapshot (either using guix pull, wget, firefox or whatever) it pauses for a while (like if it was building the snapshot) and then give internal server error
<csanchez>I thought savannah might be too loaded, but if it works for others then it must be something else
<csanchez>ok I tried from a server I got in another network and it works there
<csanchez>so there must be something about by local network
<ng0>(("cp bash \\\\.\\\\./dist/bash") "cp bash \\\\.\\\\./dist/bash cd \\\\'\\\\.\\\\.\\\\'")) the cd is on a new line. why does this fail to get substituted?
<ng0>i think it might be easier to test my theory with a temporary patch rather than substitute
<ng0>ouch. wrong file i substituted in
<catern>Hi #guix, suppose I am writing an operating system from scratch. I have a bunch of modules in different source repositories. Should I put the guix package definitions in the source repository for each module, or should I keep the package definitions separate?
<catern>in a separate place*
<ng0>can someone take a look at this and eventually spot a guix specific problem I need to patch?
<ng0>alternatively it can be accessed at http://dl.far37qbrwiredyo5.onion/debug/pbpst/log/wbad45l0bmis9bhznbdpwm7mhr3jni-pbpst-1.2.0-1.4aeb782.drv
<ng0>how does this get into the output:
<ng0>3.8.1/include -cxx-isystem /gnu/store/k3nwrfrgkg1bafhqi9w8inh2rr8njb1b-linux-libre-headers-4.1.18/include -internal-isystem /usr/local/include -internal-
<ng0> /usr/local/include .. i don't know if thiscauses the problem, but it trifggers something everytime it is encountered
<ng0>and individual /include directories are treated as "duplicates"
***frafra_ is now known as frafra
<davexunit>our gecode package fails to build because of a source hash mismatch
<davexunit>looks the tarball was updated in-place or otherwise tampered with
<ng0>ACTION eats laptop ... why does it fail
<catern>hey #guix, does guix distinguish between build and runtime dependencies?
<davexunit>catern: yes, runtime dependencies are determined by scanning the output directory for references to other store items
<davexunit>in package recipes themselves, there is no distinction, but there is a 'native-inputs' field where you put inputs that should be build for the architecture of the machine that is building the package, rather than the architecture of the machine that will run the software.
<davexunit>for the purpose of cross-building. the manual explains this better.
<catern>davexunit: what section of the manual explains the runtime-dependencies-determined-by-scanning thing?
<catern>(isn't that turing complete?)
<davexunit>I dunno, I was referring to the native-inputs thing.
<davexunit>long story short: guix doesn't have a notion of "development dependencies" like some other package managers have
<davexunit>it's not necessary.
<davexunit>the manual, AFAICT, has no mention of the scanning thing, presumably because it's an implementation detail.
<efraim>yay for "debug mode" output: phase `configure' succeeded after 61.4 seconds; starting phase `fail'
<efraim>if there is c code that says "LOAD("");", do I need to patch that to be "LOAD("/gnu/store/..../");"
<davexunit>another day, another neat electronics project I see online where someone makes their own circuit board and I lament that I cannot yet use gEDA effectively.
<jmd>What's the procedure for installing a version of a package with debug symbols?
<catern>davexunit: well, how can it be that guix automatically determines all runtime dependencies?
<steveeJ>efraim: I can't find a reference to the load function, or is it a macro? I would hope it respects LD_LIBRARY_PATH
<catern>oh, is setting that up part of packaging something?
<catern>because it seems turing complete - a program can reference an arbitrary file just fine
<catern>(i mean that it is turing complete to determine what the full set of arbitrary files a program can reference)
<jmd>catern: All packages dependencies are declared in the package definition.
<catern>jmd: that's just build dependencies, davexunit says
<efraim>Its apparently with ld and should respect LD_LIBRARY_PATH, but its not finding it
<steveeJ>efraim: is the path to libpulse in there?
<davexunit>catern: no, you've misunderstood me.
<davexunit>the only inputs that a build has access to are those declared in the package recipe
<efraim>pulse is in propagated-inputs, i assume its in the path
<davexunit>but one does not explicitly declare a runtime dependency
<davexunit>it's programmatically determined by scanning the output directory that the build creates
<davexunit>in the package recipes themselves there are 3 types of inputs, but none of them are specifically about "runtime" dependencies.
<davexunit>most likely you would just put things used at runtime in the "inputs" field.
<jmd>How do I specify the domain name in config.scm ?
<davexunit>jmd: 'hostname'
<jmd>There is a 'host-name' field.
<davexunit>yes, that
<jmd>So it is another misnomer.
<davexunit>what do you mean?
<jmd>It should be called fqdn
<davexunit>no it shouldn't
<davexunit>ever run the 'hostname' program?
<davexunit>it's the host name. it's not a domain name.
<jmd>Hostname gives the hostname. Unless you pass -f
<jmd>Or at least it should. If not then things such as kerberos will break.
<davexunit>my point is that the name is correct.
<davexunit>it's known as a host name
<davexunit>and guixsd allows you to configure it
<catern>davexunit: yeah, that's what I meant
<jmd>ok. I'll try that then.
<catern>davexunit: how can the runtime deps be programmatically determined by scanning the output directory? is what I was asking
<davexunit>catern: by looking for strings like '/gnu/store/...'
<catern>is that the only method used?
<davexunit>this is used by the garbage collector
<catern>what if, like
<davexunit>so that it knows the graph of store items
<catern>what if i did something like: store_dir = "/gnu/store/"; packageX = "...-foo"; open(store_dir + packageX); ?
<davexunit>I don't understand what that means
<catern>i programmatically generate a filename to open
<davexunit>that wouldn't make sense
<davexunit>and it wouldn't work
<davexunit>we wouldn't want software built like that
<catern>why wouldn't it work?
<davexunit>I don't have time for this
<catern>okay, thank you for your explanation
<retroj>anybody taking requests for packaging? this one is over my head, but i would really like it: git-annex
<catern>anyway, here's an alternative that's more plausible maybe - suppose the filename strings in the resulting build objects were compressed somehow (maybe the entire object is compressed)
<catern>then a simple grep won't work. is the duty of the packager to make sure such a thing doesn't happen?
<davexunit>catern: yes.
<davexunit>no compression.
<davexunit>this problem happens with python eggs sometimes
<davexunit>so we make sure the eggs are stored in uncompressed form
<catern>OK, that makes sense
<catern>a very clever method
<efraim>retroj: packaging git-annex is just `guix import hackage git-annex' and following the inputs backward until you've packaged everything
<ng0>so I need to substitute the leading parts (dist/, src/) of dist/$(PROGNM) and src/$(PROGNM).1 .. but dist/\\\\$\\\\(PROGNM\\\\) is wrong, dist/$\\\\(PROGNM\\\\) is wrong too. how do I escape this? Yes i really need to replace this, there is no other way.
<catern>is there a list of such pitfalls somewhere? maybe part of a guide for packagers?
<ng0>i need to add
<retroj>efraim: easier than i expected, i'll try it!
<efraim>git-annex itself you might have to parse by hand
<efraim>i just tried the command, it didn't like a custom field
<ng0>so I need to substitute the leading parts (dist/, src/) of dist/$(PROGNM) and src/$(PROGNM).1 -> first they are bost dist/$(PROGNM) but the location of one file changed due to reasons too long to explain here.. this is the only fix) .. but dist/\\\\$\\\\(PROGNM\\\\) is wrong, dist/$\\\\(PROGNM\\\\) is wrong too. how do I escape this? Yes i really need to replace this, there is no other way.
<efraim>i've never played with the hackage importer, I don't know if the programmers are better about reporting dependancies than python devs
<retroj>the command reported a syntax error
<jmd>If I want to install a version of a program with debug enabled, is there an easy way or do I have to define a new package?
<ng0>usually defining the output debug is enough
<ng0>if availlable, use the output, if not you have to create a local copy with this enabled
<retroj>efraim: i may be seeing a failed download. it reports a syntax error on line 316 (at the text "custom-setup"), then unexpected end of input. i'll try downloading the cabal file
<catern>so okay, also: suppose I have package A as an input to my build, and package A contains references to packages B and C. are all three included in the chroot for my build?
<ng0>can someonehelp me with the escaping? I've build this 48 times now and can't figure out how to do this last part.
<jmd>ng0: so just add (output '(debug)) ?
<catern>in other words, does the chroot for my build contain the transitive closure of all packages, starting from the inputs to my build?
<jmd>(output '("debug")) I meant
<ng0>(outputs '("debug" "out")) i think
<catern>all packages starting from*
<retroj>efraim: still a syntax error. you don't see that?
<efraim>I see it, that one might need to be parsed by hand :(
<retroj>maybe the better route is to let the developers of the hackage importer know of this problem
<steveeJ>is there a daemonless mode to use guix?
<davexunit>steveeJ: no.
<jmd>When I run guix build, I get: guix build: warning: failed to load '(build-aux build-self)':
<jmd>ERROR: no code for module (build-aux build-self)
<ng0>can someone please tell me how to substitute that? I'm a bit annoyed by the application and I have tried every possible escape I could come up with.
<ng0>this is 98% finished and I want it gone
<ng0>maybe it's just that I need to take a break, but in addition I don't know much about Guile escapes at the moment
<ng0>\\\\, \\\\\\\\ and without it did not change the end result
<davexunit>ng0: why don't you work with the regexp in a guile repl?
<davexunit>then you keep testing until you get it right
<ng0>argh. i forget about repl's..
<davexunit>you can use string-match for quick tests
<ng0>okay, i've tried it and it doesn't help. is this the reason why this is usually done in patches rather than in substitutes?
<davexunit>a patch is usually reserved for a fix that isn't specific to Guix or otherwise dynamic
<davexunit>what's the exact string you are trying to match?
<ng0>my discussion and work with the developer of pbpst lead to the build system alternative it has now, however the problem is guix specific. now after many attempts i ended with a solution where I need to change 2 strings in the Makefile to succeed, and , exclusively this part: dist/$(PROGNM)
<ng0>where when I alter the first, the second gets altered too so I need to change it immediately afterwards
<ng0>L34 needs to become src/$(PROGNM), L35 needs to become dist/$(PROGNM).1 again
<ng0>i have no time to explain the reason on this here, it's in the file documented.
<davexunit>I still don't understand, sorry
<davexunit>dist/$(PROGNM) needs to src/$(PROGNM) ?
<ng0>yep. and because the line below gets changed too, it (L35) needs to be reverted to dist/.... again
<davexunit>why don't you use a different pattern then?
<ng0>hm. oh.
<ng0>IU could include more, to make it unique, yes
<davexunit>(string-match "dist/\\\\$\\\\(PROGNM\\\\)" "dist/$(PROGNM)")
<ng0>sorry, tunnelvision..
<ng0>thanks for taking me out of it :)
<davexunit>the pattern "dist/\\\\$\\\\(PROGNM\\\\)" matches the string "dist/$(PROGNM)"
<ng0>now ihave a question on string-match:
<ng0>written as ((string-match "dist/\\\\$\\\\(PROGNM\\\\)") "dist/$(PROGNM)")) inside (substitute* "Makefile) it fails, I take that the form you gave me is correct?
<davexunit>ng0: string-match is a procedure to do regexp matching
<davexunit>you can't just stick it inside the substitute* form
<davexunit>I was just giving you a minimal example of a regexp pattern that matches the string you are trying to replace
<ng0>oh. ok
<ng0>i tried this pattern with substitute before and it did not succeed
<davexunit>then you have other problems
<davexunit>because if you run the code I gave you, you'll see that it returns a match
***lashdu is now known as drtan
<ng0>it succeeds, but $(PROGNM) becomes the value it is.. pbpst.. ending up with src/pbpst
<davexunit>sorry I don't follow
<ng0>i guess i can work around it
<davexunit>it sounds like PROGNM has the wrong value?
<ng0>no. it has the correct value. but I expect that when I substitute it, it gets placed as $(PROGNM) in the file and not pbpst
<davexunit>and that is what happens
<ng0>that is exactly what doesn't happen
<davexunit>if you replace with the literal string "src/$(PROGNM)"
<davexunit>there is absolutely no way that Guile would do that
<jmd>What't the recommended way to hack on guix from within GuixSD ?
<ng0>oh, because $PROGNM is set in the build enviornment
<ng0>or rather through the file
<ng0>when i use what you wrote:
<ng0>install: cannot stat 'src/(PROGNM)': No such file or directory
<paroneayea>retroj: efraim: ooh, I would *LOVE* to have git-annex in guix
<paroneayea>jmd: if you're in guixsd, do a git checkout of guix
<paroneayea>jmd: then you can either:
<bavier>retroj: there are some known failures of the hackage importer
<paroneayea>./pre-install-env guix
<paroneayea>jmd: or:
<paroneayea>~/.config/guix/latest -l
<paroneayea>ln -s ~/.config/guix/latest ~/devel/guix # or wherever
<paroneayea>jmd: which will make your user's guix command and repo the git checkout you're using
<retroj>bavier: okay. i wrote to guix-devel about it
<paroneayea>jmd: then use emacs + geiser, ideally
<paroneayea>you can live hack guix!
<paroneayea>./pre-install-env guile --listen # start a repl
<paroneayea>then in emacs
<paroneayea>M-x connect-to-guile
<paroneayea>jmd: hope that helps
<ng0>haha. okay, what you wrote is what I used before but I wanted it to do more than it can.. thanks davexunit :)
<paroneayea>jmd: you don't have to do all those things, but that's ideal. Check the manual for more info
<davexunit>ng0: np
<jmd> /
<retroj>how is pkg-config handled in guix? a package i'm working on, ola, provides libraries and header files. another program that uses it would normally use pkg-config to get the proper compiler and linker options for ola. is there anything special that a package needs to do to play nice with pkg-config in this way?
<jmd>retroj: Normally not.
<jmd>Except that pkg-config needs to be set as a native-input.
<retroj>would pkg-config be a propagated-input in order to be available for use?
<retroj>is it a native input of the program that wants to use ola?
<davexunit>if a program's build system uses pkg-config to find libraries, then yes.
<retroj>okay, thank you
<retroj>i am in a 'guix environment --ad-hoc ola', and pkg-config reports that it cannot find libola. what does that suggest? "Perhaps you should add the directory containing 'libola.pc' to PKG_CONFIG_PATH"
<davexunit>retroj: 'guix environment --ad-hoc ola pkg-config'
<davexunit>do you know what a search path is?
<retroj>same error
<davexunit>you must be doing something wrong
<retroj>wait, not the same error
<davexunit>ls $(guix build ola)/lib/pkgconfig
<retroj>this time it reports not finding protobuf, so perhaps i just have to put that into the environment
<davexunit>there ya go
<davexunit>guix packages include search path information
<davexunit>you can look at the pkgconfig package to see that
<davexunit>'guix environment' with gather up all of the search paths for the packages that is making an environment for and set them appropriately
<davexunit>this is why you needed to add pkg-config to the environment, otherwise guix has no way to know that you wanted PKG_CONFIG_PATH set.
<retroj>after adding protobuf to the environment, pkg-config worked. is that expected, or, since protobuf is an input of ola, should it be implied?
<davexunit>retroj: does the pkgconfig file for ola reference protobuf?
<davexunit>in which case, it probably needs to be a propagated input.
<retroj>it says: requires: protobuf
<davexunit>retroj: yeah, propagate it.
<retroj>ola also provides python and java bindings. i had the thought that these should be provided as separate outputs, because not everyone will need them. however, as separate outputs, python and java would still be needed to build ola. should they be separate package definitions instead?
<davexunit>retroj: no
<davexunit>just separate outputs
<retroj>as separate outputs, do i essentially have to rewrite what 'make install' does?
<davexunit>you'd have to figure out some way to break things up, yeah.
<davexunit>I haven't done much with multiple outputs, but there are many examples available in existing packages that you can learn from
<davexunit>could be as simple as running 'make install' and then moving things to the other outputs
<retroj>do i understand correctly that to have an output for the java bindings, for example, java would be a native-input to build the package, but a regular input only if the java output was used?
<davexunit>not quite
<davexunit>java would be a native input so that the bindings can be built
<davexunit>but java wouldn't need to a regular input
<davexunit>to be*
<davexunit>what do you mean by "only if the java output was used"?
<retroj>my question comes down to, what if a person wants to use ola, but doesn't care about java? do they still end up with java on their system? for a library that provided many such binding sets, this could entail a lot of unwanted software being installed
<davexunit>retroj: no, of course not.
<davexunit>I think you are misunderstanding how inputs work.
<davexunit>inputs *do not* mean "these packages will be installed along with this"
<davexunit>they mean "these packages are required to build this package"
<davexunit>in the situation where a user downloads a substitute rather than building from source, they would only download ola plus all of the things that the ola store item references
<davexunit>if there is no reference to java, then java won't be downloaded as well.
<jmd>When I do ./pre-instenv guix package -i pkg, in which profile do things get installed?
<retroj>if someone installs the java bindings, should that pull in java via a propagated input?
<retroj>is it generally true of language-specific libraries, that installing the library does not imply installing the language? like, would installing a ruby gem imply installing ruby?
<davexunit>it would not
<retroj>okay, that clears up a point of confusion for me. thank you
<jmd>I don't understand. Even after installing the debug version gdb claims "no debugging symbols found". Is there some othe thing I have to set?
<fturco>i'd like to try guixsd on my laptop but there are three choices for the download. what should i choose?
<retroj>fturco: i found the usb installer to be easiest
<fturco>i come from gentoo/parabola/archlinux
<fturco>as far as i understood guixsd is source based as gentoo but free as parabola
<bavier>fturco: there's one choice for GuixSD
<bavier>the other two are for Guix the package manager
<fturco>ok, choosing the first one
<bavier>fturco: you'll have the option of building packages from source or enabling binary substitutes downloaded from builders
<bavier>fturco: you'll want to read the installation instructions
<fturco>another question. in the documentation it says to use ext4 but i noticed btrfs is included as a package. can i use btrfs instead? what about encryption?
<bavier>fturco: both should be doable
<bavier>I don't personally have experience with either
<fturco>perhaps it is better to start with ext4 with no encryption and try different setups later
<ng0>recvfrom(4, ""..., 566, 0, NULL, NULL) = 566 strace. does this mean there's a fault in curl? the application does nothing on its own with certs and uses curl for that.
<jmd>We need a section in the manual on how to run gdb on a guix package.
<joolean>mark_weaver: Howdy! About that patch we were emailing about, what’s your ARM setup like? Do you have native hardware? Or is it some kind of virtualization layer? I can do some more digging - it’s probably more int-width stuff - but I’m reluctant to send you another update if I can’t test it locally.
<fturco>i just finished installing guixsd on my laptop
<fturco>how can i enable the network manager service?
<fturco>herd start network-manager <-- doesn't work
<retroj>fturco: just make sure that network-manager-service is in the services entry of your system definition
<mark_weaver>fturco: network-manager has never worked for me on Guix, and I don't think it has for anyone.
<mark_weaver>it needs to be debugged, but has so far resisted our efforts
<mark_weaver>in the meantime, there's wicd-service
<mark_weaver>has anyone here gotten network-manager to work?
<mark_weaver>joolean: I built it natively on one of our armhf build slaves, namely hydra-slave2, which is a wandboard quad
<mark_weaver>I have to go afk for a while...
<joolean>mark_weaver: Gotcha. Okay. Maybe I’ll try a VM.
<joolean>Thanks for your help!
<fturco>must go now... thanks for the help! bye