IRC channel logs

2021-09-16.log

back to list of logs

<mbakke>PotentialUser-92: what happened?
<mbakke>bootloader is the most fragile part of Guix, no rolling back from mistakes :/
<PotentialUser-92>ext4fs kept complaining about how much it wants large_dir enabled, so I did that
<PotentialUser-92>turns out there's not one, but two bug reports about grub not liking that
<mbakke>PotentialUser-92: oh my, I did not know that. Perhaps Guix should warn when large_dir is enabled and GRUB is the bootloader?
<PotentialUser-92>are there other bootloaders that understand large_dir is the better question
<mbakke>PotentialUser-92: apparently there are other ext4 features that can break GRUB too: https://savannah.gnu.org/bugs/?56897
<PotentialUser-26>Hmm, so I am able to build a new install iso using gnu/system/install.scm now, but I am unsure how to add a kernel module to it
<PotentialUser-92>PotentialUser-26: (kernel-loadable-modules (list my-totally-legit-kernel-module))?
<mbakke>often in conjunction with kernel-module-loader-service-type: https://guix.gnu.org/manual/en/guix.html#index-kernel_002dmodule_002dloader_002dservice_002dtype
<roptat>oh no I'm missing sources for dart-ast :/
<PotentialUser-26>So I;m pretty confused. Do I add this stuff in gnu/system/install.scm? I dont see a operating-system section in there
<pkill9>nice, I like guix's new behaviour of showing which package failed to build due to a dpeendency failing to build
<pkill9>it turns out genimage has a dependency on qtbase, lol
<mbakke>PotentialUser-26: there is an operating-system section there, in the 'installation-os' variable
<PotentialUser-26>Ahh I installed nvim and can find it. Not sure why didnt work in vi
<pkill9>how do i search jobs on guix data service?
<pkill9>nvm
<pkill9>is anyone unable to build qb
<pkill9>qtbase on ARM ?*
<oriansj>pkill9: you mean because of the non-deterministic behavior of the floating point operations that causes the test to fail?
<oriansj>or because of the floating calculations are done at 64bits of precision instead of 80bits like on x86 and thus the results are different. (because that is also a common cause)
<pkill9>oriansj: well the compilation fails so idk
<pkill9>In file included from ../../corelib/serialization/qcborvalue.cpp:3190:0:
<pkill9>../../corelib/serialization/qcbormap.cpp: In member function ‘QCborValue QCborMap::extract(QCborMap::iterator)’:
<pkill9>../../corelib/serialization/qcbormap.cpp:1126:12: internal compiler error: Segmentation fault
<pkill9> QCborValue QCborMap::extract(iterator it)
<pkill9> ^~~~~~~~
<pkill9>and
<pkill9>../../corelib/serialization/qjsoncbor.cpp: In member function ‘QVariantMap QCborMap::toVariantMap() const’:
<pkill9>../../corelib/serialization/qjsoncbor.cpp:898:13: internal compiler error: Segmentation fault
<pkill9> QVariantMap QCborMap::toVariantMap() const
<pkill9> ^~~~~~~~
<singpolyma>So, it seems that just runnign guix archive --export package fails for me... is there anyone else who has seen that?
<brendyn>anyway else just watch inspiration4? \o/
<PotentialUser-26>having trouble adding dm-thin-pool to kernel-loadable-modules. I get "error: md-thin-pool: unbound variable". making it a string doesnt work either
<roptat>ah the sources are in kotlin's sources already, so the error was caused by me using a previous version as an input
<singpolyma>Ok, finally fixed my guix copy. So... I can do guix install -p /whatever/profile /gnu/store/blah and get a specific package I copied installed to a profile, but that doesn't get propogated inputs because the store item doesn't know about inputs. What is the minimum I need to get an install to work? Do I actually need all the source so guix can hash it to know that it's already installed?
<robin>PotentialUser-26, kernel-loadable-modules is for packages, you don't need to change it assuming md-thin-pool is included with the kernel by default
<podiki[m]>on the grub ext4 large_dir, bug report on bug-grub got no response. pretty sure it is well known, but no idea why it is 4 years in ext4 and no update on grub for it
<PotentialUser-26>Its not included, and I'm trying to install guix system. The iso image doesnt have it and cant figure out how to add it to a newly built image
<robin>PotentialUser-26, depending on how early it needs to be loaded, you probably need to add it to initrd-modules ('(cons "md-thin-pool" %base-initrd-modules)') or use kernel-module-loader-service-type
<PotentialUser-26>I'll try initrd-modules
<robin>PotentialUser-26, hrm, you probably need to use a custom kernel package then, if it's an upstreamed module that's not built by default
<robin>PotentialUser-26, something like this, with different options of course: https://paste.debian.net/1211930/
<robin>...and presumably with the symbol m instead of #t to build it as a module, and then you can use it as the kernel in the os declaration
<PotentialUser-26>would that go somewhere in gnu/system/install.scm? and #t would be fine, I dont care if its a module or built-in
<robin>(gnu/packages/linux.scm has some configuration examples)
<robin>no, in /etc/config.scm...but if you need the module for installation, i think you'll need to build your own install iso
<PotentialUser-26>Thats what
<PotentialUser-26>Sorry, typo. Thats what im trying at the moment
<robin>oh whoops, you're right, my brain is fried right now :p
<robin>yeah, install.scm should work, i imagine you'd use your custom kernel in installation-os
<singpolyma>Is there any reason building a package on two different systems from the same package definition might result in different store items / hashes?
<roptat>grafts, or using a different guix version?
<roptat>even if the definition is the same doesn't mean the dependencies are linked to the same package. if they have a different hash, the result has a different hash too
<singpolyma>should be same guix version, I just puleed them both. talk to me about grafts
<kozo[m]>You can use guix describe to make sure they are identical
<roptat>mh, if you didn't do anything special, they're the same on both side
<roptat>I mean, same grafts are applied
<singpolyma>guix describe says guix 33bc3fb on both
<brendyn>singpolyma, many packages are not reproducible or their dependencies arent.
<brendyn>use diffoscope to inspect the difference
<roptat>since each time a package is modified, the hashes of all its dependents are modified, all the dependents need to be rebuilt, even if the result is identical (up to the hash). grafts are used as a lightweight mecanism for security fixes that would otherwise entail rebuilding too many packages. we simply copy the package to another store item, replacing references to vulnerable packages with references to the fixed package
<brendyn>for example guix pack one of them, copy to the other computer, extract and compare
<roptat>that can create multiple store items with identical name, but different hash, and can cause some confusion too
<brendyn>otherwise trying guix build --no-grafts --check --rounds=2 is also useful
<roptat>oh wait when you say "hash", did you mean the store path, or like the sha256 of the content?
<singpolyma>locally I run guix build -n -L . my-package and it just prints the store item. On remote I run the same thing (after doing guix copy so the store item is there also) and it says it wants to build with a new store item name
<roptat>ah that could be grafts: the result of "guix build ..." is the one with grafts, but guix doesn't know about this store item until it's built the ungrafted version
<roptat>try the same, with --no-grafts on both sides
<singpolyma>build with --no-grafts, copied with --no-grafts, run build -n --no-grafts locally prints a different store item than before, run on remote prints the same as before
<singpolyma>oh weird, I do have the .drv it wants to build remotely in my local store
<singpolyma>maybe copy isn't copying the drv?
<singpolyma>Oh! copy isn't copying the no-grafts version
<singpolyma>even when I pass it --no-grafts
<singpolyma>Why would the two boxes have different grafts? Just based on timing of when I ran guix pull?
<singpolyma>guix archive --export -r --no-grafts and then guix --import on the remote worked
<singpolyma>so either a bug in copy or I'm doing it wrong
<kozo[m]>Perhaps submit a bug that guix copy isn't honouring --no-grafts?
<PotentialUser-26>robin, thanks! using that worked
<kozo[m]>PotentialUser-26 What did the working code look like in the end?
<PotentialUser-26>I copied the code from the paste link into install.scm, set it as kernel, and now install image has the module
<kozo[m]>Awesome, thank you
<ryuslash>Hello Guix :)
<kozo[m]>Yo
<ryuslash>I'm sorry if this is a dumb question or unclear, but do messages from graphical applications in Guix go anywhere by default?
<ryuslash>I used to be able to easily see them in my ~/.xsession-errors on Arch, but that file doesn't get written to now.
<ryuslash>I haven't seen any mention in the Info manual or mailing list.
<podiki[m]>I'm not sure, you can check /var/log/messages and (if you're using gdm) there's a log for that too
<podiki[m]>(guix logging could be improved)
<ryuslash>thanks :) looking, I am using GDM
<podiki[m]>/var/log/gdm
<ryuslash>I looked there, it just has greeter.log, which doesn't _seem_ to have any logs from my session. But I'm also having trouble with less because for a little while now fish (I guess) can't read the kitty terminfo database? So less is kinda broken.
<nan0scho1ar>Hi, is there a dedicated help channel or can I ask my guix questions here?
<jackhill>nan0scho1ar: this is the place to ask for help! Also, hi :)
<jackhill>of course, it's always hit or miss if the people here actually know the answer to your question, but we can try
<nan0scho1ar>Thanks :) , I'm trying to install Guix on my system. I have created the bootable USB and it seems to boot. Both the graphical and manual install are done in a tty but I'm having trouble even getting the tty to start. It just puts me straight into guile.
<nan0scho1ar>I'm trying to install it on a thinkpad x220 if that is relevant
<jackhill>nan0scho1ar: yeah, that's not what's supposed to happen. I've never seen that happen with the installer, just with my installed guix if I've made some mistake in the configuration. Are you able to see hint of any error messages before the scroll off the screen?
<jackhill>Admitedly, it's been a while since I've actually used the installer, but your hardware should be ok. I've used it on newer and older thinkpads in the past
<nan0scho1ar>I'll try rebooting and take a look. Guix system installer 1.30 btw
<nan0scho1ar>It says failed to resolve partition. It's a completely unformatted drive fresh out of the box so I'm not sure what partition it's even looking for.
<nan0scho1ar>Did I skip a step where I need to format the drive and create partitions before booting off the USB?
<jackhill>nan0scho1ar: yeah, that makes sense to me as one of the errors that could casue that. It can't find the files in needs to continue to boot up. How it got that way I don't no.
<jackhill>nan0scho1ar: no you should just need to use dd to write the image you downloaded to the drive. How did you create the drive?
<nan0scho1ar>It can't find the files on the drive? I can try creating it again
<jackhill>I've run into problems before where I forgot to call `sync` after the `dd`, so the drive was incomplete. Not sure if that's your problem though
<nan0scho1ar>I was using my friends windows computer to create the drive because my laptop is currently out of action
<nan0scho1ar>But this is a definitely a point in the right direction. cheers :)
<jackhill>nan0scho1ar: ah. It's been much, much longer since I've done it that way, and I'm not sure if we provide direction, but other distros (e.g. Debian's) should work fine.
<jackhill>nan0scho1ar: cool. I think it's time for me to go to sleep (east coast USA :)), but good luck, and if you run out of help from irc there is the help-guix@gnu.org mailing list (I think the first posts are moderated by a human, so if it takes a long time to show up don't worry).
<jackhill>goodbye and good luck
<nan0scho1ar>Cheers :)
<podiki[m]>ryuslash: I too run into sudo not liking less with zsh/kitty. been meaning to look into that. also, not sure where else to look for logs, but if you find out do tell
<ryuslash>podiki[m]: ooooooh! that makes sense that it's only when I use sudo. Since I only have kitty installed in my profile and not globally I'm sure that when I run root it doesn't have any terminfo to load for it.
<ryuslash>And indeed if I use `sudo --preserve-env=TERMINFO less /var/log/gdm/greeter.log' I get no complaints :)
<ryuslash>I guess I need to install kitty globally too
<ryuslash>Thanks for the help! It's time for bed for me now.
<ryuslash>Good night Guix!
<nan0scho1ar>Hi. I finished the guix install on my laptop and it said it was successful but it doesn't boot. Inspecting the contents of the drive with another live usb shows that the files are there, including the grubcfg, but grub never starts. Any ideas how I can get my system to boot?
<blackbeard>nan0scho1ar: did you use the Guix live USB?
<nan0scho1ar>Yep I used the x64 1.30 iso
<blackbeard>I mean to boot the second time haha
<nan0scho1ar>Oh no it said to remove it
<blackbeard>You can boot with it again
<blackbeard>You don't have to do everything from scratch
<blackbeard>You can chroot
<blackbeard>And reconfigure guix
<nan0scho1ar>So just follow the manual install steps to fix grub?
<blackbeard>Do you have your config.scm?
<nan0scho1ar>Yeah the tui installer should have generated it right?
<blackbeard>Did you use the visual installer?
<blackbeard>Mmm
<blackbeard>Yes
<blackbeard>We need to check that
<blackbeard>Ok first boot with the guix USB
<blackbeard>Did you encrypt anything?
<nan0scho1ar>Yep encryption on root and home partition
<nan0scho1ar>I'm on a root shell on tty3
<blackbeard>Ok
<blackbeard>Let's see
<blackbeard>Check /etc/config.scm
<blackbeard>If it is there
<blackbeard>Run this
<blackbeard>sudo guix system reconfigure /etc/config.scm
<nan0scho1ar>do I need to mount/chroot my drive first I'm pretty sure it's currntly just on the live usb environment
<blackbeard>No but wait
<blackbeard>You are on the USB
<blackbeard>Yes you need to chroot
<blackbeard>First you need to decrypt disks
<blackbeard>Run $ lsblk
<blackbeard>And then
<blackbeard>cryptsetup open --type luks /dev/sda2 my-partition
<blackbeard>Making sure it is your actual disk
<blackbeard>May not be sda2
<nan0scho1ar>ok
<blackbeard>Then you will need to Mount
<blackbeard>The partitions
<blackbeard>mount LABEL=my-root /mnt
<blackbeard>Something like that
<blackbeard>You can follow here
<blackbeard> https://guix.gnu.org/manual/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html
<blackbeard>But don't run all the commands
<nan0scho1ar>I can probably ignore the home partition right?
<blackbeard>Because you only need to decrypt and mount
<nan0scho1ar>sda1 is boot sda2 is root
<blackbeard>Yeah possibly
<blackbeard>Then instead of a chroot
<blackbeard>herd start cow-store /mnt
<blackbeard>Follow here
<nan0scho1ar>How can I figure out the root partition label?
<blackbeard> https://guix.gnu.org/manual/en/html_node/Proceeding-with-the-Installation.html
<blackbeard>One you are mounted
<blackbeard>You should have a /mnt/etc/config.scm
<blackbeard>Check it to make sure grub is there
<blackbeard>nan0scho1ar: sudo lsblk -o name,mountpoint,label,size,uuid
<nan0scho1ar>ty
<nan0scho1ar>The label is blank :/
<civodul>Hello Guix!
<nan0scho1ar>nvn I just mount decrypted using UUID
<nan0scho1ar>guix system init fails because 'device /dev/mapper/cryptroot' and '/dev/mapper/crypthome' not found
<nan0scho1ar>Grub config and uuid's of device mappings in config.scm look fine
<nan0scho1ar>Seems like it's failing to mount the filesystem, not sure if that has any impact on grub not starting on boot though
<vivien>Hello guix! I have a patch here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50425, it seems OK but I don’t have any news. Am I expected to do something? Wait for more reviews?
<blackbeard>nan0scho1ar: did you do
<blackbeard>herd start cow-store /mnt
<blackbeard>nan0scho1ar: are you dual booting?
<nan0scho1ar>yeah I did, also it's a fresh drive and the only drive in the laptop. I'm just gonna go through the graphical install again and use only one partition and no encryption to see if I have any more luck. Once I have a bit more experience with Guix in particular I will come back to try encryption again.
<abrenon>hi guix !
<civodul>vivien: hi! thanks for the heads-up! i guess we're just lagging behind
<civodul>if maximed says it's OK, i'll go ahead and apply it later today
<blackbeard>nan0scho1ar: I guess you can also look at this
<blackbeard> https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html
<nan0scho1ar>(y)
<blackbeard>nan0scho1ar: compare your config.scm
<blackbeard>abrenon: hi!
<abrenon>I've got packages to submit, but a huge task to finish before that
<abrenon>I'll send a patch eventually : )
<muradm>civodul, i want to submit patch switching wayland-protocols dependency as (native-input for all packages, wayland-protocols is build time dependency, but some used it as in inputs, some are even in propagated-inputs, which seems to be not correct
<PurpleSym>podiki[m]: I ran `guix refresh -u -t stackage` and it updated a ton of packages, but now I’m running into issues with haskell-build-system it seems.
<muradm>currently is getting built for me locally
<muradm>i suppose this will improve dependency hierarchy and make life a bit easier in the future :)
<yoctocell>PurpleSym: what exactly is the issue?
<PurpleSym>yoctocell: The copy-file in haskell-build-system.scm at line 238 fails, because the expected config files are not there.
<PurpleSym>The temporary package.conf.d indeed only has a package.cache{,.lock}.
<yoctocell>does this happen for all the Haskell packages, or just one or two?
<PurpleSym>yoctocell: Just some.
<PurpleSym>Some I can fix by adding a missing dependency, but murmur-hash for example fails looking for bytestring.
<yoctocell>hmm, isn't bytestring one of those package that are part of the default GHC distribution?
<qzdlns[m]>morning guix!
<PurpleSym>yoctocell: Yep, it is.
<PurpleSym>So, I’m guessing make-ghc-package-database is broken then?
<yoctocell>The current ghc-murmur-hash package is already on the latest version, and it seems to build fine
<yoctocell>yeah, that sound plausible
<PurpleSym>Ah, I see the problem. setup-compiler is checking the compiler is named “ghc” :|
<yoctocell>but it uses `string-match' which matches a regexp, so "ghc-next" should be matched
<PurpleSym>Ah, true. Sorry, Scheme is not my first langugae.
<yoctocell>no worries :-)
<PurpleSym>Still, make-ghc-package-database depends on GHC’s package name to be just “ghc”. input-dirs is correct, but conf-dirs uses name-version as /lib/<ghcdir>, which is ghc-next-XXX and thus wrong.
<yoctocell>Ah, I see.
<PurpleSym>Why not just use GHC_PACKAGE_PATH here?
<yoctocell>What is GHC_PACKAGE_PATH set to in the build environment?
<PurpleSym>yoctocell: For this particular package to /gnu/store/5c206rjlbss065yhvx58d93q7mv97cf6-ghc-next-8.10.7/lib/ghc-8.10.7/package.conf.d
<PurpleSym>Yep, works.
<yoctocell>Great!
<yoctocell>It seems like GHC_PACKGE_PATH is set to the package.conf.d directory of all of the inputs
<PurpleSym>#:cabal-revision is going to give us lots of head-aches though. I wish we could update that automatically.
<abhiseck>Hi
<maximed>sneek: later tell lispmacs[work]: (define-syntax backquote (syntax-rules () ((_ exp) (let-syntax ((exp* (datum->syntax s exp))) exp*)))) (untested)
<sneek>Will do.
<maximed>sneek: later tell lispmacs[work]: (make-bytevector (backquote (* 100 100)))
<sneek>Okay.
<maximed>sneek: later tell lispmacs[work]: oops, forgot s is unbound: (define-syntax backquote (syntax-rules () ((_ exp) (let-syntax ((exp* (datum->syntax #'exp exp))) exp*)))) (untested)
<sneek>Will do.
<zimoun>hi!
<zimoun>civodul: I have seen that: <https://connect.ed-diamond.com/GNU-Linux-Magazine/glmfhs-113/deploiements-reproductibles-dans-le-temps-avec-gnu-guix>. Is it available somewhere for “free“? :-)
<bricewge>zimoun: I don't think so.
<bricewge>I remeber reading it a few month ago it wasn't that interesting
<bricewge>zimoun: I have access to the paper version of it, if you want some picture of it let me know
<zimoun>bricewge: oh cool! I will let you know privately if civodul cannot share.
<civodul>zimoun: since it's 6-month old, i think i'm allowed to share it right now
<civodul>i need to double-check
<PurpleSym>yoctocell: Do you know if there’s a way to match newlines in Guile regexp? There’s a line break here between id: and its value: https://paste.debian.net/1211965/
<makx>hi geeks. is there any documentation/preferred way to get hold of additional kernel modules? I would like the ch341 module to be available (and it should be there in the linux-libre sources, it doesn't seem to be built as a default for the arm64 generic kernel)
<roptat>I don't remember what generate-jar-indices is doing exactly? It's failing on trying to repack a directory instead of a jar file (?)
<mbakke>makx: can you send a bug report (or a kernel config patch)? might be an oversight :)
<makx>mbakke: I am a bit confused because this kernel does not have many modules (its linux-libre-arm64-generic); maybe I am doing it wrong (tm)?
<mbakke>roptat: is that the file that records runtime dependencies (since they are invisible to the reference scanner)?
<yoctocell>PurpleSym: (string-match "\n" STRING) should work
<PurpleSym>yoctocell: I was imprecise: The newline should be in id-rx, but it seems grep is reading the config file line by line :(
<mbakke>makx: I don't know why the arm64-generic kernel lacks many modules, perhaps lfam can answer
<mbakke>in any case I'm fairly certain that a patch to enable a specific driver will be accepted :)
<roptat>mbakke, maybe, although the generated INDEX.LIST doesn't seem to contain any references to store items
<roptat>in fact, my kotlin compiler doesn't work if not in an environment with its dependencies...
<yoctocell>PurpleSym: Sorry, what do you mean by "id-rx"? Are you doing something with the cabal importer?
<PurpleSym>yoctocell: No, it’s in haskell-build-system.
<yoctocell>PurpleSym: Ah, OK
<yoctocell>This might work (make-regexp "^id:[ \n\t]*(.*)$")
<muradm>is there a way output dependency tree of single package?
<mbakke>muradm: what do you mean by dependency tree? 'guix size PKG' will show runtime dependencies, 'guix graph' can visualize that and much more.
<muradm>mbakke, thanks, just trying to understand why one package depends on some irrelevant package on the first look ... :)
<yoctocell>PurpleSym: Any success with the regexp? ^^
<muradm>just was wandering why neomutt requires mesa :)
<maximed>muradm: guix graph --path mesa neomutt
<maximed>or guix graph --path neomutt mesa?
<PurpleSym>yoctocell: Nope, it does not work unfortunately, because it’s using a line-by-line grep. I’ll have to look into it tomorrow.
<PurpleSym>Got quite a few packages working today.
<yoctocell>PurpleSym: Ah, sorry I missed that.
<makx>mhmhm. mbakke it looks like if i install linux-libre it has all the modules, whereas linux-libre-arm64-generic looks fairly sparse when it comes to modules; maybe this is intentional
<yoctocell>PurpleSym: you could read the whole file as a string and then use (match:substring (string-match "^id:[ \n\t]*(.*)$" STRING) 1) on the string
<muradm>package arcan seems to be broken on core-updates-frozen...
<muradm>maximed: o, thats better, i didn't know that neomutt depends, on mesa initially, guix graph neomutt gave the whole picture, but your'
<muradm>s detailing it
<muradm>exersize or making wayland-protocols a native-input was good to understand things better :)
<yoctocell>sneek: later tell civodul: re <https://issues.guix.gnu.org/50359#17>, I can't get the "channel-news, one entry" to pass; it just returns #f.
<sneek>Got it.
<podiki[m]>PurpleSym: catching up here, you are using haskell-build-system from wip-haskell right? there were some changes that helped some packages build
<muradm>guix refresh -l wayland-protocols
<muradm>before: Building the following 1423 packages would ensure 2594 dependent packages are rebuilt
<muradm>after it became native dependency as it should be:
<muradm>Building the following 1596 packages would ensure 3380 dependent packages are rebuilt
<muradm>i don't know if it is good or bad..
<muradm>any thoughts?
<PurpleSym>podiki[m]: There was one commit, which I cherry-picked to my local branch, yes. But I’ve accumulated more changes that were necessary.
<PurpleSym>Or is there more on core-updates-frozen? I based it on master, because god knows when it will be merged…
<podiki[m]>PurpleSym: gotcha. was just remembering it was a patch for ghc_package_path, I think mostly helpful for the nontrivial setup.hs cases (and some tests)
<podiki[m]>there might be some on core-updates-frozen? I remember seeing a little on core-updates pre-freeze
<podiki[m]>or maybe it was just master. sorry, don't remember
<PurpleSym>I’ll check again tomorrow. Tried to build and fix a few packages today, but I’m not sure how we can work on this collaboratively. Ideas?
<abhiseck>Hello
<abhiseck>When I tried to evaluate a manifest file in guix, I got an error: unbound variable: specification->manifest. Then when I tried clicked on a link ice-9/boot-9.scm the error is: ice-9/boot-9.scm is not readable.
<abhiseck>Anyone know what is this error and how to fix this?
<podiki[m]>should be (specifications->manifest '("packagename" ...)) did you have the specificationS (last s)?
<podiki[m]>PurpleSym: not sure, maybe if you had your guix tree available somewhere? or a patch file(s)
<podiki[m]>or maybe on guix-devel or patches, if you think you are getting close and need some eyes to finish and polish
<abhiseck>Yeah, it was the output of 'package --export-manifest'. Note that I tried to evaluate in Geiser, also I installed guix few hourse ago so I don't knoe much about it
<abhiseck>Now that I passed the file to package -m it works.
<podiki[m]>ah, not sure what you were doing before, but usually you use manifests with things like guix package -m manifest.scm
<podiki[m]>so that gives guix package the list of packages you want to do stuff with (optionally you may want to use -p for profiles, there's examples in the cookbook)
<PurpleSym>podiki[m]: My tree is not in a usable state right now unfortunately. I think I’ll get the packages from Stackage (~300) in shape, then push to wip-haskell and then we can work on the leaf packages together?
<podiki[m]>PurpleSym: sounds good to me! then I'll see about whipping haskell-gi into shape (it is a lot of packages, but I think will be fine with newer stackage)
<podiki[m]>btw, what is the resolver you used on stackage?
<podiki[m]>lts-18.10?
<nckx>Good morning everyguix.
<muradm>suppose pkg-config version is getting updated, should all packages that use it as native-input be rebuilt?
<podiki[m]>o/
<muradm>\o
<nckx>\o/
<PurpleSym>podiki[m]: 18.9. Gah, new version again? :/
<podiki[m]>says 5 days ago :-p
<podiki[m]>but if 18.9 is for ghc 8.10.7, then probably not a big difference? i wouldn't sweat it (is there an easy way to see the resolver diffs?)
<podiki[m]> https://www.stackage.org/diff/lts-18.9/lts-18.10
<PurpleSym>Yeah, it’ll be fine: https://www.stackage.org/diff/lts-18.9/lts-18.10
<podiki[m]>jinx ;)
<rekado>why do we have this on core-updates: (define-deprecated/alias texlive-union texlive-updmap.cfg)
<civodul>rekado: this comes from 04a0b1e09abce99857e7930336421ca6d15ae630, maybe apteryx can shed some light
<sneek>civodul, you have 1 message!
<sneek>civodul, yoctocell says: re <https://issues.guix.gnu.org/50359#17>, I can't get the "channel-news, one entry" to pass; it just returns #f.
<civodul>yoctocell: oh, could you add some pk calls in there to see what's going on?
<brendyn>Adding #:use-modules (gnu packages lxqt) in gnu/packages/kde-frameworks.scm mysteriously results in all these unbound variable errors
<brendyn>seems to be some dependency loop maybe?
<yoctocell>civodul: thanks for the pointer! The second tests in the (and ...) form fails <https://paste.debian.net/1211992/>
<civodul>brendyn: sounds like it; could you report the details?
<yoctocell>I don't see why it fails; the entries should correspond to commit2 and commit4
<civodul>yoctocell: are you running tests in a Unicode-capable locale?
<civodul>yeah that's weird
<brendyn>I can. I'll try reproduce it using a simple change first.
<yoctocell>my locale is en_US.UTF-8
<civodul>ok
<yoctocell>does the test fail for you?
<civodul>no
<brendyn>interestingly I can still eval the buffer in geiser and build packages
<civodul>yoctocell: could you check if there's some .gitconfig or something interfering?
<brendyn>but not via the cli
<yoctocell>civodul: Hmm, I have applied the "tests: git: Don't read from the users global Git config file." patch, so any external git configs shouldn't intefere
<yoctocell>
<yoctocell>I will try running make check in a container and see how it goes
<yoctocell>hmm, running in a container doesn't help either
<muradm>package libmicrohttpd fails to build in core-updates-frozen, testcurl/https/test_tls_options fails
<muradm> https://paste.rs/MVq
<civodul>yoctocell: setting HOME was already supposed to avoid Git config interference BTW, but apparently it was insufficient
<yoctocell>civodul: the weird thing is that "4b94570fe4b3e2217bec4ff8a2a469a68c9e8b4c" doesn't even correspond to a commit
<yoctocell>oh, "4b94570fe4b3e2217bec4ff8a2a469a68c9e8b4c probably corresponds to the tag
<mbakke>rekado: are you working on merging the new TeX Live packages?
<roptat>I didn't notice I built asm4 with embedded jars, and that lead to some issues ^^'
<roptat>for some reason, one of the classes is parameterized, but in the resulting jar, that class is not parameterized anymore. Removing bundled jars and building manually solved the issue
<roptat>(could have been a weird interaction between bnd and jarjar...)
<attila_lendvai>robin, i have pushed my trezor patches to https://github.com/attila-lendvai/guix/tree/trezor , it seems to work fine for me
<attila_lendvai>i haven't sent it to the guix-patches list yet (maybe i'm secretly hoping that a more modern communication channel gets established while i'm testing... :)
<rekado>mbakke: no, I’m just fixing reproducibility bugs
<singpolyma>attila_lendvai: if you mean "a web UI" you could try the sourcehut web UI for sending patches. Though for a multipatch series you'll still need to send a cover letter email first to get assigned a bug number since guix-patches is not a mailing list
<lilyp>guix-patches is not a mailing list?
<attila_lendvai>singpolyma, do you mean https://sr.ht/ ? i can't find guix there.
<singpolyma>Don't need to, just push your clone of git to sr.ht then push the big blue send patches button and fill in the email address to send to
<singpolyma>Federation means don't need to have the project home be there in order to send patches :)
<singpolyma>lilyp: correct, guix-patches points at debbugs it's not a mailing list
<attila_lendvai>singpolyma, oh, i see! thanks for the pointer!
<singpolyma>So you have to send one email to get a bug number, then send the patch series to the bug-specific email address
<attila_lendvai>i have already sent my first ever guix patch, but as i can see there are some 30+ patches sent per day. quite a flow for a few people with the commit bit...
<singpolyma>Yeah, I sent my first set of patches a few days back but I expect it'll be awhile before I hear anything
<tayirvadai>Hi All "guix install stumpwm" does not add it to xsessions
<tayirvadai>is there a way to update it. /gnu/store is ro and only guix will have its own namespace
<tayirvadai>Can anyone help?
<lilyp>tayirvadai: stumpwm is one of the packages that needs to be installed system-wide to have the effect you want
<lilyp>alternatively, you can try spawning it from your xinitrc
<tayirvadai>ok thanks. will try to do system-wide for broader use. Appreciate the help
<mbakke>rekado: there are some differences between the new TeX Live packages on 'master', and those you added on 'core-updates' back in the day. Do you have an opinion on which to "preserve"?
<podiki[m]>did the big world rebuilding changes get pushed on core-updates-frozen yet? I see lots of failures in the past few days on cuirass, but I don't think those are it?
<roptat>I don't think so, we're still waiting for the rust bootstrap chain I think
<podiki[m]>ah rust
<podiki[m]>trying to see if I can jump to that branch, but need to look more with the recent build failures if any are needed on my machine
<voroskoi[m]>rust-cargo install wants to build 20+ versions of rust starting from 1.19, am I doing something wrong?
<voroskoi[m]>is that the package for cargo command?
<shcv>I think I messed something up or updated something; not sure it's guix's fault, but trying to use various CPython related things installed with pip now fails because they can't find libstdc++.so.6
<shcv>any ideas?
<shcv>pandas, numpy, scalene, etc.
<shcv>used to work...
<shcv>pandas installed via guix works, but scalene isn't in the repo so that's not an option
<roptat>voroskoi[m], yes that's normal if you don't use substitutes
<roptat>cargo is written in rust, and rust can only be built with rust
<roptat>so there's a chain of rust compilers we need in order to build the latest rust
<voroskoi[m]>I would, but aarch64 is broken most the time
<voroskoi[m]>But I see, thank you
<roptat>we have a patch pending for core-updates-frozen that reduces the bootstrap to starting at rust 1.29 and that optimizes the build time for most of the remaining ones, but it might take a bit more time to get into the branch, and master eventually
<roptat>how broken is aarch64?
<roptat>do you mean substitutes are missing, or that you can't even use existing substitutes?
<voroskoi[m]>Missing ones
<roptat>yeah not great :/
<voroskoi[m]>Sometimes just a download issue
<voroskoi[m]>But nobody seems to restart them
<voroskoi[m]>And the revdeps just do not start building at all
<voroskoi[m]>Because of missing dependency issues
<roptat>you mean on ci?
<voroskoi[m]>Yes
<roptat>I'm not entirely sure who has access to ci and can restart builds, but you can always try and send a message to guix-help if you need one to be restarted
<voroskoi[m]>Oh, i was not aware of that
<shcv>so is there not a libstdc++ package? how do I get that, or figure out why it's not being found?
<voroskoi[m]>I will, thanks
<roptat>yeah, don't stay alone with your problem, speak up, and I'm sure someone with access will be happy to help you
<roptat>shcv, I see one in (gnu packages gcc) but it's not exported
<roptat>but gcc should already know how to find it, I think
<roptat>I mean, gcc-toolchain
<lilyp>gcc should, but random pip package from the aether doesn't
<lilyp>(because those assume FHS libc probably)
<shcv>I'm just confused because it used to work, and I'm not sure what exactly changed
<roptat>oh, yeah, if it's a prebuilt binary, it's not supported by guix
<shcv>it wasn't prebuilt before, but maybe pip has started fetching prebuilts
<shcv>earlier when I installed it, it would build locally
<shcv>guess I should figure out how to force a build
<roptat>maybe we should make it a default
<roptat>if possible
<lilyp>good news, scalene seems to have only one unpackaged dependency
<lilyp>so adding it to guix should be pretty easy
<attila_lendvai>is there something like --keep-failed, but one that keeps the build dir even when the build succeeds?
<roptat>I don't think so
<roptat>usually, I add another phase that just do (throw 'fail)
<attila_lendvai>i'll do that, too, thanks!
<atuin>Hi, how can I can I add my custom sudo version to the list of setuid programs? Now I see it's installed in the system but the sudo inside setuid directory is the old one
<atuin>ahh, I guess i can override the setuid-programs field in the operative-system
<rekado>mbakke: uhm, I don’t know. Can you give me a pointer as to what packages those are? I haven’t looked at core-updates in a long time.
<atuin>mmmm I'm confused now, i get sudo `#<package sudo@1.9.7p1` in a REPL but sudo 1.9.8 when doing `guix package -s sudo`
<atuin>how is that possible? :D
<mbakke>rekado: texlive-psnfss, texlive-pdftex, and texlive-charter
<atuin>is it normal to have the package guix in the system profile? or am i doing something wrong?
<mbakke>rekado: I'm considering cherry-picking each of those commits to core-updates individually, solving in favor of 'master' as those seem generally higher quality. WDYT?
<mbakke>the hashes need updating due to TeX Live 2021, and I don't want to do that in the merge commit
<apteryx>atuin: it's normal; it's the default guix
<atuin>apteryx, I guess then that i should not use that path for the GUILE_LOAD_PATH or GUILE_LOAD_COMPILED_PATH
<rekado>mbakke: I’ll check.
<rekado>bah, I hadn’t noticed that I already did the same work on core-updates.
<rekado>texlive-pdftex on master is better than the one on core-updates.
<rekado>texlive-charter is also better on master
<rekado>texlive-psnfss is better on core-updates
<mbakke>rekado: thanks for checking
*mbakke commences