IRC channel logs


back to list of logs

<lilyp>pardon my temporary absence from the discussion, I tried opening in my browser
<nckx>RIP 💀
<vagrantc>ok, so ... that thing i love about guix where you don't have any system paths? ... how do i $(CC) -shared -O3 -fPIC -Wl,-soname,$(ABIVERS) -o $@ $^ $(LIBS) ... where libs is something like -lsodium .... replace -lsodium with some guile substitution to the full path to the sodium input?
<lilyp>vagrantc: you typically add -L/gnu/store/... to $(LIBS)
<vagrantc>lilyp: thanks!
<vagrantc>to the specific input
<vagrantc>i'm surprised i haven't run into this before
<lilyp>depends on how esoteric the Makefiles you read are
<nckx>FAILED (failures=99)
<nckx>pashencija[m]: Is there any documentation that needs to be updated for the image API? I can't find any.
<pashencija[m]>nckx: Related to my changes - there's no documentation to update. But, in general, there's a lot to be added there
<nckx>Sure, there should be docs.
<pashencija[m]>Even if I find time to write these, there's still a problem of me being not much of an English speaker
<kiasoc5>is anyone working on updating qt to 5.15.4?
<yewscion>Hello Guix, does anyone have a workaround for `emacs-deferred` handy? I tried defining a transformation with `'(("without-tests" . "emacs-deferred"))` , but it didn't change anything. It's currently hanging and preventing me from upgrading, and I need certain packages that rely on it.
<excalamus>hello, Guix!
<the_tubular>Is guile-WM stable enough for daily use ?
<excalamus>Is there a way to build a Guix package for my project using a local repo? Right now, I'm having to commit and push my changes in order to test the Guix build.
<vagrantc>is there something similar to setuid binaries, but with capabilites (e.g. setcap) ?
<civodul>yewscion: there's a bug report:
<civodul>excalamus: yes, you can use --with-git-url=the-package=/path/to/repo for instance
<civodul>vagrantc: nope!
<vagrantc>civodul: well, nice to have a definitive answer :)
<excalamus>@civodul, ah, sweet! I was trying that with url and uri in the package definition
<vagrantc>have something that absolutely should not be setuid root ... but it requires networking capabilities
<yewscion>civodul: Thanks for the link! I was aware of the bug report, just going through my guix-home config and trying to get a reconfigure to work. It seems there are a few other packages also reporting the same issue (wrong-number-of-arguments), but in build instead of in check. Once I've made a list, should I add it to the above ticket or make a new
<vagrantc>ld: cannot find crti.o: No such file or directory ... do i need to explicitly add glibc ?
<vagrantc>there appear to be a few other mentions of working around or ignoring crti.o problems in guix.git
<civodul>vagrantc: you can use gcc-toolchain to have that all set up
<vagrantc>in inputs?
<vagrantc>hrm. adding #:use-module (gnu packages commencement) to networking.scm makes guix explode.
***tremon is now known as tremon_
<excalamus>I'll be honest, I'm not sure how I can use --with-git-url to help me write a Guix package definition using a local repo. I'm calling either guix build or guix package with -f, trying to create the build script. It seems like that requires a sourc entry. Also, --with-git-url=PACKAGE=/path/to/local/.git, as I'm reading it, needs the PACKAGE. That's what I'm trying to define.
<excalamus>I'm trying things like guix build -f my_definition.scm --with-git-url=my_package=/path/to/local/repo/.git
<excalamus>All I get is an error at the line in the package definition where "source" should be. If I include the source form, guix build uses that and not the head
<excalamus>Also I'm having to constantly manually copy and paste the path to the .drv.gz and call zcat on it just to see the error. Surely there's a better way?
***the_tubular27 is now known as the_tubular
<the_tubular>Anyone already tried guile-wm ?
<the_tubular>I was looking to use it to replace exwm
***taiju is now known as Guest2904
***taiju` is now known as taiju
***taiju_ is now known as taiju
***taiju is now known as Guest2456
***taiju` is now known as taiju
<lechner>Hi, startx fails locally with (installed via system)
<lechner>the_tubular: i packaged the version from jpe90 with help here but cannot currently start it
***taiju_ is now known as taiju
<jpoiret>is there a way to ask only for a specific output with guix build?
<lilyp>guix build will build all outputs always
<lilyp>post-process with grep :)
<jpoiret>lilyp: regarding libgccjit, i got the hello world running following
<jpoiret>we'd need lots of env variables, here's what got the example running outside of a shell:
<jpoiret>PATH="/gnu/store/ldhg9pylakiv11r620j6pjxkcz4x68hb-gcc-toolchain-9.4.0/bin:$PATH" LIBRARY_PATH="/gnu/store/3kr08micnpsnf10hq4ihkdks6s5fzvqh-libgccjit-9.4.0/lib/gcc/x86_64-unknown-linux-gnu/9.4.0/:/gnu/store/3kr08micnpsnf10hq4ihkdks6s5fzvqh-libgccjit-9.4.0/lib/:/gnu/store/ldhg9pylakiv11r620j6pjxkcz4x68hb-gcc-toolchain-9.4.0/lib:$LIBRARY_PATH" ./jit
<lilyp>Should we patch libgccjit so that it correctly invokes the linker?
<lilyp>(and the tools ofc)
<jpoiret>for the linker path, yes, for the library_path i'm not sure how we could do that
<jpoiret>and, to make matters worse, it's the gcc codebase we're talking about
<jpoiret>good luck finding the right place to patch :p
<PurpleSym>Installed Guix on a laptop with the cryptsetup instructions from the manual, but Grub says “no such device: <uuid>” “unknown filesystem”. Any pointers?
<jpoiret>lilyp: i think it'd be hard to do, since the linker and assembler are called by the gcc driver itself, not the jit specific code
<jpoiret>it's never been an issue because gcc-toolchain is always used in an environment with its env variables set
<lilyp>yeah, but libgccjit isn't
<jpoiret>it's going to be annoying for sure
<jpoiret>i'm not diving into the main gcc code that's for sure
<jpoiret>PurpleSym: did it ask you for a passphrase?
<PurpleSym>jpoiret: Nope, went straight to grub rescue shell.
<jpoiret>then you might have an issue with your uuid
<jpoiret>can you try `cryptomount -a`?
<jpoiret>does it ask for a passphrase? if so, your uuid is wrong
<PurpleSym>Nope, “unknown command cryptomount”
<PurpleSym>The UUID was the one from `cryptsetup luksUUID`, as the manual states.
<jpoiret>are you in the grub rescue shell?
<jpoiret>can you try insmod luks,luks2
<jpoiret>well, maybe insmod luks <RET> insmod luks2
<PurpleSym>“unknown filesystem”
<jpoiret>are you using luks2?
<PurpleSym>Yes, it’s the LUKS2 from the manual (i.e. with --pbkdf pbkdf2).
<jpoiret>is your /boot encrypted?
<PurpleSym>Probably. I did not create a separate partition.
<vivien>Hello guix!
<vivien>I have pushed un update to my patch,
<vivien>Could someone put the "v6" in a branch? I would like to test it in a setting where it’s difficult to patch and recompile guix.
<PurpleSym>`ls` only shows `(hd0)` – no partitions or anything. I remember there was some issue with NVMe disks, but I can’t find it.
<tinybronca[m]>PurpleSym: Hmmm does GRUB need specific NVMe drivers?
<PurpleSym>No idea.
<jpoiret>no, i think it's just that long standing luks2+grub bug
<jpoiret>grub-install doesn't understand luks2 drives and won't embed what's needed to open them
<jpoiret>and since /boot is on there, you won't be able to insmod the module
<jpoiret>the maintainers are trying to merge patches regarding that, i've written one that does exactly that
<jpoiret>hopefully next grub version we'll have that support
<jpoiret>the workaround for now is to have /boot unencrypted
<tinybronca[m]>jpoiret: Why does grub-install not understand LUKS2 I thought that support has been in GRUB for months if not years by now?
<PurpleSym>Is fat32 fine for /boot? I could just use the ESP then.
<tinybronca[m]>jpoiret: What if you store GRUB on different medium than the SSD?
<jpoiret>PurpleSym: that's exactly what i do! :p
<jpoiret>tinybronca[m]: you'd need to have /boot/grub/ unencrypted to be exact
<jpoiret>so that the luks2 module can be loaded
<tinybronca[m]>jpoiret: That is only if you install GRUB onto the SSD, right?
<PurpleSym>Alright, thanks, let’s do another `guix system init` then.
<jpoiret>GRUB has a luks2 module, but none of the userspace facilities are able to read luks2
<jpoiret>ie. grub-probe and most importantly grub-install
<jpoiret>no, regardless of where grub is installed you need to have /boot/grub/ unencrypted somewhere
<PurpleSym>ArchLinux also has some pointers:
<tinybronca[m]>jpoiret: Well I am used to /boot/ being a subdirectory of root filesystem on primary SSD, what if GRUB is installed for example on NAND/NOR Flash chip as a coreboot/libreboot payload?
<jpoiret>their patch is terrible, it might not work for devices with bigger sector sizes
<tinybronca[m]>jpoiret: whose patch?
<jpoiret>the one on the AUR
<jpoiret>the way forward is just to add luks2 support to the userspace utilities
<jpoiret>if you want I can send you the patches needed
<jpoiret>it'll just be a matter of inheriting grub and adding some patches, and changing the bootloader field
<tinybronca[m]>jpoiret: Oh what, someone already coded the support? Where is this code?
<jpoiret>tinybronca[m]: there are ~4-5 different patches on grub-devel
<jpoiret>full disclosure: i wrote one of those
<jpoiret>(please don't judge my c writing skills :p)
<tinybronca[m]><jpoiret> "tinybronca: there are ~4-5..." <- and they are in process of being reviewed before merging, or...?
<jpoiret>well, they're being reviewed right now after sitting idle for a couple of months
<tinybronca[m]>I am still not sure why /boot needs to be unencrypted if you don't have GRUB on SSD
<jpoiret>because GRUB will load its modules from /boot/grub/, including the luks2 modlue
<jpoiret>unless it is embedded directly in the GRUB image, which it should do if /boot/grub/ is in fact on a luks2 drive
<jpoiret>but this is what it does not do yet
<PurpleSym>Could we do that manually in Guix, so the instructions in the manual actually work?
<tinybronca[m]>I think I remember installing GRUB to a NAND Flash chip alongside Libreboot and it decrypted fine including encrypted /boot but I don't remember fully
*attila_lendvai has an thinkpad x200 with full disk encryption that has grub in its bios as a payload
<tinybronca[m]>attila_lendvai: Oh that is cool I think I did that too, that is what I meant, but saying "in its BIOS" sounds kind of confusing if you don't have a payload implementing BIOS, or am I missing something...?
<attila_lendvai>tinybronca[m], well, in the flash chip where the bios is usually sitting. IIRC the original bios is replaced by coreboot, and grub is given as its payload
<attila_lendvai>...or libreboot, or whichever. i can look up my notes if it is of interest. but when i looked a couple of months ago, much have changed around those projects in the past 2 years since i have done that.
<tinybronca[m]>How much does Libreboot implement BIOS-like subsystems on it's own? I thought that was what SeaBIOS was for....
<tinybronca[m]>(maybe wrong channel hah)
<PurpleSym>The instructions from the ArchLinux wiki worked by the way.
<jpoiret>PurpleSym: that would require us to fully emulate what grub-install does
<jpoiret>it does a lot of detection to embed the proper modules, the grub-mkimage way requires you to specify all modules iirc
<jpoiret>lots of corner cases we could miss, which grub-install takes care of
<PurpleSym>Mh, and there’s no way to tell `grub-install` to “always include the luks2, cryptomount, … in the image”? I see a `--modules` switch it least.
<PurpleSym>(At least for EFI that’s no problem, because there are pretty much no size restrictions, as opposed to MBR boot.)
<jpoiret>maybe you're right
<jpoiret>we'd have to include all the crypto modules too though which is a pain
<jpoiret>but that could definitely be done
<PurpleSym>Well, doing it by hand is pretty painful as well.
<jpoiret>or, we could just include the patches so that grub-install works as intended
<jpoiret>nothing really depends on grub so it's not a big rebuild
<PurpleSym>Sure, that’d be ideal. Is there an issue in debbugs somewhere already?
<jpoiret>for guix? not that i recall
<PurpleSym>Could you open one? I can test them on this laptop and another Guix machine I have. And if no-one objects then let’s just push them.
<jpoiret>i'll refactor my patch and include another from the grub mls first it'll take a bit of tim
<unmatched-paren>tinybronca[m]: i don't use libreboot, but i'm fairly sure that it _doesn't_
<unmatched-paren>bios subsystems are actually completely unnecessary if you think about it
<unmatched-paren>because riscv, arm, etc don't use anything like that
<tinybronca[m]>unmatched-paren: same with UEFI 🤣
<unmatched-paren>grub can run directly on bare metal
<nckx>It depends on your definition of ‘BIOS’ *shrug*
<nckx>unmatched-paren: No.
*tinybronca[m] doesn't want some weird FAT32 partition
<unmatched-paren>nckx: i see. what does it do then?
<nckx>unmatched-paren: The whole point of Coreboot is that it can't :)
<tinybronca[m]>unmatched-paren: I think GRUB needs to be loaded by something....
<nckx>Coreboot does very little (well, until you have to write it). It ‘just’ allows you to use luxuries like RAM and a screen :)
<unmatched-paren>hmm, then i don't really understand how it works without seabios...?
<unmatched-paren>ah, so it runs on coreboot's primitive functionality?
<unmatched-paren>i see. thanks for the correction!
<nckx>When a modern CPU boots it can't talk to RAM, when the RAM comes on-line it doesn't work, and it's not as simple as flipping the ‘RAM please’ bit. You have to do a pretty complex dance to ‘train’ it. That's one of the main things Coreboot does.
<nckx>I'll shut up now, but now you have enough to search for if you want to learn more :)
<tinybronca[m]>nckx: How about machines with U-Boot? They have to load U-Boot SPL into RAM as first stage, so they have to talk to RAM....
<unmatched-paren>tinybronca[m]: there's probably a bootstrap program that runs from ROM or something
<unmatched-paren>and then loads whatever the "U-Boot SPL" is
<unmatched-paren>after initializing RAM
*tinybronca[m] doesn't know how to study such code in MaskROM
<nckx>tinybronca[m]: I can almost guarantee you that U-boot is not the very first thing that boots. But I'm only really familiar with PCs. But anything using DDR has this problem, including ARM.
<unmatched-paren>"U-Bootstrap" :)
<nckx>I doubt they provide that, the vendor does.
<nckx>But now I just educated ars^Wguessing.
<tinybronca[m]>I think you can have ARM or Power ISA machines that are "PCs"
<tinybronca[m]>Unless you believe old Apple ads that PCs = Windows
<unmatched-paren>"PCs" often refers to Intel or AMD chips
<unmatched-paren>Plan 9 calls the x86 target "pc32"/"pc64" afaicr
<tinybronca[m]>dunno Plan 9 but there's ARM laptops and motherboards for desktops/workstations
<tinybronca[m]>I don't see how they are not PCs
<tinybronca[m]>TALOS POWER9 machines are quite beefy I guess
<unmatched-paren>yeah, it's a weird convention.
<nckx>What a bizarre tangent.
<nckx>Anyway, back at the point, searching for ‘u-boot cache as ram’ does turn up things like <> so I may well be mistaken.
<tinybronca[m]>nckx: The requested URL was not found on this server.
<tinybronca[m]>tinybronca[m]: oh sorry nvm
<tinybronca[m]>Why does no web frontend for mailing lists show more than one post at a time??? 🤨
<nckx>Some do, and the ones I've seen invariably suck. (Just a correlation, but an unfortunate one).
<nckx>What's that common light-green one… Anyway, it sucks.
<tinybronca[m]>nckx: What is the name of the frontend software that can do this?
<tinybronca[m]>Why sucks? I'd rather have something that sucks and can show threaded convo on one HTML page than clicking and loading hundreds of times just to try and follow a single thread
<nckx>Well, the gustibuss & all that.
<nckx>I really don't remember which site/software it was, sorry.
<tinybronca[m]>Sorry, we couldn't find: gustibuss
<tinybronca[m]>There are no definitions for this word.
<tinybronca[m]>Be the first to define it!
<nckx>I think the Mailman interface is my least unfavourite of them all, but that may well be Stockholm syndrome. At least I know where to look.
*tinybronca[m] tried....
<tinybronca[m]>no threading on one page = crap
<nckx>tinybronca[m]: ‘de gustibus’ if you really care, which I strongly advise you not to :)
<nckx>So the ones that don't are crap and the ones that do suck. Seems par for the course for software.
*unmatched-paren wonders if mumi could be extended to cover all mailing lists instead of just debbugs
<tinybronca[m]>nckx: cmon not all software is crap or sucks..... I don't think it would be hard to modify Mailman to do this, so many websites have threaded comments on one page
<tinybronca[m]>gustibus m
<tinybronca[m]> dative/ablative plural of gustus = taste
<nckx>tinybronca[m]: It's free software :)
<nckx>I think debbugs is fine, but if you think it's crap and not hard to modify, I have good news for you.
*nckx had mumi on the brain.
<PurpleSym>jpoiret: Ping me when you’re done. Thanks 🙂
<nckx>Though I don't ascribe the extreme relativism to it that Wikipedia seems to.
<nckx>tinybronca[m]: Do you like what LKML uses? It's a kind of hybrid IME.
<nckx>Which I find stressful because I encounter the same thread in different places & 'm never sure I read the whole thing, but you might like it.
<nckx> — minimal, yes.
<tinybronca[m]>nckx: yeah I have seen, it is better to have multiple messages on one page surely, but they could do better at rendering the threading
<bovid-19>Hi guix!
<nckx>I vaguely suspect their answer would be ‘download the mboxen and use a proper mail client, be thankful there's any Web UI at all’. 🤷
<nckx>Hello bovidperson.
<unmatched-paren>anyone know why ocaml deps are propagated in some packages and not in others?
<unmatched-paren>hello, yarl
<unmatched-paren>do i need to use file-name with url-fetch? if so what's the convention?
<bovid-19>I'm thinking a about using a local clone of the guix repository.  Is there something I'd need to do to keep getting substitutes?
<unmatched-paren>wdym? just `git clone`ing it?
<unmatched-paren>oh, using
<unmatched-paren>i see what you mean
<unmatched-paren>sorry, ignore me
<bovid-19>Maybe I should have written 'channel' before (or instead of?) 'repository'. I'm still far from fluent in Guix.
<nckx>pashencija[m]: I see why your GCC mail was ‘delayed’ — it's almost 8MB in size. That would be sent out to each bug-guix@ subscriber, which is a bit much! Not everyone has broadband, or even much band at all.
<nckx>pashencija[m]: So I've rejected the mailing list delivery, but there *is* a full copy on the bug tracker. Next time please compress logs over a few 100k (at most).
<nckx>bovid-19: Repository was correct.
<bovid-19>nckx: alright, thanks
<unmatched-paren>I was just confused :)
<unmatched-paren>there was no communication issues on your side
*unmatched-paren is easily confused
***PotentialUser-58 is now known as some-one
<nckx>Yay, buds.
<nckx>bovid-19: To answer your question (I think?) — assuming you already have substitutes configured in the daemon — you don't need to do anything. You'll get substitutes for any package you haven't modified (including by changing any of its inputs).
<nckx>Assuming the substitute exists upstream, of course.
<nckx>So if you edit only ‘hello’, you'll get substitutes for everything but hello. If you modify glibc, well, bad news.
<unmatched-paren>Modifying glibc may lead to bad news even if you don't care about substitutes :)
<nckx>No refunds.
<bovid-19>I won't try to dig myself into _that_ hole.  Way too glib for me.
<bovid-19>(sorry for that rotten pun)
<unmatched-paren>The only thing you could do that might be braver is modify the gcc that's used in guix builds.
<nckx>Nah: the bootstrap binaries. Think big.
<nckx>Or smol, actually, I guess...
<nckx>You get one bootstrap-related pun if you want, bovid-19, but two is a ban.
<apteryx>has anyone used guile-ac-d-bus?
<vivien>Among the ungooglable things is "how to bootstrap the typescript compiler?"
<apteryx>looking at their own packaging (using Akku), it seems this bit is missing from our package of it.
<tinybronca[m]><nckx> "pashencija: I see why your GCC..." <- wow who uses dial-up these days?
<jpoiret>tinybronca[m]: other possible complaint, my emacs would die in a fire if i had to open an 8MiB mail
<nckx>Mine handled it just fine? Your emacs is broken, buy a new one.
<unmatched-paren>vivien: Bootstrap was obviously created to stop those nasty free software people from searching up how to build things from source (UGH! Who does that?!)
<nckx>FSVO fine.
<nckx>I didn't smell burning hair tho'.
<bovid-19>Nah, boot straps aren't my thing.  I never found any boots fitting my hooves in this humanist world, so why would I even look for decorations?  And don't get me started on the material used for them...
<unmatched-paren>jpoiret: obviously you need to apply asbestos to your emacs to stop it burning* (*terms and conditions apply)
<jpoiret>nckx: remember that the reason i started working on the installer was because my emacs couldn't handle the pictures people were sending
*nckx has vegan boots, but they are strapless (like all good things). Hmm, I smell a conspiracy by big bootstrap.
<nckx>jpoiret: 😃 I've had to respond to a lot of those. ’Sorry, thank you very much for your bug report, unfortunately the 24 megabytes of PNGs you included […]’.
<nckx>The soft limit for (only) bug-guix is already a chonky 4MB for exactly that reason.
<jpoiret>oh no
<jpoiret>strerror is not async-signal safe
<jpoiret>diving into threading particulars really was the wrong thing to do
<unmatched-paren>jpoiret: strerrordesc_np looks to be AS-Safe, but it's a GNU extension :(
<unmatched-paren>ah, also "The resulting description is not translated"
<jpoiret>yeah, i guess that's why it is AS-safe
<jpoiret>other news, execvp is not as-safe according to the POSIX standard
<jpoiret>stay in school, don't do threads
<jpoiret>and forks
<tinybronca[m]><vivien> "Among the ungooglable things is..." <- I don't know, the tsc code I found was writtin in Typescript, but I never heard of a TypeSCript JIT compiler only a JS one, so what transpiles tsc??
<unmatched-paren>tinybronca[m]: tsc :)
*apteryx tries akku; to install a simple guile package (ac-d-bus), it needs like 1 min of CPU time solving dependencies
<unmatched-paren>tinybronca[m]: this is the whole problem that is trying to solve
<tinybronca[m]>unmatched-paren: I'm aware, but I don't see them explaining how the hell to bootstrap typescript
<tinybronca[m]>unmatched-paren: well there has to be another version of tsc than the one I found
<unmatched-paren>tinybronca[m]: i guess so. maybe if you do `git log --reverse` and checkout the first commit
<tinybronca[m]>what transpiles tsc if it is written in TypeScript??
<unmatched-paren>an already-transpiled version of tsc? i don't really understand the question
<bovid-19>nckx: hmm, I never thought about that. Do you think Elon is in on it or more of a saviour like You Know Coup (as Prophesized by Q)?  [see:].  Anyway, I guess I contributed my share gnush*t for the day and will try to refrain from adding any more to it.
*unmatched-paren confused (again :P)
<nckx>That went full <> very quickly.
<unmatched-paren>nckx: tbh that's more convincing than most "truther" infographics :P
<nckx>bovid-19: You win.
<nckx>Thank you kindly.
<nckx>It's all true.
<cbaines>is still going nckx ?
<cbaines>I just spotted it had some substitutes for staging
***tremon_ is now known as tremon
<nckx>cbaines: It is.
<nckx>It shouldn't be used for reproducibility stats (I pull substitutes from ci.guix when impatient) but is otherwise up.
<tremon>hi all, is it normal/expected for packages to have their configured statedir pointing inside the store?
<tremon>asking specifically for openldap, which tries to create its default ldapi socket as /gnu/store/[deriv]/var/run/slapi, which fails when run as non-root and clutters the store when run as root
<unmatched-paren>nckx: obviously the inputs are people, the build system means indoctrination, and the outputs are satanic cultists!!1!!1111!
<nckx>Both: it is normal/expected status quo but most packages would be improved by patching them to use /var. They are often left pointing to /gnu/store/…/var because that's easier and the package in question is configured to use /var through a service instead, but in a perfect world you'd patch them. Packages shipping prebuilt /var/db stuff complicate things though.
<tremon>scanning build-system/gnu.scm I don't see any obvious ways how prefix and/or localstatedir are set before compiling
<jpoiret>tremon: even when running as root, it shouldn't be able to write to the store as it is mounted ro
<jpoiret>and only mounted rw by the build daemon in a separate mount namespace
<nckx>tremon: --prefix is passed as a default configure-flag. The code you want is in guix/build/gnu-build-system.scm.
<nckx>It is split for good but initially confusing $reasons.
<tremon>ah, then I have some local configuring to do, as my setup doesn't include that namespace mount
<nckx>Oh yes.
<jpoiret>wdym? you are running the daemon without chroot support?
<nckx>Please do.
<nckx>That now.
<jpoiret>otherwise your store might just be borked now :)
<nckx>unmatched-paren: But the good kind of Satanic cultists :3
<jpoiret>(the build daemon calls it chroot support even though it is much more than just a chroot btw)
<tremon>I'm running the daemon in its normal configuration, but /gnu/store isn't an explicit readonly mount
<tremon>I should probably add that ;)
<jpoiret>you should remount it ro yourself, on systemd-based distros there's a service file for it
<jpoiret>then, guix gc --verify
<tremon>will do, thanks
<nckx>guix gc --verify=contents
<nckx>And guix gc --verify=contents,repair to automatically fix (through substitution) what it can.
<nckx>jpoiret: --verify alone is too lazy for this, I think, it only checks whether all exected /gnu/store/foo-x.y entries exist, it doesn't recurse (IIRC).
<jpoiret>oh, i thought --verify == --verify=contents
<nckx>Frankly that would make UX sense but nope.
<nckx>=contents is potentially much slower.
<bovid-19>unmatched-paren: I think most (if not all) of the problems with Satanism stem from the sheep-based system.  As an objective bystander who isn't involved in any way, I can assure you that gnu-based Satanism is superior in pretty much every way!
<nckx>And lo, the true dark gods did reach up and teach bovid-19 who's boss by tweaking their wi-fi.
<lechner>Hi, does xinit properly encode the path of the X executable?
<a13x5>lechner  I'm using something like this to actually run xinit
<a13x5>xinit -- $HOME/.guix-profile/bin/Xorg :0 vt1 -keeptty -configdir $HOME/.guix-profile/share/X11/xorg.conf.d -modulepath $HOME/.guix-profile/lib/xorg/modules
<a13x5>Otherwise it complains a lot
<lechner>a13x5: hi, you do not use startx?
<a13x5>Never liked it actually))
<unmatched-paren>apparently there's also `sx` (not an X user)
<unmatched-paren>`guix show sx`
<lechner>unmatched-paren: yeah, i tried that. it starts but i have no input
<bovid-19>nckx: not at all: they must have infiltrated my wired network.  I guess that's it for me.  Nice to have (virtually) known y'all!
<unmatched-paren>The cautionary tale of bovid-19.
<lechner>it's our fault. we should never have called them 'daemons'
<nckx>First bovid-19, now some pox-bearing beast. What hell is this.
<nckx>Heh, SCO. Poster was ahead of their time.
<monkey`>I am interested in using the Flutter uikit (built using Google's Dart language).
<monkey`>It is not available as a guix package. Is it not included for technical/libre reasons or
<monkey`>just not one has done so?
<unmatched-paren>monkey`: bootstrapping reasons i think
<unmatched-paren>and packaging issues
<unmatched-paren>I think it requires android studio?
<unmatched-paren>which is h e l l to package/build
<nckx>unmatched-paren: Have you tried?
<unmatched-paren>nckx: i have not but
<unmatched-paren>"weirdness and embedded FHS paths" is forboding
<unmatched-paren>s/which is/which is apparently/ if you insist :)
<unmatched-paren>"bundled with a lot of binary packages"
<nckx>Thanks. If it's anything close to Android proper it will be hell.
<unmatched-paren>"my main disk doesn't have enough space for that"
<nckx>Ah, so exactly like Android proper.
<unmatched-paren>"android's junk", "some tools are downloaded by gradle"
<unmatched-paren>"Android studio comes with its own Java version, but I found that it was somewhat broken"
<unmatched-paren>yeah, sounds like hell :)
<jpoiret>"look, open-source mobile OS" "what do you mean only google is able to build it reliably?"
<unmatched-paren>"open-source" is dubious, there's so many blobs
<unmatched-paren>at least on a default android... which I am forced to use because there are exactly 0 degoogled androids available for my phone :(
<monkey`>There is a blog about installing flutter without android studio. Would this method be sufficient for guix:
<unmatched-paren>monkey`: maybe!
<unmatched-paren>"Download Android SDK, Head to and download Command line tools only for Windows. After downloaded, just extract the folder (tools) in a new folder on "C:\Android".
<unmatched-paren>doesn't look like "without android studio"
<unmatched-paren>even if it only includes the CLI tools
<unmatched-paren> added to my list of "generally unreliable websites"
<nckx>~/flutter/bin master λ ./flutter
<nckx>Downloading Linux x64 Dart SDK from Flutter engine 436f18b5a22e778604235cf6db4c676f81a6f374...
<nckx>Dis gun b fun.
<monkey`>ha yeah. At this point I'm considering the foolish task of building my own reactive framework for opengl. That would takes years I imagine?
<nckx>Oh, it's all binary blobs! /home/nckx/flutter/bin/cache/dart-sdk/bin/dart: No such file or directory
*nckx gets the rm -rf thrower.
<unmatched-paren>what did you REALLY expect tho, nckx
<unmatched-paren>of _course_ it's all blobs
<nckx>I'm really not clued into all this mobile/Android stuff, so not much, but I can't say I'm surprised either.
<unmatched-paren>monkey`: i believe some of KDE's things work on Android
<nckx>I've managed to build a lightly customised Android from ‘‘‘‘source’’’’ and rip out the most egregious blobs (a minority) but that's it.
<nckx>Don't make it harder than it needs to be.
<unmatched-paren>that works too
<monkey`>I'm not necessarily interested in being blob free on mobile today, but I want a path towards blob free and flutter ain't it
<jackhill>raghavgururajan: could I temp you into reviewing ? XMPP client upgrade :)
***taiju` is now known as taiju
<lechner>Hi, regarding "Multiple profiles with Guix Home" on -devel I'd like to contribute that "in-home" profiles work potentiall only on one machine (my home folder is networked) and only after an encrypted home folder is mounted (i use gocryptfs). The thread is quite lengthy, and i lost track. Is my comment meaningful? Thanks!
<florhizome[m]>I‘m on a foreign distro / manjaro and installing packages with the OS package manager sometimes seems to fail because it refers to guix‘ glibc instead of the native one
<rekado_>the OS package manager refers to glibc from Guix? How?
<florhizome[m]>Good question
<rekado_>is LD_LIBRARY_PATH set?
<lechner>vagrantc might have a perspective, but is away
<rekado_>also, you wrote “sometimes”. What are the circumstances when it happens?
<florhizome[m]>Right now I want to install Joplin–appimage (the other packages failed before)
<florhizome[m]>so it’s a bit more complicated maybe
<peterpolidoro>hi, does anyone know how to configure git send-email to use pass, the standard unix password manager, rather than a plain text .git-credentials file? I tried using this guide: but that did not work for me
<florhizome[m]><rekado_> "also, you wrote “sometimes..." <- the package manager (paru) wants to enter a fakeroot environment
<florhizome[m]>Then comes the error
<florhizome[m]>bash: /gnu/store/….glibc-2.33/lib/ version ‚GLIBC_2.34‘ not found
<peterpolidoro>another question, when "mock" is listed as a dependency in a Python package, is adding "python-mock" to the Guix package native-inputs still necessary, even though mock is now part of the Python standard library?
<rekado_>florhizome[m]: can you trace the package manager with “strace -f” to see at what point it opens a file provided by Guix?
<rekado_>this error looks like it ends up loading *some* things from Guix while using others from the host system.
<florhizome[m]>it’s an interactive prompt though
<florhizome[m]>not sure how to direct the output into a file
<nckx>You can strace -p PID.
***taiju_ is now known as taiju
<nckx>I just noticed my /etc/environment is never loaded on my desktop (no LANG, TZDIR, &c.) but it is on the VTs. Has anyone encountered this?
<nckx>SDDM + Sway here.
<nckx>Could this be a pam_env oddity with autologin? #t ?
<vagrantc>is there absolutely no network interface inside of the environment used by "guix build PACKAGE" ? not even loopback?
*vagrantc taunts nckx for using a display manager
<nckx>It used to be the easiest sane way to get Sway *without* ever seeing a display manager. Has that changed?
<unmatched-paren>nckx: what do you mean by that? sway treats all display managers as unsupported
<unmatched-paren>the only supported way to launch it is running it from a tty
<nckx>What a drew thing to do.
<nckx>[Narrator: meanwhile, in the real world]
<nckx>unmatched-paren: That sounds tedious and stupid. Why would I do that?
<unmatched-paren>"Run sway from a TTY. Some display managers may work but are not supported by sway (gdm is known to work fairly well).
<unmatched-paren>nckx: it Works For Me :)
<nckx>Why would I want to type ‘sway’ <RET> every time I boot?
<nckx>Is this some kind of deliberately pointless Zen ritual?
<unmatched-paren>i mean, you could set up your shell to run sway when you log in for the first time...
<unmatched-paren>of course you'd have to make sure you don't run it every time you start a login shell
<unmatched-paren>only when you actually log in... not sure how you'd do that
*nckx groans.
<unmatched-paren>you can use sddm if you want -.o.-
<vagrantc>nckx: i just log in from the console and run "exec sway"
*nckx groans.
*jackhill runs sway from GDM, but hasn't checked into its environment
<unmatched-paren>it just might not work
<nckx>jackhill: Could you echo $TZDIR for me deary?
<vagrantc>i used to actually sometimes not start a graphical environment at all ...
<jpoiret>nckx: i get /gnu/store/jj5aj3zxf65b7zgismwgy2wad7kbkcqz-tzdata-2021e/share/zoneinfo
<jpoiret>running sway from gdm
<unmatched-paren>vagrantc: alas, The Web(TM) has made that impossible
<jackhill>on the one computer where GDM doesn't run, I log in on a console and `export WRL_DRM_NO_MODIFIERS; exec dbus-run-session sway` but clearly something is wrong with that computer. Also sometimes sway loses track of windows there 🤷
<nckx>vagrantc: So did I, but it was an 5x86 that I cooled with an ice cube in summer. It is a dark time to which I wish not to return.
<nckx>(Plastic freezer ice cube, before anyone complains about the warrantee.)
<nckx>jpoiret: Which DM do you use, if you still dare answer?
<nckx>Oh, gdm, missed it.
<nckx>So apparently GDM is the premier Sway experience manager. Hmm.
<nckx>That or time-travelling to 1997.
<nckx>What to do.
*nckx considers sourcing /etc/environment somewhere unholy so it just works.
<jackhill>I would love to get sway to use the GDM lock screen. I wonder if it's just a dbus message away.
<unmatched-paren>hmm. maybe there's some way to get `login(1)` to run a program other than the shell.
<unmatched-paren>on second thought, that would be rather stupid. you'd not be able to debug if sway malfunctions
<nckx>Interesting concept. Is it possible/easy to configure login(1) to log me in automatically? (As much as I respect everyone's apparent multi-line morning typing ritual, I'll pass.)
<nckx>I can do stupid.
<nckx>Stupid's fine.
<jpoiret>jackhill: i do something of that sort
<jpoiret>although the vt switching still works, which defeats it
<jpoiret>and also i have a bunch of gdm-session-worker zombie processes
<unmatched-paren>nckx: looks like $FAKE_SHELL would be the right variable to set. This is not a good idea, tho, as i said above. Terms and conditions apply.
<unmatched-paren>"If set, login will execute this shell instead of the users' shell specified in /etc/passwd."
*nckx grins.
<unmatched-paren>`sway\n` is five characters, y'know.
<vagrantc>nckx: your dark time is my broad daylight by your dark time is ok
<jpoiret>i run `sway-lock before-sleep 'script.scm'` where script.scm is
<jackhill>jpoiret: sounds like progress. One of my goals is to share a computer with other folks in the house and have the use-swtiching features work etc.
<unmatched-paren>your username+password is probably about three-four times that length
<unmatched-paren>nckx: oh, sorry, it's not an environment variable
<unmatched-paren>it should be put in /etc/login.defs
<jpoiret>note that GDM may not run on vt7 as well
<nckx>I don't type my user name, and my password is for LUKS, and after it I hit RET and go get my coffee and there better be gaudy pixels waiting for me when I get back.
<jpoiret>i'd love to switch to a greetd-based greeter
<unmatched-paren>nckx: man login.defs
<jpoiret>my morning routine is: open laptop lid -> see GDM greeter -> password
<jpoiret>i never really power down the damn thing
<unmatched-paren>This is still an utterly terrible idea. If sway freezes up... yeah.
<nckx>It's insane yes.
<jpoiret>nckx: can't gdm handle auto login?
<nckx>Sway has never frozen up on me once in several years. That I must say.
<nckx>jpoiret: I dunno, I've never used GDM.
<jpoiret>i think there is
<jpoiret>but yeah, gnome software
<unmatched-paren>nckx: i think half the reason sway doesn't support DMs is that they can be a little janky and generate issues that are not caused by sway
<jpoiret>yeah, DMs are really terrible
<jackhill>jpoiret: do you think gnome-shell will ever run correctly from anything but gdm?
<jpoiret>i'm not sure
<jpoiret>the gdm -> gnome-shell handoff is very complicated
<unmatched-paren>what does gnome-shell do that makes it require GDM?? surely they'd have a `startgnome3` program or something?
<jpoiret>especially since gdm already runs gnome-shell 🤡
<unmatched-paren>sorry, `startgnome40` :)
<jpoiret>unmatched-paren: you say that until you actually start looking at the abomination that is gdm
<unmatched-paren>*`startgnome4{0,1,2}` >:(
<jpoiret>i've tried launching gnome manually in the past on guix, but i can't remember if it worked or not
<jpoiret>most likely not
<unmatched-paren>jpoiret: i once looked at gnome code. never again. it's like glibc code but the grossness is amplified
<jpoiret>the gdm ui is not in the gdm repository, but fully in gnome-shell, which is a nightmare
<jpoiret>also, it's all in javascript
<unmatched-paren>jpoiret: oh my non-god.
<unmatched-paren>GNOME works in mysterious ways.
<jackhill>also crazy: gnome-shell uses gjs, which is Mozilla's JS engine, but GNOME/GTK uses JavaScriptCore from WebKit for JS for web functionality in apps! Two separate JS engines!
<unmatched-paren>jackhill: isn't gjs a wrapper or something around mozjs?
<unmatched-paren>they aren't the same thing afaicr
<jackhill>unmatched-paren: yeah, something like that. a gobject interface or something
<jackhill>unmatched-paren: oh? Of course not
<jpoiret>oh, and the GJS hello world example wasn't updated for the major version, so it doesn't compile
<jpoiret>as well as the whole documentation
<nckx>So y'all running this JS abomination from (s)hell but mock me for not wanting to hand-crank my WM every time. OK.
<nckx>jpoiret: ♥
<unmatched-paren>feast your eyes (glibc/galloca.h):
<jackhill>maybe I'll go back to using stone tablets or some such
<KarlJoad>How bad of an idea is symlinking c99 to gcc?
<KarlJoad>Nevermind. I found a better solution.
<lilyp>unmatched-paren: still saner than 90% of the rust code I've read so far
<KarlJoad>Does gcc-toolchain also contain the <linux/...> headers? From a quick compile of emacsql's sqlite, the toolchain does not.
<lilyp>pretty sure glibc headers reference the linux stuff deep down
<lilyp>you do need a kernel for some stdlib stuff after all :)
<apteryx>lilyp: I thought it was the other way around (the kernel copies some of glibc headers), though I may be wrong
<lilyp>iirc the kernel has its own libc that probably shares some similarities with glibc
<lilyp>guix show glibc | guix shell recutils -- recsel -n1 -p name,dependencies
<KarlJoad>I'm just trying to get org-roam to work with my straight.el config. For some reason, the sqlite binary is never produced. I tried to manually compile, but ran into that header issue.
<KarlJoad>Namely, <linux/falloc.h> is missing.
<nckx>KarlJoad: Did you provide linux-libre-headers?
<lilyp>can't you write your straight.el config so that it takes the guix package (or do you simply not want to?)
<apteryx>lilyp confirmed in #linux; the kernel depends on the libc, not the other way around
<nckx>That sounds bogus.
<lilyp>which libc?
<apteryx>typically glibc, but could be clang's too I guess (I heard it can build the kernel nowadays)
<nckx>Are you sure about this apteryx?
<apteryx>ah, sorry, I got it reversed :-) so you are both right
<nckx>(I wouldn't have blamed you anyway, #linux can be… variable.)
<KarlJoad>nckx: No, I did not.
<KarlJoad>lilyp: I just haven't done that yet.
<nckx>KarlJoad: I've downloaded gcc-toolchain in the meantime and it contains /include/linux/falloc.h as well, so the problem might be elsewhere. But try l-l-h first.
<lilyp>nckx: probably propagated-inputs
<nckx>No, I mean in the store directory lilyp.
<nckx>It's a linkerino.
<lilyp>doesn't gcc-toolchain do a union-build tho?
<nckx><gcc-toolchain>/include/linux → <linux-libre-headers>/include/linux
<apteryx>the k* stuff is failing en masse:
<apteryx>if any KDE enthusiasts are here, this is your game
<nckx>I don't know what union-build does, exactly, but possibly lilyp.
<nckx>However, that shouldn't matter?
<nckx>I've never heard of GCC rejecting a symlink.
<apteryx>nckx: it does what you can see under ~/.guix-profile, basically :-)
<nckx>It call union-build thrice.
<lilyp>you're right, it shouldn't
<nckx>That said I've used gcc-toolchain maybe twice (I have Guix after all…), so little do I know.
<lilyp>There might be bogus include paths in the recipe straight uses
<lilyp>i.e. it might ignore the fact that /gnu/store even exists
<nckx>Or it might overwrite or ignore C_INCLUDE_PATH (which is effectively the same thing, tru).
<nckx>So many wonderful things it could do!
<KarlJoad>nckx: "l-l-h"?
<nckx>I'm not really optimistic that it will make a diff.
<roman>Hello. What is the workflow to test changes to package definitions if I need to reconfigure my system with them to test? I've made modifications to the definition in the guix source code. I can install in the local profile with the pre-inst-env, but need to test it in the system configuration.
<davidl>using #$this-package-input "pcre:bin" for `((inputs ("pcre:bin" ,pcre "bin") ... doesn't give me a directory with the correct hash for the bin output but a directory containing the hash as if using the default "out" output. Is this a bug or am I doing it wrong?
<unmatched-paren>roman: you can probably do sudo ./pre-inst-env guix system reconfigure, and if it breaks things guix system roll-hack
<KarlJoad>nckx: Adding l-l-h actually did it. It seems to have compiled fine.
<davidl>roman: you can do: guix pull --url="$HOME"/src/guix --profile=/tmp/guix.master --disable-authentication ; GUIX_PROFILE="/tmp/guix.master"
<davidl>. "$GUIX_PROFILE/etc/profile"
<davidl>which -a guix
<davidl># should print /tmp/guix.master/bin/guix
<davidl>guix system reconfigure /path/to/config.scm
<KarlJoad>lilyp: I am trying to keep my Emacs straight configuration and Guix configurations as separate as I can, as I sometimes need to work on non-Guix distros.
<singpolyma>KarlJoad: you can install guix on any distro ;)
<singpolyma>Maybe someday even OR not using the kernel named linux
<jackhill>singpolyma: don't we already have guix-on-the kernel names hurd?
<KarlJoad>I know I can. Sometimes I don't have root permissions on those non-Guix distros.
<KarlJoad>E.G. University computers.
<unmatched-paren>I **think** (!) it **may** be possible to install guix without root, but don't quote me on that
<unmatched-paren>hmm, maybe not
<unmatched-paren>unless you hack something together with PRoot
<nalaginrut>how can I specify the local git repo as a source?
<nalaginrut>or local directory
<civodul>nalaginrut: hi! for guix pull, it's: guix pull --url=file://...
<civodul>likewise for time-machine
<nalaginrut>thanks! what about 'guix package -f"
<civodul>actually maybe i misunderstood; are you trying to pull Guix from a local repo, or to build a package from a local repo?
<nalaginrut>how should I write in a package definition
<nalaginrut>I want to build a package from a local directory
<civodul>ah ok (my reply was about the former)
<civodul>then try --with-source or --with-git-url:
<civodul>as in: guix build artanis --with-git-url=artanis=file://...
<nalaginrut>I want to build guile-dbi for guile3, and I modified the definition from guile-xyz.scm, put it somewhere. Now I want to build the source code with 'guix pacakge'.
<nalaginrut>or maybe 'guix build' does the same thing?
<unmatched-paren>`guix build` builds the package, `guix package` builds AND installs it
<unmatched-paren>if you modified the definition and put it in the file:
<unmatched-paren>s/the file/a file/
<oriansj>unmatched-paren: guix package doesn't build if one builds it prior to the package command
<nalaginrut>ok, so I need the latter
<unmatched-paren>guix (package | build) -f FILE.scm
<unmatched-paren>the file needs to return the package object
<unmatched-paren>oriansj: well, yes. neither does guix build. it's just caching.
<nalaginrut>I tried 'guix build -f FILE.scm', but the original definition will download from git with certain commit. I want to build it from a local repo.
<unmatched-paren>i'm tired :P
<unmatched-paren>nalaginrut: ok, does `guix build -f FILE.scm --with-source=file://...` work?
<nalaginrut>unmatched-paren: no, I need to know how to modify ("source" ...) item
<nalaginrut>otherwise it failed
<unmatched-paren>nalaginrut: can i see FILE.scm please?
<nalaginrut>unmatched-paren: it's copied from guile-xyz.scm, the definition of guile-dbi
<nalaginrut>I modified the inputs
<nalaginrut>to guile-3.0
<unmatched-paren>ah, k
<unmatched-paren>so you want to change (source ...) to a local directory?
<unmatched-paren>you'll need to import (guix gexp), then do (source (local-file "DIRECTORY" #:recursive? #t))
<nckx>nalaginrut: How did ‘guix build -f FILE.scm --with-source…’ fail?
<nckx>There is no reason it shouldn't work with your package.
<nalaginrut>nckx: the problem is that I removed (source ...)
<nalaginrut>unmatched-paren: it works! thanks!
<nckx>You made an invalid package.
<unmatched-paren>(source) takes a "file-like object" gexp, which is installed into the store. (local-file) takes a local file or directory and puts it in the store, (origin) grabs a file or directory from the internet
<nalaginrut>so I don't have to modify the (source ...) item, and just use --with-source?
<unmatched-paren>nalaginrut: yes
<nalaginrut>ok, I'll try
<unmatched-paren>as in, you don't have to modify it
<nckx>You shouldn't have deleted the source field. Or written (source #f). Packages without a (source …) won't even parse.
<nckx>It has nothing to do with local file or URL.
<unmatched-paren><package> is defined as a record-type*, and the (source) field is mandatory in it
<unmatched-paren>nalaginrut: still, if you intend to use this multiple times, you should modify the source instead of using --with-source
<nckx>Sharing your file when asked would have saved a lot of time.
<unmatched-paren>there's also (text-file) which takes a string and produces a file that contains that i think? might be called `plain-file` or something
<nalaginrut>nckx: it's copied from guile-xyz.scm, the guile-dbi definition
<unmatched-paren>nalaginrut: but you removed the (source) field
<nckx>Which did not tell us you deleted the source field. Hence, why sharing is better.
<unmatched-paren>which is why it didn't work
<nckx>Not because of some weirdness with file://.
<nalaginrut>alright, removing (source ...) was an accident.
<nckx>Or --file, for that matter.
<nckx>Files of all description were innocent!
<nalaginrut>it's not my original issue
<nalaginrut>now the problem is that it can't build because of compiling error. Strange, I can build it directly with the same guile installed via guix.
<unmatched-paren>nalaginrut: can you zless and show the log?
<nalaginrut>"/tmp/guix-build-guile3-dbi-2.1.8.drv-0/source/guile-dbi/libltdl/loaders/dlopen.c:63: multiple definition of `dlopen_LTX_get_vtable'; ../../libltdl/.libs/libltdlc.a(dlopen.o):/tmp/guix-build-guile3-dbi-2.1.8.drv-0/source/guile-dbi/libltdl/loaders/dlopen.c:63: first defined here
<nalaginrut>maybe a deps conflict?
<unmatched-paren>somehow it's trying to build it twice?... can you show us the package?
<unmatched-paren>*build the C file
<unmatched-paren>well, that's kind of what it looks like
<nalaginrut>you may try the vanilla code:
<nalaginrut>it can build with guile directly
<nalaginrut>guile-3.0.8 via guix
<unmatched-paren>the package, not the code :)
<nalaginrut>I can paste it somewhere
<nalaginrut>guile-dbi uses it own libltdl, dunno if it's the reason
<anadon>I need to draw attention to my patch for 54630; I didn't CC people so I don't think Ludo or TGR were notified.
<KarlJoad>What is the Guix way to describe a Nix Overlay? I want my Emacs to also understand where gcc-toolchain and linux-libre-headers are for itself, so emacsql-sqlite can build.
<jackhill>nckx: re: 1a6be557010bcf55d1c6d2e38ab1f8b5efe7303b what, pray tell, is wrong with the America/Los_angeles time zone?
<nckx>anadon: Indeed I was not; thanks!