IRC channel logs

2019-12-01.log

back to list of logs

***jfred5 is now known as jfred
<nckx>guix build: error: executing SQLite query: database disk image is malformed
<nckx>Segmentation fault
<nckx>Nononono.
***catonano_ is now known as catonano
<seepel>Hi there, I've been trying to get into Guile on a Surface Book 2 with Windows Subsystem for Linux, and having a heck of a time. I'd like to explore dual booting with a guix package manager and I'm wondering how hard it would be to dual boot into guixSD with a custom kernel (someone has put together a kernel that supports pretty much all of the hardware on Surface devices).
<seepel>How much pain am I asking for if I tried to install guixSD with that kernel? If it's useful to answer the question the kernel is here: https://github.com/jakeday/linux-surface
<seepel>I should also add that in my investigations I came across this post that seems relevant: https://guix.gnu.org/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/ Is it as relevant as it seems?
***tune is now known as bdju
<malaclyps>seepel, the default guix is set up to use a linux kernel with no proprietary firmware -- you can definitely find definitions that work with the mainline kernel, and maybe that would be better stepping off point, but I suspect you should play around with getting that working first, before you experiment with a more exotic kernel!
<seepel>Good suggestion! Maybe I should actually just start with a VM and/or docker image? Two follow up questions then, 1) Do you know of any existing images to quick start such a thing, and 2) Do you know of any (preferably simple) definitions for guixSD with a mainline kernel that I could use as a starting point?
<bdju>Discussion of mainline kernels here (or other things related to needing a blob for hardware) is a mess because talking about non-free stuff is discouraged.
<seepel>Ok, sorry about that. Thanks for the suggestions
<seepel>Do folks have favorite hardware to run guixSD on?
<atw> https://h-node.org/ might be a helpful resource
<seepel>Cool, I'll poke around a bit there
<atw>I have had good luck with a desktop (though don't ask me about graphics cards!) and with a Librem, barring one tweak around the keyboard
<seepel>I have been eyeing the puri.sm stuff, looks very cool, though I suppose I need to convince myself that I'm going to stick with this before plunking down more money
<atw>fair enough. Though hardware that's good for free software would be good for more than just Guix
***apteryx_ is now known as apteryx
<seepel>Yeah, less about the hardware itself and more about moneys :D
<seepel>Hi there, just wanted to pop back in and apologize if it seemed like I was ungrateful. Was thinking about it and I asked for hardware recommendations, and it seemed like I complained that they were too expensive. It was not my intention at all! Thanks for the guidance!
<nixo_>Hi guix! After a recent update (probably 215a45) my emacs loads an older org-mode, anybody else has the same problem?
<nixo_>this works as a workaround : EMACSLOADPATH=/run/current-system/profile/share/emacs/site-lisp/guix.d/org-9.2.6:$EMACSLOADPATH emacs
<snape>nixo_: well, I think we're waiting for apteryx_ to merge https://lists.gnu.org/archive/html/bug-guix/2019-11/msg00386.html ;)
<snape>but you can cherry-pick the patches in the meantime
<jyscao>Hi guys, I'm trying to create a package which uses the cmake build system. Here's the package definition as a gist: https://gist.github.com/jyscao/f91cea54a03e03ce8653c2bd1b0165c2
<jyscao>At this point, when I run `$ guix build --file=love-nuklear.scm -K`, the build always fails with the following error:
<jyscao>builder for `/gnu/store/pb1c62pg48c0xy6yy3yfq3c0v99xh71q-love-nuklear-v2.6-0.0cca218.drv' failed to produce output path `/gnu/store/j2ldf7vxpvj1pg41h7kb30pz5kmw25yn-love-nuklear-v2.6-0.0cca218'
<jyscao>any ideas?
<snape>jyscao: it works for me (well, if I remove the (define-public ...))
<jyscao>snape: so did you just replace it with (define ...)?
<snape>nope
<snape>(define-public ...) returns something undefined
<snape>guix build -f needs a package object
<snape>which is returned by (package ...)
<snape>you just need to remove the (define-public ...) around (package ...)
<snape>around the (let ...) actually
<snape>(but that doesn't really explain why you have that error, the error should be something totally different)
<snape>(actually, my output only contains the LICENSE file)
<snape>OMG I just discovered the Emacs guix-derivation major mode
<jyscao>snape: okay yes sorry, I actually did place `love-nuklear` as the final line of my definition file (only removed it for the gist)
<jyscao>so there's no error when you tried to build it from this file?
<snape>it's awesome!!
<jyscao>snape:
<snape>jyscao: no, there is no error, but there is only the LICENSE file, which isn't much
<snape>(also, I have an up-to-date guix)
<snape>(what about you?)
<jyscao>snape: does it also build successfully when you remove the `(delete 'reset-gzip-timestamps)
<jyscao> (delete 'compress-documentation)` in the `modify-phases` section?
<jyscao>snape: my guix should be up-to-date as well, just did a pull not long ago
<snape>yes, it works too
<jyscao>okay thanks for testing it out
<jyscao>i'll try and work it out more
<snape>hmm
<snape>jyscao: why do you replace the 'install phase' with 'make'?
<snape>it doesn't really make sense
<snape>the install phase is to copy files from the build directory (with the fresly created output files) to the install directory (where you run the program from)
<snape>'make' doesn't really do that
<snape>it just builds the files in the build directory
<jyscao>snape: because the author of the project itself wrote the build instructions with make as the final step, instead of make install
<snape>no, I think the author didn't say how to install fresly built files
<snape>but the 'make' command really is to build
<snape>not to install
<jyscao>snape: I'll try your suggestion and not modified the install phase
<snape>no you need to modify it :)
<snape>but in another way
<jyscao>I just remembered it produced some error as well before I modified it
<jyscao>Ohh okay
<snape>you need to copy nuklear.so in the install dir
<snape>that's what the install phase is supposed to do
<snape>btw you can inspect the content of your 'build' dir if you want
<snape>it's interesting
<snape>at the end of the build log, there's:
<snape>note: keeping build directory `/tmp/guix-build-love-nuklear-v2.6-0.0cca218.drv-1'
<snape>you can go into that dir
<snape>and you'll see that there's build/nuklear.so
<snape>(which is good news, usually building is harder than installing ;))
<jyscao>Yes I did see that as well, which was why I tried to just delete all those post installation steps to see if that would help, but now I realize those are not the actual issues
<jyscao>Thanks very much for your help :)
<jyscao>I'm still a complete noob at Guix, but it is a very tool that I want to get good at
<snape>do you know where the love game expects to find plugins?
<snape>something like share/love/plugins?
<snape>(because that's where you should install nuklear.so)
<jyscao>I'm not quite sure. When I used love before, I just added nuklear.so to the project itself, and modified Lua's c_package_path env var
<jyscao>Maybe there is such a location, I'll ask them
<leoprikler>nixo_: It appears you've installed org at system level. I'd prefer if you installed it at user-level, then there will be no problem with path mixing
<snape>jyscao: this should help http://paste.debian.net/1118849/
<snape>it will install "nuklear.so" to share/
<nixo_>snape: thanks, good to know the problem with the load path is already known
<nixo_>leoprikler: I like having to upgrade system to upgrade everything .-.
<jyscao>snape: awesome!
<ScaredySquirrel>uh ok startxfce4 works BUT Importantly I can't use my keyboard or mouse at all
<ScaredySquirrel>oh ah
<ScaredySquirrel>ok how do I use (map specification->package+output)?
<ScaredySquirrel>lol ok I think I've got it
<ScaredySquirrel>(packages (append (map specification->package+output (cons* '("openbox" "jigglypuff" "tails" "sonic" "emerald")))))
<ScaredySquirrel>another question, how do I include all of the gnu/packages/fonts.scm in my packages automatically?
<snape>ScaredySquirrel: the goal is to pass them to 'guix package -m'?
<nckx>ScaredySquirrel: You can't ask for ‘all the fonts please’ (maybe some day, we could tag things like fonst, cups drivers, etc.) but I ran ‘guix package -A ^font- | cut -f1’ and curated that list. You'll have to, because at least one of them isn't a font at all and another (mathjax) slows down guix profile operations immensely.
<nckx>‘font-util’ is not a font.
<ScaredySquirrel>jyscao: what was awesome/
<snape>Guix is awesome
<ScaredySquirrel>well is there any reason why (kernel-arguments "quiet i8042.nomux=1 i8042.reset") says: "ERROR: procedure append: Wrong type argument in position 1 (expecting empty list): "quiet i8042.nomux=1 i8042.reset""
<snape>ScaredySquirrel: because "quite something" isn't a list
<nckx>ScaredySquirrel: (kernel-arguments (list "..." "..."))
<nckx>kernel-arguments is a procedure that takes 1 list as its arguments.
<nckx>Not >= 0 arguments.
<snape>(well, it's not a procedure, but it's used as a list)
***ScaredyS1uirrel is now known as scaredysquirrel
<nckx>Oops. Obviously.
<nckx>Don't even know what I was thinking.
<scaredysquirrel>um so how do I get mouse & keyboard working with xorg?
<ng0>does guix build gnu make with guile enabled? I've been playing around with it for pkgsrc and maybe adding it, but it seems like the number of projects using this goes almost towards 0
<leoprikler>ng0: looking at the package definition it would seem so
<janneke>o/
<nckx>\o
<ng0>leoprikler: ok, thanks
<shrzen>Is there some sorta list where i can check my hardware and if suitable drivers exist for it? I'm giving linux a try again, so i'm not that well oriented in this part of the *nix world
<nckx>shrzen: https://h-node.org/ is mentioned a lot, but I've no experience with it.
<anon987321>you might also have luck searching for "(device) drivers gnu linux"
<nckx>shrzen: …and since you dare say ‘linux’ here… 😉 I'll explicitly point out that reading ‘works with Linux!’ on a random site doesn't mean it will work with GNU Guix. ‘Linux’ ships proprietary firmware blobs, we (and other GNU distributions) don't.
<atw>wireless cards can be a common sticking point; I had to do a bunch of reading about if ones I was planning to buy would be supported.
<efraim>I bought a usb stick from ali express
<shrzen>Thanks guys, the seller gave me the wrong laptop(x280 instead of x260) so that kinda caught me of guard. I'll check for hardware compability now, but i'm quite sure the wifi doesn't work on this one.
<shrzen>nckx: yea, my bad hehe. Still gotta get the habit of putting GNU first
<nckx>shrzen: No bad. Could've been indicative of a culture shock is all.
<ScaredySquirrel>guys the X server uses a /gnu/store/bd51fdgpjsp87irjg3sr726m2xgci6pc-xserver.conf file
<ScaredySquirrel>with gdm only though
<ScaredySquirrel>startx/xinit use nothing
<ScaredySquirrel>where's the "clear" program used to clear a terminal?
<ScaredySquirrel>and reset used to reset it
<ng0>you can either achieve that with 2-5 lines of C, or install ncurses which provides clear
<ng0>well, 1 line of C.
<ng0>excluding includes and exit.
<nckx>…or Control + L 🙂
<ScaredySquirrel>what's the thing for reset?
<ScaredySquirrel>the keyboard keys
<Mrtn[m]1>(I'm running Guix under Ubuntu)
<Mrtn[m]1>If I understand it correctly, I need to run "guix pull && guix package -u" for each of my users, for it to be upgraded. However, "guix pull" is failing for some of my uses with a "502 bad gateway" or something like that. However, for other users, it seems to run just fine?
<nckx>Mrtn[m]1: Could it simply be arbitrary? Savannah (the GNU hosting service that guix pull uses) was having problems recently. I ran it in a loop & the 10th time it worked.
<roptat>right, I also experienced that
<roptat>you can try again and it will succeed at some point
<roptat>it's not related to your users
<nckx>Mrtn[m]1: until guix pull; do sleep 1; done 🙂
<Mrtn[m]1>nckx: I'll try that, thank you.
<nckx>Yes, in theory we're exacerbating the problem with a mini DDoS, but what else can we do.
<Mrtn[m]1>So the server is only partly fixed I guess?
<nckx>Looks to me like it's overloaded.
<nckx>Haven't looked closely, though.
<nckx>…and there goes the Freenode…
<zig>that was big netsplit.
<Mrtn[m]1>nckx: How can you look closely? I tried to browse it, and some links seems to fail consistently.
<Mrtn[m]1>Am I right to assume, that the load I produce on the servers, is equal to "size of guix-archive" times computers times avg_users_using_guix
<Mrtn[m]1>"avg_number_of_users_on_each_machine_with_guix", even. 🙂
<nckx>Mrtn[m]1: What's ‘size of guix-archive’? I think computers * avg_n_o_u_o_e_m_w_g is enough. Which can be simplified to… ‘how many of your users run Guix?’ 😛
*nckx hasta go.
<Mrtn[m]1>Oh .. I guess we can't see netsplits on the Matrix side.
<Mrtn[m]1>nckx: On this machine, I guess it is 3--4 potentially 5 or 6 - plus root of course. .. On my other machine, I am guessing 3 plus root.
<Mrtn[m]1>nckx: Yeah, I guess it actually boils down to "number of users running guix, plus number of machines (to include root)"
<sputny>Hello together, I'm trying to install guix system on my machine. I prepared an USB according to the manual. The USB is found by my BIOS and Grub Menu shows up. But then ther are some warings and error:
<sputny>GC Waring: pthread_getattr_np or pthread_attr_getstack failed for main thread
<sputny>GC Warning: Couldn't read /proc/stat
<sputny>loading kernel modules... wailting for partition `...` to appear
<sputny>creating /etc/michine-id...
<sputny>ssh-keygen : generating new kost keys:
<sputny>error in finalization thread: Bad file descriptor
<sputny>udev[208] no sender credentials received, message ignored
<sputny>Error: Driver 'pcspkr" is alerady registered, aborting...
<sputny>Can anybody help me?
<nckx>Mrtn[m]1: I really wouldn't worry about ‘your’ load on Savannah: it's only used when guix (or git) pulling, for the usual git ‘hey, got updates? sure, here they are’ dance. What can kill a server is the potentially thousands of pipelined requests for substitutes, but those are sent to ci.guix, which is not Savannah.
<nckx>Mrtn[m]1: …now, ci.guix has its own troubles, but they're not related to what you're seeing tonight.
<nckx>sneek: later tell sputny: Those errors & warnings are scary, but ‘normal’ (we all get them) and don't affect the boot. If your installer works there's nothing to worry about, if it doesn't it's unrelated to those messages and we'll need more info to find out why.
<sneek>Will do.
<Mrtn[m]1>nckx: Well, what I was thinking about "my load", was that other L-users probably does the same thing ... which might add up in the end .. From a personal point of view .. it is also a slow process to run "guix pull" for all my users and machines... I wonder why it is necessesary, when all it really does in the end, is changing some symbolic links ... so why does it have to download it all again for each user?
<leoprikler>because git has no system level caches
<nckx>Mrtn[m]1: It does quite a bit more than that. It Guile-compiles all of Guix. And Guix being Guix, it does that from scratch. Guile's compiler is also slower than everyone would like, that's being worked on.
<leoprikler>How ready is Guix for Guile 3.0 btw?
<nckx>I do agree that the guix pull user experience is suboptimal and downright painful on slow machines.
<nckx>Just noting that there are $reasons.
<Mrtn[m]1>nckx: My point is .. it compiles it "number of users"-times .... why isn't it good enough to download and compile once?
<lfam>`git clone` and `git pull` without any arguments like --depth or pulling specific commits is very optimized on the server end. You don't need to worry about that
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, apteryx says: thanks for the tip about VMs with a working Guix!
<lfam>sneek: later tell apteryx: Cool, I hope it's working out :)
<sneek>Will do.
<leoprikler>I don't think guix pull should compile things twice if you have the same git commit.
<Mrtn[m]1>leoprikler: Exactly .. it is not just redundant, it is potentially evil ...
<nckx>Mrtn[m]1: Does it? I don't run (real) multi-user sites, but that surprises me. It does the same as any other package: build derivations to the store, which should be re-used for ‘free’ when nothing has changed between pulls.
<leoprikler>Then again, I never guix pull'ed without the top commit having changed in-between so I might be wrong.
<nckx>And shared between users.
<Mrtn[m]1>nckx: So .. let's say user_a does a "guix pull ; guix upgrade" ..and then user_b does a "guix pull ; guix package -u" .... what happens in the second pull?
<Mrtn[m]1>(assuming the repository is unchanged).
<nckx>It *shouldn't* recompile as much Guix (by a loong shot) if nothing has changed upstream.
<leoprikler>Assuming the repository is unchanged, guix pull should not rebuild anything and guix upgrade (both variants) should reuse common packages.
*nckx can only speak in shoulds.
<nckx>If you see something different (and apparently downright pathological) in practice that might make a nice bug report.
<nckx>Mrtn[m]1: ☝
<leoprikler>That said, master is somewhat lively, so if you want to be 100% sure that nothing changes in the time you make your observations, you should provide --commit
<nckx>Yes, that will be question one: are you sure nothing changed upstream? It is true that Guix will then rebuild all of Guix. We don't really handle incremental builds well by design, and that's the drawback of using the same mechanism for pulling Guix as for building all the rest.
*nckx → bus.
<lfam>So I wonder what it would take to add some "try to respawn" code to starting services
<Mrtn[m]1>nckx: So it would make sense to split pull in a "clone" and a "build" command, so that the "clone" would check if the repository has changed, and _only_ clones changed/new pacakges, and then marks new/changed packages for build, and then "build" only builds the new packages.
<lfam>We really need it for the SSH service
<Mrtn[m]1>marks/flags
<lfam>Mrtn: `guix pull` doesn't actually build packages. It builds the Guile code that is the package definitions
<Mrtn[m]1>I can't get services to run at all, except on my GuixSD installation, which I haven't used for quite a while, since most of the hardware doesn't work with GuixSD anyhow.
<leoprikler>Well, actually it builds not only the package definitions, but also all the guix tools, etc. each of which is implemented in Guile.
<lfam>Yes, that's right. I meant to issue a correction just in the context of "building packages"
<lfam>The entire Guix codebase
<leoprikler>Yeah, that is always a three step process.
<lfam>Regard the SSH service issues, I'm curious how systemd does it. Do they just wait longer for the pid file? Or make sure the network is really working before marking it as ready?
<lfam>It's interesting that the OpenSSH service requires 'syslogd' and 'loopback' while the lsh and Dropbear services require 'networking' and 'syslogd'
<atw>guix describe tells me c6d1306 and guix weather znc tells me that there are no substitues available for znc. Is there a good way to ask the question "why not?" I am not very good with hydra
<lfam>atw: There could be a few reasons
<lfam>First, we aren't using hydra anymore so make sure you are using a working substitute server (ci.guix.gnu.org) and all that
<lfam>Either the package is broken, its dependency graph changed and it hasn't been rebuilt yet, or the CI server is broken
<dftxbs3e>Hello Guix, I'm sorry I was busy this week-end.
<lfam>You can visit the ci.guix.gnu.org web site, and then search for znc
<lfam>Then, select the build for the 'guix-master' "specification" for your architecture
<lfam>I'm guessing it's x86_64 since that is indeed failing to build on the server
<atw>thanks for teaching me to fish, lfam :) much appreciated
<lfam>But I don't know how to investigate more with the Cuirass-based CI interface
<lfam>On Hydra you could really dig in. For example, this build is failing because one of its dependencies failed. Hydra would have told you which one and offered the full build log
<dftxbs3e>nckx, I see, so GNU Guix's CI currently requires proprietary firmware to run, that's bad. Hopefully the POWER9 hardware can replace x86 entirely, with cross compiling it could. However, for testing..
<lfam>atw: So unfortunately you will probably have to build locally and investigate like that
<atw>lfam: I've built znc locally successfully but on my server which has less memory it does not build. Admittedly the derivations are not equal so it's not a perfect test but my hunch is that znc requires a hefty amount of memory while building.
<lfam>You'd think that wouldn't be a problem on the build farm
<lfam>Remember, on the build farm, we did not even try to build znc, because one of its dependencies failed
<lfam>At least for x86_64
<atw>indeed, I think I have a different problem from the build farm -- guix build znc --dry-run says that it will only build a znc .drv
<lfam>You might get better answers about debugging with Cuirass when the more active contributors are around, or by asking on <help-guix@gnu.org>
<lfam>I think there are some methods but I don't know them
<atw>thanks again!
<lfam>I know that cbaines was working on something but I don't know the status
<atw>yup, pretty sure it was mem usage in my case. I saw high memory usage followed by "c++: internal compiler error: Killed (program cc1plus)""
<lfam>That's the classic symptom of running of memory
<lfam>running out of memory
<atw>lol
***lle-bout_ is now known as lle-bout
*atw swapons
<lfam>Is anybody using kdenlive from Guix? For me it's not possible to import any media because the "add clip" dialog is broken. The dialog does open but cannot actually display any files or folders
<lfam>It does work when I make the package use qt-build-system and remove the arguments that do a wrap-program
<civodul>uh, dunno
<civodul>hi!
<atw>hello!
<g_bor[m]>hello guix!
<g_bor[m]>civodul: I am trying to create a small reporoducer system config for the berlin tls issue.
<g_bor[m]>Very nice that you managed to narrow down to the nginx version.
<g_bor[m]>There actually was about 8-10 commits between the two versions... I believe I found which one is causing the problem.
***sneek_ is now known as sneek
<civodul>g_bor[m]: ooh, excellent!
<civodul>i'm grateful you looked at the differences
<civodul>i moved on as soon as i had a workaround :-)
<g_bor[m]>civodul: I just don't want to stuck on version without being able to upgrade if that becomes necessary.
<g_bor[m]>It seems that there was a big change in the available bytes handling mechanism, and it interacts badly with our usecase.
<civodul>g_bor[m]: sounds like it could be the culprit
<civodul>perhaps if you can give them a simple reproducer, it'll help
<janneke>o/
<civodul>could be the Guile program i sent, after all, with the Guix bits pasted in it
<civodul>howdy janneke!
<civodul>how's everything? :-)
*vagrantc waves
<civodul>hey vagrantc :-)
<g_bor[m]>ok, I am trying to find out what is actually happening with your reproducer first.
<civodul>alright
<civodul>let me know if anything's unclear!
<janneke>civodul: just survived a small drop of rain :-)
<g_bor[m]>I almost have a working config, now generating the certs to get through the nginx config check
<civodul>janneke: oh, not bad! :-)
*civodul prepares to pack and all
<vagrantc>civodul: there are definitely unclear things, just so you know!
<civodul>vagrantc: unclear in what way? :-)
<vagrantc>civodul: ah, i didn't know you'd need follow up
*janneke is unsure if this viewpoint encompasses "everything", but i'm okay :)
<vagrantc>the sky isn't exactly clear
<civodul>ah oh, got it!
<vagrantc>and i'm still not remotely proficient with guile
<janneke>big *lol* here, with vagrantc
<vagrantc>so that's a bit unclear to me
<g_bor[m]>One thing I noticed, is that we are actually happily reconfiguring with a bad nginx config. Shouldn't that fail?
<civodul>can't wait to be hacking on the rooftop :-)
<janneke>civodul: please don't wait, just come over here :)
<civodul>heh, tomorrow!
<vagrantc>live in the moment!
*janneke just missed it
<civodul>g_bor[m]: bad nginx configs are detected only when the service starts, which sucks
<civodul>see https://issues.guix.gnu.org/issue/37388
<bandali>civodul, hey, any news about the ci.guix tls issue?
<g_bor[m]>bandali: are you still seeing problems?
<bandali>g_bor[m], i haven't tried (been *super* busy) but i was wondering if ludo or others had a chance to take a closer look at it
<bandali>is it already fixed for the others experiencing it?
<g_bor[m]>it seems that downgrading nginx fixed it.
<g_bor[m]>I am tring to find out what exctly is going on, but it should work.
<civodul>bandali: it's worked around: https://issues.guix.gnu.org/issue/38411
<bandali>g_bor[m], ah! so an upstream bug?
<g_bor[m]>looks like that...
<bandali>ha
<bandali>civodul, nice, thanks for the link! it's not loading for me but i'll wait and check back on it in a bit
<g_bor[m]>civodul did a really nice debugging here, it's just it should be finished, so that we can upgrade later.
<civodul>yup
<g_bor[m]>yeah ,there's something mumi is being slow.
<bandali>ha
<bandali>in the mean time, working link: https://bugs.gnu.org/38411
<g_bor[m]>I did see somehting on the ml form ricardo, but it was not further elaborated.
<g_bor[m]>Anyone knows what's missing there?
<civodul>bandali: i've restarted it (mumi, issues.guix.gnu.org)
<bandali>cool, thanks civodul; opens now
<g_bor[m]>see you later!
<bandali>see ya g_bor[m]
<ScaredySquirrel>hello guys; how would I list packages to remove from the global list of packages in config.scm?
<ScaredySquirrel>hello guys; how would I list packages to remove from the global list of packages in config.scm?
<bandali>hi, i'm not sure i understand your question
<bandali>don't people usually go the other way, i.e. add packages to be installed to their config.scm?
<ScaredySquirrel>yes but I wanna make sure these packages are not in the list
<bandali>hmm, i'm not sure :/
<ScaredySquirrel>and I know that my xorg server is broken without its /gnu/store/bd51fdgpjsp87irjg3sr726m2xgci6pc-xserver.conf file being used by telling xorg about it via its options by xinit and/or startx
<ScaredySquirrel>there's no xorg driver modules
<ScaredySquirrel>without it
<ScaredySquirrel>that makes for no mouse and no keyboard
<bandali>hmm, i'm not sure
<bandali>i suggest you try asking when more people are around
<leoprikler>ScaredySquirrel: What packages do you have currently on top of %base-packages?
<ScaredySquirrel>one of them is ungoogled-chromium-wayland and I'd like to tell it to go awway
<leoprikler>you can do that
<ScaredySquirrel>also a prevailing xorg cure would be really nice
<leoprikler>I'm really not sure what causes this issue in the first place though.
<ScaredySquirrel>what issue?
<ScaredySquirrel>i mean which
<leoprikler>Your driver issue.
<ScaredySquirrel>oh that's easy the missing xorg modules in its search path
<ScaredySquirrel>also, /dev/tty0 is inaccessible as a normal user so I can't run X
<leoprikler>ehm, what kind of setup are you aiming for here?
<leoprikler>you should not need to start X as normal user
<ScaredySquirrel>what kind? I hate that gdm thing and getting it removed is like pulling my hair out
<ScaredySquirrel>because of trying to add srfi-1 is the problem
<ScaredySquirrel>if I want to it's a miscompile error
<ScaredySquirrel>I mean I did try and it was an error
<leoprikler>You probably ended up with a poorly written configuration then.
<ScaredySquirrel>how is it possible to poorly write it?
<leoprikler>Programming languages do operate on a GIGO basis.
<ScaredySquirrel>GIGO? what is that?
<leoprikler>"how is it possible to poorly write it?" – Guile is Turing complete, you can do anything with it.
<leoprikler>And that's only counting /valid/ programs.
<leoprikler>Don't get me started on invalid ones.
<ScaredySquirrel>if you guys on irc just said "right here is everything you need to learn programming and computer science and the math + lots of terms"
<ScaredySquirrel>and gave it starting from the basics all the way to advanced
<ScaredySquirrel>when I was reading the C programming language I just got stuck on implementing my very own getline()
<ScaredySquirrel>maybe that lanky ferret is just off elsewhere learning on its own?
<leoprikler>I don't think such a detour is a good idea unless you're genuinely interested, which you don't seem to be.
<leoprikler>If you're having problems with a particular config file, the best thing would be to paste it along with the error you're experiencing.
<leoprikler>That way, others can help you instead of having to read a rant without context.
<leoprikler>"I tried adding SRFI-1 and it doesn't compile" is not useful in the grand scheme (heh) of things.
<leoprikler>*I* know how to add SRFI-1, because I breathe parentheses.
<leoprikler>What I need to know is how you arrived in a situation, in which even something that simple (to me at least) causes an error even before the step you're interested in.