IRC channel logs


back to list of logs

<davexunit>rekado: figured out the gsch2pcb issue. m4 needs to be available in the environment. going to see if I can fix the package to include an absolute path to it
<davexunit>well, it's one of the issues, anyway.
<lfam>ACTION works on the samba update
<slim404>ACTION trying to set up the display manager with french keyboard 
<suitsmeveryfine>What program do you recommend for emailing in Emacs?
<slim404>just realised that gnome on guixsd is only 14 days old
<bavier>slim404: you're on the bleeding edge :)
<slim404>bavier: yes :) and i did not realize because everything was effortless and without glitches
<slim404>bavier: it just works
<lfam>slim404: Except for the french keyboard problem?
<bavier>slim404: I'm glad it's working for you
<slim404>lfam: yes, but that is just fun. Man the soundcard worked out of the box with all that pulseaudio thing on my little aspire one
<lfam>Indeed, I was very glad when audio worked out of the box for me, especially since I have had bad experiences with PulseAudio in the past!
<lfam>It would be nice to configure sound in the operating system declaration, but at least I can listen to MPD :)
<lfam>Can somebody download this patch and tell me what the sha256sum is?
<lfam>Or, the `guix hash` of it?
<bavier>lfam: sure, just a sec
<bavier>big patch
<lfam>8 named vulnerabilities
<lfam>Are you sure the last character isn't missing?
<lfam>BTW, while you were doing that, I realized they sign their patches, but don't link to the signature from the security advisory page. But thanks anyways!
<lfam>Wow, with my comment at the top, `wc -l` says it's 39533 lines long
<bavier>lfam: could we not just do a release update?
<bavier>to 4.3.8?
<lfam>I don't know their versioning system, so I went with the patch. Is it compatible with 4.3.6?
<bavier>it sounds like 4.3.8 is the patched release for the 4.3 support branch
<lfam>It seems that 4.3.7 and 4.3.8 are security releases on top of 4.3.6. One would assume 4.3.7 is equivalent to applying the patch.
<lfam>I guess they issued the patch for distributions that don't like to bump version numbers
<lfam>I'm testing to update to 4.3.8
<bavier>I think we should do the version update, since 4.3.6 itself was released just more than a month ago
<bavier>if build/testing go smoothly that is
<lfam>I have to rely on upstream's test suite since I don't use samba.
<lfam>And I also rely on the assumption that a security update is compatible with what it replaced...
<lfam>Well, our package disables the test suite.
<bavier>that makes things more difficult
<bavier>hrm, I'm trying to fix timestamp reproducibility issues in some packages I'm writing, but I'm having trouble deciding where to put the fixes
<bavier>as patches/snippets in the origin, or as phases that do substitute*
<lfam>samba 4.3.8 builds. Do you think I should apply the update?
<lfam>Knowing that we didn't run the tests?
<lfam>I think that if the changes require patching, and the patch fits easily in a (substitute*), then you should do that. It's better than hiding it in a patch file.
<lfam>Although then users who checkout the source don't get your fix
<lfam>I don't know. I think we should try to push these changes upstream if the upstream is active
<lfam>Hello iyzsong!
<bavier>yes, ideally they would be patches to upstream to support SOURCE_DATE_EPOCH
<bavier>perhaps I'll start there
<bavier>lfam: I think you could apply the samba update
<lfam>Yes, I'm writing the email now
<iyzsong>I'd put them in snippets, they're not guix specified patches. snippets also get applied into 'guix build -S'.
<lfam>iyzsong: Good point. They could be useful on other systems
<lfam>Although the nice thing about a patch file is that, if it's good, you can send it directly upstream
<bavier>the snippets would be to fix a date string in the source
<bavier>at least at the moment
<lfam>There's no bug report like a bug report with a patch
<iyzsong>yep, patches is better for upstream.
<bavier>I don't think that would disappoint anyone doing 'guix build -S'
<lfam>Especially if you preserve upstream's behavior if SOURCE_DATE_EPOCH is unset
<lfam>On this topic, I recently noticed timestamps in many man pages. We should work to get this fixed in the manpage generators
<lfam>bavier: If you are interested in this stuff, you should checkout #debian-reproducible and #reproducible-builds on
<lfam>Yes, also with Sphinx
<lfam>And probably many others
<bavier>lfam: oh, I didn't know there were irc channels
<lfam>I've been ignoring Python 3 reproducibility issues until we get the bytecode compiler fixed, but many of them have timestamps in man pages
<bavier>pdflatex too
<lfam>This database is valuable:
<lfam>I need to start contributing to it
<lfam>The database notes timestamps in manpages created by doxygen, yat2m, ronn, Pod::Man, sphinx, txt2man, help2man, docbook2x, docbook_xsl, docbook_utils, libwibble, pandoc, golang_cobra and autogen.
<lfam>What a nightmare :)
<bavier>ample opportunities for success ;)
<lfam>It will require so many emails... ;)
<lfam>iyzsong: Thank you for fixing that bug!
<paroneayea> crazy
<paroneayea>I wonder what this will mean for icecat?
<dmarinoj>Does anyone run Guix as a package manager on Hurd here? Just installed Debian GNU/Hurd and am interested in using it as a second package manager.
***Basstard1 is now known as Basstard`
<slim404>I installed GDM in guixsd
<slim404>how am I supposed to start it?
<slim404>I tried herd start gdm it did not work
<slim404>guixsd gnome desktop is provided with SLIM as display manager in default install
<slim404>since SLIM does not seem to support non US keyboards, I'm trying to replace it with GDM
<alezost>slim404: it looks like we don't have a service for GDM, so you probably can't use it right now; but I'm not sure, iyzsong should know better
<slim404>alezost: thanks. I installed the gdm package doing guix package -i gdm. Is it supposed to be started from command line?
<iyzsong>slim404: gdm doesn't work now..
<slim404>iyzsong: shall I remove the package?
<iyzsong>yes, gdm can't running now. it want to start /usr/bin/X, I haven't patch that.
<slim404>alezost, iyzsong : btw, I can't find the shepherd startup script. documentation says it should be /etc/shepherd.scm but it's not there
<slim404>iyzsong: thanks
<iyzsong>slim404: it's in the gnu store, you can find that from '/proc/1/cmdline' or /run/current-system/boot
<alezost>slim404: every system has its own shepherd config. Look at "/var/guix/profiles/system/boot": there is a link to "/gnu/store/…-shepherd.conf"
<slim404>iyzsong, alezost thanks :)
<iyzsong>welcome :-)
***joachifm is now known as Guest95269
***joachifm is now known as Guest84027
<civodul>Hello Guix!
<iyzsong>hi :-)
<civodul>iyzsong: gnome-updates hasn't been evaluated yet
<civodul>something related to grafts is causing it to time out
<civodul>i'll be looking at it today
<iyzsong>ok, thanks!
<phant0mas>davexunit: did you manage to get avr-gcc to work for you?
<davexunit>phant0mas: yes, I followed up on the mailing list about it.
<phant0mas>ACTION checks his emails
<davexunit>I had to use a hack that isn't general enough to work everywhere
<davexunit>no i686 compiler toolchain needed, at least.
<phant0mas>hm.. this is not a good fix
<davexunit>no, it needs to be made general.
<phant0mas>let me see what I can do
<davexunit>but what it proved is that you *don't* need another cross-compiler
<davexunit>the host compiler will work, but the build system needs to understand that!
<anthk_>builder for `/gnu/store/5zw29vysmzbf20ydbp6054lxkdf1rs40-gst-plugins-good-1.8.0.drv' failed with exit code 1
<anthk_>while doing a guix system reconfigure
<rekado>looks like pandas is broken.
<rekado>tests fail
<davexunit>rekado: I'm not quite there yet, but I think I'm getting close to having geda-gaf configured correctly out of the box.
***piyo` is now known as piyo
<davexunit>for some reason it still doesn't generate a pcb from my schematic, but it does seem as though I've fixed all of the search paths.
<davexunit>so maybe my schematic is just bad...
<rekado>does it produce a netlist?
<davexunit>no. the file is empty.
<davexunit>as are the .cmd and .pcb files
<davexunit>before, PCBLIBPATH, gsch2pcb:pcb-m4-command, gsch2pcb:pcb-m4-dir were not configured right.
<davexunit>rekado: I'm assuming that you've seen this actually work before, right?
<rekado>I've designed a couple of PCBs with gschem and pcb on GuixSD.
<rekado>but it's been some time since I had to use gsch2pcb
<rekado>do the elements in your schematic have an assigned footprint?
<davexunit>rekado: I do not know. I'm a total n00b here. :)
<davexunit>I'll read up on how to check for that.
<davexunit>I didn't do anything explicitly. I just selected components with 'I', placed them, and then connected them with nets
<rekado>davexunit: I think you still have to give them a footprint.
<rekado>the schematic editor cannot guess what component package you will use on the PCB.
<rekado>that's why there's a footprint field somewhere.
<davexunit>I just discovered this
<davexunit>maybe I glossed over this in the tutorial I was reading
<davexunit>now to figure out the footprint that I want...
<davexunit>for now I'd just like a footprint for a simple through-hole connector
<davexunit>one of those little drilled circles with copper around it
<rekado>I think you can use "CONNECTOR 1 1"
<rekado>CONNECTOR is a macro afaik
<rekado>davexunit: here's one of my projects:
<davexunit>rekado: thanks!
<rekado>both gschem stuff and pcb stuff.
<davexunit>I will see if this gsch2pcb will work on it
<davexunit>rekado: it builds!
<davexunit>now my issue is that when I open it in pcb I don't see anything
<davexunit>I think it might be a rendering issue
<davexunit>the board is entirely white, but the cursor changes depending on where I move it
<davexunit>rekado: anyway, I'll submit a patch for the improved geda-gaf package. now you do not need to specify the -d flag to gsch2pcb.
<davexunit>patch sent.
<cehteh>haha .. remember when i told about the idea about software with expiry date? .. now the one who had the idea is in the news:
<davexunit>rekado: your schematics are really cool. I have a lot to learn to be able to understand this.
***Basstard1 is now known as Basstard`
<ng0>cehteh: debian seems to do that..
<cehteh>jwz not debian
<cehteh>they just packaged it
<ng0>i mean debian seems to sleep on lts after lts ended. or something.
<ng0>and some other distros
<cehteh>you should check the xscreensaver packaged in guix .. possibly the same problem
<ng0>idk.. i don't use it.
<ng0>wouldn't know
<ng0>we should track versions somehow though
<cehteh>well the discussion half a year ago was about if this expiry date for free software makes any sense
<ng0>for archiving it doesn't, for general use maybe.
<ng0>restrictions of freedom you run into
<ng0>policies of distros, release cycles, package maintainer capacitiy, etc
<cehteh>i dont want to continue this discussion .. just wanted to post that i found the initiator of that idea :D
<ng0>i did not plan on starting one, just listing things off my head
<ng0>were there problems of running guixsd in a vm? I'll probably end up doing that for some time now. the process and problems should be inthe manual and also outlined in past logs I'd assume.
<davexunit>ng0: I've made many working guixsd vms in the past
<ng0>cool, okay.
<kyamashita>Hello all. I may have a solution for building Red Eclipse successfully.
<davexunit>kyamashita: is that a FPS?
<davexunit>I really want Xonotic in Guix, but building it was non-trivial.
<kyamashita>First, how do I check out a source recursively in a package definition?
<ng0>and building xonotic (including downloads and checking out) takes a really long time.
<davexunit>kyamashita: what do you mean?
<kyamashita>ng0: Red Eclipse will take a long time to check out and download as well.
<davexunit>is this a git repo or something? are there no tarballs for this?
<kyamashita>davexunit: not easily, no. See
<kyamashita>davexunit: I mean emulating 'git clone --recursive'.
<ng0>holly tanknoodle
<davexunit>kyamashita: thanks for the context. there's a 'recursive' field you can set on the 'git-reference' object
<ng0>that's alot of packages.
<kyamashita>I thought that if I used the git repo, it'd be easier than *that*
<davexunit>but it looks like using source tarballs is doable
<kyamashita>davexunit: How so?
<kyamashita>More simply than the AUR PKGBUILD?
<davexunit>this AUR script is quite simple
<kyamashita>Well yes, but I'm not sure how it translates to a Guix package definition.
<davexunit>each of those source tarballs would be an input to the red-eclipse package
<kyamashita>So they would each have their own definition?
<davexunit>and you can eliminate redundant code by mapping over a list of these things
<kyamashita>This would be easier if I had more guile knowledge. I've just been basing my definitions on what I saw in the tree already.
<kyamashita>How would I map over a list of the tarballs? Is there something like this already packaged in Guix?
<davexunit>'(("acerspyro" "18718286a72298b0a016d147524bc53094c4ad3897859ec8422131b5acc9bd3f") ...)
<davexunit>I think this is all the info you need
<davexunit>from there a procedure can generate the origin recorder
<davexunit>er, record*
***kmic is now known as kmicu
<kyamashita>So I send the list through the procedure?
<davexunit>here's a rough example
<kyamashita>I see. And tarballs are preferable to fetching through git?
<davexunit>kyamashita: yes
<davexunit>much preferred
<davexunit>git is not a source code release system :)
<davexunit>but sometimes we have no other choice
<ng0>i will extent my discussion on gnunet-svn soon once i'm through with it with portage, there were some ideas so far we could apply.
<kyamashita>Noted. I'll try implenting that function of yours, davexunit. I'll pipe up again if something interesting happens.
<kyamashita>Prehaps with this method I could separate Red Eclipse and its data.
<ng0>you could also git shallow if that's not already the default of git-fetch in guix
<davexunit>an additional step after this would be to give a name to the ((name hash) ...) list so that you can re-use it in the build script
<davexunit>since you'll need to write the equivalent of that for loop in the PKGBUILD file
***joachifm is now known as Guest49472
<kyamashita>Yes. I was going to ask about that.
<davexunit>and now that I look at it more, it seems that "base" should be left out of the list.
<davexunit>that should be the 'source' for the redeclipse package
<davexunit>since it's not a data package.
<kyamashita>Yes. That's what I was thinking. So redeclipse and redeclipse-data will be two separate definitions.
<davexunit>I understand this might be a lot to take in, but this is *exactly* the sort of thing that makes Guix better than other tools.
<davexunit>kyamashita: you could do that, but not necessarily
<davexunit>up to you. :)
<davexunit>I actually think that you can't do that in this case, though.
<kyamashita>I'd prefer to keep them together in one since redeclipse would be useless without its data.
<davexunit>do that
<davexunit>the code I sent to you still applies
<davexunit>try to do exactly what this PKGBUILD is doing
<davexunit>just in Scheme :)
<kyamashita>Cool. I'll get working on that. Also, is any progress being made on printing support in GuixSD? It's literally the only thing stopping me from running it at this point.
<davexunit>kyamashita: would you like to join in on it? I'm not sure what the status is.
<davexunit>I don't have a printer at home so I haven't tried any of the relevant software.
<kyamashita>I'd like to try. I've never played around with system services before so it should be interesting. I'd need to move over to GuixSD for meaningful testing, though.
<kyamashita>So I guess after Red Eclipse is functional, sure!
<davexunit>kyamashita: good luck!
<ng0>is red eclipse similar to red shift or what it was called?
<davexunit>Snappy developer information for the next Ubuntu release
<kyamashita>ng0: No. It's derived on the Cube 2 engine. Ever heard of Sauerbraten (not the dish)?
<ng0>sure, the one xonotic originated from
<ng0>or was it? Darksomething engine
<davexunit>Xonotic is darkplaces
<kyamashita>Based on the Quake 1 engine.
<ng0>i think i'll just look into red eclipse :)
***handsome1pirate is now known as handsome_pirate
<davexunit>Snappy makes me *extremely* worried about the future of the GNU/Linux desktop
<davexunit>it seems made with the express purpose of papering over the packaging problem and enabling proprietary software
<davexunit>not to mention the server components of Snappy have not been released AFAICT
<civodul>"Push their free or paid apps to the Ubuntu Store" argh
<kyamashita>daveunit: Definitely. It reminds me of a Windows app store sort of thing?
<davexunit>civodul: Canonical is just the worst at this point.
<civodul>seems like it
<davexunit>they *have to* know better than to do the "free or paid" thing
<davexunit>they *know* that's confusing in our community
<civodul>all these companies want to become Apple or Google
<civodul>user freedom is a secondary concern at best
<davexunit>kyamashita: yeah. the underlying technology shares many similarities to Guix.
<davexunit>except Guix does it all better and provides many more features.
<kyamashita>Anyone remember bug #1?
<davexunit>the current, worrying trend is that most people now see two layers to their systems: the "base OS", and the "applications"
<davexunit>the base OS is your traditional distro, and your applications are things will use Snappy or Docker or whatever.
<civodul>right, and Canonical, RH, CoreOS, etc. all seem to be going in that direction
<davexunit>I think it's a fundamental flaw to view the two as different in any way.
<davexunit>we know very well through GuixSD that the whole system is connected
<davexunit>and that the very same tools can manage the base system and everything elses that runs on top
<ng0>a virtual system inside the virtual system layer which is your operating system.
<kyamashita>The base OS is made up of applications, though. Most people don't (want to) see that.
<davexunit>and we know that we can pick and choose the level of isolation that we desire for a particular problem.
<davexunit>profiles, 'guix environment', containers, virtual machines, etc.
<davexunit>what is accessible system-wide, what is available for one user, what is available just in a particular temporary shell, ...
<davexunit>I'm ranting at this point, but this stuff really fires me up.
<kyamashita>Understandably so.
<davexunit>we'll just have to keep waiting for people to give us a chance.
<civodul>there's a convergence between those who want to get rid of the distro/upstream split (which i can understand), and those who want to push for an "app bundle" approach, which will turn out to work very well for proprietary "apps"
<bavier>so, I submitted a macro to autoconf-archive, and it got accepted *really* fast:
<civodul>8mn, woow
<civodul>we should take this as an example to follow ;-)
<kyamashita>that *is* fast!
<bavier>a lot to live up to :)
<jlicht>hello guix! I'm currently trying to package a piece of software that has a Makefile that requires hardcoding some variables. Is there any package definition that is already doing this?
<bavier>jlicht: can the variable be passed when make is invoked?
<jlicht>to clarify, there is line that contains eg 'VERSION = (some dynamic stuff)'
<jlicht>bavier: I would say yes, but then I would still need to delete the line that re-sets the value
<bavier>jlicht: oh, I see
<bavier>yes, there's many other packages that use 'substitute*' to overwrite such things
<jlicht>bavier: substitute* seems to fit the bill. It is more versatile than I though :O
<mck>I read some old logs; is the best solution for a cacerts keystore (java) still to use ca-certificates-java deb?
<civodul>rekado may know :-)
<davexunit>jlicht: can you use #:make-flags for this?
<davexunit>or do you really need to edit the Makefile itself?
<kyamashita>I have to leave for now, but here is my definition so far: I know that I'm doing *something* wrong, as the fetch-data phase is non-functional.
<davexunit>sneek: later tell kyamashita you cannot download things in a build phase. you need to make those origin records inputs to the package.
<sneek>Will do.
<davexunit>sneek: later tell kyamashita when the sources are inputs to the build, you can access them via the "inputs" keyboard argument to a custom build phase. there are many existing package recipes that refer to their inputs like this for you to read.
<bavier>jlicht: See section 9.5 in the make manual
<jlicht>bavier: I can figure it out from here, although this was apparently only 1 of what seem to be more and more challenges XD ;-)
<fhmgufs>Some people said that they are running their normal guix from their git checkout.
<fhmgufs>I want to do that, too.
<fhmgufs>I created a symlink from ~/.config/guix/latest to it.
<fhmgufs>How can I actually call it? "guix package -i guix" rebuilds guix from source.
<fhmgufs>I mean "./pre-inst-env guix package -i guix"
<civodul>iyzsong: i'd like to rebase gnome-updates on top of master, fine with you?
<civodul>iyzsong: well, i went ahead, hope that's fine :-)
<mck>rekado: wondering what certificate keystore you've been using with icedtea?
<janneke>phant0mas, civodul: how to best resubmit my cleaned-up mingw cross patches?
<janneke>wine hello.exe runs on top of wip-hurd or on top of master
<janneke>more patches (ncurses, readline, libiconv, guile), to get guile.exe build and link, but guile.exe does not yet run in wine
<bavier>I guess I missed the memo about changelog indentation
<phant0mas>janneke: begin with the patches that are not in cross-base
<phant0mas>meanwhile we must simplify cross-base
***joachifm is now known as Guest31570
***sankey2 is now known as sankey
<davexunit>phant0mas: hack on avr-libc at all?
<phant0mas>davexunit: well I found out that all of the other distros just install the 32 bit glibc, which is dissapointing :/
<davexunit>phant0mas: weird! well I proved that you definitely don't need it!
<kyamashita>I'm back! What's going on?
<sneek>Welcome back kyamashita, you have 2 messages.
<sneek>kyamashita, davexunit says: you cannot download things in a build phase. you need to make those origin records inputs to the package.
<sneek>kyamashita, davexunit says: when the sources are inputs to the build, you can access them via the "inputs" keyboard argument to a custom build phase. there are many existing package recipes that refer to their inputs like this for you to read.
<phant0mas>davexunit: I was thinking that maybe we can create an empty stubs file
<phant0mas>and please avr-libc
<davexunit>it's all because it includes <limits.h>
<phant0mas>and gnu/stubs.h defaults to stubs32.h on any non x86_64 system
<davexunit>that's where I learned that I can just pass -D__x86_64__ and avoid that issue :)
<phant0mas>but what could we do on arm for example?
<davexunit>yeah, that's the problem.
<davexunit>kyamashita: I have a modified version of your package that I'm going to send you
<davexunit>I'm currently seeing if it will download everything correctly
<kyamashita>Oh! Alright.
<davexunit>it won't be complete. you'll still need to do all the data copying stuff.
<davexunit>which will mean extracting each tarball into the data/ directory
<kyamashita>That shouldn't be too much of a problem. I just need to learn the procedures.
<phant0mas>davexunit: I will try to build avr-libc on my raspberry 2 running guix
<phant0mas>maybe then I will think of something
<janneke>phant0mas: thanks, i have only one in gcc -- all others depend on cross-base
<davexunit>currently this recipe doesn't copy the data, nor does the install phase install the game to the right place.
<davexunit>I leave the rest to you.
<janneke>so we'll have to do some more work first i guess
<kyamashita>davexunit: I see what you mean now! :-)
<davexunit>kyamashita: great!
<kyamashita>I really should learn Scheme one of these days. It looks pretty nifty.
<davexunit>it certainly helps in situations like these ;)
<davexunit>phant0mas: okay, good luck.
<davexunit>we are *so* close.
<davexunit>I hope my avr-libc isn't subtley broken from my hack
<davexunit>I need to actually try out some firmware
<davexunit>but I built a whole bunch of firmwares from the KADE project.
<davexunit>every single one built successfully.
<davexunit>kyamashita: I think you need to move DESTDIR out of #:make-flags, because those flags aren't used for 'make install'
<davexunit>you'll probably need to replace the install phase with your own
<bavier>gnu-build-system passes #:make-flags during install
<davexunit>ACTION double checks
<bavier>line 299
<davexunit>bavier: you're correct!
<davexunit>my bad!
<davexunit>I was just reading this code yesterday, too.
<bavier>np, I had to double-check too
<davexunit>okay, so the redeclipse installation fails for some other reason
<kyamashita>davexunit: for some reason my guix installation doesn't like your match-lambda variable
<davexunit>kyamashita: match-lambda is a macro defined in the (ice-9 match) module
<davexunit>so import that in the module you are working in
<davexunit>I meant to mention that but forgot
<kyamashita>Got it.
<davexunit>rekado: if you don't me asking: how did you learn so much about electronics that you were able to build all these neat things for your chapman stick?
<htgoebel>Hi, good evening.
<htgoebel>I do not really understand how to specify build-time-only requirements. As far as I read the manual, all "inputs" are taken equal?!
<bavier>htgoebel: native-inputs
<bavier>htgoebel: see the "'package' Reference" section of the manual
<htgoebel>bavier: This section tells different, at least how I read it: "‘native-inputs’ are built for the architecture of the _build_ machine"
<htgoebel>Hmm, okay, one could read this as "build-time" dependency
<htgoebel>Okay, the paragraph just behind says:
<htgoebel>‘native-inputs’ is typically used to list tools needed at: build time, but not at run time
<civodul>htgoebel: guix-daemon determines the set of run-time dependencies by scanning the result and looking for /gnu/store references
<civodul>where run-time deps are a subset of build-time deps
<davexunit>civodul: this seems to be a frequent source of confusion. people are used to having to be explicit about what the runtime dependencies are
<phant0mas>davexunit: I was thinking, we could move the parts of limits.h used in avr-libc to the avr-libc itself
<phant0mas>and then kill the glibc dependency with fire :-)
<htgoebel>davexunit: ACK. I already had understood that built-time dependencies are inputs plus native-inputs (so I do not need to specify things twice). But the wording in the manual is a bit confusing.
<davexunit>phant0mas: civodul followed up on the mailing list and said it does seem odd that the build is using the host libc
<phant0mas>yes just saw it
<davexunit>but I don't see how it could not use the host libc
<phant0mas>well if it only needs the limits.h header we can cherry pick the part it wants and move to avr/include/limits.h
<phant0mas>I will try it
<davexunit>I feel like there must be something we don't understand
<davexunit>why would the developers do this?
<phant0mas>well if it only uses the declarations from that header, they probably didn't thought about it too much
***ringst_ is now known as ringst
<phant0mas>no glibc binary is actually used
<davexunit>well it's worth a shot then!
<davexunit>phant0mas: from what I saw, there's only one constant it was after
<davexunit>so if we just define that...
<phant0mas>wow adding an extra dependency for just one constant ...
<davexunit>if we replace that include with a proper definition of ULONG_MAX for AVRs we might be good
<davexunit>gotta run now.
<phant0mas>davexunit: look what I find in avr-libc's todo
<phant0mas>Write for avr-libc [3] : stddef.h, sys/types.h, limits.h,
<phant0mas> sys/systemcfg.h?
<phant0mas>haha it seems they saw the error in their ways
<davexunit>phant0mas: so perhaps we could send them a patch even ;)
<phant0mas>it sounds even better :-)
<davexunit>depends on how crazy limits.h is
<davexunit>but for now let's just hack something in ;)
<bavier>strange, hdf5 wrote a ~300 line C code to use during their build process, but I'm pretty sure a ~10 line piece of sh might do the trick