<anadon>Blackbeard: Thanks! If all goes well enough, I hope to pass it through the Linux FS mailing list to get their take. They are probably the ones who will ultimately decide if this work lives or dies. <nckx>GWL + kernel VFS? Now I'm intrigued. <joshuaBPMan>anadon: I must have missed the conversation. What features are you adding to the linux kernel? *civodul had taken the bad habit of using "-nd" as a shortcut for "-d --no-grafts" <roptat>not really, but I can try to improve the patch a bit <anadon>Blackbeard: Yeah, it is files as a foundational concept that this paper challenges. <anadon>So the Linux FS mailing list is _the_ place that decides the viability of this work. <Blackbeard>anadon: when you are done please let me read it, seems interesting even if it is not implemented <pkill9>nice, i like that package upgrades now tell you if they're only upgrading due to changed dependencies <goldenshimmer>Is there a Guix-y way to stick incremental snapshots of the store into packed files (nars, tarballs, or similar) and be able to checksum them for validity afterwards? I think I'm looking for something like guix archive, but that seems to be for specific packages or profiles, rather than the store as a whole... Thanks! <anadon>Blackbeard: it is available in the gwl-devel mailing list. <anadon>When it is done done, I'll be sending it all over. <nckx>goldenshimmer: I can't think of any. The checksums are stored outside of the store in /var/guix/db/db.sqlite. <anadon>goldenshimmer: Can what you are seeking be accomplished with a `guix pack` with program versions specified? <goldenshimmer>OK, thanks. On a related note, is /gnu/store/.links supposed to be quite so full of files? Can I tell it to bin the files by hash prefix? The impetus for the first question is that folder has hit the directory limit on this filesystem, and is filling up dmesg with "index full" errors... (I've been waiting to do a guix gc until I work out backups, but that will probably only be a temporary reprieve since that folder's hit <goldenshimmer>the limit at only ~150k files, which filled up in a couple months of casual use.) <nckx>goldenshimmer: It's ‘supposed’ to be like that in that it's how it's currently implemented, and there's no way to specifiy subdirectories. <nckx>It seems there's no way to disable dir_index for only one directory. Shame. <nckx>Is disabling it completely an option for you? <goldenshimmer>anadon: Thanks; I'm hoping for a full copy of the store though, which will help my peace of mind. Will probably just make an index of checksums plus an incremental tar instead, which is a bit inelegant but should do the trick. Thanks though! <nckx>goldenshimmer: Beware, if you're planning on actually using your /gnu/store copy in any way, back up /var/guix as well! <nckx>An extracted /gnu/store without a DB (or a DB that doesn't exactly match the /gnu/store) is useless. Things will run, but you can't do anything to it anymore using Guix. It's dead. <goldenshimmer>I don't think I probably need dir_index on, although I don't know what the performance effect would be like. My home folder's about 3500 files immediately within it, but that's more a sign that I need to get organized than anything else... Thanks, yes, I did grab the /var/guix too, although I wonder if it can be properly backed up while the system's running, or if that will have made it useless... <goldenshimmer>(Not while guix was doing anything, but I assume the daemons and such were still attached.) <nckx>goldenshimmer: I think it should be all right as long as nothing was happening daemon-wise, but good point. I've never actually tried restoring a snapshot of a running system like that. <nckx>all right = sqlite will treat it as an unclean shutdown and clean up, but that's just a guess. My experience with sqlite corruption is not good. It managed to corrupt my Guix DB for no discernible reason twice over the years. <goldenshimmer>Well, I guess I'll try turning off dir_index and see what that does. (The store's only 10GB, so it's not taking up an unreasonable amount of space as it is.) Thanks! <nckx>If disabling dir_index fs-wide isn't an option, you can also pass ‘--disable-deduplication’ to the daemon. After it takes effect you can just delete /gnu/store/.links entirely. <nckx>Your store will use more room but it will be dir_index (and rsync -H)-friendly. <joshuaBPMan>Hey guix, I am trying to solve this weird issue I have with the mailing list. I keep getting duplicates of the guix-devel messages. When I post a message to guix-devel, I end up getting multiple messages. <joshuaBPMan>Probably because people reply to my email via "To: <my email address>; CC: guix-devel@gnu.org", which I am subscribed to guix-devel. Does anyone know a simple way to not get duplicate messages? <joshuaBPMan>I've got "Avoid duplicate copies" in the mailmain daemon. But I also have my email address as jbranso+guix-devel@gnu.org. <joshuaBPMan>Also, what's the header that gnu mailman guantees is the header that will always be present in sending emails? <vagrantc>using "notmuch" or something similar will hide the issue :) <joshuaBPMan>vagrantc: I think I found out how to solve the issue. There is a header on each email: List-Id. That List-Id will never change. <joshuaBPMan>Then in the gnu mailman you can (apparently) specify that you do not want to recieve additional copies. Hopefully that works. <joshuaBPMan>I just added an email filter to dismail.de, to filter all incoming mail with the header List-Id containing "guix-devel" should go into my folder "Guix Devel". <vagrantc>joshuaBPMan: that obviously won't work if people CC you, only if people CC multiple lists managed by that particular mailman instance <vagrantc>ok, linux-libre 5.6 ... time to boot test <joshuaBPMan>vagrantc: hmmm. Then I'll probably have to do some more filtering...I find it soo annoying that mailing lists do not operate as well as reddit or usenet. <joshuaBPMan>I could probably have a filter like if CC contains my email address, and there is the List-Id field present with guix-devel, then the the server would discard the duplicate message. <goldenshimmer>Turning off dir_index hasn't had any noticeable adverse effects yet, and building things isn't causing the error messages in the dmesg any more. Problem solved. Thanks! ***catonano_ is now known as catonano
<brendyyn>you dont need luck because you are awesome already <roptat>I think I saw 3 gsoc proposals, and 2 people interested in outreachy <Blackbeard>this is my proposal in case anyone wants to give it a look <apteryx>Blackbeard: I don't have much experience with GSoC, but it looks good to me! <apteryx>I hope your application makes it through :-). Furthering Shepherd is very valuable to the Guix System. <jsoo>If I wanted to make a plain startx available in the path, how would I do it? <jsoo>Ok cool. Check! I think the path to xorg was off so I fixed it <jsoo>Now what if I wanted to use the xorg-configuration that the dms use? <jsoo>Yeah display managers like gdm or slim <jsoo>Pardon the capitalization <brendyyn>you want their config but you dont want to use the actual display manager? <jsoo>I guess I could use a special-file-service combined with the make-startx function <jsoo>It just doesn’t feel quite right <guix-vits>Blackbeard: starting comment for my firewall-to-be-config: # lohoho (127.0.0.1 and a barrel of milk) *guix-vits reworking neverball according to e-mail comments <guix-vits>``Usually, we would delete it in a snippet so "guix build -S neverball" returns source without the problematic part.`` -- Can someone, please, tell me: it just mean to place things under (snippet? <guix-vits>Blackbeard: i'm bad at explaining, i'll try in next post. See the gnu/packages/games.scm, package foobillard++ and it's (snippet <guix-vits>almost-my package def steel has some flaws, and need some reshaping. <guix-vits>Blackbeard: correct way to saying was: "my English isn't good" <Blackbeard>guix-vits: I am trying to read. But I think I should go to bed. I am really tired <Blackbeard>I will read it again tomorrow because it seems interesting <civodul>efraim: i just killed your gc process on bayfront :-) <efraim>19 GB should be enough for that :) <civodul>reconfiguring will give us a more reliable mcron, so that should be better <efraim>last time I ran a full 'guix gc' without any arguments it only freed about 600 GB <efraim>think we can get rid of some of the older generations or should I bring it up on guix-sysadmin <civodul>efraim: yeah, or perhaps it was because some of the mcron jobs didn't run <rekado>found the cause of date weirdness on issues.guix.gnu.org: mu ignores the date header of emails and uses the mtime on the file instead. <rekado>since mumi downloads mail files on demand their dates are all recent. <rekado>so I’m now downloading, parsing, and then resetting the mtime <bricewge>Working on the v2 of kernel-module-loader I would like to pass module parameters to modprobe in addition to the module name. <bricewge>Does a list of lists of string is acceptable as a service field? <rekado>civodul: I guess we’ll drop mu (or rather mumimu) eventually and use guile-xapian directly. *rekado reconfigures ci.guix.gnu.org <civodul>rekado: cool, make sure to restart mcron afterwards! <civodul>has anyone tried Bitlbee with Mattermost? <jonsger>how many GSoC proposals do we have now? I got lost in counting :P <hulten>If a Tex Live package is missing in my local installation (current case: pgfgantt.sty), how do I solve this? <hulten>'guix package -s pgfgantt' doesn't return anything; should it it were packaged? <bricewge>jonsger: I think we are 4 GSOC applicants <civodul>g_bor[m]: what's the GSoC status? :-) <hulten>rekado, okay, so I should grab it from CTAN and install it in my local texmf. <andydarcyjewell>I did a "guix pull" yesterday, and now "everything's changed" - hardly any output when I do a "guix build -f", whereas before, it was screenfuls <civodul>"guix build" still prints build output by default (-v2) <andydarcyjewell>WARNING: (#{ g117}#): `freetype' imported from both (guix licenses) and (gnu packages fontutils) <nagamalli>Hi,can anyone help me where can i find the available packages of gnome? <civodul>oh that's because the thing has already been built <civodul>"guix build" doesn't rebuild things already in store <andydarcyjewell>haven't looked at it since Thursday, and there's been a lot of mental water under the bridge since then! <andydarcyjewell>Does url-fetch (or anything else for that matter, like patch-shebang ) mangle the downloaded file? I'm getting an error from the compiled binary when doing the "bootstrap" phase, saying that the header of the downloaded boot image is invalid... <civodul>"guix build -f etc/release-manifest.scm -n" still misses a whole bunch of substitutes <civodul>oh that's unrelated to what you were saying, sorry <civodul>"undefined reference to symbol 'file_chauthor'" <mbakke>civodul: on 'core-updates', coreutils builds without libcap on the Hurd, seems related <mbakke>actually the libcap input is removed outright when cross-compiling <demotri>Why are the main guix packages not reproducible, i.e. guix-core, guix-packages, guix-package-base, guix-extra are not reproducible? <demotri>A 'guix fetch --rounds=2 -K' fails. This is unsatisfying. <civodul>demotri: that's an old Guile issue that was only partially fixed a few years ago <marmulak>I think it would be wise to switch from guile to haskell <kmicu>marmulak: there’s nothing wise in rewritting Guix from scratch. Otherwise go ahead. I will switch imediatelly. <kmicu>(It will be faster to fork Nix and start from there.) <janneke>civodul: yes, seen that before ... /me searches git and memory <marmulak>I'm curious what makes guile ideally suited for this project, not about changing it but what motivated the original decision to use it <dhanvanthri>It's a lisp, and it was made by the gnu project to interface with the system <str1ngs>guile is the official extension language of GNU. so it makes sense to use guile <rekado>Scheme is a language that’s uniquely suited for writing (domain specific) languages. <str1ngs>besides users have enough learning curve with guile then to expect them to learn haskell too <rekado>macros in Scheme use the same language, so that’s a step up from Haskell (which only has the awkward Template Haskell). <marmulak>well I mean obviously you wouldn't learn the former if you were using the latter lol <kmicu>(Haskell is excellent for eDSL too. So that cannot be the reason ;) <marmulak>I'll read up a bit about guile and its history <marmulak>I've never used scheme before, but my first time using a functional language was lisp though I hardly did anything with it at all <marmulak>I'm actually slightly confused why anyone would ever want to use lisp or anything related to it, but I also don't know anything about macros so it must be amazing for a certain class of applications <kmicu>marmulak: if we remove a good typing system, add homoiconicity then Haskell (its Core) is preety much a lambda calculus. <marmulak>does being a lambda calculus make something more or less like scheme <kmicu>marmulak: check one of countless ‘write scheme in Haskell’ blog entries to get the feel. It’s a simplification but a valid one. <demotri>civodul: Thanks. I thought I had something like that in mind. I hoped it would be away with the new 3.0, but it looks like this is still there. <kmicu>The Author can answer now why Guile (or point to the resources). *kmicu still cannot find the guix announcment mail. <civodul>rekado: am i right that the search box at ci. searches derivation names and not job names? *rekado looks at the code <nckx>I see it's April 1st somewhere already. 🙂 <kmicu>civodul: do you have a copy? *civodul .oO sent at 2AM, wtf? <rekado>civodul: it does “WHERE (Builds.nix_name LIKE :query)” <civodul>ah yes, so these are the derivation names <kmicu>Nixers replaced the mailing list with Discourse and gnu-system-discuss dosen’t have answers from there. :/ <rekado>civodul: this is in (cuirass database), db-get-builds-by-search <nckx>Oh, and mroh and civodul o/ I see I have a great connection so I'll just be my lurky self somewhere over here. *kmicu is happy org-mode preserved at least that. <rekado>updated issues.guix.gnu.org; unfortunately, the old CSS might still be cached. I wonder if I can easily force a cache reset. <wingo>what a frustrating thing about grafts & guile 3 <efraim>I assume with the way guile-for-grafts is defined it couldn't be using an old version of something <wingo>from what i understand there is likely a guile 3 runtime bug somewhere. ludo has already found & fixed 2 or 3 of them <civodul>we made progress over the last few weeks though <civodul>it's just very time- and mind-consuming <jonsger>my bugs from yesterday are still missing in issues.guix.gnu.org <rekado>jonsger: I only *just* updated mumi on issues.guix.gnu.org; the bug fetcher is still running <mbakke>rekado: AFAICT issues.guix.gnu.org does not send any cache headers? so user-agents will send If-Modified-Since 'Thu, 01 Jan 1970 00:00:01 GMT', and errh, get a negative reply even if they have been modified. <rekado>jonsger: I also still need to fix the mtime on previously downloaded messages. <jonsger>rekado: it's just the search who doesnt find it. <mbakke>some of the .css files have Last-Modified set to 2018 or 2019 though, but they are also newer than 1970 which all current files have :/ <civodul>janneke: we need to add -lhurduser on the link line, which makes sense because some of these executables directly refer to file_chauthor <civodul>so i think Coreutils FTBFS as is on GNU/Hurd, or at least with --as-needed, no? <str1ngs>whenever I see GNU/Hurd I get the urge to yell stampede! :) <efraim>It's a good chance to make sure the one in Guix doesn't need improvements <janneke>civodul: of course, that's not on master yet <janneke>civodul: /me is confused...all hurd patches are on core-updates, right? how is master even building coreutils, without bootstrap binaries... *kmicu sometimes wonders whether switching to Chez (like Racket) would give us ‘guix pull’ under a half gigabyte of RAM. <janneke>civodul: on current core-updates, "hello" should cross build as well as build nativery <guix-vits> ;; Debian doesn't strip it, though. i'm dummy <guix-vits> (delete-file-recursively "data/ball/octocat") <janneke>civodul: if you look at glibc (in base.scm), it has a "augment-libc.so" stage which adds machuser and hurduser; that will not work for a static libc; i had that problem when trying to use gcc-7 as bootstrap binary <rekado>kmicu: easier than switching to another Scheme is: have more than one person profile memory usage in Guile. <rekado>guix-vits: I don’t know what you think is slow. But generating a new source tarball after editing the contents does take time proportional to the size of the source archive. <kmicu>That’s true but that another Scheme already has plenty of folks profiling memory. Maybe not the language is the issue but increased memory usage is the price to pay for eDSL 🤷 <kmicu>(IIRC Nix can eval order of magnitude more derivations under half gig. It’s possible that any amount of memory profiling cannot bring Guix+Guile to that level cuz Nix eval cares only about small Nix DSL and can optimize more by definition.) <brendyyn>would all the descriptions in the package defintions take up a lot of memory too when the package definition is loaded? <rekado>“guix pull” compiles modules. The compiler currently uses an unusual amount of memory for compiling modules. <rekado>I don’t think that’s related to eval’ing derivations. <brendyyn>is guix pull the only part of guix that is a memory use issue? <anadon>kmicu: rekado is right on this. The DSL isn't an optimization that lowers the required memory. Now, finding out what actually uses that memory is another matter, but it isn't the DSL and with development there is no reason why guix can't do similar. <rekado>brendyyn: “guix pull” is by far the worst offender as it compiles Guile modules (in the case where it can’t simply download a pre-built Guix from ci.guix.gnu.org), and that’s very expensive since Guile 2.2. <rekado>interpreting instead of compiling would make all Guix operations terribly slow, not just “guix pull”. <brendyyn>i wish a user could subscribe to a substitutes only system where they would only pull if there was substitutes available and never compile anything <brendyyn>perhaps they could pull to the branch of the latest completed jobset of guix and any packages it that succeed, instead of latest master <brendyyn>kmicu, i heard someone complain that even nix uses a lot of memory ;/ <brendyyn>looks like nix channels update after the build server has finished building <nckx>The ‘unstable’ channels does, yea. <brendyyn>nckx, guix is always just the latest master right? although i guess there is core-updates which is build before hand before merge <civodul>"GUIX_PROFILING=gc guix build libreoffice -n" says 66MiB, not that bad <rekado>brendyyn: I’m sure we can write a little Guile snippet that talks to ci.guix.gnu.org to get the latest finished build of Guix. Put that in channels.scm to generate the latest channel commit. <civodul>the big problem as rekado wrote is Guile's compiler, that's what eats memory and CPU when running "guix pull" <brendyyn>i wish i was smart enough to go hack guile <brendyyn>civodul, do you think there is an avenue for optimising the building manual database bit of building a profile? <civodul>brendyyn: ArneBab_ posted a patch a while back to parallelize it, but i dropped the ball <brendyyn>civodul, it still gets my laptop fan going with 100% usage on 1 thread anyway, i mean is there some way to cheat, and maybe make some of the processing done at build time for the packages, and the profile building bit can just assemble it somehow? <brendyyn>i read about the optimisation of grep, and it said optimising was figuring out how to not have to do something, not how to do it faster ;) <sarg>What should I put into (operating-system) to create a file in /etc with content from string. I've tried (extra-special-file) but it doesn't accept strings. <nckx>sarg: It does accept (plain-file "my-file" "some stringy string"). <sarg>nckx: thanks! I've figured it out <pkill9>could it be possible to take a profile, and graft input(s) to all it's packages? <pkill9>meaning, to those particular store items <nckx>brendyyn: It might be interesting (but not interesting enough for me to actually try) to find out how much of that burnt CPU smell is from decompressing every single man page. Granted, auto-gzipping saves you PRECIOUS MEBIBYTES and might not be significant overhead nowadays, but still. <pkill9>specific use case is for large packages which need to be rebuilt when you're on a newer revision of guix, but you have already installed a package from an older revision of guix to a profile, and you want to just graft a different input to it <brendyyn>nckx, what even uses this man db anyway? <nckx>Was that a trick question? Did I win? <nckx>Now, is that relevant nowadays? I dunno. I don't use any of the tools that use it. <hulten>With 'guix pull --branch=' I can select an additional branch. <hulten>But I think no new packages get available when issuing 'guix package'. <hulten>How to say to 'guix package' to use a specific branch? <brendyyn>nckx, i thought it might just find a file by name in share/man <nckx>brendyyn: I assume the ‘man’ command does, & that's all I ever use. <nckx>‘Probably not decompression overhead’ then 😃 <brendyyn>so i wonder what its doing for 30seconds to build a little 4kb db <nckx>andydarcyjewell: I do, but I always know which page I want. <nckx>brendyyn: The codez are in guix/profiles.scm if you want to find out. *nckx goes back to reading manpages instead of talking about them. <sarg>pkill9: I did guix package --do-not-upgrade=my-huge-package -u, but would like to know a better solution as well. <andydarcyjewell>I'm getting no-where with working out how to fix this "invalid header" error I'm getting <efraim>sarg: pro-tip: 'guix package -u . --do-not-upgrade package1 package2 package3 ...' without the '=' makes the syntax easier <andydarcyjewell>this would appear to indicate that the file is being mangled by something before it is read in (it's the binary that the guix system just built that I think is issuing that error): <rekado>andydarcyjewell: is this version of Factor known to work? You could do as the message says and report it to the developers. <andydarcyjewell>rekado: yes, i have confirmed it works when manually built, using the exact same boot image <andydarcyjewell>it could well be a deficiency i have introduced into the build environment however (i barely know what I'm doing, as you know!) <jonsger>civodul: that 36% speedup is only for the man-db step or? <efraim>civodul: I just tried 'guix package -u' and I had no changes in my profile so nothing happened. not even with git:send-email which is a repeat offender. I think you fixed the 'propagated inputs make packages update every time' bug <andydarcyjewell>I just had the idea to try to copy-file the known working image in from my homedir (i.e. outside of the guix microcosm) but of course it fails, which makes sense. Is there any way to do that at all, just for testing? <alextee[m]>is there an example package that downloads multiple sources? <alextee[m]>i need to build something that unfortunately has a horrible build system that downloads tarballs from the internet <mbakke>civodul, janneke: should the coreutils -lhurduser fix be removed when merged to core-updates? <civodul>mbakke: i wonder, how can it possibly work on core-updates? <civodul>is it because we unconditionally link everything against libhurduser? <janneke>civodul: i'm still curiously/happily confused as to what you're doing with hurd+master :-) <janneke>civodul: but if you do: git diff master..core-updates -- gnu/packages/cross-base.scm <janneke>then there is also a -lhurduser thing <rekado>alextee[m]: you can add origins to native-inputs, then add a build phase to put them in the expected places. <civodul>janneke: don't hold your breath though: i'm just trying to placate "make assert-binaries-available" :-) <civodul>janneke: re cross-base, i wonder if we should -lhurduser globally, not sure how it's intended to be used <janneke>civodul: debian has glibc patches for this <ngz>I noticed an odd behaviour with manifests, but I don't know if that qualifies as a bug. If your manifest.scm contains (specifications->manifest '("a" "b" "c")), then guix package -m manifest.scm installs "c", "b", "a", and "guix package -I" returns "c", "b", "a", which is slightly frustrating. <ngz>I mean, one can add reverse in front of the specifications list, but I <ngz>wonder if `specifications->manifest could not include it. <alextee[m]>rekado: are you sure i can put origins in native-inputs? package `mruby-zest@3.0.5' has an invalid input: (origin (method git-fetch) (uri (string-append "http://dist.libuv.org/dist/v1.9.1/" "libuv-v1.9.1.tar.gz")) (sha256 (base32 "00c44v8m63ac972a74xqybwck305lghadssj2qz61q5fcny4fzb4"))) <mbakke>alextee: see 'git' for an example with an origin as input <alextee[m]>should be url-fetch. but that still shows the same error <mbakke>ngz: maybe bring it up on guix-devel? <mbakke>civodul, janneke: so I guess we can ignore the coreutils Hurd fix when merging? <guix-vits>"test-name: channel-news, one entry" result: FAIL <kondor[m]>Can we use this channel also as a job board? :) <mbakke>kondor: sure, as long as it's related to free software :-) <ngz>mbakke, civodul: OK. I think I will create a bug report so that we don't lose track about it, even though it is not a deal breaker. <kondor[m]>PhD Position in Exposomics/Non-targeted metaboloics at the university of luxembourg ^ <kondor[m]>you'll work with people who are guile/guix friendly, but likely produce loads of R code; plus, interest and bacground in bio...something sciences highly valued, but perhaps non-essential <alextee[m]>what does this mean? /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/sh: ./configure: /bin/sh: bad interpreter: No such file or directory <anadon>kondor[m]: Now if only I qualified for that position. <mbakke>alextee: it means something tries to use /bin/sh which is not available in the build environment <civodul>kondor[m]: interesting that you write "but" in that sentence :-) <kondor[m]>civodul: i barely managed to infest our workstations and servers with guix. guile is a whole new level to proselitise about :) <civodul>so your team uses Guix a bit for bioinfo? <kondor[m]>i'd love to see more people using scheme with practical and that goal would likely be closer at hand if I had someone else than me in the institute who is enthusiastic about scheme <mbakke>civodul: I still don't feel very comfortable with Cuirass, could you flip the switch on the core-updates specification? Let's roll! :-) ***badpixel- is now known as badpixel
<kondor[m]>civodul: atm, we use it to wrap R packages with horrid dependencies into something easily installable for me, produce containers and such <kondor[m]>but, yeah, the ultimate goal is cheminformatics <kondor[m]>read: environmental chemistry data analysis, toxin identifications in samples from the environment, or human body, etc <rekado>ugh, debbugs is a bit frustrating. <kondor[m]>/msg anadon btw, we need people for variety of computational tasks, you might fit in on various levels. we'll need technicians, possibly another postdoc. if you're into life sciences, environment, etc + computing it might be interested in you; as far as I am concerned (and I do hold about 1/3-1/2 power in the decision making) the fact that you're lurking on #guix already gives you a huge advantage in comparison to the usual <kondor[m]>candidates we're getting); so have no fear, apply :) <rekado>mbakke: there should be a button in the admin interface — but there isn’t yet. <rekado>there’s only a button to remove and a form to add a specification. <kondor[m]>ok, now i need to understand how to send priv messages from the cmd line in matrix <rekado>I just realized that the get-bug-message-numbers operation in guile-debbugs is really expensive as it fetches all messages belonging to a bug … just to return a list of message numbers. <rekado>in mumi I used that to determine whether to fetch messages… <rekado>so: I’ll need a cheaper way to get a list of message numbers from debbugs. <sneek>Welcome back Veera, you have 1 message! <sneek>Veera, guix-vits says: Hi-Hi. <sirgazil>I usually have to leave the computer alone when it's doing a "guix pull". <bavier`>Veera: could you send a keypress over stdin? <Veera>Missed telling I set up Xvfb for it <Veera>Tried pressing 'q' it did not worked <Veera>bavier`: do i have to send it while invoking qiv <kmicu>anadon: I hope so. Though Nix can be optimized for Nix and make more assumptions about the code. I doubt Guile can accept patches that optimize pipeline for Guix but make compiler slower for others. So DSL vs eDSL is a trade‑off but for sure we cannot tell how big today. <Veera>do i have to send the keypress over stdin while invoking qiv <civodul>kmicu: things like 'guix pack', Shepherd integration, hpcguix-web, Guix Data Service, Emacs Guix, 'guix refresh', etc. benefit hugely from the unified interface <civodul>so we can tell some things about the tradeoff :-) <kmicu>civodul: personally, I also think the tradeoff is worth it but my SBC with 4GIB disagree with me constatnly ;) <Veera>guix-vits: do you have knowledge about using Xvfb for testing X progs <civodul>kmicu: though in practice i rarely build things locally when pulling <civodul>and then not all the individual derivations require that much RAM <civodul>but yeah, optimizing the compiler remains high on my priority list <civodul>there have been improvements in 3.0.1 and 3.0.2, but there's still a long way to go <kmicu>For referance GC_INITIAL_HEAP_SIZE=128k nix-env -qaP -A nixos '.*exim.*' took 230MB. <kmicu>(I only wonder whether Guix can go so low at all.) <civodul>"GUIX_PROFILING=gc guix package -A exim" says 11 MiB, though i'm not sure if it's equivalent <kmicu>-A evals only exim, prev. one hits all visible Nixpgs (doesn’t ask by attributes) <civodul>"GUIX_PROFILING=gc guix search exim" loads all the package modules, runs at 41 MiB <g_bor[m]>I just would like to remind every GSoC applicants hanging around that today, 1800 UTC is the final application deadline for GSoC 2020. <Veera>lfam: can you help with me in using Xvfb for running a pkg check while running a X prog <lfam>Sure Veera. What did you try so far? <lfam>Hm, Veera. I'm not sure how to "press q" in this context. You might be able to use `expect` but it will be complicated <rekado>(the messages are not printed when running in the context of “guix pull”.) <rekado>anyway: this gives me a “guix pull” that takes a little over a minute and that doesn’t compile any Guix modules. <lfam>Veera: If the tests are meant to be run manually instead of automatically, I would think about skipping them. But maybe there is a way to automate it <brendyyn>mbakke, for that mesa bug, i guess close it? probably its a waste of time investigating it <rekado>it does compute the “Guix derivation for 'x86_64-linux'”, though. <Veera>lfam: They are run part of make install; And it has to be exited by pressing 'q' which will return 0; and it just prints test passed; but if it exit non-zero then also make install finishes successfully <rekado>brendyyn, sirgazil: does the channel file above work for you? <lfam>Veera: I looked at the qiv manual page and got some ideas. You could patch the Makefile to do `./qiv --cycle --slide --fullscreen ./intro.jpg`. This will show the picture and then exit on its own <raghavgururajan>Veera I kinda faced same situation while packaging "gnome-color-manager". You can have look at package definition of "gnome-color-manager", which is 3rd package from the top, in gnome.scm file. You can see the code regarding x11 server for tests. :-) <lfam>Veera: It's like an "auto slideshow" <brendyyn>rekado, holy shit you just made that on the spot? <lfam>Veera: You'll still need to do the Xvfb setup <lfam>But this way, nobody has to press Q <anadon>Looks like the XlsxWriter package from python is missing. <Veera>raghavgururajan: I setup similar; copied from graphics.scm <civodul>rekado: nice! you should use (guix ci) <civodul>g_bor[m]: re the release, i think we're doing ok! <civodul>but perhaps on Thu or Fri would be nice <civodul>"make assert-binaries-available" still complains <anadon>Guys, `python-django` is 2 major revisions out of date. What is the contact for updating it? <mbakke>anadon: guix-patches@gnu.org ;-) <rekado>hmm, looks like (guix ci)’s latest-evaluations is a little wrong. spec is always #f. <brendyyn>anadon, are you asking how to update it yourself, or who you can ask to do it? <anadon>I'll do it myself tonight when I have time if no one is able to get to it by then. <brendyyn>Guix does not have maintainers in the strict sense that many other projects do. You can feel welcome to work on anything. <brendyyn>so you can just try update it, get it working, check the contributing part of the documentation, then email your patch in to guix-patches@gnu.org <rekado>civodul: oh, you fixed it five hours ago… *janneke just checked their mail ***jackhill_ is now known as jackhill
<lfam>Is there a command-line tool to list the actions that a Shepherd service provides? I tried e.g. `herd list-actions ssh` but it returns `herd: service 'ssh-daemon' does not have an action 'list-actions'` <lfam>I guess we have to set it up for each service? <lfam>Does anyone know if that stuff is in place for any existing services? <raghavgururajan>sneek, later tell apteryx: Not sure how to do the block thing in debbugs.gnu.org. Could you please block 40264 by 40285, 40291, 40307, 40348 and 40349? Thanks! <lfam>You can send messages based on that to <control@debbugs.gnu.org> <lfam>For example, to reopen a bug #99999, you'd send the message "reopen 99999" to that address <kmicu>My gnus must be broken cuz it shows Subject: Why did those credit managers start to burn my phone after I visited bank? in Newsgroups: gmane.comp.gnu.guix.user. /me double checks the date. <sirgazil>rekado: In the channels config using (guix ci): ~/.config/guix/channels.scm:11:19: In procedure string=: Wrong type argument in position 1 (expecting string): #f <sirgazil>which corresponds to: (string=? (evaluation-spec evaluation) "guix-modular-master") <rekado>sirgazil: you need a Guix from < 5 hours ago <rekado>because earlier versions return #f for any evaluation-spec <civodul>rekado: i wonder if we should somehow integrate this functionality with a command-line option <lfam>kmicu: It was definitely off-topic <raghavgururajan>sneek, later tell apteryx: Please disregard my message regarding block. <kmicu>lfam: thank you, I was really worried gnus messed up something. <lfam>I could not resist replying unfortunately <apteryx>raghavgururajan: I'm working at enabling doc + test for spandsp <sneek>apteryx, you have 3 messages! <sneek>apteryx, raghav-gururajan says: I have finished packaging all the linphone project's packages. All of them have been sent to https://issues.guix.gnu.org/issue/40264 . There will be no more new patches and only new versions. :-) <sneek>apteryx, raghavgururajan says: Not sure how to do the block thing in debbugs.gnu.org. Could you please block 40264 by 40285, 40291, 40307, 40348 and 40349? Thanks! <sneek>apteryx, raghavgururajan says: Please disregard my message regarding block. <apteryx>raghavgururajan: sounds good! I'll continue reviewing the rest tonight <apteryx>raghavgururajan: success building spandsp with docs + tests :-) it was a bit tricky <raghavgururajan>apteryx, I last noticed that 3 days ago. Shoot, its been down for 3 days it seems. <apteryx>I should have linted the thing earlier to cache it on Software Heritage ;-) <raghavgururajan>apteryx The source is saved in my /store. Is it possible to offload to guix's repo <nckx>Well, that would be technically possible but we don't do that as a matter of principle. <raghavgururajan>nckx May be for just spandsp, until the upstream source is back online? <nckx>I don't understand ‘spandsp’, but if it means ‘just this once for a few days’: no 😛 You can host the files somewhere and use that URL in your patches so people can test them & it's obvious where the source comes from. <nckx>I often find mirrors of tarballs just by searching "foo-2.3.tgz" in some search engines. Worth a try. Just make sure their hash matches. <nckx>raghavgururajan: cp? It's just a regular file. <nckx>If you forgot the name: guix build <package> --source. <nckx>That's not the source, it's a derivation that points to the source. If it's really all you have, open it with less and you'll see the store name at the top. <nckx>The guix command I gave above is more proper, though. *apteryx tries to understand how to search something on the softwareheritage.org website. *raghavgururajan is seeing the silver lining that the upstream source didn't go down few days earlier. It would like 'blocked' by linphone work. <lfam>You can probably find the source code on archive.org <apteryx>I'll try having this registered on softwareheritage <apteryx>it seems it stores only git/hg/svn repositories contents, not sure *nckx got disconnected again. <nckx>Yep, only VCS repositories AFAIK. <nckx>The Web Archive is a treasure we don't deserve. *janneke wants environment --target <nckx>Do they index tarballs, lfam? I didn't expect that. <apteryx>I think it'd be OK to use this mirror: https://github.com/jart/spandsp. It is in source form, contains only a mini commit above what was 0.0.6pre17 (fixing a string format issue), and is in source form, so can be requested for archival through Software Heritage. <lfam>We've used the archive before IIRC *nckx trying to find out but it's a bit… slow… <lfam>Yeah, we have some packages doing that nckx <nckx>I thought they only cached images and ‘under construction!!’ gifs. <apteryx>nckx: should we use this in our package definition? <apteryx>arg PRIMARY paste is so finnicky. I don't get it. <apteryx>It'll drive me to use a more capable term than xterm. *apteryx quits ranting about primary paste having changed behavior on a different machine ;-) <nckx>apteryx: Have you tried switching either to or from libinput? <apteryx>I tried in the paste I think (I had this issue on another machine too), but I should revisit the idea. <nckx>raghavgururajan: An A record's just a label that can point to anything. There doesn't seem to be an actual server at that IP address. <apteryx>nckx: I have this in my Xorg.0.log: [ 57938.365] (II) Using input driver 'libinput' for 'Razer Razer Lachesis' <apteryx>so it's using the libinput driver already, it seems. <nckx>Nobody reporting any similar issues with that hardware? <apteryx>I don't think it has to do with that mouse... I don't have another one to try but I reckon the behavior would stay the same. <apteryx>I must middle-click exactly on the cursor for the paste to be registered. I'm used to being able to middle-click anywhere on the screen, and if have the text pasted at the cursor. <nckx>You're right, that's not the driver's fault. <nckx>That's not just ‘used to’; that's how it's always worked and the only way it should ever work. <apteryx>yeah, that's really weird, and the internet is not being helpful. <nckx>Yeh. All I found were bots pretending to want to disable it. As if. <nckx>Does this happen everywhere? <apteryx>in xterm as well as in browsers and emacs <apteryx>arg. tif images aren't reproducible. *raghavgururajan gonna take a break from patches for some time <bricewge>Is there any reason behind `guix lint` using stderr instead of stdout? <anadon>It looks like if I go in and update Django, it will require a huge number of knock-off updates and likely break a ton of cases that users have built up. That being said, it still needs to happen. This could get messy. <lfam>What kinds of use cases could it break? To me a "use case" is a goal, but not necessarily a particular method of achieving a goal <lfam>Could people still accomplish the same things as before? <nckx>bricewge: You know. Somebody thought (probably not even consciously) ‘these are errors, they go to stderr’. I agree: it makes less sense when you stop & think about how it's used. <cbaines>anadon, I think in the case of Django, I think it would be useful to have a package for all the supported major versions <nckx>anadon: If the ‘use case’ is ‘this Jenga tower of power I've built has to keep working no matter wat’ they can always pin the exact profile that still works. <cbaines>anadon, if you added packages for Django 2 and Django 3, this would also avoid having to migrate all the build dependencies, at least immediately <efraim>lfam: doh, I messed up my bug report about --list-generations, I meant --list-profiles <efraim>i'll close that one and try again I think <lfam>efraim: I was thinking of profiles anyways <efraim>on one box where I have root # guix package --list-profiles | wc -l gives me 109 <efraim>yeah, definately looks like I messed up my bug report completely, mixed up --list-profiles and --list-generations <anadon>I think I'll go with nckx's approach on this. <anadon>And version 2 can be omitted since it was never really a thing in guix. <lfam>efraim: There are generations of profiles and generations of systems but one command has "--list-profiles" and the other has "--list-generations" <lfam>I've noticed confusion before <lfam>I'm not saying we should change it!!! We should have a GUI instead <apteryx>It'd be nice to have a GSoC adding a Guix backend for GNOME Software <apteryx>so that even casual users could be able to easily install Guix packages as well as keep their system updated. <lfam>I think it's a great idea and even necessary in the long term <lfam>To have a solid GUI for package management <nckx>apteryx: I agree. That's the only sensible way to GUI if we do. <Kozodev>Is this the right place to ask a question about building a module? <lfam>Kozodev: It's the right place for all things Guix <raghavgururajan>apteryx I would like to do that in future. After learning some coding. <Kozodev>I am new to Guix and Scheme and I'm attempting to build a package for wire messenger. When I try to build it though, I am getting "guix package: error: cannot install non-package object: #<unspecified>" <Kozodev>What's the best way to share code here? I'm new to IRC as well <lfam>Kozodev: You used the wrong character for the inputs list <lfam>It needs to be ` (tilde) <nojr>two questions: when and how is `revision` used in git-reference to build the uri? how do you build the uri? If seen some packages use comit commit others commit revision <raghavgururajan>Kozodev Wowza! You are working Wire. That's great. I was looking forward to it so much. <nojr>i'm trying to write a package definition <lfam>nojr: Check the package definition of yubico-pam for an example <lfam>nojr: No packages should be doing "commit revision". Can you say which ones are? <efraim>if they add a version tag to a git commit then we can pull the tag (version) and use that as the commit. If we're packaging a "random" commit then we have a version string but use (commit commit) to grab the actual commit listed <nojr>so if this is the very first package, which does not exist yet in guix, the revision number should be 1? <lfam>nojr: Yes, 1 or 0. It's up to you. <Kozodev>raghavgururajan: Thank you. I'll keep poking at it. <jonsger>lfam: NXP processor sounds good. From a freedom perspective <lfam>I just think that system is cool because it's a real workstation with some power that doesn't cost very much <jonsger>lfam: they tend to have quite good upstream linux kernel support <nojr>nice, I just wrote my first package <nojr>thanks everyone! btw, what happens once I have built the package succesfully? I see a gnu/store item was created but after guix packge --list-installed its not in my profile <nojr>how do I get it to my profile? <lfam>nojr: Do `guix install foo` where foo is your package name <nojr>lfam: getting error `unknown package` <lfam>nojr: What command did you use to build it? <nojr>also used guix package -i <nojr>I used guix build -K --file=my-first-package.scm <jonsger>lfam: though this doesn't say anything about the "platform" freedom like BIOS, booting et. al. <lfam>nojr: I think you can use `guix package --install-from-file=...scm`. You might need to also include --install <lfam>jonsger: Yeah, that's not a focus for that company. They just make hardware <lfam>But the price is low enough that kernel developers will buy it, I bet <lfam>nojr: Check the output of `guix package --help` to get ideas :) And check the manual section Package Management <nojr>lfam: that worked! I'll keep reading, kind of confused with guix build rn <nojr>now I need to send my first contribution :D <lfam>What are you confused about? <nojr>lfam: why guix build would not install the package after building it but appeard on the gnu/stores <lfam>nojr: `guix build` just builds packages, it doesn't install them. That's what the `guix package` command is for <lfam>`guix install` and `guix remove` are aliases for `guix package --install` and `guix package --remove` <lfam>`guix build` is a development tool, not a package management tool <apteryx>weird, automake is installing files listed in a nobase_data_DATA variable. The doc would lead me to believe that _DATA without a dist_ prefix should not be installed. <apteryx>perhaps nobase_data_DATA is expanded to nobase_dist_data_DATA? <Blackbeard>lfam: do you know any begginers bug I can start with? <anadon>nckx: Should I try the guix-devel mailing list for my paper? gwl-devel seems entirely dead. <nckx>Yes, I think I recommended that yesterday. I certainly thought it 🙂 <apteryx>perhaps it is because the sources are built, and should be marked with BUILT_SOURCES <anadon>nckx: I thought you mentioned the gwl-devel mailing list. I'll send out another to guix-devel soon. <lfam>Not sure Blackbeard... there's a lot of bugs :) <nckx>Nope, guix-. I didn't even remember the name of the GWL list. <lfam>Use that site because issues.guix.gnu.org doesn't always display all the bugs <Blackbeard>Can anyone give me some orientation on how to solve it <Kozodev>What does this error generally mean? "guix build: error: #<unspecified>: not something we can build" <nckx>Kozodev: Guix expects something that evaluates to a <package>, but you gave it nothing. What did you do? <nckx>Blackbeard: You'd edit etc/completion/bash/guix to add the same completion that (according to Jesse) is already present for other subcommands. <nckx>Blackbeard: Beware you won't be writing much if any Scheme. <nckx>Kozodev: But what are you running? <nckx>If you use ‘guix build -f <file>’, your pasted file needs to end with ‘wire’ as the last line. <Kozodev>I see, that is what I'm running. Guix build -f <nckx>Kozodev: (define foo "whee") doesn't evaluate to "whee", it evaluates to nothing. You need to say ‘now return foo’ at the end. <nckx>This is only the case for ‘-f’. <Kozodev>Yes, since I didn't know what that was doing, I was doing git add., etc to install using -i and getting the error logs that way <raghavgururajan>So I want to undo a commit in the history (5 commits back), rework and then commit again. How do I do it? <cbaines>raghavgururajan, an interactive rebase is probalby the way to go <raghavgururajan>The command `git reset Head^5` will undo all the 5 lst commit right? <cbaines>Have you done an interactive rebase before? <apteryx>raghavgururajan: git rebase -i HEAD~5 or something similar <apteryx>then choose 'edit' on the commit you want <apteryx>raghavgururajan: it will move the HEAD pointer to 5 commits earlier, than stop there for you to modify it. Then you can git stage (add) your changes, and git rebase --continue <apteryx>if you use emacs, magit is your friend. It allows you to do this with a couple key strokes. <raghavgururajan>apteryx So in the 9th commit from back, I removed the old bctoolbox and ortp definitions in telephony.scm. I did `git reset -i HEAD~9`, changed `pick` to `edit` for that commit. But when I go to telephony.scm, I do not see those definitions I removed. <apteryx>raghavgururajan: ah, you wanted to do 'git rebase -i', not 'git reset -i ' :-) <lfam>You run the rebase command, choose the commit to edit. It will put you in the Git repo at that commit. You need to undo the commit, edit it, recommit, and then continue <lfam>`git reset HEAD^` will undo the commit but keep the changes staged for `git add` <lfam>It's worth learning how to use `git reset` well if you are going to do interactive rebases a lot <apteryx>or you could modify the sources after your 'git rebase -i ...' then 'git commit --amend' to modify the existing commit at that point. <apteryx>actually no, just git add the changen then git rebase --continue should prompt you to edit the past commit messages. <lfam>Or you could make a new commit and then squash it with the old one <lfam>Okay, I've never used it like that but there are a million ways to use git <apteryx>It's confusing at first but with practice you'll get the hang of it. <lfam>Yes, it becomes second nature after the first hundred times <lfam>Now you can edit the changes and re-do the commit <raghavgururajan>Those changes were removal of some line in telephony.scm. How do I make them reappear? <lfam>`git reset --hard HEAD^` will erase the commit and put you on the previous commit. Is that what you want? <lfam>It would be easier if you could be more specific about what you were doing ***jonsger1 is now known as jonsger
<lfam>raghavgururajan: Check the man page of `git reset`, specifically the modes, --soft, --mixed, --hard, etc <lfam>bricewge: Do you know any good examples of implementing list-actions in services? Do any services besides the root service actually return anything for list-actions? <raghavgururajan>lfam In the 9th last commit (Remove bctoolbox and ortp), I removed package definitions of two packages. What should I do to make them reappear, make "define-public" to "define-deprecated", then commit. <lfam>raghavgururajan: Basically: `git rebase -i HEAD~10`, pick the commit to edit. Then, `git reset --hard HEAD^`. That erases the commit. Edit the files to use deprecated-package, commit in the normal way. Then `git rebase --continue` <bricewge>I use actions to create and delete polybars <seepel>Hi Guix! I have another (hopefully quick) question. What is the recommended way to handle bash scripts that expect to find things in /bin? <lfam>bricewge: But what about Guix services? For example, how can I make `herd doc ssh-daemon list-actions` actually list the available actions? <seepel>No, just a random script I found an the internet <bricewge>lfam: Yes there as some see `sudo herd doc udev list-actions` <apteryx>seepel: you could use '/usr/bin/env bash' as the shebang, since /usr/bin/env now exists in the Guix System. <lfam>bricewge: So, we need to add an (actions) field to the service definitions and populate it? <apteryx>you could also define an extra-file-service to create a /bin/bash on your Guix System. <seepel>This particular script is looking for /bin/rm, but it isn't the first time I've run into a problem like this. I guess there isn't a general solution? <bricewge>lfam: Yes there are no actions defined for ssh-daemon <bricewge>What actions were you thinking of for this service? <lfam>bricewge: Well, not for that service in particular <lfam>bricewge: I couldn't figure out to use list-actions at all, so maybe I missed the services I cared about, like nscd <lfam>Although it doesn't list the obvious things like start and stop <bricewge>It's indicated in the shepherd doc I think <lfam>Right, but maybe it would be better if it did :) <Blackbeard>I am trying to run a perl script that has "use Text::CSV;" <Blackbeard>I installed perl-text-csv and perl-text-csv-xs as my user <Blackbeard>Can't locate Text/CSV.pm in @INC (you may need to install the Text::CSV module) <cbaines>Blackbeard, does it look like the PERL5LIB environment variable is set to a sensible value? <bricewge>lfam: The doc talk about 2 special actions, there are 5 of them <Blackbeard>cbaines: oh I just logged out and log in again and it works :) <bricewge>lfam: I had thought of doing what you suggested but never went on doing it. <raghavgururajan>apteryx Instead of removing old definitions of bctoolbox and ortp in telephony.scm, how do I mark them deprecated? Can I just change `(package bctoolbox` to `(deprecated-package "bctoolbox" bctoolbox@0.6"` ?? <pkill9_>i did not know of the guix issues tracker <bricewge>rekado: That's exactly what I was looking for when Blackbeard asked for some issue. <nckx>raghavgururajan: The last argument must be a variable name, so it's not going to contain @. bctoolbox-0.6, perhaps, assuming that variable exists. <bricewge>rekado: This tag is not visible in the web interface of debbugs <apteryx>raghavgururajan: I think it'd be best that the deprecated symbols point to their more up-to-date versions. <nckx>bricewge: No tags are, you have to search for them. <apteryx>so I'd remove them, import the (gnu packages linphone) new symbols with a #:prefix :linphone, then (deprecated-package old-name linphone:new). I think this should work. <raghavgururajan>nckx Oh. The variable name is same. Right now there is bctoolbox (variable+package name) in both telephony.scm and linphone.scm. I want to mark the package in telephony.scm as deprecated, as it has old version and uses different build system. <bricewge>Yup, it looks like I can't read “Valid tags are patch, ... easy” <apteryx>raghavgururajan: I think I could explain it better in one of the emails I sent to you yesterday, on guix-patches. <nckx>raghavgururajan: That doesn't sound like anything needs to be deprecated at all, you've just updated + moved the package, no? <apteryx>nckx: we need to maintain the same API, no? (that (gnu packages telephony) still knows ortp) <apteryx>no need to deprecate the moved symbols, I was wrong about that, sorry :-) <nckx>The wild goose, there she flies away. <nckx>From the old module, yes. <nckx>And adjust any module imports, if any. <apteryx>raghavgururajan: I think the package definitions should be removed at the same time the new ones are added. <apteryx>Otherwise we can break someone's manifest. <pkill9_>oh, it works in an incognito window, so it's probably a cookie gone wrong or something <Guix-beginner7>Hello, trying to build a package but I am getting "/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: ./configure: No such file or directory" <lfam>Guix-beginner7: It means there is no ./configure script to run. You can delete the configure phase. Search existing packages for "delete 'configure" for examples <raghavgururajan>apteryx Ah I see! Let me know if first 4 patches of #40264 are good to be pushed. :-) <mbakke>Guix-beginner7: does the package have a "./configure" script? <nckx>Guix-beginner7: lfam is 100% correct, but it might be the case that your package does need to run ./configure but there just isn't a ./configure script. There's no way to tell which without more information. Are you building from a git check-out? Even better: which package is it? <mbakke>oh, Matrix is dropping IRC messages again. Fun. <joshuaBPMan>Hey #guix! I'm hanging out on meet.jit.si/guix Stop by if you want to chat. <apteryx>raghavgururajan: I just pushed a modified version of spandsp, and closed that one. <nckx>joshuaBPMan: I would if I could. Hope others do! <Guix-beginner7>I just downloaded the .tar.gz and extracted and I do not see a configure sript in the root folder <apteryx>raghavgururajan: could you address the review of 40291 at first given that it blocks 40264? <joshuaBPMan>nckx: that's ok. I should have probably planned it a bit more in advance. <nckx>Guix-beginner7: There's a meson.build file in there, so you need to use the meson-build-system, not the gnu-build-system. <joshuaBPMan>nckx: what do you think about the meson-build-system? I've got a parabola developer friend, that is annoyed at c-make and the like. He said that autotools does a really good job of building software everywhere. <mbakke>apteryx, nckx: any thoughts on the blog post discussion? *mbakke goes offline for about an hour <nckx>I agree, and I'm not wild about Meson (I think it's unnecessary, me-too-fad-driven, drags in a bloatload of dependencies for no good reason, and is only simple because it's young and inflexible), but eh. We need a build system that builds the stuff, can't really avoid it. <nckx>I personally hope Meson dies a quiet painless death. <nckx>joshuaBPMan: Whenever a Matrix user coughs up an emojo I like, I add it to my HexChat's auto-complete list. <joshuaBPMan>nckx: why? I will admit, then when I tried packaging something for the first time in autotools, it was a really weird sensation. Even the guix developers seem to want to replace it with a "guile based build system" <str1ngs>joshuaBPMan: guix does not replace autotools at all <nckx>Gnome don't exactly care about portability at any level, so they don't need a portable build system. <joshuaBPMan>str1ngs: I know. :) Guix has a google summer of project proposal to add a guile based build system. <alextee[m]>meson is much easier to use than autotools, that's the reason i migrated <alextee[m]>and forces you to do the right thing most of the time. but if there was a build system in guile, i'd gladly ditch it :-) <str1ngs>joshuaBPMan: can you link the GSOC proposal <str1ngs>autotools get's a bad rap. it does a good job. <alextee[m]>with autotools i was always stuck, i can't find information online when i need and m4 is unreadable to me <alextee[m]>a don't doubt that it's more powerful and portable though <alextee[m]>maybe if there was some guile tool to wrap autotools that would do the trick <joshuaBPMan>alextee[m]: yeah, that's my understanding too. I think even Chris Webber has a blog post somewhere moaning about auto tools being annoying <raghavgururajan>alextee[m] +1 for wrapping autotools with guile. That makes things schemey and yummy. ;-) <str1ngs>joshuaBPMan: I don't see the point of this. a build system that only runs on guix is not portable at all. <alextee[m]>raghavgururajan: writing build scripts in scheme sounds so awesome :D <joshuaBPMan>does anybody know of an easy (or good) way of using ledger mode with org-mode (using noweb) that lets you autocomplete the account names? <str1ngs>besides you an already use guile with make. the issues is configuration detection and shell portability. <alextee[m]>str1ngs: i want to do something like this in guile: (find-library "gtk+-3.0") and then add the return value to a list of dependencies <str1ngs>find-library is not a hard task. what about program arguement detection. like gnu tar vs bsdtar etc <alextee[m]>it would generate/run configure and make in the background <str1ngs>autotools does a good job now. the problem is nobody want to learn it. so lets create our own wheel <str1ngs>not to mention cross building, out of source building . install target and uninstall targets <alextee[m]>well, a wrapper over autotools not not a new wheel, more like a pimped up already existing wheel :P <alextee[m]>str1ngs: those should be defineable by the build system too <str1ngs>guix is already a wrapper around autootls. most package managers are just that. <str1ngs>as much as people don't like autotools they don't understand the need or it's history <str1ngs>before autotools there only existed configure.sh . everyone wrote this by hand it was a mess. <alextee[m]>they shouldn't, developers should focus on building software and not learning build systems, this is where meson comes in <raghavgururajan>>str1ngs: guix is already a wrapper around autootls. most package managers are just that. <str1ngs>IMHO lets spend time improving autotools and not reinventing the wheel. <alextee[m]>sure, and a move from M4 to guile would be a great start :D <str1ngs>yes, add support for guile instead of m4 would provide a migration path for exising GNU projects <str1ngs>or make m4 target guile instead of shell <str1ngs>this way you can do guile ./configure <str1ngs>though replacing m4 with guile would be better I think <alextee[m]>anything that makes it easy to write build configurations <str1ngs>does not make package management you still need to deal with projects that use cmake, meson, qmake, home rolled makefiles :) <alextee[m]>oh i meant build configurations for building software, not packaging it, not sure what the correct term is <alextee[m]>like the configure.ac equivalent or Makefile.am or whatever they were called <pkill9_>is guix in a VM not supposed to be able to modify the store? <pkill9_>it complains that the lock file is read only or something <str1ngs>pkill9_: I think vm's created with system vm are readonly <pkill9_>idk, maybe htat would introduce problems <pkill9_>is the store in the VM linked to the host system's store? <pkill9_>ok next issue, I can't run anything grpahical in the VM <pkill9_>it says "do not have CAP_SYS_ADMIN;cannot become DRM master" <pkill9_>adding user to video group didn't help <rekado>I just realized that “date:yesterday..now” is not actually a valid query for mu. <rekado>that’s why it would return all messages <pkill9_>listening to synthwave while hacking is calming 