IRC channel logs

2021-03-26.log

back to list of logs

<raghavgururajan>lle-bout, ^
<lfam>!!!
<lfam>Wow, cool chart
<raghavgururajan>We first have to update core-deps before core.
<raghavgururajan>:)
<raghavgururajan>jonsger: Could be useful for you too . ;)
<lle-bout>raghavgururajan: I rebased successfully
<lle-bout>yay wow!
*lle-bout looks at chart
<raghavgururajan>Yay!
<lle-bout>raghavgururajan: https://git.sr.ht/~lle-bout/guix/log/rag-core-updates-1 - I pushed here, double check and send another patchset please?
<lle-bout>On my end, I test
<raghavgururajan>lle-bout: Thanks! Will do.
<lle-bout>raghavgururajan: you can probably make that your branch now
<lle-bout>raghavgururajan: the main issues on the rebasing were about security fixes on cairo, gdk-pixbuf and glib
<lle-bout>I modified the cosmetic commits to remove the graft and patches etc.
<lle-bout>but I signed off all the commits, probably shouldnt have
<lle-bout>I will try to unsign off them
<lfam>lle-bout: I think we are ready to try updating the Guix package again
<lle-bout>raghavgururajan: force pushed to unsignoff
<lle-bout>lfam: awesome! thanks!
<lle-bout>lfam: was a commit pushed for it?
<lle-bout>Can't see
<lle-bout>lfam: 96aa98b6ca78ffb798e309acac3c3e5068422f30 hmm okayy!
<lfam>Pending final tests, I'm going to update tzdata and related Python packages on master tonight
<lfam>As far as I can tell, we've built substitutes for affected packages for x86_64 and i686
<rndd>л
<lle-bout>raghavgururajan: I ran: "./pre-inst-env guix build glib -e '(@@ (gnu packages glib) glib-with-documentation)' libsigc++ glibmm gtk-doc gobject-introspection cairo cairomm pango pangomm gdk-pixbuf gdk-pixbuf+svg vala libgsf atk atkmm" waiting now
<lle-bout>raghavgururajan: what do you plan for gtk4?
<lle-bout>raghavgururajan: I made something like this: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome-40&id=a66e41444f4b01a9e32e637312316a793741c8bf
<nckx>lfam: You will know when that happens.
<lfam>Alright. Maybe I should reply to myself on oss-sec to shame them
<lfam>Or not :) That's probably the better approach
<lispmacs[work]>hi, i build a qcow2 hurd image using cookbook instructions, but I have forgotten how to boot into the image with qemu
<lispmacs[work]>was -hda the option I was looking for...?
<lispmacs[work]>found the blog post again
<lispmacs[work]>there we go
<lfam>Should the cookbook recipe include that instruction?
<lispmacs[work]>lfam: that would be helpful
<lispmacs[work]>lfam: the cookbook doesn't really show an example of how to build gnu/hurd image
<lfam>Oh, I've never read that part
<lispmacs[work]>it would be helpful for noobs to have an example showing how to build and how to load up the gnu/hurd qcow2 image
<lfam>What section did you follow?
<lispmacs[work]>lfam: I adapted build instructions from cookbook section 3.2, and then looked to this blog post for help on how to run it: https://guix.gnu.org/en/blog/2020/a-hello-world-virtual-machine-running-the-hurd/
<lfam>I see
<lfam>Well, help wanted :)
<lfam>Do you feel up to sending an improved text, or even a patch, to <guix-patches@gnu.org>?
<raghavgururajan>lle-bout: glib-with-doc will not build. It needs a gtk-doc version, which is not released yet. I have hidden that package.
<lle-bout>raghavgururajan: okay!
<raghavgururajan>lle-bout: What;s the branch name?
<raghavgururajan>git checkout rag-core-updates-1
<raghavgururajan>fatal: not a git repository (or any parent up to mount point /)
<raghavgururajan>Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
<raghavgururajan>oh wait
<raghavgururajan>never mind!
<lle-bout>:-P
<phossil>are u peeps ok with screenshots uploaded to discord
<phossil>i was told guix supports f2fs but i get an error using the latest image from about half an hour ago
<raghavgururajan>lle-bout: Do you know how to `git am` multiple files? I have 0001-foo to 0056-foo in a local folder.
<lle-bout>raghavgururajan: git am *
<lle-bout>using shell expension
<lle-bout>expansion (?)
<raghavgururajan>So it applies all files in that folder, in alphebetical order?
<lle-bout>phossil: what error? I believe any direct link to images are OK
<raghavgururajan>`git am ~/new-patches/*` ??
<lle-bout>raghavgururajan: don't know, try
<raghavgururajan>Cool!
<lle-bout>I usually never do that
<lle-bout>Otherwise you can always probably create a find line for it
<raghavgururajan>Holy shit it worked
<raghavgururajan>Thanks!!!
<lle-bout>cool!
<lle-bout>phossil: if I may suggest some image host if you are interested: https://pic.infini.fr/
<phossil>o oki
<phossil>i get errors when attempting to upload my last screenshot
<phossil>`Something bad happened`
<lle-bout>phossil: somehow the website just went down not sure what happened here
<lle-bout>but it's back
<lle-bout>now
<lle-bout>hmm
<lle-bout>phossil: try this one instead https://wtf.roflcopter.fr/pics/
<lle-bout>but note: this was only of informative purpose if you were interested in image hosts, but you can probably send any other direct link to the image
<phossil> https://pic.infini.fr/0sFdKaqP/mI0vkC0F.png https://pic.infini.fr/sonxScMN/rZqZNaSC.png https://pic.infini.fr/2Jl9lUrp/Z306pCDC.png https://pic.infini.fr/l7A7jQOt/MlkUYTz1.png
<lle-bout>phossil: support for f2fs may not have been added to the installer, watch out for the 1.2.1 release which will happen in the coming weeks where we will actually test and fix any problem in the installer
<raghavgururajan>lle-bout: I have emailed the rebased patches. Thanks so much.
<lle-bout>you can otherwise install your system manually without the installer using shell mode
<phossil>lle-bout: ok, i'll try that
<lle-bout>raghavgururajan: the rusts are building at 1.38.0 now
<raghavgururajan>Oh boy!
<lle-bout>phossil: it seems we don't have f2fs-tools here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/installer.scm#n324
<lle-bout>phossil: I'll try fixing it, thanks for reporting
<phossil>np
<raghavgururajan>Is GnuTLS affected by the OpenSSL CVEs?
<lle-bout>raghavgururajan: GnuTLS is a totally different code base so no
<raghavgururajan>lle-bout: Cool!
*raghavgururajan wonders difference between OpenSSL and LibreSSL and GnuTLS.
<lle-bout>LibreSSL is an OpenSSL fork, but GnuTLS is another project entirely
<lle-bout>LibreSSL is made by OpenBSD developers to cleanup legacy and improve security of OpenSSL
<raghavgururajan>Their application use-cases are same right?
<lle-bout>GnuTLS was a GNU Project
<lle-bout>raghavgururajan: more or less yes, a crypto library
<lle-bout>GnuTLS has guile bindings so there's that
<raghavgururajan>Oh there is mbedTLS
<raghavgururajan>Looks like there are lot, https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
<raghavgururajan>lle-bout: I see.
<lle-bout>There's lots of TLS implementations yes
<raghavgururajan>I wish GnuTLS stayed with GNU.
<lle-bout>It is not a big deal, the license hasnt changed
<lle-bout>I think the developers have their reasons
<raghavgururajan>True, but for the GNU spirit <3.
<lle-bout>IIRC it was about a problem where the developers felt they could not develop GnuTLS while staying in GNU because of programming policies or tooling they could use
<raghavgururajan>*misses the
<raghavgururajan>Appears so, yeah.
<lle-bout>let's agree GNU infra is ancient
<lle-bout>Can't wait for GNU Mailman 3 and Hyperkitty
<lle-bout>(At least)
*raghavgururajan like GNU Mailman interface. Simple and no JS.
<lle-bout>I feel like even the tooling within GNU Emacs to work with debbugs and git could be so much better
<raghavgururajan>But can improve
*raghavgururajan cooks on bayfront
<lle-bout>raghavgururajan: This is Hyperkitty part of GNU Mailman 3 : https://lists.fedoraproject.org/archives/
<lle-bout>It's just so awesome to me
<lle-bout>Increases accessibility by a LOT
<raghavgururajan>hyperkitty is a part of mailman project?
<lle-bout>It's a dual model for those who like web browsers and those who like email, there's an option to login on Hyperkitty and post email from there.
<lle-bout>raghavgururajan: yes
<raghavgururajan>I see.
<lle-bout>raghavgururajan: https://gitlab.com/mailman/hyperkitty
<lfam>Looks awesome
<raghavgururajan>Django .. phew!
<raghavgururajan>Was afraid it was NodeJS or Coffee/TypeScript.
<lle-bout>raghavgururajan: Fedora likes Python it seems, Pagure, Hyperkitty, ..
<lle-bout>dnf
<raghavgururajan>I am okay with anything non-JS. haha
<lle-bout>There's still JS for the frontend but bare
<raghavgururajan>No mentioned of hyperkitty at https://www.list.org/
<raghavgururajan>3.3.4 was released
<raghavgururajan>GitLab froze my IceCat and stalled my system. *sigh*
<lle-bout>raghavgururajan: https://list.org/features.html
<lle-bout>raghavgururajan: "Completely revamped and improved web user interface (Postorius) and default archiver (HyperKitty)."
<raghavgururajan>Yeah, I was on that page, clicked NEWS file link for Mailman3, took me to gitlab and kaboom 💣️
<raghavgururajan>lle-bout: thanks!
<lle-bout>gitlab has been worse, it's working pretty well for me these days but I don't know about IceCat, it seems to have it's own kind of problems also..
<raghavgururajan>lle-bout: You are right! Mailman3 is awesome. https://lists.mailman3.org/mailman3/lists/
<lle-bout>I really want the GNU Project to adopt it
<lle-bout>I am wondering where do we go to do that
<lle-bout>The main problem is that it will require converting mail archives to a mailman 3 format
<raghavgururajan>GNU/FSF sysadmins
<lle-bout>I tried reaching out but didnt work
<raghavgururajan>May be in #savannah
<lle-bout>#fsfsys also?
<lle-bout>or something like it
<raghavgururajan>May be bandali can give us some pointers.
<lle-bout>raghavgururajan: so it's planned apparently
<raghavgururajan>I see.
<butlerian>hey folks, is there any sane way of modifying grub.cfg? I want to add a certain line, but haven't found a straightforward way to do so
<lle-bout>butlerian: see https://guix.gnu.org/manual/devel/en/guix.html#Bootloader-Configuration
<lle-bout>there's no other way on GNU Guix
<butlerian>Already seen. I read the code too, but what's available is not flexible enough
<butlerian>(unless I'm missing something)
<lle-bout>butlerian: what are you trying to do? please suggest improvements to bug-guix@gnu.org or at least document your uncovered use-case so people who know GNU Guile and GNU Guix internals will be able to study the issue (not me)
<butlerian>Trying to add "set gfxpayload=keep"
<butlerian>(or any other value)
<butlerian>Only way I found to get a proper console resolution
<butlerian>Surr
<butlerian>s/rr/re/
<boomerchad>So I was able to get a slightly older version of DeaDBeeF to successully compile and launch. The problem is it fails checks after building. It complains about files wich contain translations, which are not in use. Is there a way I can disable the checks or should upstream be patched?
<boomerchad>Versions starting with 1.8.5 add libdispatch as a dependency and will not compile with gcc so I figured I'd start below that.
<boomerchad>A paste of the relevant error is here http://paste.debian.net/1191033/
<boomerchad>A paste of my deadbeef.scm is here: http://paste.debian.net/1191034/
<phossil>isnt libdispatch an apple project ? their preferred compiler is clang
<boomerchad>Yes, from version 1.8.5 and upwards libdispatch is a dependency for the core and a couple of the plugins meaning clang is needed for those parts. I decided to focus on 1.8.4 for now because libdispatch hasn't been packaged in guix yet (or nix as far as I can tell).
<lle-bout>raghavgururajan: rust 1.44.1 now
<lle-bout>butlerian: sorry got caught in things
<bone-baboon>How can I install a previous version of a package using a system configuration?
<lle-bout>bone-baboon: inferiors
***iyzsong-- is now known as iyzsong-w
<bone-baboon>lle-bout: Thanks I will look at the Inferiors section of the manual.
<raghavgururajan>sneek, later ask nckx: Do you know how to fix my key thing on bayfront? Or would you be able to?
<sneek>Okay.
<genr8_>Im confused about something
<genr8_> https://guix.gnu.org/en/download/latest/ <-- the latest binary points to something that contains 50d7wxww71k8d1h5934k42ygvqk74p31-guix-1.2.0-17.ec7fb66
<genr8_>which makes sense, except inside package-management.scm , its referencing 16.c8887a5
<genr8_>which then leads to it always saying: The following package would be downgraded: guix 1.2.0-17.ec7fb66 → 1.2.0-16.c8887a5
***TheCreeper1 is now known as TheCreeper
<wehlutyk>o/ guix!
<wehlutyk>I would like to install guix as non-root, on a system on where user namespaces are activated. Do you have any pointers for doing that?
<marusich>Emacs just ate my bug report. I crafted a nice, detailed reply, and then it crashed. Sooo frustrating...
<marusich>Anyone know how to tell Gnus or Debbugs to autosave my articles???
<marusich>This is like the third time it's happened to me, but I can't figure out a good solution. Even pressing C-x C-s to "save" the draft doesn't work; I don't know why but Gnus does the opposite of saving a draft when I do that. It doesn't save a draft.
<marusich>And sadly, now I can't even open the bug report I was viewing in Debbugs becuase of some silly Emacs error...what did I do to you, Emacs?
***regtur_ is now known as regtur
***MidAutumnHotaru1 is now known as MidAutumnHotaru
<soouul>hello, i have a question, can i run the mesa vulkan 32 bit driver on guix? if so how? i cant figure it out
<soouul>on a 64 bit system that is
<rekado>marusich: that’s annoying :-/ Is there anything in the automatically created file backups? (Or do they only exist for edited existing files and not for arbitrary buffers?)
***apteryx is now known as Guest84016
***apteryx_ is now known as apteryx
<raghavgururajan>Hello Guix!
*raghavgururajan is enjoying the first spring rain of this year, in Toronto.
<raghavgururajan>Still cold, but no ice though.
<soouul>thats nice
<soouul>no rain here yet, hopefully soon though
<bdju>anyone else have issues with some qt programs opening links? in both quaternion and nheko I can't seem to just click a link to open it. all my xdg stuff is set fine. links in dino work, emacs can open links, xdg-open command opens links fine...
<masiku[m]>bdju: Did you try turning it off and on again?
<bdju>masiku[m]: definitely, have had this issue for months but only recently it hit me that it was two qt programs so I thought maybe I was on to something
<mothacehe>hey guix!
<sneek>mothacehe, you have 2 messages!
<sneek>mothacehe, nckx says: One of them has a dead hard drive, and the other one dropped off the edge of the Internet just when I'd almost finished reconfiguring it. These things are cursed, but it shouldn't take much work once I can get to it.
<sneek>mothacehe, civodul says: thanks for the Cuirass fix!
*masiku[m] farts
<mothacehe>sneek: later tell jonsger: you may want to update to the latest Cuirass version (1.0.0-3.f5a2eea), otherwise some evaluations may fail (https://lists.gnu.org/archive/html/bug-guix/2021-03/msg00582.html).
<sneek>Got it.
<civodul>Hello Guix!
<civodul>quiz time! can the output of a fixed-output derivation have references?
<cbaines>o/
<cbaines>I guess so...
<civodul>cbaines: we'll have to see what the jury says, but i think you're right
<civodul>it's weird but it's interesting
<masiku[m]>civodul: Jury? what are you talking about?
<civodul>masiku[m]: i was kidding, don't worry :-)
*masiku[m] farts again
<cbaines>either I've got my Guix Data Service query wrong, or it doesn't know of any nars for fixed output derivations that have references
<cbaines>the narinfo data isn't comprehensive yet though, so that doesn't suggest they don't exist
<civodul>it's a feature we don't use at all currently
<civodul>because it's weird: where would those references come from?
<civodul>it's possible to create such derivations, but it's a bit convoluted
<cbaines>I guess things from the internet could contain references, but that would be a bit odd. The builder inserting references in to outputs would also be odd though, at least in the guix packaging use case
<civodul>yes, and the references of the output must be a subset of the derivation inputs
<civodul>so you have to know in advance what the references will be
*mothacehe is downloading zstd substitutes at 20MiB/s, thanks civodul!
<mothacehe>uprading to the latest emacs is much more pleasant
<i1l>sneek: who is milkman?
<raghavgururajan>i1l: It's a XMPP bot.
<i1l>raghavgururajan: they are bot!?
<raghavgururajan>Yep!
<davidl>Whats needed to setup access to cuirass build logs that are in the path: /build/252/log/raw
<raghavgururajan>from disroot.org
<raghavgururajan>Not here now though.
<raghavgururajan>i1l: Btw, what was the thing you mentioned about gnome? Can you explain please?
<i1l>raghavgururajan: you not want to know.. gnomes watching.
<raghavgururajan>i1l: Hmm. How do you know?
<i1l>> davidl: Whats needed to setup access to cuirass build logs that are in the path: /build/252/log/raw
<i1l>setting up sort of a server?
<davidl>i1l: yes, like ci.guix.gnu.org
<davidl>I have cuirass setup with nginx and guix-publish, but the build logs don't show up for individual builds, only for evaluations.
<davidl>just a page that says resource not found
<mothacehe>davidl: ci.guix.gnu.org uses the build remote mechanism that doesn't handle logs in the same way as the default build mechanism I presume you are using
<mothacehe>looks like log support is broken using the default build mechanism
<mothacehe>let me see if I can patch it
<davidl>mothacehe: ok, thanks!
<mothacehe>btw, did you manage to get your specification working?
<davidl>mothacehe: yes, thank you for that!
<mothacehe>np :) can I close the ticket then?
<civodul>mothacehe: BTW, i had to add a /admin nginx location that would return 403 in my instance
<civodul>otherwise it's open bar
<mothacehe>davidl:is your Cuirass instance
<mothacehe>public§
<civodul>(and apart from build logs, it works like a charm!)
<mothacehe>civodul: hehe yeah I noticed it on your instance yesterday
<mothacehe>looks like https://guix.bordeaux.inria.fr/ is stuck though
<civodul>i wonder if there should be an option to turn off the admin interface, and/or a warning in the manual
<mothacehe>civodul: yeah I'll add a parameter to disable it by default maybe
<davidl>mothacehe: not public, no
<mothacehe>ok
<rhou[m]>when I install `ghc`, the installed version is 8.8.3, but when I install a package like `ghc-base-compat` it gets installed for `ghc` version 8.6.5, any ideas why?
<civodul>mothacehe: there were a couple of typos in my config, should be fixed now
<smartineng>rhou[m]: probably there are some issues with the newest version or no one has tested it yet
<rhou[m]><smartineng "rhou: probably there are some is"> and where does it gets decided with which version the package gets built?
<smartineng>rhou[m]: in the package declaration https://github.com/guix-mirror/guix/blob/master/gnu/packages/haskell-xyz.scm
<zimoun>hi!
<i1l>zimoun: first. hi.
<rhou[m]><smartineng "rhou: in the package declaration"> in the package description?
<zimoun>mothacehe: hey, does the bug with pointer and Cuirass is solve? Or worked around?
<tleydxdy_m>howdy, I'm getting ssl problems with git `Problem with the SSL CA cert (path? access rights?)` and guix pull
<tleydxdy_m>this is on a fresh 1.2.0 install
<zimoun>tleydxdy_m: does it look like <http://issues.guix.gnu.org/issue/46829>?
<tleydxdy_m>yes, but I couldn't find a solution there
<tleydxdy_m>I tried to pull from http
<davidl>mothacehe: yes, feel free to close the ticket!
<tleydxdy_m>but guix weird out
<tleydxdy_m>like it return me to the shell, printing "Killed" and continues to print stuff
<mothacehe>zimoun: hey, no it doesn't show up with guardians but this is not satisfying to me
<mothacehe>I'll have to keep investigating
<zimoun>tleydxdy_m, that’s why it is still an open bug. ;-) Does «guix pull --url=http://git.savannah.gnu.org/git/guix.git» not work for you in the meantime?
<tleydxdy_m>yes, that's what I tried
<zimoun>mothacehe: hum, ok.
<tleydxdy_m>very strange output
<rekado>‘Killed’ sounds like the kernel kills things when you run out of memory.
<rekado>how much free memory do you have?
<tleydxdy_m>ah, the machine only has 512
<rekado>also: can you share the output (use a paste site please)
<tleydxdy_m>512mb
<i1l>tleydxdy_m: did thou tried zram?
<tleydxdy_m>I do have 2 gb of swap
<zimoun>mothacehe: cuirass is updated from 0.0.1 to 1.0.0? Palindromic update? ;-)
***pocketroid_ is now known as pocketroid
<i1l>tleydxdy_m: imagining `guix repo` that makes an Arch repo, and a `pacman` as a part of distribution. Parabola can get a new upstream this way :)
<tleydxdy_m>what?
<abr>hello, Guix
<rekado>tleydxdy_m: you probably need more than 1GB of RAM. But it would still help to see the output (e.g. to see if you accidentally build everything from source).
<tleydxdy_m>I see
<tleydxdy_m>hmm, 512mb doesn't get very far these days it seems
<tleydxdy_m>I'm not trying to do much on the machine anyway
<rekado>yeah, it’s a pity.
<rekado>I really like low-mem machines, and it would be lovely if Guix were to run better on them.
<rekado>one option for low-mem machines is to use ‘guix deploy’ to push a built system to the target
*tleydxdy_m < https://matrix.org/_matrix/media/r0/download/matrix.org/JcdBArMQOLUWqCGUeCUZVgua/message.txt >
<tleydxdy_m>the output is pretty short
<tleydxdy_m>btw, the bar at the end keeps spinning
<tleydxdy_m>very fun
<mothacehe>zimoun: hehe indeed
<tleydxdy_m><rekado "one option for low-mem machines "> so the bookkeeping is not done on the machine?
*i1l guix deploy pacman, heh.
<cbaines>meh, www.sudo.ws is down, so I can't reconfigure bayfront :(
<cbaines>it's this output that can't be fetched https://data.guix-patches.cbaines.net/gnu/store/bna7d1nlmlkgnnjqf7sz9f1hybn2jypk-sudo-1.9.6p1.tar.gz
<cbaines>the green successful builds showing up is a little fustrating
<pkill9_>something neat to create with guix is the concept of a 'distributed-operating-system' as opposed to just 'operating-system', which would be used in `guix deploy` to deploy many operating systems that get configured to communicate with eachother, and have it's own types of services designed for working like this
<tleydxdy_m>you mean plan9?
<pkill9_>idk
<pkill9_>haven't used that
<raghavgururajan>cbaines: Oh are you gonna re-configure bayfront now?
<raghavgururajan>I have builds running there, without offloading.
<cbaines>I've already reconfigured it earlier, but I did a guix pull, and was trying again
<cbaines>without much luck, at least at first
<raghavgururajan>I see.
<raghavgururajan>cbaines: nckx mentioned that my pub key might not be configured correctly, as I get https://paste.debian.net/plain/1190878
*raghavgururajan checks %build-node-keys in bayfront.scm as suggested by civodul
<cbaines>The guix authorized-keys changed yesterday when I reconfigured, and I changed them again this morning
<cbaines>I believe they're consistent with the config in maintainence.git
<raghavgururajan>Ah Cool!
***pkill9_ is now known as pkill9
<mothacehe>anyone knows a way to force a browser to display the bzip2 compressed content of an HTTP reponse?
<mothacehe>it works fine with gzip by passing content-type=gzip
<mothacehe>but doing the same with bzip2, my browser tries to download the file instead of just displaying it
<cbaines>I'm not sure bzip is a generally supported content encoding
<mothacehe>my issue is that Guix build log files are bzip2 compressed by default, so it's not handy to display them with Cuirass
<mothacehe>passing --log-compression=gzip to the daemon fixes it
<cbaines>yeah, for Guix Build Coordinator deployments, I've been re-compressing the logs to gzip if necessary so that they're easier to serve
<mothacehe>oh i was thinking about that too
<mothacehe>another idea was to add log-compression to set-build-options
<BlackMug>Hi there
<mothacehe>davidl: civodul: cuirass-1.0.0-4.ff3f25d fixes the log issue with the default build mode. You may want to run the guix-daemon with --log-compression=gzip though.
<BlackMug>i have question about packages policy, is it mandatory to provide apparmor/selinux (whatever mac is) for the package? if not why?
<civodul>mothacehe: yay, thank you!
<civodul>"new" blog post! https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more-quickly/
<mothacehe>woowoh, nice title :)
<SanchayanMaity>Hello...Has anyone here already tried packaging neovim master or has neovim master in a private channel?
<civodul>heh, a bit more creating than the initial title ;-)
<civodul>*creative
<abr>SanchayanMaity: isn't the default package on master already ?
<raghavgururajan>Wait! 1.2.1 released?
<SanchayanMaity>abr: It's release version 0.4.4. Was thinking if 0.5.0 from git master is packaged. Or am I missing something from guix sources.
<BlackMug>civodul how are you, long time hope you are doing well
<civodul>fine, tx :-)
<abr>SanchayanMaity: oh my bad you're right
<abr>(answer to your question is «no» if that wasn't obvious ^^ do you have any trouble doing so ?)
<BlackMug>any problem have MAC by default on the packages? similar to android/ios packages(programs)
<pkill9>what's MAC?
<BlackMug>mandatory access control
<pkill9>i don't think it would be good by default, but as an opt-in thing it would be good
<pkill9>that's what I want
<pkill9>and would work well with guix as you can easily generate wrappers
<pkill9>there is also talk of runtime-wrappers for easily making wrappers too
<BlackMug>not by default/force some developers are bad or want to be bad to avoid both security issues is better to be mandatory
<pkill9>yes but not everyone wants it implemented the same way, or same permissions etc, also if it gets made it will be quite new and have bugs which owuld be unfair to force on to everyone
<BlackMug>there is nothing unfair about forcing the developer to do his development better for the users
<BlackMug>if he want to do in his bad way then let him do it on his website
<BlackMug>but not infecting everyone through the distro
<pkill9>i agree in principle, but in practise making it mandatory in guix would cause too many problems for people, atleast initially
<pkill9>practice*
<BlackMug>guix should work on this and leaving it if guix devs really care about security
<BlackMug>and not leaving it*
<BlackMug>look at debian , one of the famous distros but when it comes to packages security is all about trusting debian didnt damage it
<BlackMug>voidlinux is doing it right but its relying on the container through linux namespaces similarly to firejail/flathub
<BlackMug>flathub uses bubblewrap sandboxing
<pkill9>what's the benefits of MACs over linux namespaces/containers?
<BlackMug> https://www.whonix.org/wiki/Dev/Firejail
<dorian_greyscale>I'm trying to set up some user services but for some reason shepherd is not accessible on a user level. The herd command reports "error: connect: /run/user/1000/shepherd/socket: No such file or directory" any time I try to use it as a regular user, but it runs fine for root.
<BlackMug>though even if guix chooses to have namespaces its better than nothing and just leaving the package to be secure to the air flow
<rekado>pkill9: you don’t need to make it mandartory.
<rekado>pkill9: if we go with SELinux, for example, it’s a user choice to set it to enforcing or not.
<rekado>one problem is that files in Guix have unexpected locations, so policies are more difficult to write.
<pkill9>yea
<rekado>domain transitions are also tricky
<rekado>BlackMug: are you interested in working on this?
<BlackMug>fixing guix to work with MAC ? or what do you mean?
<rekado>some years back I worked on a primitive SELinux policy and outlined what next steps would be needed to get one for Guix System.
<rekado>‘fixing’?
<BlackMug>you said "one problem" and problem need fix/s no?
<rekado>no, I mean actually putting in the work to implement the missing mechanisms to generate policies when packages are installed and to merge the policies with the currently active polity
<rekado>‘fix’ implies that something is broken. A problem is merely an opportunity for decisions.
<BlackMug>i have spoken to civodul before that whonix want future better friend to base itself on and i showed him what whonix do
<BlackMug>but didnt find a response because maybe hes busy or so i dont know
<BlackMug>so not sure if how cool my contribution going to be, yet i love guix to success and do things better
<BlackMug>im just contributor to whonix btw not main dev or so
<BlackMug>anyway hope to see better security implementation for guix packages
<BlackMug>cya and god bless
<lle-bout>hello! :-D
<lle-bout>raghavgururajan: hey, gtkmm failed to build it seems
<lle-bout>raghavgururajan: error: https://paste.debian.net/plain/1191095
<roptat>mh... almost all the tests fail for spamassassin ^^'
<roptat>I must have missed something
<lle-bout>roptat: heh
<roptat>well, actually most of them are disabled, and most of the rest fails
<lle-bout>raghavgururajan: gtkmm@2.24.5 fails
<lle-bout>raghavgururajan: gtkmm-2
<lle-bout>raghavgururajan: it has quite a lot of dependents
<lle-bout>it seems it's just about freezing to release series the dependencies of gtkmm-2
<roptat>oh, it doesn't find its dependencies because the perl path is not set properly
<roptat>Can't locate NetAddr/IP.pm in @INC (you may need to install the NetAddr::IP module) (@INC contains: ../blib/lib @@INSTALLSITELIB@@ /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2 /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry
<roptat>-perl-5.30.2/lib/perl5/5.30.2) at ../blib/lib/Mail/SpamAssassin/NetSet.pm line 26.
<roptat>this @INC is not enough, it only lists local files and perl itself, but during the build, I think it was able to find its dependencies
<lle-bout>roptat: if you look at sendmail package there's some stuff about perl
<lle-bout>it wasnt sendmail
<lle-bout>it was ddclient
<lle-bout>by the way, the ddclient-service-type is completely broken
<lle-bout>also because sendmail is broken, but on it's own too
<lle-bout>it always says: "service could not be started", when it clearly did start
<roptat>doesn't seem related: spamassassin does have a Makefile.PL
<roptat>but it looks like it's overriding the PERL_PATH or whatever
<roptat>oh: Note that it is not possible to use the C<PERL5LIB> environment variable to affect where SpamAssassin finds its perl modules, due to limitations imposed by perl's "taint" security checks.
<roptat>ok, https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5282
<roptat>so I should patch spamassassin to add some "use lib" directives instead
<lle-bout>ugh :-s
<luis-felipe>Hi, Guix, for those who missed it, I've published new apparel and accessories: https://luis-felipe.gitlab.io/media/2021/03/guix-test-pilot-2021-M15-JA.gif
<sneek>luis-felipe, you have 1 message!
<sneek>luis-felipe, madage says: I've also been having issues with pulse audio since some days back.. eating ram, hanging and muting sound if I plug/unplug headphones. Not every single time I did tho and I also couldn't debug it until now..
<luis-felipe>Yellow design on dark colors: https://um4no.creator-spring.com/listing/guix-test-pilot-2021-m15-yja?product=227
<luis-felipe>Blackish design on light colors: https://um4no.creator-spring.com/listing/guix-test-pilot-2021-m15-bja?product=46
<luis-felipe>Or download the source files to create your own things:
<luis-felipe> https://luis-felipe.gitlab.io/downloads/graphics/GNU-Guix-Test-Pilot-2021-M15-2021-03-25.zip
<luis-felipe>I also submited the original SVG to guix-artwork.
<luis-felipe>sneek: Later tell madage: Right, plugin/unplugin works weird for me too, but not always.
<sneek>Got it.
<zzappie>luis-felipe: very cool design! Cant access links with listings though
<luis-felipe>zzappie: Thanks :) What browser are you using?
<lle-bout>luis-felipe: I saw it earlier, it's really awesome!
<zzappie>icecat and chromium. What it says at the botom?
<luis-felipe>Test Pilot, in Japanese.
<luis-felipe>It's pronounced something like this TESUTOPAIROTTO.
<luis-felipe>The (U) there is kind of voiceless
<luis-felipe>zzappie: I'm using icecat too, and it works for me, but some people have reported problems to view some pages too. I don't know what the issue is...
<zzappie>luis-felipe: ahm problem was with tor. Works can access now fine
<luis-felipe>Ah
<roptat>zzappie, if you wonder how it's pronounced: https://forvo.com/word/%E3%83%86%E3%82%B9%E3%83%88%E3%83%91%E3%82%A4%E3%83%AD%E3%83%83%E3%83%88/#ja
<abr>luis-felipe: oh you're the author ? congratulations, I think it's a great design
<luis-felipe>lle-bout: Glad you like it :)
<luis-felipe>abr: Thanks, it's been well received in the Fediverse.
<raghavgururajan>lle-bout: Updating gtkmm now.
<luis-felipe>I hope more people get courious about Guix when they see it.
<abr>I'm usually not a big fan of buying tech-inspired merchandising but I'm really tempted to get myself a nice tank top or hoody
<lle-bout>raghavgururajan: okay! thanks :-D
<lle-bout>raghavgururajan: I am thinking we need to package all supported release series precisely so we can use them in every place they need to be precisely
<lle-bout>Same thing with gtk4, I think we'll have to adapt all packages that use either gtk3, or gtk4, to specially depend on them
<lle-bout>also, I am wondering, wouldnt it be better to have specific names for every gtk version?
<lle-bout>like gtk+-2, gtk+-3, gtk+-4
<lle-bout>without a 'gtk+' package at all
<lle-bout>because I don't think it makes sense in the gtk+ world to ever depend on any gtk+ version
<luis-felipe>raghavgururajan, lle-bout: By the way, thank you very much for working on the GNOME upgrade. I'm looking forward to it :)
<lle-bout>luis-felipe: :-D
<lle-bout>luis-felipe: I want to add some artwork there: https://sr.ht/~lle-bout/awesome-guix/ - do you have any to suggest?
<raghavgururajan>lle-bout: Yeah. I created new (glib|cairo|pango)mm-foo variables in wip-desktop, which is already in master (and c-u) now.
<raghavgururajan>luis-felipe: :-)
<zzappie>roptat: thanks :) sounds familiar
<roptat>familiar?
<raghavgururajan>> ‎lle-bout‎: like gtk+-2, gtk+-3, gtk+-4
<raghavgururajan>The last one will be just gtk. The gtk+ is known as gtk starting v4.
<lle-bout>raghavgururajan: yes but this will break all packages that didnt port to gtk4 yet, no?
<lle-bout>or is it possible for an app to work with gtk4 without changes from gtk3
<roptat>zzappie, that's not me, it's supposed to be a native Japanese speaker :)
<raghavgururajan>It won't as they to refer to gtk+ variable which is v3
<lle-bout>raghavgururajan: okay so basically gtk+ is v3, and gtk+-4 is 4? so the bare one is actually one version earlier?
<raghavgururajan>lle-bout: gtk+-2 is gtk2 and gtk+ is v3. I plan to add gtk, which will be gtk4.
<raghavgururajan>lle-bout: Done! https://git.disroot.org/raghavgururajan/guix-core-updates/commits/branch/rg-core-updates
<lle-bout>raghavgururajan: so removing the +? is it not confusing?
<lle-bout>awesome thanks!
<civodul>hey luis-felipe, very nice apparel :-)
<raghavgururajan>At the beginning, yes. We'll get use to it. ;-)
<raghavgururajan>Happens. The GNOME project changed the official name from gtk+ back to gtk.
<lle-bout>luis-felipe: I think artwork is really important and we definitely need more around GNU Guix, I think it makes one more happy to be on a system that is to have some visual identity sticking to it, like in GNU Guix desktop environments for example
<lle-bout>raghavgururajan: fair enough
<raghavgururajan>I still remember how civodul responded, "Sounds like a revolution after all these years". xD
<raghavgururajan>s/responded/reacted
<lle-bout>raghavgururajan: what is libcloudproviders exactly?
<zzappie>roptat: Yeah I meant that it sounds englishy
<roptat>yes, it's based on the English, but pronounced with a Japanese accent :)
<raghavgururajan>A library for ☁️ technologies like WebDAV, CardDAV and CalDAV.
<roptat>there are many words like that, sometimes it's hard to tell though ^^
<lle-bout>raghavgururajan: cairomm@1.13.1 fails now
<lle-bout>raghavgururajan: by the way, as I test things, substitutes get available through my substitute server running on my laptop
<abr>zzappie: it's usually the case when you find these «angular» characters in japanese (called katakana) : they exist to represent non-japanese words like foreign language or sounds
<abr>(it's not just a different font compared to the quite round characters you see for japanese, it's a whole separate set of characters, not completely unlike our lowercase/uppercase sets)
<raghavgururajan>lle-bout: I just have to remove its propagated-inputs field so that it can inherit from cairomm@1.16
<abr>roptat: my favourite one is «EA-KON» (still can't type it properly, haven't managed to figure what was wrong with ibus yet)
<lle-bout>raghavgururajan: okay! thanks!
<roptat>abr, mine is "konsento", it sounds familiar and English, but it doesn't mean consent, it means "electric plug" (short for concentric plug)
<roptat>I also have issues with ibus :/
<abr>oh excellent one ! never heard it before, thank you !
<lle-bout>raghavgururajan: glibmm@2.64.2 also fails
<luis-felipe>lle-bout: About artwork links for the awesome list, I think I haven't seen more people doing Guix related art. And everything I do I tried to save it in the guix-artwork repo.
<luis-felipe>I do have https://gitlab.com/luis-felipe/guix-backgrounds, but it currently has all the backgrounds that I already contributed to Guix.
<luis-felipe>But I plan to add more personal artwork to my guix-backgrounds.
<luis-felipe>civodul: Thanks!
<luis-felipe>abr, roptat: What issues do you have with ibus? Apart from the slowness to activate the input method, I'm able to type Japanese.
<lle-bout>luis-felipe: what do you think of the idea of creating better GNU Guix out of the box configurations? When we upgrade GNOME for example, would you be interested in an out of the box configuration that works and provides all GNOME features smoothly as well as some light GNU Guix-specific art work and theming so that users of that configuration can feel right at home
<lle-bout>I think it is really important we make better out of the box configurations of GNU Guix, I don't think it's a great thing that the only way for users to use GNU GUix is to first study how a GNU/Linux desktop must be assembled.
<lle-bout>I don't want to deal with that alone
<lle-bout>That's why I used Fedora earlier, because they have fantastic out of the box configuration
<luis-felipe>lle-bout: Yes I am. Although I'm not up-to-date with GNOME theming.
<lle-bout>The Arch Linux approach of "grow your own system" I think only works for a certain group of computer enthusiasts, it doesnt work for other users
<lle-bout>luis-felipe: awesome!
<lle-bout>Well, I think the first thing would be simply a background, but we already have some I think
<lle-bout>Then maybe just some altering default colors maybe
<lle-bout>It's CSS I think
<abr>luis-felipe: dunno, I'm starting it from XFCE's session, exported GTK_IM_MODULE and friends from .bash_profile and nothing happens when I switch IM (the selection thingy shows up, but once I've stopped over anthy and the prompt goes back to my focused window, the IM is back to bépo, confirmed by the icon of the systray ibus icon)
<abr>I noticed there was already one ibus-daemon instance started from gnome-shell (?! not quite sure since I thought I wasn't using gnome, but I guess it comes from GDM)
<abr>which leads me to this remark : lle-bout I'm not sure about this «out of the box» perspective: it's practically what gave me the most trouble since I've started giving guix a try
<lle-bout>abr: in what way exactly
<abr>it looks way more «shiny» and «out of the box» that most things I've used up to now
<lle-bout>GNU Guix has big rough edges now, so integration bugs have to be solved
<lle-bout>w.r.t. to desktop environments specially
<lle-bout>many things don't work
<zzappie>abr: cool, didn't know that. I knew that there are two systems for characters in Japanese but didnt know that one of them is generaly used for non-japanese words
<abr>but it looks like there's no way to easily go under the hood check what's going wrong
<lle-bout>abr: well there's the Scheme barrier
<roptat>luis-felipe, I can type the combo key to change input methods, and it shows on screen I'm using anthy, but when I type I still use my other layout, no Japanese
***j is now known as jess
<lle-bout>abr: I understand what you are saying but also it's that GNU Guix is written in Scheme and has a whole new service manager, is a functional package manager, etc. Those are new concepts which can make it seem obscure at first but really when you figure that out everything becomes really accessible for hacking.
<balance>Hello! can anybody help with building bisq? (https://bisq.network/) cloned git repo, installed git-lfs, but have error while building "Could not initialize class org.codehaus.groovy.runtime.InvokerHelper"
<abr>I've never used NetworkManager: «1. oh, there's a nm-applet in my tray, cool ! I'll stop being geeky girl and give it a try 2. oh, it's auto-connected on my wired connection, how great ! 3. now let's configure the lab's VPN ! -> nothing works, don't have the rights to create a connection, nm-connection-editor crashes when I run it from sudo, the «gateway» setup I have to fill in the GUI doesn't
<abr>seem to exist in nmcli»
<abr>honestly I think the Scheme barrier isn't that high to jump
<lle-bout>abr: yes... sorry about networkmanager, it's broken in various ways now
<lle-bout>I think it's about Polkit, not sure
<luis-felipe>abr, roptat: For what it's worth, the instructions from Marusich in https://issues.guix.gnu.org/issue/35610 solved my problems.
<abr>at least it's a language way cleaner than nix's own
<abr>luis-felipe: oh, thank you !
<lle-bout>abr: great, well it was some barrier for me compared to shell script at least :-)
<lle-bout>I never used functional languages before, only multi-paradigm ones, like Rust
<roptat>luis-felipe, thanks, I'll try that!
<lle-bout>abr: with the GNOME upgrade, I hope we will solve this networkmanager mess
<lle-bout>But to be honest, this is due to complex interactions between networkmanager, polkit, etc. which are problems not related to GNU Guix itself. To be frank, if networkmanager ended up this buggy on any distribution it would still be obscure, there's something we don't do right around Polkit I think.
<lle-bout>We need to figure it out.
<lle-bout>I think NetworkManager in general is not easily troubleshooted for errors.
<abr>lle-bout: no need to apologiz, I was only documenting my experience of «oh ! it looks all clean and production-ready» but then disappoints in subtle and surprising ways (because if there's something as mainstream as gnome and nm, I expect most of the users to be using it, especially since it's a default when you give it a spin for the first time — so then I'm puzzled, how can this thing not work
<abr>and no one has noticed ? it must be me ? but can I have done, I've pretty much only configured to extra-packages in /etc/config.scm)
***ChanServ sets mode: +qq +q!*@* *!*@gateway/shell/matrix.org/x-joflirxaanoqmivs
*zzappie had a dream where he wrote a long tutorial called "little guixer" where he explores guix concepts in guile repl
<lle-bout>abr: I had the same feeling at first, I think people noticed but lots of people are overworked here, also I think many people don't use GNOME.
<abr>ok, thanks for the insight on polkit
<lle-bout>zzappie: :-D
<lle-bout>abr: maybe we should start by opening bugs, lots of these issues I have met them and never reported because I didnt know what they were caused by
<abr>yeah, and software probably wouldn't have become so buggy if their developers had been working on a functional system enforcing clean packaging
<abr>ok, I could do that
<lle-bout>There's some concepts we need to properly integrate within GNU Guix
<lle-bout>e.g. Polkit
<lle-bout>Everywhere, I mean
<lle-bout>Also, printers!
<abr>I wasn't feeling «settled» enough on my guix system to start considering giving such feedback but I could do it
<lle-bout>Printing is broken in various ways in GNU Guix in most cases
<civodul>zzappie: that'd be fun! i look forward to having it on my bookshelf next to "The Reasoned Schemer" :-)
<lle-bout>abr: let's cooperate on this I am very interested in providing better out of the box desktop integration! Especially with GNOME eco-systems.
<Noisytoot>What does "+q!*@*" mean?
<abr>(zzappie: about katakana / hiragana: this is the main story, but it's trickier though, they sometimes use katakana for no other apparent reason than emphasis, and some foreign words got in so early in the language that they forgot it was foreign and spell them using hiragana like «tabako» (tobacco), introduced by the portuguese missionaries in the XVIth cent.)
<Noisytoot>(or setting quiet on "+q!*@*")
<abr>lle-bout: with pleasure !
<lle-bout>civodul: do you know who did the Polkit stuff in GNU Guix that could explain how it works?
<lle-bout>also the cups printers things?
<Noisytoot>"+q" is an invalid nickname
<civodul>lle-bout: you mean the polkit service?
<lle-bout>I tried packaging gutenprint long time ago but it's still unfinished because there's something I don't understand in it
<abr>hmmm this means I should probably setup a permanent account here to be reachable and never offline
<lle-bout>civodul: yes probably?
<lle-bout>I am not 100% sure
<civodul>isn't it self-explanatory? :-)
<lle-bout>abr: :-D also email
<lle-bout>civodul: nope :-S
<civodul>lle-bout: i think this is where the system explorer would (ideally) help dive into the thing
<Noisytoot>abr: If you want to be always online, you'll need a bouncer
<abr>oh, that too ^^'
<lle-bout>civodul: what's the system explorer? o.o
<Noisytoot>Just creating an account isn't enough to be always online
<civodul>lle-bout: https://notabug.org/civodul/guix-explorer
<lle-bout>civodul: what!!!!! did I miss this!
<Noisytoot>lle-bout: It was presented at FOSDEM
<lle-bout>Ah wow! I wasnt here much at fosdem 2021 and was waiting for talks to be uploaded
<abr>Noisytoot: I was thinking of disconnecting this weechat that runs in a mere --ad-hoc environment and joining from my VPS's tmux instance
<lle-bout>abr: there's one alternative also it's using Matrix as a bouncer
<Noisytoot>That would also work
<Noisytoot>Matrix is sometimes slow and unreliable
<abr>civodul: that's great !
<lle-bout>civodul: thanks a lot I will investigate this guix-explorer thing
<Noisytoot>(or at least the IRC bridge)
<lle-bout>Noisytoot: maybe a little
<zzappie>civodul: Although it was an example of programming lucid dreaming. I might materialize it sooner or later. :)
<lle-bout>a bit overloaded, the bridge must be
<abr>hmmm I don't know anything about Matrix ^^' sorry, too much too new at once
<lle-bout>abr: okay no worries, weechat on vps can be fine, also email, are you subscribed to guix-devel and guix-patches?
<Noisytoot>abr: You can also use XMPP with a bridge
<lle-bout>civodul: nobody spoke of guix-explorer here or on mailing lists even once, that's surprising!
<abr>lle-bout: no, not subscribed yet, I'll do that
<Noisytoot>lle-bout: When Matrix crashed (which it often does after a netsplit), it doesn't connect everyone at once, and if I then send a message from Matrix, it doesn't get delivered to IRC
*lle-bout adds guix-explorer to the awesome-guix list
<lle-bout>abr: great!
<Noisytoot>Also, I couldn't join a channel, which worked fine from IRC, because Matrix said it was invite-only, which it used to be, but wasn't at the time
<lle-bout>abr: we also have one thing here, it's sneek
<lle-bout>sneek later tell abr hello there
<sneek>Okay.
<abr>back ?
<sneek>abr, you have 1 message!
<sneek>abr, lle-bout says: hello there
<abr>oh ! so great
<lle-bout>:-D
<abr>thanks for letting me know
<lle-bout>Noisytoot: hmm yes well there's probably that it's a bit slow to sync from IRC at times also because it's kind of overloaded I believe
<civodul>lle-bout: maybe not everyone shares your enthusiasm about the explorer? :-)
<tissevert>hey !
<abr>tissevert: hello me !
<tissevert>oh ?! You're me ? I'm you
<tissevert>well hello me then
<lle-bout>civodul: well doesnt matter, a new tool in GNU Guix world deserves systematic enthusiam, no? :-D
<civodul>sure!
<civodul>we should discuss whether to turn it into 'guix system explore'
<civodul>tissevert: hi!
<lle-bout>civodul: yes! I figure the best way to share knowledge with GNU Guix is adding official subcommands
<tissevert>: )
<raghavgururajan>lle-bout: Can you do `git pull --rebase`. I have modified some stuff.
<tissevert>そして、ここで日本語で書けます!あたしもテストパイロットになりたいです^v^
<luis-felipe>lle-bout: Regarding GNOME, maybe it is better to discuss the ideas in guix-devel. If there is anything I can help with, I'll give it a try.
<luis-felipe>tissevert: \o/
<lle-bout>luis-felipe: when they are more precisely defined, yes!
<lle-bout>raghavgururajan: doing now!
<lle-bout>There https://git.sr.ht/~lle-bout/awesome-guix/commit/eed55ef !
<raghavgururajan>glibmm@2.64 cairomm@1.13 should not build now.
<lle-bout>civodul: should we get a planet.gnu.guix.org RSS feed?
<lle-bout>raghavgururajan: rather they should? :-P
<lle-bout>tissevert: is that the new abr
<tissevert>lle-bout: yeah, yeah, it's me, I hadn't closed it yet because I was looking for the name of the mailing lists : )
<tissevert>done know
<tissevert>I'm subscribed
<lle-bout>awesome!
<abr>so I guess it's bye bye
<lle-bout>tissevert: well the best way to catch up with GNU Guix IMO is to glance at the new emails a little bit every day
<raghavgururajan>lle-bout, I mean they wont be triggered to be built, as there are not references to them now.
<lle-bout>raghavgururajan: it's building xorg-server for me still on the old revision
<tissevert>ok I'll try and do that
<raghavgururajan>*no references
<marusich>luis-felipe, the artwork you made is really cool! I like it :)
<lle-bout>raghavgururajan: aaa it still fails for me :-S
<lle-bout>raghavgururajan: it says it can't find sigc++-2.0
<lle-bout>marusich: hello!!! :-D
<lle-bout>marusich: I finally updated the guix package to some version that works, so we can guix pull and everything on powerpc64le-linux!
<marusich>excellent!
<marusich>I'll give that a try too. I guess the next step is to get offload working.
<marusich>so ludo can build the release binary
<marusich>I don't really know about the --with-long-double-128 (do we need to specify it when building gcc-final?), but it works so I'm inclined to let it be. That whole long double stuff in the toolchain sort of feels like black magic to me; I guess it's an area where I'm not super knowledgeable.
<luis-felipe>marusich: Glad to hear that, thanks!
<lle-bout>raghavgururajan: I mean this: $ ./pre-inst-env guix build glibmm@2.64
<lle-bout>raghavgururajan: I run this command to test things as a whole (your commits): $ ./pre-inst-env guix build -k -v1 glib libsigc++ glibmm gtk-doc gobject-introspection cairo cairomm pango pangomm gdk-pixbuf gdk-pixbuf+svg vala libgsf atk atkmm
<lle-bout>marusich: did you announce POWER9 support to #talos-workstation?
<lle-bout>I'll send an email to Michael from Phoronix about it
<lle-bout>Also, https://www.talospace.com/ guy
<marusich>I mentioned it was coming
<marusich>but it's worth "announcing" again officially
<nckx>Good evening Guix.
<sneek>nckx, you have 1 message!
<sneek>nckx, raghavgururajan says: Do you know how to fix my key thing on bayfront? Or would you be able to?
<marusich>that's a great idea, lle-bout
<lle-bout>civodul: also it would be nice creating a blog post about powerpc64le-linux and remaining work, especially reproducible bootstrap binaries
<marusich>I was thinking it would be fun to write a blog post about the journey so far and what comes next, but i have yet to find the time
<nckx>raghavgururajan: Yes.
<marusich>yeah that part especially
<marusich>i still have to make changes to add docs/news entries for the release.
<lle-bout>marusich: yes! blog post! I can try writing one but we should not miss things so we'll have to review back and forth few times
<nckx>raghavgururajan: What's your public key?
<marusich>lle-bout, let's try to write a blog post about it; we can both present some ideas and merge it into something.
<lle-bout>nckx: hello :-)
<lle-bout>marusich: alright!
<lispmacs[work]>hi, I hooked up an old digital® lk46w-a2 computer to my guix workstation, and it has an cool but non-standard keyboard layout. I'm trying to figure out if there is a utility I could use to display what letter/function is being triggered when I press a key
<marusich>there is an email list specifically for reviewing blog posts...I think it was guix-blog@? guix-blogs@? I can't recall exactly. Anyway, if you CC me I will comment, and I will CC you when I come up with something
<lispmacs[work]>I tried looking at key-mon and xkbwatch but they are broke or don't seem to do what I was looking for
<lle-bout>marusich: I don't know about that.
<nckx>luis-felipe: NICE.
<marusich>guix-devel is fine too
<marusich>it's not like it's a secret
<civodul>marusich, lle-bout: there's guix-blog but i often end up being the one replying... so, instead, i recommend guix-devel or IRC :-)
<marusich>indeed!
<nckx>luis-felipe: Out of stock already? Or is that an artificial shortage 😉
<marusich>by the way civodul thank you very much for fixing tests/print.scm
<civodul>marusich: you can push an .md file under drafts/ and ping people
<lle-bout>civodul: OK!
<marusich>sounds good
<civodul>(make sure to push under drafts/ or it goes on-line right away!)
<lle-bout>civodul: alright! do we create another branch to not pollute the history if we cooperate on it?
<lle-bout>marusich: I propose we can use this to collaborate real time with Markdown: https://pubcryptpad.pep.foundation/code/#/2/code/edit/0iluGjRtwT4JGG1qhSjXhKQR/
<civodul>lle-bout: no i think it's fine, but please don't touch things outside drafts/ without review
<marusich>lle-bout, sure, that's ok with me
<marusich>i'll bookmark it
<cbaines>how easy is it to add substitutes for fixed output derivations to ci.guix.gnu.org?
<cbaines>It's missing /gnu/store/bna7d1nlmlkgnnjqf7sz9f1hybn2jypk-sudo-1.9.6p1.tar.gz, which is a problem at the moment as the source website is down
<cbaines>guix.cbaines.net provides a substitute for it, so the bytes are available
<marusich>cbaines, you recently mentioned that it is the output of a derivation that determines whether dependent derivations get rebuilt. but I thought one factor in determining a derivation's output path was the content of the derivation file itself. If the derivation is different, how is it possible for the output to be the same? Of course, I'm talking about non-fixed-output derivations; fixed output derivations obviously can have the same output
<marusich>with different derivations.
<cbaines>marusich, this normally happens when the fixed output derivations change, but the outputs from those derivations don't
<civodul>cbaines: we can copy the file there and run "guix download file://$PWD/sudo...tar.gz"
<marusich>But for a derivation which is not a fixed output derivaiton, is it possible to have two different derivations (different contents of the .drv file) yield the same output path?
<marusich>I thought the answer was "no", but I'm not sure now.
<civodul>marusich: yes, because it may depend (indirectly) on fixed-output drvs
<cbaines>marusich, yes, because those non-fixed output derivations will reference different fixed output derivations, which produce the same outputs
<marusich>I must be misunderstanding something. Is it true that the hash value in the output path of a (non-fixed-output) derivation depends in part on the contents of the .drv file itself?
<marusich>If it is true, then I don't understand how the output could possibly be the same if the .drv files differ.
<marusich>how the output *path* could be the same.
<marusich>i understand how the content of the output could be the same.
<Whyvn>how would I go about cleaning up old system configurations that are added from guix system reconfigure that show up in grub?
<luis-felipe>nckx: Thanks :) Some colors/items may be out of stock, but if the whole collection is displayed as out of stock, that's a bug :)
<cbaines>marusich, the way the "hash" of a derivation file is computed is a little involved, it's not just a simple hash all the bytes
<cbaines>years ago I looked in to this and included some information in a presentation https://www.cbaines.net/projects/guix/freenode-live-2017/presentation/#/7 that might be useful, you can read the notes down the bottom of the page
<lle-bout>raghavgururajan: hey, are you still here?
<marusich>My understanding is that if /gnu/store/abc-foo.drv produces /gnu/store/xyz-foo, the content of abc-foo.drv is one of the factors that goes into computing the hash xyz.
<marusich>I guess I should revisit the code to refresh my understanding. It sounds like you are saying that is not true.
<cbaines>marusich, what you say is true, but for computing the hash, you use the hashes of the dependent derivations (not their filename)
<raghavgururajan> https://jabber.hot-chilli.net/jabberupload/share_v2.php/756428bf-1043-4814-b56c-c137247b3133/id_ed25519.pub
<raghavgururajan>nckx ^
<raghavgururajan>lle-bout: Was afk.
<cbaines>marusich, and I think it's this bit that means that a fixed output derivation can change at the bottom of the graph, but it's "hash" doesn't change for the purposes of computing derivation hashes (because the derivation still produces the same bytes)
<nckx>raghavgururajan: Will do.
<lle-bout>raghavgururajan: okay :-) - well glibmm@2.64 (can't find sigc++-2.0) and cairomm@1.13.1 (seems it doesnt support meson) still fail
<raghavgururajan>You don't need to build glibmm@2.64. It was a dependency of gtkmm, but I updated gtkmm.
<nckx>luis-felipe: Not even all sizes, there was still an XL black one.
<nckx>16yo nckx would've worn it.
<lle-bout>raghavgururajan: hmm well I don't build it, it's an indirect dep
<lle-bout>raghavgururajan: I use this: $ ./pre-inst-env guix build -k -v1 glib libsigc++ glibmm gtk-doc gobject-introspection cairo cairomm pango pangomm gdk-pixbuf gdk-pixbuf+svg vala libgsf atk atkmm
<raghavgururajan>same for cairomm@1.13
<raghavgururajan>Oh.
<raghavgururajan>lemme check
<lle-bout>raghavgururajan: gtk-doc it seems
<lle-bout>besides gtk-doc, everything builds! yay!
<lle-bout>raghavgururajan: let me review commits individually really quick and let's push!
<cbaines>civodul, woo, using guix download on bayfront worked, so I'll go through those same steps on berlin in case anyone else is having the same issue
<marusich>cbaines, thank you for your link. It's helpful. I think I need to re-read the code while looking at it, but it's clear I probably misunderstood how the hashing works. In particular: "One more processing step takes place before this data in hashed. The input derivation files, shown in the green area are replaced with the hash for the corresponding derivation, computed through the same process that we are currently going through."
<cbaines>cool :)
<raghavgururajan>> ‎lle-bout‎: read my mind
<lle-bout>raghavgururajan: what do you mean?
<cbaines>every time this comes up, I remember that I wanted to make the Guix Data Service clearly display where the hashes come from, and what data goes in to it, but I haven't got around to that yet...
<nckx>raghavgururajan: I meant your Guix signing pubkey (/etc/guix/signing-key.pub). It should be the same one mentioned in the error message you get when offloading fails.
<raghavgururajan>lle-bout: never mind! I am sleep talking xD
*nckx (つ ◕‿◕ )つ ☕
<lle-bout>raghavgururajan: okay :-)
<marusich>I need to sign off for a while. See you all later!
<lle-bout>marusich: see you soon!
<raghavgururajan>nckx: You mean bayfront's pub key that I have under /etc?
<nckx>No, yours.
<nckx>On your machine.
***lukedashjr is now known as luke-jr
<raghavgururajan>Btw, I am not offloading anything from my machine. I use bayfront via ssh. Bayfront offloads to other remote machines.
<nckx>OK, then I misunderstood what needs to be done. Could you (re)elaborate what your ‘key thing on bayfront’ means? :)
<nckx>What do you run, where do you run it, and what's the error.
<nckx>I just worked 12h; use short words.
<nckx>Pictures. Sound effects.
<nckx>No emojoes, there are limits.
*raghavgururajan got disconnected *sigh*
***lukedashjr is now known as luke-jr
<raghavgururajan>nckx: While building anything on Bayfront (via ssh), I see this error message pass-by in the screen. https://paste.debian.net/plain/1190878
<nckx>raghavgururajan: Does it mention an IP above that?
<nckx>Or hostname.
<nckx>It should be one of harbourfront or milano.
<raghavgururajan>It doesn't.
<nckx>OK, ‘guix build’ woke up and works (was silent for an oddly long time), I should be able to figure out what's missing where.
<dustyweb>hello #guix!
<lle-bout>dustyweb: hey!!
<dustyweb>I just wanted to say again, thanks for being a nice community here
<nckx>raghavgururajan: By the way, 7D... is bayfront's public key, and it needs to be added to one or both of the active build nodes. I thought you had offload (root) access to bayfront and were trying to offload to it from your own machine.
<lle-bout>raghavgururajan: do we want that libcloudproviders thing? why did you add it, do you have a precise use case in mind? is it for Nextcloud? If so that's fine
<lle-bout>dustyweb: :-D
<raghavgururajan>nckx: I see.
<raghavgururajan>lle-bout: Yep, nextcloud
<tissevert>cbaines: thanks for your slides that you linked earlier, they're very helpful
<dustyweb>sometimes I kind of get depressed about the state of... everything, but the experiences I've had in this community have just been so nice. like everyone, we have a lot we could do better but I really like being here and part of things, even though my contributions are small
<cbaines>tissevert, you're welcome :)
<lle-bout>dustyweb: Racket <-> GNU Guile code converter when
<dustyweb>lle-bout: heh ;)
<nckx>raghavgururajan: So I'm trying to find out which one, and then I'll have to ping the owner(s) because I don't have SSH access to either of them.
<civodul>lle-bout: that's... upfront :-)
<civodul>dustyweb: i can sympathize... thanks for being here!
<raghavgururajan>nckx: No hurry, the error isn't fatal.
<lle-bout>dustyweb: thanks for all exciting talks you make!
<tissevert>I just have a question regarding g-expressions: in your presentation, they come out as «something separate from regular guile code»
<nckx>Yeah, it should fall back to a local build, which on bayfront is still plenty fast. Maybe even faster; I don't know the others' specs.
<tissevert>am I mistaken or how do they differ ? what about this weird #~ before the `begin` parenthesis ? is this syntaxic sugar ?
<dustyweb>:)
<lle-bout>dustyweb: GNU Guile needs love, I am kind of sad all your productivity went to Racket instead aaa :-S, guess it's hard to tolerate frustration with tooling for too long
*nckx waves at dustyweb, offers privacy-respecting cookies.
<lle-bout>Would be nice if http://swig.org/ was adapted for GNU Guile 3.x also
<lle-bout>So we could actually more or less generate bindings for all C libraries in GNU Guile
<leoprikler>well, there's still nyacc ;)
<leoprikler>btw. did we fix all bad response stuff or did I just get lucky today?
<civodul>lle-bout: two comments from the trenches: (1) i would not recommend SWIG when writing bindings (prefer nyacc's FFI tool or hand-coded FFI bindings), and (2) sometimes it's more productive to implement the thing than to write bindings
<civodul>this is hand-wavy, that's my contribution to the discussion
<lle-bout>civodul: I didnt know about nyacc! And yes, always end up more ergonomic to write them by hand but I believe generation can also help
<civodul>i'm skeptical :-)
<civodul>generating things yes, but in the sense of guile-xcb or guile-gi, not in the sense of SWIG
<lle-bout>leoprikler: it's fixed!
<leoprikler>wooo!
<leoprikler>so just to be sure, this means "really, really fixed, fingers crossed, this time", right?
<lle-bout>dustyweb: on your obj-cap work, do you use HTTP anywhere?
<lle-bout>leoprikler: yes yes yes
<leoprikler>nice :)
<lle-bout>or, yes just fixed, not fingers crossed
<lle-bout>AIUI
<tissevert>AIUI ?
<lle-bout>Some more work around tolerance to bad networking is being done also AFAICT
<lle-bout>tissevert: As I Understand It
<tissevert>oh ^^' thanks
<lle-bout>dustyweb: I am saying this because maybe we need some HTTP2 library somewhere here
<raghavgururajan>Hey dustyweb! Looking forward to collaborate with you this Sunday. :-)
<lle-bout>dustyweb: It feels refreshing to see your enthusiasm into things, I also very like much acting like that wish I saw you more around here :-D - Do you hang out in other channels now? If so which?
*civodul tries moving qt@4 to Guix-Past
<marusich>indeed, dustyweb's enthusiasm is infectious :)
<dustyweb>lle-bout: I do use http + ocap for some things!
<dustyweb>not with the captp stuff I'm doing but you can *absolutely* do ocaps over http
<dustyweb>lle-bout: about my energy going to racket: I do plan a port of Goblins to Guile soon
<dustyweb>what it's waiting on
<dustyweb>is for me to get the last parts of the network protocol done on the racket end
<dustyweb>so that I can then focus on porting what I have to guile
<dustyweb>that way we can try two separate runtimes talking to each other
<tissevert>: ) I hope this community is as welcoming as dustyweb is saying cause I've been very disappointed by so many others
<marusich>dustyweb, do you use dr racket for development, or do you use emacs?
<dustyweb>oh and yes looking forward to seeing you on sunday raghavgururajan
<marusich>just curious because dr racket seems pretty handy but emacs is also comfortable
<tissevert>but I must say everyone sounds nice and make me wanna try. thank you
<dustyweb>marusich: I use racket-mode on emacs when I'm writing things myself
<dustyweb>but drracket is good (if hugely memory hungry)
<dustyweb>and when I teach racket
<dustyweb>I use drracket so I'm using the same things as the students
<dustyweb>(for the workshops my spouse and I have done)
<marusich>cool! thank you for sharing
<dustyweb>tissevert: I hope you find it so as well!
<lle-bout>tissevert: I have a feeling that everyone here has begun and is quite advanced in the process of being self-conscious of themselves with their emotions and the ones of others so that we try to pay attention to that and when we fail recognize and try to improve together
<raghavgururajan>lle-bout: For gtkmm@2.24, can you edit the inputs to remove *-version for cairomm, pangomm, glibmm and the try building?
<lle-bout>s/and when we fail/,and when we fail/
<tissevert>wow, if that's true that's a lot ! I don't even ask that much : ) but yeah my first experience with this chan is really encouraging, especially considering I started by being quite bitchy about not getting a quick answer to my first questions
<tissevert>sorry about that
<lle-bout>tissevert: about these things, take note: we are also a bit overworked and deal with an important flood of information and frustration at times
<lle-bout>And when people don't answer, most of the time it's because nobody knows about the answer, and the ones who do are overworked and busy
<lle-bout>dustyweb: that's very cool! I read you plan on porting to GNU Guile :-) - I considered that there was more to your work than Globins in general in my previous statement
<raghavgururajan>lle-bout: Btw, did you do guix gc on the www machine?
<lle-bout>raghavgururajan: there's a cronjob when things take too much space but I don't do so manually
<lle-bout>raghavgururajan: trying your suggestion now
<tissevert>noted ! it's just I was afraid of getting the same sort of treatment I got elsewhere, being either completely ignored or man-splained — I see it's been quite different so far
<raghavgururajan>I see.
<lle-bout>tissevert: cool :-D
<lle-bout>raghavgururajan: I notice some commits also do formatting/indent changes which doesnt make them easy to review
<dustyweb>lle-bout: yes, there's more than goblins
<dustyweb>though, with the captp part, it should be possible to get different components talking to each other even if written in different languages
<dustyweb>so even if there are some racket components, guile could speak to them, and vice versa, quite feasibly... if all works out
<raghavgururajan>lle-bout: Oh, it must be the indent.el script
<dustyweb>lle-bout: though, this will be extra true if we get racket stuff packaged in guix. but I know others have been looking into it. I am hopeful. :)
<lle-bout>raghavgururajan: it's good they are indented now if they werent either way just harder to review
<lle-bout>dustyweb: Are you thinking about pushing the "microservice" paradigm to combine multiple languages together also? Or it wasnt what you were saying?
<lle-bout>dustyweb: in that GNU Guile wouldnt need ports of things to benefit from them still through some RPC?
<dustyweb>lle-bout: you could think of it as... pseudo-microservice style
<dustyweb>Goblins itself would provide the "RPC" system, that's what captp is
<dustyweb>but more on that later, busy right now :)
<lle-bout>dustyweb: okay, see you! :-)
<dustyweb>later!
<lle-bout>raghavgururajan: I am going to rewrite the commit history a little to make the cosmetic changes clearer
<raghavgururajan>lle-bout: Thanks!
<lle-bout>raghavgururajan: for historical reasons you maybe want to post this finished patchset to the bug then I'll push some time after
<raghavgururajan>lle-bout: Sure, will do.
<lle-bout>historical reasons as in, so what we did is clear for others to dig later
<tissevert>I'm going AFK too, thanks again for all the help !
<tissevert>see you : )
<lle-bout>tissevert: see you!!
<lle-bout>raghavgururajan: the git history will not be 100% pretty but I think judging benefit/loss this will be more than fine
<lle-bout>git is a tedious tool for splitting up commits, and the commit convention is also tedious to do all manually
<raghavgururajan>Yeah
<raghavgururajan>Did gtkmm-2 worked?
<genr8_>oof. I ran a command "guix pack --localstatedir --profile-name=current-guix guix" and it completely ruined all my profiles somehow. I can't even get the guix command to run now, "no code for module (gcrypt hash)"
<genr8_>it seems to have re-written everything on disk , and then re-linked stuff, but wrongly
<lle-bout>raghavgururajan: no gtk-doc and all its dependents are still broken
<lle-bout>I think we should solve it somehow but heh
<lle-bout>genr8_: woops, not sure what that involves here..
<lle-bout>raghavgururajan: you can't test it yourself?
<lle-bout>raghavgururajan: substitutes are available from my machine
<lle-bout>raghavgururajan: would be easier if you had commit access
<lle-bout>raghavgururajan: or we could agree to cooperate on a single branch somehow
<lle-bout>on any repo
<raghavgururajan>lle-bout: I tried building but some substitutes wasn't available.
<raghavgururajan>Lemme retry.
<lle-bout>raghavgururajan: here's my branch: https://git.sr.ht/~lle-bout/guix/log/rag-core-updates-1
<lle-bout>with all commits signed off and the cosmetic commits's title modified to also say that we are ungrafting (a bit ugly but whatever)
<lle-bout>civodul: how come you didnt provide a guix.scm file for running guix-explorer :-)
<soouul>hi, i set up my guix system but for some reason i cant change my caja settings :(
<lle-bout>soouul: hello! I don't know what caja is exactly but what does that entail that is, changing it's settings?
<soouul>oh its a file manager!
<soouul>and when i use nautilus the settings are all messed up and tweaks doesnt work :(((
<soouul>im on wayland if that matters
<lle-bout>soouul: what's your GNU Guix System configuration and 'guix system describe' output?
<soouul>can i paste all that? or do you want a specific line
<lle-bout>soouul: use https://paste.debian.net
<soouul>kk
<raghavgururajan>lle-bout: Thanks so much!
<lle-bout>civodul: "GUILE_LOAD_PATH=~/src/guix ./explore.scm /run/current-system/configuration.scm" wont work somehow
<soouul> https://paste.debian.net/1191124/
<raghavgururajan>I am trying to fix the glibmm-2.64 cairomm-1.63
<raghavgururajan>lle-bout, ^
<lle-bout>raghavgururajan: okay!
<soouul>wth
<lle-bout>soouul: looking
<soouul>no yeah
<soouul>i just, thought i fixed it
<lle-bout>soouul: and the GNU Guix System configuration?
<soouul>you know those moments when you think you fix it but it was just a false alarm of your foolness
<soouul>foolishness*
<lle-bout>heh
<soouul>well you want a specific line? cuz this is a disaster rn
<soouul>i was using nano for like 4 hours
<lle-bout>soouul: all of it
<soouul>noooooooooooooooooooooo
<soouul>ok 1 sec
<soouul>dont judge my propietary software :(
<lle-bout>soouul: I wont judge I just want to know what's up :-P
<lle-bout>And help!
<lle-bout>soouul: you can add a GNU GPLv3 license header before sharing :-)
<lle-bout>but maybe all GNU Guix configs are actually derivative works of GNU Guix so that makes them GPLv3+, not sure
<soouul> https://paste.debian.net/hidden/4dc8b242/
<soouul>i was thinking about that while installing
<soouul>i wouldnt mind if my soul was owned by gnu
<soouul>maybe then i would be forced to finish something!
<soouul>AND YES thats a lot of packages, its my desktop setup for maximum comfiness
<lle-bout>soouul: a lot, don't know, looks pretty normal amount to me!
***sneek_ is now known as sneek
<lle-bout>soouul: so basically there's some poorly defined runtime dependencies for some programs right now
<soouul>!!!
<soouul>ok enlighten me
<lle-bout>soouul: in that, some programs also need other packages installed to actually work
<lle-bout>or have full functionality
<soouul>ohhhhhhhhhhhhhh
<soouul>care telling me which ones, and how do i see that for the future?
<lle-bout>I think we should solve this problem in GNU Guix packages
<lle-bout>but currently I think this is a bug in several packages we need to tackle and find a good way of doing so
<lle-bout>soouul: I don't know which exactly but if you can show me precise things about that Caja bug I may be able to tell you
<soouul>wait so its only partly my fault? :D
<lle-bout>soouul: I wouldnt say it's your fault, I think we must do something about it, don't know how yet though
<lle-bout>We have been writing shells scripts wrappers on occasion
<soouul>well think a regular settings window, and when i click a setting like show hidden files it activates it and reverts instantly
<lle-bout>soouul: any log if you start caja from the terminal?
<soouul>si
<soouul>1 second
<roptat>I've had that kind of behavior before
<soouul>TWIST, its not showing log now :(
<soouul>roptat: oh? howd you fix it?
<roptat>you need another package, I think you need dconf, or something similar
<roptat>I can't remember exactly if that was dconf or some other name
<soouul>reconfiguring, tell ya in a sec
<soouul>it was that
<soouul>thanks ily u have saved my life
<roptat>if you run caja from the command line, it should give you some warning message about dconf missing
<soouul>nowww
<roptat>or some other configuration service
<soouul>how did you get the extensions to work?
<lle-bout>soouul: if I can suggest some additional packages: xdg-utils, gnome-themes-standard, gnome-themes-extra, hicolor-icon-theme, dconf
<roptat>soouul, I don't use caja
<soouul>adding them
<roptat>I had a similar error with other software, that's all
<soouul>what do you use :O
<roptat>the setting reverting immediately
<roptat>my terminal :p
<soouul>:ppp
<roptat>I think it's been like 3 or 4 years since I last opened a file manager ^^'
<soouul>i tried using ranger and nnn but i just couldnt get used to it
<soouul>well lets be honest
<roptat>I mean, I just cd and ls
<soouul>i didnt use ranger
<soouul>lmao
<roptat>and xdg-open or directly run the software to open files
<lle-bout>cd and ls feels more productive to use to me after all
<lle-bout>soouul: another thing you might need is a pinentry
<soouul>im too used to right clicking and clicking open terminal here
<roptat>but hey, I'm not judging you, if you want to use caja, it should work for you, otherwise it's an issue we need to fix
<lle-bout>soouul: pinentry-gnome3
<soouul>added it
<lle-bout>roptat: do you think we should write wrappers everywhere? I think that's tedious and need some mechanism similar to propagated-inputs but without the issues people say it has
*roptat afk :)
<soouul>should i use guix refresh or guix pull
<lle-bout>soouul: guix refresh is something else, use guix pull
<soouul>and is guix package -u the regular way to update or is it sudo guix upgrade
<lle-bout>guix upgrade is a shorthand for guix package -u
<soouul>O
<lle-bout>guix refresh is a development tool to aid in upgrading GNU Guix package definitions
<soouul>i seeeeee
<lle-bout>upgrading as in, modifying their code so they use newer versions of software
<soouul>well i gotta reboot and then sleep, i will def be back later or tomorrow, didnt think everyone would be so nice
<soouul>gotcha thanks
<lle-bout>but to fetch updates from the GNU Guix repo you use "guix pull"
<lle-bout>soouul: good night! :-D
<pineapples>o/
<pineapples>I'm trying to wrap my head around installing Guix on top of Fedora Workstation and I don't know where to obtain the *.cil file for SELinux to not prevent guix-daemon from running
<lle-bout>pineapples: hey, well I don't think the SELinux rules are complete
<lle-bout>they are in etc/guix-daemon.cil I think
<lle-bout>pineapples: https://guix.gnu.org/manual/en/html_node/SELinux-Support.html
<pineapples>lle-bout: Here https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-daemon.cil.in ?
<lle-bout>pineapples: yes, you must build it first so it's in post-processed form
<lle-bout>without '.in'
<lle-bout>pineapples: I am actually not sure if you can get those compiled from an existing install without recompiling GNU Guix
<lle-bout>pineapples: to compile: "./bootstrap && ./configure --localstatedir=/var && make etc/guix-daemon.cil"
<lle-bout>raghavgururajan: please only make new commits by the way, otherwise it could be annoying for me to integrate changes in between my current history
<pineapples>lle-bout: thanks! I'll try the command out. If it somehow doesn't work, I'll give Debian a try. As much as I love Fedora, I need Guix installed on my backup OS, just in case something goes wrong.
<lle-bout>pineapples: it's always possible to "setenforce 0" as root temporarily if you need GNU Guix.
<lle-bout>raghavgururajan: could you get substitutes by the way?
<dongcarl>Anything that needed to be done for the openssl 1.1.1k release?
<lle-bout>dongcarl: what do you mean? I grafted it to the openssl package few hours after it was released
<lfam>Hey roptat, regarding the Python optimization changes, do you have patches online anywhere? Or a git branch?
<pineapples>ill-bout: I think I'll just give a Debian try :-) Thanks for your help!
<lle-bout>pineapples: alright!
<dongcarl>lle-bout: Oh? What was involved in "grafted it to the openssl package"?
<pineapples>I've always wanted to try Debian out as my backup OS. This is my chance
<lle-bout>dongcarl: take a look at: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=10cbf042e13c328559de3bfd8e42ceb8f8f51d10
<dongcarl>lle-bout: Ah great! That's on master already?
<lle-bout>dongcarl: yes :-)
<dongcarl>:)
<lfam>You can learn more about grafting here: https://guix.gnu.org/manual/en/html_node/Security-Updates.html
<lfam>Hm
<lfam>Building the "devel" manual for the website is failing with a segfault
<lfam>"mmap(PROT_NONE) failed" when building guix-translated-texinfo.drv
<lle-bout>lfam: at some point that happened non-deterministically for me when building GNU Guix itself
<lfam>Really weird
<lfam>There didn't used to be a problem
<lle-bout>lfam: does that use GNU Guile? I think that may be related to GNU Guile
<lfam>The command is `guix build -f doc/build.scm`
<lfam> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n355
<lfam>It's configured there
<lfam>It's important for it to work, because updates to the manual are a primary way that we communicate about the project
<lle-bout>lfam: yes
<lfam>I really have no idea where to start
<lle-bout>lfam: me neither heh
<lle-bout>gdb?
<lle-bout>guile repl?
<lle-bout>lfam: about binutils security patching.. there's lots of CVEs we have to catch up for..
<lfam>Any use of binutils that occurs are build-time will not be affected by grafting
<lfam>I mean, "that occurs at build-time"
<lle-bout>lfam: yes so how do we do
<lle-bout>also must binutils be upgraded in tandem with GCC?
<lfam>There are still some run-time uses, if I understand correctly
<lfam>We should think about if the build-time uses are a security problem for Guix or not
<morgansmith>I was wondering if I could get some help. I'm trying to build something using the arm-none-eabi-toolchain that requires newlib-nano. If you read the nano.specs in our newlib-nano package, it really looks like the library should be named libc_nano.a but the only files available are libc.a. Any ideas? I'm not the greatest with gcc stuff
<lle-bout>lfam: I think nckx's CVE lint coloring patch would really help prioritizing for these issues, unfortunately the patch has a bug I am unable to find. I can't wrap my head around how json parsing works in GNU Guile
<lfam>morgansmith: It's being discussed at <https://bugs.gnu.org/47325>
<lfam>Or rather, the discussion awaits you :)
<morgansmith>O.o. Thanks! :D
<raghavgururajan>lle-bout: So sorry, just saw your message. I had create few new commits and edit few existing ones. But mostly the former. This will be the last change for this batch. Fixed (glib|cairo|pango|atk|gtk)mm-foo builds. Updated my repo.
<raghavgururajan>Once again thanks a lot for helping me out. I couldn't have managed to finish it without you.
<raghavgururajan>> lle-bout‎: raghavgururajan: could you get substitutes by the way?
<raghavgururajan>I couldn't get for cyrus-sasl and php.
<raghavgururajan>Possibly different .drv hash.
<roptat>lfam, https://issues.guix.gnu.org/47251
<lfam>Thanks roptat
<lle-bout>raghavgururajan: I see thank you! Well I'll redo commit history, no big deal :-)
<roptat>lfam, I didn't see your answer on the other patch I sent, thank you!
<roptat>I had issues importing the right modules in the snippet, so I'm not sure it'll work, but I can try again
<lfam>I don't know which patch you are talking about :)
<roptat>oh sorry, that was ludo, not you
<roptat> https://issues.guix.gnu.org/47214#3
<roptat>I also want to send a patch to move idle to its own output
<roptat>that's the case in most other distros
<lle-bout>raghavgururajan: I also couldnt do it without your experience here, I figured tackling GNOME 40 upgrade from scratch is just too much work when you don't know anything about it
<lfam>I wonder if it would be feasible to do a 'python-updates' branch that made these changes, ungrafted, and did any minor upstream updates, and complete it within 2 weeks
<raghavgururajan>:-)
<lle-bout>raghavgururajan: everything builds, awesome!
<lle-bout>let's merge and move on now
<roptat>lfam, sounds hard, but that's OK with me. The second patch might break some packages though, because it removes some .py/.pyc files that might be relied on by other packages
<raghavgururajan>lle-bout: Yay!!!
<lfam>roptat: I'm curious, what aspects of it sound hard to you?
<roptat>the two weeks sound a bit short
<lfam>For building? Or for fixing?
<roptat>for fixing
<lfam>I see
<roptat>I'm sure building will not be an issue with the new cuirass :)
<lfam>Agreed
<lfam>At least for x86_64
<roptat>and it touches the bootstrap, which is... pretty bad news for my server :p
<roptat>poor armhf :/
<lfam>I could do some advance reconnaissance, so to speak, making a branch on a powerful server and building some target packages that exercise a large portion of the package graph
<lfam>The berlin server has prolonged periods where it mostly idle
<lfam>I don't think we should hesitate to run tests like that
<roptat>we can create the branch now and test, and maybe we'll make it in time
<lfam>I don't think we should try to do it within the next two weeks. I meant, after the release, and maybe before core-updates
<roptat>there's no point talking about whether we can make it in time other than delay it and miss the time frame :)
<lfam>It depends on if core-updates is actually ready to start work or not
<roptat>oh, then we might have less pressure to fix, that's fine with me
<lfam>I absolutely don't want to do this work before the release :)
<lfam>If core-updates is ready to begin working, we would just start there
<roptat>ok, sounds good
<lfam>But if not, we could do some more specific work, such as python-updates
<lfam>I think your optimization work is important to deploy soon
<roptat>yeah, I had an artifact evaluation on a paper rejected because of it ^^'
<lfam>:(
<roptat>I sent them instructions to use guix's python that had very different timings than what my co-author had
<lfam>That's no good
<roptat>well the paper was rejected for other reasons too, so that's fine
<roptat>and it was accepted in the following venue we submitted to (with improvements)
<lfam>Still
<lle-bout>raghavgururajan: ahhh!! I am sorry json-glib fails heh
<lfam>I got `guix build -f doc/build.scm` to succeed, with --max-jobs=1
<lfam>It grafts texlive-texmf, which is 5.7 GiB on disk
<lfam>There's no way the server ran out of memory, but something is fishy
<raghavgururajan>lle-bout: Just a sec
<lle-bout>raghavgururajan: I'll fix it and push, enough of you now
<lle-bout>raghavgururajan: oh.. if you can do it heh
<raghavgururajan>Its a missing gtk-doc
<lle-bout>raghavgururajan: Okay!
*roptat afk again
<raghavgururajan>err. more than gtk-doc
<soouul>you know when yous ay youre going to sleep then stay "fixing 1 more thing"
<lle-bout>soouul: :-) yes
<lle-bout>and you end up going to sleep at 5AM somehow
<soouul>how do i set up swaylock :( says it needs to be setuid to read /etc/shadow
<soouul>more like its 4pm
<soouul>or well almost
<soouul>i sleep at like 2 pm
<lle-bout>soouul: okay so you need to add this a setuid-programs field to your operating-system definition
<lle-bout>soouul: okay :-) not very living during the day these days either
<soouul> https://paste.debian.net/1191136/
<lle-bout>soouul: something like this: (setuid-programs (append (list #~(string-append #$swaylock "/bin/swaylock")) %setuid-programs))
<soouul>i added this line just above the package expression
<soouul>OH
<lle-bout>it's the same thing I think
<lle-bout>you did well
<lle-bout>so why does it not work?
<lle-bout>try "hash -r" in your shell?
<soouul>your line worked
<soouul>mine didnt
<lle-bout>hmm not sure why
<lle-bout>soouul: oh yes
<lle-bout>you used shadow
<lle-bout>and not swaylock
<soouul>ic
<lle-bout>shadow is the name of the package, shadow is for passwd and friends
<soouul>OH ok, yeah thats what iw as not sure about
<soouul>but uh maybe i need to reboot cuz swaylock still giving issue
<lle-bout>run: hash -r
<lle-bout>then run it from terminal
<soouul>nvm it worked
<soouul>yeee
<soouul>:DDDD
<lle-bout>otherwise for sway to account for it it needs updated environment
<lle-bout>so yes reboot
<soouul>ok i SLEEP forreal
<soouul>i am BEAT i had to take my dog to the vet too
<lle-bout>like with a shortcut such as Super-Shift-L
<soouul>PEACE
<soouul>i use ctrl - alt - l
<lle-bout>soouul: good night :-)
<lle-bout>raghavgururajan: hey, so what else?
<raghavgururajan>lle-bout: Fixed!
<lle-bout>raghavgururajan: yay!
<lle-bout>raghavgururajan: reviewing
<civodul>qt@4 is back for the archaeologists among us! https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/159be3d7e86e1f22b2b7b1efc938ed63120dc973
<lle-bout>civodul: cool! inferiors wouldnt be enough to use a package from a previous GNU Guix revision?
***lukedashjr is now known as luke-jr
<civodul>lle-bout: it depends on the use case; for a library you'd have to take everything from "back then"
<oreoking[m]>How can I speed up guix compile times?
<lle-bout>civodul: do you think tooling could be made to transfer any removed package to guix-past automatically?
<lle-bout>civodul: sure hmm.. whether it is feasible to actually NOT use everything from back then when doing old things.. I think for archaeology you may be better simply using an older GNU Guix version altogether with time-machine probably
<lle-bout>oreoking[m]: which step exactly? what command do you want to speed up?
<civodul>lle-bout: in general yes, that's the whole point of time-machine, but it has its use cases: https://gitlab.inria.fr/guix-hpc/guix-past
<lle-bout>civodul: Got it!
<oreoking[m]><lle-bout "oreoking: which step exactly? wh"> guix pull
<oreoking[m]>Is it compiling from source?
<lle-bout>oreoking[m]: are you using substitutes?
<oreoking[m]><lle-bout "oreoking: are you using substitu"> Whats that?
<oreoking[m]>I am new.
<lle-bout>oreoking[m]: guix pull compiles GNU Guile code to some byte code, and that can take some time, it also generates various caches which can also take time, but there's substitutes for those operations available from ci.guix.gnu.org where a server computes them for you and you can trust that server to provide you with them pre-computed instead.
<oreoking[m]><lle-bout "oreoking: guix pull compiles GNU"> how to set up
<oreoking[m]>I am on a vm
<oreoking[m]>I am going to check that out
<lle-bout>oreoking[m]: substitutes are basically precomputed results of compilations or computations that would otherwise be done on your own machine, it can save you from re-doing them locally but it also means you trust the substitute server to not harm your computer by providing you false/malicious results of these computations
<lle-bout>oreoking[m]: how do you currently run GNU Guix? Do you have a VM with GNU Guix System installed?
<oreoking[m]><lle-bout "oreoking: how do you currently r"> yes
<lle-bout>oreoking[m]: did you download the qcow2 image or use the ISO installer?
<oreoking[m]><lle-bout "oreoking: did you download the q"> ISO
***lukedashjr is now known as luke-jr
<lle-bout>oreoking[m]: alright so you should've been asked for whether to use substitutes or not during the installation process
<oreoking[m]><lle-bout "oreoking: alright so you should'"> I dont remember
<oreoking[m]>i think I did no
<lle-bout>to check if you have that enabled now, I believe you can run: ps waux | grep 'guix-daemon --build-users'
<lle-bout>Then if the output contains: --substitute-urls https://ci.guix.gnu.org
<lle-bout>It means you probably have them enabled
<oreoking[m]><lle-bout "Then if the output contains: --s"> it has subsitute urls
<oreoking[m]>but it still is building things from source.
<lle-bout>oreoking[m]: okay then there's another thing: trusting the public key of the substitute server
<lle-bout>oreoking[m]: can you share the output of a command you think was slow?
<civodul>see also https://guix.gnu.org/manual/en/html_node/Substitute-Server-Authorization.html
<oreoking[m]><lle-bout "oreoking: can you share the outp"> i cant copy and paste between vm to os
<oreoking[m]>though its building the derivatiosn
<lle-bout>oreoking[m]: does it say "Downloading from ... ci.guix.gnu.org" anywhere?
<lle-bout>oreoking[m]: note: it's also possible the substitute server didnt have time to pre-compute the results yet therefore that you must wait to get them, also some times it doesnt have substitutes for some older revisions of GNU Guix because storing all of that is expensive
<oreoking[m]><lle-bout "oreoking: does it say "Downloadi"> no
<lle-bout>oreoking[m]: what command are you running?
<oreoking[m]>guix pull
<oreoking[m]>its building
<lle-bout>oreoking[m]: I think it's normal for guix pull to take some time, you can't avoid it, substitutes will make it faster but not instantaneous either
<lle-bout>oreoking[m]: for things to be much faster we would need to improve GNU Guile and that's always going on but it will take time :-)
<lle-bout>raghavgururajan: woops almost forgot
<raghavgururajan>lle-bout: What's that?
<lle-bout>raghavgururajan: I mean reviewing :-)
<raghavgururajan>Oh phew!
<lle-bout>raghavgururajan: getting caught up in many things some CVEs to handle now but can wait a little
<lle-bout>tar CVE
<lle-bout>DoS memory leak vuln
<lle-bout>raghavgururajan: all good!
<lle-bout>raghavgururajan: I ran this: $ ./pre-inst-env guix build -k -v1 glib libsigc++ glibmm gobject-introspection cairo cairomm pango pangomm gdk-pixbuf gdk-pixbuf+svg vala libgsf atk atkmm gtk-doc glibmm@2.64 gtkmm@2 cairomm@1.13 wayland yelp-xsl json-glib at-spi2-atk at-spi2-core atkmm@2.28 pangomm@2.42 libsigc++@2 vala gtkmm@2 wayland-protocols
<raghavgururajan>looks good
<lle-bout>raghavgururajan: we will fix whatever these patches break later in core-updates?
<lle-bout>like the dependents
<raghavgururajan>yep
<lle-bout>I hope to get Cuirass feedback then
<lle-bout>Alright, let's try that
<lle-bout>raghavgururajan: pushed!
<lle-bout>raghavgururajan: let's hope Cuirass can help us now
<lle-bout>I also will try to run some more builds on core-updates myself
<lle-bout>cbaines: hey! hope you are doing well :-) - I would really love to run guix-build-coordinator myself on powerful machines to build core-updates fast along with the policy you were speaking of that cancels builds if a new commit alters any derivation that affects it
<lle-bout>cbaines: else I would run Cuirass if it had such policy mechanism to cancel expensive builds but I don't think it has yet
<genr8_> https://ci.guix.gnu.org/log/qflzdrjldhifsqiz3s52pm58njc2fzgz-mes-boot-0.22 <-- "phase `build' succeeded after 553.3 seconds"
<genr8_>its going really slowly, and only single threaded
<lle-bout>genr8_: for reproducibility some times we don't do parallel builds
<genr8_>ok
<lle-bout>genr8_: if the reproducibility issues with parallel building are fixed then we can enabled back parallel builds
<cbaines>lle-bout, cool, the way that works for the guix-patches instance I'm running is through build tags, for each new revision of core-updates, builds are queued (just those on the branch, based on a comparison with the latest master revision), and then any build tagged for the branch, but not relevant to the latest comparison is cancelled
<lle-bout>cbaines: do you already run those core-updates build? is there any place I can see results easily? Also can I add more machines to this? What's the priority of it now?
<lle-bout>mbakke: it seems accessing https://ci.guix.gnu.org on ungoogled-chromium doesnt work at all now. It seems related to the new sorting icons that were added, I am thinking this might be due to some image parsing stuff
<cbaines>I'm trying to setup the Guix Data Service, Patchwork, Guix Build Coordinator, ... such that it helps with QA stuff, so testing branches and patches, as well as things like periodically testing fixed output derivations
<cbaines>as for core-updates, I'm not currently queuing builds, but that's just because I rebooted the machine, and I haven't started the script up again
<cbaines>I think you've already got some connected machines
<lle-bout>cbaines: yes I got powerpc64le-linux and one x86_64-linux but they could be even more powerful :-)
<lle-bout>I havent been checking out builds for them because I didnt know where to find information easily for them
<rekado>lle-bout: I can confirm this.
<lle-bout>rekado: confirm what?
<lle-bout>the ungoogled-chromium issue?
<rekado>lle-bout: the root of ci.guix.gnu.org doesn’t even begin to render on chromium
<lle-bout>rekado: ah yes, well I think it may be due to fonts or image parsing
<lle-bout>or maybe JavaScript
<lle-bout>not sure what the last changes to Cuirass are
<cbaines>lle-bout, I've just started the script to queue core-updates builds, you're welcome to add more hardware, although I'm still working on tracking what builds are taking place
<rekado>frustrating that chromium just craps out like that
<rekado>no info in the dev tools
<lle-bout>rekado: debugging tools are also intertwined with Google infrastructure and automatic crash telemetry I think
<lle-bout>so it's non-trivial to actually use without privacy invasive things
<lle-bout>mbakke was trying to enable them the other day
<lle-bout>cbaines: okay! thank you!!
<lle-bout>rekado: I have been thinking of packaging Librewolf: https://gitlab.com/librewolf-community/browser/arch/-/blob/master/PKGBUILD - what do you think?
<lle-bout>I am not sure I can tackle this alone
<rekado>I prefer not to touch browsers.
<lle-bout>rekado: what do you mean?
<rekado>there is much sadness in packaging them.
<lle-bout>rekado: I see well..
<lle-bout>I'll try to tackle it alone then, maybe you can use Librewolf instead of ungoogled-chromium then
<lle-bout>At least, I would
*rekado uses icecat
<lle-bout>rekado: I see :-)
<jackhill>lle-bout: rekado: are we collecting pages ungoogled-chromium doesn't handle well? I think I may have found one: https://git.hcoop.net which, uh, as far as I know doesn't have anything wierd on that page.
<lle-bout>jackhill: yes.. gitweb seems to crash, also sourceware and qemu gitweb pages make it crash
<lle-bout>It's surprising how ungoogled-chromium never crashes for me on various really crappy sites but crashes on like gitweb or cuirass who are the most minimalist sites ever
<jackhill>I know right? of all the things…
<rekado>I only rarely use chromium for pages that don’t work correctly in icecat (what a sad thing to write in 2021), and I’ve only see it crash for the very first time today on ci.guix.gnu.org
<rekado>but I see now that it also crashes on git.elephly.net (which is just gitweb)
<pkill9>rekado: if you want to package browsers that don't make you feel sad, package gemini browsers :)
<genr8_>I finally figured out my "filesystem corruption" error
<genr8_>turns out to be caused by the NVME controller type on virtualbox . switching it back over to AHCI fixes it.
<genr8_>it manifests as "make: stat:Makefile: sterror: unknown error" (whenever it tries to run a gzip usually)
<genr8_>highly unusual and its driven me in circles for days
<lle-bout>genr8_: I see..
<rekado>genr8_: wow, glad you figured it out!
<rekado>this was very puzzling
<genr8_>yes! indeed
<rekado>I didn’t realize you’re running Guix inside of VirtualBox (did you mention that back then?)
<genr8_>not exactly. i said a foreign distro - Devuan VM
<genr8_>it never occured to me the hypervisor was causing it
<genr8_>i mean, i checked basic stuff like, is the cpu detected right, is it in KVM mode, that kinda thing
***jx97 is now known as jx96
<genr8_>ive learned a lot in the process of re-installing like 9 times, including why theres so many dependencies for the "hello" package
<guixy>hello there
<guixy>I'm trying to use w3m on tty1. Is there anything I need to do to make it show inline images?
<lle-bout>guixy: tty1 you mean the Linux kernel console? I don't think it supports rendering images in that console.
<guixy>Someone was able to do it with Arch and Kubuntu. https://www.reddit.com/r/archlinux/comments/izkxhe/tty_woes_no_scrollback_no_images_in_w3m/ https://askubuntu.com/questions/387678/how-to-enable-display-of-framebuffer-images-e-g-in-w3m-fbi-within-byobu-pts
<guixy>I already checked, I'm in the videos group.
<guixy>video
<leoprikler>btw. I had some interesting troubles today – stopping xorg-server through herd also stopped all of my ttys without a way of getting them back
<leoprikler>is this expected? did anyone else experience this?
<guixy>I think I experienced something like that in the past. Did you stop it from a tty or from a graphical console?