<cynede>buenouanq on distrowatch release model is marked as stable and what you tell sounds alike rolling release model
<cynede>buenouanq so possibly you don't know something about it or information provided about versions is wrong or somehow different from what I expect there...
<buenouanq>maybe that more refers to things aren't available in the official repos until they have been successfully built and work without major issue.
<cynede>buenouanq no, it's still being fine in rolling release, fixed release means some stable core (for example gcc and kernel) or even bigger core (alike in FreeBSD) and packages depending on that core, and complicated model for updating that core :)
<cynede>buenouanq possibly in guix terms core == package manager version but I just want to be sure
<buenouanq>I just lurk here though - You should stick around and talk to actual devs.
<cynede>buenouanq terms are created to make people to understand some workflows, when you mark release model as fixed and actually calling it 0.12 beta you either confuse people or mean something seriously...
<cynede>buenouanq I don't know what do you mean by "meta OS" either
<lfam>cynede: Most packages are updated on our Git master branch. The default method of keeping one's Guix package up to date pulls from that master branch. But due to the functional packaging model, core packages are updated only every couple months, except for security fixes.
<buenouanq>What I see them doing is building a framework from which you then build an OS.
<buenouanq>Debian offers a product - GuixSD offers a process.
<EvilPython>How to install packages for all users in GuixSD?
<lfam>As buenouanq points out, users can easily alter the packages provided by Guix for themselves
<buenouanq>EvilPython: decaled in your os config or individually one by one
<cynede>buenouanq sounds confusing, is there distribution based on that framework?
<cynede>buenouanq I think it's normal for user not to like suffering XD
<buenouanq>categorical GNU hate/maginalization is just dumb
<lfam>EvilPython: Please read the manual, section 'GNU Distribution'. That's where GuixSD is documented :) In short, add the daemon's Shepherd service to your OS declaration and reconfigure your system
<cynede>buenouanq I don't tell hate or stuff alike that, I tell that I don't like suffering
<cynede>buenouanq because I don't want to play my favorite game on nouveau :S
<buenouanq>Freedom is more important than capability, comfort, and convenience.
<cynede>lfam so far guix packages looks very very hard
<lfam>cynede: Some programs are very complicated to build, but some follow a standard procedure, and those are very easy to package. For example, take a look at the package for python-argcomplete in gnu/packages/python.scm
<lfam>It follows the standard method of building Python programs, and it has no dependencies besides Python itself. We've abstracted several standard build systems. This package uses python-build-system.
<lfam>You can compare it to the manual, section 'Defining Packages' to get an idea of what's going on
<cynede>lfam I wonder where you get all the menpower to make those bumps, all the packages are very up to date, last gnome, ghc 8.0.2, etc...
<lfam>There are a few dozen of us. I'm sure you can find some old packages if you try ;)
<cynede>lfam where are? there are only 150 people and distribution is young (afaik) I think even nix versions are older
<buenouanq>I would like to help package things, but I've found the manual somewhat lacking - What else might I read?
<lfam>Is there anything in particular you think is missing? We want the manual to be the go-to reference
<lfam>I started by thinking of a program that seemed simple, that I knew how to test, and that was unpackaged. Then, I tried to copy and adapt an existing package definition for this program. I got stuck and asked for help, and I've been here since :)
<cynede>lfam oh if I understand right one scm package can actually define several packages? :)
<lfam>cynede: Yes, the .scm package modules tend to contain multiple packages which are grouped by a theme. This is a popular bike shed to re-paint
<cynede>lfam, I see that's why some package were looking so monstrous, it's was meta one
<lfam>Sometimes the themes stop making sense and then we have fun deciding how to recategorize them
<jonsger>cynede: updating a package in guix seems to be pretty easy, just update the git commit hash and rebuild :)
<lfam>Yeah, jonsger +1! And it's valuable, too, assuming you test the update and then send a patch
<cynede>lfam, jonsger I hope you also need ensure that deps are not changed
<lfam>That's part of what I mean by test the update
<lfam>You build the new version of the package and do some test of the functionality. Ideally the packaged software has a good test suite, too
<cynede>lfam, jonsger sometimes if you have newer version it will be building for you but will be broken for guy with older version, it's not just test, it's reading configure files changelog
<jonsger>cynede: sure, but guix can hold more than one version of a library or dependency
<lfam>cynede: With Guix, packages always refer to the precise version of the dependency graph they were built with, all the way down to the compilers
<lfam>The problem you mention doesn't exist for Guix
<lfam>This is the core innovation of the functional packaging model
<cynede>lfam how do you update that package then, which has many other packages depending on that package
<cynede>lfam e.g. when you want to update gtk+ you must update anything depending on gtk+ ?
<lfam>The "many other packages" are rebuilt with the new dependency graph. It can be computationally expensive, as you mention. If updating a package will cause more than a few hundred packages to be rebuilt, we don't push the update directly to the master branch, but instead batch these expensive updates together and rebuild on the scale of weeks
<lfam>cynede: It's not impossible at all, but the user will probably have to build their own binaries
<cynede>lfam yes, let tell user updated gtk+ 3.22.6 into 3.22.7, all his gnome packages is depending on 3.22.6 - what user will do to not break it?
<lfam>If somebody wanted to update gtk+ on their own machine, then they'd need to rebuild any program that depends on gtk+ that they wanted to use
<lfam>Or, they could try only rebuilding certain gtk+ dependent programs, while continuing to use others that still referred to the earlier version.
<cynede>lfam why rebuild? abi is not broken, it's dynamically linked?
<lfam>We can "cheat" when there is no ABI breakage, and we do it for security updates to core packages.
<cynede>lfam also, should he edit manually all those depending scm packages to set 3.22.7 there?
<lfam>No, most packages don't specify the version of their dependencies, so there
<lfam>so there's no need to edit all the package definitions
<cynede>lfam, but you tell packages always refer to the precise version of the dependency graph
<cynede>lfam, so either that or previous problem is still present
<lfam>Version numbers are imprecise. The "precise version" we use is the SHA256 hash of all the inputs to the build process of a particular program. This includes all the transitive dependencies, all the way down to the bootstrap compiler.
<lfam>I recommend reading the paper that introduced the functional packaging model, "Nix: A Safe and Policy-Free System for Software Deployment", by Eelco Dolstra, Merijn de Jonge, and Eelco Visser. This paper concisely explains the model we are using.
<cynede>lfam not sure if I understood... you've updated some gedit from version 2 to 3, u have gtk 3 installed, it works for you, user have gtk 2 installed and if version numbers are imprecise he will fail to build it
<efraim>qt question, does anyone know if its ok to update the qt modules piecemeal? with the tests enabled its much more work than just updating the hashes :)
<thomasd>efraim: you mean whether different modules from different qt releases are compatible, or you need to update them all at the same time? (I'm afraid I don't know, but would be interested, too ;-) )
<thomasd>would there be an opportunity to do some keysigning at FOSDEM this weekend? (apart from the official keysigning event, which takes place during the Guile/Guix track)
<thomasd`>by the way I seem to fail at submitting to firstname.lastname@example.org. Do you have to register in order to send messages, or is there some procedure?
<thomasd`>mabe a good time to repeat my question :) Do you have to register in order to send messages, or is there some procedure? I've tried to send a bug report twice, but don't see anything appear on the list.
<dadinn>couple of questions: 1) Is there a recommended amount for the number of build users on a single server? 2) The manual is quite terse on manually setting up an init script for guix-daemon (in case no systemd, or upstart)... I suppose I should just Google how to write a simple init script?
<efraim>I dont think there's anything special to do to get the bug message delivered, maybe if there's a large attachment or if it gets flagged as a new sender
<thomasd`>I was a new sender and did attach my system.scm config (not that it's a big file).
<efraim>The manual suggests 10 build-users, with thr number of simultaneous builds being set by flags on the guix-daemon or the like
<efraim>'Large files' in this case is only like 2mb
<efraim>It should get cleared eventually, I dont know who to poke about getting it to move faster though
<jmi2k>jmi2k: as I'm not an expert user, the difference is not so huge, but there are some benefits like the asynchronous plugin API that avoids delays. I just wanted to wait until installing neovim because I didn't want to move my config. Also, I'm interested in trying things like this: https://github.com/extr0py/oni
<rekado_>the artwork derives from the original sources, though, and the license there is unclear.
<rekado_>“unclear” because the author refuses to clarify
<rekado_>I think the problem there is that there is no explicit grant to permit verbatim copying.
<rekado_>“Data that isn't functional, that doesn't do a practical job, is more of an adornment to the system's software than a part of it. Thus, we don't insist on the free license criteria for non-functional data. It can be included in a free system distribution as long as its license gives you permission to copy and redistribute, both for commercial and non-commercial purposes.”
<ng0>hm.. if I really have problems unbundling something, that's a reason to keep the bundle, until it can be fixed, right? I'm trying to get cadaver to build with the system neo. other systems make it look so easy, but it doesn't work for my attempts
<rekado_>ng0: there is no rule either way. It depends, but in principle it can be said that bundling can be acceptable in some circumstances.
<rekado_>if other free distributions unbundled then it’s a strong indicator that bundling would not be acceptable for us.