<civodul>davexunit: if not you should email them right now because there's only a few hours left
<ng_>logs are only bad if they are kept for an indefinity amount of time, running a server you need them for a short time to interfere if something happens. that said, I don't follow that myself, but it's reasonable to have it just in one place for minimizing the logs.
<jmarciano>ng_: by linking to foreign image, one is giving information as in this case to Canonical Ltd, a company not so friendly to free software.
<jmarciano>do we have in GuixSD some "stability" principles? Like Debian is conveying "stable version", "development", etc. I have got a feeling that packages are upgraded too frequently, and I can imagine interruptions in future. I like stability.
<davexunit>jmarciano: we're in beta, so no, not right now.
<ng_>civodul: in case hydra finally ends up on its own server, and the disk might be bigger, would you consider 25GB enough (I plan for 50 for the beginning including system and my own (low trafficed) services) or should I just watch and be flexible?
<ng_>waiting to send out the new contract request/question, that's why I'm asking. initial 50GB would include ~3GB base system, maybe 10GB at max my own services, and the rest cache, open to scale up.
<lfam>I would make it as large as possible. It's useful to cache things for (at least) months.
<lfam>For example, new users who are using the 0.9.0 installer could benefit from cached substitutes of that release. Although by making it annoying for them, it does give seem to motivate some to complain until we recommend `guix pull` ;)
<ng_>currently I could go for 100GB, above that I would need to calculate. So 12GB is currently all the packages which are build in one cycle before it gets cleared? I can't get like 600GB, i would need another isp for that, prices are just to high for that with this one and for bigger sizes I prefer to bring my own dedicated server later with guixsd. I trust in-berlin from their history, support and how they are
<lfam>The thing with provided substitutes for 0.9.0... it might be a feature to drop substitutes that far back. As soon as those users start web browsing, or using DNS, they are probably going to be attacked via fixed bugs in OpenSSL and glibc
<ng_>if only that one friend wasn't at ovh.. would be perfect for a cache
<ng_>i had doubts about them and no comments from other people so far other than one friend in france who told me they are way too friendly to law enforcement agencies, but the subcompany in question (kimsufi) sells "dedicated" servers for 15 euro/month .. i just have a funny feeling about it.
<ng_>also, I would use iceland for offshore hosting, but like all the locations I like it would be way above my budget with the requirements I have with the friendly company. looking directly at DCs there's whatevertheirnamewas.. thor something they were once called, starting at ~150€/month but also capped for dedicated server. I ran into these "too expensive for reasonable business" problems with OpenNIC last
<davexunit>"Beware, this may be somewhat of a flame, but honestly right now I am quite a bit fed up with "either you support the new web app developers way of doing things or you will become obsolete except for running containers" argumentation crap."
<davexunit>the main thing I want to use it for is dumping ssh public keys into home directories
<lfam>I read some of the upthread discussion, and linked discussions. Owncloud even offered to pay for Debian developers travel expenses to come to their meeting and discuss these issues. That's a real olive branch if you ask me
<paroneayea>yes, I have some empathy with people on all sides of the debian/ownclowd thing
<paroneayea>I understand why the OwnCloud people feel like they can't trust Debian to move fast enough to keep things updated (and currently, if you install OwnCloud from Debian, it's old enough to have a vulnerability backdoor in it)
<paroneayea>I also understand how Debian folks feel frustrated by being basically kicked around by some of the comments made by OwnCloud stuff
<davexunit>with kexec, we could probably even do kernel upgrades
<davexunit>my current test of shepherd's readiness for production systems is to see if it can receive a new nginx service, one that uses a new nginx binary and config file, and can do a web server upgrade with 0 downtime
<davexunit>nginx itself can do this, so it's matter of making shepherd smart enough to trigger it when appropriate.
<davexunit>or rather, giving shepherd the means for us to write an nginx service that can do this specialized restart
<lfam>davexunit: Regarding the new binary, is that also covered by `nginx -s reload`?
<jmd>In GuixSD, confstr(_CS_PATH, ... doesn't return the correct value
<lfam>jmd: Can you send a report to firstname.lastname@example.org?
<lfam>I wonder if `loginctl enable-linger` works with elogind
<jmarciano>let's say, I wish to distribute with guix package manager, postgresql, some software, plus the data. Is it possible to "package the data", like database with it? As only that way, I could tell to someone, please install my-software.scm and he would get the data included?
<rain1>I think you can have a package that simply copies data into the /gnu/store
<jmarciano>there are many applications waiting to be downloaded, and quickly run with Guix, so people will tend to do it by single mouse click later
<rain1>maybe guix could install a tool that makes installing these extra things easy
<rain1>then its 2 things you have to do.. but as long as they are both easy its not too bad
<jmarciano>Yes. And I am pushing some ISPs to offer GuixSD. Now I wonder about security. If I let ISP install GuixSD for me, is there way that I check for integrity of daemon and all software installed?
<paroneayea>mark_weaver: I wonder how long it'll be till we have an iceweasel fix :(
<ng0>I have a question. My theory is that this is true: If I write a setup.py and contribute it to a project because I want to make an "easier" install in Guix and elsewhere, I feed the "one packagemanager per language" thing. : I already figured out how I could be just faster in writing a Guix package rather than the ~60 lines of setup.py I already have.
<lfam>paroneayea: AFAICT, this bug was disclosed last August, and it was patched in mozilla-esr last April.
<lfam>kei_: I'm not exactly sure how Guile works under the hood. But I think that the .scm file is "just" source code, which must be compiled by Guile into the .go executable. I think that if you don't run `make`, that compilation happens anyways, but the results are not stored on disk.
<lfam>To clarify, the compilation would happen anyways when you actually try to do something with the package, such as build or install it.
<lfam>Happy to be corrected by somebody that knows more :)
<ajgrf>lfam: kei_: i think he's just asking for the guix command line. which would be either `guix build -f file.scm` or `guix build my-package`, depending on how he defined his package
<lfam>Oh, I misread the question as "Why is it necessary to build a package ..."
<mark_weaver>kei_: xinit/startx doesn't work on Guix. you need to use (slim-service) instead
<kei_>Okay, so how can I access WindowMaker from slim?
<mark_weaver>just add (slim-service) to your 'services' field and 'windowmaker' to the 'packages' field.
<mark_weaver>I don't see any utility to adding xorg-server to a user profile
<mark_weaver>in theory, xinit/startx could be made to work on Guix, but it's not trivial and no one has been motivated to do that work.
<kei_>Neither did I. I'm very much a newbie as far as Guile and Guix goes.
<mark_weaver>for one thing, slim-service takes care of crafting a suitable xorg configuration file, which is surely needed to deal with all the non-standard filesystem locations for things like fonts and X drivers. also, some things would need to be made into setuid programs.
<jmarciano>hmm, I have my $INFOPATH correct, I see guile.info.gz inside, but info guile gives me only "Guile config".