IRC channel logs


back to list of logs

<muradm>any way, i think that, one who will be updating guix default sway from current 1.5 to 1.6.1+ will solve it some how :)
<muradm>probably it is just missing dbus service configuration for system tray or alike, and basu just fixes it, dunno
<pineapples>muradm: I doubt that person will because it's generally assumed that elogind is used on the user's system. The best course of action for early Seatd adopters like ourselves would be to package Basu
<pineapples>If you're interested, I can send you my package definition for it
<muradm>pineapples: one of points to run seatd is to not depend on logind or its substitute in my opinion
<muradm>as system tray is a service, there should be provider for it
<muradm>which i think should not be logind or susbstitute, and won't be seatd
<muradm>some other package that is doing systray should register dbus service for system tray i think
<muradm>why logind should do that?
<muradm>coming for packaging, i was looking some alternatives to dbus in general
<muradm>on arch i was using dbus-broker, which is also dropin replacement for dbus
<pineapples>muradm: I see. I can't give much insight into the subject other than to say that Mako also has an optional dependency on Basu
<muradm>few days weeks back i fired an idea here for dbus-broker
<muradm>it is flexible enough to get rid of the dbus legacy xml configurations
<muradm>and make scheme declarative configurations
<muradm>so in free time i currently invest in dbus-broker for now to draw whole picture
<muradm>pineapples: software is a like a sex, one mistake and you have to support it whole life :D bugs and misdesigns are being carried over and over again :)
<muradm>but of course, i didn't look at system tray service for now, and i didn't use it all, so may be a will change my mind when i will come to it
<muradm>thanks for basu hint, i suppose it is just building basu and adding it as dependency to sway, right?
<muradm>please paste your package definition, i will put it in some corner for later look
<pineapples>muradm: Roughly speaking; adding it as a dependency to either Sway (or Maku) and removing `elogind' from its dependencies
<muradm>btw, why would you need system tray? :)
<muradm>specific application that can't run without system tray? just curious
<pineapples>muradm: <>
<muradm>simple enough :)
<pineapples>muradm: Hmm. I can live without the system tray; it's just that my Sway configuration is more or less the default one, which has the tray enabled, and I just got so used to it that when I noticed it was gone, I needed to figure out why :)
<lambdalove-sadvi>Is anyone aware of a package the likes of 'pm-utils', for both hibernation and suspention to memory?
<pineapples>labbdalove-sadvi: There is <>
<pineapples>lambdalove-sadvi ^
<podiki[m]>hi guix btrfs people, I'm confused over setting the right mounts in system configuration (first attempt didn't boot properly, saying something like unknown "/rootfs")
<podiki[m]>my drive has a partition for efi, and then btrfs with subvolumes (flat) for /, /gnu/store, /var/log, and /home
<podiki[m]>each in their filesystem declaration refers to the device by partition name (all "system" since only one non-efi partition) and then mount options with subvol=subvolname
<podiki[m]>the manual is confusing if I need to include something else or not...
<muradm>podiki[m]: would be easier to see 1) commands you initialized your disk partitions and subvolumes 2) your (operating-system ...) declaration
<podiki[m]>I did like the guide you used as reference: but not encrypted
<podiki[m]>getting my system configuration will be a little tricky, but when I get back to it I will copy it somehow
<podiki[m]>just wondering if I'm missing something obvious, like the mount point or subvol name, since the manual refers to needing more for grub
<lambdalove-sadvi>pineapples: implicitly referring to a package *in the official guix repo*, as neither the 'guix search' command nor the HTTP interface weren't helpful
<muradm>podiki[m]: may be this will help
<muradm>then i use it like (make-btrfs-volume-mount "system" "root" "/" mapped-devices)
<pineapples>lambdalove-sadvi: Ah. In this case, I'm not aware of any
<podiki[m]>muradm: thanks
<podiki[m]>I think mine ends up equivalent (minus the luks device mapping). I'll investigate after dinner
<podiki[m]>if anyone else also has any examples of their config with subvolume mounting and booting, please share :)
<podiki[m]>(everything built and installed fine, grub was there, but died early after, not mounting root correctly I think. hopefully easy to spot when I get back)
<muradm>podiki[m]: looking at new systems /etc/fstab may shed some light as well
<jackhill>podiki[m]: I'd be interested in that too. The last time I tried, I couldn't figure out how to get grup to load the kernel from a subvolume. My fstab and everything else looked correct. I'll have to take another look
<ryuslash>woops, sorry :)
<sneek>Welcome back vagrantc, you have 2 messages!
<sneek>vagrantc, efraim says: apt-cache rdepends guile-gnutls doesn't show anything other than debug symbols, should/could it be changed from guile-2.2 to 3.0 instead of trying to handle both?
<sneek>vagrantc, efraim says: I checked on riscv64, on amd64 it shows guix (of course)
<vagrantc>sneek: the guix packages in debian depend on guile-gnutls, which is guile-2.2 only at this point, so all the guile packages i maintain are support both guile-2.2 and guile-3.0 currently
<sneek>I'll keep that in mind.
<vagrantc>efraim: the guix packages in debian depend on guile-gnutls, which is guile-2.2 only at this point, so all the guile packages i maintain are support both guile-2.2 and guile-3.0 currently
<vagrantc>efraim: and the background on guile-gnutls in debian ...
<muradm>sneek, botsnack
<vagrantc>ludo has tossed around some workarounds and/or fixes ...
<bsturmfels>Question on submitting patches - I posted the following patchset recently I now have an additional package to remove. Do I do that in an extra patch eg. existing 1-18/18 and the new 1/1?
<podiki[m]>will be sort of live debugging here: grub has "search --label --set system" and then paths are /gnu-store for linux and initrd (/gnu/store for others in linux command)
<podiki[m]>then errors with "In procedure mount: Invalid argument"
<podiki[m]>backtrace: In unknown file: (mount "/dev/nvme.." "/root" "btrfs" 0 "subvol=root,[square?]")
<bsturmfels>(I'm just imagining things could get a bit confusing if later a small update was required to one of the existing patches)
<podiki[m]>...this looks right to me, "system" is the partition label, root is the subvol name, don't see any typos in the config
<podiki[m]>muradm: still around? not seeing any obvious errors in my config
<podiki[m]>my filesysem lines have as options "subvol=root,defaults,compress=lzo,ssd,noatime"; maybe doesn't like one of those? defaults?
<podiki[m]>ah, this time I see it specifically calls out "noatime" for btrfs, weird (I had removed "defaults" not sure if that was tripping it up now, but don't need it anyway)
<podiki[m]>weird also because from the installation medium you can certainly mount btrfs with noatime
<podiki[m]>looks like we have a bug with noatime perhaps, will investigate and file
<podiki[m]>sneek later tell jackhill got it working, was straightforward with all top level subvolumes at least, guix didn't like the 'noatime' option though
<sneek>Will do.
<podiki[m]>sneek botsnack
<lambdalove-sadvi>jsoo: hey! How is it going with building the haskell stack? I was wondering if you had all the *.scm package definition files available somewhere
<lambdalove-sadvi>jsoo: I mean, the ones you shared over here:
<lambdalove-sadvi>jsoo: oh, forget about it, found your github page finally! :D
<jsoo>Oh yeah! The patches are about ready
<jsoo>lambdalove-sadvi: give it a test, i would love some feedback
<jsoo>I haven't built stack in a while, but they did successfully build and I could use stack (at least the bare minimum)
<bavier[m]>oh cool, our mintest package got new native-search-paths.
<lambdalove-sadvi>jsoo: I'm not quite sure how to diff and where to patch your haskell-*.scm files against... I'd much appreciate advices
<jsoo>lambdalove-sadvi: they are patches on the guix repository on savannah. As of a week ago they rebased cleanly
<podiki[m]>speaking of haskell, gotta get back to the ghc and ecosystem update on wip-haskell
<podiki[m]>oh, it is flags in a filesystem def for atime (why the separation with options?)
<apteryx_>I have a weird variable resolution problem when used in a search path
<apteryx_>this package definition: somehow causes a test failure in tests/cpan.scm
<apteryx_>"Unbound variable: ~S" (python)
<apteryx_>it builds, it runs, it can be 'guix show'd, searched, etc... but somehow this test fails with:
*apteryx_ is puzzled
<apteryx_>that package is in (gnu packages admin)
<xd1le>hi guix
<bricewge>Hey Guix!
<muradm>podiki[m]: true for noatime, also you mentioned lzo, keep in mind that it is another level of complexity and overhead..
***john__ is now known as gaqwas
<bricewge>sneek: later tell clone: By any luck, do you still have the code from which you submitted #46907? It's inapplicable with git “error: corrupt patch at line 15”. Would you mind re-sending the patch?
<sneek>Will do.
<moshy>Greetings. I've successfully built a package that was struggling on another machine due to lack of memory. Is there any way I can help make it available to others?
<bricewge>Hello moshy. By "others" you mean your other machines or other Guix users?
<gagbo>Hello, is there a way to enable the maximum debugging/backtrace information from a CLI `guix` call ? I'm toying with `guix home` and it look like deep into generation I run into a `(stat #f #f)`, and it's hard to see a meaningful backtrace
<bricewge>If your backtrace is truncated you can set the COLUMNS environment variable (ex `COLUMNS=999`)
<bricewge>But if there isn't a backtrace you would need to run a similar command in `guix repl` but it's not straight forward at all since you would need to unpeel the CLI interface code
<gagbo>I have a backtrace, so the COLUMNS trick will help a lot already, thanks. I was wondering if there were env vars to control so I suppose there are other easter eggs to find (since `width` seems to get translated to `COLUMNS`)
<moshy_>bricewge: Like to make it available from my machine to other users, while it's not yet built on the main substitute servers
<fnstudio>hi, i'm trying to install qtwebengine-5.15.2 and i notice that, instead of fetching substitutes (which i have enabled), it tries and builds things locally
<moshy_>It's likely not yet built or it might have failed
<fnstudio>is this because the package build is apparently failing here ?
<fnstudio>moshy_: ah excellent
<fnstudio>got it
<moshy_>seems odd though, the substitute was available for me
<fnstudio>unfortunately local build is not an option because it takes too long on my low-spec machine, is there a way to fetch an older substitute from the server?
<fnstudio>moshy_: hm, weird, let me try again now
<fnstudio>thanks for checking by the way
<moshy_>the grafts might take a while from what im seeing
<fnstudio>moshy_: hm i see, are the grafts always built locally?
<moshy_>don't think there's any building involved locally, but im not sure about the exact details of how they work
<fnstudio>moshy_: if i launch "guix install qtwebengine --dry-run" it does say that the derivation would be built - although not sure that's what i should check
<fnstudio>moshy_: i see
<moshy_>gonna try a pull on my end
<moshy_>is this x86-64 or different arch?
<moshy_>current git commit says qtwebengine been changed for me
<bricewge>moshy_: Unfortunately it's not possible, you could run `guix publish` but then people would have to know you are serving substitutes, trust you for any substitutes you serve and configure their machine to use your substitute server.
<bricewge>Hopefully in the future we would be able to serve substitutes through a P2P protocol, such as IPFS.
<bricewge>Maybe a Guix's sysadmin could copy your substitute unto berlin or bordeaux, but that's really not common...
<bricewge>What is the package you managed to build BTW?
<bricewge>fnstudio: If you want to fetch an old substitute you could use `guix time-machine` to install that package.
<fnstudio>bricewge: oh thanks, i'll experiment with time-machine then
<fnstudio>we were talking about qtwebengine, whose build seems to be marked as fail on iiuc
***xgqtd is now known as xgqt
<bricewge>It is available on bordeaux tho
<fnstudio>bricewge: hm interesting, i'm being told
<fnstudio>after a fresh pull
<fnstudio>my guix describe points at what i think is the correct hash, 75a3413
<bricewge>fnstudio: It work for me
<bricewge>We are on the same commit but I used `--no-grafts` to get the derivation
<bricewge>And the substitute is indeed available on bordeaux
<roptat>fnstudio, did you allow bordeaux? is it one of the default substitute servers? it's not automatic on a foreign distro
<roptat>and only on guix system after a reconfigure
<fnstudio>bricewge roptat: thanks for checking that for me, let me double-check with regard to bordeaux
<fnstudio>you're very much right! i don't seem to have bordeaux on board (sorry couldn't resist the half pun)
<fnstudio>let me see if i can fix that
<fnstudio>ah! it works! thanks roptat and bricewge; it's solved my current problem with qtwebengine (and given me better understanding of substitute servers etc)
<moshy_>bricewge: not to worry in any case. i resolved telegram-desktop not building my adding more swap space on the other machine, probs something that might be dealt with on the substitute server
<moshy_>basically need 16GB+ for less excessive swapping during the build
<mothacehe>hey guix!
<bricewge>moshy_: `telegram-desktop` is available on bordeaux substitute server
***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<moshy>bricewge: looks to be sorted thanks. I'll give the local substitute thing a go, that looks quite handy
<muradm>hi guix
<muradm>apteryx_: yo.. :)
<muradm>does it looks like silent these days, lfam is missing few days or we don't catch up TZ
<apteryx_>I think many people are still on holidays
<apteryx_>but yeah, it's been quiet in the last weeks!
<apteryx_>arg; I updated python-pytest-6 to latest, and it didn't break anything except python-pytest-django, and it seems to be a mess to try to make it work
<iskarian>Leaving a note here about several packages failing on core-updates-frozen: GCC 10 rejects multiple definitions of global variables, leading to "multiple definition of ..." errors
<iskarian>thanks for the reference
<iskarian>looks like we're just going to have to carry patches until upstream updates in many cases
<iskarian>the most common offender seems to be "enum", which needs to be changed to "typedef enum"
<slyfox>some other distributions like suse or gentoo generated a bunch of patches in their trees
<slyfox>no, most if the time it's manual
<slyfox>if you want automated workaround you can always pass -fno-common via CFLAGS
<slyfox>Sorry. Need to amend it: if you want automated workaround you can always pass -fcommon via CFLAGS
<iskarian>Yeah, but I doubt we want to bake that into our GCC, and if we're patching packages anyway, we might as well make the proper patch
<vats>Hello, in Nix package definitions there is a way to pass options to curl in fetchurl method using curlOpts. Is there a way to do this in Guile? I want to download an archive from the given URL using curl with custom options.
<iskarian>vats, it would help to know what you're trying to achieve (that is, why are the custom options necessary?)
<vats>iskarian: I need to specify the byte range of the archive to be downloaded. The archvie is more than 1GB and I just need a certain portion of it.
<vats>This is done in curl using --range option.
<iskarian>That's... interesting. They don't make only the relevant parts of it available separately? It seems odd for the source to be more than 1GB, even GCC is only ~700MB
<iskarian>(To answer your question: as far as I know, there is no such thing in Guix's url-fetch)
<vats>Does url-fetch use curl under the hood?
<iskarian>Not at all
<vats>Thanks. Maybe I'll look into how to define a method for myself that uses curl.
<iskarian>vats, you could also probably use the Guile primitives:
<vats>Thank you
<iskarian>hmm, would there be any way to search the cuirass logs without downloading them first?
<jgart>What do guixers think of having some warnings for when things are not set up that are mentioned in
<jgart>For example, should guix warn you to install nss-certs package instead of giving you an arcane msg when what you need is to just install nss-certs?
<jgart>Stuff like that