IRC channel logs

<zacts>mark_weaver: I got a response from the sabotage guys regarding the boehm-gc + musl patches

<zacts>mark_weaver: they said at least one patch is already upstream, and the other two are either on their way to being upstream, or may have already been comitted

<mark_weaver>zacts: good!

<sneek>Welcome back mark_weaver, you have 1 message.

<sneek>mark_weaver, dsmith says: Ok be root, reboot all is well

<zacts>mark_weaver: indeed, sounds promising, I thought.

<rekado>I'm currently installing software with guix on Fedora; when I switch to running the guix incarnation of the GNU system, can I simply copy over my /gnu directory to keep all the software I already compiled on Fedora? Are there any caveats?

<rekado>(it'll be the very same machine, so I'd back up /gnu to an external drive)

<rekado_>how should python packages be defined that provide both a library and executables? Should they have a "python-" prefix or is this reserved for python modules without executables?

<civodul>Hello Guix!

<Tsutsukakushi>hello civodul

<rekado_>civodul: thanks for fixing the bugs I reported so quickly!

<Sleep_Walker>are the patches I sent good for commit? I'd rather not have them forgotten...

<civodul>rekado_: you're welcome

<civodul>Sleep_Walker: i think so; let me check

<Sleep_Walker>thanks

<tadni`>Is there any big roadblocking things that would stop Wayland from being packaged, or is just no-one has attempted to yet?

<tadni`>In the long term, it seems that there is a dependence on KMS...

<tadni`>Which I think is Linux-only, so it might be problematic when trying to support the Hurd.

<rekado_>tadni`: support for wayland is an open issue for the Hurd, but it is not unportable: https://www.gnu.org/software/hurd/open_issues/wayland.html

<tadni`>rekado_: Very cool that this is a possibility.

<tadni`>There's not a ton of Wayland compositors out there, sans GNOME's really, atm, that is relatively complete... so we probably have awhile.

<tadni`>Loliwm, is actually a lot more complete than I thought would be. :^P

<Tsutsukakushi>i couldn't get loliwm working properly when i last tried

<taylanub>loliwm? doesn't look very mature. (hehe, hehe, get it?)

<taylanub>.oO( no ijp to ,shoot me here )

<Sleep_Walker>I liked quite this one https://github.com/michaelforney/velox/blob/master/README.md

<Tsutsukakushi>taylanub: we get it

<Sleep_Walker>similar to dwm but for Wayland

<Sleep_Walker>and E19 should work as well

<Sleep_Walker>but I'd rather see usable web browser in emacs and emacs running in FB/fbcon/... :)

<Tsutsukakushi>being able to run a graphical session inside just one screen or tmux pane would be nice

<tadni`>Sleep_Walker: I would rather see a basic compositor for Guile and a graphic toolkit that can render GTK in-buffer.

<tadni`>We can currently do this, via xorg.

<tadni`>It's just not an ideal experience.

<ijp>taylanub: don't tempt me

*tadni` checks if xwidget has actually made any progress.

<tadni`>There are actually a few commits, from this year.

<rekado_>I just built guix from git to get started with packaging. Unfortunately, when running "./pre-inst-env guix build my-package" I get a couple of errors, such as:

<rekado_>make: /bin/bash: Command not found

