<rekado>wigust: can perl-moo use perl-strictures version 2? <wigust>ACTION saw perl-moo source tarball <wigust>I try to get perl-moo version 2.003004 which could be build against perl-strictures version 2, but my dns provider gives a stupid html to me <wigust>ACTION hopes it could be build against perl-strictures version 2 <wigust>rekado: Hm, patching… Could be a solution, thank you! <wigust>moo version too uses strictures 2 <wigust>but I cannot check the build until resolve my dns issue <wigust>or change a url in the package recipe <dieggsy>How does one use url-fetch/zipbomb with gnu-build-system? i'm attempting it but it seems it can't find any of the files in the unziped dir <dieggsy>definitely seems possible per the example of crypto++. Does it have to unzip into the files themselves and not a directory? <adfeno>dieggsy: try to make the recipe print the contents of the current directory before it fails. <adfeno>If I'm not mistaken, the "/*bomb" variants don't assume that the archive has only a directory inside. <dieggsy>adfeno: so i may have to chdir into the resulting directory or something <adfeno>While those which don't have "/*bomb", they always chdir to the first *path* (not always a directory) it finds. <adfeno>I once caught my recipe attempting to chdir to "Makefile" :D <adfeno>2018-01-28T22:02:57-0200 <adfeno> While those which don't have "/*bomb", they always chdir to the first *path* (not always a directory) it finds. 2018-01-28T22:03:27-0200 <adfeno> I once caught my recipe attempting to chdir to "Makefile" :D 2018-01-28T22:03:50-0200 * adfeno hates (zip/tar)bombs <dieggsy>adfeno: oh, well. that's odd, since i know the output of unzipping this particular file is a single directory <adfeno>and does outputting the directory list beforethe failure actually shows just the directory? <dieggsy>adfeno: oh, those that _don't_ have a bomb chdir into the first path <lfam>This is weird. If a package's hash is "pppppppppppppppppppppppppppppppppppppppppppppppppppp" (that's 52 Ps), Guix instead prints "1ppppppppppppppppppppppppppppppppppppppppppppppppppp" when reporting a hash mismatch <Apteryx>is it legit to use (use-modules ((module1 ...)) inside a function (such as lambda)? <dieggsy>Apteryx: try it? I did this earlier today and it seemed to work. <Apteryx>yeah, I'm trying it but I don't seem to be able to gather much clues from mcron about it. It was compiling the snippet of Guile which was saying 'possibly unbounded symbol http-get' which led me to that. <Apteryx>Can someone confirm if I need 'with-imported-modules' to use guile's builtin modules in a gexp? I was thinking that no, but I'm not sure anymore. <Apteryx>seems like a Guile mismatch between mcron's guile and guix's guile <Apteryx>yeah, so the issue seems to stem from using Guile 2.0. There I get an error 400: 400 The plain HTTP request was sent to HTTPS port. Apparently the http-get method did not support https back then (Guile 2.0). <Apteryx>I'm now trying to build mcron/mcron2 with guile-2.2 <dieggsy>What exactly is the criteria for a package to be upgraded through guix package -u ? I'm tring something where i store package metadata outside of the module declaration and read it in, but changing the metadata file doesn't seem to trigger an upgrade <Apteryx>dieggsy: I think you'll want to study package-derivation in (guix packages) <Apteryx>if the resulting derivation differs from the prexisting one, that'd trigger an update (my understanding). <dieggsy>Apteryx: so what i'm seeing shouldn't happen. i'm changing an external file from which e.g. (version ... ) and (sha256 ..) are read <Apteryx>dieggsy: what exactly are you doing? ./pre-inst-env guix package -u your-modified-package? <dieggsy>Apteryx: just guix package -u my-modified-package <Apteryx>what guix is that? the one from 'guix pull', or some guix you built from the sources? <Apteryx>and how do you make guix aware of your-modified-package? <dieggsy>Apteryx: for example, i have a file version.txt simply containing the string "2.5", and in my module i (define (get-version) (read (open-input-file "version.txt"))). A package in that module has the specification (version (get-version)) <dieggsy>(it's a bit more than that, but as a very simple example. same goes for sha256 and uri etc.) <Apteryx>OK, I see what you are doing, but I still don't know how you are making guix aware of that module of yours <dieggsy>When i change the file version.txt, and confirm that (get-version) is in fact reading that change (just sticking (display (get-version)) in the module file somewhere, running guix package [anything] prints the new vesrion), then run guix package -u, nothing actually happens <dieggsy>Apteryx: it is aware through GUIX_PACKAGE_PATH <dieggsy>and i know it's aware, i can see it print changes as in the above example <dieggsy>yeah, i'm confused because AFAIK i'm definietly changing the package definition <dieggsy>Ok, i'm changing the values directly and it's not updating. now i'm really confused <Apteryx>I guess you can't use run-time obtained information for package fields. <dieggsy>Apteryx: why would it not be throwing an error then <dieggsy>Apteryx: besides, there's official packages that do stuff like (string-append in their version slot <Apteryx>I'm not sure; maybe ask on the guix-help mailing list, it's an interesting question :) <dieggsy>Apteryx: i suspect something else is going on now cause changing directly does nothing either <dieggsy>Apteryx: do versions need to follow a certain logic <Apteryx>dieggsy: I'd think the version numbering needs to increase. <Apteryx>or stay untouched (if making fixes to the guix package of that same version for example) <atw>That is what the manual section "Version Numbers" suggests <Apteryx>atw: did you end up being able to manipulate the inputs of a package using alist operations? <Apteryx>I'm attempting the same right now :) <dieggsy>Hmm, so i can't just have the version _and_ the source change together? <atw>Apteryx: (inputs `(("emacs" ,emacs) ,@(alist-delete "emacs" (package-inputs emacs-ess)))) is what I ended up with <dieggsy>atw: you know. that was a good section to point me to, heh :) <Apteryx>dieggsy: why not (if version is going upward) <dieggsy>Apteryx: I'm pretty sure my issue has something to do with me essentialy not following any version convention at all - the version was determined by the somewhat arbitrary first few numbers of the git sha. the section of the manual atw pointed me to mentions the formal way to point to git snapshots, so i'm betting if i follow that it'll work. but, we'll see <atw>dieggsy: yeah, the docs imply that you have to have something that lexicographically sorts <dieggsy>atw: i mean, don't all strings lexicographically sort <atw>I'm not sure if there's a bit of the manual that says that more authoritatively <atw>well, sorts lexicographically into version order <Apteryx>dieggsy: yes, if you follow the manual's way to make versions from git commit numbers, it'll work. <Apteryx>there's even a function for it in (guix download) <Apteryx>atw: thanks, alist-delete is what I was looking for <Apteryx>I'm glad you're now part of the Guix community, you used to help me in #emacs and now in #guix, eh! :) <atw>And I think it was you who first told me about Guix, plus you were a factor in causing me to get a Purism <atw>speaking of #emacs, I have to fix my nickserv auth. It's one of the remaining broken things since switching to guix :P <Apteryx>that's cool! getting settled I see :) <atw>slowly -- I have 5 years of cruft on my old machine and I'm using the migration as an opportunity to clean up <dieggsy>Apteryx, atw just wanna say thanks for the help and patience, heh. I'm testing now, but regardless. <Apteryx>I've been running GuixSD as my main since october 2016 I think. Start was a bit rough, setting up a minimal but functional desktop with ratpoison, but now I'm quite happy! <atw>Apteryx: going to FOSDEM? <atw>ah darn. Maybe catch you next year <Apteryx>atw: there will be a Guix meeting on the day before FOSDEM I read on the ml, are you joining them? <atw>I'm curious to hear the talks and I want to talk to people about java/maven packaging and other things <Apteryx>ok :). Sounds fun. I hope to join the fun next year too! <g_bor>I've seen a definition touch file in rust.scm. <g_bor>It is quite trivial, but we might consider moving it to utils, as it seems to be generally useful. WDYT? <marusich>civodul, hi there. Quick question: do you know if "guix pack" is intended to support cross compilation of the self-contained Guix tarball? <marusich>Since "guix pack" has a --target option, I think it's probably intended to work with cross compilation in general, but it wasn't clear to me if one can expect it to work for cross-compiling a self-contained Guix tarball (for a supported target system) <marusich>I have not tried to do it yet; I'm building other things right now, so I was just curious. <civodul>marusich: in theory 'guix pack --target=X guix' should work <civodul>in practice i'm not sure Guix and its dependencies can all be cross-compiled <civodul>on the build farm we only check cross-compilation of core packages, not Guix itself <marusich>yeah I just peeked at the source for "guix pack" also, and it looks like in theory it ought to work. <marusich>I've had a lot of trouble cross-compiling, particularly the bootstrap-tarballs. <marusich>I did figure out a way to work around it by pulling out a really old computer I had installed an old version of Guix onto, and using that to successfully cross-compile what I needed. <marusich>I have no idea what the error message is trying to tell me, or how to begin debugging it, so currently I am trying to do git bisect to see if I can figure out when that (those, multiple?) regressions were introduced. <marusich>Anyways, thank you for confirming my understanding regarding "guix pack".\\ <marusich>I've also noticed that we put only some of the binaries/tarballs from the bootstrap-tarballs into the Guix source tree. We store the others on a server and download them when building the world. <marusich>What is the rationale for including some, but not all, of them in the Guix source tree? <marusich>It seems to me like if we do not include all of them, we should just download all of them, rather than checking in multiple megabytes of binaries into the source tree. <civodul>marusich: this is "historical" and no longer the case in core-updates, where everything is downloaded <civodul>the rationale was bootstrapping: we needed an HTTP or FTP client before we could start downloading <civodul>the "Bootstrapping" node mentions that, i think <marusich>I expected that if we do not check inall of the binaries, we should not check in any of them, since they are all large and all equally essential. <g_bor>I've just managed to finish a project that was started at the Reproducible Build Summit in November. It was janneke's idea, to try to build gcc with gcc and clang as the bootstrap compiler, and produce bit by bit reproducible image. Now this is done. <g_bor>I have also posted this to the mailing list, with a reference to the repository with the code. <civodul>this is pretty much the grail, kudos on this <pmikkelsen>hi guix, what is the preferred way to develop golang applications on guix? I have installed to "go" package, but running 'go install' in one of my project dirs fails to complete because it tries to recompile (or compile) some files in the store. <civodul>lfam knows Go quite well, i think, so perhaps they have an answer <civodul>i guess the current focus has been mostly on building Go programs with Guix, and not so much about using Go "the normal way" <pmikkelsen>Allright I will do that, thanks. That was also my understanding, and I see the reasons for that, but I just wanted to know if there was a good solution for development :) <civodul>maybe we still need to patch 'go' so that 'go install' does the right thing <civodul>efraim: on the overdrive, guix-daemon sometimes seems to hang in select(2) while waiting for the build process' stdout/stderr <civodul>did you experience things like that? <efraim>No, I never could get offloading to work, but its been a while so I don't remember what I tried <efraim>We did do offloading from your machine to my odroid though <ng0>just as I suspected from my builds with the rc's of mainline, 4.15 of linux (once linux-libre releases it) might become a problem for our initrd, if it has the same content like the tarball released today. nvme.ko is still missing <ng0>the rest of the modules are still there <efraim>license files get installed to $out/share/doc/package-name+version/ ? <ng0>normally they are simply neglected.. as least to my knowlecge unless Ididn't get some recent memo <ng0>we could start putting them there <efraim>I have some READMEs in $GUIX_PROFILE/share/doc/(package-name)/ <ng0>anyway, we have kernel/drivers/nvme/{host,target} in the new released kernel so far but no nvme.ko in the entire output for linux. I suspect as linux-libre will base on this that it'll be the same. I'll read into the nvme.ko disappearance <ng0>probably because the README is part of make install files then <efraim>files beginning with not 'N' would be (find-files "." "^[^N]") <efraim>I was missing the initial carrot before, finally got it <ng0>I still don't understand you. <efraim>I wanted to find all the files in a directory that specifically didn't start with a 'N' <ng0>as a reference to what I was talking about, since I assume most of you don't build linux.. https://ptpb.pw/cd8g didn't change very much since rc3 or 5 with regards to the 'grep 'nvm'.. we include nvme.ko which has now gone AWOL.. I'll send a mail once I know about its new whereabouts or how to deal with this <efraim>I try not to build the kernel on any machine I have running GuixSD :P <ng0>it's not of a general support kind of thing, but rather "look, I ran into this and you will too".. :) <efraim>The license file in culmus is a pain, it has the header of the GPL2 and then lists how each font has an embedding exception, has parts borrowed from MIT code or bitstream, or just copyright, sounding like all rights reserved but actually meaning plain gpl2 <efraim>the package license should be (license license:gpl2))) ; except for when it isn't <civodul>rekado: could there be firewall issues between overdrive and berlin? <civodul>like constraints on packet sizes, bandwidth, ssh, or something <rekado>and it’s tedious to figure this out, but I can ask. <efraim>the latest diamond is failing on all non-x86_64 architectures <ng0>I guess it's still a mainline release and not a 'stable' branch release <ng0>nvm what I wtrote then. I guess there's still changes coming <rekado>civodul: I opened a ticket with IT to get clarification on the firewall restrictions that are in effect for this server and/or SSH connections from/to machines in the DMZ. <rekado>I found that our pypi importer has lost much of its utility as few of the packages I tried to import come with a requirements.txt file. <rekado>as a result none of the dependencies are recorded. <rekado>maybe it should fall back to parsing “install_requires” of the setup.py file? <civodul>i'm not 100% sure networking is the cause of the problem, but it's fishy enough <civodul>rekado: re pypi, it also parses "wheels" files, no? <civodul>perhaps we could make requirements.txt optional <Apteryx>I just realized that maybe the slowdown of guix on my system is caused by bayfront still being in my list of servers. <Apteryx>I think it doesn't even ping anymore, so it probably induce some timing out. <Apteryx>it'd be helpful if Guix was a bit more talkative here; there's nothing print at all about that, it just hangs for while with no output. <civodul>and yes, bayfront has been offline for a few weeks <civodul>we'll be setting up a replacement within a week or so ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | FOSDEM: https://gnu.org/s/guix/blog/2018/meet-guix-at-fosdem-2018/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://hpc.guixsd.org'
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | FOSDEM: https://gnu.org/s/guix/blog/2018/meet-guix-at-fosdem-2018/ | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://hpc.guixsd.org'
<rekado>does anyone here know how to configure ZNC/ERC such that private messages are replayed when I connect on a different machine? <rekado>my workstation in the office usually receives these private messages and I don’t see them when I connect with my laptop. <rekado>only the channel buffers are replayed. <rekado>so I don’t see any private messages until I’m back at the workstation, which is pretty inconvenient. <rekado>I don’t know. I use ZNC on my home server to stay connected to all channels. With my laptop I then connect with ERC to my home server instead of freenode, and it replays past communication — with the exception of private messages. <rekado>I just hoped someone experienced the same problem and found a solution. <rekado>y’all just connect directly, huh? <efraim>Apparently there's an irssi plugin that can connect to quassel if you don't want a GUI client <kmicu>rekado: I am not connecting directly, but I also do not remember whether a weechat relay can replay private messages. I assume it can, b/c I see logs from private chats with '**** Beginning/End of log ****' messages. (I am not using weechat anymore, so cannot check for sure.) <kmicu>(PS you can use weechat relays and stay in Emacs thanks to weechat.el mode) <rekado>thanks for the pointers everyone! <rekado>I need to deal with the customs again… :( Laptop is still stuck there. <efraim>I've thought about getting my import license so I have more leeway with customs <efraim>I once had DHL call to tell me they wouldn't deliver to my house and offered to meet me on a street corner <rekado>I only have tomorrow and the day after to clear customs; this is going to be tight. I don’t even know what to do. It’s a mess. <jlicht>rekado: which country's customs are we talking about here? <rekado>the delivery needs to be “registered” with the customs and that seems to be a really difficult process <jlicht>good to know, I might move there in the next few years <adfeno>rekado: I use ERC directly, no ZNC, but if I need to stay connected, I put my Emacs in server mode and launch a client in GNU Screen, and have SSH enabled for key-based authentication only. So when I'm in other computer (or phone) I can login in SSH and reattach GNU Screen. <adfeno>sneek: tell dieggsy {tar,zip}"bombs" are called this way because when one extracts the archive their contents spread everywhere immediatelly. <sneek>dieggsy, adfeno says: {tar,zip}"bombs" are called this way because when one extracts the archive their contents spread everywhere immediatelly. <adfeno>sneek: later tell dieggsy {tar,zip}"bombs" are called this way because when one extracts the archive their contents spread everywhere immediatelly. <wigust>ACTION sended an installable licensecheck \\o/ <adfeno>I do need that. I've been slowly working on the evaluation of that big thing called Chromium for the past weeks. <chewzerita>Hey all! Has anyone had luck installing rustup on guixsd? <bavier`>hmm, I have a package test that fails on aarch64 when built with the default gcc@5.4.0 but passes with gcc@7.3.0 <bavier`>I suppose knowing whether the issue is in the test or the library is important now <catonano>a few months ago I mumbled about how the Guile stacktraces could be improved. Now I happen to have run some Clojure tools after a long time and I can offer this picture https://imgur.com/a/78x8O <civodul>it might be a better choice to edit config files in our installation image <civodul>from the commit log it seems to do Lua syntax highlighting <civodul>well dunno, maybe i'm overinterpreting :-) <lfam>I think the installation image should have a fully configured Vim with lots of plugins ;) <lfam>And I think we can drop zile ;) <adfeno>I use nano by default when `guix edit'-ing <civodul>i think we need something that does syntax highlighting and paren matching <lfam>Paren matching is the most important thing IMO <adfeno>... but my version of nano has none of what civodul described, although I didn't research for how to do this yet. <civodul>are we missing a build dep or something? <bavier`>w/ my nano@2.9.2, I can't seem to see any syntax highlighting <rekado>ACTION fixed selinux build failures on i686 <rekado>civodul: about the script: can I just refer to it as @file{etc/guix-install.sh} in the manual? Or should we link to it on the web, so that people can fetch it from there when they read the manual online? <dieggsy>how do i recompile files that i'm told "newer than compiled" about <sneek>Welcome back dieggsy, you have 1 message. <sneek>dieggsy, adfeno says: {tar,zip}"bombs" are called this way because when one extracts the archive their contents spread everywhere immediatelly. <civodul>rekado: it could be @uref{...} with the cgit URL maybe? <bavier`>I think maybe nano doesn't search the correct directory when loading its syntax files <bavier`>they're installed to pkgdatadir, but the code looks like it only looks in sysconfdir <catonano>dieggsy: are you building Guix ? Maybe just run make. <dieggsy>catonano: no, it's about custom recipe files in GUIX_PACKAGE_PATH <bavier`>if you put e.g. 'include "/gnu/store/...-nano-.../share/nano/c.nanorc"' into your ~/.nanorc you can get C syntax highlighting <catonano>dieggsy: then just erase the old compiled file by hand <dieggsy>catonano: huh. how does compilation happen? <ng0>wasn't this public knowledge that nano has syntax highlighting? I found a syntax highlighting repo for it a couple of years ago <catonano>dieggsy: I don't now, I have a similar warning in my terminal, it's been a few months now. I just can't bother about learning the guile machinery <ng0>maybe I have it someewhere in my offline repos or in backups <ng0>could even throw in g-exp in there and include a nano guix.nanorc in guix <dieggsy>lol, just imported _all_ ripgrep cargo dependencies (recursively) into a custom module, guix package -A ripgrep is taking _forever_ <ng0>did you fix rust-build-system, or why so optimistic? <ng0>some parts of it still don't work <dieggsy>ng0: huh, does cargo-build-system not work <ng0>at least to my knowledge <dieggsy>ng0: ah, well, i did not know this :) <ng0>or at least emails.. one moment <ng0>ACTION is still sitting on 100 crates <ng0>wrt nano highlighting: it needs to go into ~/.nanorc <ng0>or like a line lik ethis: <ng0>include /usr/share/nano/* in ~/.nanorc <dieggsy>ng0: what's the differenec between rust-build-system and cargo-build-system? <ng0>"include /usr/share/nano/*" in the file "~/.nanorc" <ng0>uh. I'd have to check out changes, apparently there have been some in rust.. <ng0>ah so it is called cargo-build-system <dieggsy>ng0: not sure i actually follow the issues <bavier`>ng0: I see the relevant line in the sample.nanorc. I'm guess I'm surprised that it doesn't work out-of-the-box <ng0>dieggsy: try and see at which points it fails <dieggsy>ng0: well, it failed just reading the file (no installation or anything, just reading my custom crates file, i think). something about MAX_HEAP?