IRC channel logs
2023-09-01.log
back to list of logs
<makads> GUIX's QCOW2 image I don't have a graphical environment after QEMU installation, how do I install GNOME or XFCE? <jpoiret>makads: Guix is like Debian, it's a distribution that can run on GNU/Linux or GNU/Hurd <jpoiret>Just like you have Debian Hurd, there's a way to run Guix on Hurd. Although since Debian Hurd is basically the distribution developed and maintained by Hurd developers, it's the most "complete" one <makads>But I don't really use it to apply package managers <makads>Can you provide an installation script or something? <janneke>oh yes, a DE on guix hurd that would be something! <jpoiret>makads: Guix Hurd on bare metal is pretty experimental, I don't think it's ready for consumption by users (but ofc janneke is more aware of how hard it is to install/use) <janneke>makads: gnome or xfce; a desktop environment <janneke>i've looked at the installer but have no real clue how we'd want to install the hurd <jpoiret>janneke: wrt. guix pull and reconfigure, what's missing? I don't have much time for this these days but once it stabilizes i'll be happy to have a look again <jpoiret>was it the splitting of the guix pull compilation? <jpoiret>well, is the only difference with your config the fact that you use (kernel hurd) and the i586-pc-gnu system? <dan__>is anyone actually still developing Hurd ? <janneke>jpoiret: there's probably more to your import cycles thing <janneke>jpoiret: also, pull only works from a local tree, cloning the git archive through pull crashes at 60% or something <janneke>makads: probably doing something like `apt install xfce' <jpoiret>dan__: yes, they got x86_64 working recently, and smp is under development <makads>right but guix can not use "apt"... <jpoiret>well actually smp "works" but is slower than non-smp <jpoiret>makads: I don't think xfce works on Guix Hurd <janneke>makads: yes; guix support for the hurd, especially in the area of available packages, is still waaay behind debian <janneke>i think 60% of debian packages builds for debian/hurd, on guix that's in the area of 5-10% if we're lucky <makads>how Guix GNU/Linux to install GNOME or Xfce? <janneke>xfce and gnome need services at the system level <janneke>xfce and gnome can also be installed directly from the installer, but ymmv; i often like to install a fairly bare/simple system first and go from there <ulfvonbelow>does anyone know why a package that explicitly passes a #:system argument would seem to ignore package transformations in its implicit inputs, even with #:deep? #t <ulfvonbelow>if I attempt to build wine, with a #:deep? #t transformation applied, I end up with 2 different glibcs as inputs <ulfvonbelow>in my particular case, it ungrafts, removes debug outputs, passes #:strip? #f to every build system that understands it, and prepends a phase with (setenv "CFLAGS" "-ggdb") to every package's phases, except for some in (gnu packages commencement) that are too early in the bootstrapping chain to implement -ggdb. <ulfvonbelow>(I'm already building everything locally, and am tired of having to try modifying a package to support debugging after the fact, and simply "hoping" the exact same problem reappears, or waiting for a long rebuild, etc) <ulfvonbelow>I'll try to reproduce the problem with a more minimal transformation <ulfvonbelow>ah good, turns out it was a fault in my transformation - it was assuming that anything that specified implicit-inputs? #f was too early on in bootstrapping to use -ggdb, but apparently that's specified all the way up to the glibc used by gnu-build-system. <rekado>ulfvonbelow: re injecting -ggdb: you could also use the --with-debug-info transformation and apply that to all packages of interest. <apteryx>does --no-grafts breaks --with-debug-info? <adanska>how does asdf find systems in guix? i cant seem to find any conf files in the usual places, and i assume there is some patching done around it to make stuff avaliable under guix <janneke>ACTION sends a rather discouraging mail with their findings for guix pull / build self to civodul and jpoiret <Guest98>Hello, I am a newbie, how can i switch between WMs? If I install one it doesn't appear in the GDM menu <AwesomeAdam54321>Guest98: Hi, WMs should be added to the packages field of the operating system definition <andreas-e>AwesomeAdam54321, Guest98: Is it not a service? I have this as an entry in my list of services: "(service xfce-desktop-service-type)" <andreas-e>But since I use only one, I cannot really answer the question. I suppose one could add more lines like this in the system configuration. <Guest98>also do you know how can I change display manager? <AwesomeAdam54321>Guest98: The display manager can be changed by changing the display manager service used, for example lightdm-service-type <AwesomeAdam54321>andreas-e: From looking at the manual, DEs and WMs have services but window managers are just packages because they need a display manager to start them <Guest98>Hello, I am a newbie, how can i switch between WMs? If I install one it doesn't appear in the GDM menu <andreas-e>Somehow the concepts are not clear in my head... I realise I am ultimately aware only of desktop environments. <podiki>jonsger: that config generator is a nice idea (though pantherx seems to like their dangling parens everywhere) <RavenJoad>I know NixOS built an installer/config-generator in a recent release. Might be a good thing for us too. <nckx>Did #guix just DoS the PantherX git server. <andreas-e>I would like to, but do not find it. I have the impression of going in circles on their web site. <andreas-e>Got it! By clicking on "recent changes" somewhere. <podiki>thanks for all the texlive updates, every package is in now? <ngz>Yes, the import is complete. <ngz>So `texlive-scheme-full' should be as complete as `texlive'. <ngz>I expect a few bugs in some binaries (one is already reported for chktex). <podiki>I saw the one little one I needed at some point (datetime2-english or something like that) made it in the last batch :) <mirai>ngz: should I report the missing texlive-etoolbox propagation from texlive-microtype or is it _not_a_bug_? <ngz>mirai: it can be reported upstream (in TeX Live), tho. <ngz>mirai: URW Type 1 fonts are installed with, e.g., texlive-collection-fontsrecommended. You may try to add it to your profile? <mirai>ngz: would it be considered overkill to add it within the texlive-updmap.cfg? (I'm assuming by profile you mean that using it as package input via texlive-updmap.cfg is fine as well) <mirai>ngz: do you have bug report examples for these kind of missing propagations? (or a sample package that I can see what a proper propagation should look like?) <mirai>re URW Type 1, adding it to texlive-updmap.cfg didn't cut it, still errors out with the same message <ngz>mirai: There are plenty of "missing" propagations. You can look at the source of almost any TeX Live package and grep for "requiredpackage". You'll see plenty of packages that are not defined as dependents. <mirai>hmmm… I think this URW thing isn't a texlive issue, its with dot <RavenJoad>I am working on adding a system service and I keep running into "service 'my-service' is provided more than once", even though there is only one of those shepherd services. There are 2 shepherd services, but they have different provision lists. <RavenJoad>Both of them extend the shepherd-root-service-type, but that could not be causing the issue, could it? <ngz>mirai: re texlive-etoolbox: The choice of only providing `collection-basic' in `texlive-updmap.cfg' <ngz>was motivated by the need for a minimal common setup for packages. <ngz>Of course, anything can be discussed, and we can extend this setup with other packages. But I doubt there's an optimal solution. When optimal is not an option, minimal becomes nice. <dissoc>my guix pull isnt working. with debug it is showing a constant loop for "locking path ..ghostcript", "wait for a while", "waiting for children", "substitution of ...ghostscript woken up" (repeat). any ideas? <RavenJoad>Can each service-type only have one extension that extends shepherd-root-service-type? <lol234>how to compile packages from source?? <lol234>(like arch's makepkg or slackware's buildpkg) <mirai>RavenJoad: no, see the knot service <mirai>it uses 2 shepherd extensions <mirai>lol234: guix build <package-name> <andreas-e>lol234: If you insist on compiling yourself, "guix build <package-name> --no-substitutes" <lol234>do i have to dc in the drectory? <RavenJoad>mirai: knot-service-type has multiple extensions, but only one of them extends the shepherd-root-service-type. <mirai>RavenJoad: ah, I think the extensions there are unique <mirai>but whatever you're doing to return the shepherd service itself <mirai>you can have (lambda (config) (list (the-first-shepherd-service) (the-second-shepherd-service)) <andreas-e>lol234: Assuming you have installed guix the system or the package manager, the "guix" command knows about the package definitions. So no need to go anywhere. Also, do a "guix pull" from time to time to get up to date packages. I would suggest to start by reading the Guix manual from the website. <lol234>thank you, i rode the manual by the way but the given instructions did not work <mirai>RavenJoad: what part should I look at? <mirai>btw, if you're going to use (format …), this (quote-val val) is unnecessary <mirai>will enclose a string with quotes <RavenJoad>mirai: Sorry, at the very bottom. There are some xe-guest-utils-* and the xe-guest-utilities-service-type. The 2 uncommented service-extensions are causing the issue. When building, Guix says xe-guest-utilities-procfs is provided twice. <mirai>and I believe its (format #f …) <mirai>unless you really want it to output to current-output-port (usually stdout) <mirai>adjust parentheses accordingly <mirai>RavenJoad: right at the top :-) <RavenJoad>Oh. Those format-s are not mine. I have nothing to serialize. <bumble>would anyone recommend how to handle the newish mingetty error seen when doing guix system reconfigure? <bumble>`error: modify-services: service 'mingetty' was deleted here` <bumble>this error occurs at the modify-services section, where several (delete mingetty-service-type) calls are made <RavenJoad>mirai: So everything that extends one service must be a single list in the extensions field? <mirai>must return a single list that is <ngz>andreas-e: I don't like that the gory details about how to find a missing file are in the middle of the section, but I think it is still more readable than the current one, IMO. <bumble>it looks like the several (delete mingetty-service-type) calls can be removed now and a single call can be used... <unmatched-paren>hm, putting a <package> into a Geiser guix repl seems to be causing an error <unmatched-paren>unknown file:#f:#f: encountered raw symbol in macro output in subform socket of (current-location-vector) <andreas-e>ngz: It looks good. I would write a big warning that the two are mutually incompatible, we have already had discussions with people who had installed texlive and additional (well, duplicate actually) packages. <andreas-e>Is the "guix shell" necessary for tlmgr? Should this not be available with any collection or scheme? <ngz>andreas-e: There are small glitches I'm currently fixing, and I'm adding a footnote about minimalism. <ngz>`tlmgr' is available as soon as texlive-bin is, so after any collection/scheme is installed. <andreas-e>I mean, after speaking of collections or schemes and saying that one should start by installing at least one scheme (I suppose this is quite reasonable, albeit not mandatory), one can complete with more collections and individual packages. <ngz>I'm not sure the two are incompatible. <ngz>Combining the two is useless, of course, but at least, doesn't generate errors anymore. <andreas-e>Hm, most people install into a permanent (or *the* profile). I would phrase it this way, and then also drop the "guix shell texlive-scheme-... -- pdflatex ...". <ngz>Just a sec, I'm sending an updated version. <andreas-e>So after saying schemes+collections+packages, give your example. <andreas-e>And then in the end explain how to find the missing packages. <andreas-e>They may not be incompatible, but they also might be. If you end up with a random pdflatex in bin/, all kinds of things could happen. One honours GUIX_TEXMF, one does not, and so on. <ngz>Yup. Combining the two is, ahem, undefined. <ngz>I found it interesting. <andreas-e>Too specific, in particular in the beginning. <andreas-e>I would start with saying: you should choose a scheme, so a footnote that says a collection without a scheme will also work is more confusing than anything. <andreas-e>"The following command lists available *schemes and collections*", to stick with this order. <ngz>schemes are not really more important than collections. <ngz>They are just collections related to size instead of domain. <andreas-e>But they are bigger, right? Should one not at least start with texlive-scheme-minimal? <ngz>texlive-collection-basic is exactly texlive-scheme-minimal, so you don't need the latter. <andreas-e>Well, but conceptually selling the latter is easier, I think. <ngz>And texlive-collection-latexextra is certainly bigger than most of the schemes. <andreas-e>So I would keep the beginning (without the footnote) up to "If needed (...) complete (...) huge collection". Then give your French example. <andreas-e>And then explain what to do about missing stuff. <ngz>(if you're not too busy, you may want to amend my paste instead; of course, if you are, I will update it) <andreas-e>So people would start with a reasonably large collection (depending on their particular needs), and you tell them how to enlarge it when they come across a package they are unable to compile. <ngz>That sounds logical enough. <andreas-e>Notice I just wrote along and did not try to compile it. Actually, I essentially shuffled your text a bit around, and dropped manifests. <andreas-e>I think this is an orthogonal topic: People can imperatively construct their "home" profile or write manifests, and then work directly within the profile or using "guix shell", much as in other contexts. <andreas-e>Although the sheer mass of packages in the texlive realm may require specific dammage control :) <ngz>This looks better! Just a small nit, however. There's the paragraph starting with "If you come across a document that does not compile in such a basic setting,", and then an example with a missing "tikz.sty"... but the basic setting includes that file already. <ngz>I guess we need to remove `texlive-pgf' from the "French system". <ngz>(for consistency, that is) <ngz>The example given in the manual about TeX Live modular system, and targetted towards some French LaTeX user. <ngz>The "French" part is actually a poor excuse to throw in a Babel package. <andreas-e>Yes, it is good to have a French system. Non-French people should be able to make the appropriate replacement. <andreas-e>I need to leave for a while, but will drop in again later. <ngz>OK. Thanks for the update. <ngz>lilyp: On another topic, is it fine to update Emacs packages in master, or should this go into "emacs-team" branch? <lilyp>I merge master into emacs-team regularly, so I ought to pick them up. <lilyp>Be careful with stuff that uses emacs-next though <vagrantc>hrm. running both guix pull and guix time-machine at the same time on a 4-core system with only 4GB of ram ... is a bad idea. <bdju>I probably posted about this some weeks or months ago but is anyone using kaidan? it's broken and doesn't launch for me. I'd like to switch to it if I can make it work because gajim is horribly laggy and crashes often, as does dino. something about gtk on wayland. <lilyp> /gnu/store/56imsri0dgwr45h4fnz3fl7zw00jidlz-emacs-29.1 <lilyp>bdju: maybe it's missing sonnet as an input? <lilyp>that being said, rebuilding sonnet also rebuilds kaidan <bdju>could I work around this by installing sonnet or does the actual recipe need to be changed? <lilyp>not sure – try spawning a shell with kaidan + a bunch of kde stuff until something sticks <lilyp>I'd hazard a guess that it's a missing wrapper <jackhill>hmmm, our GTK package needs to be updated anyway. <jackhill>bdju: have you tried kopete in the meantime? <bdju>does kopete support omemo? <jackhill>bdju: it's the old KDE XMPP client. On, I don't know, I haven't used it since before OMEMO… <bdju>I've been stuck doing guix upgrades since this morning, I think I picked a bad day/time to run them. it was building ungoogle-chromium or something. not sure what it's on now but my CPU's been pegged all day <jackhill>interestingly, Dino seems OK for me with sway. Are you using plasma's wayland? <bdju>almost all my gtk stuff is horribly laggy and crashy and has been for over a year <bdju>somehow gimp is fine but both gajim and dino are barely usable and the gtk file picker crashes when you move your mouse around half the time <jackhill>interesting. Well, I at least don't have the crashing issue, but GTK doesn't detect my monitor geometry correctly <bdju>got into a habit of using scripts with dragon to drag and drop everything to avoid the file picker <bdju>sometimes I fear my own machine is broken in unique ways and I'll never get my problems solved <bdju>doesn't help that guix is niche enough that I could realistically be the only person using certain packages on it regularly, or one of 5 or 10 maybe <jackhill>I'm not that familiar with KDE or Qt though, so not quite sure how to fix it. Just installing sonnet doesn't do it. <mwette>bdju: I'm using sway also on guix system, because I want wayland and vnc. <jackhill>bdju: ok, installing both sonnet and kdeclarative "fixes" it. <jackhill>as lilyp says, it probably needs a wrapper. At least we know what ought to be wrapped in now :) <jackhill>msavoritias: I suspect that pulls in sonnet and kdeclarative into the profile <jackhill>bdju: would you mind opening a ticket for kaiden by writing to bug-guix@gnu.org <bdju>so in the meantime I could just install those two packages to get kaidan working? <bdju>uh yeah sure I can do that <jackhill>bdju: yeah, I think so. Well at least get it to open a window (that's as far as I got) <RavenJoad>I am a little confused about why xen's mini-os input is just an origin and not a package (even just a copy-build-system)? <mirai>can fontconfig handle packages that provide some *-foo.conf files? <nckx>RavenJoad: Why {w,sh,c}ould it be a full package? <RavenJoad>nckx: No idea. I'm not saying it should be a public package, just why was only an origin chosen as the input? <nckx>Because (barring arguments, of course, which there may well be) a package just adds overhead. <nckx>If mini-os is tightly coupled to Xen, there's nothing to factor out and you'd pay twice the storage cost + the time required to unpack/copy files twice for unclear reasons. <RavenJoad>Gotcha. I ask because I am trying to get Xen's guest utilities added to Guix by using NixOS's as a guide. But they have a system service depending on xend, which I cannot find anywhere. I am thinking that I may have to build Xen to find it. <Guest40>if i have 2 identical guix system with the same package input, will they produce the same hash output? <nckx>Guest40: If you're using the same Guix (and channel) commit(s), and the operating-system doesn't refer to any external file-like state and the like, then yes. <nckx>‘guix system build’ should be just as reproducible as other Guix products. <nckx>RavenJoad: OIC. I also see that there doesn't seem to be a substitute for Xen, but that might be my outdated Guix. <nckx>If that's the problem: I'm building it, so unless the package is broken, there should be a toot soon. <RavenJoad>No, Xen has not built on CI for quite a while now. It is broken. <RavenJoad>There is a compilation failure on 4.14.whatever. I'm bumping to 4.17.something, but that has a ld error during compilation. <nckx>ACTION annuls the build. <RavenJoad>I tried building it too, and I got the exact same build error as CI did a couple of weeks ago. <RavenJoad>I should be able to do (file->udev-rule "blah.rule" (string-append package "/etc/udev/rules.d/blah.rule")), right? No wrapping the rules file with plain-file? <Guest40>Fedora and Debian have package split as of <package>-dev for header files and libs used for development and <package> for the software itself. May Guix do this in the future as well? <andreas-e>Guest40: We tend to put it all together, unless there is a good reason to split (size, for instance). <RavenJoad>Guest40: Guix already does this occasionally, but only for the biggest packages or totally optional functionality right now. A package can have multiple outputs. For example, glibc and git have several outputs. <andreas-e>libs are also often needed for software that links to it. And only the headers do not make much of a difference. <Guest40>andreas-e: but isn't that the case with that approach? Well, sure it is only some kib but I guess better than nothing <ngz>andreas-e: Re manual edit: there is one exception we didn't mention about incompatibility between monolithic and modular packages: `texlive' and `texlive-biber' are expected to be installed together, because `texlive' doesn't provide `biber' binary. <andreas-e>Guest40: Well, it is a hassle to create, and I also find it a hassle on Debian that I always need to install the -dev packages on top. (Often with a different name to top it off.) <andreas-e>ngz: Indeed. We might have to add a sentence... Adding exceptions waters down the message :) <ngz>(I kind of like footnotes) <andreas-e>I also wonder about the importer. It is almost not needed any more... But it may be good to add a sentence, because in the future there may be more packages in texlive that people could want to add this way. <RavenJoad>Answered my own question. Not string-append, but file-append works. <Guest40>Since you are talking about texlive. Since the merge of the that texlive branch, it feels xelatex is a little bit slower. Am I just imagine it? <andreas-e>A footnote then be it :) Something like: "No rule without exception! As the monolithic texlive does not contain the biber package, it is okay to combine it with texlive-biber." <ngz>andreas-e: The part about the importer was merged in the "Invoking guix import" node. <andreas-e>Okay, putting it with "guix import" sounds good. <andreas-e>(Actually, the real problem is that people should not add texlive to their collection of texlive-* packages. In reality it should be okay to add a collection of texlive-* packages to texlive, hehe.) <ngz>I'm waiting for the day when we will add (define-deprecated-package texlive texlive-scheme-full) <RavenJoad>Does Guix have a way to run marionette VMs inside another hypervisor? The xen-guest-utilities rely on /dev/xen/xenbus being present, which Linux only exposes when running as a xen guest. <andreas-e>ngz: Actually if you really want all of it, texlive is more efficient. There is quite a bit of latency for downloading thousands of small packages. <andreas-e>And I am keeping the source of texlivetexmf around and build it myself for every update. <ngz>But it doesn't make much sense to keep both. <ngz>Moreover, texlive is not more efficient when you have a flaky connection. <andreas-e>I just build it myself, no connection is needed. But one could do the same for texlive-scheme-full, of course. But I assume it would also take much longer. <Guest40>Is bind9 as a guix/scheme beginner to much to implement as an additional dns solution? <RavenJoad>Guest40: bind9 is already packaged. But if you want practice, it does not look too _horrible_. <Guest40>No, I mean as a dns service for an additional option as dnsmasq or knot <ngz>andreas-e: Of course, but the comparison is not fair. texlive-scheme-full would re-generate all of its runfiles, whereas texlive just copies them. <RavenJoad>Oh. I have no idea if it will be easy to package as a service-type. But so long as it behaves somewhat nicely, it should be doable. <Anadon>Following from a ML thread a few weeks back on minimal packages vs maximal packages, has thought been put towards building packages with options set to enable functionality only available with other packages installed in addition to bare preferences when the remaining support is up to the user? Basically automating Spack support into Guix package <Anadon>That's several hundred emails deep. The gist was that using Guix to build containers was impractical compared to something like Alpine Linux due to building maximal packages by default vs building minimal packages by default. But if Guix were extended to only add functionality which could be used from other packages and then asking the user <Anadon>what features they want from ones which have a preference, then the advantages offered by Alpine and the like would be reduced. 