<rain1>Maybe the best solution would be a complete update of icecat <jlicht>rain1: what is wrong with icecat? afaik, it is based on a "lts-like" release of firefox, and gets regular security updates as well <jlicht>All I am missing is the ability to use guix to manage my add-ons :) <rain1>for me personally I just want the newest version of firefox (potentially rebranded, so it can be included in guix) <apteryx>jlicht: +1, icecat is as good as firefox in my daily usage, and thanks to the hard work of Mark Weaver, it also gets patched for security. <rain1>that's a neat idea that guix could manage ff addons! <rain1>ok so perhaps the idea of making icecat base off the latest ff is not the right path then <apteryx>rain1: if you have the manpower to maintain it, I don't see why we couldn't have a icecat-next that'd track newer firefox <jlicht>rain1: well, it would of course always be nice to have the option to do so, but it does not seem to be a focus area for upstream icecat devs. In that sense, if you are willing to make it work, it could definitely happen :) <jlicht>what apteryx said, pretty much ^ <rain1>I would like to contribute something smaller first though, I wonder what i could do <lfam>Part of the issue is that there is not really an "upstream" icecat project with a lot of resources. It's basically one or two people working as volunteers ***astronavt_ is now known as astronavt
<bandali>hi, could someone please enable python3 bindings for the z3 package? <bandali>as of now, z3 only includes ,python-2 in native-inputs <marusich>bandali, perhaps you could try customizing the package definition to install the python3 bindings? <marusich>You would need to create a new package definition that uses python-3. Judging by the package definition for z3, you would probably need to do the following things in your new package definition: (1) use python-3 in the native-inputs instead of python-2, (2) replace the string "python" in the bootstrap phase because python-3 provides no binary named python (it only provides "python3" etc.), <marusich>and (3) change the configure flags - specifically you would probably need to replace "/lib/python2.7/site-packages" with something more appropriate for python3. <marusich>This is, of course, assuming that the z3 project supports python3. <marusich>If you get stuck, ask for help. The community is helpful, but sometimes the fastest way to get something done is to try it yourself. It may be faster than waiting for someone to do it. <marusich>If you have questions, I'm sure someone here or on the guix-devel@gnu.org email list can lend a hand. <epimrphsm>The package I am trying to build has several shell scripts for the build pipeline that reference /usr/bin/env. What is the proper way of handling this with Guix? <epimrphsm>Should I substitute /usr/bin/env to (which "env")? <epimrphsm>I've noticed that this is done automatically for /bin/sh, if I understand the output of `guile build` correctly <epimrphsm>oh i see the problem, patch-shebang doesn't work in this case because /usr/bin/env does not occur as a shebang at the beginning of hte file <epimrphsm>wtf why would you write `/usr/bin/env awk ...` in a shell script D: <cbaines>epimrphsm, using env is normally undesirable, as in many cases you want to use a absolute path to the thing in the store <cbaines>for example, I would suggest replacing /usr/bin/env awk with an absolute reference to either awk or gawk in the gawk package <brendyyn>'s build phases have a patch-shebangs phase <brendyyn>and yes basically you replace them with direct paths <epimrphsm>cbaines: yeah, I don't know how to do that properly unfortunately. i just ended up replacing `/usr/bin/env ` with an empty string in this particular file, and now it build sucessfully <brendyyn>there are plenty examples in the repo if you look <cbaines>epimrphsm, I'd usually use the substitute* function. I'm guessing you might have used that to replace it with the empty string? <epimrphsm>cbaines: yeah, I am currently trying to use (substitute* "build_tools/build_commands_hdr.sh" <epimrphsm>but it doesn't seem to work; trying to investigate why atm <epimrphsm>uh-oh D: i think that is indeed the problem brendyyn <cbaines>Maybe it's coming from the build system <cbaines>I bet the gnu-build-system directly or indirectly provides gawk <cbaines>So, yeah, if you're using the gnu-build-system, you don't need to (and probably shouldn't) specify gawk as an input in the package <brendyyn>I wonder if those packages are wrong to not include awk then? <epimrphsm>aah the problem was that I was doing the substitution business inside a `(snippet)` instead of modifying the build phases <rain1>applying substitute* on the bash script source code is one way <rain1>but there is a slightly better, wrapping PATH to provide these binaries <rain1>the password-manager package does this for reference <myglc2>Hi. I'm getting 'guix build /gnu/store/..-info-dir.drv' >> "ERROR: In procedure scm-error: <myglc2>no code for module (guix build utils)" using Guix from Git v0.16.0-131-gce3fef9fc. Any idea why? <pkill9>brendyyn: the package is password-store <rain1>There is a plugin for firefox/chrome called decentraleyes which contains local copies of common cdn scripts <rain1>adding this to icecat might be good <brendyyn>I think we should always have a core Icecat that deviates minimally from Firefox. Something likethat could be added as an extra package perhaps <rain1>I think that's a good idea but I am hesitant to work on that because I heard there is serious difficulty packaging the rust parts of the latest firefox <rain1>there may need to be communication with the rust/cargo team on the networking part of the build process (if there is no sane workaround to provide offline copy of the files) <rain1>im am wondering about some much easier short term contribution i could try making, any suggestions or place I could look? <brendyyn>rust is already packaged isn't it? We have Icecat 60 <brendyyn>rain1: You can look at TODO's in the code, or find an out of date package and update it <rain1>rust is packaged. i was working on replacing the binary seed with a mrustc bootstrap build but I did not manage to compleet it <rain1>the task is very difficult because of how long ti takes to do each test build <rain1>(this is unrelated to ff though) <rain1>I'm struggling to package a program that uses SDL <rain1>ive been looking at examples in games.scm <rain1>and I was able to get it to build but it fails on linking <rain1>SDL_LIBS ?= $(shell $(PKG_CONFIG) --silence-errors --libs sdl2) <rain1>the makefile does this, so I think pkg config is not finding the .pc files inside the sdl-union <rain1>thre's what I have so far, adding LDFLAGS didn't help <bandali>could someone please tell me in which section of the manual using a local guix repo is described? <bandali>i have a local clone of the guix repo, and i'd like to test my changes to one of the package definitions before submitting a patch <rain1>thanks pkill9, that wont help here because this codebase has no ./configure <pkill9>oh ok, i just realised it may not help anyways cos it looks like you did something similar anyways <rain1>with CFLAGS i have got the include path bit sorted, but it breaks on linking now -it cant seem to find the libraries <rain1>but it must be failing to invoke them or maybe they don't give correct results <rain1>I tried setting PKG_CONFIG_PATH to point to the sdl union derivation + /lib/pkgconfig but that made no change <rain1>frustrating.. i tried everything I can think of. I would probably have to edit the makefile itself to do this <rain1>I use guix envirnoment to get into the build env, and $ pkg-config --libs sdl2 is actually giving correct results <rain1>Where do I get 'ldd' on guix? <rain1>how do I put % codes into a URL in method url-fetch uri? <bandali>is there a convenient way to have gnu-build-system not pass --enable-fast-install? <rain1>bandali: from grepping guix sources, the only way I see to achieve this is to replace the configure step with invoke system* "./configure" <pkill9>what url are you trying to put in rain1? <pkill9>that will convert all the %'s into what they represent <j3kyl_>are functions originated from LISP or they existed in earlier PL as fortran tclp.. [17:57] <apteryx>rain1: I think because SDL is dynamically loaded (at runtime), not linked <apteryx>you'll have to patch instances of dlopen or such (SDL_open?) <apteryx>look for examples of patching dlopen in the packages sources <bandali>rain1: thanks, that's what i figured too. i wish there were a more convenient way to specify the options <rain1>perhaps we can modify gnu-build-system to make this an optional thing