<gazoombo>is there a simple way to install a package not included in the gnu packages source tree? I may be overlooking something obvious. <gazoombo>if I have, for example, ~/my_private_package.scm <mark_weaver>why not put it in the expected namespace? there are ways around that but it seems easiest to put packages where the standard guix ui expects them to be, namely (gnu packages ...) <mark_weaver>note that you can do so without putting it in the same directory as the standard guix packages <mark_weaver>all you need to do is to put it in $SOME_DIR/gnu/packages/my-private-package.scm <mark_weaver>whre $SOME_DIR is one of the components in your GUILE_LOAD_PATH <mark_weaver>and make sure that my-private-package.scm begins with (define-module (gnu packages my-private-package) ...) <mark_weaver>(the filename, with .scm stripped, should match the last component of the module name) <gazoombo>that will probably work to test this, but I'd like to start a small personal repo of package definitions for non-GNU tools, custom config, etc. <gazoombo>there was some discussion a while back on the mailing list about "Overlays", but I'm not sure where that landed <mark_weaver>I'm sorry, I was mistaken. It turns out that there can be only one gnu/packages/ directory. <mark_weaver>I guess one obvious way to tweak guix is to make a branch in git, and then you can periodically merge from the master branch. <mark_weaver>maybe civodul, Steap, or viric has a better answer for you. I haven't yet studied Guix in depth. <mark_weaver>I confess I don't know much about overlays. do you think they are superior to branches in git? <mark_weaver>well, I can see one limitation of branches: they are not easily composed. <mark_weaver>civodul: what do you think of making the list of directories where (package-files) looks be extensible by the user? <mark_weaver>i.e. allowing more than one directory tree to be searched. <mark_weaver>currently, it seems that (package-files) searches only a single directory: %distro-module-directory, where packages.scm was found (as a sibling). <mark_weaver>fwiw, I'm not even convinced this would be a good idea. <civodul>mark_weaver: yes, that's a good idea <civodul>actually, the single directory thing was always just a hack ;-) <gazoombo>It's very late here, so I won't be up much longer, but this is encouraging to hear. <civodul>the real thing is to allow users to drop (gnu packages xxx) in their %load-path, and have the commands pick it up <mark_weaver>do you have any thoughts on how best to implement something analogous to overlays from some other source-based distros. <civodul>mark_weaver: there was a thread recently on this topic <civodul>basically, the only missing piece is what you mention (allowing fold-packages to look in user dirs) <mark_weaver>civodul: yeah, that part seems obvious, but some people have misgivings about naming modules (gnu packages xxx) if it's not considered part of the gnu operating system. <civodul>so we could allow other names too, somehow <civodul>not difficult, we just need to agree on mechanisms and conventions *civodul goes grab coffee <viric>civodul: the writer of ugarit got into #nixos, did you know? <youlysses>We could just shorten all the expressions, modules, or what be-it as "3p" (3rd party) or the like, right? <gazoombo>it would be nice if other paths and packages were even on an equal plane with the gnu packages as far as guix was concerned <youlysses>*That aren't a part of the upstream GNU project. <mark_weaver>gazoombo: what do you mean by "equal plane", concretely? <gazoombo>I've talked with Max, the creator of Homebrew about their "tap" feature, and one thing he's said he wishes he could go back and do is to implement the main repository that way from the start <gazoombo>mark_weaver: it depends on how things are implemented <gazoombo>I'm drawing heavily on my experience with homebrew (and lack of experience with guix/Nix so far) <gazoombo>but with homebrew, all of the package definitions are kept in a git repo, and then you can add additional repos as "taps" <ArneBab_>civodul: I cannot install mercurial with guix package -i mercurial ; I did guix pull, is there somethingn else I need to do? <youlysses>Are there any really big packages we're missing in Guix, in-terms of networking? I started network.scm and right now I got libnl working fully, and wpa_supplicant is almost done. <youlysses>I'd suspect, there's probably a fair amount. :^P <mark_weaver>gazoombo: how do you specify the other taps? the taps are independent git repos from possibly independent sources? <ArneBab_>mark_weaver: that’s what Gentoo does - but with multiple ways of getting them (rsync, svn, git, mercurial, bzr, …) <mark_weaver>well, it's easy enough for us to do something similar. <gazoombo>mark_weaver: yes. taps are independent git repos from possibly independent sources. There's a convention to specifying them by github user/projectname <gazoombo>mark_weaver: but now there's a plugin that allows for taps from arbitrary git repos <mark_weaver>glad to hear it. being tied to one particular git repo site is bad policy. <gazoombo>I think the problem with the distinction between the main homebrew package repo and all of the taps is that the main repo can shadow things from the taps <gazoombo>yes, being able to specify arbitrary repos also makes it possible to use private repos (e.g. internal to an organization) <gazoombo>I may be incorrect about shadowing being the reason Max wanted to move the main repo to a tap. I'll see if I can find out more. <ArneBab_>In Gentoo it is the other way round: overlays win over the main repo <gazoombo>But it's the kind of thing that pays to get right early on because it's a pain to sort out once you have a large userbase <gazoombo>Apparently one reason is because it would help them keep issues and updates to homebrew core separate from issues and updates to the formulae (package definitions) <ArneBab_>civodul: I saw it, but I missed your question… <civodul>gazoombo: here we have a full programming language, so we can pass package definitions around, like normal objects <civodul>the only question is how to provide more flexibility at the UI level <ArneBab_>civodul: the testsuite is run with nose - cd tests/ <civodul>ArneBab_: could you adjust the recipe accordingly, and reply to the message? :-) <youlysses>Okay, some factor of completeness for ethtool, dhcpcd, libnl, and wpa_supplicant -- with net-tools and wireless_tools on the way (eventually) ... though I'm probably going to end-up passing out in a few. <gazoombo>civodul: based on my experience with homebrew, I'd really like to be able to have guix check out a repo and add it to guix's module-directory path automatically <ArneBab_>civodul: do you really want to run all the tests? 1h install time is quite heavy… <gazoombo>civodul: it looks like all of the gnu packages are currently in the main guix repo - do you think it makes sense to move that out into a separate repo? <civodul>ArneBab_: and yes, we run all the tests; usually people will arrange to use pre-built binaries when in a hurry <ArneBab_>(meaning I will have to first package nose to enable running the tests) <civodul>gazoombo: i don't think so; it's good that we can change the API and the package definitions in a single commit <civodul>ArneBab_: alternately, to get a better feeling of achievement, you can post the Mercurial patch with a comment saying "FIXME: tests disabled until nose is available" <civodul>youlysses: net-tools is already packaged, BTW <ArneBab_>civodul: ok - I’ll try to get at it when I’m home <youlysses>civodul: Are inetutils and net-tools the same then, I assume? <youlysses>civodul: Okay, I have more looking into and cleaning of this module anyways -- just thought I'd mention it here to feel pressured to get it done sooner than later. :^) Well as soon as I can; starting tomorrow, my week is going to be very busy so it might be able to get to by the weekend, but no promises. I still need to figure out why this box won't recognize any packages I try to build -- but that's a question for another <youlysses>I also need to still look deeper into kbd; it was yielding weird errors with guile-config -- iirc. My top priority in-terms of packaging, is stuff still missing for the upstream distro, which luckily doesn't seem like that much. <youlysses>Okay all, I'm going to try and get some sleep. I may or may-not be back in an hour, possibly (and hopefully...) much more. Peace people; AFK. <viric>civodul: you are better at marketing than Delft ;) <civodul>though i'm not as good at making fancy web sites <viric>you target a more specific public, with the kind of sites they like: the gnu fans <civodul>i'm not sure if the "gnu fans" is a large category, nor if examiner.com falls into that category ;-) <viric>I don't think it's a large category, but enough for them to echo to a broader audience <viric>well, you also have gnu endorsement. That rises your product up :) <Steap>What exactly is examiner.com ? There are news about both GNU and Scarlett Johansson there. I'm not complaining, but I'm having a hard time understanding what the site is all about <viric>but I can very well imagine people interested both in GNU and Scarlett Johansson <viric>civodul: who is the copyright owner of guix? <viric>I don't know at all how gnu endorsment works. :) <poppush>viric: gnu doesn't require contributors to assign copyrights <poppush>it's possible, but it's not a requirement <poppush>if the project decided to assign copyrights, then you'll probably have to do that <viric>do you mean that you can have gnu endorsment, without assigning copyright to gnu <poppush>guix doesn't require contributors to assign copyrights to gnu <viric>well, "if the project decided to assign copyrights to gnu", you mean, "if the author gave the copyright to gnu", right? <poppush>the above should have said "to the fsf" instead of "to gnu" <viric>how can 'the project' decide anything? <poppush>guile requires contributors to assign copyrights to the fsf <viric>and who takes that decision? <viric>does it mean that the maintainer refuses to hold the copyright? <poppush>I don't like the word "refuses" but yeah <poppush>so you basically say: "from now on the fsf is the copyright holder" <viric>then, all next decisions on the project can only be done by the fsf <poppush>the fsf has "the legal power" to do anything but they promise not to make your program proprietary, for instance <poppush>iiuc, the main reason why assignments exist is to simplify fighting violations in courts. <poppush>because it's easier when a single entity holds the copyright <viric>I understand, but a project could require that contributors refuse their copyright on the patches, giving all copyright to the maintainer, not fsf. <poppush>the fsf is a non-profit with a clear goal <poppush>that promise not to proprietarize the program <viric>so the transmission of copyright to fsf is subject to a contract: not breaking the promise. <viric>does such contract exist, at the time of transferring copyright? <ArneBab_>viric: IIRC actually it’s written in that copyright transfer that the FSF does not make the program unfree. <ArneBab_>viric: so in case they do, they break the contract <ArneBab_>viric: yepp: You actually send them papers (I did that for the Hurd) <viric>so it's similar to a writer/publisher relationship <ArneBab_>with much stronger restrictions to the FSF, I think. <ArneBab_>The FSF makes it so that you do not need to trust them completely. <viric>does the FSF accept a copyright transfer for any software? <viric>how a software becomes part of gnu? <viric>as I don't know all that, it's normal that I never considered proposing something to gnu <poppush>viric: you said that it should be easy to find the N64-realted kernel option, but I'm failing to find it. any pointers? <viric>I remember seeing something about that, but I'm sure I never tried that option. I never tried n64. <civodul>viric: so no, we don't do copyright assignment <civodul>the requirements are minimal (way too minimal IMO) <viric>I don't understand clearly "do copyright assignment" still. <viric>so, in the predicate "doing coyright assignment", who is the subject? civodul said 'we'. And it also looks like a continuous tense, instead of perfect tense. <viric>as something you have to do regularly <viric>Before that, I understood only two possibilities: "the maintainer decided to give the copyright to FSF", or "did not decide that". <viric>ah, plus "contributors keep copyright of their patches, or they lose the copyright, once contributed" <viric>What does the "copyright assignment" expression map to, of what I said? <viric>maybe I should read the links, to use common terms :) <poppush>it's always better to read before asking questions, he-he <viric>for 'assigning.html', it looks like civodul should have used perfect tense. "We decided not to assign the copyright to FSF". instead of "we don't do assignments. <viric>the assignment is something done *once*, isn't it? <viric>ok. then civodul should use some perfect tense, related to the decision time. <civodul>what i mean is that anyone can send code, with emself as the copyright holder, and we can put that in <civodul>the only requirement is for it to be GPLv3+ <viric>civodul: picky because I think I have great troubles understanding all that about assignment. I don't mean to annoy. :) <viric>civodul: ok, so you list all contributors as copyright holders. <viric>and if you wanted to assign the copyright to the FSF, now you'd need the ack from all holders <civodul>but i don't see any reason to do that <civodul>i didn't want to assign copyright to the FSF, because doing the paperwork is a significant barrier to entry <civodul>whereas packaging tasks typically require little investment in time <viric>ah, every next contributor would have to do the paperwork? <viric>I remember a discussion in fossil... <civodul>i mean contributors in general would do it just once <civodul>and that's really comfortable for this kind of project <viric>a point of view of bsd vs gpl. If you have some time to comment if you think it's correct, it'd be great <civodul>woow, that message is very confusing <civodul>misplaced uses of "have to" for instance <civodul>the "precondition for reading the code" is completely wrong <civodul>either that person doesn't understand anything, or they're trying to trick contributors into following their policy <viric>yes, I'd like to narrow that down <civodul>they could just require people to submit files with the right license header, and that's it <viric>I had to do paperwork to be able to contribute to fossil :) <viric>civodul: does every file have a different copyright holder, in headers? <viric>and how is the copyright of the patches to the files handled? <civodul>if the change is "legally significant" (more than, say, 5 lines), then the submitter may/should add their name as a copyright holder <viric>and who judges that? the same contributor? <viric>Who takes the decision to add or not to add the name? <viric>Have you had such additions in any checkin? <civodul>BTW, that's what any project should be doing <civodul>any project should be keeping track of the various copyright holders <viric>I wanted to see an example, simply <viric>unless there is a contract about copyright assignment with every author. <viric>(thank you a lot for your time on this. I had a mess in my head about that :) <civodul>the copyright lines are here just to reflect reality about copyright holders <poppush`>civodul: regarding copyrights: I think the manual should have three copyright ... lines instead of a single line (like now). For instance, I wasn't contributing to the manual in 2012. ***poppush` is now known as poppush
<viric>the #go-nuts channel has fun discussions often about GPL/BSD. <viric>there are extremists of both sides :) <Steap>That has been going on for like... 30 years ? <viric>well, #guix does not have much battles of GPL vs BSD. There are arenas more inclinated to that <poppush>n64 mips binaries status: I switched to JFS and trying to build hello <mark_weaver>poppush: please let me know how it goes. I'm skeptical that the problem we had has anything to do with the ext3 problem, since I see the same problem on my system, and yet everything works properly outside of guix-daemon (including both N32 and N64 binaries). <poppush>currently it's just fetching the needed tarballs <mark_weaver>civodul: I think we should be passing --enable-__cxa_atexit to gcc's configure. <mark_weaver>and on mips, we'll probably want --with-mips-plt as well. <mark_weaver>unfortunately, several of the defaults are meant for running on non-GNU systems, e.g. without glibc. <civodul>mark_weaver: you can add these flags to gcc.scm, under 'gcc-configure-flags-for-triplet' <mark_weaver>*nod*, but I think that --enable-__cxa_atexit makes sense for any target where glibc is the C library. <civodul>i trust the glibc hackers to choose the right defaults <mark_weaver>the problem is that gcc configure defaults seem to assume that you might not be using glibc or GNU binutils. <mark_weaver>if you *can* assume GNU binutils and glibc, then it makes sense to pass some additional configure flags. <civodul>if you have more details on what erroneous choices GCC's configure makes, i'm interested <mark_weaver>I'm not sure I'd call them "erroneous". It's just that GCC has a long history of being installed on non-GNU platforms, and so traditionally the defaults are chosen based on that. <mark_weaver>as you know, the "GNU platform" didn't even exist when GCC was written and became popular. <civodul>yeah, i mean "erroneous for our uses" <serhart>is it viable trying to build on osx? <poppush>with the same error as far as I can tell <mark_weaver>poppush: thanks for letting me know. I'm not surprised. <poppush>so should I try anything else now? viric suggested to enable some kernel option, but it doesn't seem to be the cause <mark_weaver>I'm going to try building for N32 (which I think is a better choice anyway) after I figure out the right configure flags to pass to binutils/gcc/glibc <mark_weaver>part of the problem is that 'strace' doesn't work very well on N64 binaries, so that will make it harder to figure out what's going on. <mark_weaver>I know what flags I used on my home-grown system, but I should find out which of those flags I can safely omit, since in Guix we want to stick to defaults wherever reasonable. <poppush>civodul: have you talked to andreas regarding n64 vs. n32 issue? <mark_weaver>civodul suggested that I do that, and I intend to, but first I want to get the build started :) <poppush>mark_weaver: could you discuss it on the list please? I'd like to read about pros and cons. <mark_weaver>fwiw, the only "con" I know of is that with N32, the virtual address space of a process is limited to 2 gibibytes. <viric>and currently we have mainly 1GB systems, no? <mark_weaver>right. apparently the yeeloong 8101B only supports up to 2GB of RAM. <mark_weaver>the newer yeeloong 8133 (which needs a blob for the accelerated video) supports up to 4GB. <civodul>poppush: yes, we met for lunch, and i prepared him ;-) <viric>civodul: I hope andreas erased my private data of the fuloong :) <mark_weaver>note that N32 assumes you have a 64-bit processor, uses 64-bit registers, and requires that linux (the kernel) be compiled with 64-bit pointers. <mark_weaver>it's just that pointers and int/long are 32-bits, to save memory. <viric>mark_weaver: and long long are handled with 64-bit instructions, right? <mark_weaver>N32 is somewhat analogous to the x32 ABI that's gaining traction in the intel world. <mark_weaver>so N32 can support more than 4GB is physical RAM, since the kernel uses 64-bit pointers. it's just that each N32 process is limited to a 32-bit address space. <mark_weaver>that's the real win of 32-bit pointers: it effectively doubles the data cache size for pointer-heavy programs. <viric>mark_weaver: I used for some time NixOS with a 64-bit kernel, and MOST userspace being 32-bit. <viric>for better RAM/cache experience <viric>but with the option to have some 64-bit programs. <viric>no, then I got lazier, and didn't finally push upstream support for such pair: 64-bit kernel with most userspace 32-bit. <mark_weaver>the problem with the i686 ABI, btw, is that is usually means you're compiling code that could run in a 686, which means that you can't use 64-bit registers, or the much larger register file, or SSE.. which means you pay a heavy cost for that. <mark_weaver>using x32 (or N32 for MIPS) allows you to get the benefits of 32-bit pointers without paying the cost of avoiding 64-bit features. ***ae is now known as Guest60435
<Guest60435>Here is the outcome of compiling gmp on n32 mode: <Guest60435>So the basic word size for gmp multiprecision is 8 bytes, implemented as lunsigned ong long int. <Guest60435>Well, it means that pari-gp will not compile, if I understand this correctly: <viric>I imagine n64 may have bugs due to so few people using it <mark_weaver>I just finished building N32 bootstrap tarballs with Loongson 2F workarounds. <mark_weaver>now trying to use them to bootstrap Guix on my Yeeloong <mark_weaver>well, I ran into the same problem as on N64, but at least now I'll be able to run strace on it! <Guest60435>I thought these were the MHz of the processor, but apparently not. <Guest60435>Which is better than an older Atom and ARM Cortex A9 according to