IRC channel logs


back to list of logs

<quiliro>i don't mind downloading
<quiliro>but the problem is comming to a link
<bavier>quiliro: yup
<quiliro>bavier: what is the command you ran with that .scm?
<bavier>quiliro: 'guix system disk-image /tmp/source-image.scm'
<quiliro>bavier: package-direct-sources instead of package-transitive-sources ?
<bavier>quiliro: vice versa, if you aren't interested in all packages source
<bavier>idk at the moment how large an image might be
<quiliro>bavier: thank you for you guide
<quiliro> iwill study what you have told me
<quiliro>be back in aweek or so
<bavier>quiliro: np, glad we could make a little headway
<civodul>lfam, mark_weaver: it seems to be running now
<civodul>please keep an eye on the build queue though
<civodul>lfam: also, tell mark_weaver if something looks wrong
<civodul>well, not sure if the mips machines are in good shape
<civodul>lfam: i've started an evaluation of 'staging'
<civodul>ACTION -> zZz
<joshuaBPMan_>Hello, I'm dual booting guixSD and Parabola. I'm having trouble logging into gnome as a normal user. I can login as "joshua" in a free tty, but I cannot log into gnome as the user "joshua".
<joshuaBPMan_>I should not that my Parabola and GuixSD installs are sharing the same /home partition but have different / partitions.
<joshuaBPMan_>I've recently updated all of my packages, and run 'sudo guix system reconfigure /etc/gnome-xfce.scm', but I still can't log into gnome as "joshua". Anyone have any ideas?
<joshuaBPMan_>i just search syslog, and I couldn't find anything with "gnome" in it. Does guix use something sdm login utility?
<lfam>joshuaBPMan_: GuixSD uses the SLiM login manager
<joshuaBPMan_>thanks lfam
<lfam>joshuaBPMan_: Sorry I can't help more :/ My GuixSD system is non-graphical for now. If you can't figure it out, please send a message to
<joshuaBPMan_>lfam: That's ok. And you use a non-graphical guixSD. May I ask why? server stuff?
<lfam>joshuaBPMan_: It's just an always-on laptop "server" at home. It used to be graphical but there was a bug in Guix 0.11.0's glibc package that I didn't want to work around, so I built everything from source for a few months. I could do that faster without the graphical stuff.
<lfam>I should reconfigure it now that that bug is fixed on the master branch and I can use substitutes again
<lfam>I mean, reconfigure it graphically
<joshuaBPMan_>lfam: Ok. That makes sense. I've actually just thought of something. I going to log off now. try to log in as my normal user, log in as root and check the syslog file for any changes. That might point me in the right direction. Be back in 10 minutes or so.
<joshuaBPMan_>Well I've found some errors in my syslog. Looks like I have some permissions errors with gnome-keyring and parsing a desktop file.
<lfam>Wooow, I guess that 21531add3205e400707c8fbfd841845f9a71863a was a long time coming!
<lfam>Date: Sun Mar 2 22:39:48 2014 +0100
<joshuaBPMan_>lfam: What do you mean?
<lfam>It's a recent commit, but the date is from 2014
<lfam>If you amend a commit, it doesn't change the date
<lfam>So, you can keep working on a commit forever but, unless you manually change its timestamp, it will still have the date of the original commit
<atw> haha wow. Didn't know about
<bavier1>davexunit: I'm looking at your dolphin package right now
<bavier1>I haven't tested the build yet, but it looks like it could use a few more inputs: enet, curl, and sfml
<bavier1>to avoid the bundled versions
<bavier1>the license should probably be gpl2+, since the Externals/Bochs_disasm that in unconditionally included is gpl2+
<bavier1>davexunit: the Externals/d3dx12.h has a questionable license
<bavier1>the upstream license was clarified to "MIT", and any of the d3dx12.h files at could probably be substituted
<bavier1>since the license header is updated, and the diffs seem limited to whitespace and additional declarations
<bavier1>davexunit: or simply removed... since the video backend that uses it is not built
<albertoefg>sneek later tell lfam if he wants no play hedgewars
<bavier1>In case anyone has been wondering, the source for all Guix packages occupies roughly 15.5G
<lfam>That's not too bad
<sneek>lfam, you have 1 message.
<sneek>lfam, albertoefg says: if he wants no play hedgewars
<bavier1>too much for a dvd iso :)
<lfam>bavier1: Who has optical drives nowadays? :)
<bavier1>lfam: sometimes I wonder if its only me
<lfam>texlive-texmf is ~1/4 of that total
<bavier1>davexunit: I was able to buid and start your dolphin package with additional curl and sfml inputs
<bavier1>can't test, don't have any of my isos atm
<buenouanq>what would a standard partition scheme recommendation look like?
<buenouanq>how does Debian decide what sizes to choose for a boot, main, and swap partition on a drive?
<janneke>morning guix!
<civodul>Hello Guix!
<buenouanq>any plans to include kiwix?
<civodul>buenouanq: there is no plan when it comes to what packages go in :-)
<buenouanq>Space Cadet
<buenouanq>Space Cadette
<albertoefg>sneek -help
<albertoefg>sneek: help
<thomassgn>buenouanq: On my laptop I usualy have swap at 4GB-ish and / on the rest. Simple, seeing as I don't have a lot of space to play with I'd rather not spend time managing partitions much.
<thomassgn>on a machine with more space or a less generic use I might partition differently.
<thomassgn>does anyone know if guixsd will create mount points for file-systems?
<civodul>thomassgn: there's a 'create-mount-point?' knob, see
<rekado_>about mount points: is there a way to try to mount and give up if the disk does not exist?
<civodul>no, but what's the use case?
<thomassgn>civodul: aha, thanks.
<rekado_>I have GuixSD on a workstation in our rehearsal room / studio without internet access, so I often take it home to update the system. The workstation has an extra disk for archival.
<civodul>i see
<rekado_>when I use the disk in my laptop it tries to mount the archive disk forever
<rekado_>I can’t even abort it
<civodul>what i do is that i have a file-system declaration with (mount? #f)
<civodul>for my removable storage
<civodul>so i can type "sudo mount /mnt/disk" when it's plugged in
<civodul>downside is that it's not automatically mounted
<rekado_>on the workstation this should be mounted, so that users don’t have to do this manually
<civodul>we should use the udisks(?) automount stuff for this
<civodul>not sure what needs to be done
<rekado_>udisks automounts USB drives, but I haven’t ever used it to mount internal disks.
<civodul>oh it's internal?
<rekado_>(and it only mounts on user actions, e.g. clicking on the drive icon in a file manager or running “udisks mount -b /dev/sdb”)
<rekado_>yes, the archive disk is just a large internal disk
<civodul>does it make a difference to udisks?
<rekado_>well, udisks mounts drives at /media/username/label
<rekado_>and I haven’t seen the disk appear in a file manager.
<rekado_>I guess I could run “udisks mount -b /dev/…” in a script after login
<rekado_>but… I don’t know, this seems hackish
<civodul>right, or have a custom service
<civodul>but yeah, hackish
<civodul>actually if you have a normal file-system decl, it may be that the corresponding shepherd service will simply be down if the disk is missing
<civodul>did you try that?
<civodul>BTW i think you should blog about GuixSD & music :-)
<rekado_>a couple of blog post ideas (tasks?) are in my org pile…
<rekado_>I’ll get around to it eventually, I hope
<rekado_>without any of the extra mount options I tried booting without the disk but shepherd would try again and again to mount it.
<rekado_>thus preventing the system from booting
<civodul>hmm dunno
<civodul>we should make it possible
<rekado_>I don’t know if there’s an fstab flag that would allow us to do this
<rekado_>(I feel like I should know this)
<janneke>civodul: anything i can do to get mingw into 0.12?
<fr33domlover>ACTION wonders why mingw would be useful to GuixSD users
<civodul>janneke: could you rebase a branch and push it somewhere?
<janneke>fr33domlover: to build binaries for unfortunate users
<civodul>janneke: i'm sorry to ask you to redo this :-/
<civodul>the problem i have is that when i pick things to review/apply i tend to pick low-hanging fruits that i can complete in a timely fashion
<janneke>civodul: sure, rebased on master?
<janneke>will do, thanks
<fr33domlover>janneke, or give them GNU/Linux installer ISOs :-)
<fr33domlover>since i left my last tech job, over a year ago, it's so nice not to need to have any contact with that pr0prietary os stuff
<janneke>fr33domlover: small steps...
<janneke>also, deploying guile/guix `packages' could benifit from a guile.exe
<fr33domlover>on the other hand making software support l0sed0w$ hurts our ability to compete. the more software GNU/Linux has and pr0prietary OSs don't, the bigger the reason for people to move
<fr33domlover>i mean, i see lots of projects that have a build for l0sed0w$ and 0sx etc.
<fr33domlover>but... dunno, just feels like were stepping in the stinky mud just to please users and get popularity
<fr33domlover>i'm happy to teach vega diet to cannibals, but i won't serve it on a dead body for them :P
<roelj>It's kind of hard to explain "we create software you are free to run wherever and however you wish" if it can only run on an OS that they don't have.
<buenouanq>I would much rather have a system I loved and was proud of, than something I could use but was being catered to casuals.
<buenouanq>Look at what's happened to Mozilla.
<civodul>"catered to casuals"? that sounds a bit elitist no?
<kmicu>ACTION ಠ_ಠ
<buenouanq>is there something wrong with that?
<civodul>it's just that i think there should not be "casuals" and "end users"
<buenouanq>the people that are going to tune it will, and attempting to cater to those that never will only servse to make things worse for the ones that of us that are here
<civodul>yes, i see what you mean
<civodul>i think we should reach out to "those who don't tune" so that they eventually start tuning and hacking
<buenouanq>yes, and the best way to do that is to have something that's nothing like what they already have
<civodul>of course clicky GUIs fail at that
<janneke>civodul: re mingw: conflicts in cross-kernel-headers...someone merged their stuff earlier
<janneke>this will need some time to resolve, and *ugh* redo all tests
<civodul>janneke: :-/
<civodul>i guess you were competing with phantomas on this part of the code
<janneke>yes :-/
<janneke>running my tests on all individual patches takes about 2 days...if everything passes :-(
<rekado_>there is a difference between making things easier and restricting access to tuning.
<rekado_>I would be very happy if people who don't have a background in programming or system administration could use Guix to build the system they want to use.
<rekado_>they'd still be users for the most part (like myself when it comes to most free software), but experiencing full software freedom would only be a small step away.
<ng0>GUIs don't have to be restrictive. at some point there could be something which works in a set of modules, and those modules you can drag around and assemble, you can edit them if necessary.
<ng0>it works better in my mind. or drawn.
<ng0>in a project, someone mentioned something to me which just some minutes in looks like nix ops or where ever we are going..
<ng0>got to go
<thomasd>Hi #guix,
<thomasd>is there a way to use the store path of a package A in the derivation of another package B, without making A a dependency of B? Dealing with some circular references here
<thomasd>(package B can refer to A at runtime, but can also work without it)
<civodul>thomasd: that's not possible, there cannot be circular references
<thomasd>hmm actually that would be unwise, maybe a bootstrapping package A' is needed, so we can have A' < B < A :-/
<civodul>right, that's how we usually address such cases
<thomasd>civodul: I think I just came to the conclusion :)
<thomasd>it's about kde packages
<thomasd>kinit relies on kdbusaddons,
<thomasd>but kdbusaddons is responsible for (re-)starting the kdeinit5 process at runtime, which is a /bin output of kinit
<thomasd>so if I want to hardcode the store path to kdeinit5 in kdbusaddons, I'd need to to the bootstrapping thing
<davidl>im having some install issues and need some help. When running system-init it says "grub-install: error: disk `lvm/my-root' not found" but Im not using lvm.
<civodul>davidl: do you have a cryptsetup-encrypted root partition?
<civodul>ok, and you're installing from the 0.11 image?
<davidl>yes, the latest one on the website.
<civodul>that one didn't support encrypted roots
<civodul>this has been fixed in the meantime though
<civodul>this specific GRUB problem has been fixed here:
<civodul>what you can do is run 'guix pull' in the installation image, which will give you the latest Guix
<davidl>that only works if you already run guix right?
<davidl>this is my first time installation of guix sd.
<civodul>no no, you can run 'guix pull' from the installation image, even if you have not yet installed GuixSD
<davidl>I see
<davidl>from the root@gnu prompt right?
<davidl>now it says gzip: stdin: not in gzip format and "failed to unpack source code"
<civodul>weird, it works here
<civodul>could it be a network issue?
<civodul>did you set up networking as explained in the manual?
<davidl>I did it with wpa_supplicant and dhclient as explained on the website I think.
<civodul>ok, and does it fail systematically?
<civodul>any other messages before that one?
<davidl>though I had a "possible network" issue before so I reverted to --fallback when invoking guix system init.
<civodul>can you ping or similar from there?
<davidl>uhm, it says starting download and fetching patch <url> found valid signature, downloading and unpacking then the gzip error.
<davidl>ping works
<civodul>can you run "tar tf /gnu/store/..." on the faulty tar.gz file?
<davidl>gives the same error
<jmd>Is there a way I can get more verbose logging from make-system ?
<jmd>s/make-system/make check-system/
<davidl>civodul: do you have any other suggestions or ideas as to why it can't unpack?
<civodul>davidl: no sorry; maybe if you could copy/paste the full command and output that would help a bit
<civodul>jmd: 'make check-system' simply builds derivations, so there logs are saved in /var/log/guix
<davidl>civodul: I wrote it down.
<Petter>Oooh, so form feeds are in the code on purpose, I was thinking they were mistakes :P
<Petter>davidl: is a bad paste service, it blocks some users and also mangles data.
<davidl>Petter: ok, what's the suggested alternative?
***civodul changes topic to 'GNU Guix | | 0.12.0 is in the works! | videos: | bugs: | patches: | paste: | log:'
<davidl>Petter: done -
<Petter>Looks like your network isn't working correctly. Try pinging and see if that works.
<davidl>sry, I made that paste wrong. network functions. Im annotating it.
<davidl>the problem is gzip
<civodul>davidl: run 'guix pull' without any argument; the command you gave here cannot work
<davidl>returns the same ERROR: In procedure getaddrinfo: Name or service not known, etc.
<Petter>How did you check that the network functions properly?
<davidl>ping and ping
<davidl>both replies.
<Petter>I suspected a DNS issue.
<roptat_>hi, I would like to add a package that could be built with python-build-system, except that the steps must be performed in a subdirectory of the source
<civodul>roptat_: hello! you can add a build phase that does (chdir "subdir")
<civodul>see the 'unpack' phase in mit-scheme for example
<roptat_>ok, thanks
<davidl>so now guix pull works, it worked after pinging around a little including which makes me suspect its some dns cache issue.
<jmd>civodul: Which derivation is pertinent to running a system test?
<civodul>you can see which derivations it builds i think, search for "build-started" tags in the console
<roptat_>my #:phases in arguments is being ignored...
<civodul>i can't believe it! :-)
<roptat_>oh nevermind, it works
<civodul>ah, see? :-)
<roptat_>I wrote two arguments...
<civodul>that is not properly diagnosed, which isn't great
<thomasd>I think I've solved my circular dependency problem, but is there a way to automatically verify I didn't mess up?
<civodul>how would you verify?
<civodul>guix lint -c no-messing-up?
<thomasd>that's what I was afraid of
<thomasd>so I'm correct that circular dependencies only show up when the daemon actually tries to build derivations of the packages?
<civodul>circular dependencies currently result in a stack overflow when trying to compute the derivation
<civodul>so you immediately notice
<civodul>that is, "guix build foo -d" would crash
<thomasd>yes, but I've changed a number of KDE packages in the process (switching from the old kdbusaddons to an inherited package), so I should try to build all of them
<thomasd>Meanwhile, let me submit a feature request for "no-messing-up" :-)
<buenouanq>M-x do-what-i-want-not-what-i-type-mode
<jmd>Does anyone else get "BUG: unable to handle kernek paging request ...." about every 2/3 attempts to run make check-system ?
***the_ktosiek is now known as ktosiek
<civodul>not me
<civodul>thomasd: "guix lint -c derivation" will tell you if there's any circular-dep style issue
<civodul>it's a good idea to rebuild the relevant KDE packages though, to make sure they still builds, ofc
<rekado_>I'd like to learn how to use Geiser better when doing Guix work.
<rekado_>To be able to use M-. I need to have all Guix modules loaded into Geiser first, no?
<branko>'lo folks. Guide suggested sharing experience, so just a small comment that current installation instructions include command "ifconfig interface up" - this one by itself did not obtain IP etc (had to run dhclient manually).
<davexunit>rekado_: correct.
<rekado_>are you using guix-switch-to-repl for this?
<davexunit>geiser works by querying the running guile process
<davexunit>honestly, I don't use geiser with guix
<davexunit>which is a shame.
<rekado_>guix-switch-to-repl is very slow for me, probably because my Scheme files aren't all compiled.
<rekado_>do you run make each time you switch branches?
<davexunit>I always keep everything compiled
<davexunit>I didn't even know guix-switch-to-repl existed until now
<rekado_>I have so many branches here and switching them changes the timestamps, which makes Guile think that I need to compile everything again.
<rekado_>Is there a way to avoid this?
<davexunit>not that I know of
<davexunit>that's just how make works
<rekado_>switching from one branch to another and back again I'm again asked to compile everything
<davexunit>usually my branches aren't vastly different so I only have to recompile a few things
<davexunit>I think using git subtrees would make you happier
<rekado_>I'm already using different workspaces to keep my regular Guix installation separate from all the wip stuff.
<ng0>civodul: is there an ETA for 0.12 release?
<davexunit>er, worktree, or whatever they call it.
<davexunit>that way if you're working in many branches you don't have to recompile stuff so much
<rekado_>with worktrees I always get confused about files that are already open in Emacs
<davexunit>maybe projectile could help there
<rekado_>like "is this the emacs.scm from guix or from guix-wip...?"
<davexunit>I haven't really used it, though.
<rekado_>yeah, I'm using projectile now
<rekado_>not happy about having to open a bunch of files from different worktrees
<rekado_>I have 16 branches right now (and that's all current work, after merging and deleting some more branches).
<rekado_>having a worktree for each of them feels clunky
<ng0>I have 60 branches (guix) and some more checkouts and I don't like it either.
<rekado_>could ccache or something like it be used?
<davexunit>I think you'd have this problem in any project where you have 16 active branches
<rekado_>yes, but that doesn't make it any less annoying :)
<davexunit>agreed :)
<davexunit>I've never managed branches at that scale so I don't have any useful suggestions at this point.
<ng0>i think my ~/src/guix/* is at 2GiB and more
<rekado_>when you build guix do you do this inside of "guix environment guix" or do you install the dependencies somewhere?
<davexunit>always within an environment
<rekado_>so do I but the lack of persistence also means that things are not safe from GC.
<rekado_>after GC I need to manually fix up the shebang, run "guix environment guix", then reconfigure, and then make.
<davexunit>if the shell started by 'guix environment' is running then it is protected
<rekado_>so I'm considering to have a separate profile for all Guix deps
<davexunit>the connection to the daemon remains open the entire time
<davexunit>protecting the store items that were built
<rekado_>right, but in my case I rarely ever leave the environment active.
<rekado_>I only need the guix environment when I build guix.
<davexunit>okay so that's the problem
<davexunit>you should leave it active
<davexunit>or write the patch for 'guix environment --save' or whatever ;)
<roelj>How can I disable the stripping of binaries for a package?
<davexunit>'#:strip-binaries? #f', I think
<davexunit>see the gnu build system source
<rekado_>do you know of a shortcut to load up all (gnu packages *) modules in the REPL?
<roelj>davexunit: Thanks!
<davexunit>rekado_: it's doable, just needs a bit of code.
<davexunit>one sec...
<davexunit>this worked for me
<davexunit>assumes that the current working directory is the root of your guix source tree
<davexunit>rekado_: oh but first run (use-modules (ice-9 ftw))
<rekado_>davexunit: thanks!
<bavier1>davexunit: did you see my notes about your dolphin package?
<davexunit>first-class modules ftw
<davexunit>bavier1: no, I'll read them.
<davexunit>bavier1: thanks for the notes.
<davexunit>I can make the relevant changes before I submit upstream
<davexunit>I didn't realize those libraries were bundled.
<bavier1>I'll try to test an iso soon
<davexunit>I've used it to play a gamecube game online with other people
<bavier1>I couldn't get it to take our enet package; didn't look at the logs though
<bavier1>davexunit: neat!
<davexunit>so it works quite well for me! getting the "broadband adapter" feature to work is a pain, though. it's no fault of guix, but it requires root privileges to setup a bunch of virtual network devices.
<bavier1>I'd love to do some multiplayer melee
<davexunit>and then the ethernet device can't be used for anything else while you're playing...
<davexunit>it's because you make a bridge
<davexunit>and then the device isn't able for it's regular usage
<davexunit>and dolphin uses that bridge
<davexunit>and the gamecube uses DHCP to get an IP
<paroneayea>hello *
<paroneayea>davexunit: sadly putting "input" as a group for my user didn't fix pressure sensitivity in the wacom tablet... too bad!
<davexunit>darn :(
<paroneayea>it does work but I have no pressure sensitivity.
<davexunit>I thought it didn't work at all
<davexunit>my bad
<paroneayea>well, and it should register the eraser separately
<paroneayea>so, when the wacom driver doesn't "fully" work
<paroneayea>it registers it like a pointer on the screen
<paroneayea>you have to do something, and I forget what since my Gentoo days ;), to get the pressure and eraser working.
<paroneayea>`xsetwacom --list devices' lists nothin'
<paroneayea>could be that our kernel doesn't have the wacom driver enabled.
<paroneayea>or could be that we don't have the right udev rules.
<paroneayea>one of those, probably!
<davexunit>perhaps you need to modprobe something
<civodul>ng0: i think 0.12 will be after the repro build summit
<civodul>so, two weeks from now
<ng0>ah, ok
<paroneayea>hm, someone wants to do a Jitsi call with me this week. I have a feeling Jitsi isn't a trivial thing to package.
<rekado_>jitsi is a whole lot of java
<paroneayea>iirc java isn't a fun packaging time in guix and maybe elsewhere too
<rekado_>on the plus side, many jars are portable
<civodul>Hydra can do repeated builds on a per-derivation basis:
<rekado_>if jitsi doesn't depend on any bindings to system libs you might be able to just use the pre-built jars
<paroneayea>rekado_: true
<roelj>In a couple of days we may get root access on our HPC for guix-daemon, but now that it's almost there, the non-root solution is working quite streamlined and well that I almost feel bad to give that up.
<rekado_>ha! :)
<civodul>roelj: giving up on that brings tangible benefits too :-)
<davexunit>ludo likes to say something and then drop the mic
<roelj>It would be great fun to have the CI system deal with git pushes to package repositories. Something like git push -> CI server builds tarball -> CI server builds package with new tarball -> CI installs that package in a per-program profile -> user can directly access it through that per-program profile.
<ng0>a nice maintainer pov writing about how hard negative articles can be and that there should be more outreach to the positive ones, etc
<Petter>Can someone see what the problem is here?
<Petter>I'm trying to do as lfam's
<efraim>I assume you meant (let ((dir "SRC..."))
<jmd>how can I find out why a service is not starting in the marionette?
<Petter>Oh, right. Thanks efraim!
<ng0>hm. I did submit an epic5 package, or was this something I planed to do?
<ng0>i did
<ng0>but no one comented on my questions since october
<ng0>so the question is, drop gdbm functionality?
<ng0>I will just asume gdbm is not vital for it
<ng0>our online documentation is outdated again.. isn't this handled by a cron job or something?
<Petter>How do I find out what f.ex. (with-directory-excursion) does?
<thomasd>Petter: do you have Geiser?
<thomasd>I mean emacs + geiser
<Petter>Probably not.
<Petter>Not unless it comes with Emacs.
<thomasd>I think it does, if not it's just a package-install away
<Petter>Thanks, I'll look into it.
<thomasd>then, from a guix source buffer, you can say "switch to REPL and enter module", to start a guile repl with the current module loaded,
<Petter>Oh, I do. It's on the menu bar.
<thomasd>and Geiser can provide information on symbols (docstrings + links to source)
<doktaNG>seems to work
<doktaNG>unicode testing äö!"?ß<Ø
<doktaNG>okay, I think I'll send this updated epic5 package
<thomasd>Petter: though it won't magically work on every symbol. I believe expressions which are to be run by the build daemon and are quoted in the package descriptions are not analysed. (Other people on this channel should be able to provide a more proper explanation :-) )
<Petter>It looks like some configuration is needed, it says "no documentation available" for everything I've tried so far.
<thomasd>ah, yes, you need to add the path to your guix source to geiser-guile-load-path
<Petter>Ah, thanks.
<Petter>I also just remembered there's something about Geiser in the manual,
<thomasd>yes, and the geiser manual itself is also usefule
<Petter>Thanks for showing me the light! :)
<ng0>why don't we have lib/libssl.a in our openssl?
<ng0>while libressl has it
<quigonjinn>is there a way for the build daemon to have network access while carrying out a build phase?
<davexunit>quigonjinn: network access would apply to the whole derivation. the only derivations that may have network access are "fixed output" derivations where the sha256 hash is known in advance.
<quigonjinn>davexunit: are there any examples I can take a look at?
<ng0>alezost: ok, so what's the exact symlink format you want? something which takes the already created soffice symlink as a target?
<davexunit>quigonjinn: source code downloads are the only example.
<davexunit>my guess is that you are asking to do something that guix won't allow, though.
<davexunit>maybe you should describe your problem more.
<alezost>ng0: If 'libreoffice' should be placed in the same directory ("bin"?) then just: (symlink "soffice" "libreoffice")
<ng0>*sigh* I'll build libreoffice then. but I think this could be changed without verifying it works? otherwise I'll compile it over night
<alezost>ng0: don't build it; it's easy to check without building
<alezost>is 'soffice' placed in "bin" dir?
<alezost>so (symlink "soffice" "libreoffice") will surely work
<ng0>i noticed a typo in my commit message, i'll send an update any minute
<quigonjinn>davexunit: you are probably correct that guix won't allow. I am trying to bundle some java stuff for my university lab, namely maven.
<davexunit>quigonjinn: yeah, that's a no-go.
<davexunit>the usual problem here is that the build system is also a package manager that downloads pre-built jars.
<davexunit>it's a tough problem to get software like this into guix.
<ng0>git diff
<alezost>ng0: I mean it will work inside (with-directory-excursion (string-append (assoc-ref outputs "out") "/bin") ...). Here is a simple guile script that you can test:
<alezost>(assuming you have "/usr/bin/env" and guix modules in your GUILE_LOAD_[COMPILED_]PATH)
<ng0>ah right, the directory excursion i asked for in the mail i've just sent
<ng0>so it can be shorter
<quigonjinn>davexunit: yes i'm aware. i see there has already been some effort on this one
<ng0>alezost: i#ve just sent the new version with-directory-excursion. could be that it can still be made shorter
<alezost>ng0: I've replied
<janneke>civodul: rebased and tested mingw branch at:
<janneke>i was kinda lucky: none of the cross-base conflict/changes triggered any compiler/libc rebuilds
<civodul>janneke: cool, thanks!
<civodul>ACTION adds it as a remote
<janneke>readline-7.0 needed a patch...but i worked triggering non-cross rebuilds by using a mingw-specific CPP make flag...
<janneke>*worked around
<civodul>that's wip-mingw32, right?
<janneke>oh no, mingw
<janneke>i'll remove wip-mingw32 right away
<civodul>hmm i don't see a 'mingw' branch
<janneke>it's there:
<janneke>and i removed wip-mingw32 some time ago...seems something did not update?
<civodul>oh i was looking at your thing, not the one
<civodul>i do see the branch now, thanks :-)
<janneke>ouch...haha -- I'll remove that
<civodul>arf, offload hook is not fully baked:
<ng0>does an web radio player for the command line written in guile exist? if so I can spare myself the time to convert my bash player to guile
<civodul>janneke: note that we cannot add the cross-toolchain variables at the bottom of cross-base.scm
<civodul>see the comment there
<civodul>so i have to strip that part
<civodul>i think it was just a convenience though
<lfam>civodul: If a package foo fails spuriously on Hydra, and I restart the build, will packages that failed as a result of foo's failure be restarted as well?
<civodul>i don't think so
<civodul>lfam: does it fail to new offload issues or something else?
<civodul>i just fixed an offload issue as i wrote on guix-sysadmin
<lfam>There was a spurious failure of gobject-introspection on staging. It succeeded when I restarted the build of that package. But the thousands of failures that resulted are still failing. Should I request a new evaluation?
<civodul>instead you should request to "restart all dependency-failed jobs"
<civodul>in the "actions" menu of the evaluation page
<civodul>something like that :-)
<lfam>Ah, that sounds like what I need :)
<civodul>ACTION -> zZz
<davidl>how long does it generally take to build something like webkit?
<davidl>I passed the --fallback flag to the guix system init command and it's been building webkit for hours...
<ng0>webkit is huge
<ng0>depending on your machine 1 - 13 hours
<davidl>then probably somewhere around 13 hours
<davidl>2,26 Ghz or something.
<davidl>2008 lenovo laptop.
<ng0>do we capture the start and end time of builds? this way we could easily get something where length of build is recorded and can be queried
<davidl>maybe a -i flag for interactive fallback mode.
<davidl>wouldn't hurt.
<ng0>there was this gentoo tool I used for this, you could list all builds, all builds of a certain application and the build which is currently happening and depending on wether there was previous recorded data it would give you an ETA
<lfam>david1: Supporting interactivity in the builds would break the functional packaging model? How would the human interaction be accounted for?
<lfam>And yes, building webkitgtk takes a very long time
<paroneayea>beep beep
<davidl>lfam: Im not qualified to answer either of those questions unfortunately xD
<davidl>the interactivity I considered was just something along a regular install script where you press yes or no.
<lfam>david1: Do you get what I mean? The functional packaging model tries to take all the inputs (source code, build scripts, etc) of a build into account, so that binaries can be substituted for building from source, but still be expected to provide the equivalent result. If a human do interact with the build process non-deterministically, this breaks the model
<lfam>Where do you think it would be useful to have a yes-no dialog?
<davidl>yeah I see kind of. I have programmed some haskell but Im not a developer.
<davidl>while invoking the guix system init command with a flag.
<davidl>I used --fallback so it would build packages from source which it couldn't download as binaries for some reason.
<davidl>but since those build processes take so long in case of webkit then maybe you would want to individually say to not build some packages.
<lfam>I typically use --dry-run before "big" things, to make sure I'm ready
<davidl>I suppose I should have done that.
<davidl>then I could have made sure to fetch these packages manually or something.
<davidl>but Im not sure, since webkit also has dependencies?
<lfam>If you can't fetch a binary substitute for webkitgtk right now, it's because we don't have one available.
<lfam>david1: Are you usig the 0.11.0 USB installer image?
<davidl>the 0.12 I think, since I entered guix pull to get the latest one.
<lfam>I don't believe we've tagged 0.12.0 yet :)
<lfam>So, you are somewhere in between
<davidl>yeah xD
<davidl>I was gonna do full disk encryption but needed lvm2 for grub to notice mapped devices.
<lfam>I was going to suggest `guix pull` after explaining some caveats. But since you already did that, I think that we must have made some change recently that requires a webkitgtk rebuild, and that rebuild is not done yet
<lfam>My best recommendation is to initialize with an OS configuration that doesn't require any graphical packages. Once you have the system installed, then reconfigure into a graphical system.
<davidl>The build can run overnight =) not a big problem really.
<lfam>Initialization is still somewhat brittle, so I prefer to init with the simplest system possible. Once installed, the system is very robust and you can reconfigure, roll-back, etc
<lfam>But, if you are willing to run your x200 overnight, I think that webkitgtk will be done by then :)
<davidl>mhm. Ill try that if it doesn't when I wake up.
<davidl>doesn't work*