<rekado_>patch-shebang: ./scripts/makeBashScripts.py: warning: no binary for interpreter `python' found in $PATH

<rekado_>I thought any reference to /bin/bash would be replaced automatically?

<civodul>rekado_: the build environment includes only the store items that were explicitly specified as 'inputs', and notably it doesn't have /bin/bash and /bin/sh

<civodul>references to it are automatically replaced 90% of the time

<civodul>this must be one of the 10% left :-)

<civodul>likely cause is a Makefile that reads "SHELL = /bin/bash"

<civodul>could you check whether that is the case?

<rekado_>yes, that's the case

<rekado_>SHELL := /bin/bash -e

<civodul>ok

<civodul>so the recipe will need to patch that, possibly using the patch-makefile-SHELL procedure

<civodul>there should be examples of that in makefiles around

<rekado_>ok, I'll search the tree

<rekado_>thanks

<rekado_>civodul: the regular expression in patch-makefile-SHELL is insufficient in this case; it doesn't match a definition (i.e. where "colon equals" is used)

<rekado_>I patched it to "^ *SHELL[[:blank:]]*:?=[[:blank:]]*([[:graph:]]*/)([[:graph:]]+)(.*)$"

<rekado_>added ":?" before the equal sign. With this change the Makefile is patched up correctly.

<civodul>rekado_: oh ok; this change triggers a full rebuild, though

<civodul>we could do it in the 'core-updates' branch if you want, which is the staging area for full-rebuild changes

<rekado_>heh, I was already beginnig to wonder why guix build my-package results in a full rebuild...

<civodul>yeah

<civodul>the easiest approach will be to mimic patch-makefile-SHELL in your own code

<civodul>for the time being

<rekado_>ok

<rekado_>hmm, I just aborted the full rebuild and now guix build fails to build my package.

<rekado_>~/code/guix $ ./pre-inst-env guix build --keep-failed bedtools

<rekado_> guix build: error: bedtools: unknown package

<rekado_>my package recipe is in gnu/packages/bedtools.scm

<rekado_>(the function is named "bedtools" and the package name is "bedtools")

<davexunit>does 'make' pass?

<davexunit>function? it should be a variable.

<rekado_>davexunit: erm, yes, I meant function.

<davexunit>or rather, the variable should be bound to a package object, not a procedure.

<rekado_>erm, variable

<rekado_>(gah!)

<rekado_>this worked before my changes to utils.scm (which I reverted) and the full rebuild (which I aborted).

<rekado_>where is guix looking for packages when I invoke it as ./pre-inst-env guix build pgkname ?

<davexunit>it's searching the package modules in gnu/packages/ and GUIX_PACKAGE_PATH

<davexunit>is the package variable public?

<rekado_>yes, it is.

<rekado_>(define-public bedtools ...

<rekado_>and it did work a little while ago (unpacking the tarball, and failing to compile)

<davexunit>did you add bedtools.scm to the makefile?

<rekado_>no, I did not. Do I have to rebuild guix each time I add a new package?

<rekado_>or does the .scm have to be compiled to .go first?

<davexunit>every time you add a new module file

<davexunit>not a package

<rekado_>okay.

<davexunit>it doesn't *have* to be compiled via make

<davexunit>guile will auto-compile it

<davexunit>running make won't rebuild all of guix

<davexunit>does the things that have changed.

<davexunit>s/does/just/

<davexunit>weird typo

<rekado_>am I supposed to actually edit the generated Makefile or the precursor to it? Would a patch to add a new module file for packages have to include changes to the Makefile (or whichever of Makefile.{in,am} is expanded to it)?

<davexunit>rekado_: you want to edit gnu-system.am

<rekado_>ah, that's the one. Thanks.

<rekado_>I think I know why this stopped working before: syntax error in my module file (I really need to remember to enable paredit automatically)

<rekado_>everything is good again. Yay!

<davexunit>yay

<rekado_>bedtools has a Makefile in which "@python" is used to run a python script during make. I have already added python to the inputs, but the build still fails with this error:

<davexunit>I'd recommend looking for an appropriate module to put that package in instead of making a new module.

<rekado_>davexunit: I don't see anything appropriate. This is bioinformatics software.

<davexunit>you could start a bioinformatics module maybe?

<rekado_>sure.-

<civodul>agreed, that seems like the best option

<amirouche>I keep getting this error: substitute-binary: guix substitute-binary: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable

<davexunit>that means you haven't authorized any server to provide binaries

<davexunit>which is fine if you don't want to do that.

<amirouche>I do ^^

<alezost>amirouche: you need to authorize hydra: https://www.gnu.org/software/guix/manual/html_node/Substitutes.html

<amirouche>I mean I do want binaries, my machine is kind of slow

<davexunit>then read the link alezost posted :)

<amirouche>davexunit: by the way, I ran ``guix environment -l package.scm`` in a fresh checkout of sly and ./configure complains about missing dependencies (sdl right now)

<davexunit>amirouche: hmmm, could you email the error to davet@gnu.org? I'll look into it.

<amirouche>got it, both your blog article and sly documentation miss the ``-E sh`` at the end of ``guix environment -l package.scm`` but it still complains about missing gl function or something...

<amirouche>no hurry, I will get back to it more seriously later...

<davexunit>you don't need -E sh

<davexunit>guix environment automatically uses your $SHELL or /sh

<amirouche>ah!

<amirouche>adding something to $PS1 will be helpful

<davexunit>amirouche: yes, agreed.

<amirouche>seems like libglew is missing. well, I'll go back at my stuff, this is not very helpful anyway

<davexunit>amirouche: my sly environment works with guix atop debian. I thought that because I used the --pure flag to test that it would also work on the standalone guix system, but I guess not.

*mark_weaver employs civodul's sql query to restart all the mips dependency failures on hydra

<davexunit>amirouche: thanks for trying sly, though. the standalone guix system has some opengl issues that need to be dealt with, which is part of the problem you are having. I am unable to get any opengl programs to work currently.

<mark_weaver>(the python builds failed on mips for some mysterious reason, though restarting them manually worked)

<civodul>mark_weaver: oh ok, thanks for doing it

<davexunit> http://www.markshuttleworth.com/archives/1434

<davexunit>"Announcing Ubuntu Core, with snappy transactional upgrades"

<davexunit>looks like everyone is jumping on the bandwagon, but no one is using something like nix

<civodul>heh

<Steap_>davexunit: that is an Ubuntu thing

<Steap_>they suffer from a severe case of NIH

<civodul>from a quick glance it's not clear how it actually works

<davexunit>yeah I'm not sure either

<Steap_>Mir, Upstart...

<civodul>but it sounds like they're dropping apt-get altogether

<tadni`> Steap_: Well... :^P

