IRC channel logs


back to list of logs

<ecbrown>wow, 8500 packages in guix!
<OriansJ>ecbrown: well yes, it is really easy to add a package to guix; simply take the time to figure out how to build the package and then document that information in a build definition and you are done
<OriansJ>For example here is one for astyle:
<pkill9>is there a way to create a simple custom build system out of a trivial-build-system?
<lfam>pkill9: Maybe I misundertand your question, but that is basically what you do with the trivial-build-system. It doesn't actually "do" anything otherwise
<ecbrown>OriansJ: already doing it :-)
<pkill9>lfam: i was thinking like defining the trivial-build-system into a variable and then specifying that variable as 'build-system' in the package, if that makes sense
<lfam>pkill9: Would it be different from making a new build system?
<pkill9>defining the trivial-build-system arguments*
<pkill9>not sure
<lfam>Have you taken a look at how the various build systems are defined?
<pkill9>yeah i had a quick look just now
<pkill9>actually i didn't look at font build system which may be more relevant
<lfam>Anyways, I think you could what you originally suggested, or adapt an existing build system (probably gnu-build-system)
<lfam>Font-build-system was created because all the font packages where doing basically the same thing with trivial-build-system. Looking at the transition from all the fonts' trivial-build-systems to the font-build-system would probably be useful
<mbakke>Hello Guix!
<mbakke>I'm struggling with channels, they don't seem to be on %load-path? So (search-patch ...) etc fails.
<jonsger> TLS cert is outdated
<xav1984>Hi everyone
<xav1984>I test guixsd, it's work nice , so i just cant' launch .appimage file
*ecbrown is interested in this, too. i've gotten execv (?) error
<ecbrown>i wonder if appimage assumes that there's stuff living in /usr/bin, etc
<xav1984>i have error no such a file or directory and you ?
<ecbrown>yeah, that sounds right.
<atw>I had this problem. I believe it is related to though it is because on GuixSD, libs are not in expected locations as they would be on traditional distros
<atw>(that answer is not 100% precise, if someone else could elaborate that would be nice)
<atw>In my case, I got not by running the appimage, but by writing a package definition for the version of LÖVE ( ) and building from source
<xav1984>ok, i need to use freecad on guixsd , the solution is building from source ?
<ecbrown>good thing there's 8500+ packages and all the dependencies are likely there
<ecbrown>better would be to make a package :-)))
<tune>I really want deluge to be packaged, but it feels confusing and difficult to me to do it myself
<atw>xav1984: FreeCAD appears to be FOSS, so if you write a package, you could contribute it!
<atw>tune: what's the difficulty?
<tune>not even sure where to get started
<tune>well, I have the defining packages page open
<tune>I get the feeling that packaging something on guix is easier than elsewhere, but I've never had to package anything
<tune>and I've heard some people in here have built their own deluge packages, so I'm also unsure why they haven't just submitted them to the repo
<lfam>tune: There's a Deluge package here:
<lfam>I'm not sure if it works or not. There is a bug report about it in that repo
<tune>I actually have that bookmarked also, that bug report is from me
<lfam>Okay :)
<tune>there was a gtk conflict when trying to install it, IIRC
<lfam>I played around with the package a bit a couple months ago, but started to feel like it was too much effort for something I probably wouldn't use (I'm using Transmission)
<lfam>Conflicts like that are a typical problem with propagated-inputs and a reason we generally try to avoid propagating things
<lfam>Usually it works with Python software. I think we could probably avoid propagating GTK+
<lfam>I mean, usually propagation works with Python software. But as you saw, it doesn't work to propagate both major versions of GTK+
<atw>maybe not the easiest package to get started with? :P
<atw>I am trying to guix pull from a channel I have made, but I am getting "guix pull: error: Git error: cannot locate remote-tracking branch 'release'". I believe that my channels.scm refers to a repo and a branch that both exist. What else can I check to find what I'm doing wrong?
<ecbrown>atw: can you try "origin/release"
<pkill9>atw: have you specified the branch name as 'release'? if so, try 'origin/release'?
<ecbrown>also, you may want to git pull, because i reported that and a fix was applied
<pkill9>yeah it was fixed in
<ecbrown>guix pull
<pkill9>that was 11 days ago
<atw>let me try...
<atw>thanks ecbrown and pkill9! pulling my channel now works but compiling the scheme file in my channel fails with "no code for module (git)". I can see that mbakke had this problem in my scrollback, but I'm not sure what the resolution was
<lfam>atw: Try installing guile-git
<atw>lfam: can do, but why sin't guix environment --ad-hoc guile-git -- guix pull sufficient?
<lfam>atw: Not sure, somehow it doesn't work for me. But, `guix environment guix --ad-hoc guile-git` does
<lfam>Well, in other related scenarios. I haven't tried using channels yet
<atw>lfam: seems like neither installing guile-git nor your invocation worked :/
*civodul finally replied to janneke re wip-bootstrap \o/
<civodul>atw: i suspect the fix will have to be similar to cb341c121919877ae6267a6460c0c17536d06eff
<civodul>it's a problem that these things can go unnoticed :-/
<thorwil>how are linebreaks in the description of a package handled?
<atw>thanks civodul! Maybe not many people are using external channels yet?
<civodul>atw: possibly!
<tune>I saw that icecat-bin in the AUR is updated to icecat 60. Will guix be getting it soon?
<janneke>civodul: thanks for your review!
<civodul>yw! it was overdue...
<janneke>aiui: we could do with a number of style issues/cleanups -- i very much agree
<janneke>i didn't see some of them `(,@..) eg :-)
<civodul>really no big deal compared to the huge step forward that this work represents
<janneke>so, how will "we" be doing this...shall i try to address some of your remarks and create a new wip-bootstrap?
<civodul>but i thought i'd collect these things as i was looking at the cofed
<janneke>yeah, i read it like that
<civodul>yes if you could address the easy bits, that'd be great
<civodul>then you can rebase on core-updates (or merge it, whichever is convenient)
<civodul>and then push it as "core-updates-next"
<janneke>i can also imagine "you" create core-updates-next' and fix my stupid mistakes in one go :-D
<civodul>i could do some of it, though i'd rather let you add the comments for patches etc. for instance
<janneke>yes, that makes sense
<civodul>so if you want, you can do that part (adding comments), and then i do the rest
<janneke>OK, i'll do what I can based on your feedback, create a new wip-bootstrap rebased on core-updates and ping you
<janneke>civodul: one more thing, i used the "mes"boot suffix for some packages, to avoid conflicts with the guix *-boot names
<janneke>i think that's kind of silly
<janneke>"it works"
<janneke>i could do with an idea to remove the "mes" prefix
<civodul>janneke: ah sure, either way is fine
<civodul>the story with the "boot0", "boot1", etc. names was to make the layering a bit more apparent
<civodul>the difficulty now is that "level 0" on i686 is not the same as on other architectures
<civodul>so in that sense, it might make sense to have "mesboot" (or whatever) vs. "boot"
<civodul>another option would be to use negative numbers or fractions :-)
<janneke>hehe :)
<civodul>like "gcc-boot0.5", etc.
<janneke>guile has rationals, right
<civodul>ah ah :-)
<civodul>but yeah, why not :-)
<civodul>oh i guess the problem is that we can't have slash in store file names
<civodul>so: exact->inexact :-)
<janneke>crap, *lol*
<civodul>atw: i'll push a fix shortly!
<nckx>tune: I assume that newer Icecat versions have the same (as yet unpackaged) Rust dependencies as newer FF versions. If so, no, not that soon. :-(
<thorwil>what do i make of a build requirment given as "libglib2.0-dev"?
<thorwil>i take it automake and intltools should appear as such in native-inputs, but i'm puzzled how libglib2.0-dev and libgimp2.0-dev map
<thorwil>looking at gimp-fourier, just ("glib" ,glib) and ("gimp" ,gimp), though i wonder how there is no minimum version encoded
<tune>oh, didn't know of the rust issue
<ng0>sorry to inform you, moving the bot will take a bit more time. but we'll catch up with the logs. I haven'T forgotten about it.
<ng0>so the guix 'nim' package is basically not really functional. I am closing in on having a functional package on my side with more system integration soon, but it needs some cleaning up and time before I can send this to you.
<ng0>it's fun to learn about this language internals, in just a couple of days after some weeks blockers this worked out pretty fast
<atw>sneek: later tell civodul my channel is working perfectly!
<sneek>Will do.
<ng0>i also have Docker (docker-ce) to the point where I just need to debug it. the basic package is done.
<ng0>there's some further trails down not so deep rabbit holes I want to look at, like if I need to build nim from pre-nim compiler sources or if the way it builds is alright wrt bootstrapping, etc