IRC channel logs

<lfam>Cool, looks good. Any idea when it's necessary to define (name) and when it's not?

<lfam>paroneayea ^

<paroneayea>lfam: hm good question, I can probably drop the (name) here. It couldn't *before* I did the package-with-python-2 on the inherited package

<paroneayea>but now it should be implied

<paroneayea>let me verify....

<paroneayea>lfam: looks like I don't need that

<paroneayea>so that was duplication

<paroneayea>removing that line, ok to push?

<davexunit> https://news.ycombinator.com/item?id=11088125

<davexunit>"So you want to write a package manager"

<lfam>paroneayea: As long as it works, I think so!

<paroneayea>lfam: cool

<lfam>davexunit: I saw that headline.

<paroneayea>davexunit: I skimmed that yesterday, it was funny

<paroneayea>though I didn't pay attention enough to see if useful

<lfam>ACTION groan

<paroneayea>davexunit: I think the takeaway is that people are under pressure to write new package mangers for everything but we should stop doing it.

<davexunit>paroneayea: yeah, but the alternatives people are advocating for seem even worse. :/

<davexunit>the hacker news comments are discouraging.

<davexunit>instead of package managers, just ship a self-contained executable!

<davexunit>brilliant

<paroneayea>davexunit: more fuel to the fire for the morning:

<paroneayea> https://blog.tincho.org/posts/Why_I_am_not_touching_node.js/

<lfam>That Medium article was way too long for me to read considering that searching for "Guix" and "Nix" returns no results.

<lfam>If they haven't researched the state of the art, then I figure their conclusions must be wrong.

<lfam>And if they are really advocating statically linked executables, then they also haven't considered what happens when their bundled dependencies earn a CVE

<davexunit>yeah, the article still seems to think that "dependency resolution" is a thing that should be done.

<davexunit>lfam: I don't know if the article advocates that, but the HN responses do.

<lfam>To be fair to those commenters, I didn't get it until I started working on Guix. I never imagined the pace of vulnerability discovery.

<paroneayea>Guix teaches you a lot about packaging and what makes sense and what doesn't

<paroneayea>I had set a goal last year to try and *really* understand packaging, because all I knew was MediaGoblin's situation was a mess

<paroneayea>I feel like Guix has helped me a lot there

<paroneayea>and the barrier to entry to package in guix is *so much less* than in Debian, etc.

<paroneayea>for me, at least. I do have the bias that I was already comfortable with lisps (but not scheme)

<lfam>paroneayea: There are a few pieces of software that I have decided not to self-host due to packaging issues. Usually they are "web apps" with a catacomb of dependencies

<lfam>And by "not self-host" I mean "not use"

<paroneayea>lfam: I don't blame you

<paroneayea>lfam: the situation is so bad that I was unwilling to deliver on my "premium hosting" promise from the last campaign until I knew of a better solution, because even I didn't want to deploy my own software with that state of the world

<paroneayea>and to be fair, mediagoblin made its share of mistakes, amidst a nest of mistakes, because I just *didn't know better*, and nobody was giving me better advice either

<paroneayea>so a lot of it is my fault

<paroneayea>but guix has been a path of sanity

<NiAsterisk>i don't get nodejs.. when did people just give up to normal packaging? this brave browser is the first nodejs based software I used I think.. weird.

<paroneayea>NiAsterisk: I think also though that the pressures of webdev cycles, it's kind of understandable without seeing nix/guix how people made that mistake

<paroneayea>I have empathy, having been in that land for a long time

<paroneayea>webdev is so bad and you're desparate to try to simplify things for your users

<paroneayea>but those "simplifications" are usually short term wins, long run disasters

<lfam>Well, I hope we can help you achieve your goal and get that premium hosting going!

<lfam>It's really important for free software projects to have some source of support such as premium hosting, in my opinion.

<davexunit>"The language package manager can have so much richer information than the system one"

<davexunit>WAT

<daviid>davexunit: that shows he/she does not really know what he/she is talking about, so not worth even making a comment or losing precious time reading more ... imo

<daviid>bbl

<lfam>davexunit: I'm getting mails bounced from your worcester.edu address

<davexunit>lfam: hmmm

<davexunit>I am still receiving mail

<davexunit>lfam: what address are you using exactly?

<rain1>hello, success! guix with luks on the metal

<lfam>davexunit: Here's the error message: <dthompson2@worcester.edu>: Host or domain name not found. Name service error for name=worcester.edu type=MX: Host not found, try again

<lfam>I suppose the problem could be on my end as well

<davexunit>lfam: I would suspect so, I have been getting mail all day.

<lfam>Okay, it's happened a few times in the last few days. Maybe worcester.edu is angry with fastmail.com.

<rain1>is there a program to download files while in the installer?

<rain1>it doesn't have curl or wget

<davexunit>rain1: you can install wget

<rain1>i did that but it took a really long time

<davexunit>probably because hydra is slow

<davexunit>that's the way it is until we upgrade our servers

<rain1>clearly guixsd is able to download things somehow, it could be kind to expose that

<lfam>You can easily create your own installation image with `guix system disk-image --image-size=1024MiB gnu/system/install.scm`. So, you can edit install.scm to provide some package in the installation image.

<lfam>rain1 ^

<NiAsterisk>hm.. so I did some changes in a new branch, did guix environment guix , did configure and build inside this branch, left the environment, tried `guix environment --container --ad-hoc emacs-popup -- guix build emacs-popup and I get "emacs-popup package not found" am i still doint it wrong?

<rain1>thanks

<lfam>NiAsterisk: you configured and built what?

<NiAsterisk>in a recent git checkout, built the whole branch after a make clean-recursive

<lfam>If you are using `guix environment foo`, then you are getting a development environment for foo.

<lfam>I think your workflow is too complicated.

<mark_weaver>rain1: guix's own downloader can be used via "guix download <URL>", but note that it always adds the downloaded things to /gnu/store

<mark_weaver>which is harmless

<NiAsterisk>maybe...

<rain1>that's a really nice tip! I wish i kkew that..

<lfam>NiAsterisk: Here is a method that works. It assumes that you have already built Guix in the git checkout.

<rain1>just to grab files like a premade system configuration

<lfam>Make your changes on a branch. Then `./pre-inst-env guix build foo`

<mark_weaver>the filename in the store will be one of the things printed out, along with its hash. if you want it somewhere else, copy it there.

<mark_weaver>rain1: ^^

<NiAsterisk>without being in a environment or container?

<NiAsterisk>although, it's some kind of envrionment, right?

<lfam>NiAsterisk: You don't need to be using `guix environment` when you use `guix build` AFAIK. The core build system of Guix puts everything in a clean chroot or container already.

<NiAsterisk>oh.

<mark_weaver>rain1: but it should also be mentioned that most of what you need to "guix package -i wget" from the installer are things that you'd need to download anyway for the subsequent "guix system init"

<mark_weaver>(assuming that you "guix pull" before doing both of those steps)

<rain1>oh so it wasn't wasted time

<lfam>NiAsterisk: '--ad-hoc curl' puts curl itself in your environment, so that you could use curl.

<NiAsterisk>okay, I'll just try to adapt what I do

<NiAsterisk>thanks

<lfam>./pre-inst-env sets up the environment for you

<lfam>NiAsterisk: The reason you got that error message is that you didn't use ./pre-inst-env. Instead, your Guix was looking for emacs-popup in the upstream package database, rather than your git checkout.

<lfam>Also, since using a binary substitute and building from source are transparent in Guix, `./pre-inst-env guix environment --container --ad-hoc emacs-popup` will build emacs-popup for you if it is not already built.

<lfam>Afterwards, you will be in a container that has emacs-popup on your PATH.

<rain1>when will hydra be replaced/faster?

<CompanionCube>Soon(tm)

<mark_weaver>rain1: there's one iteration that should happen within two weeks, where the FSF is upgrading the hardware underlying their VMs, including the one that hosts hydra.gnu.org. and, independently of that, we're building a new bare-metal box to replace hydra.gnu.org that we hope to deploy within two months.

<rain1>alright! that's exciting

<lfam>Sometimes it really is faster to build from source with --no-substitutes.

<lfam>Also, if you are iterating over a package you are working on, you might get all the substitutes on the first try. Then, subsequent iterations can use --no-substitutes and be much faster!

<mark_weaver>rain1: right, that's always an option, but it should be noted that it's quite a lot of stuff to build, given that at our base we do something roughly analogous to Cross [GNU/]Linux From Scratch.

<lfam>Oh, I forgot rain1 was building a new system. Yes, that would take a while :)

<rain1>ah but i have my system now :)

<rain1>im really happy that it all works

<mark_weaver>\\o/

<davexunit>NiAsterisk: when you do 'guix environment --container', you cut off access to the guix daemon and all that stuff.

<mark_weaver>davexunit: regarding your question earlier about what automounts removable drives in gnome: I'm not sure, but I think that's udisks' job. we have a (udisks-service) in %desktop-services, but maybe we need some additional configuration to specify that things should be mounted automatically. policykit might also fit into this, dunno.

<davexunit>mark_weaver: ah, okay. I might look into udisks sometime if I find the motivation. :)

<davexunit>thanks.

<calher>When I DL a tarball, do I get the hash from `guix hash <tarball>'?

