IRC channel logs


back to list of logs

<bms_>Nice job, rain!
<rain1>or maybe just pcc
<OriansJ>rain1: well tcc should be able to be compiled using earlier versions of tcc, which if I remember correctly started with just a single C file source
<rain1>ah, that is neat
<OriansJ>rain1: literally
<OriansJ>which would be about a weekend or two of work to figure out the optimal tcc bootstrap starting from the first commit (or possibly a couple later) that janneke's MES could build
<OriansJ>Then we just fill in the gap between stage0 and MES, then we would only have trivial work to do from then on out
<bms_>My first (hopefully) daily entry on my wiki page is up. That does not conclude that day's work... I'm just getting started!
<rain1>keep it up :)
<rain1>ACTION reads..
<epronk>I ran into a corrupt file: p63i3cyqcnafmxyn154q7mlk84k6qj5k-bash-4.4.12-doc
<slyfox>building openssl in core-updates fails because guix tries to patch random ELF file from 'rm' to .../bin/rm:
<slyfox>(why do it at all if tests are not supposed to be installed?)
<OriansJ>slyfox: how could something like that even happen?
<slyfox>don't know maybe openssl tarball alredy contains elf file
<rain1>that's interesting :O
<slyfox>yeah, openssl-1.0.2l/test/ssltest_old is an ELF in openssl-1.0.2l.tar.gz
<rain1>ahh a test case
<Apteryx>Q: Why is this file used from the store when using `guix environment': "/gnu/store/09rv8r22x7qyqx6c59zi75jkl4inx6hk-module-import/guix/build/gnu-build-system.scm"
<Apteryx>My Guix is configured to use ~/src/guix (git checkout).
<Apteryx>Hmm. Maybe it gets copied there from ~/src/guix at some point of the process.
<bms_>Gregg Allman died.
<bms_>I saw his Hammond yesterday.
<epronk>What is the status of "guix system container"?
<epronk>I'm looking for clues on how to boot GuixSD in LXD.
<EuAndreh[m]>n00b question: a package I'm creating just uses the trivial-build-system and all it needs to do is copy a Shell script
<EuAndreh[m]>How do I do that? Is there a cp function or something similar?
<EuAndreh[m]>Line 23:
<OriansJ>rain1: You might find this interesting
<rain1>thank you
<OriansJ>rain1: another one
<OriansJ>and finally
<OriansJ>rain1 janneke, this probably will simplify your C bootstrapping work
<OriansJ>essentially we eliminate the need for libc from the bootstrap at the beginning but we have a straight forward mechanism for adding it when we want.
<OriansJ>sneek: later tell janneke: You might find this useful
<OriansJ>sneek: botsnack!
<Apteryx>Hello! I'm encountering a problem that I can't figure out... Any help is very welcomed! I've written this patch:, but upon applying it to my tree, and running 'make', Guile bails out on a memory error. Am I doing something wrong? The error is show here: TIA!
<catonano>EuAndreh[m]: yes there are a couple of procedres for copying a file
<catonano>EuAndreh[m]: I suggest you to try again during European daylight time, that´s when most guixers hang around
<catonano>EuAndreh[m]: you could also grep te guix codebase for "copy-file" and "install-file"
<catonano>EuAndreh[m]: there's also a help mailing list
<janneke>morning Guix!
<sneek>janneke, you have 1 message.
<sneek>janneke, OriansJ says: You might find this useful
<catonano>janneke: Good morning !
<janneke>catonano: hi!
<amz3``>hi all!
<Apteryx>amz3: Hi!
<Apteryx>janneke: morning!
<janneke>Hi Apteryx!
<janneke>hi amz3
<Apteryx>I'm stuck. I did what I think is a simple change but now I get: GC Warning: Out of Memory! Heap size: 2689 MiB. Returning NULL!
<amz3>rekado: using a Makefile only with make, make install and make check doesnt work because the Makefile doesn't know where to install stuff
<Apteryx>Here's the diff of my change. Basically just added a new field `append-separator?' to our search-path-specification record:
<Apteryx>Hmm... Maybe I had to do "guix environment guix" using my modified versions. It's rebuilding the core tools now (bash, gcc, etc.). I guess due to my change. I'm hoping the crash will be resolved after that!
<cbaines>I thought I'd give installing Guix in a VM from a Debian live ISO a go again, but I've got stuck copying the behaviour of the cow-store service. I can't seem to move the mount, mount --move /.rw-store /gnu/store gives mount: bad option. Note that moving a mount residing under a shared mount is unsupported. Any ideas?
<amz3>I've sent a packaging request on guix-help..
<rekado>amz3: normally a Makefile will install to PREFIX and allow the user to override the PREFIX variable.
<rekado>so in Guix we would to (arguments '(#:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")))))
<amz3>hmm ok
<amz3>Will see, if nobody answers my packaging request, I will try that
<rekado>okay, I won’t touch it in case someone else wants to give this a try.
<amz3>I had a completeé Makefile, but I deleted it instead of using 'git stash'
<amz3>two times in a row
<amz3>I will work on documentation now
<rekado>amz3: deleted as in “rm Makefile”?
<amz3>no, I did 'git reset --hard'
<amz3>I don't like git tbh
<amz3>I was more confortable with mercurial and its anonymous branches
<Digit>heh. im just on guix package -i git.
<rekado>amz3: I use local branches on git all the time.
<amz3>I read git has anonymous branches too, but it's weird thing, I should follow some git dojo or something to learn more about guix
<Digit>should help me expedite recovering my configs, n making guix nice, so that i actually start using it. terrible ootb configuration.
<rekado>I only use stash for emergencies.
<slyfox>amz3: if the work was committed 'git reflog' will contain the past commit
<amz3>I don't have that habit yet
<amz3>thanks for the tip
<rekado>Digit: what has a terrible ootb configuration?
<Digit>guixsd. not a fan of the wm, or various other choices.
<rekado>Digit: but … there is no default.
<rekado>what is the default wm?
<rekado>no, that’s just a fallback in case you don’t have any :)
<Digit>so... effectively the default then. :P
<rekado>what does your configuration say?
<rekado>where does that come from?
<slyfox>guix in core-updates reports phase times like 'phase `strip' succeeded after -671187998.0 seconds'
<rekado>core-updates guix is really fast
<rekado>slyfox: we haven’t even begun evaluating core-updates at this point.
<rekado>slyfox: have you built everything from source?
<rekado>Today I’ll push a glibc change to core-updates, so you’d have to rebuild everything again :(
<slyfox>it's ok, i have a few local patches to speed up it's building
<AndChat|217856>I don't like rebasing, in git
<AndChat|217856>It loses the history of the branch
<slyfox>it's not a requirement to rebase in git
<slyfox>you can use git pull
<AndChat|217856>And I usually forget ti properly order the commits so I mangle the patchrs
<rekado>“git pull” = “git fetch”; “git merge”
<slyfox>'git rebase --abort' can roll things back fr you if you are in the middle of collision
<rekado>ACTION always rebases
<AndChat|217856>Slyfox, i use rebasing when i have to integrate/fix the patches that i submit to guix-patches
<slyfox>right. there is no point of keeping history there
<rekado>AndChat|217856: why would the order of patches have to change then?
<AndChat|217856>Rekado i usually modify things that belong to commits that are up in the branch
<AndChat|217856>And i usually overload the last One
<rekado>ah, I do that too
<rekado>but I name the commits such that I know where they belong
<AndChat|217856>I do too
<AndChat|217856>But i hate that
<rekado>for modifications to the last commit I just amend
<AndChat|217856>I feel like i am playing that japanese game where you have to pick up a stick without moving the other sticks
<slyfox>'git add -p' allows you to do multiple commits from one modified workdir
<AndChat|217856>Right. I still can't do that
<AndChat|217856>You never know enough :-/
<AndChat|217856>Why do you say there's no point in keeping the history ?
<slyfox>maybe there is. how would history look like?
<slyfox>all the merge commits you did and conflicts solved?
<slyfox>or having some intermediate states that don't work?
<slyfox>those i would say are not useful
<mystified>hey guys downloaded uixsd-usb-install-0.13.0.x86_64-linux.xz
<AndChat|217856>I have no idea, I'm no Linus Torvalds. I Just tell you that i triestini ti nitpick once and It took a versione so old i didn't Remember about it
<mystified>to make live usb installer do I need to decompress first
<slyfox>mystified: yes, you need to decompress
<AndChat|217856>I tried to cherrypick
<AndChat|217856>I have no merge commits
<slyfox>cherry-pick is a way to pick a commit rom another branch and apply it to another
<rekado>cherry-pick is like a single-commit rebase
<rekado>ACTION always uses interactive rebase
<AndChat|217856>When patches get accepted i erase the branches
<roptat>hi, I've got a problem with xfce4-terminal when I want to choose colors, it crashes with "(xfce4-terminal:14965): GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.ColorChooser' is not installed"
<slyfox>i usually use 'git pull --rebase'
<AndChat|217856>Exactly. I tried to rearrange my branches using cherrypicking
<AndChat|217856>But It took very old versions offline my branch back to life
<AndChat|217856>Because my original branch was rebased several times
<slyfox>cherry-pick accepts a commit ref. you can specify sha1 or branch name
<AndChat|217856>Git is a nevessary evil
<slyfox>whichever is easier to get right
<AndChat|217856>Branch name is easier to get right
<slyfox>'gitk' (or git show-branch) could be useful to get the ide how branches are laid out now
<AndChat|217856>But It doesn't work on rebased branches
<AndChat|217856>In my experience
<slyfox>for massive branch changes it might be useful to clone a branch and remove unnnecessary stuff with intractive rebase
<slyfox>you know about 'git rebase -i', right?
<AndChat|217856>And how do you clone a local branch ?
<slyfox>git branch -b new-b old-b
<AndChat|217856>Yes i use git rebase -i all the time. That's when i mangle commits
<slyfox>or 'git checkout -b new-b old-b' (ot switch it to as well)
<AndChat|217856>Interesting. I didn't know
<AndChat|217856>Anyway, git is awful. The fact that workflow needs so much discussion is a shame
<AndChat|217856>Yestetday i was looking at darcs
<AndChat|217856>Hoping It could be better
<slyfox>before git i mostly used CVS. for me git is a blessing. and i really miss many git's features in hg and others :)
<efraim>how are we doing with staging? I'm testing it now on aarch64
<AndChat|217856>What is git pull --rebase ?
<janneke>AndChat|217856: git fetch; git rebase <the-merge-branch>
<slyfox>'git pull' is a 'git fetch origin/foo' + 'git merge origin/foo'. --rebase makes it 'git fetch origin/foo' + 'git rebase origin/foo'
<slyfox>s/git rebase origin/foo/git rebase --onto origin/foo/
<efraim>i often do git fetch, git rebase -i
<AndChat|217856>So you call that from within a feature branch and It automatically rebases your feature branch onto the updated master ?
<efraim>for that i do git fetch, git rebase -i origin/master
<AndChat|217856>Ok but does git pull --rebase do that ?
<efraim>not sure, never used that
<AndChat|217856>See ? Git is a mess
<efraim>there's quite a number of overlapping commands
<AndChat|217856>It's a huge antipattern in user interaction
<AndChat|217856>I don't understand why this IRC client can't get my Mame right
<AndChat|217856>My name
<slyfox>'gut pull --rebase' rebases on top of pulled branch, yes
<AndChat|217856>Ah ok. Thanks
<AndChat|217856>Ok time to get back home
<AndChat|217856>I have to ride my bike for 8 km
<AndChat|217856>I need to loose wheight
<AndChat|217856>Maybe i deserve One more desugared ginseng before going
<cbaines>Is there a simpler approach to the cow-store service for installing GuixSD? I'm trying (and failing) to install GuixSD from a Debian live system, and I can't seem to reporoduce a working cow-store service like thing...
<AndChat|217856>I'm home
<Digit>home again, home again, jiggidy jig.
<catonano>Digit: ☺
<slyfox>in master or core-updates 'guix environment --ad-hoc gcc' pulls in gcc-7.1
<slyfox>how would one override a gcc dependency for a package to use gcc-7.1? say, for re2c
<slyfox>I tried 'guix build --with-input=gcc=gcc re2c' but it does not seem to do the right thing
<janneke>slyfox: what about: (native-inputs `(("gcc" ,gcc-toolchain-4.9)))
<slyfox>is there a way to do that with just 'guix build' command without changing/creation new derivation explicitly?
<rekado>“guix environment --ad-hoc gcc@4” gives you a different gcc
<rekado>(also, you should be using “gcc-toolchain”, not “gcc”)
<slyfox>'guix build --with-input=gcc-toolchain=gcc re2c' has no effect
<rekado>not sure if the input rewriting works with toolchains
<slyfox>if it's not a normal procedure to occasinally try to build a package with newer gcc how do you normally update base gcc everything is built with?
<janneke>OriansJ: yeah, i'm very unhappy with Mes' build system; it was intended to be universal and real simple to use, but i went overboard
<janneke>OriansJ: and we will need something like a shell/scheme script anyway while bootstrapping
<janneke>so feel free to do anything to it that you see fit, and tell me how I could help
<rekado>slyfox: we update the gcc alias and build it all on hydra
<slyfox>'gnu/packages/gcc.scm:(define-public gcc gcc-5)' this one?
<rekado>slyfox: yes, I think so.
<rekado>ACTION is not sure
<mbakke>slyfox: also see b810a85019ab3c4ee1f889d0751b8eb06157dadc
<slyfox>sorry, i'm very confused now :) why 'guix environment --ad-hoc gcc' picks different version?
<rekado>slyfox: because “gcc” is a package name
<mbakke>slyfox: the various guix commands pick the latest version
<rekado>slyfox: and guix picks the latest version
<rekado>slyfox: the gnu build system, on the other hand, uses gcc-final
<slyfox>aha, that makes sense
<slyfox>at which stage --with-input= tries to perform the rewrite? i thought it changes key/value ~aroud -guile-builder where it's trivial to see all inputs (gcc/cross-gcc):
<ng0__>for intel ethernet cards, is the Intel i350-AM2 Gigabit Ethernet supported by linux-libre?
<ng0__>this is on supermicro server if it helps.. I seem to recall that most of my devices have intel ethernet, but I'm not sure
<ng0__> 82579LM Gigabit Network Connection by intel is on another machine which works with linux-libre.. I guess the problem is then just with wifi from intel?
<ng0__>or are there some proprietary mushrooms in chipsets used on server boards?
<mystified>hey guys trying to make bootable installer. decompresssed th file. I now have " guixsd-usb-install-0.13.0.x86_64-linux " Description 'UNKNOWN' "
<mystified>is that right
<mystified>should it not be an iso or an img
<brendyyn>It just doesn't have a .img on the end
<ng0__>it is a raw qemu image
<mystified>it says unknown
<ng0__>this is not important
<mystified>in type or description
<mystified>I was trying make the img with etcher.
<mystified>I see i must use DD
<ng0__>you can just dd it do a disk/usb drive or run it with qemu, as documented in the documentation :)
<mystified>Ill do it bthat way now
<ng0__>iso will be avaialble in the future, because a huge part of the industry of server hosters still depends on iso to offer systems :)
<mystified>etcher is so much easier and rarly have a failure with it compared to other methods.
<mystified>with iso & img
<rekado>ng0__: yes, there are proprietory network chips on server boards. Many broadcom chips for example.
<ng0__>I would have to read the linux-libre source to find out the deblob, right?
<ng0__>e.. if it is prop. I meant
<ng0__>also I'm not sure if linux-libre supports xeon as I never had one of them. my kernel configuration experience is limited to linux, not libre
<ng0__>basically what I'm looking at as a given choice is
<OriansJ>janneke: I'm honestly going to need you to list out the build order for MES and I'll use that as a Map for creating a trivial makefile that should be sufficient for right now
<janneke>OriansJ: OK
<janneke>OriansJ: possibly we should distinguish between two build scenarios: bootstrapping and development
<janneke>there is a lot of stuff in mes: test/ scaffold/ tinycc/ that is only interesting for development
<janneke>also, building src/mes.c using GCC is also only interesting for development
<OriansJ>janneke: I'll be sure to break those out as separate pieces and have a make development
<janneke>OriansJ: good.
<janneke>then currently, there is an extra level of complexity with the 32bit binary memory dump of the full scm reader: module/mes/
<janneke>we need a 32bit verion of Mes to create that dump
<OriansJ>even on 64big hosts?
<janneke>if we instead add src/reader.c to bootstrap mes and remove (or not use) the binary memory dump+read feature, then things get even more simple
<OriansJ>lets keep it simple
<janneke>OriansJ: yes...bootstrap mes is currently 32bit on a 64bit host, i'm using an i686-unknown-linux-gnu-gcc cross compiler to build i686-unknown-linux-gnu-mes to make that dump...
<janneke>all of that is not necessary if i manage to add the reader to mes, i think that should be my first step now
<OriansJ>Do that and capture what exactly needs to be done to build it
<janneke>thanks for pointing out the [obvious] pain, it's easy to get blind for your own mess ;-)
<OriansJ>janneke: it is easy for us to forget what is easy for us isn't always easy for others.
<janneke>glad you understand -- i can see how silly this unnecessary complexity is, esp. when trying to get others involved -- of course i have very sound historical reasons for things being as they are ;-)
<OriansJ>janneke: of course, you were by yourself and making progress but now other people want to help.
<janneke>also, src/reader.c did not compile with mescc and moreover, i wanted the C core for bootstrapping as minimal as possible -> not having a reader in C but running a binary scheme program saves some C primitives (and ca 200LOC)
<OriansJ>janneke: actually those things in the reader, aren't C primitives. They are just imported functions
<janneke>OriansJ: hmm...didn't you have a way in your stage2 LISP to make that distinction?
<janneke>i would like that for mes, but did not see how to do it
<OriansJ>janneke: it is easy anything in C that takes the form of name(...) is just an imported function
<OriansJ>janneke: as for the stage2 LISP, only a small number of special things needed to be treated differently than all of the other functions. They are generally referred to as special forms.
<janneke>OriansJ: i like what i hear, i've been searching for something like that, but i cannot see it yet
<brendyyn>guix import cpan is broken I think. Doesn't recognise the SSL cert
<OriansJ>janneke: Hence I sent you this all you need is an assembly interface and the entire C language support requirements drop like a brick
<brendyyn>guix/build/download.scm:417:6: X.509 certificate of '' could not be verified:
<brendyyn>X.509 i mean
<janneke>OriansJ: ah yes, I read part and then glanced over the rest of i. if i'm not mistaken, that's what mes already does; everything can be compiled using either gcc or gcc -nostdinc -nostdlib.
<janneke>OriansJ: I have a working version of out/mes.guile that includes the reader and runs without
<rekado>ng0__: you only need to read the deblob script. It’s distributed separately.
<ng0__>okeiokei :)
<OriansJ>janneke: I'll pull the changes when you are ready and verify the build instructions
<ng0__>brendyyn: do you have the nss-certs in your system?
<janneke>great, i'll let you know
<janneke>or else you see it in my git ;-)
<rain1>good morning
<janneke>morning rain1!
<brendyyn>I installed it but it still didn't work. It does work on my GuixSD system though, but not on this laptop with Guix on Parabola
<rekado>brendyyn: have you set the required environment variables explained in the manual?
<brendyyn>some of them. maybe not ones to do with finding certs
<ng0__>if you use bash you can source the file
<ng0__>the .guix-profile/etc/profile
<OriansJ>how is it going rain1?
<rain1>very good, i just sent a thank you to the tcc ML for their patch
<rain1>I might check now if ACK can build PCC
<OriansJ>rain1: keep up the good work :D
<brendyyn>which file should a program like Ack go in?
<rain1>I guess it would go with compilers/language implementations
<brendyyn>I mean Perl ack
<rain1>oh im sorry
<brendyyn>It's justa coincidence that you happened to mention ACK and then I asked that, xD
<rain1>i got mixed up
<rain1>maybe it could go in developer tools
<brendyyn>There is no such file
<OriansJ>brendyyn: why not?
<janneke>rain1: i have made quite some progress compiling tcc.c, but the news that our target may be easier makes me very happy
<rain1>well, OriansJ suggested building an earlier single file tcc then bootstrapping up to the latest one
<rain1>this seemse like a very good idea
<rain1>but theer also the option of pcc, whether its code is easier to compile or not I can't say
<rekado>mbakke: ah, you already fixed gajim
<janneke>i was thinking about the ack/pcc options
<rekado>mbakke: I was just about to push my fix
<rain1>ACK seems quite enormous and failed to build so I don't know if it will be a help
<rekado>mbakke: thanks!
<rain1>it was worth checking it out though
<rain1>but yes it's looking a lot more promising than it was!
<OriansJ>rain1: how about you find the oldest version of tcc that can build the current version?
<rain1>and the more alternative bootstrap chains we have the better
<rain1>i can have a go at that, by bisecting the commits
<OriansJ>exactly, and we can always go back and add more bootstrap chains
<EuAndreh[m]>catonano: Thanks. European daylight time is something like GMT +0, right?
<catonano_>gmt +0 up tp gmt + 2. i think
<efraim>I would think +2
<catonano_>EuAndreh[m]: now it' s 04:11 PM in Italy
<ng0__>utc is -2 hours from berlin (which also covers rome)
<ng0__>ah, daylight saving.. uh.. no diea
<ng0__>from utc, daylights saving time is -2 and -1 depending on the season
<rain1>the old tcc versions seem to execute the program, not producing a compiled binary
<OriansJ>rain1: ouch
<mbakke>is it okay to update binutils on core-updates?
<paroneayea>sneek: later tell civodul in case you didn't see, I know you wished you got one of the Guix shirts last time, and sirgazil put them up here:
<sneek>Got it.
<mbakke>paroneayea: wow, those are awesome!
<quiliro>what is the cheapest solution considering total cost of ownership (including electricity): cluster of old machines or new machine?
<quiliro>what i mean is that it might be cheaper to pay for a high performance single machine than to pay for several low performance machines which offer the same combined performance.
<paroneayea>quiliro: depends on your circumstance?
<quiliro>4 core 2 r
<quiliro>4 core 2 duo or 1 i7
<catonano>quiliro: depends on the cost of electricity
<roptat>hi, there's a %D%/packages/patches/synfigstudio-fix-ui-with-gtk3.patch.patch in gnu/ that's probably a typo :)
<Apteryx>Trying to build gcc 5.4.0, I got build error: collect2: error: ld returned 1 exit status
<quiliro>$0.10 /KWh
<quiliro>catonano: that is the price in Ecuador
<janneke>paroneayea: woa, way cool!
<catonano>quiliro: you need to calculate how much would it cost to keep a bnc of old macines humming. And how mch would it be to do the same with a single more modern machine
<quiliro>how can i know how much each consumes?
<catonano>you should take a look at them, at thhe labels on the back. Maybe search for the tech sheets on line
<mbakke>quiliro: look up the processors on
<mbakke>the TDP is listed there
<mbakke>a modern i7 is *much* more power efficient than core 2 duo
<mbakke>and probably comparable to 4x c2d in processing capacity
<efraim>Go arm boards!
<Apteryx>It's pretty intensive to try to hack something at the level of gnu-build-system :o
<Apteryx>I need a server farm.
<janneke>OriansJ: i have pushed a `wip-build' branch [to]
<janneke>OriansJ: i have removed the dependencies on *.mo and building of them alltogether, which means that also building mes does no longer depend on a 32bit gcc or these binaries
<janneke>OriansJ: i tried to write a little something about the current (soon to be fully revamped by you ;-) build process in HACKING
<janneke>OriansJ: and i have added a new target: make build-scripts that uses make --dry-run to generate two sets of build scripts: one for bootstrapping and one for development
<janneke>you may want to have a checkout of tinycc (git clone next to mes, so that the development build scripts show building and rurring tinycc's test/test2/* tests
<janneke>i hope this makes some sense, be sure to nag me if it doesn't ;-)
<Apteryx>Hmm. What's that: *** No rule to make target 'gnu/packages/patches/synfigstudio-fix-ui-with-gtk3.patch.patch', needed by 'all-am'. Stop
<Apteryx>Happening on master
<Apteryx>Is there a way to have Emacs vcs support for git worktrees? Right now it says "not under version control".
<Apteryx>Ah, nevermind, I was looking at 'Makefile' rather than ''. It works.
<Apteryx>OK, the make problem was a typo in I've sent a small patch to fix that.
<Apteryx>(see guix-devel)
<slyfox>thank you!
<ng0>Hej! I'm preparing a batch of font-build-system packages and I noticed the font-awesome hash changed. should I use the source on github instead?
<ng0>the source includes the font twice -.-
<ng0>but the font isn't that big..
<Apteryx>lfam: Also, there are translation updates to be commited. I've sent a patch, mostly as a reminder ;)
<ng0>I will change the source in an extra patch.. can be taken as is or left out.
<Apteryx>It has a date in it though... so this would not make guix unreproducible :(
<lfam>Oof... I just realized that graphicsmagick includes a bundled copy of libtiff
<lfam>And many other libraries...
<Apteryx>lfam: Oh. That's unfortunate
<Apteryx>Are you going to unbundle it?
<lfam>Yes, hopefully it's not too hard. *Many* libraries need to be unbundled
<Apteryx>I wonder what's up with this trend of wanting to bundle everything.
<lfam>No good solutions for developers... aside from Nix / Guix ;)
<Apteryx>lfam: Is there not a build flag to use system version instead?
<lfam>I'll find out. I have to go AFK soon
<lfam>ImageMagick does not do this
<ng0>it's not recent I think. This was the way since forever to ensure that your static build binary is the same on every system
<ng0>there's a follow up commit to one of the recent font-build-system commits which will fix the build of a font.. Strange that lint did not complain about two build-systems in one package :) I will be done in a while
<EuAndreh[m]>I just sent a few duplicated (and a few encrypted) mail to
<EuAndreh[m]>Sorry about that, I'm still struggling a bit with the email workflow
<ng0>okay, font patches are out.
<rekado>Apteryx: thanks for reporting this.
<rekado>sneek later tell lfam Thanks for fixing my typo in gnu/
<sneek>Will do.
<Apteryx>rekado: yw!
<Apteryx>I'm not sure what to do of the translation file updates though; there's a datestring somewhere in there so it's non-reproducible as it stands.
<Apteryx>But there was already a date string there and it didn't seem to affect anything. Maybe it's OK.
<Apteryx>sneek: later tell alezost: Do you think it'd make sense to use search-paths instead of the elisp glue code for module discoveries? I think I've got something working, but I've yet to test it (touching gnu-build-system search-path means rebuilding the world).
<sneek>Will do.
<janneke>ACTION has first hacky small success compiling struct foo { int bar[2]; };[0] = y;
<janneke>tcc needs that
<janneke>ACTION -> zZzz
<Apteryx>janneke: good night!
<ng0>sigh... apparently GNU wants a trusted key for ftp upload capability. which is not good when you simply ignored the WOT part of GnuPG for a long time. Anyone by any chance living around NRW, Germany of you?
<ng0>or I simply start sending signed emails with the now permanet key I have and maybe some of you want to sign the key as is without meeting