<civodul>so they'll have just as much work to do as ourselves ;-)

<davexunit>haha

<davexunit>yeah

<tadni`>Steap_: I mean, NIH is fine ... if you have given reasons why they are doing such a thing. I think many could call GNU Distro exactly this.

<Steap_>well, not sure whether Ubuntu really has reasons

<Steap_>:)

<tadni`>Steap_: Eh, what alternatives to sys-v did we really have that were viable -- when upstart, started?

<tadni`>Mir, is a bit of a ... harder thing to argue for.

<Steap_>none, but we did not need any :)

<tadni`>Steap_: The greater community would argue with you.

<tadni`>Seeing, we have like ... 4? Bigish alternatives now.

<Steap_>hehe

<Steap_>one that works: sysV

<Steap_>:)

<tadni`>I've only done, very, very trivial write-ups in sysv. A little more with systemd, and a tiny bit in DmD.

<tadni`>I much prefer systemd and DmD over sysv. :^P

<tadni`>But whatever, as long as it's not blantantly deterimental to other sane and established systems for whatever reason, I don't really buy and/or give credence to berating people, espeically in FOSS, that fall suspect to this "NIH" mode of thinking. :^P

<tadni`>Especially since, again, if GNU Distro ever gets popular ... I'm sure we well get this front of complaints from the greater community too. Not seeing our reasons to "just use apt" or "just use systemd", or just use Debain, etc, etc.

<tadni`>as well will*

<davexunit>oh we'll get plenty of that

<davexunit>already heard it

<tadni`>I think, there's some save face possibility for the greater community -- just in how different it it from it's alternatives GNU+Linux variants, all-free or otherwise.

<tadni`>There's really not anything, sans NixOS that is similar. And they aren't pushing for mainstream Distro status, from what I can tell. :^P

<tadni`>Oh well, time will tell.

<tadni`>Why does (dhcp-client-service) not connect to my eth?

<DusXMT>tadni`: does it give you any error?

<tadni`>I don't know, it's before slim-service, so it probably gets drowned out.

