IRC channel logs


back to list of logs

<kyamashita>Quick question: if I were packaging the pygame library, would that go under game-development.scm or python.scm? I'm leaning more toward game-development.scm right now.
<bavier>kyamashita: game-development seems appropriate
<kyamashita>bavier: I assume a similar opinion for libraries built on top of Pygame, like onpon4's SGE Game Engine?
<davexunit>ACTION is a little frustrated with people saying that it is hard to contribute to guix
<davexunit>it is, without a doubt, *significantly* easier to contribute to guix than any mainstream distro
***fkz is now known as Guest403
<Sleep_Walker>that is not true
<Sleep_Walker>we spent a lot of effort on making easy contributions to openSUSE and it doesn't require Scheme (which is not exactly the most popular language around)
<Sleep_Walker>we have almost the same way as github/gitlab - fork, fix, submit, review, accept/reject
<lfam>We have basically the same workflow: clone, fix, submit, review, accept/reject
<lfam>Sleep_Walker: Any advice on how we could make it easier to contribute packages to Guix?
<Sleep_Walker>I believe that the hardest part is with Scheme :)
<Sleep_Walker>and sometimes Guile error messages are not exactly helpful
<lfam>I was mystified the first time I read a Guile backtrace
<Sleep_Walker>is there a way how to override the list of required kernel modules without reimplementing initrd generation code? I have my own kernel configuration and have all code compiled in (to disable module insertion at all)
<lfam>I'm not sure. There has been recent discussion on help-guix about using custom kernel configuration. Would that help?
<Sleep_Walker>thanks for the tip, I'll check the archive
<Sleep_Walker>I'm reading guix-devel only
<Sleep_Walker>it seems that they're still struggling with kernel build and not yet initrd troubles :)
<Sleep_Walker>the thing is that I'd need to express that that I have no modules to be added into initrd from system configuration, unfortunatelly it is now hardcoded and not set as some default value
<Sleep_Walker>maybe optional ignoring errors on module non-existence can be easier
<civodul>Hello Guix!
<civodul>zero SourceForge issues showing up at
<alezost>woohoo! thanks to Leo!!
<civodul>alezost: indeed!
<Sleep_Walker>useful :)
<ng0>what's useful?
<ng0>one thing i like about guix, people no not read between the lines and assume you have magical knowledge of discussions which were not visible for you. If I were not interested in solving it and had 2 people with positive reactions, I'd just unsubscribe from the bug at gentoo and solve it in private.
<wingo>ng0: you can always read the archived chat logs to know the context of a conversation :)
<ng0>this was not related, sorry
<ng0>just a general feeling of rant towards guile bug at gentoo
<ng0>i ask clear question and point out clear points of failure, make suggestions and all I get is minimal answers with assumed knowledge of internal discussions
<ng0>ACTION *thumbs up*
<jlicht>hello guix!
<civodul>hello jlicht :-)
<jlicht>my freshly pulled guix is complaining about the source hash for wxwidgets@2.8.12
<jlicht>before I assume I am being singled out by some nefarious government agency, is anyone else also noticing this?
<civodul>ACTION checks
<civodul>there's a substitute at
<civodul>with --no-substitutes i get: `/gnu/store/9q5n4985lh5bp0xavwddc13lr7dc8yfl-wxWidgets-2.8.12.tar.bz2' should have sha256 hash `1gjs9vfga60mk4j4ngiwsk9h6c7j22pw26m3asxr1jwvqbr8kkqk', instead has `01zp0h2rp031xn6nd8c4sr175fa4nzhwh08mhi8khs0ps39c22iv'
<jlicht>civodul: exactly
<civodul>so i think it's been modified in place
<civodul>jlicht: the top-level directory name has changed and there's a number of new files:
<civodul>could you propose an update on the list?
<jlicht>civodul: as long as this update entails looking at the changed files and subsequently changing the hash, sure :-)
<jlicht>civodul: found some more sourceforge-hosted source archives that seem to have been slightly modified
<Sleep_Walker>in my case :(
<Sleep_Walker>don't tell me that sourceforge repacking tarballs again
<Sleep_Walker>it would be almost year anniversary since last incident ;b
<jlicht>Sleep_Walker: indeed
<jlicht>maybe we can get them a cake?
<civodul>bah, that'd be terrible
<jlicht>is there some way in which to update all of my packages to their latest versions (via package -u), but exclude texlive?
<jlicht>nvm, just found the --do-not-upgrade flag
<ng0>once a year they change? maybe we need a sourceforge-fix-changes thing
<Sleep_Walker>ng0: I meant this
<frerbst>Hi! Currently I'm installing GuixSD on an old machine to play around with it a bit and test it. I have the problem that "guix system init" keeps failing due to "networking issues" while downloading python2-setuptools-18.3.1. It always downloads exactly 345KiB and fails then. I tried to build it locally, but this adds it to the store of the live system (I#m not very experienced with Guix, but this is what I guess). Any ideas on how to continue?
<ng0>i have a solution… which differs and will need time. a byproduct of the gnunet-fs thing.
<ng0>frerbst: you need to restart ncsd or what the name was
<ng0>herd ncsd restart (I'm not good with remembering services)
<frerbst>ng0: Shouldn't it be "herd restart ncsd" (which fails with service ncsd not found)?
<ng0>it probably isn't named ncsd then
<ng0>we should have this in the manual.. maby there's even an open patch about it
<frerbst>ng0: So what is this service doing that makes the download failing in the middle of the process?
<frerbst>Or not doing, if it has to be restarted.
<ng0>it's the dhcp daemon i mean
<efraim>its related to name-server recognition iirc
<ng0>herd restart dhclient? check if you can ping, else it has to be restarted
<efraim>civodul: I rechecked the hash of gnuplot that I got from updating it, the hash is 08vpmhl85l48xcccx8jrkamalih2d6z9ppqpsppwii9y2l1p3297. I'm sure its the one I got from one of the sourceforge mirrors
<efraim>logfile from the download says I got it from
<civodul>efraim: could you compare the old and new tarballs?
<civodul>on access control in Flatpak and Snap:
<efraim>i'm putting a copy at , old is the one I downloaded, new is the one I just downloaded
<efraim>i'll look at them too, in case anyone else wants to take a look at them also
<Sleep_Walker>and has anyone asked on #gnuplot?
<efraim>difference on the changelog
<efraim>looks like they might've changed the tarball themselves
<Sleep_Walker>fulld diff
<efraim>diff -r? I should've read the man pages
<efraim>it doesn't look like its malicious
<Sleep_Walker>it does look like two different snapshots where the older one is used instead
<civodul>looks innocuous
<civodul>Sleep_Walker or efraim: could you post the two hashes and the diff to the list, along with a patch to update the thing?
<civodul>this one looks safe
<civodul>thanks for investigating
<efraim>you did new to old, old to new it looks like they added a check for something
<Sleep_Walker>efraim: you're right :)
<koosha>Hello friends !
<koosha>I've just installed the openssh package . I wanted to start the ssh service but I don't know it's name . What's it's name ? Thank you .
<civodul>hello koosha!
<civodul>currently there's on sshd (OpenSSH) service in GuixSD; there's lsh-service instead
<koosha>Hi , so you mean I can't use openssh ?
<davexunit>koosha: also note that installing a package doesn't install system services to the global system config
<davexunit>packages and services are completely separated, unlike in Debian and co.
<davexunit>you can start the openssh daemon manually using the software provided in the openssh package, however.
<koosha>davexunit: Oh , I tought it's like Debian . thank you .
<koosha>* thought
<davexunit>we don't do imperative global config changes like that
<koosha>So how can I start the openssh daemon ?
<davexunit>I already told you.
<davexunit>you can start the daemon program manually if you'd like.
<davexunit>for it to be integrated into guixsd, you need to write some Scheme code to create a new Shepherd service.
<koosha>Yes , I see that . But how could be done manually ?
<koosha>* could it
<davexunit>I don't know the ins and outs of every program.
<davexunit>read the man page, google it, etc.
<koosha>Okay , thank you .
<davexunit>all I know is that the openssh package provides the client and the server, so you can start the server somehow.
<koosha>Sorry , I'm noob . I installed lsh package but it seems that lshd is not installed .
<davexunit>civodul: nice work on the libgit2 bindings!
<civodul>davexunit: really a quick hack, but i hope Someone can make a proper guile-libgit2 package eventually
<davexunit>civodul: I sent a reply to the list that I had started such a project awhile ago
<davexunit>I just didn't get anywhere with it
<davexunit>if I may snarf these bindings...
<civodul>that'd be awesome!
<davexunit>civodul: would LGPLv3+ be okay with you?
<civodul>davexunit: sure!
<civodul>i have a slight preference for GPLv3+, but LGPLv3+ is fine too
<davexunit>me too, but I don't see a particular reason to use GPLv3+ for this
<rekado>I have a weird error trying to build Guix:
<rekado>./random:156256:1: error: exponent has no digits
<rekado> 000000EEEEEEEEEEEEEEEEEEEEEEEE000000EEEEEE424242848484E6E6E6808080424242EEEEEE
<rekado>does this look familiar?
<rekado>huh, never mind.
<rekado>there was a file "random" and for some reason it affected the build.
<rekado>removing it fixed it for me.
<rekado>(the file was a result of unpacking a tarbomb)
<wingo>weird :)
<rekado>it affected the build of nix/libutil/libutil_a-archive.o
<lfam>So, how many SourceForge package hashes were changed in place? :(
<lfam>I spot-checked while updating the URLs, but I didn't verify all of them
<jlicht>at least two of them (gnuplot and wxwidgets)
<jlicht>might be more, of course
<lfam>I don't like this news :(
<efraim>gnuplot was a rerelease, so that one we can pin on them
<lfam>Very happy to read about Git bindings for checking signatures
<kyamashita>lfam: Where did you read about that?
<lfam>kyamashita: Starting here:
<lfam>I subscribe to bug-guix so it was in my Guix mailbox :)
<lfam>Currently re-downloading all the source tarballs of our SourceForge packages...
<civodul>lfam: thanks a lot for the SourceForge work!
<lfam>It's a significant set of packages!
<lfam>And it's something I'm able to do, so I'm happy to do it :)
<civodul>yes, you're doing everyone a great service
<jlicht>thanks, lfam!
<jlicht>what are you using to download all the source tarballs of our SF packages?
<jlicht>I might want to download _all_ sources, as I'll be without Internet for about a day
<lfam>jlicht: alezost gave me a handy script to print a list of packages that fetch from SourceForge. I'm re-uploading it here:
<lfam>I use a shell for loop to run `guix build --source --no-substitutes` on each one
<lfam>I think downloading *all* the source code might take a while
<lfam>This has already been running for over 30 minutes, and that's only the SourceForge stuff
<lfam>It would have been smarter to use GNU Parallel
<lfam>It just finished :)
<jlicht>hurray :-)
<lfam>I'll send my findings to the list
<lfam>ACTION sends it
<Sleep_Walker>I got HTTP error 410 Gone on texlive-texmf-minimal-2016 from hydra
<lfam>Sleep_Walker: Add --fallback to the command
<lfam>We had to stop serving that because it's so insanely large
<Sleep_Walker>lfam: I'd rather not build texlive locally
<lfam>The method of not serving it is sheduled for improvement ;)
<Sleep_Walker>lfam: makes sense :)
<lfam>Sleep_Walker: Hydra doesn't build it anymore
<lfam>There's been some discussion of the pros and cons of different methods of addressing this problem on guix-devel. Feel free to chime in
<Sleep_Walker>I'm not sure now which package pulled this as dependency
<lfam>It's not satisfactory
<lfam>What did you try to do?
<Sleep_Walker>build system configuration
<Sleep_Walker>I have worked on patch where I can specify no kernel modules and I didn't get to the testing yet :)
<rekado>ACTION just pushed a commit without signing it :O
<lfam>Yeah... something always pulls it in. Since they seeem to update infrequently, I've made the texlive-texmf source a gcroot on my systems (symlink it to /var/guix/gcroots)
<lfam>rekado: Bad! ;)
<rekado>still haven't set up a subkey for my workstation in the office.
<rekado>forgot about it
<rekado>normally I push from my laptop
<lfam>I think there's a repo option we can turn on to only allow signed commits
<lfam>Maybe it's time?
<rekado>I would like that
<rekado>many of us have been pushing only signed commits for many weeks now.
<lfam>Yes, I checked recently, and prodded some people to upload their public keys, so I can verify the entire signed Git history now, IIRC
<lfam>I think we are ready to make the change, assuming we have access to that level of configuration on Savannah
<lfam>Can anybody do `guix build --source --no-substitutes utfcpp`?
<rekado>FYI: I'll be traveling (probably without internet access) for one week, starting tomorrow.
<jlicht>lfam: I get stuck in a redirect loop
<jlicht>but I might have some gnutls issues as well
<jlicht>lfam: no wait, it ends up at tarballs.nixos, where I get a 404
<lfam>I thought I was having gnutls issues with the sourceforge packages, but I think that error was unrelated
<lfam>I can provide a "raw" URL, copied from my web browser. But when it is constructed with Guix's sourceforge mirrors and string concatenation, it fails
<Sleep_Walker>same for me
<lfam>I wonder if it has something to do with the whitespace in the URL
<jlicht>lfam: this is what I get :,
<lfam>jlicht: Same here
<lfam>When I started fixing all the other URLs, I found that the http -> https redirection only happens when the http URL is bad. So, I think the gnutls warnings are spurious in this case
<bavier>rekado: have a fun trip!
<efraim>I think some of the lx* packages moved to github, but that might've been the lxqt packages
<rekado>bavier: thanks :)
<bavier>lfam: IIRC civodul already enabled the signing option on the repo; it'll reject non-signed commits for some weeks now
<lfam>bavier: Apparently not. See commit f21403e2b
<efraim>tig doesn't show if its signed, what are you guys using?
<lfam>`git log --show-signature`
<lfam>There is also `git verify-commit`
<bavier>lfam: interesting
<civodul>bavier: it doesn't reject it yet
<civodul>do you know of a push hook that i could ask the savannah admin to install?
<civodul>a hook that would reject unsigned commits
<lfam>civodul: The pre-push hook I shared a while ago could show the way, although it uses `git verify-commit`, which requires the public keys and GnuPG to be available
<lfam>So, perhaps it's not appropriate in this case
<lfam>The question is, do we want to only accept signed commits, or do we want to only accept verified commits?
<lfam>The latter is ideal, but it's significantly more complicated
<efraim>we could scrape the keys from savannah and create a keyring to compare the pushed commits against
<efraim>ACTION goes afk until tomorrow
<ng0>how would I link to a collapsed entry on the packages html list?
<lfam>ng0: I don't think there's a way to do it. I've found that the anchor links always unfold the entry.
<ng0>oh. okay
<lfam>Why don't you want the entry expanded? :)
<ng0>oh wrong word
<ng0>i meant expanded
<lfam>Add #foo to the URL to link to package foo
<ng0> not like this?
<ng0>updating curl at the moment, then I will create a version bump patch and right now I'm writting a message to curl with information to list us
<lfam>ng0: We have to update curl on core-updates, since so many packages depend on it
<ng0>so 7.50 is done?
<lfam>Your link works, too. I never tried that :)
<lfam>And I was wrong. The packages are not expanded.
<lfam>ng0: On core-updates, curl is 7.47.0
<ng0>have to update.. oh
<ng0>reading is hard
<ng0>okay I'll do the update on core-updates
<lfam>Let's hold it for core-updates next unless it's a security update. We are just finishing the current core-updates cycle, finally
<ng0>i wanted to read up on the notes, it could be a security update
<ng0>i see no cve, but in a previous version above 7.47 there is
<ng0> we do not package mbedtls/polarssl yet
<lfam>No, we decided not to update in response to that. If curl was easier to update, I would have done it.
<ng0>ah, i remember now
<lfam>But, if I had known the current core-updates cycle would keep being restarted, I would have updated there
<lfam>Next cycle I will be less timid about changing things
<pmikkelsen>Hi guys, am I right when I think the only way to update the system is to run `guix system reconfigure`?
<adfeno>pmikkelsen: "update" to what extent?
<bavier>pmikkelsen: users may update their own software with 'guix package -u'
<pmikkelsen>adfeno: update all the system packages, like the kernel, xfce, mesa etc.
<pmikkelsen>bavier: Yes I know that, but I dont have a lot of packages installed compared to what the system has
<bavier>pmikkelsen: yes, 'guix system reconfigure' is the way to update the system packages
<pmikkelsen>bavier: okay thanks
<ajgrf>i'm packaging a python program. anyone have an idea of the correct way to get the function call ctypes.util.find_library("c") to work correctly in guix?
<lfam>ajgrf: I don't, but there are two results when grepping for ctypes.util in gnu/packages
<lfam>Maybe they will show the way?
<ajgrf>ok i'll check that out
<lfam>I wonder if janneke has any thoughts about the lilypond build failure on core-updates? <>
<lfam>It dies in 'fix-path-references'
<lfam>In unknown file: ?: 1 [string-append "\\"" #f "\\""]
<janneke>lfam: yeah...don't do that ;-)
<janneke>looks like a problem with gs (or sh)
<lfam>Yes, although I don't see why there would a problem
<janneke>ghostscript is listed in inputs, shouldn't it be in native-inputs too?
<lfam>If it's in inputs, it will be available while building
<lfam>native-inputs is more appropriate when it's only needed for building. I don't know whether or not that's the case with lilypond and ghostscript