IRC channel 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: https://paste.debian.net/1042379/

<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> https://hpc.guixsd.org/ 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 https://askubuntu.com/a/133460 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 https://gitlab.com/technomancy/exo-encounter-667 not by running the appimage, but by writing a package definition for the version of LÖVE (https://gitlab.com/aterweele/exo-encounter-667/blob/guix/guix.scm ) and building from source

<xav1984>ok, i need to use freecad on guixsd , the solution is building from source ?

<ecbrown>probably

<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>unfamiliarity

<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: https://github.com/mrosset/guix-free/blob/master/gnu/packages/mrosset.scm

<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>Haha

<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 http://git.savannah.gnu.org/cgit/guix.git/commit/?id=37a6cdbf1b3503d3e60840a176318284b1f7ca25

<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?

<sneek>Okay.

<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

<civodul>*code

<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

<janneke>OK

<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

<civodul>WDYT?

<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>binutils-33-3/5

<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

IRC channel logs

2018-09-16.log