<tadni`>Do I need to specify the intrface or something?

<tadni`>Like (dhcp-client-service #:interface "enp2s0") ?

<DusXMT>I'd think so? But perhaps it's a different, known bug, I'll check to see if it's fixed already, whether it could be it

<tadni`>#:dhcp isc-dhcp is the given option in the manual.

<tadni`>No idea what that does... :^P

<mark_weaver>I think it's supposed to run on all interfaces by default

<tadni`>As in, just (dhcp-client-service)?

<mark_weaver>I thought so, but I confess I don't currently use it.

<tadni`>mark_weaver: I've had it enabled for a week or more now, have rebooted at least 3 times and each time I had to manualy use dchlient.

<tadni`>"Return a service that runs dhcp, a Dynamic Host Configuration Protocol (DHCP) client, on all the non-loopback network interfaces. "

<tadni`>That's from the networking services documentation.

<mark_weaver>the relevant code is 'dchp-client-service' in gnu/services/networking.scm and the comments seem to imply that it's trying to listen on all interfaces

<DusXMT>tadni`: It's possible you're experiencing this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18483

<tadni`>Ah, seems possible to probable.

<tadni`>In any case, having a dmd-udev-bridge or something similar, as Ludo describes, seems very handy.

<mark_weaver>tadni`: what happens if you run "deco restart networking" ?

<tadni`>mark_weaver: Stops networking services, tells link is not ready for wifi interface, says service has been started.

<zacts>hi guix hackers

<Tsutsukakushi>hai zacts

<zacts>you have a cool nick Tsutsukakushi

<Tsutsukakushi>oh, thank you :3

<Tsutsukakushi>usually i'm just called weeaboo for it, quite rare that someone likes it

<davexunit>I immediately entered it in a search engine to see which anime series it was from

<davexunit>and it was one I haven't seen

<Tsutsukakushi>hentai ouji to warawanai neko

<Sleep_Walker>I actually never met someone who'd use 'weeaboo'

<Sleep_Walker>well, I feel like I'm surounded by otakus

<Sleep_Walker>I know about this only from PBF

<Tsutsukakushi>funnily it's most often the people on *chan irc channels and most *channers are weeaboos themselves

<bavier>I'm trying to use guix as an unprivileged user for the first time, and with a non-standard store-dir, and I'm getting errors in the strip phase of gcc-cross-boot0.

<bavier>I might have done something obviously wrong. The docs don't detailed unprivileged use much.

<bavier>Basically, I'm just running the daemon with `guix-daemon --disable-chroot`

<amirouche>bavier: can you paste the error somewhere?

<bavier>amirouche: http://paste.lisp.org/display/144645

<mark_weaver>I vaguely recall that it's important to keep the absolute store-dir name short, maybe because of a limit on the length of shebangs

<mark_weaver>just a guess

<mark_weaver>I'm not sure that anyone has tested running the daemon as non-root in guix, so there may be other problems too.

<davexunit>you lose build isolation when running as a non-root user

<mark_weaver>yeah, it's definitely best to run the daemon as root

<bavier>yes, but if you don't have such a luxury on a particular system...

<davexunit>ahhh

<mark_weaver> http://lwn.net/Articles/625199/

<mark_weaver>(unrelated to this discussion )

<davexunit>oof, that's a big list.

<mark_weaver>bavier: I agree that we should support it if possible, but you're in uncharted territory for guix

<bavier>mark_weaver: ok, wasn't aware. I'll see what I can debug then.

<Sleep_Walker>is there a way how to express that different parts of package has different licenses?

<Sleep_Walker>I found some use of (license (list ...)) ; and details in comment

<Sleep_Walker>but it won't be visible to users

<Sleep_Walker>and from user perspective I'm not sure if it means dual licensing or my case - different parts, different license

<bavier>Sleep_Walker: If passed a list of licenses, each license will show up in the output of `guix package --search` e.g., so it's user-visible in that regard

<mark_weaver>I've forgotten the meaning of a list of licenses. civodul would know.

<Sleep_Walker>bavier: but I'm afriad that the meaning of the list is not obvious, or is it?

<bavier>From what I've seen, a list is generally used for multi-licensed works

<bavier>If different parts of a package are covered under different licenses, I think this is just noted in comments at the moment.

<Sleep_Walker>bavier: ok, and what should I do when package is dual licensed?

<Sleep_Walker>use list as well?

<bavier>Sleep_Walker: yes

<civodul>mark_weaver: the meaning of a license list is actually undefined, which is the main reason why there must be a comment above

<civodul>low-tech ;-)

<civodul>we could have a procedure to mean "at the user's choice"

<Sleep_Walker>or use 'and' and 'or'

<civodul>that wouldn't work, because only one would be retained

<civodul>we need 'license-or' and 'license-and'

<civodul>bavier: as mark_weaver notes, there's a limitation on the shebang length, among other things

<bavier>civodul: do we know what the length is?

<civodul>oops, big CVE list for Xorg

<civodul>bavier: 128 bytes (!)

<civodul>search for "shebang" in tests/gexp.scm

IRC channel logs

2014-12-09.log