<parabool>is it of any concern if a gpg fingerprint is exactly the same as shown on a website, but with an extra space right in the middle? ie 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910 (this is not guix, but can't seem to find an answer elsewhwere)

<mark_weaver>gvfs is different. iirc, the idea is that GNOME programs access the filesystem via gvfs instead of regular POSIX calls, and that allows programs using gvfs to access files over FTP and SSH semi-transparently.

<calher>parabool: Spaces no matter.

<mark_weaver>(without the need for something like FUSE or Hurd)

<parabool>calher, ty

<mark_weaver>calher: yes, "guix hash" is the right tool for that.

<calher>Can Guix deal with bzip2?

<mark_weaver>yes

<mark_weaver>also gzip, lzip, zip, and xz

<calher>What does (gnu packages ...) mean?

<calher>Oh wait, I can look at the curl declaration for that.

<mark_weaver>calher: those are name of scheme modules, which correspond to files gnu/packages/....scm in the source tree.

<calher>OK, so nothing to do with GNU packages.

<rain1>weird im having a lot of trouble accessing websites

<rain1>keep getting sec_error_ocsp_server_error in icecat

<mark_weaver>well, they are packages that are part of the GNU *system*, but indeed it does not imply that the packages are part of the GNU project itself.

<rain1>0% packet loss though

<rain1>with a ping test

<mark_weaver>rain1: icecat makes TLS negotiation more strict by default in various ways. I can dig up the list of settings they tweaked compared with upstream firefox ESR

<rain1>that explains it! I can't even google to find out how to turn it off just now

<mark_weaver>rain1: see http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/settings.js#n146

<mark_weaver>rain1: recently, in the guix package for icecat, I removed the four customizations after the "// Avoid logjam attack" comment in that file

<rain1>thank you, now i can google

<mark_weaver>rain1: I notice that some of those have "oscp" in the name: security.OCSP.enabled and security.OCSP.require

<paroneayea>hm

<mark_weaver>others that might cause problems are security.ssl.require_safe_negotiation and security.ssl.treat_unsafe_negotiation_as_broken

<rain1>I just disabled OCSP

<mark_weaver>rain1: you can customize these via the "about:config" page.

<mark_weaver>rain1: it's strange that google didn't work for you though. I certainly have never had that problem.

<mark_weaver>(nor have I heard any reports of it not working)

<rain1>even gnu.org wasn't working for abit, then it worked

<rain1>again with the OCSP error

<mark_weaver>rain1: I almost suspect a man-in-the-middle somewhere between you and them.

<mark_weaver>maybe some intrusive proxy?

<rain1>nothing that I knowabout

<mark_weaver>(maybe a transparent proxy)

<mark_weaver>this is all very unusual and raises alarm bells for me.

<mark_weaver>I have OCSP enabled and I access google and gnu all the time.

<rain1>i dunno i think firefox normally has ocsp, and i have no trouble usually

<rain1>just on guix for the first time and this happened

<mark_weaver>(admittedly, I only use google for some searches, and not for much else)

<paroneayea>so

<rain1>i have heard that duckduckgo is not trustworthy, i forgot the details

<paroneayea>we might have to make a real decision on this sqlite and python stuff soon, or at least I hope we will

<rain1>it wasn't loading anyway, which is why i tried google but that wasnt working either

<paroneayea>it's a blocker on mediagoblin's packaging, at least

<paroneayea>and having broken python + sqlite seems worrying anyway.

<paroneayea>the tests fail in that certain operations silently don't happen in the database, as far as I can tell

<paroneayea>from looking at the sqlalchemy failed tests

<paroneayea>ACTION should send another email to the list...

<mark_weaver>paroneayea: have you looked for an upstream bug report in sqlalchemy or sqlite about this? if there's no upstream bug report yet, they should be made aware of the problem, for starters.

<calher>Why `#:use-module (gnu packages gawk))'?

<paroneayea>mark_weaver: yeah I suppose you're right

<paroneayea>mark_weaver: I didn't see any when I looked

<paroneayea>I'll try to send one soon. In the meanwhile I'm going to focus on packaging all the other remaining things.

<mark_weaver>paroneayea: in the meantime, downgrading 'sqlite' would entail about 6500 rebuilds. better to make a separate older sqlite package, if needed, as civodul suggested.

<mark_weaver>calher: some context would help

<mark_weaver>presumably the file that contains that needs a binding exported by the (gnu packages gawk) module. most likely, a package object.

<mark_weaver>and since 'gawk' is the only binding exported by that module, I guess that's what it needs.

<paroneayea>mark_weaver: right, I submitted a patch for that

<paroneayea>davexunit raised a concern that it might have unintended consequences. I'm really not sure either way.

<mark_weaver>paroneayea: there's also the question of whether the older sqlite has known security flaws.

<paroneayea>I guess it compiles sqlite stuff linking it right into python, so it's *probably* fine...

<mark_weaver>paroneayea: I notice upstream has a newer sqlite, 3.10.2, which seems to have some important bug fixes.

<mark_weaver>maybe one of those bugs is what's causing this problem?

<mark_weaver>paroneayea: it would be interesting to see if the problem with sqlalchemy happens with sqlite-3.10.2

<mark_weaver>better to upgrade than downgrade, if that works.

<mark_weaver>I notice

<mark_weaver> https://sqlite.org/releaselog/3_10_2.html

<mark_weaver>includes "Critical bug fix: Version 3.10.0 introduced a case-folding bug in the LIKE operator which is fixed by this patch release. Ticket 80369eddd5c94."

<mark_weaver> https://www.sqlite.org/src/info/80369eddd5c94

<paroneayea>I don't think thtat was the source of the test failures I saw, but could be wrong...

<mark_weaver>paroneayea: no doubt there have been many other bug fixes as well. it would be great to try sqlite-3.10.2 with sqlalchemy.

<mark_weaver>because if it doesn't work, then we should report the bug upstream.

<paroneayea>mark_weaver: ok, I'll give it a try in a few, gonna finish trying to get pytest-xdist working

<mark_weaver>thanks!

<paroneayea>It's nice getting more MediaGoblin deps packaged and in! :)

<paroneayea>my overly ambitious goal will be to have all of them packaged locally, but maybe not upstream to guix, by tomorrow night.

<calher>mark_weaver: In the GNU Hello package definition.

<mark_weaver>oooh, nice!

<paroneayea>all the python ones that is

<paroneayea>we're not going to talk about the js deps for now ;)

<rain1>sorry im just a little confused as to how I would edit /etc/resolve.conf

<rain1>i can use su to become root but root does not have zile or nano or guix

<mark_weaver>calher: I don't see any occurrence of "guix" in the file containing the 'hello' package.

<mark_weaver>s/"guix"/"gawk"/

<mark_weaver>rain1: use "su -" instead

<rain1>thanks!

<mark_weaver>plain su sets a hard-coded PATH with directories that we don't have in GuixSD.

<rain1>changing DNS didn't fix the strange internet failing thing

<mark_weaver>I guess maybe we should patch 'su' to use a different path for us.

<mark_weaver>rain1: /etc/resolv.conf is normally managed by dhclient

<calher>mark_weaver: I see it in <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html>.

<rain1>ah i shouldn't edit it manually, ill read the dhclient manual

<calher>BTW, the docs I have on my system do not include the most recent manuals with the shepherd change, even though my system now has shepherd because of getting things straight from git on the root account. i guess it was all the package definitions or something from git.

<mark_weaver>calher: ah, I see. well, that version of the hello package includes 'gawk' in the inputs, so it needs to access the 'gawk' binding from (gnu packages gawk)

<mark_weaver>rain1: why do you feel the need to edit /etc/resolv.conf? what did dhclient do wrong?

<calher>OK; took it out of my definitin. -- Ugh, I need to change back to Dvorak, my fingers are getting tied.

<rain1>sorry DNS did fix it

<rain1>mark_weaver: I didn't know that I should use dhclient, I will read its manual and use it in future

<rain1>in guix stuff is different, i have some learning to do

<mark_weaver>rain1: dhclient is the DHCP client that we use, btw.

<rain1>oh dhclient did nothing wrong: it set my DNS to use my router

<mark_weaver>rain1: if you use 'wicd' to configure your network, that uses dhclient behind the scenes.

<rain1>and for some reason that worked really badly

<rain1>but using a different dns works ok

<rain1>so it was a combination of that and icecat being strict about OCSP

<rain1>maybe the OCSP stuff will be alright now too

<mark_weaver>your router DNS might be doing something nasty

<mark_weaver>bah

<mark_weaver>does your ISP control your router?

<rain1>yeah i think so

<mark_weaver>if you have administrative access to it, you might be able to configure what DNS server(s) is tells DHCP clients to use.

<mark_weaver>s/is/it/

<mark_weaver>one thing that nasty ISPs sometimes do is provide DNS servers that never fail on any lookup. failed lookups are redirected to a site they run full of ads.

<mark_weaver>or at least I recall reading about that practice a few years ago. I don't know what they do now.

<mark_weaver>or maybe your router has simply been hacked

<rain1>yeah i've run into that in the past, hate that

<rain1>that wasn't the issue here

<rain1>i wonder if it was hacked i wouldn't know how to verify that or anything

<rain1>but i don't know if this is a sign of that

<mark_weaver>rain1: if you use 'wicd', you can override the DNS servers used for a specific wireless network.

<mark_weaver>it's part of the per-network configuration

<calher>I'm scared to test this <http://sprunge.us/VNhI> out.

<mark_weaver>calher: what are you afraid of?

<calher>I don't know if Guix will put the man page in the right place, or if it needs to read the Makefile, or if I need to change the Makefile (made for FreeBSD).

<mark_weaver>just try "guix build -K mcwm" and find out

<calher>Or if I didn't properly designate the dependencies.

<calher>It's scary.

<mark_weaver>failure is cheap in guix

<mark_weaver>builds are done in an isolated build container as an unprivileged user.

<calher>cal@leela 20h ->guix build -K mcwm

<calher>guix build: error: mcwm: unknown package

<calher>cal@leela 20h ->

<mark_weaver>it doesn't have the ability to mutate any state on your system besides creating the output director(ies)

<calher>mcwm.scm is in "~/Bazaar/".

<mark_weaver>calher: see GUIX_PACKAGE_PATH in the manual

<mark_weaver>better not set it to a directory that has a lot of other stuff in it.

<mark_weaver>calher: btw, there is no (gnu packages libxcb) module. libxcb is in the (gnu packages xorg) module.

<mark_weaver>"guix package -s libxcb" will tell you where it is

<NiAsterisk>hm... are packages in melpa just .el files? the corresponding .git listed in the file in melpa contains more than just .el files. with emacs-build-system (I used elpa import) I get an error on "no tar file"

<calher>mark_weaver: OK, `#:use-module (gnu packages xorg)'.

<NiAsterisk>should I just use git-fetch then?

<calher>mark_weaver: Use `(inputs `(("xorg" ,libxcb)))'?

