***the_tubular74 is now known as the_tubular
<GNUtoo>Hi, is bash completion supposed to work in Guix, I run bash and I've bash completion installed in my operating-system declaration and somehow git doesn't autocomplete <GNUtoo>For instance 'git fetch or[tab]' autocompletes in Parabola but not in Guix (in the same repository) <civodul>GNUtoo: i noticed that Bash completion for Git specifically stopped working recently <gabber>Can i enforce a complete build from source of some package so i get all the build logs? How do i get the most verbose log from a build process? <oriansj>gabber: your build log is in: /var/log/guix/drvs/ ***toluene6 is now known as toluene
<mbakke>sneek: later tell gabber you can get the log file with 'guix build --log-file PACKAGE' <gnucode>bummer, I am trying to install guix system, and the installation image doesn't seem to be detecting my HHD.... <sneek>gnucode, you have 1 message! <sneek>gnucode, nckx says: Hullo :) <gnucode>df only seems to be reporting my usb stick image. <iyzsong>gnucode: df will only report mounted filesystems, 'fdisk -l' maybe more useful for you <gnucode>iyzsong I just tried that too. fdisk -l is only showing /dev/sda where the largest partition is 3.8GB. <gnucode>when I do fdisk /dev/sda it says this device contains an iso signature and it is currently mounted and in use. That's definitely the installation image.... bummer. <gnucode>I was so excited to install guix on it today... <iyzsong>um, does other gnu/linux can see the disk? <gnucode>I just bought this hard drive...., I was trying to install openBSD on it the other day...I think the installation was working, and then it crapped out...I'd really rather not have to buy another HHD, but I may have to to test it <gnucode>iyzsong I have only tried guix system installation image. <gnucode>iyzsong I suppose I can download the debian installation image and give that a try. <iyzsong>yes, i'd say it's rare for linux not detect the disks but openbsd can.. <gnucode>iyzsong it's definitely plugged in... <shcv[m]>so, I think I broke my guix by canceling a guix pull... now it says "unsupported manifest format" whenever I do a guix command <gnucode>shcv[m]: I think that's a known upgrade bug. <gnucode>I think they changed the manifest format. :) <gnucode>perhaps try te regerenerate your manifest file. <shcv[m]>odd I haven't run into that earlier today then, given how many pulls I've done <gnucode>shcv[m]: do you have a manifest file for your packages? <shcv[m]>probably not; this is on an installation media <shcv[m]>(though I think it's editable, so probably would still be messed up if I reboot) <shcv[m]>I can reflash the USB stick I guess if that's the easiest thing to do though <gnucode>shcv[m] yeah I would give that a try. :) <shcv[m]>is there a better way to make writeable install images that don't take so long to copy? e.g., make an image with just enough space for guix in it, copy it to the drive, then extend the partition? <iyzsong>shcv[m]: is it the image-based installation images (for arm systems, eg. pinebook pro)? maybe we can use it for x86 too, just dd to harkdisk and then boot.. <shcv[m]>iyzsong: no, just the normal "guix system image --image-size=8g install.scm", with a slightly customized install.scm to add zfs support and a few utilities <shcv[m]>though I should look into the image based install process you're describing <shcv[m]>sounds like it could be more like what I'm looking for <shcv[m]>also, I ran into the manifest error again after a normal pull (didn't cancel mid-way this time, so I guess that wasn't the problem) <apoorv569[m]>I am trying out `guix` for the first time and I was wondering how would you compile a third-party package? for example a package from a `git` repository using `make` or something. <apteryx>two options: A) package it (the better option) B) setup an environment to build it "by hand", e.g. 'guix shell make gcc-toolchain python-wrapper ...' <apoorv569[m]>Interesting! How do I package it? Can you point me to some documentation? <apoorv569[m]>Does setting up a environment creates like some temp directories `/bin` and all? <apteryx>apoorv569[m]: no, but it sets environment variable that have a similar effect, e.g. PATH <apteryx>for packaging, there should be lots of resources out there, the biggest and probably best being the Guix source code <apteryx>it contains 20000+ definitions to inspect and search, you can use 'git grep' to query something <apteryx>or open a basic package such as hello in your editor, 'guix edit hello' <apoorv569[m]>So if I am developing software, I have to setup the environment for it, unlike a regular distribution like arch or debian which uses the standard `unix` directory structure. <apteryx>to get started, a good read would be info '(guix) Contributing' <apteryx>what do you mean by setup? you'd also need to 'apt install foo' on Debian; here you can either 'guix install foo' or 'guix shell foo' or list all your project dependencies a manifest.scm file and 'guix shell -m manifets.scm' <apteryx>it's similarly easy, but more flexible/convenient <apteryx>also, if the package is already in guix (guix search foo), you can more simply 'guix shell -D foo' <apteryx>to spawn a build environment for foo <apoorv569[m]>I see. I guess I have try it out so understand better. But thanks for the info. <apoorv569[m]>Is `guix shell` a separate package? I am getting error `guix: shell: command not found` <apteryx>apoorv569[m]: you probably want to update your guix using 'guix pull' <apteryx>you should then have 'guix shell' available <apoorv569[m]>No my bad it was `guix environment` but now called `guix shell` <roptat>apoorv569[m], no guix shell is the new name for guix environment <roptat>guix environment has been around for a very long time <roptat>apoorv569[m], can you check "type guix" says it's ~/.config/guix/current/bin/guix (and not /usr/local/bin/guix or ~/.guix-profile/bin/guix)? <roptat>RudraveerMandal[, gdm is the default display manager <roptat>something's broken then, you should have guix shell available <apoorv569[m]>Ok `guix pull` was saying already updated but I rebooted the machine and now updating some packages <RudraveerMandal[><roptat> "Rudraveer Mandal, gdm is the..." <- But gdm has a dependency on gnome-shell <apoorv569[m]>Ok so I am trying to compile the `st` terminal I have my own build of it on `gitlab` I downloaded the dependencies from `guix` which include `freetype harfbuzz fontconfig pkg-config make` etc.. <apoorv569[m]>now I run `guix shell freetype harfbuff fontconfig pkg-config make` ? <apoorv569[m]>while creating the env or when running make inside `env` ? <roptat>I didn't know there was a binary called c99 <apoorv569[m]>ok it worked now I am missing `Xatom.h` probably `x.org` deps.. <apoorv569[m]>Hmm, I think I got the idea though how would it work, to manually compile a software. <apoorv569[m]>BTW, after compile do I just `sudo make install` would it work? <roptat>it will install, but I doubt you'll be able to run it <roptat>well, maybe it'll even have trouble finding /usr ^^' <roptat>oh we have /usr now, so nevermind <roptat>nckx, the Dutch translation of the website is very close to drop below 60% completion! <dirtcastle>zathura doesn't work for me. when I install zathura. it asks me to export guix profile . I did that multiple times. zathura doesn't open anything. even pdfs don't work <unmatched-paren>but test with a login shell first so you don't go to that trouble only to find it doesn't help <roptat[m]>would it make sense to add guix pull's news.scm on weblate for translation? asking before I write some tool to convert between news.scm and po and back <roptat[m]>news -> po would be easy, the other way might be harder <roptat[m]>also, it doesn't make too much sense to translate old entries ***dgcampea-2 is now known as dgcampea
<ekaitz>hi issues.guix.gnu.org is giving me a bad gateway 502 error <unmatched-paren>Oh my, I thought I'd seen bad dependency trees before but tuigreet's just exceeds them all... It depends on rust-i18n-embed, which depends on rust-rust-embed, which then depends on a whole load of web frameworks like rust-actix-web, rust-axum, rust-warp, rust-poem, and rust-salvo, many of which are composed of multiple packages and aren't themselves packaged yet. <unmatched-paren>All this for a little TUI that sends a bunch of JSON messages in the approximate direction of greetd. <unmatched-paren>Oh yes, most of these web frameworks depend on large, complex packages like hyper and tokio. <vivien>unmatched-paren, wait until you find out that NPM is involved <vivien>(I don’t know if it is, but be prepared) <unmatched-paren>Probably not, rust packages are usually quite well-behaved within the boundaries of cargo. <vivien>What if they embed precompiled typescript? <cnx>how do i open a firewall port? asking to use barrier <unmatched-paren>Why can't we have sane, well-behaved internationalization frameworks, not hulking behemoths like gettext and fluent? <cnx>what's wrong with gettext (i've only used it limitedly) <cnx>isn't there libgettext or sth (only used the wrapped one with python) <cnx>i suppose an alternative frontend could be written if to be used within make <unmatched-paren>I suppose. Surely, though, a program that takes a simple spec and produces a source file containing a function that maps strings to correctly localized text wouldn't be too hard to write, though? <vivien>cnx, does the network thing whose firewall you want to open run guix system? <cnx>hot take: the only way to avoid absurd dep tree is to make treeing difficult <mrvdb>https:/issues.guix.gnu.org down? <unmatched-paren>cnx: As in, don't make it possible to add tons of dependencies with a single line of TOML? <cnx>(, as in, make automated transitive dependencies propagation impossible upstream <cnx>thanks, vivien, i'll take a look <unmatched-paren>cnx: So all dependencies, even indirect ones, must be specified in the Cargo.toml? <cnx>no, indirect ones should be ambiguously documented <vivien>What if a direct dependency wants to use a newer version of one of its direct dependencies? Do they have to inform you to update your indirect dependencies? <cnx>like with c abi, it's difficult/time consuming to manually install nested dep tree, so people refrain from doing that <cnx>where does dbus-run-session come from? i have dbus-service enabled but the command doesn't come with it <cnx>nvm i need dbus package for the command <unmatched-paren>This is getting depressing. I think I'll take a break from this packaging session :) <rekado_>nckx: I can’t connect to ci.guix.gnu.org <ekaitz>am I the only one that can't visit issues.guix.gnu.org or is it a known issue? <ekaitz>aaah ok ok, I don't have logs and I get lost in this... <rekado_>no idea if anyone is working on it. I’m baking cup cakes. <ekaitz>rekado_: good idea, if you don't have access what else you can do? <RudraveerMandal[>I am doing (flags "size=2G mode=775") in a tmpfs mount but it's not working <rekado_>odd that the cuirass web interface at ci.guix.gnu.org is still up <rekado_>I can access it via serial interface <rekado_>what’s up with all these sshd-* services listed by herd status…? <nckx>Nope: Connection closed by 141.80.181.40 port 22 <sneek>Welcome back nckx, you have 1 message! <rekado_>shepherd says: Maximum number of 0.0.0.0:22 clients reached <rekado_>since when do we have sshd-<number> services? <nckx>A while. They are now transient, created on demand. <nckx>But 360 is a surprisingly low number to max out on. <nckx>(Mind goes to some kind of /second limit? Or just coincidence.) <nckx>rekado_: How are you logged in? <rekado_>I was connected to the serial interface, but now I can’t connect to that one either. <PotentialUser-53>hi all, is there anyway to install older packages on guix ? like if I want python 3.5.3 instead of 3.9.9, but only once off, can I get the guix package for the older version? <rekado_>PotentialUser-53: or add the Guix Past channel <nckx>(Enjoy the cupcakes—er, ‘lunch’.) <rekado_>cupcakes are for later; just finished them. <rekado_>nckx: serial console is still blank; I can reboot the server, but I’ll have guests over in a moment. I don’t really want to touch it today. <nckx>rekado_: OK, I can deal with this after work, we'll survive without Mumi for a bit. <nckx>RudraveerMandal[: It takes a single comma-separated string, by the way. <nckx>rekado_: Is it now actually possible to access the serial console when berlin is down? <nckx><87y1xiydqv.fsf@gmail.com> is the latest I can find and it says ‘no’. <mrvdb>i'm trying to install ungoogled-chromium on powerpc64le. go-1.16.15, as dependency fails during check phase: https://dpaste.org/ib5CZ (file too large failure). I can't check issues atm, as site is down. Anyone seen this before? Complete log is here: https://dpaste.org/iWfL0 (Large!) <antipode>README.md: Supported Oses: Android, [...], Linux, [...], Raspberry Pi <antipode>There's non-Linux Raspberry Pi, but otherwise a bit redundant <antipode>It also reads /etc/os-release & /etc/lsb-release to look for a 'system name' <antipode>Could perhaps be patched to 'Guix' (maybe not 'Guix System' because of foreign distros) <antipode>Will keep the old behaviour but I'll add a TODO-like comment that could be investigated later <Kurosh>Guys, does anyone know how to use IBus in Guix? IBus works everywhere except applications installed with Guix <nckx>mrvdb: Could you report this (with the info) to bug-guix@gnu.org? The issues.guix.gnu.org front-end is down but it will still be tracked & forwarded, and there's a second Web UI at debbugs.gnu.org. <nckx>mrvdb: Thanks! apteryx: Pity. <apteryx>In which package are the X11 keyboard layouts stored? <nckx>apteryx: xkeyboard-config yes. <nckx>Bad omen that it insists on hard-coding them at build time. <antipode>WDYT of compiling tests even when cross-compiling, installing them in a "tests" output such that tests can be run by on the system cross-compiled to? <antipode>It's difficult in the general case, but easy in case of Rust. <nckx>apteryx: Is this for a test suite? (That would be OK.) <nckx>antipode: Somebody else suggested that, I think. <nckx>Who knows with these nick jugglers nowadays. <nckx>I thought it was an interesting idea but too much work, I guess the Rust part negates that. <antipode>Yes, except for some outliers like librsvg and some individual packages assuming Cargo the build systems for Rust are very uniform. <antipode>It's more-or-less what I'm doing already in antioxidant. <antipode>The reason I ask, is native-inputs or inputs. <apteryx>nckx: any other path to consider for guix system? <apteryx>I can add more paths in xbk_keyboard_layout_engine.cc in the chromium source code of qtwebengine <mrvdb>nckx: bugreport submitted, pls let me know if you need more details <nckx>I've already answered you. <nckx>apteryx: Back at laptop now. Looks like quite a few packages have xkeyboard-config as input, so patching it in Qt6 wouldn't be unprecedented. It's just a shame because a good number of people like to customise their keys, meaning they'd have to rebuild Qt now IIUC. <nckx>Curious as to the reply to your report. <shcv[m]>does anyone else get the 'unsupported manifest file format' error after a first guix pull, or more importantly have suggestions on what I should do to avoid/fix it? <apteryx>nckx: indeed, the current state of thins is suboptimal <nckx>apteryx: Where can I build qtwebengine@6? ***califax_ is now known as califax
<apteryx>I haven't published anything yet, but it'll soon hit guix-patches <apteryx>it's about adding a chunk of Qt6 libraries, enough to build jami with it <apteryx>I still need to go and enable the test suite for each Qt6 package I added <apteryx>lilyp: I think you had worked on a patch similar to #42157, perhaps? Do you think we should merge something like this? <apteryx>To avoid the dreaded XDG_DATA_DIRS set by Guix breaks the session manager or similar reports. <apteryx>raghavgururajan: seems someone made a report about the recent gajim 1.4.6 (c.f.: #56651 and #46652) <nckx>I want a fresh pair of eyes on the thing, and yours would do just dandy. <nckx>I'd like to merge it tonight if nothing egregious pops up. <unmatched-paren>"Bundles jquery and several other .js libraries" sounds pretty egregious to me, but i guess we can allow it given that we don't want to put david larsson through hell <unmatched-paren>I also don't understand what (build-system copy-build-system) with no arguments is supposed to do. <nckx>They've already had the guided tour of purgatory at this point. <nckx>Are you saying it's a no-op? <unmatched-paren>that pydaemon package looks dubious, it could just use copy-build-system with a patch phase <unmatched-paren>copy-build-system installs the entire source directory as $out by default <unmatched-paren>the note about the pydaemon package also applies to the bash-coding-utils package <KarlJoad>I want to build a special version of stumpwm that includes contrib <KarlJoad> modules in the package, similar to how gcc-toolchain does special <KarlJoad> stuff to make gcc, binutils, and glibc understand each other. Would <KarlJoad> gcc-toolchain be a good idea to look at for inspiration? <rekado_>nckx: to access the serial console from .41 (node 129) someone needs to swap a cable in the data centre. <unmatched-paren>I can't write this down in an email because I'd need to be able to import the thread as an mbox <unmatched-paren>which aerc can't do without a patch that is currently sitting in its mailing list <jackhill>unmatched-paren: and you can't apply that patch because you'd need to import the thread, and to do so… :) <muradm>any chance that some one could look fail2ban thing? 56579 and 56608? <civodul`>unmatched-paren: TIL! i always wondered what "am" could possibly mean :-) ***civodul` is now known as civodul
<podiki[m]>unmatched-paren: yeah, "ratbleed" unveiled about a week ago <podiki[m]>but it doesn't affect current gen processors, for those lucky enough to have upgraded <unmatched-paren>I guess that'd be the name for a vulnerability in the Linux mouse driver... <rekado_>nckx, apteryx: do you want me to reboot? <nckx>I guess so. I don't see another way forward. <RudraveerMandal[><nckx> "I've already answered you." <- It still doesn't work the same error <nckx>RudraveerMandal[: Please paste the complete file-systems for at paste.debian.net. <apteryx>you'll have to play the russian roulette again... no the best things to do when one has guests <apteryx>rekado_: I'd personally wait for that cable to be swapped at the MDC, so that we can unlock 24/7 support via nckx and myself ;-). <nckx>You visit the site, copy your (file-system …) form into the empty text area, hit ‘Send’, and share the resulting URL here. <nckx>You can also paste the entire .scm file if that's easier. <rekado_>I can’t log in. Serial console shows no prompt. <nckx>apteryx, rekado_: If the machine still doesn't even boot reliably I'm with apteryx, but when can this cable be swapped? <rekado_>I also can’t just go to the data centre and connect a display, because our installed systems are configured strangely — last time I checked they boot without output to the screen. <nckx>I don't think you should go to the data centre if you're not working. <rekado_>I’m still on vacation, so I’d really like to avoid a visit to the data centre; none of my colleagues have any planned activities there either, so unless I call in a favor we’d have to wait until August. <RudraveerMandal[>There is a tool in gentoo that can be used to paste a file on 0x0 and others from the commandline <rekado_>very disappointed that the serial console let me down <drakonis>RudraveerMandal[: you can just use netcat with termbin <nckx>RudraveerMandal[: Use a browser? You can guix install links, or install curl and use http://ix.io/, or install or use wgetpaste, or… <nckx>ix.io probably works with wget if you can work out its arcane option syntax. <KarlJoad>RudraveerMandal[: You can use Curl and 0x0. I do it. <nckx>wgetpaste is the userest-friendly. <nckx>So probably not a good alternative. <nckx>(flags "size=2G,mode=775") <nckx>You didn't change anything? <nckx>Neither of these things are flags, you can't use the flags field for options, use (options "size=2G,mode=775") instead. <nckx>The manual page I linked to earlier has an example of what flags are (no-atime and the like), although it should be an exhaustive list instead of a ‘for example’ so users know that everything else is an option. <nckx>The ‘mount’ tool just throws them all together after -o, but they are in fact different in the API. <nckx>The good news for you is I don't see any actual flags in your code, so you should be safe simply changing all ‘flags’ to ‘options’ :) <nckx>(File systems are things you can mount.) <nckx>I'm not sure if Guix System supports a /gnu subvolume. Maybe someone else is. <nckx>I'm certainly curious to find out if it can boot from tmpfs. <nckx>Right. I'm familiar with the concept, but I haven't heard any success reports (yet!). <KarlJoad>From what I remember, it was because there are a few things that Guix puts into stateful spots it expects to still be there. <elais[m]>well an @gnustore subvolume that I map to `/gnu/store` <elais[m]>and the few stateful things are probably the stuff in `/var/cache` or whatever. No reason you couldn't create subvolumes for those <nckx>Well, /var/guix is very important, and must always be in sync with /gnu. <nckx>I certainly didn't mean to imply that mounting /gnu was enough. <nckx>Mount your darlings; erase the rest. <KarlJoad>I think Nix puts that under /nix/var, which is why it can boot with just /boot and /nix. <drakonis>the other thing is that it gets used with zfs or btrfs <kaelyn>That brings a question to my mind: why does Guix use "/gnu/store" for the store, with needed state off in /var/guix and nothing else under /gnu? <kaelyn>(the conversation a few minutes ago made me think, "/gnu seems guix-specific and has only one subdir, so why not /gnu/guix instead of /var/guix?") <elais[m]>probably because `/var/` is conventionally where stateful things go <acrow>vagrantc: Consolidated copyrights working -- sorting/formatting leads to many possible preferences. <elais[m]>I'm guessing if we make sure to keep /var/guix, /var/log, /gnu/store, and a /persist directory to store things like passwords we'll be most of the way there to booting from tmpfs <acrow>vagrantc: I keyed on email addresses -- turns out that might not be optimal. <kaelyn>elais[m]: quite true about the convention of "/var", but as I understand it, that is an old UNIX convention, like /bin and /sbin containing core programs needed to boot a system with general software installed under /usr, etc. Some of which are no longer adhered to by most Linux distros, and Guix deviating even more. <nckx>kaelyn: Only because of conventions (GNU standards), nothing more. <nckx>It could be moved to /gnu if it were worth it. <elais[m]>Well guix also, IMO, adheres to conventions that make a lot more sense than nix does (or at least did before flakes). All guix tooling follows GNU standards pretty closely except in cases where it probably can't <nckx>Consistent snapshotting being one advantage; lack of sane structure for those who want vars to be vars would be a disadvantage. *nckx is actually in the /gnu camp but has no robot dogs in this fight. <elais[m]>I suppose you could create a /var directory under gnu for the express purpose of syncing stuff in a stateless system rather than creating a separate /persist directory. I think only the /gnu/store subdirectory is mounted as unwritable <elais[m]>been a while since I messed with my "erase your darlings" config <nckx>elais[m]: Yes, not /gnu. <minima>it's a series of small patches - not even sure they're worth consideration (little more than applying guix import) <elais[m]>awesome, so if you wanted to you could treat /gnu like a others treat their /nix directory <minima>but i was curious to know if there's anything missing, anything that i should do at this stage or anything that can be improved/adjusted on my side <acrow>vagrantc: The peices all exist in the repl except for boilerplate concerning license texts. Those license texts will just be embedded in the program. I should mention that the debian format appears to only accept a single email address. Multiple addresses exist for some individuals. My presumption is to try and get the one associated with the most recent copyright entry. <vagrantc>acrow: separate lines for separate emails ... *could* be a different person <vagrantc>acrow: in fact, i would only consolidate exact matches <nckx>minima: There are a few tweaks I'd make to descriptions (The package → This package or The XXX package (I prefer the latter); framed → @code{framed} for clarity), but I noticed nothing that would necessitate sending a v2. <nckx>But hey, if you want an excuse to bump it in a week or two :o) <minima>that sounds like some good improvement, especially the @code{} bit, i should have thought of that <minima>great, yes, a good excuse to send a follow up in a week or two <acrow>vagrantc: Ok!, that is the way it is currently set up! I don't see any guidance on sorting. Here is a sample of the current output. http://ix.io/453Q <acrow>vagrantc: well, the consolidated-copyr piece. <vagrantc>acrow: i was sorting by first appears of copyright date, but other than that ... whichever i noticed first ... but sorting consistently would be a nice plus :) <mrvdb>what is the equivalent of 'gir1.2-gtk-3.0' in guix? The 'solaar' program wants it but 'guix install solaar' happily completes without it. Missing dependency? <acrow>vagrantc: ok, but you could also use eww. <nckx>Not having to use eww is its own reward. <antipode>Usually the gobject introspection data is installed in the relevant package itself. <antipode>Though possibly solaar is missing some wrapping or propagation (preferably the former), if that's what you mean. <nckx>mrvdb: Define ‘wants it’? <antipode>(What I mean is, the equivalent of gir1.2-gtk-3.0 is probably just gtk-3.0 itself) <lilyp>apteryx: I worked on a patch that documented XDG_DATA_DIRS, but maybe that can be improved some <mrvdb>nckx: when starting it says: "Solaar: missing required system package gir1.2-gtk-3.0" <nckx>guix shell --pure solaar -- solaar works fine here although I have 0 devices to test. <nckx>Can you try the above guix shell command? <nckx>Try guix shell --check first if you haven't to test for possible sources of environmental pollution. <mrvdb>nckx: guix shell -pure solaar works <nckx>Just to make sure: running ‘solaar’ inside the shell works? (I'd expect just ‘guix shell --pure solaar’ to always succeed.) <lilyp>antipode: indeed yes, gtk+ contains lib/girepository-1.0 <nckx>mrvdb: If so, this does sound like environmental interference from your ‘foreign’ distro. <acrow>paste.debian.net has it's own problems. It appears to have a max lines limit. <nckx>Not something I know things about. <mrvdb>yep, --check reveals it, this gives me something to look into. thanks. <nckx>But at least you can use shell --pure as a work-around. <davidl>maybe yall now but issues.guix.gnu.org is down (502 bad gateway) <acrow>I need to pare down the list from 585 lines to ???. Maybe change the sort to accentuate the problems. <davidl>Wohoo! Im crossing my fingers :-P <nckx>Your poor, broken fingers. <unmatched-paren>What I thought was you could switch both pydaemon and bash-coding-utils to copy-build-system with an extra phase for the patching <nckx>davidl: We were wondering: would it make sense to install pydaemon.sh as just pydaemon? The ‘primary’ command in $PATH shouldn't have an extension. The .py extension would stay, though. <unmatched-paren>Could it also make sense to install the .py scripts somewhere not in PATH? Seems like those scripts exist to be called from pydaemon.sh, right? <davidl>nckx: yes that would make sense. and yes, they should probably be in a libexec directory. <nckx>If nothing external calls them by name I would like to do so. pydaemon itself assumes they are in BASH_SOURCE[0], however. We could patch that in Guix, but ideally it would go upstream? <nckx>Er, dirname, but you get the point. <nckx>Which, assuming this is Bash-only as it appears to be, could be written as ${BASH_SOURCE[0]%/*} to save a binary invocation. <nckx>BASH_SOURCE is assumed to be valid so yes. <nckx>davidl: So specifically, I'd like to get rid of the first two SUBSTITUTE* regexes (the first by you using "$0" instead of $(dirname myself)/myself :), because those look like things that belong upstream (assuming you agree about moving to /libexec). However, that patch is something I'd feel comfortable pushing either way. *nckx glances at to-do list — actually, one more thing… <nckx>You need to add a licence grant. <nckx>Just add a licence header to each file, with a full copy of the licence text in COPYING. <nckx>(I'm not as familiar with CC as the GPL, but the same good practices apply to all licences.) <nckx>davidl: Since you sent us a patch claiming the licence is cc-by, you'd have a very hard time suing us, but that's the only evidence I can find of this being free software at all — I believe it's currently proprietary by default. <singpolyma>I wouldn't generally suggest putting license headers, but of course IANAL <antipode>a double ' works, but I would expect #~'((...) ...) to be slightly easier to understand. <antipode>Also, some nix people have written a tool that parses bash scripts to automatically do the equivalent of substitute*, which I'd expect to make the definition simpler (though again not required). <antipode>You are also writing to /tmp/SOME-location without checking that it doesn't exist yet, and then even reading code from it to execute, which is rather daring security-wise. <antipode>(In C land, you would check for EEXIST or such) <antipode>I recommend placing things in (some subdirectory of) /etc & /run, which aren't world-writable. <antipode>IIUC that you are upstream, you can also give it a nice version number instead of 0.0.0-dae... <antipode>Also I'd recommend checking whether this use of the CC-BY-SA@3.0 license is compatible will python's license <antipode>the GPL seems a better fit here to me as it was written for code in mind <antipode>I've unarmed the time bombs, hopefully those were all of them. <unmatched-paren>And then the COPYRIGHT.md file contains information about which licenses files are under, where you can find the full text, and a copyright statement list of all the people who have contributed code. <unmatched-paren>That way, you don't need a tedious list of everyone nor a summary of the license. <antipode>There's still a list of everyone though? <antipode>In the COPYRIGHT.md instead of individual files. <unmatched-paren>antipode: But a contributor doesn't have to write their name in every file they edit. Just COPYRIGHT.md. <unmatched-paren>It's quite easy to forget, in my experience, to add that copyright line in each file. <antipode>OTOH, what if you want to copy some code from a file to another project? <antipode>Then you'd need to copy everyone instead of only the people in the project. <unmatched-paren>True. OTOTOH, what if you want to copy a little bit of the code from one file to another file/project? How do you know who specifically has edited that section? <antipode>You don't (without digging through the history), though the list of people is at least reduced. <antipode>[K guix-packages-base-source 4.5MiB 410B/s 21:18 [# ] 11.1%guix substitute: error: fport_read: Connection reset by peer <nckx>antipode: I prefer ''(…), sorry 😉 #~' is harder to ‘understand’ (…that there's nothing special going on, that is) than simply ‘quote, but twice’ here. Gexps are the best thing ever but even I have my limits. <nckx>I thought I was a sucker for consistency but I guess not. <antipode>nested quasiquote is complicated, but #~ + ' isn't (though in this case it's quote, not quasiquote ...) <nckx>Double quote isn't, though. <nckx>antipode: I've already asked davidl to relicence to GPL if possible and willing, glad to hear more peer pressure building. <antipode>In my view, in this case s-exps are a special case of g-exps that don't import modules or do #$ / #+. <nckx>CC-BY-SA isn't too awesome for code. <nckx>antipode: Revisionist but interesting. <nckx>Is #~ performance identical to ' now? <antipode>TBC I mean in case of Guix code staging, outside the relevant Guix contexts this view is completely bogus. <nckx>I'm not going to pretend that's a huge factor in my utterly arbitrary taste preference, but it would be an argument. <antipode>nckx: #~(foo) constructs an object that contains the list (foo), so it can't be faster. <antipode>I don't know if the difference is neglible. <antipode>if you look at (guix build-system gnu), you'll see that s-exps are just directly converted to g-exps. <antipode>OTOH, (guix gexp) constructs a procedure to put into the <gexp>, and has a location field, which probably isn't the cheapest, compilation-time-wise. <antipode>Summarised, I don't know, though IIRC Ludo has done some performance tests. <antipode>FWIW I've written some optimisation ideas on IRC in the past (to make them even faster than s-exps by representing things as strings with gaps in them instead S-exp structures), though untested, maybe that would actually make things slower. <antipode>Untested idea for faster compilation: change (lambda #,formals #,sexp) to (const #,sexp) when (length formals)==0. <nckx>Who knows, across the entire code base… <antipode>Also maybe less .go size (there was some analysis that pointed at thunking causing large .go files) <nckx>(Serious) Does anyone care? Is it significant in places? <apteryx>I remember Wingo mentioning .go are not well optimized for size (ELF wise if I recall correctly). There are probably lower fruits to optimize .go sizes. <nckx>Only example that comes to mind is the initrd, but there compression might slightly save us. <apteryx>Guix is rather large on disk thanks to the big .go files *nckx wishes compsize was file-system agnostic — again. <apteryx>/gnu/store/ywshrqcyj76dqjkrbqlj0x7564q34h0n-guix-1.3.0-28.c23e0aa/lib/guile/3.0/site-ccache is 258 MiB <antipode>nckx: There was some analysis that pointed at thunking causing large .go sizes, and in case of too many thunks, compilation becomes a lot slower (something about exceeding the fixnum limit?), especially on 32-bit. <apteryx>compresses to 54M on Btrfs zstd, but not everybody uses that <antipode>Now imagine you run dozens of "guix pull", 2 * 12 * 258 = significant (though possibly deduplication helps) <antipode>(I don't know if my proposals would make a significant difference though! Completely untested!) <nckx>Possibly, but I'd easily see each generation differ by a few bytes per file or something silly. *antipode antis some oxen <nckx>Did restarting the jobs help at all? <antipode>antiox = against oxen = (after ofuscating) antis some oxen <antipode>It did help with the substitution-related failures. <antipode>But the new support for running tests lead to failing tests and hence failing builds. <antipode>So it's taking some time to resolve the failing tests and get back to close to 100%. <antipode>(no changes to the 'core' antioxidating code, only tweaks to the package structure such as skipping tests, missing test inputs, ...) <nckx>antipode: Ik was mee. But I don't think Unicode has oxen, hence a buffalo, which I have aliased to ‘gnu’, for maximal confusion. <nckx>If they have oxen, I didn't bother to check. <antipode> Confusingly, I didn't see the buffalo in your ˀ🐃ˀ. <antipode>It's invisible in Icedove. Probably missing fonts. <antipode>Only read that character by going to logs.guix.gnu.org in the browser. <nckx>That would prove their evil bias. <nckx>I'll stop using possibly confusing characters now. <sneek>From what I understand, ox is 🐃 <antipode>Clearly, oxen and gnu are the same thing. <antipode>sneek: sneek is a trustworthy expert in biology <sneek>From what I understand, Sneek is coaxial <nckx>sneek: sneek is a happy 🤖 <nckx>The ‘sneek’ column must be pages long by now. <antipode>Now some biology research group named 'sneek' should be formed, then sneek can appear in scientific journals. <antipode>There's a contradiction! That's how sneek is so many things, as by contradiction it is everything. <nckx>I've heard worse logic on this very Internet. <antipode>sneek: contradiction is sneek, so sneek is everything and nothing, and sneek is not everything and not something. <sneek>From what I understand, contradiction is sneek, so sneek is everything and nothing, and sneek is not everything and not something. <sneek>Someone once said Sneek is just picky… <sneek>Last time I checked Guix is pretty neat, it has all the packages and doesn't afraid of anything. <sneek>I could be wrong, but sneek is having absolutely what you are selling, friend. <sneek>Last time I checked Guix is pretty neat, it has all the packages and doesn't afraid of anything. <nckx>antipode: Oh you lucky pode. I just had to change the ''() to a quasiquote, so it's gettin' gexp'd. Go ahead, rejoice. <nckx>We don't talk about Nix. <antipode>sneek: Guix is the thing you are discussing on this channel, assuming you're at #guix and not one of these _other_ channels. <antipode>sneek: Nix is something you can replace by Guix. <antipode>sneek: Guix is not a fork of Nix (the daemon doesn't count) <sneek>From what I understand, malware is bad. <sneek>Last time I checked Guile is an implementation of the Scheme language. <sneek>I could be wrong, but Guile is an implementation of the Scheme language. <antipode>sneek: Guile is the language Guix is implemented in. <nckx>sneek: Nix is named in honour of Richard M. Nixon, a great man and shining example for us all. <unmatched-paren>sneek: Malware is commonly referred to as 'software written by the employees of one of several major software corporations'. <sneek>From what I understand, Malware is commonly referred to as 'software written by the employees of one of several major software corporations'. *vagrantc wonders when the bots rights people come out of the woodwork and defend poor sneek <sneek>Last time I checked Guix is the thing you are discussing on this channel, assuming you're at #guix and not one of these _other_ channels. <sneek>Last time I checked Bot is a thing that does not have right. <nckx>OK now it's getting dark. <antipode>sneek: malware is somehow sometimes free software, weirdly. <teythoon>guix/import/crate.scm:260:26: In procedure find-crate-version: <teythoon>error: string->semver-range: unbound variable <antipode>Question: context? Is this the guix from a "guix pull"? <teythoon>i'm using guix shell -D guix --pure, and a latestish guix checkout <antipode>TBC, the "guix import" happens inside the ./pre-inst-env and the ./pre-inst-env happens inside the "guix shell -D guix --pure"? <antipode>We have had cases were people ran the ./pre-inst-env outside the "guix shell" environment. <antipode>FWIW that environment looks reasonable, but I currently don't have a guix thing set up to test it in. <teythoon>;;; Failed to autoload string->semver-range in (semver ranges): <antipode>guile-semver seems missing from the guix package definition <antipode>Though really, it could just say "error: The module (semver ranges) could not be found. hint: Install the guile-semver package.". <teythoon>so when i import some crates, where in the 73kloc crates-io.scm file should i add those? <antipode>Put it as early in the file as possible that doesn't violate alphabetical ordering more. <antipode>What I meant is that not all crates have to go in crates-io.scm. <antipode>Especially if they are not I/O-related crates. <antipode>(AFAICT, it stands for I/O, not crates.io). <teythoon>are you saying that i need to categorize the crates? <antipode>tethyoon: You don't have to categorize the old crates. <antipode>But if you have a new crate, and a matching category exists, then you should put it in the matching categoru. <antipode>unmatched-paren: What does crates-gtk and crates-graphics stand for then? <unmatched-paren>antipode: I think it's somewhat arbitrary, but crates-gtk is for GTK+ and graphics is for things that handle drawing, colours, etc. <antipode>That's what I think to, though I don't think it's arbitrary, rather I think that Rust packaging has been neglected. <teythoon>so where should a command line parser and any crates it depends on go? <teythoon>or rather, the part that generates shell completions <antipode>It's not really I/O but it doesn't fit the others and crates-io seems to be currently a 'rest' category. <unmatched-paren>This, for instance, is not I/O: "A Rust library quotes, unquotes, and unescapes strings". <antipode>unmatched-paren: What I meant is that, if crates-gtk stands for GTK+ and crates-graphics stands for graphics, then if that scheme is followed, io stands for I/O <unmatched-paren>We should have more categories probably. Like crates-cli, crates-web, crates-multiprocessing, crates-text maybe <antipode>Then it should have been names crates-crates-io, to match the naming scheme of the rest. <unmatched-paren>So for some reason or other, the general crates file is named after crates.io. <antipode>FWIW, for C, C++, Vala, Fortran ... we don't have separate c-foo, c++-bar, vala-baz, ... categories. <unmatched-paren>(of course i mean 'qualified' with c-* and cxx-*, not 'they aren't qualified for categories' :)) <unmatched-paren>And there aren't that many Vala or Fortran packages as far as I know. <antipode>Though maybe they should be qualified as c (in a general sense, including C, C++, Vala and Fortran because they can easily be mixed). <unmatched-paren>Not sure why those languages get special treatment, that is a fair point. <unmatched-paren>But there are just so many lisp-*, python-*, go-*, rust-*, erlang-* packages, so I guess they need to be sorted out. Otherwise we'd have name collisions all over the place. <antipode>c-multiprocessing, rust-crypto, python-science, guile-dunno, ...? <antipode>Basically, two components in categorisation, an 'ABI family' and a 'conceptual categorisation'. <unmatched-paren>Well, there are a few C compilers, but also things like libbytesize, libfixposix, libhx, packcc, which are just miscellaneous C libraries. <antipode>And depending on how many packages an ABI family has, the categorisation is finer or coarser (but with mostly consistent naming across the ABI families). <nckx>We already have a file for random unrelated crap, it's called admin.scm. <antipode>And linux.scm tends to accumulate non-linux-specific things. <nckx>And failing that, linux.scm, ‘because it runs on Linux’. <unmatched-paren>Let's just give up and shove everything in gnu/packages.scm, categorization is too hard :) <antipode>FWIW we could also just .... not do categorisation. <nckx>I can *never* find packages in Nix (without grep). <jackhill>the categorization is also part of the package name though <antipode>(maybe with some exceptions, e.g. for Minetest mods putting them together works fine) <antipode>jackhill: IIUC, we were talking about the categorisation into modules, not about package names. <jackhill>antipode: ah, I misread and thought you were talking about both, thanks! <antipode>Though prefixes for c-ish things would be possible too! <nckx>unmatched-paren: We don't have to. It's a choice. <nckx>But changing that would be an absolute ‘IANAL but…’ shedfest. <antipode>nckx: I usually use "git grep" or "guix search" to find packages. <nckx>antipode: I don't have a Nix checkout to grep. <nckx>Sometimes the GitHub search provides useful results, sometimes it's on page 5, depends. <nckx>But browsing the tree never gets me to where I expect it to be. <antipode>TBC, I meant "git grep" for searching for the location of Guix packages. <antipode>And "guix search" for searching for packages. <nckx>I mostly use [a script that wraps] grep for Guix, yes. <antipode>And "guix show" to find the location of a package I already know the Guix name of. <drakonis>nckx: does guix search not work for you? <nckx>I never use it, because I never want to search full metadata. I use grep because it's faster, not because the supported methods don't work. <nckx>I'd use guix package -A if so. <antipode>I sometimes do "EDITOR=echo guix edit the-package" to determine the location. <nckx>s/if so/if I used the Guix CLI for that/ <nckx>echo is the standard text viewer. <drakonis>antipode: giving each package a module would require changes for discoverability <antipode>For some reason, the EDITOR=echo trick makes me think of continuation. <antipode>drakonis: (gnu package guile guile-json)? <nckx>I use VISUAL=cat a lot which is just really sick. <antipode>It's technically possible to have both categorisation and individual modules. <nckx>I think that would rainbowify my commit messages, if lolcat doesn't check for a TTY. <nckx>I don't think people would be amused. <nckx>Nor can I find it mentioned in the ChangeLog standards. <nckx>(I use it when running git rebase/amend where I don't want it to pop up a stupid editor window each time.) <antipode>Splitting packages of into (gnu packages category package) modules where needed to reduce cycles could potentially help with reducing cycles a lot. <unmatched-paren>ChangeLog is standardized? I could never find any comprehensive description. <nckx>unmatched-paren: And yet it is. <antipode>(which opens up some methods for making "guix pull" incremental -> faster) <rekado_>antipode: I don’t see how that would help <antipode>rekado, drakonis: I've previously started an e-mail thread about this, I could give a link? <nckx>unmatched-paren: Right, but most of it *is* encoded in our practice, not explicity documented, at least the many Guix-specific conventions. <rekado_>there’s no clear separation between ‘core’ pcakages and everything else <antipode>rekado_: the goal is not to eliminate all cycles, but to reduce them a lot. <rekado_>this discussion of categorization and splitting modules etc is recurring <rekado_>cutting cycles is also not something you’re ever really done with <antipode>rekado: We could have a linker that enforces "no extra cycles unless they are in the approved list"r <antipode>and by reducing them a lot, the DAG of strongly connected components can be computed, <antipode>which can be compiled efficiently (if some leaves change, no need to recompute the non-leafs, etc.) <antipode>On how the discussions are recurring: I have in the past suggested different methods (for compilation, multiple for reducing cycles). But I never received a clear: yes, that looks a good proposal, let's start doing that. <rekado_>I’d like to see a proof of concept, and perhaps some guarantees that this won’t result in reshuffling of package definitions every few months, breaking third-party channels. <antipode>(the former can be done without the latter, but the former would be much more effective after doing the latter) <nckx>Anything demonstrating (rather than promising) a compelling effect would be a start. <antipode>A possible problem is that it only becomes compelling after a lot of work is put into cycle breaking, and then people might disagree on the cycle breaking method, and then the cycle breaking has to start all over again. <antipode>Though maybe there are enough leavy modules to demonstrate the SCC method ... *rekado_ just finished reading all messages in 54539 <jpoiret>i wonder about the performance impact of such a method 
