<atw>I was doing guix package --upgrade and one of the downloads got 410 Gone. What should I do about this? <buenouanq>did anyone ever fix the default .guile-wm that somehow made it"s way into every home dir even if guile-wm is not installed? <atw>buenouanq: what? I've done some work on that package...are you saying this would happen even if you'd never installed guile-wm? <atw>so weird. What's in that file? <atw>I can't imagine why this would be <buenouanq>what gets run every time you make a new user, like to generate their home dir? I imagine it's accidentally being pulled in from there. <buenouanq>If not for this accidental inclusion though, I would have never known it existed - And it might become my favorite wm ever. <atw>apparently Ludo put it in. Interesting. ***ifur_ is now known as ifur
<rekado>sneek later tell atw To get around a “410 Gone” add “--fallback” to the command you were running. <roelj>Err.. I'm running './pre-inst-env guix environment --container --ad-hoc --pure gcc-toolchain libtool autoconf automake make libgcrypt bzip2 sqlite' and I get 'guix environment: error: clone: 2080505873: Invalid argument'. <roelj>What could be going wrong here? <roelj>guix-deamon is running with 'guix-daemon --build-users-group=guixbuild --max-jobs=4 --no-substitutes'. <sturm>Hi there, is anyone aware of a package containing the `dig` DNS lookup program? (or something similar) <sturm>brilliant, thanks marusich :) <marusich>You can install it via something like "guix package -i bind:utils" <sturm>marusich: does the ":utils" on the end mean? <marusich>So, in Guix, a package can have more than one "output". In this case, the bind output has two outputs: "out" and "utils". <marusich>You can see this by examining the result of "guix package --show=bind" <marusich>By default, when you specify a package by name like "bind", you'll get the "out" output. <marusich>To install the "utils" output, you need to specify it. You specify it with a colon, like "bind:utils". <marusich>For more information, please refer to "(guix) Packages with Multiple Outputs" in the manual. <pol38z>hi, can you install guix without root? <ifur>pol38z: not really is the short answer, the build daemon still needs root AFAIK. <sturm>thanks marusich, I wasn't aware of that, very cool :) <roelj>Why does it attempt to download a tarball when I specifically tell it --with-source=/path/to/tarball.tar.gz? <marusich>roelj, what's the exact command you're running? <roelj>guix package -i xcb-util-keysyms --with-source=/root/p7v6lmz2cxv1wjajfic88rvjkpqw696k-xcb-util-keysyms-0.4.0.tar.bz2 <marusich>Huh...and it downloads the xcb-util-keysyms-0.4.0.tar.bz2, anyway? <roelj>It tries to.. but the mirror links seem down <marusich>Does the version of xcb-util-keysyms (shown by guix package --show=xcb-util-keysyms) match the version of your tarball? I don't know if that matters, but if they're not the same maybe that's why? <marusich>Also, maybe try putting --with-source=... before the -i option? I don't think the order would matter, but maybe. <roelj>It matches: ftp://ftp.chg.ru/pub/X11/x.org/individual/xcb/xcb-util-keysyms-0.4.0.tar.bz2 <marusich>Unless somebody knows a better way, the only way I can think of to troubleshoot exactly what's going on would be to debug some source code and see what's going on. <marusich>Looks like the transformation stuff happens in guix/scripts/package.scm (process-actions) <marusich>Your invocation looks correct to me based on what I'm seeing in the manual. <marusich>last guess: does it work when you do "guix build xcb-util-keysyms --with-source=/root/p7v6lmz2cxv1wjajfic88rvjkpqw696k-xcb-util-keysyms-0.4.0.tar.bz2"? <rekado>roelj: re the clone error: does your kernel support user name spaces? <efraim>You want --with-source=file:///path/to/tarvall <efraim>With an indeterminate number of forward slashes <jmd>Is there any way to estimate when a substitute for gtkwebkit will be available? <jmd>It takes longer to build than my CPU can stand in one sitting. <roelj>rekado: Yes, it's a standard CentOS 7 VM. <roelj>rekado: Can I check to be sure? <roelj>marusich: efraim: I did 'guix gc -d `ls -d -1 /hpc/cog_bioinf/guix/store/* | grep keysyms`' <roelj>marusich: efraim: Then I used --with-source=file:///... <roelj>So it could be that the gc action actually removed the derivation that wanted to download it. <marusich>The manual, as well as the test tests/guix-package.sh, suggest that "file://" is not required as a prefix when specifying a local file. <roelj>So the problem is likely that when you start a build derivation, cancel it, and then restart it with the --with-source argument, the argument gets ignored because the derivation already exists? <rekado>scipy fails because we ran out of space: guix build: error: build failed: cannot link `/gnu/store/.links/1m17f17gs7wgvwcq9l6j410v4sawnxw1nr03zgrzizg90jcp6fw0' to `/gnu/store/qwqpbfx4carmdq29ikwslq7m72qbiy09-python2-scipy-0.16.0-doc/share/doc/python-scipy-0.16.0/html/scipy.special.hyp2f1.html': No space left on device <marusich>efraim, rekado, I was curious, so I checked. FYI the "file://" is not necessary because the code goes like this: transform-package-source (in guix/scripts/biuld.scm) -> package-with-source (in guix/scripts/biuld.scm) -> download-to-store (in guix/download.scm), where we special-case a normal path (without "file://") and invoke add-to-store directly using that path. But "file://" works too. So the manual and the test are correct. <marusich>If anything, I suppose we should mention that you can specify a URI like "file:///foo/bar" <jmd>Why does installing a package require building graphviz? <rekado>what package? Are they inputs to the package or to one of the inputs? <jmd>But the package is already built. <jmd>It seems that just installing it is requires all these things. <jmd>Oh mesa it wants to build too. <rekado>do you get the same behaviour without grafts? <jmd>This is silly. Gtk it wants too. <jmd>just to install (say) coreutils <marusich>jmd, did you do a guix pull or otherwise modify a package that might have been deep in the dependency graph, I wonder? <jmd>well I'm doing git pull, and the ./pre-inst-env which is the equivalent of guix pull. <jmd>But I've have a clean tree, I think. <marusich>I think it's hard to say why so many things were being built. But if you were changing the package definitions via git pull, it's possible that something changed deep in the dependency graph which triggered a rebuild of lots of things. <jmd>In that case, somebody must have pushed to master what belonged in core-updates. <htgoebel1>civodul: When fixing build errors caused by the new python build system, should I push them directly or post them for review? <jmd>marusich: But regardless of that, what I really don't understand is why "guix package -i <anything>" requires a build of gtk and lots of other things. <civodul>htgoebel1: unless it's trivial and obvious, please post for review <civodul>we could track them much more efficiently than these projects do since we'd know what they have in /gnu/store and all that <rekado>"potential sponsors always ask for data. When they hear that we have no hard metrics, their offers decrease (or vanish)." <rekado>what kind of sponsors are these? <htgoebel1>civodul: I think it's trivial, but I've been bitten once :-) <mthl>civodul: Sounds like a great idea :) ***htgoebel1 is now known as htgoebel
<jmd>civodul: Any kind of user tracking should be strictly opt-in IMO. <roelj>Can't we track using Hydra? We can see where a request for a download of a substitute comes from.. <jmd>OrangeShark: Perhaps. But on the up side, we wont have to remove the first bullet point at www.gnu.org/s/guix <htgoebel>jmd: I agree: Any kind of user tracking should be strictly opt-in. <ng0>why are you talking about tracking users? <ng0>something with sponsors afaics <htgoebel>As soon as Guix is starting tracking users (per default), I'll leave the project. I'm not going to work for any project keeping users under surveillance. <OrangeShark>I believe it is just a joke, since Django is proposing to track their users <OrangeShark>oh you just joined so you missed the part where civodul mentioned it <ng0>i read the text online <ng0>Django should use the gnu keylogger, I heard it's great <ng0>is gitlab the only git scm with integrated wiki and issue tracker? <ng0>gogs has no wiki afaik, the fedora thing doesn't have one either, .. <ng0>kallithea lacks issue tracker <ng0>i'm not looking for guix this time, other project. <ng0>and gitlab just consumes much memory for an application <ng0>with the requirements of gitlab you start to think they have an easter egg where you can run doom 3. <civodul>jmd, htgoebel: that was a joke, referring to the fact that more and more free software projects take that path <civodul>i'm glad you reacted this way, it's a good sign to me :-) <ng0>can someone merge the downgrade of psyclpc? I'd prefer it to be on that commit until we have figured out upstream how to talk to new pcre <ng0>civodul: it's strange.. an acceptance of the status-quo (which is not actually quo) to actively participate in surveilance rather than to look for other ways to support themselves <civodul>roelj: well you're right: the nginx logs on mirror.hydra.gnu.org already tell a lot <civodul>we can work around it today by having people host mirrors, like marusich did <roelj>civodul: You can count on your ISP to log the same information. <civodul>obviously the question is who/what you want to protect from <roelj>civodul: So multiple mirrors would work.. I proposed a plan for a build host at our HPC facility. <htgoebel>civodul: I didn't take this to serious. But even if it a joke: Wehret den Anfängen (German proverb, according to leo to be translated with "nip things in the bud"). You never know when jokes start to become serious. <civodul>roelj: that'd be cool! a mirror or a build farm? <roelj>civodul: Right now it's a build farm because we're using /hpc as prefix instead of /gnu (for lack of a mount), but that should change to /gnu. <ng0>civodul: i think server based infrastructure must have some kind of control.. you could purge logs after 30 days or something, which is what I did when I ran dns servers. <roelj>ng0: Then again, any traffic coming into your network ports are logged. Putting together a DNS lookup and going to an IP address can bring powerful inferences. <ng0>the real fix is in the future <civodul>roelj: mthl and i were discussing that we should have a web page showing our package reproducibility status, which means we first need two or more fully independent build farms <roelj>civodul: I think we will have enough power to host a build farm. <ng0>or the past, as using gnunet-fs has been discussed since guix started to use a list on gnu.org <htgoebel>ng0: Regarding your pending python patches: I did not know they are still pending. AFAIR most where okay. Just update the inputs ans they should be ready to be merged. <roelj>civodul: I cannot promise anything (yet), so let's talk about this in Berlin, when I know more about our Guixuation. <ng0>you mean inputs to -> propagted-inputs, right? <ng0>civodul: oh, I might bring one or multiple +1's to the meeting. not sure how many of secushare will come <civodul>it can be more productive if we're only among Guix developers, i think <civodul>that said, i'd also like to meet with Secushare folks at some point, maybe FOSDEM? <htgoebel>ng0: Yes inputs to -> propagted-inputs. You may want to try guix lint, which gives you some hints :-) <ng0>civodul: one of us will be at reproducible builds meeting <roelj>civodul: Do you have some figures about what's needed for a proper build farm? (hydra cpu, disk, network usage?) <davexunit>so last night I spent several hours frustrated that my joysticks weren't working in GuixSD <ng0>though I think i'm currently the only one in the intersection of guix and secushare because of what I work on there. nevertheless they are interested :) <davexunit>turns out that the applications I was trying to use with the joysticks use SDL2, and SDL2 uses dbus for joystick support. <civodul>roelj: not very precise, but we could gather figures from hydra.gnu.org <davexunit>so I compiled SDL2 with dbus support, but things still didn't work. <davexunit>turns out that only root can read joystick events! <civodul>roelj: currently it has 1.5T and that is just enough to keep stuff for 4 arches for 80 days <davexunit>and it's not clear how to tell dbus "every joystick can be read by unprivileged users", only "this particular model of joystick can be read by unprivileged users" <rekado>civodul: do you have an agenda in mind for the 12th? <ng0>so we need moar harddisks and/or build farms? <ng0>htgoebel: ok, thanks <ng0>htgoebel: i'll see when I can get it wrapped up <ng0>I hope the dependencies in place will give someone the motivation to finish packaging kallithea and other applications. <ng0>no problem, we're all busy somehow :) <davexunit>they recommend a udev rule that grants the "input" group the ability to read from any input device. that sounds generic enough, and safe enough, to be used in GuixSD. <rekado>I'm using udev rules to allow non-root to access certain devices. This looks similar. <roelj>civodul: Thanks for the figures. That's a lot! <davexunit>rekado: yeah, what I'd like is something that we can do so that joysticks work out-of-the-box on GuixSD <davexunit>it took me a really long time to figure out why nothing could detect the joystick <rekado>FWIW I used a gamepad in Mars on GuixSD. <davexunit>rekado: I don't know what Mars uses, but my guess is that it uses the legacy joystick interface <davexunit>SDL2, and certain other programs, use the new "event" interface which corresponds to the /dev/input/event* files <civodul>rekado: HPC, build farm, 'guix pull', organizational issues, misc questions :-) <ng0>icecat release, finally <rekado>davexunit: Mars doesn't use SDL. <rekado>davexunit: dunno what the lib they use does differently <davexunit>rekado: it must use the legacy joystick API which doesn't have this issue <davexunit>I happened to try out 2 different applications that both used SDL2 <davexunit>I didn't realize they both used SDL2 at first, so I thought the problem was more general <davexunit>despite not being able to actually use my custom joystick in any meaningful way, I was at least able to compile and flash the firmware. <paroneayea>OrangeShark: wait, django is looking at tracking their users? <bavier>I can understand the desire, and it appears they're approaching the topic diplomatically, while suggesting that only anonymous info be gathered <bavier>certainly much nicer than other apps that gather data, that don't mention it to the user at all <paroneayea>what I wonder is: did the Django Software Foundation actually run against a hurdle in fundraising where they didn't know how many developers are using it? <paroneayea>or are they just thinking "boy, we wish we could advertise such a number" <davexunit>that aaugustin fellow on that PR is frustrating <davexunit>"I'm afraid it's a holy war (dare I say jihad?) and it will be hard to escape." <davexunit>"There's little point in gathering metrics if they're disabled by default." <davexunit>people always use this justification for opt-out tracking. <OrangeShark>paroneayea: says that sponsors want hard data on usage numbers <OrangeShark>"Anyone who's tried to raise money for Django knows this first-hand: potential sponsors always ask for data. When they hear that we have no hard metrics, their offers decrease (or vanish)." <paroneayea>and I have a hard time believing that sponsors would think that Django is anything *but* one of the top frameworks in the world <davexunit>looks like django is yet another project that is hostile to distros <OrangeShark>it is kind of weird, don't they want them continuing to improve Django so they get the benefits? <davexunit>saying that pip is the technically superior way to get django, etc. <paroneayea>because what happens if they start gathering statistics at their peak <ng0> "Anyone who's tried to raise money for Django knows this first-hand: potential sponsors always ask for data. When they hear that we have no hard metrics, their offers decrease (or vanish)." I would want solid data for these claims <paroneayea>davexunit: unfortunately I doubt jk-m would be sympathetic to our concerns... I think he gets annoyed with idealists <paroneayea>he's also one of the most vocally anti-copyleft people around <bavier>davexunit: the originator of the PR, "jacobian" <ng0>and complices in global surveilance model. <bavier>ng0: I'm not sure that's what they're going for <ng0>well they are discussing it <ng0>so one part of the community has to have an interest in it <ng0>they may name it differently, but if you just take the facts, that's what it is <bavier>they want some more data, and they seem to want to do so while also taking everyone's privacy concerns into account <reirob>Experienced that a 5GB image is not enough <reirob>so the command: qemu-img create -f qcow2 guixsd.img 5G <ng0>iirc you can expand those disk images, no? <reirob>should be changed to create a bigger image, though I really don't know how much GB is sufficient <bavier>reirob: I think it really depends on how much you attempt to install inside the image <reirob>ng0, yes probably I can. But I came here just to tell this so that somebody fixes the documentation, for other people to not run inside the same issue. Don't know if that's the right place <reirob>I followed just the instructions didn't try to install anything additional <civodul>ACTION starts considering the addition of a Nix vs. Guix section in the manual <civodul>looks like people need to be spoonfed <bavier>we could eventually get rid of it, if appropriate <civodul>i was always naively hoping that people would read the articles, watch the talks, browse the manuals, try the tools, find out by themselves <ng0>reirob: it is the right place. or even more visible, open an bug about it, or send an patch to recommend a new size <ng0>25GiB was what I used with very small source compiled systems so far, so i assume 7 - 10 GiB would be enough, but it has to be tested. <reirob>ng0, thanks. I am quite new to this. Just trying it out. I will try out with 20GB and see how much space is left and tell how much is left. Will need to find out how to report this. <ng0>just email bugs-guix@gnu.org (or what was the address?).. if I'm wrong about this, the right one is on gnu.org/s/guix/ <reirob>So far I managed to make guixsd work on a libreboot thinkpad x60s :-) <reirob>It was compiling the whole night. Then I discovered that there is no VI editor so I added vi to the system config and started to do reconfigure and now it is again recompiling everything for 8 hours <reirob>There is probably an easier way to do this. <bavier>reirob: it shouldn't have to rebuild *everything* <bavier>it should just build/substitute VI, then rebuild the os derivation <reirob>Maybe it doesn't rebuild everything but from what I see it rebuilds all the graphical stuff. Is it possible that it rebuilds because I run sudo guix pull first? <reirob>When I tried to run guix system reconfigure it asked me to run guix pull first <davexunit>there are many packages for which binaries aren't available right now <reirob>yes i think, this is why it has to build. I had to run it with --fallback as well. <davexunit>basically our build farm is in shambles right now <reirob>would be great if the builds that are done by people could be uploaded to the server <bavier>yeah, not in our trust model yet <davexunit>but you could trust certain people that share their builds with 'guix publish' <reirob>like this the next users wouldn't have recompile. Yes that it would be unsafe <davexunit>and use hydra.gnu.org and any number of other servers for binaries <reirob>are here people who are using guixsd daily? <davexunit>I have 3 computers that run it, 2 of which I use frequently. <reirob>Cool. So it can be considered as quite stable, right? <davexunit>reirob: it's stable in the sense that if you reconfigure and something breaks, you can very easily roll back to the previous working system. <reirob>I will first try it with a secondary machine. But I am looking to replace ubuntu with something like guixsd <davexunit>which gives me the freedom to make dangerous changes <davexunit>but we don't have the large community of the bigger distros <reirob>Yes, this rollback thing and having a replicable set-up is what I am looking for <bavier>then you've come to the right place <davexunit>just last night I was making dangerous xorg configuration changes and I created a system that didn't respond to any of my keyboard input <davexunit>so I just rebooted and selected the previous system generation and was back in action <davexunit>so we might ship broken software sometimes, but you can always get back to when things actually worked. <reirob>Is it possible with the concept of guixsd get rid of major update - I mean, with Ubuntu I had did a reinstall every 2 years to the last LTS. But I would like to avoid it actually <davexunit>reirob: right, guix is more similar to the rolling release model <davexunit>we still have official versioned releases, and in the future we might have more conservative "stable" series. <davexunit>but being on the bleeding edge is just tracking the master branch of our git repo. <davexunit>'guix pull' is just downloading the latest master <reirob>these official versioned releases are more for new users, right? <davexunit>you can install a new system with it, then upgrade to the latest in master once you have the initial install working <davexunit>but yeah, for security reasons and such, it's best to keep up with master if you can. <davexunit>guix sees a lot of heavy development, so things roll quite fast. <davexunit>I can't keep up sometimes, so I update my system less frequently. <htgoebel>civodul: What is the schedule for 0.12.0? <jmd>Yeah that's the down side. If somebody commits something heavy it can mean that it takes a looong time to update things. <davexunit>such commits go into branches other than master <htgoebel>I'm preparing a php-fpm service, which might be good having in 0.12.0 since it may attract new users and developers <ng0>htgoebel: in python, everything even non-python applications, are propagated, correct? <ng0>i should read the new documentation then <htgoebel>ng0: Only all python packages used at run-time are propagated. <htgoebel>Other libs and binaries should be found as usual using PATH an rpath AFAIK <davexunit>they should use absolute file names to the binary used during the build <davexunit>that way they won't break if the user doesn't have that particular program installed or uses a different version <davexunit>unfortunately, python programs, and really anything using a non-autotools-like build system, will have this problem all over the place. <htgoebel>davexunit Is this described in the manual? (I can't remember to have this read.) <davexunit>the problem is basically nonexistent for any software that uses a configure script <davexunit>because usually the lookup the absolute file name for the program they are after and substitute that into the code. <davexunit>yet another example of autotools being leaps and bounds better than the alternatives. <ng0>WARNING: (gnu packages tor): imported module (gnu packages dns) overrides core binding `bind' <Apteryx_>Just read the part about pronouncing Guix and thought that was hilarious. <ng0>should this be imported differently? <davexunit>ng0: that's okay, but we should add "#:replaces (bind)" to the define-module form in that file <civodul>we should rename it to something else, even <ng0>that's sometimes used <ng0>i think that might not even be necessary <ng0>i'll try wthout bind first <bavier>I'm almost finished with a clamav package <bavier>but I need to figure out still how to get its database update to work <dvc>civodul: why is the root file system read from the --root command line and not from the mounts list in linux-boot.scm? I'd like to mount a btrfs subvolume, so should I support a --root-flags or should I use the spec list? <lfam>dvc: civodul isn't away ATM. Use sneek :) <jmd>How many dependencies must a change have before it goes in core-updates? <lfam>If it's less than that but potentially disruptive, it should have it's own branch IMO <lfam>That 2nd it's should be its <lfam>We should put this information in the manual if we haven't already <lfam>Yes, HACKING is probably the right place <dvc>lfam: what's sneek? I doubt you mean sneek.io? =P <paroneayea><dvc> sneek: later tell civodul (what you want to say here) <lfam>Wow, sneek.io looks like a damn nightmare <dvc>lfam: do you want me to remove flex-2.6.1 with my flex patch? <lfam>See all your team mates pretty faces on one screen as Sneek takes your photo at a regular interval (which you control). Yes, we all pick our noses, there's no shame." <lfam>Great, now even when I'm alone I have to think about how I lookj <jmd>What happens if you tell sneek to tell sneek something? <dvc>sneek: later tell civodul why is the root file system read from the --root command line and not from the mounts list in linux-boot.scm? I'd like to mount a btrfs subvolume, so should I support a --root-flags or should I use the spec list? <lfam>Then sneek goes on vacation <paroneayea>sneek: later tell sneek to tell sneek to tell sneek <lfam>sneek: I used your botsnack as a doorstop <lfam>Sneek is always so cheerful! <lfam>No matter how bad the news is :) <lfam>The two items I see on this subject are actually about the version that we already use, 2.6.1, so I think it's okay to simply update them <dvc>I got it from trying to compile kde-frameworks packages with flex-2.6.2 <lfam>Has anyone reported this to the KDE people? <dvc>I haven't, I guess I should if I want it fixed... :) <lfam>IMO core-updates is the place to make breaking changes and wait to see the result. So I would just do the simple update. We can fix the problems if they arise later, when we try building the branch. <lfam>OTOH, if you know about specific issues, and you are willing to manage the extra complexity of multiple flex versions, I don't see the harm in doing that now <dvc>lfam: ok. I removed flex-2.6.1 <jmd>sneek: later tell sneek to tell sneek something. <ng0>does someone wnat to take on putting some finishing touches (substitute stuff) to an package for arm (the tor arm, not arm architecture)? I did something and realized later I have no intention to finish it <paroneayea>I got some really useful info/feedback on hosting at rackspace, and permission to post it to the list <ng0>has someone tried the upgrade of icecat? <bavier>buenouanq: yes, 45 was released today <buenouanq>I didn't think so - I installed and moved over to GuixSD and that's what was there. <ng0>no, real release this time <buenouanq>I hate it, but the old one was no longer even in the repos. <bavier>buenouanq: oh, right, we've had a beta 45.3 version for a bit <bavier>idk, hopefully it's less crashy too <ng0>if you still can't edit the search engines, I'll have to come up with an patch myself <buenouanq>we fixed the crashes, you have to change gfx.canvas.azure.backends and gfx.content.azure.backends from cairo to skia <buenouanq>ng0: you can add more, but you can't switch between them with f4, and it doesn't stay with whatever you just selected via the mouse, it only uses that for the current search <ng0>i don't want to add more <ng0>the problem is i can't edit the search engines i add <ng0>which is default in firefox since forever <ng0>so i add an searx instance and chnage the query string to its onion for example <ng0>works in firefox, breaks in icecat <buenouanq>this has been like watching a loved one get into heavy drugs and slowly ruin everything they had going for them <buenouanq>by the time you start to think you should maybe be worried, it's already too late <ng0>well you can stay on the cve ridden old versions if you like to :) <buenouanq>I'm still only seeing 45.3.0-gnu1-beta though... <ng0>yes, in guix.. what i meant is upstream release <buenouanq>is whatever you're talking about so new that it hasn't made it into the repos yet? <buenouanq>note the cairo skia thing though if it still crashes <buenouanq>someone should change this in the guix release <buenouanq>I've found an interesting problem. In Transmission (GuixSD with stock Gnome), the rightclick `open folder' option opens Gnome"s disk usage analyzer Baobab rather than the file manager. <buenouanq>I've no idea where to even start looking for something like that. <buenouanq>first I guess I should ask someone to confirm, so we know it's not just me <rekado>I hope articles like that convince people to take bootstrapping issues more seriously <ng0>i can confirm it on multiple applications <ng0>i don't know if it was fixed at some point <ng0>i can check it out on a gnome system now <bavier>rekado: thanks for sharing. I'm collecting articles like that <ng0>buenouanq: when Iright click the open folder buttion, nothing happens <ng0>is your guix recent? <ng0>*diud you recently issue guix pull and/or guix reconfigure i meant <civodul>rekado: i think we must work to get people to publish a statement about bootstrapping next wekk <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, dvc says: why is the root file system read from the --root command line and not from the mounts list in linux-boot.scm? I'd like to mount a btrfs subvolume, so should I support a --root-flags or should I use the spec list? <buenouanq>wait, I just did a pull, but that doesn't on it"s own update anything installed does it? <civodul>dvc: the reason is mostly that i thought it can be useful to change the root fs from the GRUB command line, and it's what's usually done <dvc>so does it make sense to add a --root-flags flag to the initrd? <ng0>buenouanq: you have to issue guix package -u (you can add -n to see what would be build and what updated) to update a users profile software <ng0>and the reconfigure updates stuff like gnome etc <ng0>and the services etc <ng0>*guix system reconfigure <civodul>well it's not exactly next week, but almost ;-) <bavier>civodul: oh cool, I didn't realize there was another one coming up <civodul>i want to get people to think about bootstrapping <buenouanq>In GuixSD, is there any way to not have the graphic login, and start x manually with startx? <bavier>civodul: yeah, I've been doing quite a bit of research and trying to collect my thoughts <bavier>there are a lot of different paths that could be explored <civodul>if you have ideas of things we can get other projects to consider, or things we could lobby for, that's the right moment <civodul>my take was that we should work on a "best practice" document for compiler writers <bavier>the more research I do, the more I feel like I'm still very new to this area :) <ng0>i wish I would've expended my stay in berlin for 3 more days, but getting some friend to care for the cat, now i have someone to do that for 2 days.. rb meeting should be interesting. <bavier>civodul: yes, a best-practices would be useful <bavier>the hard part will be in convincing developers that its useful <bavier>and different groups have different threat models <civodul>also there's no consensus on what the best practices are <civodul>i would say the compiler has to be bootstrappable from C, but that is debatable <bavier>but other developers might just scoff that that'd be too much of a maintenance burden <bavier>but in general, trying to minimize the bootstrap path would be helpful <bavier>at this moment I've convinced myself that implementing a C compiler in Forth will provide the greatest benefit <bavier>but I'm an expert neither in Forth nor compiler implementation (yet), so we'll see how that goes :) <buenouanq>why not just stick with and rewrite everything in FORTH ;3 <bavier>buenouanq: that thought has crossed my mind ;) <buenouanq>FORTH blew my mind the first time I discovered it - I should get back to playing with it at some point. <ng0>go forth and write forth :)