<mark_weaver>calher: `(("libxcb" ,libxcb))

<calher>mark_weaver: But you said they're in xorg.

<mark_weaver>calher: what gave you the idea that the string in that 'inputs' field has anything to do with what module libxcb is in?

<paroneayea>in case anyone sees the commit emails and gets confused:

<paroneayea>I accidentally pushed my private mediagoblin-deps branch, but then realized it and deleted it

<mark_weaver>paroneayea: heh, no worries :)

<paroneayea>all the stuff in there will go in wip-mediagoblin shortly

<paroneayea>just a local workflow thing because mediagoblin needs to be the last commit, and makes rebasing easier

<mark_weaver>sure, makes sense

<calher>Error for <http://sprunge.us/AWVf>: guix build: error: #<unspecified>: not something we can build

<calher>From $ guix build -f mcwm.scm

<mark_weaver>calher: "guix build -f" requires that the final expression in the file evaluates to a package object. so if you want to do it that way, you need to add "mcwm" (without the quotes) to the end of the file.

<mark_weaver>(define ...) evaluates to #<unspecified>, hence the error.

<mark_weaver>note that the example in the manual just has (package ...) as the final expression, without the 'define'.

<calher>(define-module (gnu packages hello) ...

<calher>(define-public hello ...

<calher>> without the 'define'

<calher>:/

<mark_weaver>I'm sorry, I don't have time to continue giving this amount of help to you, specifically.

<calher>cal@leela 20h ->curl --silent http://sprunge.us/AWVf | grep 'define '

<calher>cal@leela 20h ->

<iyzsong>calher: you can do `echo mcwm >> mcwm.scm'.

<calher>Atoms outside lists?!

<NiAsterisk>well, I'll just try with git for now.

<calher>And now, something completely different: <https://paste.debian.net/plain/385018>.

<calher>^ It did new stuff but it still failed.

<calher>WTF, the example definition under -f in <https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-build.html> is different.

<calher>Changed mcwm.scm to <http://hastebin.com/raw/itoyisobip>.

<iyzsong>calher: yeah, mcwm don't use `configure', you should delete the 'configure' phases and set 'PREFIX', see 'dmenu' for example.

<calher>iyzsong: Oh crap, I forgot the GNU Build System assumes a configure script.

<NiAsterisk>I'm using the emacs-build-system without any changes so far. is this something okay for guix, or should I removed README.md, Cask, .gitignore, .git/, Makefile and travis.yml before installing? https://ptpb.pw/4rG3.txt

<lfam>paroneayea: I just noticed that in python2-wtforms, python2-setuptools is more properly a native-input.

<lfam>Since it's only used at build time IIUC

<NiAsterisk_>arg. 5 AM already. i really want to get this lispf4 issue to get fixed. gdb isn't helping very much.. hrm.

<mark_weaver>strace is often more useful for debugging problems of relevance to guix packages

<paroneayea>lfam: ah you're right

<paroneayea>lfam: I can push that fix.

<lfam>When you realize upstream's test suite has been totally broken for several years...

<NiAsterisk_>possibly. I'll try

<NiAsterisk_>something with permission levels still, I guess. maybe I just go to sleep and try tomorrow. but strace reads like it's still readonly, no matter which permission level..

<NiAsterisk_>g'night

<lfam>I have a package that wants to run tests with tox, but I get this error: ERROR: toxini file 'tox.ini' not found

<lfam>Anyone have any ideas?

<lfam>Never mind.

<lfam>They don't distribute that file with their software.

<calher>iyzsong: What is #:make-flags in dmenu?

<iyzsong>calher: it will be passed to 'make', 'make check' and 'make install' by 'gnu-build-system'.

<iyzsong>it's in gnu-build-system.scm as '(system* "make" "install" make-flags)'.

<calher>To build MCWM, I just do make; make install.

<calher>iyzsong: ->guix build -f mcwm.scm

<calher>guix build: error: failed to load 'mcwm.scm':

<calher>/home/cal/Bazaar/mcwm.scm:8:2: In procedure #<procedure 9f03680 ()>:

<calher>/home/cal/Bazaar/mcwm.scm:8:2: In procedure module-lookup: Unbound variable: mcwm

<calher>mcwm.scm source: <http://hastebin.com/raw/celalocama>.

<lfam>calher: My Scheme is still weak, but what if you wrapped the (package) in a (define) or a (define-public)

<iyzsong>or, you can remove the last 'mcwm' line.

<calher>But it sort of worked last time.

<calher>And someone was telling me to remove the define crap and put atom 'mcwm' at the end because I'm doing guix build -f

<iyzsong>remove the 'define' or add 'mcwm', not both :-)

<calher>The example for guix bulid -f <https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-build.html#Invoking-guix-build> does not wrap '(package ...' in anything.

<calher>iyzsong: oh ok

<calher>Using <http://hastebin.com/raw/tikikucaxi>...

<iyzsong>calher: yeah, reason to learn scheme :-)

<calher>Failed. Using <http://hastebin.com/raw/ajiqarejox>...

<calher>iyzsong: Scheme is easy. It's the Guix stuff that's weird.

<calher>mcwm.c:42:29: fatal error: xcb/xcb_keysyms.h: No such file or directory #include <xcb/xcb_keysyms.h>

<calher>But... I included XCB! Does Guix cut XCB into pieces, too? I thought just Ubuntu did that...

<iyzsong>well, missing depends of 'xcb-util-wm' and 'xcb-util-keysyms'.

