<aeva>anyone here use leger? I'm having trouble trying to install it <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, efraim says: if its not too disruptive go ahead and pull in the python-2.7.12 update f0499100a62e0b36ea31ad46021d30a9868b71ea , it really ended up being a drop-in replacement for 2.7.11. ***Digitteknohippie is now known as Digit
<aeva>it looks like some tests are failing? I'll paste a log in a sec <aeva>is there a way to try to install an older version? <lfam>aeva: Yes, you can try installing it from a Guix Git commit older than HEAD. I reviewed the package, and it did build when we added it. But, you would be missing any security updates in ledger's dependency graph if you did that <lfam>Since both failed tests are related to time, and tzdata is a dependency of ledger, I wonder if it needs a newer tzdata package, if there is an issue with your clock, or if the tests simply "expired". I see code that deals with time expire all the time. It's really annoying <lfam>Our tzdata is not the latest version. But we shouldn't update it on the master branch since it would require ~900 rebuilds. <aeva>which one will help me figure out why I don't have any money faster? :D <lfam>I'll update it on core-updates if it's not already there. You could try building ledger with that commit. <lfam>Personally, I don't need an accounting program to answer that question ;) <efraim>i don't think tzdata has been updated on core-updates <lfam>efraim: Okay, I'll do it now <aeva>how do I install from a specific commit...? <lfam>aeva: Are you familiar with Git? <aeva>I have the commit hash picked out, assuming that I can pick whichever one? <aeva>I figure I just want to try the most recent release tag, and then work backwards until something works <lfam>aeva: Yeah, basically any commit on the master branch. Our policy is for that branch to be "deployable", but sometimes we make mistakes :0 <lfam>You could try `git bisect` <lfam>Anyways, to use Guix from Git, you have to build Guix from Git and then prefix your commands with the 'pre-inst-env' file that will be created in the Guix Git tree <lfam>Hm, wrong section. See the previous section for building instructions <lfam>Make sure to note the sentence about the localstatedir <lfam>Most installations of Guix will have a localstatedir of '/var'. You will want to use the same localstatedir <lfam>Okay. First, clone our Git repo. Then, use `guix environment guix` to put all the Guix build dependencies in your environment. Then, `./bootstrap && ./configure --localstatedir=/var && make`. Afterwards, there will be a script called 'pre-inst-env'. It makes it easy to use the Guix you've just built: `./pre-inst-env guix build hello` <lfam>So, to use some commit, check it out and then use the 'pre-inst-env' script <lfam>Please let me know if that doesn't make sense <aeva>and this is to... rebuild guix??? <lfam>aeva: Yes, that is currently the way to use Guix from an arbitrary Git commit <lfam>Some of us *only* use Guix in this way, never using `guix pull` to update <aeva>:( I thought there might have been some way to just install older versions of the package? <lfam>aeva: Not yet. We know it's a limitation. <lfam>But, it's also a super powerful way to use Guix. Perhaps too involved, but powerful. <aeva>yeah this is above my skill level :( <lfam>Never a bad time to learn new skills :) <lfam>aeva: Did ledger ever work for you? <aeva>no - I only just tried to install it <lfam>Hm, otherwise I'd suggest you use the rollback mechanism <lfam>Well, I'm trying to fix it now :) <aeva>I'd say while trying to work out a financial crisis is not a particularly great time to dig into git bisict and meta distro packaging <aeva>I appreciate your efforts <lfam>aeva: gnucash is potentially another option <aeva>it doesn't seem to be able to read the csv exports from my bank? like, it wants more info I think than is actually there <aeva>which is an easy fix with a dash of python, but at that point I may as well just have it create the files for leger <lfam>efraim: I built the new tzdata on master, and pushed the commit to core-updates <lfam>ACTION guix package --install 1-million-bucks <aeva>if only it were that easy *sigh* <lfam>Sorry, that package is broken ;) <mark_weaver>aeva: the --with-source option to 'guix build' or 'guix package' is often sufficient to compile a package using an existing package description but with a different tarball. <mark_weaver>the last git commit where ledger was successfully built by hydra was d256397 <mark_weaver>I don't think --with-source would be sufficient here though. I guess it broke when some other dependency was changed. ledger itself was not updated <lfam>I'm building ledger with --keep-failed to see if there are logs of the test failure <mark_weaver>aeva: the only failure seems to be a couple of tests. an easy way to get it working for now would be to disable tests, by adding #:tests? #f to the arguments list <mark_weaver>2 tests failed out of 352, both having to do with date/time formatting apparently <lfam>aeva: That is something you can set if you are using Guix from a Git checkout, as I mentioned earlier <mark_weaver>if not, there are other ways, but that's the best way to test fixes or make changes. <mark_weaver>but I can give you a simpler approach for now if you don't want to deal :) <aeva>uh, I have guixsd installed via the docs I found online <lfam>aeva: Try using mark_weaver's name, or he might not notice your message :) Most IRC clients will alert the user if their name is used <mark_weaver>I saw the message, I'm not mulling on how best to deal with this <mark_weaver>if you had a git checkout, this would literally be adding one line "#:tests? #f" in the appropriate place in the recip <mark_weaver>and if you had ever installed ledger in the past (and hadn't removed that profile generation), then you would also still have it. <aeva>I think I'm going to have to do this on someone else's machine for now - I think I need to fix my budget before I have the spoons to try to do this the right way >_> I appreciate your trying to help me a lot though <aeva>ah, I misunderstood - I thought I'd have to also like rebuild the entire package manager for scratch or something <aeva>I'll try in a sec - I need to eat something >_< <mark_weaver>building guix from a git checkout is not much harder, although it takes a bit longer. "rebuild the entire package manager from scratch" definitely makes it sound much worse than it really is. <mark_weaver>on another note. why do test suites *suck* so badly? <mark_weaver>an inordinate amount of my time is spent dealing with poorly written tests that fail intermittently, depending on the load on the machine, or the time of day, or fail on some platforms, or with newer versions of dependent libraries, etc. <aeva>in a coarse huristic for how bad my day is going to be, git sometimes factors unfavorably based on context lol <aeva>gonna try the thing, 1 sec ***deadrat is now known as spammerbot
<OriansJ>Finally made stage1/stage1_assembler-2 self hosting [Now I fully appreciate why no one writes code in Hex anymore] Only 2 more tools remain in stage1 :D <lfam>OriansJ: Wow! I was thinking of your project the other day. I'm glad to hear about the progress :) ***spammerbot is now known as deadrat
***deadrat is now known as Guest36833
<OriansJ>lfam: Now to decide which to convert next, the M0 Line macro program or the SET text editor; which have already been prototyped out in C ***Guest36833 is now known as deadrat
<amuck>I get "warning: failed to install locale: Invalid argument" every time I run guix <amuck>lfam: I did not, so I'll try that <amuck>I'm running it on Ubuntu as well now <mark_weaver>where are you seeing this problem? on GuixSD, or Guix on top of Ubuntu? (or both?) <amuck>I didn't get to that section of the instructions yet <mark_weaver>okay, then indeed you should look at the link lfam posted ***abbe_ is now known as abbe
<ng0>toxic is horrible and I want to punch its Makefile. <ng0>it is ignorance incarnated <ng0>I hope qtox is easier <suitsmeveryfine>Hi! I'm trying to contribute a package but get errors such as "no binary for interpreter `python' found in $PATH". Should I select a different build system perhaps? <cbaines>suitsmeveryfine, what are you trying to package, and what build system are you currently using? <cbaines>The error doesn't quite make sense to me... <cbaines>So, looking at the guix source, the error is coming from the shebang patching code <cbaines>Are there any scripts included in the package that use python? <ng0>the error is normal, depending on where the error is.. <ng0>is it a fatal error or non-fatal? <ng0>can you paste the build log? <cbaines>If the scripts should be installed, I think you should add python as a input <cbaines>Or, if the scipts should not be installed, you may need to remove them from the output <suitsmeveryfine>cbaines: I've tried to both include and not include python as an input <cbaines>This is the fatal error: /gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/bash: ./configure: No such file or directory <cbaines>The shebang warning is not fatal (and is just a warning) <ng0>there's no configure <ng0>you need to replace or delete configure <ng0>the fail in this case is the configure, not the python <cbaines>Yep, just search for (delete 'configure) for examples <cbaines>Also, thanks for looking at packaging some OpenTTD music, I've been playing it on GuixSD, and am looking forward to having some music :) <ng0>for example egrep -nr "delete 'configure" <roptat>it works perfectly well when I change libm for libpcre for instance <roptat>I have a libm.so and a libpcre.so in /usr/lib <roptat>so how does it actually work, and how does it find a library file? <ng0>no, ratox is also just in git <ng0>all my issues recently are the same "please do a release" "Makefile $feature_x is broken" .. gr <ng0>funny... i got an email from "the future", which is very odd while I am in UTC timezone.. i wonder how the person managed this :D <cbaines>suitsmeveryfine, I think you need to alter the arguments to patch-shebangs, the node package might be a useful example <cbaines>and the woof package, as that uses python <muck>got rid of the segfault by commenting out gtk test for lua-lgi ... but a few tests still fail, including all the cairo tests <ng0>what did you mean with the lua part? my lua experience is limited to the rc.lua of awesome <ng0>i think i can't package ratox.. and need to poke upstream ratox about the fact that libtoxcore changed once more <ng0>s/can't/should not.. it is dead I was told. <OrangeShark>ng0, I already went through trouble of packging qtox, but I haven't really had the chance to test if everything works <ng0>take a look at the toxic patches on the list, would be cool to get the dependency graph working <OrangeShark>qtox's qmake file was pretty bad at the time too, it hardcoded the paths to libs. I helped them fix it to use pkg-config <ng0>i tried to fix and adjust but I think I have to poke upstream or wait on upstream <ng0>i need to learn how pkw-config works though <ng0>your libtoxcore is 99.99% similar to what I have in wip <ng0>openal is now in guix master <ng0>i packaged freealut additionally <ng0>I'd put tox* into messaging, and the other packages in their related files, would be great to test qtox :) <ng0>is upstream dead, or guix version outdated? <ng0>i mean i had problem aquiring freealut, so i don't know the state of openal <ng0>random-nick: could you be more specific? <ng0>i'll try an update of your utox <ng0>is utox compatible with toxic and qtox .config/tox/ files? <random-nick>openal is proprietary, openal soft is a lgpl licensed implementation <ng0>i had an weechat addon, but it is outdate now <random-nick>but I guess most people call openal soft just openal <ng0>random-nick: this is openal-soft i meant <OrangeShark>ng0 I think utox needs a specific name for their profiles <ng0>why do you build it with openal-soft 1.17? <ng0>can you prepare a patch for your filteraudio in audio.scm ? I just started building utox here, filteraudio succeeded. v4l2-utils-1.10.1 failed <ng0>maybe there's an update <ng0>v4l-utils build in master fails. <ng0>i will try to fix that.. there was something about perl <ng0>qt has been update recently, right? <muck>ng0, which part ? lua itself needs recompiled with LDFLAGS=-ldl and and CFLAGS=-DLUA_USE_DLOPEN in order for lgi to even be imported ... or did you mean the gtx part ? <muck>i'm pretty sure thats default for most distros anyways <ng0>OrangeShark: utox builds, with the patch I just linked to which makes v4l-utils succeed. <ng0>I have pushed the version to the newest one.. maybe you can send the dependencies of it, and I send the updated utox, and put my name in co-authored? <pmikkelsen>Hi guix, I am trying to package the haskell stack tool, but I have run in to an issue <pmikkelsen>when trying to build it, an error occurs, and it seems to be some sort of stack overflow from guile <pmikkelsen>So I don't think it has anything to do with the program I am trying to build, but maybe it has somethink to do with my package having too many nested dependencies <pmikkelsen>the error i get is: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())' <ng0>OrangeShark: looks like utox needs some more dependencies to look okay in awesome-wm <ng0>the switches in config are usable but ugly <ng0>and it is not compatible with qtox+toxic config <ng0>well. it is compatible. cp $HOME/.config/IDDDDDDDD.tox utox_save.tox or whatever utox creaetes <ng0>confirmed to work. can you prepare an update patch, OrangeShark, or do you want me to do it? <ng0>well. wait. makes no sense. I update my libtoxcore patches, remove toxic for now, and you can add your utox + deps on top of that <ng0>pmikkelsen: can you provide more verbose error/build logs? maybe people with more haskell knowledge can help <pmikkelsen>I do have a guile backtrace, but where should i send it? <pmikkelsen>ng0: it seems to me like some guix internal thing, but I am not the right person to figure that out <lfam>pmikkelsen: I think there is a circular dependency between your packages. That is a common cause of a stack overflow in Guix <pmikkelsen>Oh, I am dealing with many many dependencies, so that may be my problem. I will check it, thanks! <lfam>Argh. There is now a circular dependency between the latest versions of python-pygments and python-sphinx. <lfam>I think I'm going down a similar rabbit hole <suitsmeveryfine>Hi! I get "File or directory does not exist" if I try to run binaries that I've downloaded, even if I do it as root. <lfam>gnu/build/file-systems.scm:436:7: warning: possibly unbound variable `reboot' <lfam>suitsmeveryfine: By binaries, do you mean Guix binary substitutes, or something else? <lfam>If you mean something else, then I presume that the binaries are looking for shared libraries somewhere in '/usr', and they won't find anything there <lfam>I recommend running the binary with `strace -f` to see exactly what it's looking for <lfam>But, it's probably something like what I suggested <suitsmeveryfine>lfam: I think that it's strange that the error message each time is "file or dir does not exist" <lfam>suitsmeveryfine: strace is not going to solve the problem. It's a diagnostic tool. It will show you what the program is doing and hopefully give you an idea of what's wrong <lfam>I bet you will be able to see eclipse fail to find some library <lfam>Okay, I guess the problem is with beginning execution itself. This is the end of my knowledge. But anyways, GuixSD does not claim to support execution of binaries built for other systems. I've done it with Go binaries, but those are basically statically linked and self-contained. <lfam>Maybe it's worth trying to package eclipse for Guix <lfam>I'm sure that error message is misleading, btw <lfam>I've seen misleading "No such file" messages in several cases <lfam>suitsmeveryfine: I don't know much about Java, but wouldn't the icedtea packages provide a Java compiler? <lfam>suitsmeveryfine: I think it does provide a 'javac' <lfam>Also, you might want to try `strace -f ./eclipse`. <lfam>I think you need to specify the path. strace won't look in the current working directory <suitsmeveryfine>execve("./eclipse", ["./eclipse"], [/* 55 vars */]) = -1 ENOENT (No such file or directory) <suitsmeveryfine>write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory <lfam>I guess the issue must be in "55 vars" ;) <lfam>suitsmeveryfine: The jdk output of icedtea includes 'bin/javac' <noway21>how i can install guixsd on luks partitions? <lfam>So, `guix package -i icedtea:jdk` <ng0>OrangeShark: utox works for me. I just tried in GNOME, and it is just minimal, not broken. <ng0>I've sent my updated toxcore patch <lfam>Does it do video chat? Would that make Guix's first video chat package? <ng0>theoretically it does <ng0>webcam is in the next room, and the only online contadct i have at the moment does not have a webcam <lfam>And also the outputs field of `guix package --show=icedtea` <lfam>Yeah, I don't know how I would test it <lfam>But, I think it's a valuable feature for our distribution. Many people use *bad* programs to do video chat <suitsmeveryfine>lfam: but whereis javac doesn't give me anything and the 'java' binary sits by itself <lfam>suitsmeveryfine: Did you do install the jdk output? `guix package -i icedtea:jdk` <ng0>lfam: I can try and ask the contact for testing webcam <ng0>though i have not configured v4l here <ng0>hopefully it just works <lfam>suitsmeveryfine: Also, I'm not familiar with 'whereis'. Is that like `which `? <Petter>noway21: There is support for at least some cases involving luks partitions <lfam>Okay, do as I suggested and install the jdk output :) <lfam>That should provide `javac` <lfam>A bit of a confusing, I admit. Although I think that installing a java compiler is a special use case :) <lfam>As we get more Java software packaged, maybe the icedtea packages will evolve <ng0>lfam: well.. my webcam is supported in NixOS and other systems out of the box. chat itself works, and calling people (though i just tested rining) <suitsmeveryfine>lfam: I'm just trying to learn java currently and I'm not very familiar with the tools <lfam>ng0: I think that if video chat does not work, it's okay. The package could still be added. But it's a good goal to work towards. I can help with it too <lfam>suitsmeveryfine: You probably already know more about Java than me ;) I just help keep our icedtea packages up to date <ng0>lfam: I don't want to send the patches for it.. utox and one of its dependencies is not my work.. i just version bumped it <ng0>i just sent libtoxcore, a dependency. <ng0>well I did some corrections to toxcore, which originally lurked around some of davexunit 's git repos <ng0>okay.. i can't test it because a patch for v4l needs to be applied first.. in theory it should work. <kyamashita>Does anyone know why dragging icons in the GNOME Activities menu causes GNOME to crash? <kyamashita>Or perhaps, where I'd start looking to find out? <lfam>kyamashita: Ouch! Is there anything in /var/log/messages or a similar log file? <kyamashita>lfam: Let's see! If I disappear, it's because I was kicked back to the login manager... <lfam>Remember, you can use a second TTY for a stable environment while debugging GNOME <kyamashita>I found some related info in /var/log/messages. Let me find a place to paste it. <lfam>Hm, I'm already stumped :p <lfam>BTW, we like paste.lisp.org. At least, pastebin is problematic since it apparently blocks Tor users <lfam>kyamashita: I don't know, since I don't use Tor all the time. But others have said so in this channel <Petter>With Tor I get to the CloudFlare CAPTCHA screen. <kyamashita>lfam: I just tried it and I was blocked by CloudFlare. <lfam>kyamashita: iyzsong is our main GNOME specialist. They go by 宋文武 on guix-devel <kyamashita>Alright. I can't see the characters because of my TTY configuration, but I know who you are talking about. <kyamashita>The issue seems to be with libglib, the only library mentioned in the logs. <kyamashita>I'll contact iyzsong on guix-devel and see what they think. Thanks, lfam. <lfam>Good luck. That's a bug that should be fixed! <schumaml>hi there, over in irc.gimp.org #gimp, jmd told us that he got sent there by this channel <schumaml>there is some issue with gimp finding some python modules on guix, and apparently this is due to the file system structure <schumaml>jmd claims it is the applications job to find things - like python modules - in guix# file system <jmd>Well that's a bit of a paraphrase of what I said ... <schumaml>we are pretty sure that there is some relatively easy way to tell application where to look for packages, maybe depending on the standard set of evironment variables for this <schumaml>then the only remaining issue to solve would be whether tit is the users job to set them, or if there is something in the package management process to do this <jmd>But for the benefit of the people here who didn't see the discussion on #gimp, the issue is that after "guix package -i gimp" gimp plugins fail due to missing python modules. <lfam>jmd: There is a recent commit on the master branch: 580dfc332 (gnu: gimp: Fix python plugin.) <lfam>Does that solve the problem? <jmd>Ahh then, no I haven't tried. <schumaml>jmd: and I strongly disagree with your statement of us providing "the opposite of help" over in #gimp <schumaml>lfam: part of the issue what the seemingly random directory names of guix <schumaml>can you explain how applications are supposed to find anything there? <jmd>lfam: Looking at the commit, it seems that it is the same issue. So hopefully it has fixed it. Thanks. <lfam>schumaml: By "random", are you referring to the hashes in file names like this: /gnu/store/deadbeef....-gimp <lfam>It's not random, but a hash of *all* the dependencies, down to the bootstrap, that were used to build the gimp contained in that directory <lfam>We model package building as a pure function <schumaml>let me repharse: is it gimp or guix job to make this work? <kyamashita>It's the job of Guix. Manipulating environment variables to work with our file system is a common task in packaging software for Guix. <lfam>schumaml: In general, we make it work on our end. Sometimes we do find broken upstream build systems, and we try to help the upstream project fix it. But typically not. We (and Nix, who use similar techniques) have thousands of packages, and we couldn't do it if all the upstream projects had to adjust to us <jmd>schumaml: I left #gimp just now, because I didn't want to participate in an argument. I don't want to participate in one here either. <kyamashita>schumaml: You're welcome. lfam goes into more detail and is more experienced than I am. :-) <kyamashita>schumaml: What does it look like when GIMP finds the python modules? <lfam>I don't know what happened in #gimp, but I don't want there to be a bad relationship between us and gimp. I hope we can provide a great gimp package. <schumaml>nah, I was pretty sure that everything would be like you have just confirmed <lfam>I will say that application plugins typically require a little extra from our packaging. <kyamashita>I'm updating my GIMP installation right now. We'll see if everything is in order. <lfam>Now, sometimes upstream projects use build systems that make it very difficult for us. For example, they hard-code assumptions about the filesystem hierarchy rather than using a proper build system like Autoconf, Python setuptools, cmake etc. But that's rare, because software developers typically don't want to spend their time rolling their own relatively half-baked build system from scratch. <schumaml>lfam: a summary of the discussion in #gimp would be: jmd didn't believie that it could be a task for guix to make this work, and I disagreed <jmd>schumaml: That is a total misrepresentation of what I said. <lfam>I think that when computer programmers disagree on the internet, it's usually a consequence of poor communication, rather than a real technical problem. <lfam>And, communication is really hard, especially in writing <lfam>So, we have to remember to be generous when reading each others' messages <jmd>What I said was that once the OS developers understand the application developers' intention, then the OS people can decide how best to implement it on their system. <jmd>Somebody on #gimp refused to explain things because "we should use standard paths". <lfam>Or, the build system should make it easy to use non-standard paths ;) All the major build tools do this <akk>I'm probably the somebody you're referring to, and what I said, repeatedly, was that I was sure guix must provide a way to find paths for libraries and modules. <jmd>Anyway, like I said before, I don't wish to participate in an argument. <mark_weaver>kyamashita: the same crash happens for me, and I recall some others mention it as well (davexunit and wingo, iirc). <lfam>Gimp's build system works fine for us. Plugins can get a little complicated, but I think the situation is fine <jmd>But I'm glad that somebody has fixed the problem. Saves me doing it. <ng0>can someone look at my git service? I don't know where it is failing.. this is my first service. <schumaml>jmd: we were effectively asking you (or suggesting) to check out what ways guix has to set up the environmentr for applications <schumaml>and if I read the latst change to the guix gimp package correctly, it does just this <kyamashita>schumaml: In GIMP's python console I can see the plugin directory. That is, print(gimp.plug_in_directory) returns an existing directory with a python subdirectory. <kyamashita>I've never used GIMP's python plug-in feature knowingly, as I'm a fairly pedestrian user. Is this indicative of good behavior? <schumaml>well, you won't necessarily notice if you a using a plug-in written in C, Python, C++, .. <schumaml>but if the python console work, the plug-ins written in python do work <lfam>I think the issue that spurred the commit was related to a python plugin, so at least we are improving :) <kyamashita>Oh, I just found the file in GIMP's python directory that is from today's patch. <kyamashita>mark_weaver: Glad I'm not the first to see this! Has any progress been made on the problem as far as you know? <mark_weaver>not that I know of. I don't know that anyone has sincerely tried to debug it yet. <schumaml>I wouldn't have solved it like this, but maybe adding a python file to modify pythonpath is guix' way to handle this <lfam>schumaml: How would you have solved it? <schumaml>shell script to set up the environment and run gimp, and pass all parameters to it <schumaml>whether this is feasible for guix I can't tell <lfam>schumaml: We do that sometimes. We call them "wrappers". <lfam>TBH I'm not sure what the pros and cons are in this context <lfam>Actually, all Python software in Guix is wrapped that way. <lfam>The Python wrapping happens automatically as part of our abstraction on the Python build process. <schumaml>then it would be best to keep your standard <lfam>But, plugins make it complicated :) <lfam>Unless you think our solution to GIMP plugins is dangerous or broken, I think we will keep it <lfam>GIMP is not wrapped in this way since it does not use our python-build-system <schumaml>well, you could change the default.env file and add your specific PYTHONPATH there <schumaml>this is what I'd expect distros to do if they use non-standard paths <lfam>I'll send an email to our development mailing list with the suggestion <lfam>If the default.env solution has the same effect as our current solution, I'd favor it, because it will probably be more "maintainable" by less skilled Schemers <roelj>ng0: About the gparted patch.. I'm still stuck at implementing a hook for the documentation stuff.. <roelj>ng0: The patch provides a "working" gparted, except for the help function. <lfam>roelj: I think it might be okay for now. Do we have another graphical partitioning tool? <lfam>I think we should add the package as-is. In my opinion, everyone should know how to partition their disks from the command line, but many people disagree :) <jmd>I wonder how sensible it is to have the user's profile in $HOME ? Since oftern $HOME is a network mount. <lfam>sapientech: Your email address in 'gnu/packages/python.scm' is <sapientech@sapientech@openmailbox.org>. Is that correct? <roelj>lfam: So should I go on and push the latest GParted patch? Or should I revive the discussion on the mailing list> <lfam>Is <sapientech@sapientech@openmailbox.org> even a valid email address? <Petter>It's valid to have @ in the username, yes. But it certainly looks like an error. <ng0>recently I learned even *@host.tld is valid <ng0>i mean the literal "*" <ng0>there's a file which starts with an empty line in gnu/packages/ ... but every time i work in it, i forget to fix it <Petter>Looks like it's not valid, because the @ in the local part isn't quoted. <rekado_>I see that there’s a more recent version of Epiphany/Web than the one we have in Guix. Is 3.20.x a stable branch and 3.21.x a devel branch? <Petter>Cool, hopefully this fixes Epiphany for me. Current version has been buggy for me. <rekado_>seems to be “unstable” – it depends on an “unstable” webkit release. <kr2>Hello, to configure X11, do I have to add (slim-service #:startx ...) and remove the slim service from %base-services, via a filter for (not (equal? 'slim (service-type-name (service-kind service)))), or is there a better/easier way to do this? <rekado_>so I’ll just upgrade to epiphany 3.20.3 <ng0>i have to see if my xml patches still apply with that 1 line moved <rekado_>oh, just wanted to respond to kr2 :( <random-nick>Is there a list of differences somewhere between Nix(OS) and Guix(SD)? <lfam>random-nick: Not that I know of, but we'd be happy to answer questions from our point of view <rekado_>Petter: pushed an update for Epiphany. It’s just a patch release, but maybe it contains a fix for your problems. <random-nick>lfam: well, I'm more interested in the nix side since I don't know much about nix, I should probably read its manual <ng0>I found the documentation less complete <ng0>I started using NixOS this week <lfam>random-nick: I would read "Nix: A Safe and Policy-Free System for Software Deployment" by Eelco Dolstra et al, and then "Functional Package Management with Guix" by Ludovic Courtès. Those papers will introduce you to the functional packaging model, and clarify some of the improvments made in Guix <roelj>What's the change in the sourceforge mirror uri? <roelj>I cannot build GParted anymore because it cannot download the source code from sourceforge.. <lfam>roelj: Do you mean "What did SourceForge change about their URLs"? ;) <lfam>roelj: Check cd4c41fdcf469524161fbbec58c2756f36bcef56 <roelj>lfam: Thanks.. That's what I meant.. <lfam>roelj: Also de67e922885baf68a746a0484ca0b45e45b0964b <lfam>They shuffled lots of things around <ng0>also some might still be in project while we use projects in the mirror:// <roelj>Mine seems to be in 'projects' <roelj>So that should be fine, right? <roelj>I now have: "mirror://sourceforge/gparted/gparted-" version ".tar.gz" <roelj>But that does not seem to work <ng0>could you check on the web site if it changed? <lfam>roelj: Begin your string after "projects/" <lfam>Oh, I see. It's a project / projects things <lfam>Anyways, *if* the correct 'project' word was used, your string would need to start with 'files/...' <lfam>Or, with the first gparted. I'm sorry for being so confusing. I am having flashbacks about the last time SF changed all their URLs <lfam>And then denied changing them... <ng0>but mirror://sourceforge only includes *projects* not *project* in the mirror:// part... right? I ran into this problem with tintin++ <lfam>So, we can't use the mirror:// system <ng0>can't we make the mirror flexible? if projects does not return 404 use it, else use project ? <lfam>ng0, roelj: I think you should use a regular URL that hits SF's load balancer, mentioned in this commit: fe224d20cccd6500cdc823899070d2c46fe59ad3 <roelj>But then there's no load balancing across mirrors, is there? <lfam>roelj: I'm suggesting you use their load balancer, which is what our mirror system does. <lfam>Our system only uses the mirror list if their load balancer doesn't respond <lfam>I think we should not puch much energy into our SF mirror system right now. I want to wait and see if they change everything again. As I said, their support claimed that *no* changes had been made. So, it seems like they are disorganized, and I don't want to put more energy into riding their wave of chaos <lfam>Of course somebody may work on it, if they want to. But nobody else wanted to last time :) <roelj>This seems to work: mirror://sourceforge/gparted/gparted/gparted-0.26.1/gparted-0.26.1.tar.gz <lfam>And it's not using the cached tarball in your /gnu/store? <roelj>No, because it really starts downloading, and I don't have this version anyway. <roelj>Could you try it? guix download mirror://sourceforge/gparted/gparted/gparted-0.26.1/gparted-0.26.1.tar.gz <lfam>roelj: It downloaded a file whose hash is 1h9d6x335wxpm49yphzm9n1hbh2hcg0p2rphv76mrvsss91bcm1g <roelj>lfam: Thanks. I get the same hash. <lfam>Great. Lots of fun, huh? ;) <roelj>Should I now replace "gparted" with "name" everywhere in the uri? <lfam>It's a matter of taste I think <roelj>It looks kind of funny: (string-append "mirror://sourceforge/" name "/ "name "/" name "-" version "/" name "-" version ".tar.gz") <lfam>Yeah, it's hard to read, but then again, it's not a "real" HTTP URL. And the other way is not that easy to read either <roelj>I see I didn't do that in the old patch. <lfam>When I fixed all the broken SF URLs, I did not have a consistent approach to this <lfam>Yes, I don't think we have any policy <ng0>what would be a short, but precise explanation why just using a git commit is not satisfying enough for releases, ie why do we want a tarball? <ng0>I've done a basic explanation already <ng0>but it wasn't enough for them.. <lfam>How are packagers supposed to know which Git commit to use? Do they have a policy that says "all commits on master are okay"? <lfam>I don't have a clear or precise reason. If they want us to package a Git commit, that's their choice. But all the different distros will end up packaging different commits, which seems suboptimal. <ng0>that's what happens currently <lfam>It will become harder for security advisories to announce which versions of the software are okay, since hashes are not something that sort chronologically <lfam>Or logically. It doesn't make sense to sort hashes at all <roelj>Maybe something along the lines of: A developer (hopefully) puts thought and care into making a release, marking it as a definite point to build on. Developers generally do not put the same care in git commits, because bugs introduced in them can easily be fixed with another commit, or worse, by amending a commit (changing its commit ID). <lfam>I think we should just package the latest commit. If it's broken, we file a bug report. <ng0>i know libtoxcore $head works, because that's what my patch uses ;) <ng0>but I dislike testing into the blue of software which I do not know every inch and line <lfam>Although they should never amend public commits, *especially* if they want us to package them <lfam>That would be really perverse <OrangeShark>ng0: I think people have tried before to get them to make releases, but I think toxcore still doesn't consider it stable or anything to make a release <roelj>lfam: Yeah, I know.. But I don't think many people consider our effort of packaging their software when doing funny stuff like that.. <ng0>maybe when enough people annoy them over time they have been presented with enough reasons for "why" <lfam>roelj: You're right. But even for the sake of their own colleagues within the Tox project, they shouldn't rewrite public history <roelj>So maybe the argument should be more that a release brings a certain guarantee to users that that point in time can be used and tested by others. <roelj>By the way.. I built gparted-0.26.1 succesfully, and it looks like it works (except for the help function). Should I push it? <roelj>It's a newer release than the patch I provided earlier <OrangeShark>I think a lot of the other projects just checkout the latest commit of toxcore <ng0>in another project we used the commits which marked version releases, and hardly used release files of upstream <ng0>but the commits had no verifiable hash, just the commit id and that's it <ng0>i'll be afk. good night <lfam>roelj: If the only change from your earlier patch is the updated version, I'd say it's okay to push