<lle-bout>It's using them that reveals to be a problem <lle-bout>Maybe you mean that we could have GCC-10 in bootstrap binaries for powerpc64le-linux-gnu <mbakke>we should ask janneke about it, but I don't think it will be a problem <lle-bout>I'll try right now, but there's chances between gcc-5 and gcc-10 during commencement.scm there will be quite some code to modify <lle-bout>mbakke: it would simplify things a lot, I expect <mbakke>lle-bout: core-updates is still on GCC 7 though, we haven't switched yet (but it should be just a matter of changing the 'gcc' and related variables) <lle-bout>GCC-10 is the first version where all things compile with default settings on powerpc64le-linux-gnu <mbakke>it also has some neat defaults for ARMv8.1 AIUI <lle-bout>mbakke: I tried making GCC-10 default and AFAICT some patch fails to apply <mbakke>lle-bout: oh, maybe the cross-environment-variables patch? <mbakke>lle-bout: feel free to try porting whatever patch is required! otherwise I will look into it in the coming weeks (but can't guarantee more success with that patch) :-) <lle-bout>mbakke: I'm trying to do everything I can, I was so happy to merge something that worked but unfortunately core-updates is already on glibc 2.32 so it fails... <mbakke>I hope that a GCC 10 native bootstrap for ppc64le can bring an end to the troubles :-) <mbakke>so first we need a native GCC 10, then fix any cross-compilation issues, and then patch make-bootstrap to use GCC 10 on ppc64le, IIUC <mbakke>and then actually create the tarballs and update (gnu packages bootstrap) accordingly <mbakke>that means another round of reproducibility testing (GCC 5 was the problem last time?) <lle-bout>mbakke: yes gcc 5.x wasnt built reproducibly by gc 7.x <mbakke>let's see how GCC 10 fares against GCC 10 :-) <lle-bout>mbakke: that might be our solution to reproducibility problems.. <mbakke>at least it should be easier to get upstreams attention if there turns out to be a problem still :-) <mbakke>on a related note, I wonder how far off GCC 10.3 is <lle-bout>erhmm package transformations being.. hungry <lle-bout>$ ./pre-inst-env guix build --keep-going -M 1 --with-input=glibc=glibc@2.31 --target=powerpc64le-linux-gnu bootstrap-tarballs <lle-bout>Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <lle-bout>mbakke: yes it was the cross-environment patch failing <fnstudio>hi all, guix on a foreign distro here, i get this unexpected behaviour when using bc <fnstudio>my foreign distro's bc runs ok, but the one i get from guix, well the arrow keys don't seem to work finr <fnstudio>instead of moving the cursor back/forth/up/down, i get this unexpected key codes, eg `^[[A` <fnstudio>the foreign distro and guix both give me the same bc version <fnstudio>(unless there's any difference in the way bc gets compiled) i would assume the problem is not really with bc... rather with the way my cli environment is set up under guix? <lle-bout>fnstudio: what's your TERM env variable like? <lle-bout>fnstudio: try setting it to: xterm-256color - does it work better? <lle-bout>when setting, I mean in your shell, not just for bc: export TERM=xterm-256color <fnstudio>lle-bout: hm, well, no it doesn't seem to be a temporary thing, it's been there for a while <lle-bout>if you get rid of tmux in the mix, does it work? <fnstudio>could it have anything to do with bash vs sh? <lle-bout>I have no idea of the cause, just throwing what I'd do in your situation, it seems related to termcaps or term compat things though <nckx>fnstudio: This is because Guix's bc is built without GNU readline, whilst your distro's bc probably is. <nckx>I don't know. Probably because ‘nobody’ uses it interactively? 😉 It adds only 7 MiB, so it should be fine to add it. <lle-bout>nckx, fnstudio: it is built with readline it seems <lle-bout>it doesnt have readline in inputs though <nckx>You just asked me not to? <nckx>Note that it's a core-updates patch, it won't help fnstudio straight away. <ryanprior>Where should a bignum library live? maths.scm? <lle-bout>nckx: well you've made it so now do it :-) - I'm just interested in having commit access and need to bump my merged patch count honestly.. <nckx>lle-bout: That's how I interpreted ‘let me submit’, and I'm fully behind you gaining commit access, so please do. <nckx>I thought this might be my first ever use case for the fabled ‘package transformation options!’ but it looks like they only allow replacing pre-existing slots with pre-existing packages? Is that really true? That would be strangely limiting. <nckx>I'd love to tell fnstudio to just ‘guix install bc --with-input=readline’. <lle-bout>nckx: what about $ guix install bc --edit <lle-bout>so you can edit a temporary copy of the package definition as you like <lle-bout>or is it not good to do it like that? because updates? <nckx>Hum. I'm personally unenthousiastic about encouraging such a workflow in our UI. 😉 <nckx>But indeed, package transformation options are stored, this would not be, which could make things even more confusing. <lle-bout>nckx: why did you say it was a core-updates patch? bc is a dependency to many other packages? <nckx>lle-bout, fnstudio: You can do something like guix package -e '(use-modules (guix packages) (gnu packages algebra) (gnu packages readline)) (package (inherit bc) (inputs `(("readline" ,readline))))' <nckx>I admit that's not exactly pretty either. <nckx>lle-bout: Yes. Much more depends on it than you'd (well, I'd) expect. I thought it was just Linux being silly. Check out ‘guix refresh -l bc’. <lle-bout>nckx: ah.. but they depend on it during build correct? <lle-bout>nckx: I don't use git send-email at the end, I just use format-patch and my regular email client GNOME Evolution <nckx>lle-bout: Thank you. s/albegra.scm/algebra.scm/. I don't think the commit message is really needed but now I'm just nitpicking. Guix commit messages tend to be less chatty. <nckx>lle-bout: As long as patches can be easily extracted from the mail (no .patch.gz nuttiness) & apply with ‘git am’ do whatever you prefer. <lle-bout>ryanprior: your question got ignored, what is the difference between algebra.scm and maths.scm? <nckx>lle-bout: And I'd already pushed it 😛 <ryanprior>"Small portable multiple-precision unsigned integer arithmetic in C" <ryanprior>I'm about to send a patch, so if maths.scm is not the right place somebody say so +D <nckx>ryanprior: Sorry, I missed your question as well. I'd say maths. <lle-bout>what's the policy in general? do we package libraries even if no other package uses it? <ryanprior>Right now it's vendored in but I'm working on digging those vendored sources out of there. <lle-bout>ryanprior: I was asking not for you but also me :p <nckx>ryanprior: Thanks. Burn them all. <ryanprior>I'm working on updating it to the 1.30 release right now <lle-bout>technically, socially maybe the community isnt resilient enough <lle-bout>nckx: about security patches maintenance burden, is it OK if some packages go unmaintained inside GNU Guix repo without "refresh" handlers? <nckx>lle-bout: That's fine. A significant portion of packages isn't covered by ‘guix refresh‘ (there is/was a command to list the coverage but I forget what it was). OTOH, I update quite a few packages and never use ‘guix refresh’, so... <nckx>lle-bout: Oh, the coverage is just part of guix refresh --list-updaters output. <nckx>So it's not bad but ~1/4 of all packages don't have a refresh ‘handler’. <guixy>I saw guix publixh can now --advertise. When will that option be configurable for guix-publish-service-type? LIC such an option wasn't documented... <lle-bout>nckx: how do we do to be reminded of updates then? It's got to be very troublesome to check them all individually <lfam>I'd say that `refresh` doesn't offer that much help for security updates. The bulk of the work is learning that there is a problem and what the fix is, and usually we'd like to deploy the fix before there is a new release upstream <nckx>guixy: You'd add ‘--advertise’ to ‘extra-options’. A separate (advertise? #t) switch is pretty but not strictly required to use the feature now. <nckx>lle-bout: I subscribe to a lot of lists/forge notifications/... <nckx>I also have some proprietary (because they're embarrassingly bad) bash scripts to help me. <nckx>One Day™ I'll port them to Guile and dare share. <lfam>I have organic heirloom shell scripts for updating linux-libre <lfam>One day it would be nice to let `guix refresh` do it <nckx>I agree with lfam about CVEs and such. I much rather get a mail from upstream that rely on some opaque tool. <lfam>Some upstreams are good about issuing new releases in response to security problems, but many of them rely on distros to cherry-pick some patches <nckx>I want to love guix refresh more than I do, really. But there's no spark and it sits there unused. Sorry, freshy ☹ <lfam>I do feel motivated to add the kernel refresher. I just need to find the energy <lfam>The energy to learn how to add it, that is <lle-bout>shouldnt we try and add update notification to Guix Data Service? So that it could run ad-hoc scripts even the ugly ones? We don't care after all, they're not the reliable part of the system. <nckx>First you write a Guile IRC client library to connect to #linux-libre, then sniff out the New Kernel Alerts. Simple. <mizukota[m]>"guix pull; guix package -u" does update and save from CVEs when updates are packaged, what else do you need? <nckx>*** guix-refresh has joined. <nckx>mizukota[m]: Damn it! I've been doing updates the hard way for all these years! <guixy>nckx, --advertise is an option for guix publish correct? guix-publish-daemon does not have extra-options. <nckx>(mizukota[m]: Not sure if joke, if not: guix pull bring updated packages to ‘users’, but we're discussing the actual updates to the Guix repository after an upstream release/security patch.) <vagrantc>whoah ... guix publish --advertise sounds suspiciously like more build dependencies for guix ... *vagrantc keeps watching the goal posts shuffle around <nckx>mizukota[m]: Someone has to hunt down those patches & bump those versions & check those hashes & build the result before pushing them to everyone. <vagrantc>yeah, and so's guile-ssh, but try building without it <lle-bout>vagrantc: GNU Guix is an extensible monolith, that's a given <vagrantc>nckx: may as well have sneek do it. pretty obedient <nckx>guixy: Oh, you're right, I conflated the two. <nckx>guixy: I wonder how the early adopters adopted it. <nckx>vagrantc: What could go wrong! <mizukota[m]><nckx "mizukota: Someone has to hunt do"> how guix refresh helps you with that? <vagrantc>why does my kernel keep emitting "WARNING: /dev/botsnack running low"? <nckx>guix refresh polls about 75% of supported package upstreams for new upstream releases, so you know there was one, without subscribing to 16,000+ mailing lists. <nckx>It can even update the version & hash for you if you run it from a Guix git repository, with ‘-u’. <vagrantc>i've often wondered if you couldn't add some metadata to the package for things guix refresh doesn't support at the moment <lle-bout>lfam, nckx: I tend to think the only way to be up to date with security patches is to get the latest version. <mizukota[m]>i thought it's like `guix pull` but without undoable local repo update <vagrantc>e.g. a phase for guix refresh to call, to give you arbitrary flexibility with updating <lfam>lle-bout: Yes, but I was talking about when upstream doesn't make a release quickly enough. <nckx>lle-bout: I don't disagree but don't understand why you say that. How else? But: too often security patches are released before a new, er, release. <nckx>vagrantc: I'm jaded so that sounds like more janitorial work to me, not less. ☺ <lle-bout>I mean that some distros freeze versions and apply security patches as they find them but I think it's too easy for a dev to fix a security issue and not tell anyone in the commit history <lle-bout>you might not even realize you did it as a dev <lfam>Sorry, I missed the beginning of this discussion so I'm not sure what's really being talked about <nckx>lle-bout: Guix always updates to the latest version when possible. <mizukota[m]>wait but what you have to specify in package recipe for checking latest upstream version? <lle-bout>re metadata packages for guix refresh: Big yes! <lfam>In general, "security" as a property is not so easy to describe or identify. We assume that every upstream release fixes bugs, and many bugs can be considered security bugs, so every release includes security fixes <nckx>A known CVE will change some parameters (like do we bother grafting, or will I spend my free evening fixing broken dependents). <vagrantc>nckx: the biggest check that i find doing manually is having to verify the signatures on upstream tarballs a bit tedious <nckx>But you can never assume that a new release doesn't contain security fixes. Linux is a prime example. They always do. <lfam>And security breakages! :) <nckx>mizukota[m]: It's based on upstream URL. E.g. there's a ‘cpan’ updater than recognises all CPAN URLs and knows how to query the service for any newer versions. <lle-bout>Most software projects are hosted on git <lle-bout>As a first metadata we could try regex on git tag names for version updates in guix refresh <nckx>ryanprior: You can use gexps though! <guixy>What is published by the guix publish daemon? Is it generally anything in the store? <nckx>ryanprior: See 0ad-data for an arbitrary example. <ryanprior>Is there a billiards shot by which I can refer to inputs via gexps? <nckx>No, because the source and the package are completely separate derivations. They're not different steps in the same build. <ryanprior>Got it, I moved that logic out into a build stage. <vagrantc>lle-bout: all the permutations are why i think you might want some hand-crafted things ... e.g. URL and a pattern <nckx>ryanprior: Just curious: why wouldn't a gexp suit your needs? <ryanprior>I don't know for a fact that it wouldn't, I guessed based on what you were saying about those being completely separate. <vagrantc>lle-bout: e.g. vX.Y.Z vs. release-X.Y.Z vs. other arbitrary release schemes <lle-bout>vagrantc: I don't understand what you're referring to exactly <vagrantc>lle-bout: a generic updater to match against upstream release tags? <nckx>ryanprior: If you need to run a tool that just happens to be in the package's inputs as well you can just refer to the tool (like 0ad-data does with unzip; unzip might or might not be an input too, I didn't even check, it's irrelevant). <ryanprior>I snipped out the tiny-bignum vendored source from vlang and then I was going to patch vlang's source right there in the snippet, because it hard-codes the path to the vendored source. <nckx>Remind me what ‘vendored’ means again. <ryanprior>It means that vlang copied tiny-bignum's source code into their own tree. <vagrantc>grab stuff from random upstream project and pretend it's yours? <lle-bout>vagrantc: yes, in guix refresh, but bruteforce common patterns or add metadata keyword argument to specify pattern (some common patterns could be available as variables) <ryanprior>They don't pretend it's theirs (and that's not a normal connotation of vendoring) <nckx>ryanprior: Ah, so you'd be embedding /gnu/store paths into the source tarball? That could probably be done but it's evil and a phase is the right choice. <lle-bout>another issue is that we don't get everything from git, some times it's available on git but we fetch tarballs instead <ryanprior>nckx: oh I didn't realize it's evil? What's the deal, how come? <vagrantc>lle-bout: in debian there's uscan, which does this sort of thing <nckx>It's due to what you're *doing* with the ‘input’/gexp (writing it's sekrit hash to disc) rather than the fact you're *using* it though. <lle-bout>so metadata would need to specify git url as well.. <vagrantc>well, you could probably infer that from (source (origin (method git-fetch) ... <lle-bout>vagrantc: I was saying when it's uri-fetch but project also has git <lle-bout>that somehow we couldnt check versions with the uri <mizukota[m]>but dependencies can change, url can change, git repo can change... <lle-bout>the uscan thing seems to go one directory up and check <vagrantc>could also check for patters in the URI, though <vagrantc>mizukota[m]: it doesn't have to be perfect to be useful <lle-bout>some cdns don't have directory listings I guess <lle-bout>mizukota[m]: each update requires manual intervention and testing of course <lle-bout>the fact that it builds and tests after update is a pretty good sign already <lle-bout>vagrantc: patterns in URI yes but you need to list available versions, you can't just guess the new one <nckx>ryanprior: Do any patching of /gnu/store file names into the source tree as a build phase, never in a snippet. So what you're doing now is good. <mizukota[m]>horray! Just 7 hours of guix system disk-image and I almost have livecd with vanilla linux kernel, custom kernel module for my hardware and xfce for installing <vagrantc>lle-bout: agreed. it won't work in all situations ... hence why i thought there could be a few extra flags used to handle those cases <vagrantc>lle-bout: or at least tell the tool options to search for new upstream versions <lle-bout>I want to try and contribute these generic updates if they don't already exist <ryanprior>It still seems chaotic to me that the source tarball in the store references non-existent files. <nckx>If false positives were guixcoins you'd both be very rich soon. <lle-bout>forge based updater (e.g. git tag) and regex on directory listing one directory up <lle-bout>also new keyword argument for package metadata <nckx>ryanprior: Ideally, it wouldn't, but a GC-invisible /gnu/store reference in the .tar.xz ‘source’ tarball is much worse. <lle-bout>keyword argument or just "field", not sure what they're called <vagrantc>lle-bout: sometimes there are crazy things like example.org/PACKAGE/MAJORVERSION/PACKAGE-FULLVERSION.tar.gz <vagrantc>nckx: i'm already rich with artisinal hand-crafted mistakes, why not automate some of it :) <nckx>lle-bout: (record (field foo)) - (procedure-call #:keyword bar) <lle-bout>(package (refresh `(#:git-tag-regexp "^v(P<version>.+$"))) ? <vagrantc>heading out ... always fun here in #guix <nckx>lle-bout: You're assuming that the next release will follow that pattern. <mizukota[m]>if a manual intervention is still required, why is this needed? You still need to check upstream, its dependencies, tests, sources. Such complex constructions look overengineering if their only use is to update url and hash and to notify about update <nckx>If it's opportunistic, it shouldn't be part of the package record. Just a list of common regexes hard-coded in the ‘guess’ updater. <nckx>Most projects don't have tag naming rules in practice, ‘v1.0’ → ‘1.1’ is quite common. <nckx>So IMO ‘I saw package-foo use a v in the past’ isn't valuable information to add to the package record. <lle-bout>that and check manually I much prefer that <lle-bout>nckx: you could have a list of default ones and a way to add more? <mizukota[m]>i think it should be some third-party package instead of being part of guix package <nckx>Why add more at the package level? <nckx>Why not add it to the general list? <lle-bout>nckx: at some point checking all the regexes on all packages might get a bit heavy I suppose <lle-bout>mizukota[m]: GNU Guix already has a facility for this, GNU Guix already has many functions, it's designed as a system, not a tool, at this point. <nckx>To me it feels like you intuit how many false positives this will generate, and hope to work around it by adding smaller ‘well we've seen format x’ fields for many packages. But these fields will grow over time, the false positives will return, you'll have more false negatives, and the fields will become a maintenance burden themselves. <nckx>Note my personal bias here: I don't use the updater so go nuts adding as many ‘best-effort/guess/regex’ updaters as you want, but I read packages every day and will fight IMO noise where I can 😉 <nckx>On matching all regexes to all URLs being heavy: I don't think it's computationally significant. I mean, look at how ‘guix refresh --list-updaters’ prints its output: this is not intended to be an instant tool. <nckx>(The coverage is calculated live, which is cool.) <nckx>lle-bout: It would be interesting to break down the current distribution by looking at the commit field of all packages with a git-reference source URI. See how many weird schemes there are in the wild. *nckx ought to go to bed before the clock strikes 4:00... Good night all. <ryanprior>I tried doing `guix build --check vlang` and it just spits out the current build hash <lle-bout>ryanprior: Maybe: guix gc -D $(guix build vlang) <lfam>ryanprior: `guix build foo --check --no-grafts` <lfam>Otherwise it just re-does whatever grafting operation if the "built" package <lfam>I mean, "whatever grafting operation is the 'built' package" <philipper905>I'm trying to add an emacs package to guix and I get an error I can't make sense of <ryanprior>s is the name of an emacs library (called emacs-s in guix) ***iyzsong-- is now known as iyzsong-w
<dissoc>is it possible to add channels to config.scm file rather than ~/.config...? <slimjim>question about library search path for sqlite extensions; I've installed both sqlite and libspatialite into my default profile. Spatialite is an sql extension module that lets you work with geolocation data, similar to postgis with postgresql <slimjim>when I launch sqlite3, ".load mod_spatialite.so" fails, but ".load /home/slimjim/.guix-profile/lib/mod_spatialite.so" succeeds <slimjim>it requires a full path, neither ~/.guix-profile... nor $HOME/.guix-profile work <slimjim>so does anyone know what it might take to get the sqlite3 guix package to look in the '/lib' directory of the active profile for extension objects by default? <slimjim>(possibly relevant, this is a foreign distro install on top of ubuntu 18.04) <slimjim>if I do ```export LD_LIBRARY_PATH=$HOME/.guix-profile/lib``` before launching sqlite3, I can load it by basename only. So I guess question is, can things like sqlite be set up in GUIX to be wrappers that automatically set variables like LD_LIBRARY_PATH before launching the binary? <philipper905>I'm making a package for maxima.el and for it to work properly I still need to type in (require 'maxima) because it seems the autoload system doesn't take care of that. <efraim>dissoc: I suppose one option would be to create a channels.scm that gets placed in /etc/guix/channels.scm, but I can't immediately think of anything like what you're looking for. <wleslie>I made a change to (gnu build cross-toolchain) and now my entire world is recompiling <sneek>civodul, you have 1 message! <sneek>civodul, chrislck says: how to remove unbound-variable new between 3.0.2 and 3.0.4 <civodul>g_bor[m]: i see zimoun sent an updated patch for the Outreachy blog post <civodul>i guess you can push it whenever is convenient for you <civodul>we just need to adjust the "date" in the header before pushing <efraim>oops, wrong window with up arrow <wleslie>it's right there to the left of the space bar <wleslie>my cross gcc is including headers in /usr/include <divoplade>I have a M-x key on the right of the keyboard, just next to the control key <civodul>efraim: is it a functional PM? i remember seeing a demo to make a super fast tool <efraim>civodul: I was about to answer that it seems to function well ;D <efraim>seems not actually functional, just very fast <efraim>I've been following some of his blog posts, and I like how he speeds up the library searching speed by symlinking the linked libraries into his packages' %out/lib <efraim>looking at guix strace logs we're looking in potentially dozens of paths until we find a shared library, worse if it doesn't find it <civodul>that doesn't explain the package manager slowness anyway ;-) <civodul>"distri uses images instead of archives" <jas4711>hi! unattended-upgrades.log contains plenty of ANSI sequences making it quite unreadable -- how to disable it? <civodul>hi jas4711! i guess that's a bug in part of the UI, which forgets to check whether it's writing to a tty <raghavgururajan>divoplade, wleslie: The keyboard doesn't have system keys (windows logo) and application key (menu logo). <abcdw>civodul, Can you remind the name of service for managing secrets, please? I remember you mentioned it on guix day, but do not remember how it called. <civodul>but you can find it next to hurd-vm-service-type <mizukota[m]>this builds iso fine, but on boot I get kernel panic about not being able to mount unknown-device block 0,1. As you can see, bootloader and file-systems are exactly same as in default installation-os, image has been built using guix system disk-image --image-type=iso9660 --verbosity=666 ./install2.scm <mizukota[m]>(and written to usb using dd if=/path/to/iso of=/dev/sdb bs=8M status=progress) <mizukota[m]>oh i forgot to mention, this install2.scm file should be placed near install.scm of guix git repo (gnu/system/install.scm) and nonguix repo should be installed to ~/.config/guix/channels.scm <mothacehe>mizukota[m]: that's probably related to the initrd you are using but we cannot discuss it further here as you are using the nonguix repo. <mizukota[m]>is nonguix repo discussion forbidden in guix channel? How do you install guixsd on real hardware then? <abcdw>civodul, secret secret service) got it, thank you. <mizukota[m]><mothacehe "mizukota: yes it is, please read"> I read it and i dont see why dont i have freedom to also use unfree things, especially if I already have hardware that is not open-source and i cant afford new open-source hardware which is not cheap <mizukota[m]>it only says that guix itself only contains free and opensource things and even deblobs the kernel <rekado>mizukota[m]: you have the freedom to use whatever software you want, and Guix makes it easy via channels. But we keep nonfree software discussions outside of this official channel. <mizukota[m]>I understand. So is there some hidden unofficial channel where this discussion can go? <lle-bout>mizukota[m]: please refer to the projects in question, they may have their own discussion rooms <mothacehe>yes I saw it, as Cuirass missed around 1 day of evaluations, it may be normal. I'm inspecting the derivations in sqlite right now. <rekado>civodul: I love your work on the ld.so cache <rekado>I feel wholly inadequate to review it, though. glibc patches weird me out. <rekado>civodul: in glibc-dl-cache.patch you write “static const char store[] = "/gnu/store";” — should this not be “@STORE_DIRECTORY@”? <dannym>Ok, just a heads-up, I will be merging the largest (in rebuilds) part of Raghav's work to guix master in an hour or so <dannym>It has been tested on wip-desktop, and on my local laptop--seems to work fine <civodul>rekado: oh you're right, that's a leftover from testing *rekado sees “Collect Unused Guix Items” in Gnome’s “Low Disk Space” warning for the first time :) <rekado>hmm, gitlab enters a loop in icecat; “Checking your browser before accessing gitlab.com.” <rekado>works fine in ungoogled-chromium <civodul>yeah i have troubles with gitlab.com too <kisaja[m]>hello all, what are the ways to install rtl8xxxu realtek wifi driver *guix-vits it feels like on ask.fedora today. <civodul>rekado: i'm glad you looked at the ld.so.cache patch <civodul>probably i'll merge today if there's no more feedback <lle-bout>kisaja[m], Most drivers probably like the one you are mentioning are included in the linux-libre kernel, however linux-libre does not include nonfree firmware. If something does not work then it's probably the cause. GNU Guix does not endorse proprietary software or firmware and therefore does not include them in the official repository. You will have to look elsewhere. <kisaja[m]>i bought this usb wifi adapter because of the free driver, i just believed that network-manager would show it as a device, will check the normal way ) <lle-bout>kisaja[m]: also in dmesg (as root) output do you see anything about firmware not being loaded? <lle-bout>It could have free driver but still require nonfree firmware. <rekado>uhm, pandoc-citeproc fails to build now <kisaja[m]>dmesg says missing free firmware, reject firmware deblobbed, fatal failed to load, rtl8xxxu probe failed with error -11, registered new interface driver rtl8xxxu <kisaja[m]><lle-bout "So you're on your own!"> wikipedia comparison of wifi cards says it has free firmware <rekado>ghc-yaml does miss its static libraries <lle-bout>kisaja[m]: there may be built in ROM that include nonfree firmware by default (therefore the OS does not need to load it) - but in that case it should be working for you already. <lle-bout>kisaja[m]: Maybe the linux-libre patches could obstruct that mode of operation from working, try asking in #linux-libre <rekado>how can I use the Guix Data Service to figure out when ghc-yaml started failing? <rekado>hmm, I haven’t been able to find this URL by clicking around; thanks <civodul>i usually check my browser history :-) <rekado>I’m surprised to see so many ghc-* packages have changed since d482954c99720e5b166400d7b42204ddbf94412e <rekado>I don’t know how to best bisect things so I just used guix time-machine --commit=d482954c99720e5b166400d7b42204ddbf94412e -- build ghc-yaml <rekado>but it resulted in lots of ghc-* downloads, so between this commit and today something must have affected quite a few ghc-* packages <civodul>rekado: that's something the Data Service should help explain <wleslie>this line is within an ifdef to check the macro is defined <rekado>this looks relevant: 2a659af50c8a5e3113337b503339ce797b966e1e <rekado>gnu: libyaml: Do not build static libraries. <rekado>all the rebuilds probably come from changes to ghc-quickcheck on “staging”, so that’s not unexpected <wleslie>I figure I should get capros running before messing with the new stuff <lle-bout>authenticated smtp wont work in git send-email while it works in GNOME Evolution. Sad. <jlicht>kisaja[m]: I've had issues with a similar chipset, where there were several revisions of the exact same dongle that worked, and others' that didn't without nonfree firmware; make sure the ID's in `lsusb` are exactly what you expect to see. <kisaja[m]>can i convince it that its rtl8192e and not rtl8192eu, to try if it works? <rekado>hmm, java-picard-1.113 fails to build :-/ <jlicht>kisaja[m]: I'm just the guy with obscure problems, not solutions. Sorry! <cairn>In the bootloader configuration section of the manual, when talking about terminal-outputs, it mentions it can take the value "morse" <dannym>Hmm, qemu-minimal tests consistently "fail" on armhf (native); I can't see what the failure is, though. Looks fine from the logs. <dannym>Then I tried, guix system disk-image novena.scm --without-tests=qemu-minimal <dannym>I get: guix system: error: without-tests=qemu-minimal: unrecognized option <dannym>Also, qemu-minimal is a dependency of grub-efi, and I don't need grub-efi there in the first place. Where does it come from? <dannym>(I have overwritten the operating-system bootloader to be u-boot-novena-bootloader of course) <dannym>MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} QTEST_QEMU_BINARY=alpha-softmmu/qemu-system-alpha QTEST_QEMU_IMG=qemu-img tests/qtest/boot-serial-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl --test-name="boot-serial-test" <dannym>ERROR boot-serial-test - Bail out! FATAL-ERROR: Failed to find expected string. Please check '/tmp/qtest-boot-serial-s6WFly8' <dannym>** (tests/qtest/boot-serial-test:19889): ERROR **: 11:47:48.690: Failed to find expected string. Please check '/tmp/qtest-boot-serial-s6WFly8' <mbakke>Cairn: if you follow the reference to the GRUB manual, it explains that it uses the "system beeper" <cairn>mbakke: Ah, sweet. I see that now. That's really interesting. <lle-bout>it seems I don't have the permission to close my own issues on debbugs <nckx>lle-bout: Everyone has permission. What did you try? <lle-bout>nckx: sending the commands identically as some other person did (and it worked) - my message didnt get appended to the thread publicly <wehlutyk>I'm looking into updating python-setuptools which is now version 50.3.2 (vs. 41.0.1 in guix), but dropped support for python 2 at version 45. What would be the recommended way of doing this? <wehlutyk>Keep an older version like python2-setuptools-44 for the packages that rely on python2-setuptools? <wehlutyk>(This in turn is for fixing python-keyring's way of declaring its version, as described here: http://issues.guix.info/44077#43 . It's simply a matter of including python-setuptools in the native-inputs, but keyring requires setuptools >= 42) <nckx>lle-bout: All public SMTP submission is either authenticated or broken, so git supports it just fine. Could you share your git configuration? <lle-bout>nckx: It worked unauthenticated heh but my ISP has odd setup <nckx>You can send mail unauthenticated through smtp.free.fr? o_O <lle-bout>nckx: yes, only when I use my ISP's network <nckx>What's odd about their set-up? <halfdann>I somehow ended up with a package that I can't delete. It probably came from an incorrect package definition from myself some time ago: `guix gc --referrers <pkg>` shows it has 1 referrer which is the package itself and `guix gc -D <pkg>` says it's still alive <halfdann>Any tips how I can go about deleting the package? <nckx>lle-bout: Try using smtpserverport = 587 instead. <lle-bout>nckx: filtering unauthenticated SMTP outside of ISP network <lle-bout>nckx: Port 465 is what my email client uses <nckx>lle-bout: But (start)‘tls’ on ‘465’ is a very odd combination. Did you copy the former as well? <nckx>Try ssl:465 or tls:587 (the latter connects, I tried it, just because your mail client uses the former doesn't mean it's the only option). <lle-bout>I don't see the difference between tls and ssl in the manual, I though they were aliases <nckx>I can't connect to port 465 using non-immediate SSL at all, but of course they might allow it for internal client traffic... <nckx>Using immediate SSL works. <lle-bout>nckx: I see.. unclear what the difference between ssl and tls is in the manual. Thank you. <civodul>mbakke: regarding grafts, i was wondering <civodul>grafts play a significant role on the overall performance <civodul>1st because they avoid redownloading/rebuilding tons of stuff (good) <civodul>2nd because they lead to many things being grafted locally, which takes time (bad) <civodul>to have the benefits while reducing the costs, i wonder if we could semi-automatically ungraft things in a branch <civodul>such that 'replacement' fields don't stay for too long <mbakke>we could perhaps relax rebuild limits for "ungrafting" on 'staging'? <civodul>because by definition ungrafting is "safe" as in it won't cause build failures <civodul>currently we have replacements for glib + dbus + libx11 + fontconfig <civodul>meaning that virtually everything gets grafted <mbakke>probably we can't get rid of libx11, curl, openssl and gnutls outside 'core-updates' as they nearly trigger full rebuilds <mbakke>but dbus, glib, fontconfig should be okay I think <civodul>beware of glib, you have to use -e '(@ (gnu packages glib) glib)' <mbakke>oh, fontconfig is also in the "full rebuild" range :/ <civodul>i guess the question is: should we wait for core-updates for things like that? <mbakke>yeah, maybe not, that branch almost always introduces breaking changes that can take months to fix <mbakke>so I guess a dedicated ungrafting branch makes sense <civodul>if we were able to build at full speed (ahem), we could perhaps build everything in a week <mbakke>maybe wait for the new OpenSSL :P <civodul>i don't know, would we pick all the packages we listed? <civodul>or just the "highest" two thirds or so? <civodul>intuitively i think it's kinda unavoidable to have grafts to GnuTLS & OpenSSL <civodul>whereas for the desktop/graphical stuff, it should be rare <civodul>so i'd definitely ungraft glib + dbus + libx11 + fontconfig <mbakke>I'd say why not, as long as they don't introduce many extra rebuilds <civodul>i'm busy with other things right now but i can create the branch later if nobody beats me at it! <civodul>some of these are already ungrafted in core-updates <civodul>so we'll be able to cherry-pick from there <mbakke>sounds good! I'm busy for some time as well. <mbakke>civodul: WDYT of also taking the latest "non-security" releases for GnuTLS and D-Bus at the same time? In theory they should be just as safe as ungrafting... <mbakke>actually GnuTLS 3.6.15 does contain security fixes, hmm. <mbakke>and dbus 1.12.20 has a "maybe security fix" (upstream words :P) <civodul>thing is, it should be easy, and if we go beyond ungrafting, it requires more mental work <mbakke>civodul: agreed ... maybe I should quickly add these grafts on 'master' instead :-) <jeko>Is there a recommended way to fully allocate the disk space when creating a disk image with guix system disk-image ? <jeko>otherwise I have to do something like that qemu-img convert -o preallocation=full <jeko>or qemu-img convert -S 0 <jeko>I may have missed something in the reference… <rekado>I used “./pre-inst-env guix pack --save-provenance pigx bash …” and I get warnings: “guix pack: warning: could not determine provenance of package bash” <civodul>rekado: that it cannot save provenance here because that info is unavailable <civodul>provenance info is only available from a "guix pull"d 'guix' <rekado>random thought: provide a blinkenlights curses interface for Guix to better show progress of concurrent builds <apteryx>bah... anyone else having issues with Chromium? It suddenly started using all my CPU and everything slowed down to a crawl in the middle of a conference, so much I couldn't rejoin after. <apteryx>even killing it and retrying would recreate the same situation. <mbakke>apteryx: have you enabled hardware acceleration? <mbakke>I've had trouble with previous versions, but the latest version has been solid through multiple conferences (on Wayland though). <guix-vits>anyone have troubles C-n past a page in emacs-pdf-tools? C-p works with continuous mode, but C-n do not. ***jess| is now known as jess
<apteryx>mbakke: not that I know! It's been a while I updated my user profile though, I'll do this now. <mothacehe> rekado: I deployed Avahi support on berlin build nodes, and would now need to restart berlin itself. Is it possible? <mbakke>FWIW I have not enabled HW acceleration since the switch to Wayland, and it's been pretty solid. <mbakke>mothacehe: isn't restarting guix-daemon enough? <mothacehe>mbakke: no rebooting seems necessary, not sure why though <mbakke>mothacehe: rebooting berlin needs special care due to the odd bootloader configuration, so we should wait for civodul or rekado <mbakke>anyway it should be possible to update the Shepherd configuration without a reboot, I know civodul has done some ninja tricks for that before :P <mothacehe>hehe let's wait for their inputs then, thanks mbakke. <apteryx>mbakke: thanks for the help, I'm ugrading now. I'm using the nouveau driver, on a desktop. <apteryx>Which pretty means OpenGL but no video acceleration at all. <civodul>mothacehe: "herd restart guix-daemon" should be enough <civodul>then you can "pgrep guix-daemon" to check it's running the right version <civodul>speaking of which, last time rekado had to reboot berlin, it failed to boot <civodul>so we'll have to take some time to investigate <lfam>apteryx: If it seemed to break when you started sending video, and your computer is not very powerful, it's probably not able to encode video in real-time <mothacehe>civodul: rebooting the daemon is sadly not enough. I'll try to find what's blocking then. <apteryx>mbakke: 'Use video acceleration when available' is enable in my Chromium <apteryx>I guess it's better to leave it off, knowing myself that no video acceleration is possible. <mbakke>apteryx: right, not using an intel system? <lfam>What videoconferencing platform is it, apteryx? <mroh>wehlutyk: my python-keyring 21.5 test build with setuptools 50.3.2 has a (broken) keyring-0.0.0-py3.8.egg-info. What am I doing wrong? <mbakke>apteryx: nouveau is actually blacklisted by chromium, but you can try to enable hw acceleration for nouveau going to chrome://flags and toggling "ignore-gpu-blacklist" <apteryx>lfam: that particular one was a proprietary cisco thing, but I've had issues with Jitsi too before. <lfam>It's almost certainly the lack of hardware accelerated video encoding <mbakke>last I tried nouveau toggling the flag made a world of difference, but Chromium also crashed when I tested a web game, so YMMV <mbakke>it could be that video encoding/decoding is stable though <apteryx>video acceleration can't make use of OpenGL, right? It's something different. My particular GPU doesn't support any video acceleration without blobs. <lfam>I'm not certain, but my understanding is that OpenGL is about "graphics" rather than "video" <lfam>Video acceleration is built-in to every computer from the last 10 years of so, but I'm not sure what it takes to enable it <lfam>Sometimes there are even multiple implementations in the same machine. I have a Macbook Pro with both Intel and Nvidia accelerators <mbakke>apteryx: can you try toggling ignore-gpu-blacklist and see if it makes a difference with Jitsi? <lfam>I'm installing ungoogled-chromium on my Debian system now to poke around <civodul>mothacehe: not enough in what sense? it's not running the right version of the daemon after "herd restart guix-daemon"? <zimoun>civodul: about Nix/Guix, do you imagine blog post or manual entry or cookbook entry? <civodul>zimoun: i was thinking about a blog post, which could eventually become a cookbook section if need be <mothacehe>civodul: The avahi-daemon does only register the "lo" network interface until the machine is restarted. I tried restarting the "guix-daemon" and "networking" herd services. <apteryx>That's why I'm pretty sure that I'm out of video acceleration, but I'll give it a shot for the fun :-). <mothacehe>Don't know why it cannot "see" the ethernet interfaces. <lfam>I'm not totally sure, but I don't think that Chrom{ium,e} can do hardware accelerated video on Linux at all <civodul>yeah weird it doesn't see the other ifaces <lfam>I think it's not a feature of the software <lfam>That all seems to be about decoding <lfam>I assume apteryx can decode video in real time, or they would have noticed already <lfam>It's the encoding that is really pushing the limits of most laptops <lfam>That's kind of annoying. I wonder if icecat can do it <lfam>I'm not really sure how browsers do this work. Maybe they offload in a way that can be accelerated. I don't think "encoding in the browser" was a mainstream use case until recently <mbakke>lfam: I think VAAPI also enables HW accelerated encoding, but even Intel GPUs require proprietary firmware for that to work nowadays. <apteryx>civodul: I finally managed to capture an strace log for 43518! <civodul>apteryx: 502 is cached by nginx, so you'll have to try again later <civodul>it seems to work when talking directly to "guix publish" on berlin <mbakke>lfam: I'm getting ~12% cpu usage when running 'guix environment --ad-hoc intel-vaapi-driver ungoogled-chromium -- chromium --user-data-dir=/tmp/test --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy' and going to https://meet.jit.si , I guess that would not be possible without some hardware assistance? <civodul>apteryx: perhaps you tried right when mothacehe restarted the daemon? <lfam>mbakke: It really depends on your CPUs <mothacehe>apteryx: I did that a couple times so, could be. <lfam>It also depends on if you are actually sending the video over the network or not (in a meeting or not) <civodul>apteryx: yes, i do think the 502 reply is still cached by nginx, but i'm not sure how long it'll take <civodul>the request clearly doesn't reach 'guix publish' <apteryx>interestingly --fallback doesn't seem to help; I think because it doesn't get passed to the offload machine. <mbakke>I did get an "unknown libva error" with that command, so maybe VAAPI was not in use at all :/ perhaps it does not work with Xwayland? *apteryx has another meeting; tries with IceCat this time, fingers crossed <apteryx>Which shepherd service needs to be restarted to have the users provisionned by guix-daemon created? <guix-vits>mbakke: the end of user? and the user has many ends: left and right arms, legs, ears, and much more. bottom benefits the most, i sure. but from whuom vitory was this benefication grown, from device or the distro? that's is a question (01:04)! <lfam>mbakke: I don't get that error on X. It seems to work fine here <apteryx>I just tested with Icecat; it also required quite a bit of CPU and the sound quality was worst than with ungoogled-chromium, but it seems to rely much less on writing files to disk. ***jmarsden_ is now known as jmarsden
<argylelabcoat>Thus far, the documentation for Guix has been rather good. But there are a few areas I feel are a little vague. <argylelabcoat>I'd like to debug a package definition ( scm file ) I'm working on, but I do not know how to attach the guile debugger <apteryx>OK, the guix-daemon extends the users via the activation service type. When is the activation service type triggered? <apteryx>The docstring of the activation-service-type says it occurs at boot time or at 'guix system reconfigure' time. <apteryx>so, seems if I was to reconfigure the machine the guix-service-type extra users should all get created. <apteryx>ah, I'm using 'guix deploy' to manage it. I think there was an issue about it not doing the activation. <lfam>argylelabcoat: It's good to hear this kind of feedback. You should get some advice if you wait a little while <smithras>I was looking at old forgotten issues after reading zimoun's email and I saw that this bug http://issues.guix.gnu.org/22952#4 is marked as open despite Ludo closing it way back in 2017. Is this a glitch on the website or is is actually still open? <lfam>smithras: The bug was reopened a couple weeks ago <lfam>I guess the issues.guix.gnu.org front-end doesn't properly handle this case of long-archived bugs being reopened <lfam>I advise to use the bugs.gnu.org site <lfam>I'll file a bug about this meta-issue <lfam>It's tricky to reliably do what <issues.guix.gnu.org> is attempting, because the debbugs database is not designed to be the back-end of another service. <lfam>Well, it's not correct to call it a database. If it was one, we wouldn't have any trouble <smithras>oh interesting, I didn't know about that <lfam>Anyways, thanks for helping deal with the bugs! It's really valuable for the project <smithras>yeah I'm glad I'm able to help! Although instead of closing bugs we opened a new one instead :) <lfam>New bugs are better than old bugs <apteryx>smithras: indeed, thanks for handling bugs! They're increasing... <lfam>I heard that debbugs might run out of numbers soon ;) <pineapples>I have a rather simple request to one of people with the commit access, that I think doesn't deserve a bug report, but I'll open one if I have to. Anyway, two directories must be added to XDG_DATA_DIRS after installing Flatpak to make applications installed by it discoverable OOTB <zimoun`>smithras: thanks for playing the game. :-) I have not carefully checked the URL about the forgotten bugs provided by issues.guix.gnu.org because I am using emacs-debbugs. ;-) Thanks for the report <zimoun`>lfam: basically the database Debbugs is plain mbox. IIUC. But corner cases could happen when parsing it. <argylelabcoat>lfam: you are welcome. I was hacking in Nix for a few months and I'm moving over to Guix since Guix supports armhf and I've got some hardware I need to develop for that falls into that category. <zimoun`>apteryx: yes, the number of bugs open per day is really larger than the number of bugs closed per day. We should set the rule: you are allowed to open a new report if and only if you first close one. ;-) <zimoun`>The GNU projects using the Debbugsinstance has created ~5000 entries in ~9months. Almost 18 new bug or patch per day. Hard to tell about Guix only; but I bet the big contributors to these figures are at least Emacs and Guix. :-) <nckx>Is the guix-days@ alias still needed? <zimoun`>nckx: well, it could be useful for the next event. I guess <bavier[m]>I was going to remark about not having a gcc-toolchain@10, but then noticed that the sorting on versions is not done with verscmp? <nckx>zimoun`: Sadly it's also a spam magnet. <zimoun`>crap! Because it appears explicitly in some webpage, right? <zimoun`>well, in this case, yes let remove it and recreate this alias or another one when we need it. WDYT? <nckx>zimoun`: I have no idea, I've had this address for years with no major spam problems, but somehow guix-days@ managed to make all the shitlists in the world in record time. I wonder why. <nckx>zimoun`: It would be nice if we could pause it, yes. <nckx>zimoun`: Can we remove/add such aliases at will without bothering gnu.org every time? <roptat>dropping a quick idea, to see if that makes any sense: when I debugged some ocaml reproducibility problems, I noticed filesystem ordering issues were hard to diagnose, and it was also hard to see when it was fixed because when it's present, the package usually builds reproducibly on the machine <civodul>nckx, zimoun`: we can comment it out if you want, we just have to log in to fencepost.gnu.org <roptat>so what I ended up doing was mounting a disorderfs on /tmp, and built the package a few times to make sure. Should we add support for building in a disorderfs when using --check? <charles`>Is this where I can ask questions about Guix system configuration? <roptat>there's also the mailing list help-guix@gnu.org if noone here has an answer for you :) <charles`>I have several questions. 1: The iso is just an installer, is there a way I can test it on my machine before installing? <jorge[m]>Hola,como llamo o invoco en guix a gnome ? <roptat>if you are patient, you can build a system image from an existing installation of guix (the package manager, on any distro, including but not limited to the Guix System) <civodul>jorge[m]: ¡hola! tienes que utilizar el terminal <civodul>jorge[m]: solo se puede utilizar GNOME en Guix System; no se puede hacerlo con Guix en otra distribución <jorge[m]><civodul "jorge: ¡hola! tienes que utiliza"> ya lo hice pero no lo ejecuta, yo uso guix <civodul>roptat: perhaps we could have a package transformation or something like that that builds a different derivation, but one that better excercises all these issues, with disorderfs, etc. <civodul>that'd be a good hack for a R-B meeting <jorge[m]><civodul "jorge: solo se puede utilizar GN"> yo uso guix system <roptat>civodul, I was thinking the filesystem was outside the scope of the derivation, so it would not be recorded in it (how could it?) <civodul>jorge[m]: entonces, ¿puedes escoger GNOME en el menú de "log in"? <roptat>I would simply mount /tmp/guix-build-... as a disorderfs and then start the build in the container in there <charles`>question 2: has anyone setup wayland with gnome? <jorge[m]><civodul "jorge: entonces, ¿puedes escoger"> no,lnstale solo mate <civodul>roptat: yes so we could either add special support in the daemon, as you suggest, or just leave the daemon unchanged and make a "user level" hack; it's a tradeoff <civodul>jorge[m]: cuando instaló Guix System, ¿escogió GNOME ademas de MATE? <roptat>oh, that would be in the daemon? not sure I want to change it ^^' <civodul>plus, in general, it should be a last resort <jorge[m]><roptat "oh, that would be in the daemon?"> no,solo mate <roptat>charles`, isn't wayland the default for gnome nowadays? not sure, because I don't use it... <roptat>and I'm not sure how it's implemented in Guix exactly *civodul pushes the RUNPATH hack <charles`>yes, but gnome on guix isn't latest, so it is still on xorg <roptat>oh, then I guess nobody uses gnome on wayland here <roptat>well, I'm not very knowledgeable about that part of the distro, maybe others know better? <roptat>civodul, what other issues were you thinking of? <civodul>roptat: oh actually, you can simply do something like you suggest: create a disorderfs somewhere, and run: TMPDIR=/path/to/disorder guix-daemon ... <charles`>I tried adding (service sddm-service-type <charles`> to %desktop-services. but I get error "service 'xorg-server' provided more than once" <jorge[m]><civodul "jorge: cuando instaló Guix Syste"> Yo intale guix system con mate despues instale enlightenment y hace poco gnome pero no se ejecutan desde el inicio. <civodul>jorge[m]: no es suficiente ejecutar "guix install gnome" por ejemplo <civodul>hay que cambiar el archivo /etc/config.scm y después ejecutar "guix system reconfigure" <jorge[m]><civodul "aquí hay un ejemplo con gnome-de"> gracias,voy a leer y hacerlo. <roptat>well, I'd love to be able to choose per-build if I want a disorderfs or not <roptat>charles`, you'll need to also remove the existing gdm-service from %desktop-services <charles`>I tried searching but, it is only used right there <charles`>I removed the existing (set-xorg-configuration ...) <zimoun`>civodul, nckx: I have no opinion about guix-days. It is useful for organizing but if it is a spam magnet, let turn it off for now and then reevaluate the position later when required; since it is only an alias on fencepost, IIUC. <apteryx>mbakke: chromium uses about 11% of my CPU too with your command <apteryx>(visiting meet.jit.si with video + sound enabled) <jonsger>apteryx: I guess thats due to missing hardware acceleration from your GPU with the codec used by Jitsi <apteryx>mbakke: oh wait, this was just the preview <apteryx>actually joining a test meeting uses much more than that <kisaja[m]><charles` "I removed the existing (set-xorg"> that fixed it? <civodul>zimoun`, roptat, nckx: i've now commented out the "guix-days" alias on fencepost <raghavgururajan>apteryx: Does the chromium's tab crashes few minutes after joining test meeting? <roptat>charles`, the (remove ...) part on the bottom of the example is the relevant part <charles`>It is really cool how the rainbow parenthesis highligh in the documentation online <apteryx>it uses about 45% of my CPU without video acceleration, or 22.5% with video acceleration (half!) <apteryx>that's good, for a GPU that lacks video decoding support. I don't know what magic it's doing. <charles`>roptat That look like it will work. I will try it when my iso is made <dissoc>for the httpd service it says to add virtualhosts in extra-config. i cant get it to work. is it supposed to be (extra-config (list (httpd-virtualhost ...)))? <jonsger>apteryx: GPUs shader units can maybe do video encode/decode better then a CPU, even if there are no special "ASIC" for encode/decode... <mbakke>civodul: did you figure out why the "devel" manual is not updating? <raghavgururajan>apteryx: My jisti experience on chromium got little better after I upgraded CPU microcode. <GNUtoo>hi, I was wondering something, during build Guix often patches references to binaries in the reguar path like "#!/bin/sh" in shell scripts, <GNUtoo>If you were to write a portable script that runs in Guix too, is there a way to refer to the interpreter? <GNUtoo>for instance "#!/usr/bin/env python" is probably not the best way <apteryx>mbakke: If I use the old chromium I had (version 86), with or without the hardware accel enabled, it was performing the same, at around 45% CPU usage. <civodul>mbakke: oops sorry; i ran it manually but then forgot to check the result <apteryx>so it seems the hardware accel has been fixed in the latest version <civodul>/gnu/store/799y72icf6na3fil660hmxhz88q1zi5a-guix-translated-texinfo.drv failed <apteryx>mbakke: that's your doing in fddc87063231f8f9aa22bbbc5bca4a46b9bbf004 it seems :-) <civodul>oh, the dreaded "map(PROT_NONE) failed" <mbakke>apteryx: nice :-) I think upstream has done a lot of GNU/Linux optimizations recently as a consequence of integrating the Igalia Wayland work <mbakke>currently 'ungoogled-chromium-wayland' is just a wrapper script over the regular ungoogled-chromium, whereas previously it had to be built separately <mbakke>apteryx: that commit is not entirely unrelated either :-) <mbakke>it was mostly fixing a regression <civodul>mbakke: i had to build guix-translated-texinfo.drv with -c2 and it passed <civodul>even though 98750a9d9967b84a077735a2e4e6d5526256a5fd was supposed to fix that already <mbakke>civodul: oh noes ... I wonder if we should revert back to libgc 7? <mbakke>we've hit a lot of strange edge cases since switching to libgc 8 <apteryx>mbakke: pretty cool, it feels much snappier <jonsger>mbakke: please not, there is no libgc 7 in Tumbleweed anymore... <mbakke>jonsger: you can use libgc 8 for the "system" guix and daemon though :-) <mbakke>but it would probably be better to fix libgc or guile, or whatever is causing these issues.. <mbakke>no idea how to start debugging GC issues in Guile <mbakke>apteryx: if it's stable for you, we can consider "unblocking" the nouveau driver <mbakke>wait, pixman update on 'master'? that does not sound right <apteryx>right, that would be cool! I can use it for a couple days just to make sure, but it seems fine so far <mbakke>oh boy, looks like we have to revert many of raghavgururajan's patches ***amfl_ is now known as amfl
<jonsger>they should go to core-updates or so, I guess <dannym>I thought so too, but ludo said months ago it would be better if they went to master slowly <dannym>Feel free to do something else with them--if possible, before gdm implodes entirely <jonsger>guix refresh --list-dependent gobject-introspection <jonsger>Building the following 2275 packages would ensure 5850 dependent packages are rebuilt <dannym>While we have perfectly good updates waiting :) <dannym>See the guix-patches mailing list <jonsger>dannym: still don't understand why we want to rebuild the world on master <nikita`>i wonder if i should just /dev/null all future bug tracker emails. i don't really have follow-up questions to emails i haven't responded to in 3 years, it's a bit very standardized to say "please message to reopen" <nikita`>good to see bugs getting closed though! <zimoun`>nikita`: what do you mean by “it's a bit very standardized to say "please message to reopen"? Since it is mainly that writes these closing emails. :-) <nikita`>sorry, german phrasing of mine doesn't transport me being humoured by this in a non-offensive way. what i mean is, people (probably also you) close bug tickets i have opened 3 years or more ago and i have no intention of reopening them <charles`>roptat It seems that using (remove ...) worked! thank you very much <nikita`>so being direct and not including this would be okay. i'm not annoyed, if it's what you need for routine, i'm okay with that <dannym>So with this new information, the patches cannot go to core-updates and cannot go to master, so what do we do with them? <dannym>Also, core-updates is broken in more fundamental ways, see my numerous posts about it. So it wouldn't do anyone any good anyway <mbakke>dannym: how is core-updates broken, and why can't it go there? <dannym>Meanwhile, guix from master didn't let me log into my computer, both before and after system rollback <dannym>While we have perfectly good updates for both gdm, and lightdm <dannym>mbakke: Ludo said (link see above) it would be better if they went to master and not core-updates <dannym>Also, I posted numerous mails detailing exactly where core-updates is broken <dannym>The most important one being bug 43986 <cbaines>If there are specific issues with core-updates, maybe we can tag them in debbugs <dannym>It would be good to process gnome updates in whatever means are best--if possible before no one can log into their computer any more <raghavgururajan>dannym: I think in one way or another, major changes to any of the influential pacakage, gonna cause some waves. <dannym>I can see that rebuilds are annoying (they totally annoy me); but unusable computer because of display manager bug long since fixed upstream is more annoying. So that's the tradeoff <zimoun`>nikita`: I am just typing a bit mecanically the message and it is appears to me respectful for your past time when you opened the bug. <dannym>raghavgururajan: It's a *GNOME* update; basically, everything that has a GUI that is not KDE uses it. Also, glib is used by most daemons, too. So yeah, updating those is totally gonna rebuild a lot <mbakke>I also had to revert 71b15b4874b7f9ec7001d2916a8ab27dcce6cdc0 from way back, which also triggered a huge rebuild <mbakke>I suppose no guix developers have pulled recently <mbakke>now GTK+ produces the same derivation as on 1.2.0 again <cbaines>Out of interest, what was the workflow for creating these "Update package definition" commits? It looks more like rewriting the package definitions from scratch in places? <mbakke>they also remove useful comments in some instances <mbakke>I wanted to remove some of those as well, but did not have time to bother with the merge conflicts <cbaines>The formatting changes add some noise. I just looked in to the "[license]: Modify." change for Wayland, and it does indeed look like the license did change at some point (5 years ago it seems!) <civodul>dannym: what is the display manager bug you're referring to? <mbakke>the formatting changes also break 'git blame' <dannym>civodul: gdm doesn't let you log into the computer anymore. See irc log from a few days ago (of me and of lispuser*) <mbakke>so they have some tangible cost, and in many cases I think the cosmetic changes are for the worse <dannym>civodul: gdm login screen would come up, then let you enter username and password, then after you press enter would fake-try logging in and immediately bring you back to the gdm login screen <cbaines>dannym, I use the GDM on my laptop, and I updated after I saw people were having problems, and it seemed to work for me. Maybe I got lucky somehow with my GDM state? <dannym>Another user on the ML also reported a gdm black screen loop before even getting the login recently <cbaines>I seem to remember there have been problems in the past with updating the GDM that were worked around by deleting state <mbakke>could it be another Mesa cache bug? <civodul>don't we wipe /var/lib/gdm on log in these days? <dannym>The only reason I can log in right now is because I finally removed gdm and replaced it by slim again <dannym>Btw I checked /var/log/messages back then and it doesn't say anything interesting, except that it couldn't start the session (also posted to irc) <cbaines>I think the GDM has it's own logs in /var/lib/gdm <cbaines>Although, saying that, I have /var/lib/gdm, but nothing in it <civodul>actually no, we don't wipe /var/lib/gdm <cbaines>ah, no, /var/log/gdm, I managed to check the wrong thing, I do have stuff in /var/log/gdm <cbaines>dannym, you might still have GDM logs as well in /var/log/gdm ? <mbakke>dannym: also check if you have any state at all in /var/lib/gdm <raghavgururajan>> cbaines: Out of interest, what was the workflow for creating these "Update package definition" commits? It looks more like rewriting the package definitions from scratch in places? <raghavgururajan>I am in the process of splitting patches. I think things would be clear after that. <dannym> /var/lib/gdm has only hidden files <dannym>fontconfig/ ibus/ libgweather/ mesa_shader_cache/ <cbaines>dannym, thanks, this is a Guix system right? I'm just wondering whether systemd-logind means elogind in this case <dannym>mbakke: Btw, I have pulled recently after the push, and guix weather reported 60% available on x86_64-linux afterwards <mbakke>dannym: the weather should be good again now, on 04b83678653fda3c66e600e88f54f5108290ec1c <dannym>I mean that weather was 60% after the patchset <mbakke>dannym: that's because the patchset triggered a rebuild of ~40% of the packages <mbakke>I have reverted those that changed the derivations now <dannym>That's a definition of "world" I wasn't previously aware of <mbakke>more like "couple of continents" i guess <mbakke>please check 'guix refresh' next time! <dannym>But jokes aside, there needs to be some way created to update glib, gobject-introspection, pixman and so on. <dannym>And the patchset was originally for core-updates, until someone rerouted it to master <mbakke>right, that's probably because there was another continent-rebuilding patch recently, 71b15b4874b7f9ec7001d2916a8ab27dcce6cdc0 <mbakke>in general, if the weather is below 80-90%, something is wrong <mbakke>I think civodul meant to push the non-rebuild commits to master <dannym>There were no non-rebuild commits in that patchset <mbakke>sure there were, I left some of them <cbaines>"Leaky bucket" might be the right analogy, I'm unsure, but what I'd like is some kind of refilling quota that each change pushed subtracts from <mbakke>even though I did not necessarily agree with them :P <cbaines>Each commit or group of commits would have a score related to the impact, so changing a leaf Ruby library => low, changing some input to ungoogled-chromium => very high <cbaines>You only merge patches when there's sufficient quota (so it doesn't go below 0) <dannym>mbakke: I meant that there were only patches that would rebuild a lot in bug# 42958. That's why it was marked core-updates. Why else? <cbaines>and you tune the rate at which the quota gets refilled based on observations on how quickly you can build things <dannym>And this set was from bug# 42958 <mbakke>dannym: some of the commits you pushed were not reverted *civodul just notices the big-rebuild commits ***wleslie is now known as m`wleslie`
<mbakke>civodul: beat you to it! there was one two days ago as well that we all missed <mbakke>took me about 16 minutes to track down :-) <nikita`>sneek: later tell zimoun`: I also do not intend to react to bugtickets that old (see icecat localizations one) because I have no means to reproduce it and don't really have the spoons to deal with more than one project this year <dissoc>is it possible to get the path of a package in the config.scm file? i made a package for an apache module, but i dont know how to reference it <civodul>it's true that currently we have guidelines, but it's ad-hoc and requires coordination among us <civodul>dissoc: usually you'd just refer to the package (its variable), never to its store file name <mbakke>it should be possible to write a pre-push hook that does the checks <mbakke>"pushing these Y commits will cause N rebuilds... are you sure about this?" <nikita`>i'd really be interested in providing more useful feedback, but between netbsd, working a minimum wage job, fighting bureaucracy to even stay in a flat, finding a new job, learning more languages to find a new job and having some kind of weird social life in these times, i kind of run low on spoons for experimentation. 