<Digit>someone reminded me of clfswm earlier. it's got some stump code in it iirc. i see from guix package -s clfswm, it's not there yet. ^_^ only a matter of time before more lisp fans find it. ;) <ng0>is it x11 or has it wayland/xwayland compability? <ng0> /me starts packaging supercollider now <ng0>wasn't there a discussion about qtwebkit going on? supercollider needs it too <ng0>or am I thinking about the wrong qt thing which was discussed? <lfam>Recently we discussed qtwebengine. I don't think we came to a conclusion. I don't know what the relationship is between qtwebengine and qtwebkit <ng0>there's probably none <ng0>why does everyone create their own pakcage management system.... supercollider created one for their optional extensions.. i hope the manager is optional to install the extensions <lfam>They do it because so far there hasn't been another good option <ng0>yeah. I can understand the motivation.. <ng0>I talked with someone at the hackerspace I go to.. it's unfortunate that they decided to not publish their sources yet (moving around code) because I think it's a nice project and they need people to work on the code.. though they should tranlate their website :) <ng0>if someone knows how to read german: http://www.happyhydro.org/ otherwise I think you can contact them directly via email. site is a bit broken too and lacks the presentations and talks they gave etc <ng0>is qtpositioning part of qtcore? <lfam>Interesting that I don't need to include python-pytest in the borg package definition if I want to invoke pytest... I guess it's propagated by something <lfam>Possible bug: on my very slow machine, running `sudo -i guix pull && guix pull` builds Guix twice even though there have not been any commits in between <lfam>I don't see this on my other machines, and I don't remember seeing this issue before <lfam>And I was wrong about borg and pytest. I do need to explicitly include pytest in the borg package definition. I think I was seeing some .go caching issues <OrangeShark>is the `cp` command in the build environment different from the regular version? <lfam>OrangeShark: I think it should be the `cp` from the coreutils package. Why? <OrangeShark>lfam: trying to fix artanis package and for some reason it not properly copying <OrangeShark>for example `cp -frd -P ./pages /gnu/store/0b7zlh5sv44asllrwk21ifff3lpj7vnl-artanis-0.1.2/etc/artanis/` <OrangeShark>this should copy the pages directory into etc/artanis/ <OrangeShark>but it copies the actual contents of pages into etc/artanis <lfam>I recommend using the (copy-recursively) Scheme procedure, which is defined in (guix build utils). We'll ask you to do that anyways if you submit your changes using `cp`. <OrangeShark>lfam: this is part of artanis's makefile when make install is done <lfam>You are patching the Makefile? <OrangeShark>I was fixing the paths, it was duplicating the out path <lfam>Yes, I remember the earlier discussion <lfam>I remember recent dicussion about the output directory being nested into itself in a broken way <lfam>I don't remember who was talking about it <lfam>Can you share a link to the Makefile? <lfam>Or is it just the Makefile in the current Artanis package? <lfam>If so, I can use Guix to get the source <lfam>I guess the Makefile is generated at build time <OrangeShark>the cp command used in the makefile looks fine though. It like if it used `cp -r ./pages/* /gnu/store/hash-artanis-0.1.2/etc/artanis/` <lfam>OrangeShark: I'm not sure why that is happening. I assume you noticed the cause of the nesting issue is that our package definition sets DESTDIR=out? <lfam>I don't think that should be necessary, especially since the generated Makefile has the correct value for PREFICX <OrangeShark>it later does $(PREFIX)/$(DESTDIR) which causes the nesting issue <lfam>Yeah, it does look right, which is why this confusing. <lfam>I'm not an Autotools expert, so my guess is as good as yours, really <OrangeShark>I think I will try using artanis from git, they properly use PREFIX <lfam>As a non-expert, I'm confused by the Makefile's install target. But I don't know if there is something wrong with the target or if I just don't understand it <lfam>It installs the pages into DESTDIR/..., but does it ever copy them into PREFIX? <lfam>It seems to be missing the step where the contents of DESTDIR are installed <lfam>Yeah, and then the whole things goes awry when $(CP) $(BIN)/art $(DESTDIR)/$(PREFIX)/bin/ <lfam>Hopefully this is all worked out in the latest Git revision. <lfam>For us that's fine. DESTDIR seems more important in distros that mutate /usr <lfam>I really don't know why that `cp` invocation is behaving as you described <lfam>But I'm not familiar with -f -d or -P <lfam>-d seems partially redundant with -P <OrangeShark>I'll look more into it tomorrow and possible send patches to artanis <rekado>what do we do about the gtk+ hash mismatch on core-updates? Has anyone investigated this yet? <rekado>civodul: it seems that we still have a lot of jobs in core-updates that should be restarted but haven’t. Many of them are marked as failed due to the tcsh failure, which has already been fixed. <efraim>gtk+ hash mismatch: I sent an email to Sou about it <efraim>looks like it got updated and pushed directly to core-updates, so I don't think it was built by hydra previously ***mog- is now known as mog
***Noctambulist is now known as Sleep_Walker
<wingo>for some reason i get my git-send-email mails three times. weird but maybe it doesn't happen publically -- if someone else gets them three times per message also, let me know plz <alezost>wingo: I have "suppresscc = self" line (in "[sendemail]" group) in my global gitconfig to avoid sending mails to myself; although I don't really know why you had them 3 times <wingo>alezost: as long as you don't have them three times it's all good for me :) <snape>wingo: it there a way to make configuration "disabled" with your define-configuration system? <snape>like, instead of having pid-file="", I would like to offer the possibility to the user to have no pid-file line in its conf file <snape>for this, I was thinking about using things like maybe-string <snape>where the user could enter a string, of #f if he does not want the configuration <snape>not sure its a good idea though <snape>(I'm working on a service for prosody) <wingo>snape: yeah you have to make a maybe-string :/ <wingo>seems ok, though it's too bad to have to build it up by hand <wingo>i guess you can make a macro <wingo>(define-maybe-field-type string) or so <wingo>could make it less bad anyway <wingo>(that macro would define maybe-string? and serialize-maybe-string) <csanchezdll>guix enviroment -e '(@@ (gnu packages commencement) findutils-boot0)' tries to build findutils-boot0 <csanchezdll>which fails (that's the reason I am setting the env, to check why) <csanchezdll>seems some kind of circular dependency, is there a way to set up that env? <efraim>Which version of tar did you go with? 1.27 for me gives problems when building make-boot0, it says there's no source to open <csanchezdll>yup, I am using 1.29 from base, but have a slightly modified custom phase to change it <csanchezdll>I was waiting to send everything once bootstrap was working, but I can send current patches to the list <csanchezdll>so "sh" is taken from PATH (which includes static coreutils when bootrstraping) <efraim>i might have to try something like that with aarch64 <csanchezdll>I also had to customize static bash... cross compiling makes it use its own "getcwd" (cause it cannot run-test system one) which has problems with bind-mounts <csanchezdll>my guess is that will happen in all the bootstrapping scenarios where static tools are cross-compiled <csanchezdll>so if you or others are tryign to bootstrap other targets makes sense to send those patches ASAP <civodul>csanchezdll: try: guix environment --bootstrap -e ... <csanchezdll>civodul: thanks, I found it :) as I said, I should read --help more slowly <quigonjinn>how can i set a gcc version, for a package to be built with? <csanchezdll>seems the bootstraping compiler generates slightly wrong code that makes findutils test_isinf to fail <civodul>it's OK to #:tests? #f for the "boot0" packages <civodul>because they are rebuilt with an up-to-date compiler in the next stage <civodul>i doubt findutils relies on 'isinf' to function ;-) <csanchezdll>yes, I know, but as findutils had tests enabled I thought on trying to find where the problem lied <thomasd>I would like to lobby for a guix installation at work, but am not sure how well it currently works with a shared /gnu/store <thomasd>I found a conversation on the mailing list from 2015-07. Has the situation changed since then? <civodul>i suppose you want to install it on a cluster, right? <thomasd>not strictly a hpc cluster, we actually have 2 systems <thomasd>one is a bunch of linux servers runnin SLES with a network mounted /home, where everyone can connect and run software at will. <thomasd>would be nice to have Guix there, too. <thomasd>but the approach outlined by rekado in their article could work. <civodul>thomasd: at any rate, please email help-guix with whatever suggestions or problems you may have <civodul>this is a use case that several of us are interested n <thomasd>yes, I was thinking about similar use cases (apart from simple convenience of being able to install and manage software at will). also writing custom Guix packages for our own codes can really help to clearly establish dependencies and code versions used in processing chains etc. <thomasd>thanks for the articles. I'll think about how to present the case in order to convince our sysadmin :) <thomasd>I'll keep you updated if I have useful feedback or would need some help <thomasd>somehow, `guix environment hdf-eos5' requires gcc-4.9.3, which is not available from hydra and therefore triggers a long build. <thomasd>how can I see where this dependency is coming from? <thomasd>oh, probably guix graph is my friend <thomasd>hmm, so gcc-4.9 is the default gcc. But shouldn't it be substituted, then? <jmd>Has anyone got any useful tips on creating a pam service? <cehteh>ACTION seen pam_shell somewhere .. hooking shell scripts into pam <cehteh>but, for prototying some scripting language may be helpful <jmd>That isn't a guix related thing is it? <efraim>civodul: I hear guile-2.0.13 is going to be released soon <efraim>anyone want to take a stab at updating tcsh on core-updates? <civodul>bad timing regarding core-updates, but such is life <efraim>just saw the email to oss-sec :p ***marxistvegan_ is now known as marxistvegan
***NhanH__ is now known as NhanH
<rekado>efraim: what's wrong with tcsh? I already patched it on core-updates some days ago. <citronputride>i watched the presentation about free softwares by RMS on gnu.org. I'm totally agree but i have a question about freesoftware <Digit>many eyes make all bugs shallow. if only a corporation can see the code, and those who've seen the leaked code but cannot reveal they have openly, code whose notion of protection is merely obscurity... then i think that's a more vulnerable position. to those only accustomed to "security through obscurity", code anyone can see may at first seem daunting, but in time, you'll see it evolves more strongly, that anyone can find the bugs <Digit>and offer fixes, through shared interests. <davexunit>citronputride: security flaws will exist no matter if the source is readable or not. <citronputride>davexunit, but is it not more easier to send virus or bad softwares if we have the source code? <Digit>more discouragement to intentionally put security holes in Free Software. more incentive to put security holes in proprietary software, for profit & power-over. <Digit>citronputride: that doesnt seem to have been the case in practice. <Digit>i imagine it was better than mine. <citronputride>Digit, i didn't search for a list of virus on linux. But your previous answer helped (is it english?) me <Digit>my french is terrible, so i have no idea if this online translation is accurate: il y a plus de découragement pour mettre intentionnellement des trous de sécurité dans le logiciel libre. il n'y a plus d'incitation à faire des trous de sécurité dans le logiciel propriétaire, pour le profit et le pouvoir-sur. <citronputride>i think i'll try guix. I'm one ArchLinux now (because of wow) but i want a free distro'. I tried Parabola, that's a good distro' but i love the name of GuixSD X))) <snape>citronputride: but we should not speak french here though <Steap>ACTION speaks French as well \\o/ <Digit>there's no #guix-francais / #guix-french ? ^_^ <jmd>We should also not use Europe/Paris as guix's default timezone!!! <civodul>i suggest that we change the default timezone every month so that everyone is happy <jmd>We had n agreement in 1845. France gave up all claim to the prime meridian if the rest of the world adopted the metric system. <wingo>and the uk just adopted the euro, i hear ;-)) <Digit>that would be hilarious, with brexit decided <paroneayea>speaking of announced guile security things today <paroneayea>I notice that slime for common lisp has a patch to support unix domain sockets <paroneayea>I vaguely wonder if it's worth making a separate guix package using that branch in the meanwhile. <paroneayea>looks like it's still a recursive package manager <davexunit>what can they possibly do to improve things? <davexunit>seems like they aren't fixing the things that really need fixing <paroneayea>added parallel installs and locking, it looks like <paroneayea>it looks like it reimplements some NPM things more concurrently and alsso adds bower support maybe <paroneayea>davexunit: yeah, heh, that thing's sad/hilarious <ng0>thanks for the pre-release icecat inclusion <reepca`>Question... can I install guixsd straight from my desktop system (has Ubuntu 16.04) to a flash drive, not just putting the installer on it? ***reepca` is now known as reepca
<reepca>ACTION makes a note to look up tree style tabs later, sounds useful <ng0>I wish I had enough money this month to buy the new server already... can't test the mailinglist servers I packaged <ng0>has someone tried installing guixsd from within a debian server post minimal-install image? <paroneayea>davexunit: tree style tabs is the best extension ever <paroneayea>tabs go on the left side, and if you start "opening in new tab" <paroneayea>so the "wikipedia rabbit hole", you can collapse or expand it for example <reepca>oh so if you click a link from a page it makes it the child of that page instead of just adding it to a queue? <ng0>I wonder if I can log in to gnusocial then again with new icecat... old icecat+epiphany is broekn <ng0>login == reset password :D <paroneayea>ng0: I'm able to log in to quitter.se with epiphany <ng0>now with a new icecat I'm less motivated to finish palemoon, but it'll still happen :) <ng0>I think I should just try to guix system init when I've got a new vps at in-berlin again <ng0>maybe it works without much problems <ng0>this new java package manager is called yarn? that sounds like *yawn* <ng0>icecat, compile faster! x.x there's an maybe interesting news of scotland yard and crypto i want to read <ng0>why are graphical web browser so terrible big these days <ng0>okay using my phone.. wow these are terrible depths.. teaching crypto is now terrorism? wow <Petter>Hm, computer crashed and rebooted while running "guix package --upgrade" (from git checkout). <davexunit>Petter: sorry about the crash, but due to guix's design nothing else bad should have happened, at least. <reepca>So how would I go about installing guixsd straight onto a flash drive from ubuntu? <civodul>reepca: you could install Guix on your system, and then run "guix system init myconfig.scm /mnt/flashdrive" from there <reepca>any complications I should know about that would make it different than the process listed in the manual? <ng0>civodul, have you ever guix system init'ed into root (/) of a running debian system? I want to test this for a server next month, so maybe it's not something I have to document for others <Petter>davexunit: yeah, no worries. Nothing bad happened! Just thought i'd share in case other people experiences the same, then it would be worth looking into. <civodul>ng0: i ran "guix system init /" on my laptop when "guix system init" came into existence but haven't tried since then <reepca>where in the git repository can I find the file desktop.scm that would be located at /etc/configuration/desktop.scm if I were using an installation image? I searched for it but could only find one at gnu/services/desktop.scm <lfam>The tcc tests segfault on core-updates :/ <civodul>lfam: tinycc is a leaf, we can leave it for later :-) <civodul>telepathy-glib yes, we can restart it <lfam>Turns out it was already built. I think I got confused! <lfam>Testing the expected file size, the result was "undef" instead of the expected size <ZombieChicken>Anyone else having problems compiling nx7a43cg4fhlgkkixq6i9j83c782pl4j-gzip-1.8? <ZombieChicken>Installing guix on a Gentoo box, and it can't find anything at all <civodul>lfam: the "undef" thing sounds like a Perl compatibility issue (we upgraded Perl in core-updates) <lfam>civodul: That's what I was thinking <lfam>ZombieChicken: Presumably you need to install whatever package provides `more` <lfam>Which I think is util-linux <lfam>But I don't know the specifics of what is failing <ZombieChicken>lfam: Yeah. I think I'll just bug ng0 and see where his Gentoo overlay is hiding <lfam>I don't remember Guix depending on `more` <ZombieChicken>lfam: guix may not depend on it, but some build processes seem to <ng0>ZombieChicken: Gentoo openrc based or systemd variant? for the overlay, the openrc service is sh***. if you can fix it, be welcome and send a patch my way. also, not everyone on irc is a 'his' :), so 'they' works better <lfam>ZombieChicken: If a package's build process if failing because it can't find more, then the package definition should include util-linux as an input <ng0>layman -a youbroketheinternet <ng0>guix is currently masked there because the openrc service is bad.. the rest is functional. <ng0>bad as in 30 minutes shutdown <lfam>ng0: Does it actually shut down after 30 minutes have elapsed? <ng0>feels like 30 minutes.. could be more or less <lfam>I wonder what's going on there <lfam>My GuixSD system starting hanging on shutdown recently but I'm not sure how to debug it <ng0>i trust in the distributed nature of our overlay that someone will fix it one day.. i don't feel responsible. I just gave the start with the guix ebuild ;) <lfam>Maybe ZombieChicken will fix it :) <ng0>lfam, you can read it on gnunet.org/git/ <ng0>in the overlay repo it is sys-apps/guix/files/ afaik <ng0>ah well, when you use torify layman you the onion.. forgot to mention that :) <ng0>in case you want to use the onion <lfam>ZombieChicken: I just built our gawk package successfully for x86_64 from the current HEAD of our master branch (bfb48f4f335). So you should be able to build it for that architecture from that commit, too. <ZombieChicken>as it in doesn't actually do what it is supposed quite frequently <lfam>And the gawk package does not include util-linux / more in its package definition <ZombieChicken>lfam: Well, I'm currently removing guix to merge it from the ebuild <ng0>ah okay... i reported a bug which got fixed in perl, but tor is... well they are not very repsonsive. <ng0>so i don't know if my torsocks bug will be fixed <ng0>idk.. search the tractor <ng0>I was told opening bugs there is prefered, at least by what tor team told me in their irc. <ng0>that is the pre-release version of torsocks, the stable ones just work. <ng0>more or less, haven't tested the buggy perl application/version combination with torify again <ng0>makes no sense as long as the fix is not published.. or was there a perl release in the last 3 months? <lfam>I don't remember when it was released, but on core-updates we are updating Perl from 5.22.1 to 5.24.0 <ng0>[perl #128740] perl5 segfaults (perl5 versions gentoo(5.20.0, 5.22.0), guix (5.22.1)) without message <ng0>there's a chance it's fixed now :) <lfam>python-cryptography on core-updates doesn't detect the openssl version correctly <lfam>Does anyone have any insight into that? "Failed: DID NOT RAISE" <ng0>yes... but it'll take time and people <lfam>Perhaps I'm misinterpreting the nature of the failure. It might not have anything to do with detecting the openssl version <lfam>ZombieChicken: It wouldn't be to hard to try yourself. You could use the "superseded" package property to supersede openssl with libressl <ng0>actually, one only needs to replace all openssl with libressl in a new branch, let hydra build that and fix failures accordingly. <ZombieChicken>Have to check to see if any distro has done that. Save us the headache <lfam>We already use GnuTLS for a lot of things. We are not a TLS monoculture ;)