<calher>Yep, it is split up. Dammit!

<calher>cal@leela 23h ->s keysyms

<calher>name: xcb-util-keysyms

<calher>iyzsong: How did you know about xcb-util-wm and xcb-util-keysyms?

<iyzsong>calher: I used to use Exherbo(like Gentoo) which build all packages from sources, so I know what the error means. and then I run 'guix package -s xcb-util' to find them.

<calher>iyzsong: OK, make built the thing, but it couldn't do make check (which I never did).

<iyzsong>add '#:tests #f' to arguments will disable the tests

<iyzsong>^^ considered better than delete the 'check' phase because it's more obvious.

<calher>Added #:tests? #f to (arguments).

<calher>starting phase `install'

<calher>install -m 755 mcwm /gnu/store/vah2y7nyaq0f8gzgg3c9iwp81y2zx3xd-mcwm-20130209-2/bin

<calher>install: cannot create regular file ‘/gnu/store/vah2y7nyaq0f8gzgg3c9iwp81y2zx3xd-mcwm-20130209-2/bin’: No such file or directory

<lfam>calher: Did you have to make your own install phase or is that upstream's?

<Jookia>you have to mkdir $out/bin

<lfam>If the former, then I'd use (install-file). If the latter, I'd use (mkdir-p)

<calher>lfam: Haven't touched the Makefile.

<lfam>Then you'll need to make a phase before the install phase and use (mkdir-p)

<Jookia>mcwm's makefile might need patching if it's broken

<lfam>Perhaps. If this is the only change then I think it's clearer to not make a patch.

<lfam>Patches are barely human readable and they're not in the package definition

<Jookia>This is true, but it's also good to get upstream fixed too

<lfam>But if many changes must be made, a patch is the way to go.

<lfam>True, you can send the patch upstream

<lfam>There's no bug report like a bug report with a patch

<calher>what kind of patch? makefiles always install things into the wrong file if it's guix or nix

<calher>*dir

<calher>*wrong dir

<lfam>Does this kind of error message make sense to anybody? It's from a Python program test suite: http://paste.lisp.org/+6L1W

<Jookia>Installers should use --prefix to determine where to install things

<calher>Why is everythingjfdjflkdsjfs fso hard

<Jookia> https://github.com/tkln/mcwm/blob/master/Makefile It appears the Makefile does the same thing, it just doesn't make the directories it needs in prefix

<lfam>Heh, I feel the same way sometimes calher :)

<calher>Jookia: Last time I looked at the Makefile, it just put the bin in $(PREFIX)/bin

<calher>What's the problem...

<Jookia>$(PREFIX)/bin doesn't exist on guix

<lfam>I guess it never makes the bin directory

<Jookia>it needs to be made

<Jookia>It needs to make $(PREFIX)/bin and $(PREFIX)/man/man1

<calher>Jookia: Well *duh*, but you'd figure Guix would have an automated way around this obvious piece of Hell.

<lfam>I guess they are expecting you to *always* have /usr/bin/ or something like that

<Jookia>calher: Guix can't fix broken makefiles ;)

<calher>If it strays from the normal file hierarchy, it should always know how to read these Makefiles and reinterpret them in a way that fits.

<lfam>calher: To be fair to Guix, most _good_ Makefiles don't fail in this way

<lfam>In fact, this is the first Makefile I've seen that has this error

<calher>Jookia: It's not broken. The Makefile does what it needs to.

<lfam>No, the Makefile is definitely broken

<Jookia>The makefile tries to install something to a directory that might not exist- often when I buld things I set PREFIX to "$PWD/install"

<Jookia>This would fail in that case too

<calher>But the Makefile tells it where it's supposed to go. Now, it *is* broken on Trisquel: it assumes man page and binary dirs share a common parent dir, which is not the case.

<lfam>In my opinion, any Unix shell script-y type thing should *always* `mkdir -p` before trying to put something in a directory. That's a standard practice.

<lfam>Not doing that is just lazy and begging to fail

<Jookia>Makefiles aren't declarative and we can't 'reinterpret' them without creating more subtle bugs

<lfam>We have at least hundreds of Makefiles in Guix that don't fail in this way :)

<Jookia>In this case, this is evidence that the person hasn't tested the 'install' command outside existing directories- perhaps the soruce code reflects this too

<calher> http://hack.org/mc/contact.txt

<Jookia>calher: Coolie petrolie

<calher>Huh?

<Jookia>You could send them a bug report :D

<calher>"Hi. Um, MCWM's Makefile puts stuff in directories that don't exist."

<Jookia>Wrong

<Jookia>It *doesn't* do that

<calher>"Hi. Um, MCWM's Makefile tries to put stuff in directories that don't exist and fails."

<Jookia>In the install phase

<calher>"Hi. Um, MCWM's Makefile's install phase tries to put stuff in directories that don't exist and then fails."

<Jookia>Great, send that off

<lfam>It might help to provide an example of *how* it fails along with a patch to fix it. It's a lot more likely to get fixed that way.

<Jookia>Yeah

<Jookia>Or why it's important to fix it and how to reproduce- in this case 'make install PREFIX=$PWD/install'

<calher>lfam: IDK how to fix it. I'm barely learning how to package stuff in a package manager nobody uses.

<calher>*package manager and filesystem hierarchy

<lfam>Heh, fair enough. In that case, I'd add a phase before the install phase that makes the directory. Then, I'd send the bug report without the patch. I think they'll know how to fix it. The other option is to ask the mailing list for help.

<lfam>I mean our mailing list

<calher>lfam: Sent: <http://hastebin.com/raw/udiyahopon>.

<Jookia>Now you sit back and wait a few days, or weeks :)

<Jookia>I hope that didn't corrupt any logs

<Jookia>If gnunet_bot assumes BMP=Unicode then I'll flip my lid

<calher>gnunet_bot: Where is thy creator?

<calher>Where is their author?

<Jookia>You could probably find it online

<Jookia>Or in #gnunet

<calher>Jookia: Done: <https://gnunet.org/bot/log/gnunet/2016-02-14#T915171>.

<calher>It would be funny if someone would make gnunet_bot ragequit if it detects emoji, then crashes.

<calher>lfam: If a simple app like MCWM can't be built, then I doubt Mumble will ever get built; the Mumble team is not very responsive at all and is mostly Windows-focused.

<calher>(Mumble is very complex, buggy and hard-to-build on even normal systems, let alone GuixSD.)

<lfam>calher: The issue with MCWM is not a big deal, that's why I suggested you mention it on guix-devel. Somebody will be able to patch it quickly.

<lfam>I don't have any experience with Mumble one way or the other.

<lfam>But we have packaged some very complex stuff before. It's possible if the motivation is there.

<Jookia>NixOS has Mumble packaged so it's probably not a big deal

<Jookia>calher: If you have time you should try learning a few programming languages, it can help with doing work like this

<lfam>Gosh darn it, why would your test suite not print any errors when it fails?!

<Jookia>lfam: Tests are for developers maybe? :P

<lfam>Or maybe they never run it

<lfam>Packagers running tests on unfamiliar systems are a really important part of finding bugs IMO.

<Jookia>This is true

<lfam>Consider that gnupg recently had a broken release that was found by people on *other* systems

<lfam>The tests are really worthless if they only get run by upstream

<Jookia>This is also true

<lfam>Oh, I found the backtrace a thousand lines up :o

<calher>Does gnunet_bot hate all unicode?

<lfam>Please don't try to crash the bot anymore. A lot of people use the logs it collects.

<calher>lfam: May I test my own instance locally?

<lfam>Of course! Just not in a channel that others use

<davexunit>some discussion about functional package management on HN, started by me: https://news.ycombinator.com/item?id=11096572

<davexunit>notably, one of the Spack developers chimes in

<davexunit>good amount of dislike for functional package management

<davexunit>"I dislike the whole 'functional' package manager idea as it just punts the work onto people to add explicit deps when most of the dependency information is within the code itself."

<xd1le>davexunit: i was debating whether to let you know about that "so you want to write a pm" article

<xd1le>as soon as i started reading it, and realised that it doesn't mention guix nor nix, i had to stop and ask him and this what happened: https://twitter.com/xd1le/status/698630788397424640

<xd1le>(if you're interested)

<davexunit>xd1le: the author responded to my comments on the HN thread

<davexunit>he's kind of a jerk.

<xd1le>ooh, link?

<xd1le>actually

<xd1le>i'll just look for it

<davexunit> https://news.ycombinator.com/item?id=11088125

<davexunit>"sdboyer" is the username

<xd1le>ah

<xd1le>top comment

<xd1le>when i saw the hn thread

<xd1le>there was like one comment mentioning nix

<xd1le>which was about it

<davexunit>his article goes on about PDMs, "project development managers"

<xd1le>yeah i see

<davexunit>which, from I gathered, downloads and bundles source code

<davexunit>which is bananas.

<davexunit>but he dismisses functional package management.

<xd1le>i mean, he hasn't even *used* nix nor guix

<xd1le>yes it is

<davexunit>also, the Spack author doesn't seem to really get Nix or Guix.

<xd1le>spack author?

<xd1le>(i haven't read the article btw, obviously)

<xd1le>like the full article

<davexunit>I don't know if its *the* author, but it seems to be someone involved in the Spack development.

<xd1le>what is spack?

<davexunit>I didn't read the full article because it is very long

<davexunit>another package manager.

<xd1le>ah, excellent

<davexunit>claims to be a middle ground between language package managers and functional package managers

<xd1le>and the obvious question.... but why?

<davexunit>civodul and rekado (I think) put out a paper awhile back that has a section about Spack

<xd1le>why the need for that when you can just use fpm's

<xd1le>ah, does it predate when nix became relatively popular/known?

<yvm>Trying to install GuixSD with 'desktop' I got test_format_newc FAIL when testing libarchive-3.1.2. Also message "If tests fail or crash, details will be in: /tmp/nix-build-libarchive..." lied: there is no such directory.

<yvm>So. Any quick workaround?

<davexunit>xd1le: I don't know exactly. I should probably educate myself more about it.

<davexunit>others are more familiar with it.

<davexunit>yvm: that output is probably from the software's build system that has no idea its being run in a temporary chroot

<davexunit>yvm: to keep the failed build around in /tmp after a failure, use the --keep-failed flag.

<davexunit>yvm: but besides that, I think you have a bigger problem.

<xd1le>davexunit: nws. i wonder why he/she wouldn't understand Nix or Guix though.

<davexunit>if you're using our installer you shouldn't have to build anything from source, provided that you run 'guix pull' first.

<davexunit>so run 'guix pull' and then retry the system installation

<davexunit>you should notice that it downloads pre-built binaries of nearly everything.

<davexunit>it's 3AM here. time to sleep. good luck.

<yvm>Got it. Thanks.

<Jookia>why have a functional package manager now if we can wait for tools that'll analyze our code that don't exist yet? ;)

<Jookia>Foolproof tools that understand human intentions, just like speech recognition

<xd1le>Jookia: i.e. write a functional package manager in idris ;)

<Jookia>Eek, dependent typing

<Jookia>Types gone too far

<Jookia>I'd love to see a package manager that can deduce what packages I need down to the bugfix version

<xd1le>Jookia: i.e. dependent typing!

<xd1le>(although it was just a joke though)

<xd1le>what's wrong with dependent types though?

<xd1le>uh, i guess this isn't the place to talk about that though

<Jookia>I don't think dependent types would solve that unless you actually had proof of the program's inner workings itself. Static typing is useful but I think it shouldn't really be used to run code

<xd1le>yes i don't think using idris has much benefits for the users

<xd1le>don't get what you mean by run code though

<Jookia>dependent types are basically their own language that you program in to enforce constraints

<xd1le>that's not running code though

<Jookia>The compiler is running the code

<xd1le>as in, the program doesn't run the type annotations

<xd1le>which is what i mean

<xd1le>i think you mean something different, but i'm not sure

<xd1le>but it doesn't matter :)

<xd1le>we're both in agreement about it's usefulness here, i was just joking originally :)

<Jookia>icy

<xd1le>icy?

<Jookia>i see

<xd1le>ah, yes, i believe the compiler trys to make the final program all efficient and remove all that type stuff

<xd1le>as in, talking about the idris compiler

<Jookia>Not sure it's worth it

<Jookia>At least, not for the programs I write

<xd1le>well, it's still pre 1.0

<xd1le>

<Jookia>As for the language Idris itself it doesn't share my type of programming ;) Laziness is a big thing to me

<xd1le>but i think its usefulness grows for larger programs

<xd1le>idris has laziness as an option, but i forgot how it works/how to use it

<xd1le>i'm very much still an idris newbie

<xd1le>probably be like that for a while too

<Jookia>it's opt-in which makes it kinda useless if the entire community isn't using it

<jubalh>hello

<jubalh>is rekado's fosdem talk already available somewhere?

<xd1le>yes

<xd1le>although

<xd1le>i'm not sure if it's the full takl

<jubalh>hmm

<jubalh>full one would be nice ;)

<jubalh>it has been two guix talks on fosdem right?

<xd1le> http://ftp.fau.de/fosdem/2016/k3201/a-gentle-introduction-to-functional-package-management-with-gnu-guix.mp4

<jubalh>thanks

<xd1le> https://video.fosdem.org/2016/k3201/ for a few more guix/guile

<xd1le>talks

<xd1le>unfortunately, if you look at lost_talks.txt, you'll see there's a another guix talk there (that was lost)

<xd1le>i.e. not recorded, accidently

<a_e>There was another talk by Ludovic in the distribution room.

<a_e>And one by Ricardo in the HPC room.

<xd1le>ah yes http://mirror.onet.pl/pub/mirrors/video.fosdem.org/2016/k4201/reproducible-and-customizable-deployments-with-gnu-guix.mp4

<xd1le>a_e: ooh nice. what was ricardo's other talk on?

<a_e> https://fosdem.org/2016/schedule/event/hpc_bigdata_gnu_guix/

<a_e>It was a lightning talk of 5 minutes.

<xd1le>thanks!

<a_e>The room was packed, and I could not enter.

<xd1le>uh

<jubalh>i'll have a spare laptop soon and theen install guixsd on it :)

<jubalh>looking forward to ti

<a_e>Which I think was a good thing - so many people learning about Guix, while I already know about it.

<a_e>I am trying on a spare laptop that has 10 years right now.

<jubalh>is lxqt avaiilable on guix already?

<a_e>It is not fun when it needs to compile things :-)

<jubalh>hehe

<a_e>jubalh: Not yet. I packaged a few of the packages, but not all.

<a_e>It needs to be updated also.

<a_e>If you want to get into packaging, this would be a good start:

<jubalh>a_e: interesting. i would join you once i have a guixsd setup. i right now only have it in a qemu vm

<a_e>update the packages that are already there;

<a_e>add the missing ones.

<jubalh>fine

<a_e>As far as I remember, they were rather easy to package.

<jubalh>my problem right now is that i dont know guile yet hehehe

<jubalh>yeah i package lxqt for an rpm based distro

<a_e>There is no real need to _know_ Guile, just a few notions will be enough.

<a_e>Great, so you are the right person here!

<jubalh>what do you think i should know so i can package software? is there an overview somewhere?

<xd1le>also guile is pretty easy to get the basics of

<xd1le>if you need/want to

<xd1le>that's a good question

<a_e>I am only starting with GuixSD. So all I can say is that the packages compile and pass their test suite. The final test comes when using it in GuixSD.

<xd1le>the docs do go through it a bit

<a_e>There is a talk here:

<a_e> https://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf

<jubalh>thanks

<jubalh>oh seems like i was looking for exactly

<jubalh>cool :-)

<a_e>It is a bit old, but still quite up to date.

<a_e>Only the alist-delete line should be replaced by the newer modify-phases syntax.

<a_e>In the beginning, it explains a few things about scheme.

<jubalh>nice

<jubalh>i'll read it

<jubalh>i set up my guix vm a month ago. but havent done much yet, it was only the initial playing around.

<jubalh>but now would like to to more from time to time

<jubalh>and since its weekend .. ;)

<a_e>I am still using Guix as a package manager on top of Debian. It works quite well also, and provides a gentle path towards more and more Guix.

<jubalh>which is the right way to update the list of available packages again? guix pull is for reallyupdating the packages right? so not what i am looking for

<jubalh>nice

<a_e>No, guix pull just updates the scheme code, that is, also the package definitions.

<jubalh>a_e: did you setup a clean debian and then used guix for every package you installed beyond the basic set of packages?

<a_e>To upgrade in your profile, you then use "guix package -u ...".

<jubalh>and the 'guix package -A' is always up to date?

<a_e>No. I had a full Debian, then I installed Guix, and replaced more and more packages.

<jubalh>i see

<a_e>I am still using X and KDE from Debian.

<jubalh>okay

<jubalh>so a 'grep package -A | grep lx' shows me that 4 lxqt packages are there so far

<a_e>Not a whole lot :-)

<jubalh>a_e: is Enge a french name?

<a_e>No, German. Guix is an international project :-)

<jubalh>I guessed its german. I just wondered because on the slide it sais you held that talk in Paris :)

<a_e>Testing the resistance of GuixSD. The laptop on which I tried "guix system init" just broke down; a ten year old battery is not very resistant...

<a_e>Yes, that was tat he GNU Hacker Meeting.

<a_e>Apart from that, I live in Bordeaux.

<jubalh>I see

<jubalh>a_e: in your slides it sais: Add module to

<jubalh>gnu-system.am

<jubalh>i dont find this file

<efraim>its in the base of git

<a_e>To develop, you should use a git checkout. It is at the top level.

<jubalh>a git checkout? you mean a git version of guix?

<a_e>Yes. In that way, you will also be able to send in patches that can be applied to the development version.

<jubalh>so i shall clone guix from git and build it from there instead of using the one i got via my package manager?

<iyzsong>guix itself and all packages definitions are in one repo

<a_e>Yes, I would do so.

<a_e>The sources from your package manager are immutable, no?

<jubalh>during ./bootstrap i get: possibly undefined macro: GUILE_MODULE_AVAILABLE

<a_e>You may need a few extra packages; on Debian, something like guile-dev in addition to guile for the header files, and so on.

<jubalh>:) thanks

<jubalh>i hope now it wont get confsued with my already running guix daemon which i got via package manager

<efraim>the guix daemon rarely changes

<jubalh>so i did the ./configure the ./make check. now i suppose i will have to do the make install. how to make sure it doesnt get problems with the guix i installed via my package manager?

<jubalh>do i have to specify a path where it should install it? and use another guix profile?

<jubalh>sorry for those newbie questions :-)

<efraim>if you've already installed guix then you can skip make install and just run from the git checkout

<efraim>I use `./pre-inst-env guix foo`, but another option is to symlink .config/guix/latest to the git checkout and not run guix pull anymore

<jubalh>so what this will do is still use the guix binary from my package manager but use the packages from git?

<efraim>./pre-inst-env guix uses git, guix uses the binary

<jubalh>so after make check a make install needed but no make install, is that correct?

<efraim>right, you don't need to run make install

<jubalh>i didnt even run 'make' yet. maybe it was done by ./configure already? ./pre-inst-env guix package -A already works

<efraim>I don't think ./configure runs make

<efraim>./pre-inst-env works without running make

<jubalh>aha! now I can just edit the gnu/packages/lxqt.scm and add some more lxqt apps, run guix package -i lxqt and if it works i can send a patch to the ML?

<efraim>yup :)

<jubalh>efraim: please explain pre-inst-env for me more. i dont get how it works. is it using the system binary then? i didnt run make yet so i suppose it has to if configure doesnt run make

<efraim>I don't know the "magic" behind it, but it runs guix using the git repository for the package definitions

<jubalh>hmm

<efraim>when I don't run make I get terminal spam about it loading all the newer definitions before completing the command

<jubalh>ok

<jubalh>a_e: what is the purpose of adding the package one develops to gnu-system.am ?

<efraim>if its a new package file (or patch) then it tells guix to pick it up also when looks at the package definitions

<jubalh>hmm

<jubalh>well my git build doesnt seem to work: http://susepaste.org/view/simple/38435849

<efraim>rerun configure with --localstatedir=/var

<jubalh>what does it change?

<efraim>instead of looking in /usr/local/var/guix/daemon-socket/socket it'll look in /var/guix/daemon-socket/socket

<wingo><wishlist>a guix package for gitlab</wishlist>

<jubalh>efraim: thanks :)

<efraim>np :)

<jubalh>so i just changed the version so far for libqtxdg and wanted to run the download command to get the sources so i can find out the hash. but this happens: http://susepaste.org/view/simple/4187335

<jubalh>i dont see why

<jubalh>also its the right one: https://downloads.lxqt.org/libqtxdg/1.3.0/

<efraim>guix download takes a url as the argument

<efraim>you want guix build

<efraim>then it'll spit out the error about the hash mismatch

<efraim>oh, if it's a https url then you should change it in the package also

<jubalh>okay

<jubalh>ouch, seems its compiling gcc first

<jubalh>this iwll take a while :-)

<efraim>do you have substitutes enabled?

<jubalh>efraim: how to check this?

<efraim>sorry, gotta go afk for a while

<jubalh>ok

<rekado>jubalh: the introductory talk wasn't captured. The video only contains the Q&A session.

<rekado>the talk in the HPC devroom was only 5 mins and has a focus on reproducibility

<rekado>it's not suitable as a general introduction to guix.

<xd1le>ahh, that's unfortunate

<jubalh>indeed

<jubalh>what can i do against that: http://susepaste.org/view/raw/37927297

<jubalh>it would be helpful if one would know _where_ it tries to create a directory

<rekado>jubalh: authorisation tries to write to /etc/guix/acl AFAIC

<rekado>it stores the public key there.

<rekado>so it would need to be run as root

<jubalh>ok :)

<jubalh>now it will automatically use substitutes?

<jubalh>rekado: http://susepaste.org/view/simple/56116716

<jubalh>it still doesnt seem to want to take substitutes

<alezost>jubalh: does /etc/guix/acl exist?

<jubalh>/etc/guix does not exist

<jubalh>hmm i now used guix archive without the pre-inst-env and now it does

<jubalh>but it seems that still all the packages would be build from source: http://susepaste.org/view/simple/76249762

<jubalh>does someone know why?

<jubalh>oh sorry

<jubalh>i misread the output

<rekado>jubalh: the output says that postgres, qt, and libqtxdg will be built from source.

<rekado>maybe there are no substitutes available for the particular variants you want?

<alezost>postgres was updated several hours ago, so there are no substitutes for it yet

<efraim>yeah, sorry, that was me with postgresql and the CVEs

<efraim>normally ~50 isn't bad, but it hit both qt and qt-4

<jubalh> https://nopaste.me/view/raw/add0a3b1 hmm whats this about?

<rekado>jubalh: this means that you don't have the gnutls bindings for Guile installed.

<rekado>this also happens when http is redirected to https.

<jubalh>i dont see a package for that. maybe its in libgnutls-devel?

<rekado>I don't know.

<rekado>are you using Guix on Debian?

<jubalh>no on openSUSE

<efraim>boo, iceweasel CVE in the bundled graphite

<jubalh>rekado: do you know the debian package name?

<rekado>jubalh: no, sorry.

<rekado>you could install it with Guix...

<jubalh>it would be?

<rekado>how did you install Guix on openSUSE? did you use the binary installation?

<rekado>or did you install from git?

<jubalh>rekado: i tried it via the package manager, then people here told me i shall install it via git so i can update the lxqt packages. i did only a make and use ./pre-inst-env guix now. people told me like that it will use the git version

<mark_weaver>efraim: thanks for taking care of the postgresql update!

<mark_weaver>efraim: I already patched the bundled graphite in iceweasel. in fact, right now that's the only graphite fix in 'master'.

<mark_weaver>efraim: the fix for our main graphite package is in 'security-updates', and hopefully will be ready to merge later today.

<efraim>mark_weaver: glad to hear it

<mark_weaver>I haven't checked qt

<jubalh>rekado: but also in guix i dont see the package

<mark_weaver>jubalh: the problem is that our 'libqtxdg' package refers to an 'http' URL, so gnutls is not included as an input to the derivation that downloads it. however, at some point since we last updated that package, they started redirecting 'http' to 'https'.

<mark_weaver>jubalh: the fix is to change 'http' to 'https' in the code. I'll do that.

<jubalh>mark_weaver: so in the packge urls from http to https you so? okay :)

<jubalh>mark_weaver: let me do it i am trying to getting into packaging for guix :-) and i intended to update the lxqt package anyways

<mark_weaver>jubalh: do you have Guix built from a source checkout of our git repo?

<mark_weaver>I've already pushed this update, sorry.

<mark_weaver>but I'll let you update to newer versions :)

<jubalh>mark_weaver: yes i have it from source

<jubalh>i see, okay

<mark_weaver>jubalh: in order to make changes like that (and to contribute to us), the first step is to build guix from git.

<jubalh>i did

<mark_weaver>and to make sure it works by building something from the built git checkout, by running "./pre-inst-env guix build ..."

<mark_weaver>great!

<mark_weaver>happy hacking, then :)

<jubalh>yes thats what i try to do with lixqtxdg currently :)

<mark_weaver>:)

<jubalh>can you explain to me what the pre-inst-env is doing exactly? i am using it but not sure what it actually does

<mark_weaver>jubalh: it sets several environment variables before running the following command, which configures guix to use all of the code within that directory.

<mark_weaver>whereas normally it would use the code within $HOME/.config/guix/latest which is a symlink created by "guix pull"

<mark_weaver>since I *always* want to run the guix from my git checkout, I make both ~root/.config/guix/latest and ~mhw/.config/guix/latest symlinks to my built git checkout, and I never run "guix pull".

<mark_weaver>pre-inst-env is just a shell script, btw, with lots of comments, so you can read the code.

<jubalh>its compiling qt now, so it will take some time. then i will try to update lxqt and send a patch :)

<jubalh>since i switched away from Gentoo i totally forgot how long it can take to compile a big package..

<mark_weaver>jubalh: qt is practically an OS by itself, with all of its bundled libraries and programs. it takes quite a long time to build.

<Jookia>One thing Qt likes to involve is WebKit

<mark_weaver>it bundles chromium!

<Jookia>That too? Amazing

<Jookia>Have a web browser in everything, even your text editor

<Jookia>mark_weaver: I've dug a bit more in to that gdk-pixbuf test issue and found that it only happens when you have JPEG support enabled.

<mark_weaver>well, we should certainly keep JPEG support

<mark_weaver>hmm, I might be remembering wrong about chromium being in qt. I don't see it in qt-5.5.1 anyway. maybe it was bundled in an earlier version.

<Jookia>WebKit is definitely there which takes way too long to build. We should definitely keep JPEG support, but it's bringing me closer to finding out why it's broken in particular- this happens in the newest gdk-pixbuf version

<mark_weaver>Jookia: what is broken? the only issue I remember is that one of the tests required a lot of memory.

<Jookia>mark_weaver: The test requires lots of memory which can lock the machine up at worst or cause the build to fail at best

<mark_weaver>hydra has been building it successfully

<Jookia>On machines with 2G of RAM, that is

<mark_weaver>tell me about the machine on which it fails for you. how much RAM does it have? how much swap?

<Jookia>T400, 2G RAM, 8G swap

<mark_weaver>both of the mips64el-linux build slaves have 2G of RAM (and 2G of swap), and they've not had a problem building it.

<Jookia>Interesting

<Jookia>This is running from a live USB

<mark_weaver>I also build Guix from source code on my Lemote Yeeloong with only 1G of RAM.

<Jookia>Though the TMPDIR is on a HDD

<mark_weaver>Jookia: it probably has something to do with that.

<Jookia>Hmm

<Jookia>I know! I'll try building it on my eeepc

<Jookia>This can only go well

<mark_weaver>haha

<Jookia>My eeepc that crashes if I have too many firefox tabs open. I looked in to getting more RAM for the T400 and found it'd cost $90 to get that stuff where I live

<Jookia>90% sure if my eeepc had a swap it wouldn't crash

<mark_weaver>Jookia: when using the live USB, did you start the cow-store service?

<Jookia>mark_weaver: This isn't the Guix live USB, it's a Debian live USB

<mark_weaver>Jookia: out of curiosity, why build Guix from a live USB and not from a system installed normally on the HDD?

<mark_weaver>what device was /gnu/store located on?

<Jookia>Well, I'm doing that from my Novena at the moment. ;) But in actuality it's because it's the same way I installed NixOS and I run Libreboot so dual booting would be confusing

<Jookia>/gnu/store is on the HDD- all persistent data is on the HDD since I have to reboot the machine often. It's --bind mounted from /mnt/scratch/gnu

<mark_weaver>well, this is just a guess, but iiuc live systems tend to have a lot of stuff in ramdisks, and that may be dramatically reducing the amount of available memory for compiling stuff

<Jookia>That's absolutely possible

<Jookia>I may have to come back to the bug after I get a working install then

<mark_weaver>Jookia: ah, I see now. qt-5.5.1 *does* bundle chromium, but we remove it in a snippet, so I didn't see it in the result of "guix build -S qt"

<Jookia>Wow, I haven't gotten to 5.5 yet I don't think

<Jookia>That's terrible

<mark_weaver>and of course chromium also bundles a lot of stuff. it's bundles within bundles.

<mark_weaver>really nasty

<Jookia>Google has the habit of bundling modified third party code and not putting it upstream

<Jookia>So you probably have like 5 versions of zlib on your system, only some updated properly

<mark_weaver>I try to keep up on security updates, but I've explicitly posted that someone else will need to take charge of keeping Qt's bundled libraries patched up. as for me, I've purged my system of anything that uses Qt.

<Jookia>Heh, good idea

<mark_weaver>my avoidance of Qt is not a principled stand, but rather a practical one. last I knew, no one has been keeping an eye on making sure security updates are applied to Qt's many bundled libraries, and I don't want to do it myself.

<mark_weaver> https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00302.html

<mark_weaver> https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00018.html

<Jookia>ouch

<Jookia>How's GTK on that front?

<mark_weaver>The GTK/GNOME world doesn't tend to bundle things. vastly saner.

<Jookia>I've also noticed GTK builds faster

<jubalh>interesting to learn about this

<jubalh>i like lxqt though. now its sad to learn about this

<Jookia>Is there such thing as a modular Qt

<mark_weaver>I don't know

<mark_weaver>if it's possible, the debian and fedora folks would do it, so maybe look at what they do.

<mark_weaver>fedora in particular historically takes a strong stand against bundled stuff.

<mark_weaver>and debian too, but maybe not as strongly.

<jubalh>./pre-inst-env guix build libqtxdg <- where will this library be now?

<calher>are there any graphical ssh clients in guix that are decent

<mark_weaver>jubalh: after building (if needed), it will print out the directory name(s) in /gnu/store produced by the build.

<jubalh>ok

<jubalh>now lets try building lxqt-comon ;) in the new version

<jubalh>hmm an issue: http://susepaste.org/view/simple/74524593

<a_e>jubalh: Permission to write into the store denied?

<a_e>Strange. Did you create all the build users and so on as explained in the docs?

<mark_weaver>jubalh, a_e: the problem is that one package's build system is trying to write into a different package's output.

<a_e>Oh, that is new in this package set.

<mark_weaver>iirc, jubalh is trying to update the lxqt packages.

<efraim>it seems python-2 bundles zlib

<a_e>mark_weaver: Yes, so it is surprising that the newer versions of the packages write into each other's directory, while the previous ones did not.

<a_e>efraim: Too many bundles, and bundles of bundles!

<efraim>yeah :(

<davexunit>software is terrible.

<paroneayea>davexunit: only a few small packages left

<paroneayea>for the python mediagoblin deps

<davexunit>paroneayea: that's great to hear!

<paroneayea>I might not have time to do the stuff I was hoping for the guile potluck

<paroneayea>but

<paroneayea>I think it's more worth my time to do this this weekend

<paroneayea>it needs to happen!

<davexunit>:)

<davexunit>ACTION has no potluck dish

<a_e>davexunit: Hardware is frightening.

<paroneayea>oh

<paroneayea>I *should* promote the potluck, at least

<jubalh>mark_weaver: hmm how does this happen and what to do against it?

<a_e>This is tricky and depends on the package. Maybe it would be enough to install the files into the corresponding directory of the package itself and not of its neighbouring package.

<a_e>Sometimes an environment variable could be enough. Sometimes one needs to rewrite the installation phase.

<a_e>Maybe we will even need a search path specification, so that the files that are expected to all end up in one location and that are now spread over several packages are well taken into account.

<a_e>Is there a way of browsing the maintenance-guix and guix-artwork git repositories via the web?

<a_e>Only the main repository is referenced on savannah; I tried a few obvious things to reach the others, but without success.

<paroneayea>what

<paroneayea>whaaaaaaaaaaaat

<paroneayea>davexunit: around?

<paroneayea>python's packaging system is doing something really... strange

<paroneayea>I noticed it's pulling down the same tarball I am

<paroneayea>but... but!

<paroneayea>it patches the syntax on py3.4 to be proper py3.4 syntax!

<paroneayea>yeah, holy shit

<paroneayea>davexunit: setup.py -q bdist_egg somehow *modifies the source* to make it py3.4 compatible

<lfam>Wow, we should use that tool to transform all upstream code into Guile! ;)

<paroneayea>lfam: ha :)

<lfam>mark_weaver: I asked about security policy and on #qt, and they pointed me at <https://wiki.qt.io/Qt_project_security_policy>. They publicly disclose issues on qt-announce, and have a private security-announce list for people like us. Think I should ask on guix-devel if anyone wants to try to get on that list?

<a_e>lfam: Good work, and interesting result!

<a_e>The page states explicitly that Qt-4 is not supported any more. One more reason to get rid of it!

<lfam>a_e: It was a very small amount of work :) I was disturbed by the discussion of this topic

<a_e>Sending an e-mail is a good idea.

<lfam>Okay, I will compose it

<a_e>Yzsong could be a good candidate, he seems to be our qt expert. And you as one of our security experts :-)

<paroneayea>whoa

<paroneayea>whoaaa okay

<paroneayea>so I figured it out

<lfam>I am no expert! Thankfully many upstreams make security updates easy by issuing simple patches.

<paroneayea>if sys.version_info >= (3, 0):

<paroneayea> extra.update(use_2to3=True)

<paroneayea>right inside the setup.py

<paroneayea>so it uses 2to3

<lfam>paroneayea: I guess it must be a pretty simple program if it can be auto-translated like that, right? Otherwise, why wouldn't all Python programs use such a tool?

<dannym>Hi lfam :-)

<lfam>Hi!

<paroneayea>lfam: it is fairly simple, yeah

<paroneayea>lfam: and 2to3 is not perfect

<dannym>Many Python programs do use 2to3 but its limited in the usual sense (i.e. it can't tell in general what a program does without running it).

<paroneayea>but is pretty good

<dannym>So what it does is 1) syntactical fixups and 2) pattern matching for fixing up imports etc

<dannym>But it's nice that it exists at all - really turns down the heat in migrating to 3. Many programs work just fine "auto-"migrating them like that

<CompanionCube>ACTION wonders just how useful 'guix system' would be without GRUB

<dannym>(but we had problem with 2to3 regarding openssl migration before - they did some kind of huge reshuffling in the openssl socket support and that's really too much to autofix)

<dannym>they=Python stdlib

<efraim>i'm working on python-2 and I'm having a hard time rewriting my snippet https://pastee.org/mcvwb

<efraim>I know I should be able to use pattern matching to shorten it, but I keep on getting it wrong

<davexunit>paroneayea: ...interesting!

<paroneayea>davexunit: interesting / disturbing? ;)

<paroneayea>anyway, someone in #pypa seems to think this is fairly on-kosher for python packages so maybe that's a little bit reassuring

<davexunit>if it doesn't fuck anything up for us, it seems okay enough..

<lfam>a_e: sent! And not proofread, so there a quite a few typos :/

<efraim>python-2.7.11 built with tests enabled!

<lfam>Yay!

<dannym>hmmm... in guix git I get: gnu/packages/scheme.scm:493:0: In procedure module-lookup: Unbound variable: broken-tarball-fetch

<lfam>dannym: What command results in that?

<dannym>lfam: guix environment guix, then make; details at https://pastee.org/8mk4v

<dannym>Next, I'm trying to remove all the .go files since it seems to be intermittent

<dannym>yeah, after deleting the .go files it works

<dannym>(and after calling "make" again)

<dannym>touching gnu/package/engineering.scm, it breaks

<dannym>Did I git checkout gnu/packages/engineering.scm just to make sure, called make again, still broken

<lfam>dannym: Try ./pre-inst-env guix environment guix. Most likely there is an ABI mismatch between your system Guix and the Guix from your Git checkout.

<lfam>Well, that's my guess anyways

<dannym>Ctrl-C doesn't work, but after it's down with this round, I'll try it

<lfam>That's my bet since I have no trouble building current master:HEAD, which a recently pulled system Guix.

<lfam>s/which/with

<lfam>Are you on GuixSD? I noticed being unable to send SIGINT there, too.

<dannym>lfam: yeah, I'm on GuixSD.

<lfam>What on earth could be causing that?!

<efraim>guix environment guix doesn't accept Ctrl-C

<efraim>I think it falls under known bug

<lfam>It accepts it on my Debian system

<dannym>lfam: tried "make" using ./pre-inst-env guix environment guix, make, touch gnu/packages/engineering.scm, make -> it breaks

<lfam>dannym: What git commit?

<dannym>lfam: git log says b042bdc8fdc2a89e51da852339c0ee86b7bedaf1

<lfam>I don't have that commit. Is this a private branch?

<lfam>NVM, typo

<dannym>(just to make sure: url = git://git.sv.gnu.org/guix.git

<dannym>[branch "master"]

<dannym>)

<cbaines>lfam, do you still have questions about the removal of (guix build utils) from /gnu/packages/version-control.scm ?

<lfam>If we both have that commit then everything else is the same

<lfam>cbaines: I was waiting for somebody who knows more about Scheme to weigh in. I really can't make an informed judgment about it.

<dannym>lfam: (it updated lots of translations, so git diff flags them (the po/.../*.po). Other than that, no changes)

<cbaines>lfam, Ok :)

<lfam>cbaines: My opinion is that people have to advocate for their patches. So, by asking here, you're doing a good job :) But you might have to ask on the mailing list again if there is no attention.

<lfam>dannym: If you look in `git log -p` for 'broken-tarball' you will see that it's an interesting case. I wonder if something changed in the last update to scheme.scm that broke it.

<lfam>I reproduced the problem.

<cbaines>I've just updated one of the patches based on feedback given, so I'll give people a bit of time to look at that

<rekado>finally did my part for ilovefs-day. I think I'm finally settling for a rhythm of writing a single blog post per year.

<a_e>This is indeed very regular.

<fhmgufs>I'm really keen on having the same environment as on GuixSD on top of a foreign distro.

<rekado>I hope I can keep up at this speed.

<lfam>dannym: Can you send a report to bug-guix about that issue? I reproduced it but I don't have time keep working on it now.

<NiAsterisk>access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) which application provides ld.so.preload?

<rekado>NiAsterisk: this is not a real error.

<NiAsterisk>okay

<rekado>it's for systems that use a global library cache for dynamic linking.

<rekado>(or something like that)

<rekado>we usually use the RUNPATH feature to hard-code the full paths to store items, so we have no use for this.

<NiAsterisk>I'm just trying to get into strace.. all I can see is that the point where SYSATOMS is being opened, SYSATOMS has no full path..

<NiAsterisk>all other paths point to store

<rekado>correct

<rekado>I haven't yet looked at the code, but it seems to be related to the value "o__1"

<rekado>i__1 = f_open(&o__1);

<rekado>this all looks a bit too cryptic for my tastes and I don't have time to investigate this right now.

<rekado>but there probably is a way to prepend the full store path by patching the sources.

<NiAsterisk>so what I suppose I need to do, is look at the C code, and ask the author what's meant with "don't mess with the generated C code", if there's a way around that

<NiAsterisk>*suppose/guess

<davexunit>rekado: your nice article is at the #1 spot on HN! :)

<davexunit> http://elephly.net/posts/2016-02-14-ilovefs-emacs.html

<rekado>hehe

<NiAsterisk>that might take some time, if this is the way I need to go, I have some studying in crypto and other math to do for a job I might maybe get an interview for if networking goes well

<rekado>surprise!

<rekado>NiAsterisk: oh, that's *generated* C code...?

<NiAsterisk>sort of

<NiAsterisk>fortran to C with some fixes i guess

<NiAsterisk>it sucks that it's so bad in guix, but that's also good, because I can learn much

<rekado>nah, I don't think that's a guix issue, really.

<lfam>NiAsterisk: Can you compare with strace against the working version you have?

<rekado>it just seems to assume that you run the binary from the same directory as that file.

<rekado>lfam: good idea

<davexunit>"It's kinda sad that MS Dos, Windows and MacOS have all had a plethora of powerful editors with convenient standard user interface meanwhile the Unix world is anchored to Vi and Emacs."

<lfam>Lol

<davexunit>the HN thread so far is mostly people putting down Emacs

<lfam>Well... it is Hacker News

<rekado>"Once, I used Emacs. All I did with it was play in the land of elisp. I never got any real work done."

<rekado>valid complaint :)

<rekado>but then I don't really have "real work" that needs doing.

<CompanionCube>it's the most recent thing to think that Vim is the most Pefect thing around and personally I despise that notiom

<Jookia>mark_weaver: Bit late to the party but WebkitGTK has some security issues too https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ that won't be fixed

<NiAsterisk> @strace and lispf4: okay, will do as soon as I have a functional second system again.

<NiAsterisk>I wasn#t expressing that i think it's a guix issue

<NiAsterisk>:O friend brought back promotional posters to spread for a congress in berlin, looks very interesting, but 80-250 Euro for 2 days ticket is kind of an issue when you have to add traveling and hotel.

IRC channel logs

2016-02-14.log