<rain1>how do you get man pages for c programming? <ajgrf>rain1: probably the man-pages package? idk for sure, that's just from a quick search <lfam>sneek: later tell civodul: The graph coloring is very useful! <frimam>See manual says that 'maintainers' is a list of maintainer objects. Just because I'm curious: Where is this record defined? <alezost>frimam: Do you mean <package> record? In (guix packages). If you mean 'maintainers' – it is not a record, it's just a list. And it is not actually used :-) <frimam>In the manual it says: "The list of maintainers of the package, as maintainer objects." <frimam>Ok, but if it's not used it shouldn't be of interest. <alezost>yes, it is not used and 'maintainer' object is not defined anywhere, so yeah, of no interest :) <frimam>Ok, thanks, I just asked me that when I read the manual. :) <marusich>frimam, if the manual is incorrect, you can submit a patch to guix-devel@ to fix it so that others are not confused in the future <frimam>marusich: Maybe that record was intended to implement when it is used? <frimam>And I think if it's not implemented and nowhere used, you can pass what you want to, right? <ng0>would it be useful to use maintainers field, or do we just assume that with a rising number of users and developers people will jump in and fix, update and discuss problems and improvements more often, even when files reach lengths of several thousand loc after years? <ng0>i don't think we need that field. <janneke>maintainer: the Guix maintainers ;-) <Jookia>We probably need a better system than a mailing list if we want to scale <Jookia>Right now patches are lost/forgotten about and the mailing list GUI is archaic <janneke>Jookia: forgetfulness can be quite a feature <mthl>Jookia: archaic is the new black. :) <ng0>mthl: that is much more than just double meaning :/ <janneke>Have you ever used a system like bugzilla? <Jookia>Well I'm done contributing for now because of the current system <janneke>A system that automagically, inherently "forgets" can be a feature <ng0>see the gnunet-svn , fetches from svn <ng0>oh, thanks for the reminder, i forgot that i wanted to email bug-womb today <Jookia>janneke: I don't want to make a fuss about it and I haven't talked about it at all but in short: I need a working system, and I can't waste time any more trying to work on upstream <Jookia>So I'm probably going to run private patches and do bug reports <rain1>Jookia, what do you think about an AUR type system? <Jookia>rain1: Most the changes I have are in core Guix, so it's not really helpful <rain1>did you have patches that got ignored/forgot? <ng0>rain1: define which era of AUR you refer to <rain1>I think my ffmpeg version dump did... <ng0>it recently switched to something I can no longer understand <rain1>ng0, just conceptually - a shared git repo for extra packages not in guix core <ng0>rain1: it would still need to be limited to free licenses <ng0>AUR is unoffical, but still arch connected <rain1>Jookia, here is what I think.... <rain1>it's hard to find patches that have been forgotten in the ML <ng0>I am thinking of maybe packaging non-free things later just to drop it on some place not in guix, for example libertad.pw/git/non-free-guix/ (server entirely down atm, don't check the link) <rain1>then you could easily see 'open' patches and they could be closed when they are pushed or decided not to take <ng0>Jookia: there was/is a discussion on this on the list. I agree that the system is not optimal <Jookia>But discussions/change takes a very long time <Jookia>Especially when people that have to make the change don't have problems with the system <Jookia>I'm not going to be too satisfied until there's a system that has a web interface and patches as bugs <rain1>what do you think about debbugs for that? <ng0>"adn patches as bugs" ? you mean the software patches? <Jookia>ng0: I mean when it comes to management <rain1>Jookia, btw yes I think others have felt this is a problem - me and ng0 were talking about it too <Jookia>I don't know about debbugs. Maybe it'd work? People who don't know how to set up their email client to work with mailing lists probably won't use it <Jookia>I suggested moving to Mailman 3 which has a web GUI that integrates with the mailing list but the devs didn't really seem to understand why that'd help so iuno <rain1>if it's acceptable and a couple people agree it could be worth proposing it to the guix developers <ng0>the mailinglist depends on what runs on gnu.org currently. <ng0>could be changed (i think) when guixsd.org has its own webserver <ng0>guixsd spoilt me. I no longer want to setup any other system, but I can't run a guixsd server currently because it requires more services. <Jookia>Well, NixOS is more mature, less free, and has a github that might be a bit easier to use. So maybe I'll go spend some time there again. :P <rain1>what about trying to fix the problem? <rain1>like my suggestion, is that no good? <ng0>i would say it's out of our control at the moment to change to mailman 3. someone wanted to testrun the software "patches" soon. <rain1>Jookia, or ask for a commit bit perhaps <Jookia>I'm not happy to accept a solution that only affects me <rain1>I think the problem you pointed out is real and others have noticed it too <rain1>if it can be resolved then it should improve guix for everyone <rain1>is I think it's worth at least proposing a solution <Jookia>There's solutions proposed but in the end I've waited a few months and I'm kinda done <pizzaiolo>I agree, the mailing list model too disorganized <Jookia>Maybe it's a tradeoff between high quality code and having enough people to review it <ng0>what if we have monthly meetings (in irc) to discuss problems, like patches which need attention which are about to fall into archive state, etc <ng0>i've followed this in #archlinux-women for a while, and for things it helps. <ng0>interesting, kde-plasma/plasma-meta as of 5.6.x ships a theme for grub. <ng0>the almost default of plasma-meta in gentoo has around 106 packages.. i imagine it will be more on guix to get into. <ng0>no. at least not currently.. i just update from 5.5.5 to 5.6.1 now on gentoo <ng0>currently I am trying to wrap my head around services, so i can write gnunet-service for guixsd, and try to get guix on gentoo <ng0>it will never arrive in portage though, but our .onion overlay has it <ng0>guix made me loose time to SecuShare.. i need to learn to split time :/ <ng0>see bug #355355 in bugzilla of gentoo.. now celebrating its 6th birthday <rain1>mabye gentoo can get the newest guile version <ng0>where our overlay has a working guile2 which will not wreck your system. <ng0>at least my own system <ng0>i refuse to get involved in portage after the outdated packages i have seen <ng0>*coin related software, lagging 6 versions behind, 3 years outdated. some openssl changes. torbrowser not even in portage, but an overlay we sync with, guile2 from portage breaks your system, etc <ng0>project:scheme almost being non-existent <ng0>so i don't run gentoo, if i wouldn't run plasma from their overlay, i would run my own os, relying mostly on my own ebuilds <ng0>when I tried to bring it up in #gentoo, someone just pointed me to the bugreport <rain1>ng0, I know a gentoo user that got guile working <rain1>I could ask if they did anything special? <ng0>repeat, i have a working guile <ng0>see just on www.psyced.org/download.html , checkout the .onion overlay .. as I work on this again after a break, I will replicate it once i have a webserver again. <ng0>but the guix versions you see there might be outdated, depending on if lynX synced again from my .onion or not. <ng0>rain1: the fun thing with guix from source is also that it install into all kinds of default locations of gentoo, and /gnu/store gets created, but as soon as builders kick in there are issues I can't work out. builders are in the right group, but guix complains they aren't.might be one long emerge guix; emerge --depclean guix; run guix and repeat until i got it <ng0>the binary version is even worse atm <nee`>Hello, I need a guix environment with a qt-5.5, but 'guix environment' keeps building qt it from source. This PC is slow and it would take until tomorrow. Is there a way to fallback to an older substitute from the server? <rekado_>nee`: the only way to use older substitutes (if they are still available) is to use an older version of Guix. <rekado_>I wanted to set up "patches" on my server, but it looks like I won't be able to do this for at least another two weeks. <rekado_>I don't think a regular meeting would help much. <rekado_>having even more stuff to follow up on doesn't sound like a good idea to me. <rain1>qt is really huge I hade to wait all day to build it myself :( <rekado_>if you think a patch was overlooked just wait for a couple of days, then send another email to the list <rekado_>this works for me (both as a sender and receiver of emails on the list) <Jookia>I don't want to do that, and I doubt newbies will want to do that either <rekado_>well, I can't go through hundreds of old emails that didn't make it over my threshold <Jookia>Which is why we need something better <rain1>rekado_, how do you feel about a dedicated debbugs for package patches? <rekado_>that's why I wanted to install "patches", I just don't have the time today, and that means it has to wait for the next window <str1ngs>Gerrit would be better then mail patches <str1ngs>works in conjunction with mail patches <jmd>aegis would be even better <davexunit>this patch review discussion is driving me crazy. <davexunit>we may supplement this with the "patches" tool from Qemu <davexunit>if a patch of yours hasn't gotten feedback, please just send a ping on the mailing list. <Jookia>Won't that only encourage people to create more noise or abandon patches? <davexunit>this is really less of a tool problem and more of a people problem. we don't have enough people reviewing patches. I haven't done enough review myself. <davexunit>if more people review, less people will feel like their stuff is forgotten. <janneke>also, some problems really become less important as time moves by <davexunit>so for now, it would be great if people could understand our situation. if all of these things were pull requests on github we'd have just as much of a problem because still couldn't review fast enough. <ng0>i think i realized that and started to review where possible <pizzaiolo>not advocating for github, but at least in that platform the pull requests wouldn't be buried <rain1>of course github is not free software <rain1>at least the idea can be taken <Acou_Bass>there are plenty of other git-based things that are free ;D <efraim>there's redmine, which looks like a software-project manager all-in-one <Acou_Bass>i use gogs for my git needs, though its MIT licensed, not sure if thats free enough :P <janneke>phant0mas: got a bit further again, now stuck on compiling readline. I found that in the (cross) environment, there is native ld-wrapper0 and native binutils, glibc. These set C_INCLUDE_PATH and configure breaks. <sneek>Welcome back phant0mas, you have 1 message. <phant0mas>hey rekado_ currently I am trying some of janneke 's changes to your toolchain because my previous ideas ended up failing.. <janneke>it's easy: there are native packages (glibc) that set their C_INCLUDE_PATH <janneke>shouldn't be in the environment-variables <janneke>probably my fault somewhere in cross-base.scm <phant0mas>janneke: which libc should readline use when on windows? <phant0mas>janneke: the problem with your realine here is that it wants the 32bit glibc <janneke>phant0mas: it should use mingw-w64, that's its "libc" <janneke>phant0mas: but also "ld-wrapper" is wrong, it should have "ld-wrapper-cross" <janneke>i guess that in build-system/gnu.scm (standard-cross-packages): something goes wrong, but it's so hard to debug <janneke>add a print statement in the wrong place, and native bootstrap toolchain rebuilds <janneke>phant0mas: the problem here is that readline's configure picks-up native headers. I removed them manually from environment-variables, and then readlink builds fine. <phant0mas>janneke: hm.. maybe a good idea then, would be to modify the c_include_path when crossbuilding in cross-gcc <janneke>phant0mas: yes, c_include_path needs to go...but these native packages must not appear in a cross-build's *-inputs ***kelsoo3 is now known as kelsoo
<kyamashita>Hi all. I have a bit of an interesting situation here. <kyamashita>I want to package wmbattery (for Window Maker), but the tarball has a new hash every time it's downloaded. <lfam>Probably the first step is to figure out what the difference is <lfam>If you can't tell, you can use a tool like diffoscope to do the hard work <lfam>Do other distros package this software? You could check their packaging to find a workaround <kyamashita>The PKGBUILD from the AUR skips the md5 checksum verification... <lfam>Yeah, that's not a solution <kyamashita>It appears that the tarball is created on request. <kyamashita>The only difference is the timestamp on each file. <lfam>I'd file an upstream bug <lfam>That's a non-standard distribution method in my experience <lfam>Disturbing that Arch disabled the check <lfam>And that they even use md5... <rain1>confirmed that every single download has a differennt hash! <ng0>on email and having no overview / thing on the list: i just gave up on Gnus for sorting. I will use notmuch for sorting and reply somehow in notmuch or Gnus or combine both. 9000 emails just tells me i need to get rid of what I use now. good thing I can still keep track with guix somehow. <rain1>It seems to generate the tarball on demand <rain1>and so the creation date on each file is the download date <lfam>They probably just didn't consider this issue when they set it up. I would contact them <rain1>I suppose it's just the web server thing they have set up <ng0>so that people can overload the system with tarball requests <rain1>I agree to contact them, it's can hopefully be tracked back to a CMS or something and a bug could be filed <lfam>I don't think you could leave the hash out of a Guix package and have it still build, regardless of the source of the package <kyamashita>There is also a git repository containing many dockapps. Perhaps this can be used instead?