IRC channel logs


back to list of logs

<marusich>Hello, Guix!
<rekado>Hi marusich!
<noobly>does guixSD have an equivelant of gentoos use flags?
<rekado>noobly: you can easily customize packages.
<rekado>hmm, gjs does not like my build of mozjs-52. The configure-generated test program segfaults.
<snape>hi guix!
<amz31>snape: hey
<snape>amz31: hey!
<amz31>amz31: I tried to run cuirass
<amz31>it doesn't work, I am retrying now. Previously I was stuck during tests
<snape>amz31: you mean that tests don't pass?
<snape>they definitely should
<snape>make check?
<amz31>both stuck and don't pas
<snape>is cuirass up to date, and clean?
<amz31>I did guix package -f build-aux/guix.scm and now it does what I pasted above
<amz31>noob mistake
<amz31>I clean up. and restart the command
<amz31>it works better indeed
<amz31>no promise, I am hunted by my day job, but I will try stuff
<amz31>hello Labu
<amz31>snape: you remember the '(#:arguments (begin ... )) misunderstanding
<Labu>Hello amz31
<amz31>that form, doesn't respect lexical scoping, variables comes from somehere else that what is in the code directly visible, my understand is that at some point there is (eval quoted-expression derivation) or something like that
<amz31>what I would have understood and more easy to the mind would have been something like '(#:arguments (lambda (out %build-inputs ...) ...)
<amz31>this adds an extra step, ie call the procedure in the eval step by the build daemon but it's more clear what comes in
<amz31>mark told a good reason it's not like that but I don't remember why
<snape>I see what you mean
<amz31>I started the web server, I have a 'No elements here.' how can I have stuff in the table?
<snape>I thinka lambda would just give a false impression of respecting the lexical scoping though
<snape>I don't know enough to answer your question anyway
<snape>what you can do is send a mail to help-guix about it
<amz31>another quick question where is the TODO?
<amz31>grep TODO doesn't yield much
<snape>find -name :-)
<snape>at the root of the Guix repo
<snape>(unless you were talking about the Cuirass TODO?)
<amz31>but I found the manual
<amz31>snape: yes cuirass TODO
<amz31>snape: btw, sneek is gone and was replaced by a shallow copy of it called sneek_
<snape>oh. too bad.
<snape>hmm there is no Cuirass TODO in the repo
<amz31>I remember reading a document... well nvm
<snape>but for the Gsoc, people wrote a TODO in some email
<snape>that I have to find :-0
<snape>I meant :-)
<amz31>i got it
<amz31>no did not find it
<snape>hmm wait a minute
<amz31>well, maybe the interface of cuirass should be like gentoo's
<amz31>or debian or ubuntu
<amz31>it. package oriented
<amz31>ie. package oriented
<amz31>my understanding is that current proeminent information is "what was built" but when you work daily, you _also_ want to know what happened to a give package in particular
<snape>you're showing a cgit interface
<snape>it nothing of what Cuirass does
<snape>it *does nothing
<amz31>wrong like
<amz31>wrong link
<snape>Yes, that would be the "job-name"
<snape>it would be good to display all builds belonging to a "job-name"
<snape>with all architectures, etc
<amz31>the gentoo link doesn't link to a build log of any sort
<snape>hmm actually the job name contains the version
<amz31>a gentoo package browser was my first code contribution to free software
<snape>whereas a package doesn't, so there is a slight difference
<snape>! nice
<snape>mine was a libreoffice patch
<snape>amz31: I agree it would be nice to be able to have a package page that would show the builds for all versions / architectures / evaluations
<amz31>snape: tx you undertand what I meant
<snape>btw I'm working on a patch that merges the Builds and Derivations tables
<snape>and gets rid of the very-complicated db-get-builds procedure
<amz31>that will be fun to see
<ng0>snape: gentoo's view is just a customized cgit
<amz31>OrangeShark wants to replace cgit ;]
<amz31>with guile
<ng0>and the functions different
<amz31>hey ng0
<snape>ng0: which of amz31's links are you talking about? The first or the second?
<ng0><amz31> well, maybe the interface of cuirass should be like gentoo's
<amz31>ng0: sorry the correct link is
<amz31>i mean ^^
<amz31>ACTION should slow down
<ng0>we can not do that. we can take it as an inspiration, but the way guix packages are structured is unlike ports
<snape>ng0: yes, indeed, that first link was a customized cgit that does nothing of what Cuirass does
<ng0>same for
<ng0>the source for that is on their git
<amz31>ng0: yes I don't say to take their software but get inspiration from it
<ng0>hjave to search the url because i just have everything local
<ng0>i meant our layout is not like their layout. portage (once upon a time) derived from pkgsrc or one of the other ports
<amz31>somewhat off topic, I keep thinking about connecting guix git with cuirass not sure if it makes sens, right now my undertanding is that cuirass has no knowledge of the git guix repository? is that correct?
<snape>amz31: indeed, right now the Guix git repo is just one input among others
<snape>in the case of Berlin, it's the only one though
<amz31>I am wondering whether cuirasse reads the diff before starting an evaluation? the alternative is to rebuild everything at each commit
<snape>right now Cuirass rebuilds everything at each commit, but the patch I'm working on will change it
<snape>because this is extremely inefficient
<snape>instead it will build only the derivations that changed
<snape>that said, the underlying Guix won't build twice the same thing, so even now the extra builds aren't that costly
<snape>wip here:
<snape>(you can see that there is more "red" than "green", which is excellent :p)
<amz31>ah you are right!
<ng0>amz31: imo we should just look at other systems for this: what do people using it regularly like? what is it they don't like? how do we view the user interface as users, not developers?
<ng0>inspiration is too little
<ng0>and thinking a bit outside of the box, look at some of the BSD ports webinterfaces.
<amz31>well, my point is that from the user perspective the "entry point" is the package like displayed by guix edit woof
<amz31>ng0: I don't know BSD ports web interface
<ng0>there are search engines.
<ng0>from memory, I think only freebsd and netbsd have interfaces..
<ng0>then there's
<ng0>and something else
<ng0>even when they are very minimal we can take nots on it
<amz31>ah yes tx for sharing
<ng0>no, more like or what it was
<amz31>you are right, even if could displayed the git history in cuirass we can also link to gitweb
<ng0>ah, i think /ports/ports-.. is the listing
<ng0>i have to read emails now
<snape>amz31: linking Cuirass to the Guix repository isn't easy because some packages might come from GUIX_PACKAGE_PATH instead
<amz31>you are right
<snape>acually, they were linked before I added a commit that adds GUIX_PACKAGE_PATH support :p
***root is now known as Guest7377
<sadasaulna>Noob question here folks.. I have a GuixSD install, i'm reading about how you can write system configuration and apply it. Is there anyway to see the current configuration and just edit that?
<cbaines>sadasaulna, the current configuration is what you applied last
<cbaines>(assuming you haven't explicitly booted in to a previous generation of your system)
<Labu>I am looking guix web site. Is there a mean to use it on a BSD system ?
<sadasaulna>chaines, I thought so.. but this is a VM image I downloaded so I suppose I will never see what the file that created it was
<sadasaulna>chaines, ie if memory serves me right its a fresh install from the image supplied on the website
<Labu>I mean guix not the website
<snape>Labu: I don't see why you couldn't, but I don't know if anyone tried
<snape>Labu: I don't know if the binaries would be compatible
<Labu>Kernel is not the same and the documentation talk only about linux on several architecture. How binaries are chosen ? they are not the same
<Labu>no binaries are not of course
<amz31>I guess you have to try
<Labu>I will amz31
<Labu>But I need to know how it works before, I think
<snape>I'm pretty sure it's not supported then, but rekado surely knows better abou tit
<Labu>for binaries no
<snape>I meant, Guix on BSD
<Labu>but I think I can use it to build from source and make a repo
<Labu>I have just discovered guix
<ng0>Labu: no.
<ng0>I mean, not officially. you have to port it to the kernel
<Labu>ok ng0
<Labu>I ahave no idea the difficulty to do that
<Labu>I will look
<ng0>depending on what needs to be adjusted it can be easy or hard
<ng0>one long porting effort is the Hurd
<Labu>and guix works on Hurd ?
<ng0>the person doing that could give you some pointers where to start
<amz31>well, given most of guix is guile if all dependencies requirements are met it should not be very difficult, who knows?
<ng0>amz31: the challenge could lie in parts of guix itself.
<ng0>but it could just work.
<Labu>yes I must try to get an up to date guile version
<snape>Also, porting Guix isn't the same difficulty as porting GuixSD...
<ng0>I haven't tried on obsd laptop
<amz31>ng0: I agree
<Labu>I will begin with guixSD
<amz31>Labu: well, some love was given to guile on BSD
<ng0>i would begin with guix on one of the bsd, if you want to port it
<amz31>but the person moved to Linux I think
<snape>(I meant, using GuixSD with a BSD kernel is probably even more difficult)
<ng0>it just needs time.
<ng0>one of my experiments is just that
<ng0>and interchangable userland
<Labu>Is there something which stand from this amz31 ?
<amz31>Labu: i don't understand what you want me to comment on?
<Labu>guix work on guix SD, no ?
<amz31>with a linux kernel yes
<Labu>sorry amz3
<amz31>I don't what is more simple
<amz31>it depends where you want to invest time in
<ng0>amz31: openbsd has guile-2.2.3 in ports-wip
<amz31>myself, I like doing guile things, so I invest not a lot of time in guix itself, hence no custom kernel or other fancy things
<amz31>but at the same time i don't invest time in understanding how guile VM works and is built, i build 'webapps' after all
<Labu>the person which try to port on BSD. Is there somewhere I could find the result of this attempt ?
<amz31>so my view and my use of guix is direct by the wish to build gui stuff
<ng0>you both have a misundrstanding in communication.
<amz31>what is it?
<ng0>amz31 mentioned that someone on *some* BSD operating system was working on guile. no one is porting Guix or GuixSD to BSD at the moment, actively.
<amz31>ng0: true
<Labu>guile works on BSD
<ng0>if you want/need some OpenBSD userland applications, I can help with that already
<amz31>Labu: the work in guile for BSD is in stable guile 2.4 or something like that
<Labu>amz31 yes
<ng0>amz31: again: which BSD
<Labu>Net BSD
<amz31>ng0: it apple's bsd
<ng0>there's no apple bsd.
<amz31>I don't know how much portable are the fixes
<amz31>ofc there is
<ng0>so you mean OSX?
<amz31>it's not a BSD?
<ng0>it came a long time since taking parts of NetBSD
<ng0>*long way
<amz31>#hope :]
<Labu>the OSX kernel is Darwin, no ?
<amz31>i think yes
<amz31>there is also the compiler as dependency i think
<Labu>wich is built on mach kernel with some pieces from net BSD
<amz31>not sure what is on OSX
<ng0>FreeBSD requires an update of guile: ../FreeBSD/ports/UPDATING:10910: guile has been updated to version 1.8.8. Please rebuild all ports that
<ng0>but I'd focus on one BSD first.
<amz31>1.8.8 is antique
<Labu>I have a real Net BSD 7.1, with guile 2.0.14 from pkgsrc
<amz31>I use guile 2.2.4 to be precise
<Labu>yes I think about try to build guile 2.2.x on net bsd
<amz31>Labu: you try with that, maybe guix is backward compatible but it's bad pratice, we try to push newest stable version of guile
<ng0>I'd add the direct dependencies of Guix, and see if it just works
<amz31>Labu: like I said, it dependes what you wanto to do, if you want to fiddle with compiler errors and C go the guile 2.2.4 way otherwise try guile 2.0.4
<amz31>again it might work flawlessly with 2.2.4
<ng0>Labu: I think discussing this on the guix-devel mailinglist would get more attention from people who are not always around here.
<amz31>the adventure begins
<ng0>, it has a greylisting so your first message might be delayed
<Labu>I think I should try on a linux and learn about how it works before trying to do that on NetBSD. Like I said I have just began to discover guix
<Labu>thx ng0 for the mailinglist address
<ng0>Labu: how much experience with the BSD you use do you have?
<snape>ng0: Labu it's not a greylisting, but a human validation
<Labu>2 years with a daily use. Before I tried FreeBSD and Open BSD too
<ng0>hm.. could I PM you?
<Labu>yes no problem ng0
<sadasaulna>cbaines: looks like I forgot to copy my config.scm into /mnt/etc when i installed it
<sadasaulna>i am restalling anyway now
<cbaines>Ok :)
<amz31>Labu: let us know how things goes
<amz31>I did not see your email on devel mailling list
<Labu>yes amz31 I did not do this again
<Labu>I don't know if I am gonna do this right now
<Labu>I need familiarize to guix before
<amz31>you don't need to understand all the things to use it tho
<Labu>yes but I need to know how it works if I want to port it on Net BSD
<Labu>I am very new on
<vagrantc>netbsd would be something new for sure
<Labu>I am new on guix vagrantc
<vagrantc>guix makes significant use of user namespaces
<vagrantc>might be hard to port to bsd
<vagrantc>athough i guess it's possible to use without namespaces
<amz31>wait namespace are only for containers right?
<Labu>yes it is not a problem (If I well understand what user namespace means)
<vagrantc>containers are used for building the packages typically, no?
<Labu>I have application in my home which were not system wide installed
<Labu>but if it is standalone container it should be harder
<vagrantc>each package build happens in it's own container
<amz31>vagrantc: good to know
<amz31>I heard that was planned, so now it's alive :)
<vagrantc>i think that's been supported for quite some months
<Labu>what is the container system exactly ? Is it a guix native system ? It is possible to build something in a sandbox in netbsd. I use it for pkgsrc
<vagrantc>i think it just uses linux namespaces
<vagrantc>so it has it's own process tree, at the very least
<Labu>ths cgroups ?
<Labu>indeed there is no cgroup in netbsd
<Labu>on FreeBSD there is jail but not in NetBSD/OpenBSD
<vagrantc>i'm pretty sure it's possible to just build in plain chroots as well, but obviously the builds are less isolated. maybe using BSD jails would at least get some of that benefit
<Labu>there is no jails in Net BSD sadly
<Labu>But If it is just for build packages chroot could be sufisanrt
<rain1>nix stops build processes from accessing the web, I think
<rain1>does guix also do this?
<vagrantc>i would think so
<cbaines>rain1, note that it's not all build processes
<cbaines>fixed output derivations can access the web
<roptat> :/
<roptat>hehe "have a look at our github" with a link to a gitlab instance :)
<roptat>hm.. java-cup also requires itself, and not only jflex...
<roptat>That's a shame but I don't think I can do anything
<mbakke>Bah, my Chromium 68 build just failed at step 18883/19325 :/
<mbakke>snape: Are you renting out capacity on that build server of yours? :P
<mbakke>I've lost my build machine, and my laptop is completely unusable in the five hours it takes to compile Chromium.
<snape>sure, maybe mp me :-)
<mbakke>Cool, I'll email you tomorrow or so, heading out tonight so no rush :-)
<rekado>both mozjs 52 and 60 segfault for me when running a simple program that does JS_Init()
<rekado>this even happens when I use all the bundled inputs.
<rekado>the Internet suggests that I need to do something to mozglue at link time.
<rain1> NOTE to users in Crimea, Cuba, Iran, North Korea, Sudan, and Syria: may not be accessible after the migration to Google. Google has informed us that there are legal restrictions that are imposed for those countries
<rain1>interesting info to the people who just moved from github to gitlab..
<OriansJ>rain1: That is why essential projects need to remember to have multiple independent hosts to ensure consistent availability and greater fault tolerance. Eg if your software is hosted on a Single host and it is being used by others, you need to fix that problem promptly
<rain1>totally. It's really simply to add multiple remotes!
<rain1>then every git push uploads the code to 5 places
<OriansJ>exactly, it also makes it easier for other people to notice differences between what is provided by different hosts and spot host based tampering.
<OriansJ>Oh and due to recent behavior on #guix-code-of-conduct-discussion ; it has been switched to invite only (anyone invited is able to /invite anyone else they want) and no one is eligable for invites for 48 hours to let the people involved cool off.
<rekado>fixed gjs! The internet was right.
<OriansJ>rekado: nicely done
***Tionis is now known as Guest90125
<pkill9>does anyone have any idea of what causes this test failure?
<pkill9>it's the gst-plugins-base package, and it successfuly builds+tests on x86-64, but not on i686 nor on arm
<Copenhagen_Bram>Hi! How do I put the /gnu/store directory in /home? My root partition is sort of small
<rekado>Copenhagen_Bram: you cannot easily put /gnu in /home.
<pkill9>Copenhagen_Bram: if you're using guix on a foreign distro you can bind-mount it from /home/gnu-store to /gnu/store
<Copenhagen_Bram>Even during the installation of guix?
<Copenhagen_Bram>hrm alright
<pkill9>on GuixSD I don't know, because you nee dto bind-mount before the guix-daemon is run
<pkill9>i wanted to do that a while back also
<rekado>you would even need to do this before booting the kernel.
<pkill9>(you can technically recompile guix to use a different directory, but then you'll be unable to get substitutes since they'll be compiled to point to /gnu/store/x, which i assume you would want)
<Copenhagen_Bram>ah i'm on trisquel lol
<pkill9>oh yeah cos hte kernel is also in the store
<pkill9>aht hen it's easy, just add an fstab entry that bind-mounts the new directory to /gnu/store
<pkill9>i confirm it works cos i did that on slackware
<Copenhagen_Bram>I wonder if on guixsd you could move individual directories from /gnu/store to the home directory and rbind them to /gnu/store/whatever
<Copenhagen_Bram>rbind is just recursive bind lol