IRC channel logs


back to list of logs

***irfus- is now known as irfus
<Gooberpatrol66>I read that you should not guix pull as root and should just use guix system reconfigure with sudo and your user's guix. Is that correct?
<Gooberpatrol66>Are there any potential security drawbacks to never updating root's guix?
<trevdev[m]>Did you mean *not* use sudo for the user config?
<nckx>Gooberpatrol66: Are you using Guix on a foreign distribution?
*yewscio_g is back (gone for 00:06.08)
<podiki[m]>any go or go importer experts around?
<nckx>yewscio_g: Why announce that only in #guix?
<elais[m]>I wrote one, sadly it was not used in the current implementation lmao
<nckx>Was it superior in every way?
<podiki[m]>I'm hitting a bug with eg `guix import go -r` and vaguely remember something about go and refs/tags ...
<horizoninnovatio>Good Morning Guix! I've beeing doing "guix pull" "guix package -u" regularly for over a week, maybe two and there have been no updates/upgraades. Is this normal? or am I missing something?
<podiki[m]>depends what packages you have, if they weren't updated then nothing will happen usually (sometimes will because of dependencies being updated)
<podiki[m]>(on go importer, found several matching issues, so it is known... eg 51633, 52362)
<podiki[m]>(and 54097)
<Andronikos>Does someone know the state of Guix running on a Raspberry Pi 4?
<KarlJoad>Quick question: Does Guix support the man(9) pages? They are non-standard and are provided by Linux's documentation system. I made a request to nixpkgs (#127424) about it, which has been added.
<sneek>KarlJoad, you have 3 messages!
<sneek>KarlJoad, trevdev says: Update: I deleted my guix profiles and garbage collected my user. Then I ran a guix pull, and a guix home reconfigure. It looks like everything came back OK except that my gnupg pinentry broke. Its looking for pinentry in .guix-profile instead of .guix-home/profile. I guess guix home can't account for unexpected external state.
<sneek>KarlJoad, trevdev says: What's more is that using only guix home has had no effect on the original problem. After initially rebuilding my entire home to generation 1, garbage collecting, and doing a guix home reconfigure, I am still getting every home package downloaded and/or rebuilt
<sneek>KarlJoad, trevdev says: I appreciate your help, thanks for the suggestions. I am not sure what to do at this point beyond give up on home, or email the bugs list. Maybe I'll do both :)
<nckx> horizoninnovatio You should check whether 'guix describe' gives a new commit.
<KarlJoad>sneek: later tell trevdev[m] I recommend you email to the bugs list anyways. It makes sense that a reconfigure from generation 1 to current rebuilds everything, but does a subsequent reconfigure, without pull, still cause a mass rebuild?
<nckx>They did.
<nckx>Excellent idea re: man9 pages.
*nckx -> zzz
<KarlJoad>The nice thing about the man9 pages, is they are pretty simple to build. The nixpkgs PR# 139672 should be fairly portable to Guix. Just some Perl shenanigans.
<KarlJoad>Also, is there are repo that contains the infrastructure for the IRC server?
<KarlJoad>Particularly the sneek bot.
<Andronikos>KarlJoad: After some research I didn't find anything. Let me know if you have something.
<trevdev[m]>KarlJoad: Thanks! I did email help-guix but after more reading and mulling I am still not sure I'm not just misusing guic gc. As per the docs reconfiguring your system after a gc can be "inconvenient" so do it as infrequently as you feel like you can get away with. Maybe this carries over to guix home with "requirements for the ability to install packages"
<sneek>trevdev[m], you have 1 message!
<sneek>trevdev[m], KarlJoad says: I recommend you email to the bugs list anyways. It makes sense that a reconfigure from generation 1 to current rebuilds everything, but does a subsequent reconfigure, without pull, still cause a mass rebuild?
<trevdev[m]>guix gc*
<trevdev[m]>sneak botsnack
<trevdev[m]>sneek botsnack
<trevdev[m]>When you use guix home to generate your shells and crons, are the resulting working file copies considered immutable?
***sebbu2 is now known as sebbu
<bjc>for the most part, if it's installed by guix, it's immutable
<Gooberpatrol66>nckx: No, I'm using guix system
<lechner>Hi, what's a likely reason why an attempt to boot Guix on ancient hardware (Athlon XP Mobile) would fail with "waiting for partition to come online," please?
<lechner>Does Guix 1.3 still ship parallel IDE drivers?
<Gooberpatrol66>lechner: it looks like it
*yewscio_g is back (gone for 01:43.34)
<trevdev[m]>Is there some way to derive the specifics of what was changed between home config generations?
<horizoninnovatio><nckx> " horizoninnovations You should..." <- Generation 17 jun 28 (current)
<tangonov>I made a stupid "pros & cons" list for managing my user home with guix home vs guix package + stow. Comments/thoughts are appreciated. ADHD is hard.
<muradm>hi guix
<unmatched-paren>tangonov: I like it, except that I don't think the guix (package|home) split is that confusing. guix package is for installing packages in the traditional way, with mutable profiles, and guix home manages stuff the declarative way, with reconfiguration, containerization, et cetera.
<tangonov>I noticed profiles are pretty guix package centric as well. I wonder if it would ever make sense to mix the two
<unmatched-paren>Profiles as in files that specify packages to install?
<unmatched-paren>s/packages/sets of packages/
<unmatched-paren>Oh, I think I know what you mean. Never used profiles.
<unmatched-paren>At least, never used anything other than the default profiles :)
<tangonov>As in inter-changable isolated envs of packages, best supported with manifests:
<unmatched-paren>Couldn't you just write another guix home configuration instead of another manifest then?
<tangonov>Yes, yes I technically could. Though each profile has its own generation history, whereas your home has only one
<tangonov>And package installations/removals are more granular when you review the record of what was changed.
<abrenon>hello guix
<nikola`> Hello
<sughosha>Hi Guix!
<sughosha>If someone could check if they can merge the patches in <>, it would be great.
<abrenon>looking at it
<sughosha>abrenon: Thank you! :)
<civodul>Hello Guix!
<abrenon>hi civodul !
<ardon>Hi Guix! Sorry to cut the fun, but I'm genuinely lost here. I'm trying to package a Go application which depends on a Go library (that I'm also packaging myself). This library includes //go:embed directives on its source files to consume some SQL static files that it uses to initialize some application storage. From what I've read, these directives must be relative paths (meaning I can't patch this path to point to a /gnu/store/... one)
<ardon>and can't take symlinks. The last point is what is particularly bugging me. Since I'm referencing the library to build the Go application, I believe Guix uses symlinks from /tmp/guix-build/... and thus I always end up with "pattern xxx: cannot embed irregular file xxx" errors.
<ardon>I can submit this as a bug if it's too long to discuss here.
<ardon>Also, I should note that if I simply `substitute*' these directives for empty strings, it successfully builds but I consequently get runtime errors when launching the application
<civodul>ardon: hi! yes, it might be easier to discuss on the mailing list since the setup sounds a little tricky :-)
<civodul>i'm not familiar with Go; //go:embed is some sort of #include feature?
<efraim>oh nice, python on core-updates can be built with openssl@3
<ardon>civodul: Thanks, I'll open a bug report in a sec. I'm not familiar with it either, but from what I could gather from here it's a way to embed static files within the source without having to make OS calls
<abrenon>does markdown formatting work in an email to the patch tracker (specifically, can I use ``` … ``` for verbatim blocks to report errors ?)
<sughosha>abrenon: Thanks for reviewing my patches. I replied but it may take some time to reach on the website. I will make the required changes and resend the patches.
<abrenon>cool !
<mbakke>ardon: so package B is embedding files from the source of package A?
<ardon>mbakke: As far as I can tell, package A (the Go application) needs package B (the Go library) as input, and package B has those "//go:embed" directives on one of its source files which point to SQL files in the same directory as that source file, which gets run when package A is built. However, building package B on its own doesn't produce any errors.
<nckx>Gooberpatrol66: Then there is no reason to ever pull as root or have a separate 'root's guix', unless you deliberately want two guixes that are out of sync. Most people don't. Guix System doesn't use root's guix for anything. Root is just another user, not 'the system'. You'd just be permanently wasting space on the closure of an old guix by pulling as root.
<nckx>Gooberpatrol66: The better solution for the average user is to only ever pull one cuix (their own) and use 'sudo guix' with that.
<nckx>sneek: later tell KarlJoad: There isn't really any Guix 'IRC infrastructure' or server to put there :-) Libera (once 'Freenode') provides a competently staffed network of servers, we don't host our own.
<sneek>Got it.
<nckx>sneek: later tell KarlJoad: even sneek isn't owned or operated by Guix, it's maintained & hosted by a #guile regular and was invited here long ago. She's Bobot++ extended with Guile, IIRC. I don't know if & where the code is hosted.
<sneek>Will do.
<nckx>sneek: Look, botsnack.
<nckx>sneek: later tell KarlJoad: (h/t Noisy toot)
<sneek>Will do.
<sughosha>Hi all, is there any rule for where (maybe after how many characters) to line break in description?
<abrenon>sughosha: usual line width, must be something like 80 or 78 characters, I don't remember which
<abrenon>but doesn't guix style handle this automatically ?
<sughosha>As far as I know, no.
<sughosha>`guix lint` is only saying that the line is too long.
<sughosha>I tried `guix style` but that didn't affect the long line in description.
<sughosha>abrenon: Sorry, I forgot to ping you for the above reply!
<silicius[m]>I have a patchset to send. Am I reading the manual right that I should send the cover letter first, wait for the bug number and then send the patches to that bug?
<mbakke>ardon: I see, so the problem is that the GOPATH directory structure configured by Guix uses symlinks, and thus the Go compiler refuses to resolve those embed directives? sounds like it warrants a bug report indeed
<mbakke>ardon: in the mean time, you may be able to work around it by (delete-file-recursively "the/library"), and then (copy-recursively (assoc-ref inputs "the-library") "the/library")
<roptat[m]>silicius, yes that's correct
<mbakke>should we go with GCC 11 or GCC 12 for the next core-updates round? run debate :-)
<sneek>trevdev[m]: wb!
<civodul>mbakke: i vote for 11!
<mbakke>I'm also partial to GCC 11 because it's more widely supported, and GCC 12 is still fresh out of the oven
<civodul>better let others fix GCC 12 issues before
<bjc`>speaking of compiler updates, do we have anyone who works on go? i need 1.18 for some stuff, and while ‘--with-commit=go1.18’ seems to work and pass all tests, i feel like someone with more expertise should probably be involved here ;)
<sneek>bjc`, you have 1 message!
<sneek>bjc`, muradm says: there are other things that depends on cgroups, especially docker, in order to not break others, i decided to maintain the compatibility. and as I point in my comments, i suppose that cgroups should be a dedicated service-type, instead of coming with either elogind or seatd
<bjc`>sneek: later tell muradm: i've come to the same conclusion, but from a different angle; i think it should be in %base-filesystems (it'll still be removable if its placed there) because it's lower-level than elogind/greetd, and the only way that i can see to make sure it's always mounted before them (without even larger infrastructural changes) is to put it in with the rest of the initial filesystems
<sneek>Got it.
<efraim>I vote for gcc-11
<efraim>also I'd like to bump some go 'x' packages to a later version
<efraim>apparently some of them have some tag related to the go version
***wielaard is now known as mjw
<ardon>mbakke: Thank you! Your suggestion did the trick :D I'll file a bug report later on
<efraim>Ok, built to mesa successfully on core-updates. now to try with --with-input=openssl=openssl@3
<necrophcodr[m]>Is anyone using Guix-kernel for Jupyter and has it working? It fails building for me, even during a `guix install guix-jupyter`
<civodul>necrophcodr[m]: hi! i've used it, but i noticed test failures with the latest Jupyter updates
<civodul>i haven't had time to investigate yet.
<civodul>you could try to "guix install guix-jupyter --without-tests=guix-jupyter", which will allow you to go further if the test failures aren't fatal
<efraim>Oh, I was wondering about gcc-10.4.0, just got the email
<necrophcodr[m]>civodul: i will definitely try without the tests. of course it'd be ideal if those passed, but for me right now i'm just doing some research so as long as it isn't fatal that could definitely work!
<mbakke>efraim: yay for OpenSSL 3.0! :-)
<necrophcodr[m]>civodul: that does indeed appear to work! thank you so much!
<civodul>rekado: shouldn't we make simple-texlive-package public?
<civodul>that'd be convenient for users who import packages and would like to have them in their manifest
***jess is now known as JESS
<muradm>sneek: later tell bjc`: the other day we were discussing lxd requiring cgroup2, i have some draft patch that splits cgroup-fs and updates to v2. i promised to look at it in the weekend, but unfortunately had lack of time. will try to catch up upcoming weekend
<sneek>muradm, you have 1 message!
<sneek>muradm, bjc` says: i've come to the same conclusion, but from a different angle; i think it should be in %base-filesystems (it'll still be removable if its placed there) because it's lower-level than elogind/greetd, and the only way that i can see to make sure it's always mounted before them (without even larger infrastructural changes) is to put it in with the rest of the initial filesystems
<efraim>vim 9.0.0000 was tagged
<silicius[m]>Where should I put the branch in a patch's subject: [PATCH core-updates v2 2/2] or [PATCH v2 2/2 core-updates]?
<efraim>I'd do the first, but it doesn't really matter
<fps>what does the linter try telling me here: /home/fps/src/guix/guix/gnu/packages/audio.scm:2715:6: ingen@41dcb999: the source file name should contain the package name
<fps>that's the package
<civodul>fps: line 2715 column 6 is prolly the location of the (origin ...) form
<civodul>what that tells you is that you need to add a 'file-name' field that matches the package name
<civodul>as in the example at
<fps>civodul: hmm ok. shouldn't the linter then maybe rather complain about a missing file-name field? and besides: why do i need that?
<fps>oh ok, i just read on.. ok
<silicius[m]>I wonder, is WTFPL acceptable for guix?
<silicius[m]>hmm, I gues since it's in (guix licenses) it's fine
<peterpolidoro>guix shell --pure -m manifest.scm
<peterpolidoro>echo $PATH
<PotentialUser-87>Hi. I tried to reconfigure my pinebook pro and ran into an error related to failing tests while building iwd.
<peterpolidoro>when I use guix shell --pure I get a different path when I use a -m manifest versus a -f guix.scm file
<civodul>silicius[m]: yes; you can get a list of packages under that license with: guix search . |recsel -e 'license ~ "WTFPL"' -p name,version,synopsis
<peterpolidoro>when I use -f guix.scm /usr/local/bin is on the PATH
<peterpolidoro>is that correct behavior?
<civodul>peterpolidoro: manifest.scm is supposed to contain a manifest, whereas guix.scm is supposed to contain a package definition
<silicius[m]>civodul: in which package is recsel in?
<civodul>silicius[m]: recutils
<peterpolidoro>yes that is how I am using it, I am just curious why the path for a package definition still includes /usr/local/bin
<peterpolidoro>but when I use a manifest, the path only includes the /gnu/store
<peterpolidoro>the /gnu/store profile bin
<civodul>peterpolidoro: yes, '--pure' ensures there's nothing but /gnu/*profile/bin in there
<peterpolidoro>but when I use --pure with a package definition it still includes /usr/local/bin
<peterpolidoro>when I use --check it claims the environment variables are set properly
<peterpolidoro>is that proper behavior or is there a bug somewhere?
<peterpolidoro>guix shell --pure -f guix.scm
<peterpolidoro>echo $PATH
<peterpolidoro>I get /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<civodul>peterpolidoro: what about "echo $GUIX_ENVIRONMENT"?
<peterpolidoro>echo $GUIX_ENVIRONMENT
<peterpolidoro>I get /gnu/store/7z3wsx5jjlnn8p344y07kp3scsgb3vs4-profile
<civodul>is there a bin/ subdir?
<peterpolidoro>guix shell --pure -f guix.scm --check
<peterpolidoro>guix shell: All is good! The shell gets correct environment variables.
<peterpolidoro>no bin/ subdir in my working directory where guix.scm is located
<peterpolidoro>could anything in the guix.scm file affect the PATH variable in the shell?
<civodul>could it be that what you really want is: guix shell -D -f guix.scm ?
<civodul>that is, the development environment of the package in guix.scm, not the package itself
<peterpolidoro>interesting, that does change the PATH
<peterpolidoro>guix shell --pure -D -f guix.scm
<peterpolidoro>echo $PATH
<peterpolidoro>i get /gnu/store/wa3l0p89zc7bzy9izlr117yjd3v9hz9l-profile/bin:/gnu/store/wa3l0p89zc7bzy9izlr117yjd3v9hz9l-profile/sbin
<peterpolidoro>so is that normal behavior that if you do not use -D then you get a path that is not on the store?
<peterpolidoro>the only reason I wanted to use a guix.scm file instead of a manifest is that I wanted to set some environment variables as well as install some packages
<peterpolidoro>I thought to do that I could make a package definition with inputs of the packages I want plus setting some environment variables within the package definition
<civodul>peterpolidoro: i would expect PATH to be empty, but it could be that the shell automatically populates it
<civodul>anyway, use -D if you want the development environment rather than the package itself
<peterpolidoro>so if I use -D, then only the native-inputs get installed?
<peterpolidoro>or all inputs?
<peterpolidoro>would environment variables I set in a package definitions get set?
<civodul>all the inputs, really the "development environment" of the packages
<peterpolidoro>so if I need a shell with packages and certain environment variable set and a PATH that only includes the the /gnu/store/*profile/bin then I need to set those variables outside of the guix.scm file or the manifest.scm manifest?
<civodul>right, if you need extra environment variables, you need to set them by yourself
<maximed>I've heard there are many people using ThinkPads here, do they work well with Guix (System)?
<peterpolidoro>but if a guix package needs certain environment variables to be set then those can be set within the package definition?
<civodul>it depends
<civodul>Guix takes care of environment variables that correspond to "search paths":
<peterpolidoro>does it depend on the package build system?
<maximed>peterpolidoro: I haven't been following the discussion but if a package needs certain env vars set to certain values, you can use 'wrap-program' on those binaries.
<maximed>Though I don't think this is very useful for shells.
<maximed>peterpolidoro: Search paths are orthogonal to build systems.
<peterpolidoro>wrap-program, when does that get called? is that part of the package definition?
***JESS is now known as jess
<maximed>petpolidoro: It is a Guile procedure you can call from the phases of a package definition.
<maximed>It is also run automatically by some build systems (e.g. glib-or-gtk-build-system, IIRC)
<peterpolidoro>and then those will be set whenever that package is installed?
<maximed>* petpolidoro -> peterpolido.
<maximed>peterpolidoro: What are ‘those’ here?
<peterpolidoro>those environment variables
<maximed>Environment variables are run-time.
<maximed>So they are set when the (wrapped) binary is run.
<maximed>Not when it is installed.
<peterpolidoro>oh I see
<peterpolidoro>so you cannot set environment variables when you install a package only when you run a binary within a package
<maximed>peterpolidoro: Only when running a binary, but without the ‘within a package’ clause.
<maximed>Unpackaged programs can set environment variables too.
<peterpolidoro>I will play around with wrap-program to see if I can create a package definition to do what I need, thank you
<maximed>(Also, TBC, "guix shell", "guix install -f", etc, could be modified to support setting arbitrary environment variables, via $GUIX_ENVIRONMENT/etc/profile, but at least currently that's not implemented (yet?))
<peterpolidoro>seems like it could be useful to set some environment variables when you run guix shell
<silicius[m]>Does it makes sense to include pyinstaller for a program that uses it or it's better to make some kind of script that runs it straight from sourcE?
<maximed>silicius[m]: We package the package itself in Guix, without an indirection by packaging thee installer for the package, if that's what you mean.
<maximed>However, we usually do not run things from source.
<maximed>Usually we compile the python things first (though not always!)
<silicius[m]>The program is just python and the official workflow build script uses pyinstaller, but afaik it just bundles all the modules in one file
<silicius[m]>and pyinstaller is not even in guix yet
<silicius[m]>It's this script (and program) ->
<peterpolidoro>so when setenv is used in a package definition, that environment variable is only set for the build phase?
<maximed>peterpolidoro: If you mean in the phases, then yes.
<peterpolidoro>it is set during that phase, then unset?
<maximed>If outside the phases, then it's probably run in the "guix shell" / "guix build" / ... process.
<maximed>peterpolidoro: It's set, not unset afterwards (unless done with (unsetenv ...)).
<fps>where can i find more information on the triplets reported by guix build --list-targets?
<silicius[m]>maximed: By include I meant use it in a build phase (and potentially add pyinstaller to guix since `guix search pyinstaller` returns nothing), sorry
<peterpolidoro>so if you use setenv outside the phases and do not use unset then when will that environment variable have that value? when the package is installed?
<fps>also is it possible to create an image without 1. a kernel and 2. a boot loader?
<maximed>peterpolidoro: Due to the functional model, environment variables do not escape package builds.
<maximed>Also, no.
<maximed>It has effect inside the Guix process only (and it child processes, unless --pure).
<maximed>It doesn't tell the abovelying shell or other process to modify it's environment variable.
<maximed>Also, I expect that to be a dead end.
<peterpolidoro>but when you use wrap-program that environment variable will be set whenever you run a binary and stay set until when?
<maximed>peterpolidoro: Until it exits. But only inside the process (of the program).
<maximed>Environment variables aren't global, they are per-process.
<maximed>(Or until the process unsets its variable)
<silicius[m]>So what's the solution for program that are just python scripts? Any examples in the repo I could look at?
<maximed>silicius: Just put it in /bin and add 'python' to the inputs.
<maximed>(This assumes it's a stand-alone python script)
<maximed>(Also, if it has Python dependencies, add them as well & use wrap-program to let them be found)
<peterpolidoro>does wrap-program work for any build system?
<maximed>wrap-program doesn't care about build systems.
<maximed>I recommend to just try it out.
<peterpolidoro>ok thanks for all your help
<maximed>Does someone know if all ‘AMD Ryzen 7’ have the non-freenesss problem (I assume: yes)?
***yewscio_g is now known as yewscion
<silicius[m]>maximed: I guess it is since it has a shebang, though it just imports its own module in it
<maximed>FWIW, if you don't know yet, there's a python-build-system.
<maximed>and a pypi importer.
<abrenon>trying again since there are more people now: any one else has issues with ibus-anthy since the upgrade on friday 2022-06-24 ?
<maximed>Does someone know where the site about Windows refunds is?
<civodul>is that even a thing?
<maximed>civodul: It is in France:
<maximed>Also in Italy.
<maximed>Not sure about $local_country.
<maximed>There was some non-FSF, non-FSFE site with more information ...
<maximed>Maybe I'm in luck: (assuming the ifnormation is correct)
***panosale1 is now known as panosalevro
<maximed>Does someone know a good list of which ‘AMD Radeon Graphics’ actually work?
<maximed>I've heard that ThinkPads usually just work.
<maximed>Does someone know if this only apply to the old ones or also the new ones?
<mbakke>'./pre-inst-env guix build --target=aarch64-linux-gnu nspr' fails on "core-updates", and the backtrace suggests that both (%current-target-system) and (%current-system) were #false in a call to (hurd-target? ...) down the stack
<mbakke>somehow other packages are fine, except those that depend on nspr/nss
<mbakke>the target-hurd? call is from bdw-gc.scm, which pretty much anything depends upon
<mbakke>I don't get why only nspr is affected by this, ideas?
<mbakke>this also happens with -d, no need to actually build anything
<nckx>maximed: The meme factor definitely comes from the old machines, with coreboot support etc. I'm very happy with my X230T but haven't tried newer ones.
<nckx>What was this Windows refund thing about?
<unmatched-paren>nckx: I think maximed is buying a new laptop, which obviously would come with Windows by default, so they want to get their money back on the pre-installed Windows (which certainly isn't free)
<unmatched-paren>Oh, you already know. Silly me.
<unmatched-paren>I should read backwards more thoughroughly before I hit enter.
<maximed>unmatched-paren: Yes, though looking at some documents, apparently it shouldn't be a refund but rather not paying for the Windows license in the first place (could easily have misunderstood though) ...
<maximed>(My current one is ductapy and only charges when held right ...)
<maximed>* ducktape
<unmatched-paren>Nice to hear that I'm not the only victim of wonky ports.
<maximed>unmatched-paren: Wonky ports refers to charging or ducks?
<unmatched-paren>maximed: Charging and also Ethernet, USB, et cetera.
<maximed>TBC I meant the laptop charger, for the accu.
*maximed 's chemistry teacher insisted that ‘rechargable batteries’ aren't batteries but accus
<unmatched-paren>Let's annoy both sides by calling single-use batteries "single-use accumulators" >:)
<unmatched-paren>Muahaha, watch as the pedants squirm!
<maximed>sneek: rechargeablebatteries are chemically nonsense.
<sneek>I'll keep that in mind.
<maximed>Anyway, I sent a mail to the customer service to ask how to only buy the computer, and not the Windows license.
<nckx>unmatched-paren: No, I didn't? So thanks!
<unmatched-paren>I expect the response will be somewhere along the lines of either:
***skmdab[m] is now known as filinta[m]
<unmatched-paren>+ the os is part of the computer you silly consumer
<unmatched-paren>+ we only sell laptops with windows, sorry but not sorry
<maximed>unmatched-paren: They sell ‘Chromebook’ and whatever the generic name is for Apple stuff.
<maximed>So won't work as-is.
<nckx>Probably not relevant if you've already made a choice (scrollback == hell here, sorz) but Dell sold 'developer machines' a few years back that came with, I'm guessing, Ubuntu.
<nckx>XPSes so nice machines.
<unmatched-paren>"What do you mean, a Chromebook is just a Linux laptop wrapped in a restricted interface that won't make people who are conditioned to incredibly dumbed-down UIs scream and run?"
<maximed>Are they (physically) robust? Given how the previous laptops went, the ‘military tested: yes’ of the ThinkPad is a plus.
<maximed>(Also, Lenovo ‘Yoga’ is more like Lenovo breaks after bending. Not really yoga-ish in my experience.)
<nckx>Oh, interesting since I considered that once.
*nckx has a weeeird thing for tablet PCs.
<nckx>maximed: Talking to me? I can't say, I'm extremely forgiving with my stuff, I've learnt, compared to others.
<nckx>It goes in the bag and nobody touches the bag.
<unmatched-paren>A shame Apple didn't name it the iWatch due to legal issues. Would have been a hilarious gaffe :)
<nckx>(Still assuming you were talking to me) I don't think anything beats a Thinkpad that isn't a gimmicky toughbook with rubber bits stuck on, but older higher-end Dells I've used were very sturdy. Felt so, too,
<nckx>unmatched-paren: IDGI.
<unmatched-paren>nckx: The watch would be admitting the truth: "I watch"
<unmatched-paren>s/the watch/Apple/
<nckx>I was thinking from the user's perspective — witch I guess proves I'm not an Apple customer, doesn't it.
<raghavgururajan>This mingetty auto-login hack in cookbook [] stopped working.
<raghavgururajan>The auto-logined TTY shows "Error om service module".
*raghavgururajan has a weird thing for tablet PCs too, nckx :D
***mark_ is now known as mjw
<mbakke>hmm, the poppler test suite includes a CC BY-NC-ND article:
<mbakke>I'm inclined to treat this as "non-functional data" in FSDG lingo, as it is only used as part of the build process and not user-accessible ... thoughts?
<jackhill>mbakke: we might need a lawyer, which isn't me, but I can see ND being workable in an exmple corpus, but NC seems problematic.
<jackhill>Also, I wonder how they extraced page 8, whouldn't that be making a derivative work?
<jackhill>one reading: using it as a test case is fair use in the USA. It doesn't harm the market for the original, has a different nature of use than the original, and uses only as much as is needed, so 3 out of 4 factors.
<jackhill>In which case, it can be used in freedom.
<unmatched-paren>jackhill: In situations where "we might need a lawyer" is justifiably uttered, I'd say play it safe :)
<vagrantc>mbakke: it's not clear that the original document has any licensing at all ...
<mbakke>vagrantc: it has a "CC BY-NC-ND" banner at the bottom right of the first page
<mbakke>come to think of it, it is likely many PDF/image/video test suites have similar issues
<jackhill>unmatched-paren: that's all the time though, isn't it? In the case where there isn't a technical reason folks can't exercise their freedoms (e.g. missing source), I think the question is does the law prevent them from doing so, which is the desire for legal advince, and since I'm not addmitied to the bar, I can't give any :). Onother way to do the risk assesment, is that poppler isn't some random project,
<jackhill>and Xorg/freedesktop are comforatable with this use.
<vagrantc>wow, i searched for all of the terms in the document cc, by-nc-nd, creative commons, etc. ... a single icon is sufficient to assert licensing terms?
<jackhill>also, does have any overall terms for submitted items?
<vagrantc>and, does the modified document have the icon used to identify the licensing terms?
<vagrantc>none of these parties has complied with the terms of CC BY-ND-NC ... they all fail to give attribution
<vagrantc> /o\
<jackhill>maybe worth asking the poppler devs about their understanding of the issue. Not nessisarilily that we need to come to the same assesment, but could be informative?
<jackhill>vagrantc: what about my fair use idea?
<vagrantc>fair use seems to be the only leg to stand on
<vagrantc>also not a lawyer, which is why i can say anything vaguely resembling legal advice :)
*vagrantc wonders what percentage of free software projects have licensing issues
*mbakke got nerd sniped by the actual article, good to know my work videoconferencing software is respecting the mute button
<jackhill>another option would be to contact the authors and ask them for a free licence for that page :)
<unmatched-paren>Doesn't seem like the authors are actually given though.
<unmatched-paren><vagrantc> none of these parties has complied with the terms of CC BY-ND-NC ... they all fail to give attribution
<vagrantc>i remember documenting the licensing for guix when packaging guix for debian, and it was an exhausting list of copyright holders, but there were very few issues that made me squint or grimace :)
<vagrantc>unmatched-paren: the authors of the original document are presumably the relevent parties ... but who knows, maybe the universities involved own the copyright
<vagrantc>and this is why most of the world just doesn't pay attention :)
<jackhill>at least it's only two universities to check…
<vagrantc>seems worth raising the issue upstream, at least
<vagrantc>maybe also ask the debian maintainers, to have another avenue of concerned parties who pay attention to licensing
<obabo>arch remote desktop
<mbakke>note that this test data is not shipped with the poppler source, it lives in a separate repository (perhaps for licensing reasons?)
<vagrantc>mbakke: oh, interesting
<mbakke>in guix it is downloaded in a separate derivation, only used for tests, and thrown away
<vagrantc>worst case, remove it and the test that uses it?
<sneek>trevdev: Greetings :)
*trevdev throws sneek a botsnack
<trevdev>sneek botsnack
<trevdev>Theeere we go
<silicius[m]>If a package imported from pypi tries to build opencv on its own should I move to building from source and replacing the bundled libraries?
<silicius[m]>I'm trying to package opencv-python-headless, which I need for another package
<lilyp>silicius[m]: yes, you should replace the bundled opencv with the one that's already included in guix
<silicius[m]>lilyp: I figured how to remove the bundled file, but I'm not sure how to replace it. It complains that cmake_source_dir is set to a nonexistent directory
<lilyp>you probably need to remove that cmake directive and replace it by one that adds the relevant include flags
<lilyp>this should typically be possible with substitute* as the offending directive ought to span only a single line
<silicius[m]>I noticed it also includes two patches for the bundled opencv
*** sets mode: +o ChanServ
<maximed>How do I start Emacs as a GUI?
<maximed>Typing "emacs" in a terminal results in a TUI.
<maximed>But in the past I got a (GTK) GUI
<bjc>it should start in a gui by default. do you have $DISPLAY set?
<maximed>I cannot reproduce with "guix shell emacs -- emacs".
<maximed>bjc: I have.
<maximed>It works with "guix shell emacs -- emacs".
<bjc>got me, then
<maximed>It also works with guix shell "r-mgcv" "r" "emacs" "emacs-ess" -- emacs
<maximed>But it doesn't work if I put that in a manifest.
<maximed>* manifest -> guix.scm
<maximed>found the issue: "guix shell -f guix.scm" ignored all packages with ‘no packages specified; creating an empty environment’
<maximed>Could someone do "guix --version"?
<maximed>I get "guix (GNU Guix) 0", but that doesn't seem right ...
<jonsger[m]>hm is there a way to do a make (inside guix git) sans all the doc/ stuff because that fails actually
<maximed>touch doc/the-failing-new-thing && make (is work-around though)
<jonsger[m]>maximed: dito
<maximed>Things failing looks like a bug.
<maximed>TBC: touch the output, not the input
<unmatched-paren>maximed: I get "guix (GNU Guix) 0" too
<maximed>Will send bug report.
<unmatched-paren>does -m work?
<jonsger[m]>maximed: on openSUSE with its Guix RPM package I get `guix (GNU Guix) 1.3.0`
<unmatched-paren>i believe you should be using -m hee
<unmatched-paren>jonsger[m]: wait, that might indicate you're on a really old revision of guix
<maximed>unmatched-paren: According to the --help, -f still exists.
<unmatched-paren>can you guix describe?
<maximed>(it's like guix.scm)
<maximed>unmatched-paren: that works.
<unmatched-paren>maximed: I think -f is for installing packages from files, not manifests
<maximed>unmatched-paren: I'm not working with a manifest.
<jonsger[m]>unmatched-paren I'm there. It was just to have a comparing point :)
<maximed>I'm working with (a list of packages).
*unmatched-paren tries to reproduce
<maximed>Also, if I do "guix shell -f non-exist.scm", I still get:
<vagrantc>maximed: i get version 0 also with guix pull on a foreign distro
<maximed>‘warning: no packages specified; creating an empty environment’
<maximed>vagrantc: I'm on foreign distro too.
*vagrantc would be curious if Guix System is any different
*vagrantc wishes guix used soemthing like "git describe" for it's versions
<vagrantc>that can generally get you last upstream tag + N commits and most recent git commit
<vagrantc>which generally should increase, although there are weird cases where "N commits" might decrease
<maximed>jongser[m]: In case you didn't know, keep in mind that (the distro's I know of) don't update the Guix package in case of updated packages.
<maximed>So you won't get security updates.
<vagrantc>and sometimes git picks a curious tag depending on the merge history
<maximed>(Except presumably for the guix daemon itself)
<maximed>I haven't really given version+commit+delta-etc schemes much thought myself.
<unmatched-paren>Looks like (list pkg1 pkg2) isn't accepted by either -f or -m. I wonder, though, whether that's intentional.
<nckx> vagrantc: It does exactly that.
<maximed>(new bug reports: #56289, #56290)
<vagrantc>nckx: which exactly? :)
<nckx>E.g. (yes, I need to pull, but at least it's not 0 :-)
<nckx>vagrantc: --version
<maximed>nckx: foreign distro or Guix system?
<nckx>Newer Systems have 0, of course.
<vagrantc>that looks reasonable
<maximed>Updates #56290 with system / foreign distinction.
<jts>does anyone know what the error "expected a regular file" when running `guix build -f guix.scm` might be, when guix.scm is a (at least syntactically) well-formed package definition that returns the package it defines?
<maximed>jts: Context?
<unmatched-paren>jts: Please show the guix.scm in question :)
<maximed>Full error message in context, maybe
<nckx>Good, also, morning Guix.
<nckx>maximed: Did you get a response from Coolblue after that?
<unmatched-paren>maximed: I was able to reproduce the guix --version 0 on Guix System
<maximed>nckx: For first mail (me asks ‘no license please’): yes. Second mail: not yet, but let's give them some time, it's a complicated matter.
<unmatched-paren>jts: Do you return `motl` at the end?
<nckx>maximed: That addendum is not correct, I can repro on Guix System just fine.
<nckx>22:56 nckx Newer Systems have 0, of course.
<jts>unmatched-paren: yes, it's at the very bottom of the first image
<unmatched-paren>Ah, yes. I mistook that for some statusbar or something because of the highlighting of the line your cursor is on.
<nckx>maximed: I'm very curious. I hope you post further updates here :-)
<maximed>For textual things, I recommend a textual paste service (e.g.: readable by people with poor visual senses, copyable, ...), though a picture works.
<jts>it's worth noting the build failed the first time I ran it, I changed nothing (because Guile traceback is... unhelpful, to be polite) and then this started happening
<maximed>jts: does it actually reach 'motl'?
<maximed>Maybe put a (pk 'foobar) before the motl at the end.
<maximed>My guess is that the 'local-file' fails.
*vagrantc bisects the guix --version 0 issue with existing generations
<unmatched-paren>jts: Add #:recursive? #t to the (local-file ...)
<maximed>jts: The problem is that the way you are calling 'local-file', it expects a regular file.
<maximed>But you are giving it a directory, so you have to add #:recursive? #true.
<maximed>as unmatched-paren writes.
<maximed>A 'hint: Add #:recursive? #true to local-file (line etc.)’ would be nice and technically feasible
<vagrantc>somewhere between 2b6af630d61dd5b16424be55088de2b079e9fbaf and 3213c37341d84a6cf125478c553f009110e66a89
*nckx couldn't find the thumbs up.
<jts>indeed it was `local-file`. you have to specify #:recursive explicitly even though it's true by default. (:
<maximed>jts: Where do you find it is the default?
<unmatched-paren>I don't see any other problems with that package, except perhaps that... interesting license it has, but it's not my business to judge your licensing choices :)
<vagrantc>so ... approximately mid/late january till early march ...
<jts>in the source for `local-file`, in the comment in the definition
<unmatched-paren>Just be aware that it'll mean you won't be able to upstream the package.
<jts>yeah don't worry, I'm not trying to get this in the repos lol
<vagrantc>guess this could be git bisectable with guix time-machine ...
<maximed>jts: I'm not seeing it.
<maximed>Which line exactly?
*unmatched-paren away \o
<nckx>There's no such thing as 'true by default but only if you pass it' keyword, at least not in standard Guile.
<jts>maximed: ah, wow, my mistake; it's git-predicate that's recursive by default...
<jts>don't write code at 4 AM, folks
<jts>anyway, thanks for the help!
<nckx>A lot of software would have to be rewritten then, jts.
<jts>not a bad idea
<jonsger[m]>hg clone thunderbird from is so fast, not :(
<jonsger[m]>maximed btw thanks for that touch trick on doc/*.info that helped a lot :)
<jackhill>mbakke: thanks for writing up our discussion for the mailing list!
<mbakke>jackhill: np!
*mbakke has 30k unread emails tagged with Guix, oh dear
<mbakke>ooh, teams
<vagrantc>i have ~30k emails total related to guix
<mbakke>vagrantc: you should subscribe to guix-patches ;-)
<maximed>I only have ~3K ...
*mbakke needs to find a way to tag away patches and bugs that have been closed
<maximed>Though the mail program is a bit inaccurate, it counts mails I sent myself and counts mails I read quickly.
<vagrantc>mbakke: i have no need of more email, really, quite happy with guix so far :)
<mitchell>When i run guix system build on the installation os it fails with the error `guix system: error: canonicalize-path: no such file or directory:"/gnu/store/...-guix-1.3.0-27.../share/guile/site/3.0/gnu/installer/aux-files/logo.txt". How can this happen?
<mbakke>maximed: is your GPG public key available somewhere? I could not find it on my usual keyservers
<mbakke>mitchell: file system or store corruption perhaps? you could try 'guix gc --verify=repair,contents' (warning: expensive)
<KarlJoad>Does Guix have an equivalent to Nix's buildFHSUserEnv for shell environments? Does Guix even need it?
<sneek>KarlJoad, you have 3 messages!
<sneek>KarlJoad, nckx says: There isn't really any Guix 'IRC infrastructure' or server to put there :-) Libera (once 'Freenode') provides a competently staffed network of servers, we don't host our own.
<sneek>KarlJoad, nckx says: even sneek isn't owned or operated by Guix, it's maintained & hosted by a #guile regular and was invited here long ago. She's Bobot++ extended with Guile, IIRC. I don't know if & where the code is hosted.
<sneek>KarlJoad, nckx says: (h/t Noisy toot)
<mitchell>mbakke: That did not do the trick :(
<trevdev[m]>o/ KarlJoad
<KarlJoad>nckx: Thanks! I figured there would be little about the servers themselves. I was mostly interested in sneek.
<KarlJoad>Hey, hey trevdev[m]! How is the package collection, reproduction issue going?
<trevdev[m]>KarlJoad: Honestly, I really am getting the sense that I don't really have an issue beyond the wrong mindset.