<ecbrown>cbaines: same error :-( oh well, will probably abandon this "approach" <safinaskar>i just have read that guix 1.1 halved binary seed <safinaskar>some blog post, describing heroic attempts to halv binary seed <joshuaBPMan>Hey guix, I'm trying to specify to the meson build system to use meson version 0.51.2. <joshuaBPMan>(arguments #:meson "meson@0.51.2") is apparently an invalid input. <cbaines>Assuming #:meson works as an argument, I'd guess that the value needs to be a package <safinaskar>janneke: i think bootstrapping OS is simply not enough <joshuaBPMan>cbaines: according to the info doc it does. I'll try the variable meson then. <safinaskar>janneke: we should bootstrap computer, too. uefi, cpu, cpu microcode etc. ideally, create new computer without existing ones <pinoaffe>safinaskar: go and build your own toy computer in ttl circuits, then :) <joshuaBPMan>cbaines: does #:meson need to go into (build-system ...) or into (arguments ...) <vagrantc>is there some special command to make newly installed icons available? e.g. like fc-cache or something? <vagrantc>most likely spammers flooding the channel ... <plstohelp>it is astounding to me that a high-maintainence fork like manjaro can have such good mirrors with so little money <plstohelp>i know its not exactly an original or constructive observation but damn <pkill9>i dunno why more distros don't use torrents for package downloads <pkill9>i don't know of any that do actually <plstohelp>i know many people who would be unhappy at being "conscripted" to seed packages <plstohelp>many proprieatry programs do just that, because the users aren't savvy enough to notice the uptick in upward traffic <plstohelp>it pains me to see package updates be this slow when they really don't have to be <plstohelp>but iirc torrents are hot garbage for small transfers <pkill9>you could pack it into a single torrent, and then request only particular files within that torrent <vagrantc>you could bundle batches ... and there's even some support for only downloading partial torrents <vagrantc>i know there was some work to do that in debian <plstohelp>is there a "best guide" for guile online? does the GNU project host one? or would scheme documentation be better/ <pkill9>p2p guix substitutes would be good for custom channels <pkill9>hmm actually you'd still need a metadata server maybe <pkill9>which package is the qt creator in? <pkill9>oh it's not packaged i dont think <pkill9>plstohelp: as long as the file evaluates to a package, you run `guix package -f file.scm` ***catonano_ is now known as catonano
<vagrantc>janneke: so i want to borrow parts of your u-boot-pinebook-pro patches, but not all of it ... because I have a small patch series that works with v2020.04! <vagrantc>janneke: basically, i just need the installer stuff, as it's just a few patches on top of the regular u-boot. <vagrantc>i guess i've seen co-authored patches ... i'll look at examples of how to give proper credit <vagrantc>janneke: so i think i'll just mash that part of your patch into a new patch. <ryanprior>It's free software, but it would be cool to offer a similar system that's native to guix. <bdju>that would be very cool if so <bdju>I've been thinking of getting one at some point but I don't much like the idea of running Manjaro <vagrantc>ZombieChicken: master doesn't have a kernel that works with the LCD yet ... but it's in progress <lispmacs>hi, how do I specify package version in a package definition input? <Blackbeard>lispmacs: hi, the version of the package you are defining or one that your package requires? <lispmacs>Blackbeard: well, I was trying to figure out to install gtk+ 2.* version, but I see there is actually a separate package for that <lispmacs>is there something like a gcc-multilib package in Guix? <lispmacs>I'm trying to build something and getting error <lispmacs>ld: cannot find crt1.o: No such file or directory <lispmacs>does anybody know what package crt1 is supposed to be in? <efraim>i assume it's part of gcc-toolchain <lispmacs>i think it has something to do with the target of this emulator I'm trying to build, maybe it is something missing from the source <janneke>vagrantc: beautiful, and it's in master -- thanks a lot! <plstohelp>why are options required to pre preceded by -- when invoking guix package but not guix system? <xelxebar>What you are calling "options not preceeded by --" are typically called "subcommands" <plstohelp>why does guix system have subcommands and guix package have options <plstohelp>does it have something to do with guix package being intended for use outside of guix sd? <xelxebar>It helps to organize options. The subcommands of guix system are applicable to every sub-subcommand but not vice-versa <xelxebar>It wouldn't make sense to call guix system --reconfigure --describe <vagrantc>janneke: thanks for getting that ball rolling! <xelxebar>plstohelp: One could argue that the sub-subcommands of guix system should be lifted to subcommands of guix, so something like guix describe-system and guix reconfigure-system. It's mainly a matter of organization. Do you want a subcommand hierarchy or a large flat list of subcommands? <plstohelp>like, it really bothered me when i di guix system list-generations and guix package --list-generations back to back <plstohelp>i have package generations that show a package being uninstalled, and the same version being reinstalled <vagrantc>yeah, the differences with --list-generations vs. list-generations is a bit annoying <vagrantc>plstohelp: probably dependencies changed ; the hash is different for the package build, yes? <vagrantc>in guix, a given build of a package is not just the packagename+version, it also includes a hash of all the inputs/dependencies for building that package <plstohelp>i keep struggling with changing out of the debian package management mindset <plstohelp>what would cause dependencies to change that WOULDN'T accompany a version upgrade? <janneke>plstohelp: a version change in one of its dependencies <janneke>plstohelp: guix implements /functional/ package management; a package is the result of the build of its inputs (source, build recipe); and that all the way down <plstohelp>so an update to a DEPENDENCY of a package- rebuild the whole package <plstohelp>and it reuses whatever is kept in /gnu/store where possible <plstohelp>but sometimes you have a hash change, or maybe something got deleted by guix gc <janneke>the store is just a cache that may give a quick result for a package build, not ulnike a substitute server can give a pretty quick result for a package build <vagrantc>hmmm... could have called it /gnu/cache :) <xelxebar>plstohelp: Yeah, the idea is that we want builds that are *binary equivalent*, meaning that the outputs of builds are bit-for-bit equal no matter where they were built. <xelxebar>plstohelp: So if you build package-foo which uses library-1.0, the foo binary will be different if you build it against library-2.0 <xelxebar>Thus, package-foo-1.0 + library-1.0 is, in a sense, a *different version* than package-foo-1.0 + library-2.0 <plstohelp>i am going to attempt to package lutris if i dont see anything in the licsencing that would displease the GNU <rekado>I spent two days generating a sorted list of files in /gnu/store on ci.guix.gnu.org, but I don’t see qemu-image or disk-image in the list. <rekado>I wonder if the names have changed and that’s why we can’t delete the disk images any more? <bricewge>lprndn: Related to lightdm, please see fafe2343c2 services: sddm: Have sddm provision xorg-server. <bricewge>BTW yesterday I stumbled upon a channel using your lightdm service. It looks like we are not the only ones using it. <lprndn>bricewge: thanks. Seen it the other day. It's done. Will send the patches soon, just need to test it works correctly. ;) <bricewge>Great, happy to review it when it's done. <leoprikler>you can make your own license record if it's really exotic <leoprikler>but it does look like some license I've seen before <bricewge>leoprikler: How can I now which license it is without some guesswork? <leoprikler>there is also a large collection of licenses on gnu.org <leoprikler>you can iterate through them and do pattern matching <bricewge>I think I'll go with learning them by heart to improve my Vogon poetry <lprndn>hum.. is there a way to do something like mixed-text-file but outputing a string and not a file? or get a string from a gexp? <hendi>Hi, I have a question re. packages. I'm running gtk3 with some patches, e.g. to restore the insane type-ahead behaviour to the behaviour from gtk2 times. If I create my own gtk.scm file with the patches applied, will all gtk3 applications pick that up automatically? Or would I need to create a fork of gimp.scm, gedit.scm and so on as well? <hendi>okay, that makes sense. thank you! <leoprikler>you can use grafts if you don't want to rebuild anything <emys>cbaines, its a AMD Ryzen 3 3200G with Radeon Vega 8 Grafik <emys>sorry, needed to go offline when you asked for which grafic chip I had <hendi>leoprikler: oh, sweet, didn't know about grafts. That sounds useful <leoprikler>thing is, to effectively use them you'd have to build your local guix to override the gtk definition <lprndn>hendi: I think cloning guix repo, modifying it and using it through ./pre-inst-env (or as you only channel?) should work too. You'll have to build everything impacted but no need to rewrite gimp or any other gtk dependents. Maybe wait for someone to confirm or not... <hendi>Ok, that's enough for making me try guix. If there's a chance that'll work I'm happy :) <rekado>civodul: I’m updating the cuirass-gc-roots cron job to include squashfs images and guix pack archives. <rekado>I also want it to write out a list of files it freed up for garbage collection so that we can target these files explicitly when necessary. <rekado>I’m now running guix gc -F6T on ci.guix.gnu.org after deleting these roots <civodul>can you also increase the treshold for the GC job? <janneke>so, what's with aspell; has that just broken for me? <janneke>=> "Error: No word lists can be found for the language "en_US". <rekado>6T isn’t all that much. We have 4.2T and I think it could be at least 10T of free space. <rekado>it’s only going to collect ~2T now, which should be achievable <civodul>intuitively i'd say we should aim for free space equal to 2x to 4x the amount of disk space we consume per day <civodul>janneke: dunno, i think it works for me <rekado>civodul: I’m just concerned over the fact that we lose so much space so quickly. That hasn’t been the case in the past. <rekado>so I’d like to free up as much as I can just from disk images and the like <rekado>and see what amount of space we actually use for “important” stuff <janneke>civodul: okay, thanks -- yes, that's set *janneke goes further into divergence <rekado>I don’t sleep well when ci.guix.gnu.org is on the verge of running out of space <srk>hello! I'm trying to find out where's the Guix narinfo tooling located, I've realized it is not quite compatible with nix narinfo <civodul>rekado: yeah, the pace at which disk space is consumed is worrying <civodul>part of it is probably due to core-updates making lots of changes <srk>hi civodul, parser and printer :) <civodul>ah, the parser is in (guix scripts substitute) <srk>I would like to take a closer look and see if it could be standardized <civodul>the printer is in (guix scripts publish) <srk><3 thanks, not sure what to do with that yet ^^ :D <civodul>i don't think it significantly differs from Nix though, does it? <srk>not really, subtle changes s/Sig/Signature, multiple outputs, missing FileHash <srk>and order is a bit different <srk>yup, got pointed to that yesterday. I'm building a haskell lib for parsing/printing narinfo - ideally it should support both <srk>what do you think about the specification for the format? <srk>like take nixes narinfo, extend with multiple URLs so it is a proper superset but keep the order and Sig field the same <civodul>overall, i think we want to be able to evolve the format to suit our needs <srk>ok, I will take a look at the tools, required changes and try to put something together <rekado>is there value in compatibility with narinfos from Nix? <civodul>for instance, change the set of fields the signature applies to <srk>rekado: well for tooling it is <srk>which could be reused, for example you could possibly use Cachix <srk>if formats diverge too much it would make stuff way harder as you need to have separate parser/printer/types for each <srk>but if yours was just a superset it could be made so it handles nix narinfo as its subset and still be extended if needed <civodul>we'd need to look at the history of changes <srk>I'm not sure either, just a proposal ;) <srk>it's not *that* big deal currently either but it could get worse as there's more tooling which would need to support both variants <civodul>since the two are developed independently, we can expect to naturally diverge <srk>sure, hence the specification :) <srk>but yes, it is a little binding <srk>indeed, I'll think about it and maybe propose some draft spec or just a mail for ml to discuss this deeper <srk>thanks for the pointers civodul ! *civodul prepares a Shepherd release <civodul>janneke: shepherd fails some tests on GNU/Hurd, where it triggers a libc issue it seems <janneke>civodul: ah, so the good news is that `make check' works on Debian/Hurd <janneke>well if it's not a regression, we can worry later? <civodul>tests/respawn-throttling.sh gets stuck, and its log shows "hurd: Can't add reference on Mach thread" <civodul>yes sure, i was planning to worry later :-) <civodul>especially since it's probably "not our fault" *janneke looks forward to later worrying <civodul>let's find someone to worry on our behalf <janneke>i expect some of us to look at some glibc issues on hurd anyway <civodul>but only the 1st page, the 2nd seems to jump back in history <pinoaffe>is there a way to specify which package you'd like to have if there are two packages with identical names and version numbers? <rekado>pinoaffe: you can refer to them by variable name, which should be unique <rekado>-e '(@ (gnu packages foo) the-package)' <rbonnal>hello, how can I modify a file inside at runtime, of ala `sed -i` ? <rbonnal>finding a regular expression and substituting the string, sorry I am not yet a ninja with guile. <bricewge>rbonnal: substitute* in (guix build utils) <bricewge>Look around in gnu/packages it's widely used there. <rbonnal>instead related to using emacs-guix stuff, can I run `./pre-inst-env guix build package` from inside emacs ? <mroh>can someone confirm a segfault for xfce4-display-settings? (at least on a 3 monitor system, crashes on free() after display_settings_get_profiles()) ***wxie1 is now known as wxie
<efraim>/gnu/store/48vyvqrd1zyfaba9f93d9jm59dn4n5dg-hello-2.10/bin/hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /gnu/store/23vikdirgh992dapq6is0yazh8l02l21-glibc-2.30/lib/ld.so.1, for GNU/Linux 2.6.32, not stripped <apteryx>trying to build gnu/system/hurd.scm: checking whether struct stat.st_atim is of type struct timespec... builder for `/gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, raghavgururajan says: I have sent v2 to #40657. No propagation required. :-) <civodul>hey apteryx! what command did you run on which branch? :-) <efraim>hmm, I should probably combine and drop a couple of the patches *ecbrown does not have a gnu/system/hurd.scm <rekado>ecbrown: wip-hurd-vm or core-updates has it <rekado>civodul: woo! Yay for a new Shepherd release! *rekado battles email inconsistencies in the Debbugs stash <efraim>civodul: I think it was about 40 hours from bootstrap-binaries to hello, with 13-17 hours on guile-3.0 and probably 10 on gcc-7 <apteryx>civodul: ./pre-inst-env guix build -f gnu/system/hurd.scm on branch wip-hurd-vm, commit 08ddea3fffabf09c384a9c8fbf126593d6022c11. <apteryx>I see there is now a 'wip-hurd' branch as well <civodul>apteryx: wip-hurd is mostly outdated (?), and wip-hurd-vm is the future! <civodul>maybe janneke can help you with that <civodul>or you can try on core-updates for something a less ambitious but still pretty fun <apteryx>it's the building of guix itself that fails on wip-hurd-vm IIUC. <apteryx>janneke: can it be removed? the amount of stale branches is growing steady :-) <civodul>true, we'll have to do a spring cleanup <apteryx>ah, no, it's the build of guile-bootstrap that fails with a segmentation fault (builder for `/gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault)) <janneke>apteryx: i don't need it; not sure if it's needed for cuirass that is/was building it... <xelxebar>Oh, cool, so guix pins executables to specific dynamic libraries by setting DT_RUNPATH in the elf .dynamic section. <janneke>the difference between wip-hurd and wip-hurd-vm may blurr real soon; we could also go back to the `wip-hurd' name and drop wip-hurd-vm some time soon <apteryx>janneke: good, as long as there is only one hurd branch to keep things easy to follow :-) <janneke>apteryx: guix should build and cross-build on wip-hurd-vm <janneke>however, there are terrible kludges near the tip of wip-hurd-vm to do so <apteryx>interestingly, ./pre-inst-env guix build /gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv fails instantly (no log!) just a segfault. <apteryx>the build directory kept with --keep-failed is also empty <janneke>something like guix environment guile3.0-guix <apteryx>nope, I ran ./pre-inst-env from a 'guix environment guix' that gave me 2.2.6 <apteryx>janneke: seems to work better from a 'guix environment guix --pure' environment <apteryx>ah, nope. Same signal 11 error (segfault) on the guile-bootstrap-2.0. <janneke>core-updates only works with guile3.0-guix, afaik <TZander>mbakke: is there a special reason why qtbase has not been upgraded to the latest version? Or just not had time? <apteryx>janneke: ah, weird, i hadn't had issues until now with just 'guix environment guix' on core-udpdates. I'll retry with 'guix environment guile3.0-guix --pure'. <efraim>IIRC no one put in the effort yet for qt <apteryx>janneke: same error with guile-3 :-/ <apteryx>(to make sure: that's on the wip-hurd-vm branch, at commit 08ddea3fffabf09c384a9c8fbf126593d6022c11. <janneke>apteryx: what about: ./pre-inst-env guix build --target=i586-pc-gnu guile-bootstrap ? <raghavgururajan>bricewge For your udiskie shepherd service, did you install udiskie in your user profile or just added a like `(#: use-module (gnu packages foobar))` in ~/.config/shepherd/services.scm? <bricewge>raghavgururajan: It's in my user profile <civodul>janneke: lambdas and gexps, it seems <raghavgururajan>bricewge Thanks. Btw, for user services, is it required to install packages explicity in user profiles? Or is it enough to declare (use-modules [...]) in ~/.config/shepherd/services.scm? <janneke>apteryx: i was just creating a 2.2 worktree to check -- i'd better try on a fresh machine, then <apteryx>let me know if you can reproduce the failure! <janneke>can you build 'guile-bootstrap' (see above) ... i'm kind of wondering where you got the .drv to build <raghavgururajan>bricewge Also, do you have `udisks-service-type` in your system config? <bricewge>raghavgururajan: I didn't tried it that way. My user profile is full of packages, which isn't the recommended wa. <rekado>civodul: only the English version is available. Other languages return 404 <civodul>funny how Phoronix makes any anecdote look like breaking news <bricewge>raghavgururajan: No -service-type. Have a look of the file I shared with you a few days ago. <civodul>"the Shepherd init system is predominantly used by GNU Guix." <janneke>oh, and seven (7) developers -- a lot of tracktion! <bricewge>raghavgururajan: The answer on the ML by Pierre is the same I gave you few days ago <civodul>rekado: the problem is that the list of languages in doc/build.scm is static <civodul>still i wonder why the German translation is not picked up <rekado>first results from using guile-xapian: it’s fast <bricewge>civodul: Does the new shepherd release mean no zombie processes anymore? <rekado>but: parsing the log file format from Debbugs is not <bricewge>It wasn't clear when reading the changelog and the git log <civodul>bricewge: what bug are you referring to? <civodul>a bug that's not reported is a bug that doesn't exist :-) <civodul>seriously though, i don't know what zombies you're talking about <rekado>I wonder if I can get around parsing emails by only filtering the raw Debbugs log files <rekado>leaving only headers that we actually use and then parse them manually <rekado>but: we’re getting closer to a working and non-threatening issues.guix.gnu.org <mbakke>TZander: it's probably just that no one has volunteered to do the work <TZander>mbakke: sounds cool, I was looking at the update. Should not be too hard, but testing (and compiling) is the real killer ;) <mbakke>TZander: awesome :) yes updating "core" packages requires a fair bit of CPU time <rekado>uh, xapian just crashes when you give it an invalid query <bricewge>civodul: I'm talking about shepherd still waiting on processes that have died. Which ps return as having a Z status ***ChanServ sets mode: +o lfam
<civodul>bricewge: i think that 2016 bug report has been irrelevant for ages <civodul>i don't see zombies originating from shepherd on my systems <civodul>perhaps that's what you have in mind? ***lfam sets mode: -r
***ChanServ sets mode: -o lfam
<apteryx>janneke: I could build 'guile-boostrap', yes. <apteryx>it downloaded it from ci.guix.gnu.org though, and when attempting to build it with --check --no-grafts it goes through very quickly, apparently not doing much. <apteryx>re-attempting ./pre-inst-env guix build -f gnu/system/hurd.scm still throws the same signal 11 error though --> builder for `/gnu/store/i83xngxlhyxkxxgwp9dg9qz5gjxnm9wi-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) <raghavgururajan>bricewge I have set up shepherd files, but for some reason udiskie doesn't load at startup. Here are my files: <janneke>apteryx: would you like to create a bug for that? <civodul>janneke: should we have bug reports for temporary branches, though? <civodul>perhaps let's merge as much as possible into core-updates first <janneke>apteryx: does it work on core-updates? <janneke>it would be "great" if it's a bug on wip-hurd-vm only <janneke>apteryx: great! then someone needs to bisect wip-hurd-vm :-) <janneke>apteryx: thanks a lot for trying and reaching out! *lfam testing new openssl <bricewge>civodul Not mcron, even thought it also create them, I'll try to reproduce it and open a issue. ***wielaard is now known as mjw
<raghavgururajan>lfam Should we replace all openssl dependencies with libressl? I heard the latter is more clean and security-focused. <lfam>I haven't seen any evidence of that <lfam>And since OpenSSL has changed their license, OpenBSD will not be able to take their work anymore, so they will have serious challenges keeping up with feature development <lfam>Yes, that was pretty bad <lfam>The OpenSSL project has really kicked into high gear since 2014 <lfam>You can never be sure where the next terrible bug will be found. But given that premise, I think it's best to stick with the project with the most development activity and commercial support <lfam>The problem that OpenSSL had previously was lack of attention and support, and they have it now <lfam>Unfortunately LibreSSL is now in the opposite position: lack of attention and support <raghavgururajan>lfam I agree regarding sticking to a project that is in active developement. <lfam>Yeah, it's an attractive list of changes <lfam>It's already fallen behind on features though. It lacks TLS 1.3 and has not well-defined roadmap to implementing it <apteryx>janneke: bisects says 'system: hurd: Add the Shepherd.' is the first bad commit (bc34f5ef2c344029d38c93a8843b637d7cda6d62). <raghavgururajan>Folks, what is the difference between "make-system-constructor" and "make-forkexec-constructor"? <janneke>well that's unexpected...any ideas civodul? <lfam>I would try removing the "&" <lfam>Also, are you starting Shepherd manually? It won't be started automatically? <lfam>I mean, it won't be started automatically. It's not a question <lfam>No, you have to start it <lfam>It's not integrated with the system shepherd <raghavgururajan>Oh. Is it possible to auto-start it, by mentioning something is system config. <lfam>Just type `shepherd` to start it <lfam>Right, I have this issue too <lfam>What distro are you using? And what graphical environment? <lfam>Basically, it uses $XDG_RUNTIME_DIR to choose the socket directory <lfam>It doesn't work for me on Guix System so I manually set XDG_RUNTIME_DIR=$HOME/run and I made sure that ~/run exists <lfam>I figure it works right with a full GDM / GNOME setup otherwise not <lfam>I don't use a graphical system at all, although I do have dbus and elogind services <lfam>It's not easy to support all these niche use cases <raghavgururajan>Btw, when I just do `udiskie &` on terminal. Hotplugging works. But I get pop-up to enter password for /dev/sdXY. *raghavgururajan 's head is spinning <apteryx>janneke: np, thanks for hacking on the hurd! <janneke>did you peek at the commit? just by looking i'm really puzzeled about ... a segfault?! <raghavgururajan>Hmm. I get this error during build. "configure: error: can only configure for one host and one target at a time" <TZander>I'm racking my memory on this; who can tell me how to make my guix clone be the 'active' guix project so I can test changes to the packages? <TZander>the only thing I found was to run it with a script, but that requires I compile my own guix, I recall there was some pull or something. <lfam>TZander: You can either use the pre-inst-env script by building from Git, or point `guix pull --url=/path/to/repo` at your Git repo on-disk <lfam>If you are submitting patches for inclusion in Guix, please use the former <lfam>It is much faster and will match what we do to test your patches <TZander>pre-inst-env script isn't there until I get safely through configure. Which implies I have lots of stuff installed. So thats a no-go <lfam>What do you mean? You shouldn't have to install things <lfam>You only need Guix installed, and then you can use `guix environment guix` to create the environment <TZander>configure fails because I don't have the compiler for gui <lfam>Either way works, but testing with `guix pull` will be very slow <TZander>ok, it doesn't seem to work, though :D I updated the qtbase package and doing a ./pre-inst-env guix package -s qtbase <lfam>That means you didn't rebuild your source code yet <TZander>package definitions are source code? <raghavgururajan>How do I overcome the build error "configure: error: can only configure for one host and one target at a time"? <lfam>TZander: Do `guix environment --pure guix` and then, from within the environment, `./configure --localstatedir=/var && make`. You shouldn't need to reconfigure very often, unless you garbage collect the programs selected by a previous configure <raghavgururajan>I checked the configure file and --host is not declared multiple times. <lfam>But, you do need to run `make` somewhat frequently. Guile will auto-compile (avoiding the necessity to run make) but, as you saw, that doesn't work if the configure is stale <TZander>I was hoping for a version of 'guix package -f myfile.scm'... :( <lfam>I guess I'm confused about what you are asking <janneke>apteryx, civodul: ah got it...git bisect fooled us (or we fooled git bisect): the "Add the Shepherd" has another, mostly harmless failure: it does not introduce the segfault <janneke>so...the segfault is probably due to one of the ugly reverts and hacks for guix cross build; that needs attention anyway <lfam>Merges and reversions tend to mess with bisection <janneke>hmm this does mean, however, that the guix-daemon service can only be added later, after the guix cross build fixes anyway <janneke>lfam: yes, luckily this is a lineir history <TZander>lfam: I want to upgrade an existing package to a new version. And naturally test if my changes work. <lfam>Okay, in that case you should use the pre-inst-env script. It's the standard way to test changes during development <TZander>right, wish that package upgrades were not seen as 'development'. <lfam>It's a common wish item but it's very convenient for us to integrate packages as code <lfam>After you build your Git checkout the first time, future work goes more quickly <nagamalli>Hi, I got small doubt regarding version whether the package is stable or testing or unstable , where can we see which version does the packages belongs to? <nagamalli>By the way I was suggested to do gnome packag update which is having stable version..! <TZander>nagamalli: guix show [package] shows the latest. Or 'guix package -l' shows the installed apps and versions. <nagamalli>TZander, I understood the thing but i need like , stable, testing or unstable <TZander>nagamalli: check the homepage of the package you are talking about. They have releases listed. <TZander>It is not like debian where there is 'testing'. <nagamalli>Actually I was suggested to do gnome-todo package update only to a stable <nagamalli>version matching the other parts of GNOME we have. <nagamalli>Where i guix we have 3.28 version and the latest one is 3.91 <rekado>3.91 is a development version AFAIK <TZander>nagamalli: gnome versioning is a bit of a difficult topic... <nagamalli>I am very new to guix ,can you suggest me how i need to do? <nagamalli>rekado,<3.91 is a development version AFAIK> oh ok ,then what is my step to move forward? <nagamalli>rekado:can u help me,how can i proceed to fix gnome-todo package which is need to be stable version also? <lfam>ryanprior: Did you try building it with pytest? <lfam>Is there any information from upstream about the test suite? Like, how to run it? If they run it regularly (CI)? Etc <civodul>roptat: i'm looking at handling guix-cookbook in (guix self) <civodul>i wonder: since we already have a PO parser, how hard would it be to do away with po4a? <ryanprior>lfam what do you mean by build it with pytest? Add pytest as an input to the guix package? Or run pytest locally with the source code? <lfam>Add it as a native-input, maybe write a custom test invocation <lfam>Usually errors like this are a sign that the test suite is not being invoked correctly <lfam>It's also possible they don't use the tests <lfam>There is a 'dev/test.sh' script. Did you look into that? <ryanprior>I don't get the sense it's using pytest at all. In any case, adding python-pytest as a native-input didn't change anything. <lfam>I would try running that script <ryanprior>Dang okay so how do I reconfigure the test step to do that? Do you know a guix package that does that so I can look at its definition? <rekado>nagamalli: what is your goal with gnome-todo? What does “fix gnome-todo package” mean? Is it broken? How? <lfam>ryanprior: Look for instances of "replace 'check" <ryanprior>Okay now I'm getting somewhere. The tests assume you're in the git repo, not a tarball. I can ask upstream if they support any method of testing without git. Or, can I have guix fetch the git repo instead of the tarball? <lfam>ryanprior: It can't be done, because the '.git' directory changes, meaning we wouldn't be able to treat the source code as content-addressed <lfam>For cases like this we just skip the test suite <lfam>If the package is working for you, that is good enough <lfam>I mean, we do fetch Git repos as sources, but in that case part of "building" the source is to delete the .git repo <ryanprior>Do you think I should submit this package as a patch to guix then? Even though it doesn't run tests? (I'm going to ask upstream about running tests against the tarball, maybe that's something they can support with the right workaround.) <lfam>Yes, it's fine to skip the tests if there is a good reason, and this counts as a good reason. As long as the package is free software and works for you, we want it :) <ryanprior>Should I document the reason in a comment in the package, or in the commit message, or elsewhere? <rekado>ryanprior: a short comment next to where you disable the tests would be fine <raghavgururajan>Folks, So I want to add a new phase after 'install, to execute `gtk-update-icon-cache -q -t -f $resolve_datadir/icons/Faenza"` command. What would be the syntax? <rekado>raghavgururajan: (add-after 'install 'update-icon-cache (lambda …)) <rekado>but I don’t think you should do that <rekado>the icon cache is updated as part of a profile hook <rekado>to invoke any command you’d use (invoke "the-command" "and" "its" "args") <rekado>I’d just ignore it until it turns out to be a problem. <rekado>raghavgururajan: have you strace’d the application to see where it tries to find them? <rekado>are they loaded when the package is installed in a profile (and thus the profile hook has run)? <raghavgururajan>rekado I have made some changes to pak def. Gonna re-check by installing in profile. <raghavgururajan>rekado I changed gnu-build-system to glib-or-gtk-build-system. Now work perfectly. Looks like it needed the gtk phases. <ryanprior>In terms of formatting my patch, is it a good idea to add the visidata package to `python-science.scm` since it's a data science tool? Or is it better to put it in its own `visidata.scm` file? <atw>ryanprior: in my uninformed opinion: python-science.scm seems to be python packages that are useful while doing science. If visidata is a standalone application, that's a good rationale for putting it in a visidata.scm. OTOH if it is a python library that is useful for doing science, then python-science.scm would make sense :) <ryanprior>It is an end-user application, so I will start with that recommendation. Thank you atw :) <rekado>python-science is the new home for the scientific python stack (numpy, pandas, scipy, etc)