<lfam>Every audio/visual production company is looking for products to buy and they aren't satisfied with any of them <degux>what are problem with github and "guix refresh"? <lfam>Btw mbakke, I've used Pulseaudio / pavucontrol a bit for this pipewire-esque task of moving audio streams around, and it works great. Way better than what's built-in to MacOS <mbakke>oh really, I thought the macOS APIs A/V APIs were pretty good <bavier[m]>degux, just what it says, github has a rate limit. Check the guix manual for an env var you can set to your API key for unlimited access. <mbakke>degux: you can create a GitHub API token and set GUIX_GITHUB_TOKEN to avoid the rate limits <degux>do not want register on microsoft github to update my GNU guix machine ) <lfam>mbakke: They are fine but "just an API", if I understand correctly. Whereas with Pulse, it's built-in to the OS, so the application doesn't need to have a UI that is aware of it <lfam>There are nice 3rd-party solutions for MacOS <lfam>I can go into pavucontrol and route audio between applications. It's nice to control it all from the same place <mbakke>degux: that's an interesting point, I wonder if we could request an API key for all Guix users. <lfam>degux: `guix refresh` is not used for updating your Guix machine. <degux>maybe need to change github to own mirror? <lfam>degux: To update your Guix System machine, you can use `guix pull && sudo -E guix system reconfigure /etc/config.scm`. And also `guix upgrade` for the user's own packages <lfam>`guix refresh` is a tool for Guix developers <lle-bout>nckx: it's kind of crazy the amount of patches coming in everyday, can't wait to help review them <lfam>Btw, my name starts with a lowercase 'L', not an uppercase 'i' ;) <lfam>Let us know if you have more questions, degux <lle-bout>nckx: is it OK you think to add a GNU Guix offload machine to the official CI that doesnt run with officially committed code? <lle-bout>nckx: e.g. we could setup the machine you got from OSUOSL with my wip-lle-bout-le1 branch <lle-bout>nckx: it's bootstrap binaries are not reproducible but you can rebuild them yourself from source to make sure <lle-bout>luis-felipe: yes it's awesome!! where can we buy it? <lle-bout>luis-felipe: is "libray" in the song on the back a typo ? shouldnt it be "library" ? <luis-felipe>lle-bout: It's a typo poem. From common typos in package definitions. <lle-bout>luis-felipe: okay! thanks for the link, had seen it in the chat in the mean time :-) - About the T-Shirt, I regret there's not a more visible GNU mention or logo though :-D <leoprikler>pineapples: It's time to write Netbeans, but for Javascript. Let's call it… WebBeans. <luis-felipe>lle-bout: I'll have that in mind for a next design. I actually mention GNU everywhere I can, but yeah :) <pineapples>leoprikler: Don't give this sort of ideas; somebody will take you seriously <leoprikler>One are so out of the world, that no one will ever take them seriously, and two are those, that I believe someone else will already have thought about in a very sincere fashion. <pineapples>In this case, the next (un)logical step is a thin, Electron-based client that fetches a web app from the Internet for every "desktop" application on your computer. DRM at its finest <lfam>It's something that GNU should focus on. I don't know many "non-techie" computer users who prefer to use native applications over web-based replacements <lle-bout>web based IDEs simplify things a lot for companies and their employees, suddenly they only need to give out thin clients to their employees and rent servers with as-you-use pricing. It also means employees don't lose time setting up their own machine, for each and every project.. but GNU Guix if generalized can also in a very elegant and respectful way achieve that. <lfam>Native applications were easier to use, until they weren't <lfam>Local files were more convenient, until they weren't <lle-bout>For companies, local files are intellectual property loss risk <lfam>And, they are annoying to move around to different users. Google Drive offers real utility <lle-bout>I still "struggle" to share files to my peers with onionshare some times <lfam>Already, a huge number of corporate office workers do all their real work over VNC <lle-bout>And the user I am giving it to needs Tor Browser <lfam>They have their laptops at home these days, but they are just terminals <lle-bout>Amazon Workplace or Citrix XenApps is very common yes <lle-bout>But let's be honest, this isnt the same monster, we can't be at the forefront of technology on every subject with GNU-spirit projects and ideas that works for real people. There's nothing we can do to prevent people from doing these things. <lfam>To replace these things with free software, there are so many missing pieces, at every level of the stack. So I think we have to be pragmatic in our advice, and focus on building the movement <lle-bout>There's Eclipse Che by Red Hat but really unfortunate it's not AGPL instead. <lfam>At least it's a free license <lle-bout>The permissive license for that project specifically makes it so easy to abuse and strip user rights along the way <dannym>vagrantc: Did you make the image to boot the novena with using guix system disk-image? Which image type did you use? <dissoc>how do i add authorized keys to the (operating-system ...) in config.scm? am i supposed to modify the guix-service-type do append the keys? would i likely use (local-file "something.pub") ? what format is (authorized-keys expecting the keys to be in? <dissoc>im following the invoking guix deploy page. the generated key is in this unique format with parenthesis. <mroh>dissoc: try something like `(define %my-keys (append (list (local-file "key.pub") (local-file "key2.pub")) %default-authorized-guix-keys))` and than in guix-service-type: `(guix-configuration (authorized-keys %my-keys))` <dissoc>mroh: it works! at some point i had it working but i made changes and it stopped. but all is good now. thank you! <charles`>lle-bout do you still need help with Emacs? <lle-bout>I still do, you said geiser and company? <lle-bout>I have a question, do we always need to M-X run-geiser <lle-bout>charles`: so here we are, I installed Emacs with company and geiser, I also installed spacemacs-theme so it looks great and readable in my terminal. <lle-bout>I'll try some GNU Guix now, any tips for company+geiser best experience? <lle-bout>company code navigation shortcuts would be really useful, also inline docs - is that possible? <lle-bout>Inline docs especially for builtin GNU Guile functions, that would be sooo cool <charles`>I'm not very experienced with guix. I find the only thing I need to do with company is add a keybinding for `company-complete` <charles`>(global-set-key (kbd "C-/") #'company-complete) <lle-bout>charles`: I use Fedora as my main OS right now, so I installed Emacs on there, not using GNU Guix at all but for reading GNU Guix's GNU Guile code I mean :-) <charles`>when you press that after typing part of a function or variable name, you will get a dropdown <charles`>geiser should provide (through Eldoc) function arguments at the bottom (mini-buffer) <lle-bout>Right, but could there be English text documentation of what the function does you think? <lle-bout>Like a Magit-Popup of the info section in GNU Guile's manual, don't know <charles`>well, C-/ is default to complete based on other text in the buffer. so I bind it to company-complete to, the more powerful version <lle-bout>Do we need to run-geiser or it does that all automatically when it needs to? <charles`>I've seen other geiser like thing provide the documentation in the minibuffer. let me see <lle-bout>well - thanks for looking that up for me - I could do more research even though I've done a lot already. I've had my Emacs try-hard period which I ended because unproductiveness. At least this gave me the hang of it (I know the basic shortcuts :-)) <charles`>do you have geiser working? It required guile2.2 <charles`>on fedora the package is guile22 and the binary command is guile2.2, so in emacs you should M-x customize-variable RET geiser-guile-binary RET and change the value to be guile2.2 <apteryx>Hello Guix! IceCat question: there used to be a button on the left of the URL bar which could be used to configure the content blocking preferences on a particular site, but I can't find how to do this anymore? <lle-bout>Yes Fedora's guile package gave me lots of trouble compiling GNU Guix notably.. <lle-bout>apteryx: Did you change version since then..? Maybe that was patched out for some reason? <apteryx>lle-bout: the change has been quite some time ago, I think it was with one of the major version bumps. <lle-bout>apteryx: I can't see it either. But you can configure in about:preferences#privacy with "Manage Exceptions.." I guess, not user friendly I know. <charles`>lle-bout the number 1 feature of geiser is the ability to put your cursor over a definition and press C-M-x to invisibly send it to the REPL. <charles`>lle-bout you said you're using terminal Emacs? you can M-x menu-bar-open RET to to navigate to the geiser menu and see a lot of documentation related geiser functions. Look up symbol descriptions, module descriptions. <lle-bout>charles`: wait a little, still doing the first thing <apteryx>lle-bout: in that 'Manage Exceptions...' you can only remove existing entries, not add any, unless I'm missing something. <lle-bout>charles`: somehow geiser is installed but the variable doesnt show up <lle-bout>apteryx: I suggest using Ublock Origin, it probably works better than Firefox's built in, and you can disable that latter one entirely <lle-bout>charles`: "send it to the REPL", what does that do about surrounding context? <charles`>lle-bout when you M-x list-packages RET and search for geiser is it's status installed? <lle-bout>charles`: yup: geiser 20201202.1922 installed GNU Emacs and Scheme talk to each other <charles`>lle-bout by surrounding context, do you mean things like closure? <lle-bout>charles`: variables in upper scopes, other libs? A line of code is often going to depend on them <charles`>the surrounding contexts should already be evaluated in the runtime <charles`>If I have (define x 0) and (define (incx!) (set! x (+ x 1))) I have to evaluate the first before the second <charles`>try M-x customize RET and type guile in the search bar and press enter <lle-bout>charles`: it can't find it, neither can it find geiser, I tried earlier <lle-bout>alright so it does evaluate context automatically too <charles`>no, I have to do C-M-x on first form then another C-M-x on the second one. or, if they are in the right order, I can evaluate the whole file with C-c C-b <lle-bout>charles`: also C-/ is "Undo" for me by default <lle-bout>somehow it goes over the custom set company keybinding <lle-bout>charles`: I noticed run-geiser is present though, but not the customize things <charles`>what does M-: geiser-guile-binary RET give you? <lle-bout>charles`: Lisp error, (void-variable ..) <charles`>that is strange, did you try run-geiser? <lle-bout>charles`: I tried yes but it can't start because wrong guile version heh <lle-bout>charles`: ahh after running it the variable exists <lle-bout>charles`: when I press M-/ it now says Company not enabled so I guess I have to find how to enable it <charles`>well, we have to do this the hard way. Go you your init file, and add <charles`>If you already have a custom-set-variables, just add '(geiser-g...) to it <lle-bout>charles`: when I went to customize menu and set it to guile2.2 it automatically added it to my .emacs <lle-bout>company-mode, right. So geiser REPL window doesnt have it enabled by default <charles`>M-x customize-variable RET prog-mode-hook RET then add company-mode <charles`>that will turn it on automatically whenever you open a scheme (or other programming mode) <charles`>btw a better way to bind M-/ key is like this <charles`>(define-key company-mode-map (kbd "M-/") #'company-complete) <charles`>that way when not in company mode, M-/ will revert to the default behavior <lle-bout>charles`: so I found out about which-key because I'm still a newbie - how would I do to enable which-key always? <charles`>lle-bout for which-key, by always, do you mean in every buffer or every you restart Emacs? <lle-bout>charles`: I mean I always want minibuffer help for command sequences to show up when I pause typing them no matter what <charles`>lle-bout I have never actually used which-key, It looks like it is mainly for prefix keys but M-x which-key-show-top-level might do the trick for you <lle-bout>charles`: Spacemacs for example opens a popup automatically showing possible command sequences and their documentation when you pause typing, it's so useful <charles`>I don't think I can help you with that. Do you have geiser working? <lle-bout>charles`: yes I have the repl, and completion with company works I guess. Will try on GNU Guix sources in a min <lle-bout>charles`: I believe what I asked was solved by adding: (which-key-mode) in my .emacs <charles`>about documentation, I don't see a super easy way to make it appear as a popup, or in minibuffer, but consider binding a key to geiser-doc-symbol-at-point it opens documentation in an Emacs window window <lle-bout>good night! (I missed you..) - doc-symbol-at-point is good enough I guess. <raghavgururajan>sneek, later tell charles`: [1] ./pre-inst-env guix system vm my-config.scm [2] /gnu/store/…-run-vm.sh -m 1024 -smp 2 -net user,model=virtio-net-pci <lle-bout>if that inspires anyone, someone said to me they would very much like something like Gentoo's USE flags in GNU Guix - how would that translate into GNU Guix? <smithras>lle-bout: Oh I remember talking about that at the Guix Days in February. Ludo just sent out an email recently about that I think <vagrantc>dannym: the original novena image i created with "guix system init" and have done "guix system reconfigure" ever since... <guix-vits>vagrantc: sorry: did u enc. any sig. issues on guix@aarch64 on recent commits? <vagrantc>guix-vits: haven't tested any aarch64 machines lately ... but if i had, i wouldn't know what you meant without asking you to spell out your words :) <guix-vits>lle-bout: that would be nice, if not everywhere. especially for linux kernel: FEATURES = +nftables,-selinux,-wifi... <guix-vits>btw, *make-linux-libre already (as it's a procedure) has parameters, including kconfig. it's amazingly useful. <sneek>civodul was last seen in #guix 11 hours ago, saying: ooh!. *civodul was head-down finishing a patch <mothacehe>heh I think I missed it too then, I was repairing the washing machine :p <cbaines>I've still got time now if you want to chat, I don't have much to talk about though <civodul>same here, but maybe we can talk about the next steps? <civodul>i had another idea (an old idea) on how to improve Cuirass throughput <jas4711>hi! newbie question: how do i list the installed packages in the system profile? <efraim>guix package -p /run/current-system/profile --list-profile *efraim is pretty sure, on mobile ATM <zap>efraim: I think it's guix package -p /run/current-system/profile -I ***zap is now known as zzappie
<jas4711>i tried reading the manual but there is a gap between 'guix package' and 'guix system' I think <jas4711>maybe 'guix package --list-profiles' could list the system profile? just an idea. that would have helped me but maybe it is architecturally incorrect <dannym>vagrantc: Hmm, because it seems disk-image with u-boot-novena-bootloader doesn't use its bootloader installer (it's #f in the resulting guile code build side). That's why it fell back to grub-efi (!) <dannym>So I tried to cp gnu/system/images/pine64.scm gnu/system/images/novena.scm and s;arm64;arm32; and so on, and then guix disk-image -t novena-raw novena.scm, and then it tries to compile a cross-compiler for armhf ON armhf <dannym>Was that new disk-image api stuff tested? Sigh... <mothacehe>dannym: it's been only used in a cross-compilation context for now <mothacehe>some work would be needed to make it do the right stuff when directly on a native machine <kisaja[m]>how to get http certificaates working in container <mothacehe>that's basically just unsetting %current-target-system <dannym>So how do I use the old version that did work? <mothacehe>you can time-machine, but it's more or less a one-liner to fix it <vagrantc>oh, it only supports cross-compilation... crazy. *vagrantc had been meaning to look into it recently <lle-bout>hey, can anyone successfully build vim on latest master? <dannym>mothacehe: What is the one line to fix it? <vagrantc>e.g. making a pinebook.scm image with a "simple" desktop like sway. <efraim>I was going to revert my most recent vim change, with the testsuite. Seems too brittle still and fails the last time I tried on aarch64 <lle-bout>efraim: yes thank you while we figure this out. <PotentialUser-62>Hi, I installed Jupyter Notebook via pip, but does not work now. What is the solution? <lle-bout>PotentialUser-62: Hello! How does that relate to GNU Guix? <efraim>I think if you try to make a raw disk image it doesn't cross compile to itself...maybe <dannym>efraim: I tried--with a guix system disk-image -t raw it uses the grub-efi installed even though I'm using u-boot-novena-bootloader <lle-bout>PotentialUser-62: FYI there's too little information in your question to give any help <civodul>PotentialUser-62: hi! i recommend installing it via Guix: guix install jupyter python-notebook <mothacehe>dannym: yes, I should really rename "raw" to "raw-efi" <PotentialUser-62>llw-bout: Since I used this easily in my previous system (Debian), I guessed that this was a Guix issue. <dannym>Also maybe as a heuristic (not sure), armhf (not aarch64) machines can't use EFI directly anyway <dannym>So it makes no sense to let it no matter what you specify <dannym>Ok, it's building without cross-compiler now <mothacehe>the default could be arm32-raw image type on armhf <lle-bout>PotentialUser-62: GNU Guix's a bit weird and unconventional compared to other systems so some software's assumptions may no longer be true but whether that is a GNU Guix's bug and other software's bug is not so certain.. I believe you can just use the GNU Guix's recipe to install jupyter and python-notebook like civodul said. <dannym>You have to decide that--but it would be better than the current thing <dannym>whether the magical default is good <dannym>But whatever the case, defaulting to EFI on armhf doesn't do anyone any good <mothacehe>yes sure, this native part clearly needs some more work, having no machine on those architectures at home doesn't help me though <dannym>The reason I started contributing to Guix all those years ago in the first place is in order to have trustable packages. All x86_64 machines have binary blobs even before the main CPU comes out of reset. There exist ARMHF machines which don't have *any* blobs in that chain. <dannym>So at least for me, it's much more important for it to work on ARMHF than on x86_64 (or even aarch64) <dannym>I'm not gonna prepare disk images for a trustworthy system on an untrustworthy system by cross compilation <mothacehe>Yeah, I get that. What about having a "system" field in (gnu image) that would describe the expected system of the image. When one a foreign system, "guix system" would automatically cross-compile and when on the right system, build natively? <bonz060>Hi guix! How would you use the graph API to draw a graph inside the REPL? I want to add an extra phase in some package definition that generates that graph and stores it in some static dir... <bonz060>I'm kinda lost when I tried poring through "guix/graph.scm" <dannym>I'm not sure which is better for reproducibility--do people want to be able to guix challenge the images that result from cross-compilation vs. non-cross-compilation ? Does that even make sense or will they be different anyway? <dannym>guix-vits: A much cheaper and much slower armhf machine (also everything is free software, including the ROM loader--it's on github :) ) is the Banana Pi M2 Ultra <dannym>We develop Mes for ARM on a Banana Pi M2 Ultra <dannym>But since we are starting to bootstrap the actual Guix using Mes for ARM now, that's a "little" slow <dannym>So I'm migrating it over to Novena right now <dannym>mothacehe: But yeah: My gut feeling says yes, a "system" field would be nice. <mothacehe>dannym: people could pass "--system" and "--target" arguments to force native/cross image building and challenge images. But if nothing is passed, "guix system" would try to do the right thing. I think having a bit of magic is necessary here so that user don't have to understand the differences between system/target, what's a cross-compilation triplet and so on. <dannym>I see. Yeah, if it's overridable anyway, sane default is much better <pineapples>dannym: Pardon the question, but do these armhf machines you mentioned: do have their GPU stack fully-liberated, yes? That means they can run Wayland just fine? <dannym>Also, what's with these manual agetty services in gnu/system/image ? tty-auto would set one up anyway if you passed kernel-arguments console=ttyS0 <dannym>That's necessary for both ARM and non-arm, so not sure why there is manual stuff going on there <dannym>pineapples: The Novena, yes. A stretch goal was to write GPU drivers, and they reached and far exceeded it <dannym>I lot of other projects use vivante gpus because of that now <dannym>pineapples: And the Banana Pi, yes, there are free GPU drivers for all parts, but the 3D graphics part is under development still ("lima") <dannym>2D graphics is entirely free software there though <dannym>3D graphics can be free software, but not finished <dannym>Quake does run really fast and correct on it, though :) <raghavgururajan>sneek, later dannym: I should be done with glib and cairo tomorrow. Btw, were you able to review v4 patch-set for pidgin? Thanks! *raghavgururajan gonna join sneek for sleeping *raghavgururajan meant that he's gonna fall asleep too <guix-vits>pineapples: btw, mali gpu has troubles with wayland, but x-org not working at all (for me). xwayland works. <guix-vits>so afaik, question isn't "will wayland play nice on that board", rather "will it has any graphics at all" :) <dannym>Why are you using the mali gpu with xorg ? <dannym>It works by rendering the 3D scence into an offscreen 2D bitmap <dannym>That doesn't sound like something Xorg needs <guix-vits>this is my gpu. idk what else i can use for xorg. <dannym>Usually there's a 2D blitter silicon next the ARM core <dannym>The thing on sunxi that actually displays stuff on screen is called the display engine (DE) <dannym>But as I said, that's dependent on vendor <guix-vits>i saw messages from panfrost on tty, when exiting sway, thought mali is ruling all my graphics. ok <dannym>It's just different from x86. Took me some time to get used to as well <pineapples>guix-vits: Which board does it concern? Novena or the Banana Pi M2 Ultra? Asking because I haven't looked into their specs <guix-vits>pineapples: in theory, my board rockpro64. idk novena and banana. <pineapples>dannym: Will you be getting any of those boards any soon? <pineapples>dannym: Preferably Novena. I'd love to have someone confirm they work with Wayland on Guix System <dannym>I'm trying to set it up right now <dannym>"Right now"="for the past 5 days" <dannym>Which is not Novena's fault, but Guix's <dannym>The shipped sd card that Novena delivered worked just fine immediately <dannym>Actually, nlnet has the Novena, technically, I guess :) <dannym>But it will be used as a build machines for GNU Mes for ARM, so I don't think there will be a gui on it ever, wayland or not <guix-vits>PotentialUser-87: are u infamous porn spammer? <pineapples>dannym: Too bad for me :( I can't buy one until I, for sure, know it's gonna run Wayland just fine <dannym>Guix installation experience 2/10 <mothacehe>I just proposed a patchset regarding what we discussed earlier <pineapples>Now.. If you could.. you know.. install Sway on it, and just run 'sway' if possible. Not asking to, but would be really nice <leoprikler>PotentialUser-87: is this really something you needed to screenshot? <dannym>pineapples: I can try to do that later after I've reviewer mothacehe's patches, pushed my gnu/system/images/novena.scm, migrated the Guix system to the SATA drive (or did guix system init again ? Not sure) <dannym>pineapples: But I've never used sway before--how would I test it? <guix-vits>dannym: add elogind-service, then on tty `sway`. if resolution is correct, u win. <guix-vits>(for user, dmenu or analogues needed, also cp the default config, and place it to ~/.config/sway/config, and edit it) <pineapples>guix-vits: Copying the default config is not necessary, Sway will read the config stored in the /gnu/store path automatically. dannym: Just add elogind-service, run `guix install sway` and `sway`. To close it, use the META(Win)+Shift_L+E key combination. <leoprikler>That's the expected result from running --version <guix-vits>pineapples: default has xterm as default. one will neccessarily want to edit it! <pineapples>Also, thanks a lot again! You're really helping me out right now. I'll gladly wait until you're done with your assignments <guix-vits>but for test, all in (...) not needed, ye-ye. <leoprikler>If you don't know how to run jupyter, using -h [it does not seem to support --help according to this message?] should give you some pointers as well <pineapples>guix-vits: The default config switched to alacritty recently, but yeah, like you've said yourself, a terminal emulator won't be needed for the test, let alone exit Sway <dannym>mothacehe: Yes, natively on armhf-linux with your one-liner target patch <guix-vits>pineapples: and if dannym has no mouse, tty2 and killall sway :P <pineapples>Oh right. It needs a mouse by default unless configured otherwise <guix-vits>'cause Shift+... seem to not work with keyboard <pineapples>That's kinda a bummer that swaybar's confirmation dialogs can't be manipulated with a keyboard. Not very i3 to me <dannym>And with a fix to qemu-minimal :P <dannym>mothacehe: I've just added gnu/system/images/novena.scm to guix master <dannym>That's the one that worked (after other patches to guix that have not been pushed) <dannym>I don't really like the agetty block in that gnu/system/images/novena.scm, but I used pine64 as a template and there it was in there <dannym>IMO it shouldn't exist and there should be a (kernel-arguments '("console=ttymxc1")) instead <dannym>But who knows what the pine64 committer has seen ;) <guix-vits>PotentialUser-87: `man jupyter`? i think most there do not know what it is, just like me. <dannym>In fact, I'll try removing it and writing a new sd card--I'm on the serial line anyway <mothacehe>dannym: yes I vaguely remember there's a reason to it <dannym>(It worked. Pushed update to gnu/system/images/novena.scm on guix master) <dannym>Now we have both commits in the history, so can be changed back and easily <dannym>mothacehe: Yeah, but I fear the day two agetty start up on the same serial line--you're not going to be able to log in <dannym>Because one agetty with get character 1 you type, the other agetty character 2 and 3, the first one character 4 <mothacehe>yeah, anyway the reason is not commented, maybe that's not need anymore anyways, I'll try that on my pine64 later on <mothacehe>dannym: you can even add novena-barebones-raw-image to the CI :) <dannym>Next, reviewing and testing your patches on novena :) <dannym>ah, the dreaded record abi mismatch <pineapples>guix-vits: If you don't mind: what troubles did you run into on Wayland? And what other problems did you experience with rockpro64 on Guix? I considered rockpro64 before, but there was a lack of mainline drivers for me to justify buying it <mothacehe>dannym: hehe, thanks for testing. Regarding ABI, you can just "rm gnu/system/images/*.go". <dannym>Will do that next time; it's 80% done compiling guix checkout from scratch now <mothacehe>dannym: I see that the "kernel" field is commented in novena.scm, does it manaage to find the right kernel anyway? <mizukota[m]>can guix be installed without root access at all? without daemon and builders with usergroups <mbakke>mizukota: you need the daemon, but it's possible (although not recommended) to run it without root <guix-vits>sneek later tell pineapples: trouble #1 for me, but i didn't heard about that from anyone else: keyboard do not working in u-boot menu. i need to use a serial console to roll-back in case of troubles. #2: i don't remember exactly, but armbian's numbering for emmc and uSD devices was different from what it was on guix boot.. use LABEL or UUID for /. #3: my 1680x1050 screen works in 1440x900 in sway.. maybe display/adapter issue. <guix-vits>#4: need to re-attach keyboard after every boot. #5: fan is a must under load (imho). Needless to say, u have chances to NOT encounter ANY of these :) (#6: aarch64 low on substitutes.. probably u need to get a bloated-web browser from someone). <guix-vits>sneek later tell pineapples: i happy with that board, because it's my first not 'anal-fenced' arm device, where i can do "wahtever". <guix-vits>mizukota[m]: main trouble, there will be no proper isolation in build processes, reproductibility may suffer. (see manual) <guix-vits>sneek: later tell pineapples: armbian worked better, but idk why. and it has all sorts of non-free things enabled by default (also it has cpu-max-working-freqs higher, vs guix; idk why). good news: sdl games work (7kaa, blobwars). nomad-browser working too (so webkit is working). <civodul>kraai: hi! try passing --no-grafts in addition *mothacehe added substitute server discovery to the installation image <roptat>\o/ I managed to bootstrap ocamllex :) <roptat>it's a small step towards a full bootstrap of ocaml <civodul>perhaps we should ask for user consent though, due to the privacy issues? <civodul>we could add a shepherd "action" to turn discover on and off <mothacehe>yup this maybe calls for a new installation page proposing to enable this option and possibly add other remote substitute servers as suggested recently <jonsger>mothacehe: but you still need to authorize this substitution server? <civodul>as long as it provides the same binaries are the server(s) you trust *jonsger does configure stuff mostly via declarative guix acl <civodul>mothacehe: it might be best to not offer a way to add more servers <mothacehe>even for chinese users that may require mirrors? <civodul>well, we could offer a way to prepend new URLs <civodul>because a UI to authorize new servers can be tricky to get right <mothacehe>oh didn't really think about the implications <civodul>fetching /signing-key.pub doesn't sound confidence-inspiring for instance :-) <civodul>or you'd delegate to the X.509 PKI, which may or may not be a good idea <mothacehe>OK, I'll think about that. Almost unrelated, I'm having a look to your recent "substitute" patchset, looks really nice! I have a small concern about the integration with the discovery mechanism. "read-substitute-urls" is now called when "guix substitute" is started. With your patchset it would only be run once, right? That would prevent the newly discovered substitute servers to be used. <civodul>note that in practice, if you run a "guix" command, even though read-substitute-urls is called only once, it's good enough <civodul>because the session is terminated right when the command terminates <civodul>it could be problematic for long-running sessions as with Cuirass <civodul>or for a very long "guix upgrade" or "guix system init" <mothacehe>oh I see, then I guess it's fine! Calling it in "--query" and "--subtitute" loops would be too much, right? <constfun>Hello, is there a way to prevent having to enter the password twice when setting up with LUKS encryption? I tried seven different ways now. I'm using manual partitioning with non-encrypted efi partition. I'm still getting two prompts, one before Grub, one after. I also tried creating a separate boot partition in addition (/boot) in addition to the <constfun>efi partition (/boot/efi), but I get a broken system that way, it appears grub doesn't attempt to use luks at all in this configuration. <civodul>mothacehe: in --query, it wouldn't make any difference since adding the discovered substitute URLs normally doesn't change the list of available substitutes (since discovered servers are typically not trusted) <civodul>in --substitute, it would be excessive to call it once per loop iteration <civodul>given that we're struggling to optimize things, that is ;-) <civodul>but we can adjust later if reality proves me wrong :-) <civodul>we have derivations getting built on the wrong machines somehow <civodul>"while setting up the build environment: executing `/gnu/store/hfydj9kw6b0y52cf6b2zlzc98d5dxfw7-guile-3.0.4/bin/guile': No such file or directory" <civodul>that's for /gnu/store/rwj8xgskq9fbwfgdkhablic1scaf08c9-guix-core-source.drv on berlin <civodul>oh i see, we still had emulated build for aarch64 :/ <civodul>mothacehe: also this: 2020-12-03T16:34:45 batch of builds (partially) failed: unexpected EOF reading a line (status: 1) <mothacehe>civodul: running "zcat /var/log/cuirass.log.*|grep EOF" shows that this EOF has been around since a long time <roptat>protobuf doesn't compile on my armhf board, because of a test issue (probably because I don't have enough memory) <roptat>and guix system doesn't take the --without-test argument <civodul>mothacehe: okay, i suppose that's "good news" <ces>Hey, can someone help me? I am trying to create a package for xmonad-utils, and i have used the gux import hackage xmonad-utils, and rewritten it with the define-public and define-module "blocks/style". The package has inputs ghc-x11 and ghx-random, but when i try to install it with =guix install= i get error: ghc-x11: unbound variable <nckx>Hi civodul. Do the recent avahi improvements (thanks Mathieu!) make the offload machines act more like a mesh than a star, or just reduce the (to, one might say, zero) conf needed to find them? <ces>I use (gnu packages ghc-x11) but it still does not work <PotentialUser-29>Has anyone successfully installed guix system with graphical installer with gnome desktop? <nckx>ces: (gnu packages ghc-x11) means that you created a gnu/packages/ghc-x11.scm file in your Guix git checkout, that does (define-public ghc-x11 (package ...)). Is that the case? <civodul>nckx: discovery is for substitutes, not for offloading <mothacehe>nckx: for now the only implication of the Avahi improvements is that your daemon is able to use substitute servers on your local network without any config <nckx>Hmph. Shows how much I've been following the commit ML. <PotentialUser-29>My installation doesn't work. I got a white screen saying something went wrong. I guess gdm fails. <nckx>I just saw berlin + avahi roll past. <civodul>nckx, mothacehe: though from day 1 the section about offloading has said one could use Guile-Avahi in /etc/guix/machines.scm :-) <nckx>civodul: Right! That's what I do now, so I thought it might be obsolete. <mothacehe>having /etc/guix/machines.scm Avahized could be nice I guess, in particular to deal with machines going offline <mothacehe>for now the behaviour is to block the build until it shows up again unless I'm wrong <guix-vits>vagrantc: my rockpro does not boot to 5.9. My kernel (-generic) differs from stock by inclusion of nftables (as in default, just copied relevant lines). Good luck with Ur boards. <civodul>mothacehe: no, (guix scripts offload) has a short timeout when connecting to machines and it skips those that are unavailable <ces>nckx: I have never used the =guix git checkout= so holdup (i installed yesterday). But quick question: i assumed that i could just write and then install packages from GUIX-PACKAGE-PATH and all the packages i have installed would be in ""scope"? Is this possible (or stupid)? Also, source https://pastebin.com/nP5A6c03. <nckx>That should definitely be possible, but it's not a method I ever used myself. <nckx>ces: But you wrote a package for ghc-x11 too, right? The importer can suggest inputs that aren't yet present in Guix and need importing themselves. <nckx>ces: It's not a bad method, although mostly superseded by channels now IMO. <nckx>I just prefer working from git. <ces>nckx: No, i actually was able to find both dependencies with guix install. <leoprikler>"Mostly superseded by channels" here means, that GUIX_PACKAGE_PATH is only really useful as a quick and dirty hack for testing and should not (seriously) be used otherwise. <ces>leoprikler: This is kinda also my use case (i.e. i need a dirty hack). I depend on xmonad-utils to build my xmonad, but as soon as it has been compiled once i could actually work sort of comfortably (and make it "correct"). <leoprikler>Then it's fine, just telling you in case you want to share your xmonad with others. <nckx>leoprikler: And ‘guix build -f’ nibbles a good chunk out of that use-case too. <ces>leoprikler: i actually would love to share it after thou, to leave a rope for people <leoprikler>nckx: true, most stuff goes well into a single guix.scm <ces>I am really new thou, is there something obvious thta could make it so that packages i install are not visible yet? <leoprikler>Don't worry about it, it will pass through a very rigorous review session. <leoprikler>But given that you want to distribute your personal variant of a package, that already exists in Guix, chances are slim that it will actually land upstream. <leoprikler>Instead, we'll talk about channels once your build succeeds :) <nckx>ces: ghc-x11 is in (gnu packages haskell-xyz). <nckx>So remove those two (nonexistent) imports and import that and you should be good to go. <leoprikler>PotentialUser-29: I do have a running GNOME desktop. <nckx>PotentialUser-29: Not ignoring you, just don't use GDM ☺ (for that reason, actually. Insulting your users with deliberately hostile error messages won't win one many.) <leoprikler>Most here have systems older than that, but that should hardly make a difference given that the failing component is gdm. <ces>nckx: THANKS! It built! <leoprikler>there are some logs in /var/log, that could be potentially useful, particularly /var/log/gdm (note that you need superuser for those) <ces>PotentialUser-29: I installed yesterday on latest with gnome and it ~worked~ (booted and could login) <PotentialUser-29>got frustrated by the error and formated my machine. Sorry but I don't have logs to help <leoprikler>most my installs have been manual as I needed to deal with yucky hardware <ces>leoprikler: Graphical <PotentialUser-29>ces: I'm using Debian now but with sddm but when I was using parabola with gdm I used to have problems with gdm too but would fix with setting Wayland flag to off. I have a 64 bit capable Pentium 4 <leoprikler>Guix does not yet have Wayland, so you should be running on Xorg. <nckx>leoprikler: s/Guix/&'s GDM/ ? <nckx>You can run Wayland just fine on Guix. Some things even natively. <nckx>It's like X11 but with more crashes \o/ <samplet>GNOME on Wayland works okay, but it can’t be started from GDM. *nckx .oO ...sigh, I didn't mean you had to crash *now*, IceCat... <samplet>For a long time, I think. Mark Weaver has been talking about running it for years. <samplet>I have been running it on another machine a bit lately, and it works well (I don’t remember why I bothered, but I’m sure there was a reason). <samplet>Specifically, I run “XDG_SESSION_TYPE=wayland gnome-session”. <samplet>leoprikler: There are six or so spots where we patch it to work nicely with Guix, but we only did the X path. AFAIK, one would have to check which changes need to go on the Wayland path and adapt them. <samplet>I did the finishing touches to get GDM working with X, but I wasn’t motivated at the time to investigate Wayland. <nckx>civodul: It was discussed here y'day or the day before. <nckx>civodul: I see you didn't see the submitter's message I approved at least an hour ago, saying ‘5.9.12 doesn't have the bug’, because it doesn't seem to have arrived yet 😒 <nckx>From: guixuser6392, to #44956, ‘I can't reproduce this issue on the Linux kernel v5.9.12 and v5.4.81.’ <nckx>lle-bout also had trouble with delivery to the bug tracker. <civodul>problem is 1.2.0 installs 5.9.11 i think <smithras>Do you need to have permissions to close a bug report or can anyone do it? <nckx>civodul: Yes, so ‘fine’ isn't the word I'd use. 100% of users shuts down after installation, few of them pull. <nckx>Do we sync before shutting down? <nckx>Not explicitly it seems. <nckx>civodul: The bug is that the kernel oopses, so any unsaved data would be lost, right? <civodul>root-file-system-service explicitly calls 'sync' when stopping <nckx>If /mnt is always unmounted before efivarfs that's OK apart from ugly. <civodul>wait, the reports we got are for installed systems, right? <civodul>it's not the installation image that's crashing, IIUC <kozo[m]>I have only seen the issue when shutting down <leoprikler>stupid question, but how would I setup a substitute server with the new --advertise and --discover? <kozo[m]>leoprikler: This is what mbakke told me yesterday: there is a some information about it in (info "(guix) Invoking guix-daemon"), but arguably not a lot to go on <kozo[m]><mbakke>essentially you start guix-publish on remote nodes with the --advertise option, and guix-daemon with --discover, and your daemon will discover the other machines automatically <mdevos>leoprikler: my configuration (not tested yet, guix system reconfigure is still running) <sneek>Welcome back mdevos, you have 1 message! <sneek>mdevos, nckx says: The legacy guix.info domain and subdomains now redirect to guix.gnu.org. <roptat>you should provide a better picture though ;) <mdevos>sneek: tell nckx redirection works great! <sneek>nckx, mdevos says: redirection works great! <mdevos> there seems to be a bug in the guix-configuration documentation: ‘discover’ should be ‘discover?’, the former failed to build for me <mdevos>anyone with commit access online? <roptat>oh, found an issue with the French translation :/ <roptat>--without-test=PAQUET instead of without-tests (with an s) <vagrantc>and.... guix fails to build on Debian now :( <vagrantc>as guile-gnutls now is built with guile-2.2... <nckx>civodul: I wonder why the installation image isn't affected. It uses shepherd. It shuts down(?). <leoprikler>maybe because it doesn't mount efivarfs in the first place? <distopico>Hi, I need some help with a build, I'm trying to build `guix build qoauth` <distopico>and I'm getting 'Error copying /tmp/guix-build-qoauth-2.0.0.drv-0/source/oauth.prf' to '...' <distopico>`guix install qouath` also failed, in parabola Gnu/Linux <lfam>The installation process is trying to copy some files that are part of qoauth into the store directory of qtbase, which is another package. This is a bug in the qoauth package — once packages are built on Guix, their store directories become immutable and can not be written to <distopico>I see, there is a workaround? or is something that we should report to guix? <lfam>I wonder what changed that caused this to happen. This package has only ever been touched once <lfam>It's a bug and should be reported. The only workaround will be to fix it <jorge[m]>Se puede ver los paquetes de guix por categorias ? <nckx>jorge[m]: No. Guix doesn't have package categories. There's a rough grouping by module name (.scm file) but it's for technical reasons, not taxonomy, nor do I know an easy way to search for packages by module. <civodul>"guix search" takes file names into account <nckx>You can use ‘guix package -A | grep /gnu/packages/foo.scm’, I guess. Or using recsel. <leoprikler>would it make sense to add "keywords" or "tags" to packages? <nckx>civodul: It won't help you search for something like ‘web browser’ or ‘IRC client’, both are littered amongst modules. <leoprikler>proper tagging might also make some other stuff more visible, like often searched commands <lfam>*If* we can keep the tags up to date, they will be useful. But I think no tagging system is better than a stale one <leoprikler>Well, I'd imagine using tags for stuff that doesn't change that often. <leoprikler>Of course, you'd miss that if no one tagged poor nomad, but imo that's something one could live with <leoprikler>I'd also sparingly sprinkle them across packages as needed, not e.g. tag every dependant of gtk as "gtk". <mbakke>wowza, I just got an error with 'git pull': <mbakke>error: RPC failed; curl 18 transfer closed with outstanding read data remaining <mbakke>fatal: error reading section header 'acknowledgments' <lfam>leoprikler: Well, we already have the 'properties' field which can be used for anything. We just need to expose a 'tag' property in the UI and go from there <luis-felipe>Who knows how easy would be to use the free software directory to extract information about packages and be able to search by category... <mbakke>funny, I'm getting similar error with 'git-fetch' <mbakke>what is going on with GitHub :-) <guixy_>OpenRCT2 is at version 3.2 upstream, but guix puts it at 2.6 <guixy_>I would upgrade it myself, but the new guix refuses to build anything. <lfam>It refuses to build anything? That's unexpected <jorge[m]><nckx "jorge: No. Guix doesn't have pa"> ok,no todos los paquetes GNU estan en Guix ? <lfam>If you'd like help, please help us help you by giving more details <guixy_>I'll link a pastebin of the error... <guixy_>Something about how build has too few arguments <nckx>jorge[m]: Most! But not all. A random example is GNU Eiffel (Liberty Eiffel), which I recently tried to package but turned out not to be impossible to bootstrap. <guixy_>I'm pulling right now. This will take a while. <jorge[m]><nckx "jorge: Most! But not all. A ra"> Quiero instalar Gneural Network relacionado a redes neuronales y no encuentro algo parecido. <nckx>jorge[m]: Never heard of Gneural Network. It's not in Guix yet. <nckx>Last release is 4 years old. <nckx>That's like 20 in ML dog-years. <Formbi>how to disable output formatting? <dannym>indexing objects 26% [############## ]guix pull: error: Git error: error inflating zlib stream <guixy_>I decided to do a clean-ish build. make clean; make <jorge[m]><nckx "That's like 20 in ML dog-years."> ok,si es muy viejo no se empaqueta <lfam>What's the workflow for testing updates to the Guix package? Specifically, any suggestions for fetching its source locally? <mbakke>dannym: are you pulling from GitHub? <mbakke>I just got some strange errors from git myself, when pulling from GitHub. <civodul>dannym: interesting; is that reproducible? <lfam>dannym: The savannah servers are being updated and rebooted today. Maybe it's related to that *mbakke pushes GnuTLS security update <dannym>Now it got to 80% and then fails with a backtrace <lfam>I found the manual chapter about updating the guix package. Reading... <civodul>dannym: that 'guix' from 'guix pull'? <civodul>lfam: normally we only update it if there's a fix or a new feature on the daemon side <lfam>civodul: I see. I want to test the update of libgit2 <dannym>Yes, it's guix master from not too long ago (today), and I didn't edit any configuration, just copied novena.scm into the novena root drive via a serial port and the clipboard <civodul>lfam: oh i see, so you don't need to update 'guix' itself <lfam>No? It doesn't use libgit2 via guile-git? <dannym>(I edited nothing to what guix system disk-image -t novena-raw novena.scm gave me) <civodul>lfam: what you can do is update libgit2, run "./pre-inst-env guix build guix", and use that 'guix' to run 'guix pull', say <dannym>the first guix pull ever on this board, in fact <civodul>dannym: so the one that crashes is the 'guix' command from the cross-compiled 'guix' package, right? <dannym>No, it was compiled natively on armhf <civodul>'guix system disk-image -t novena-raw' builds the image natively? <civodul>does 'guix pull' work on the banana pi? <lfam>guixy_: Did you want help? <dannym>If the target system and host system are equal, it builds the image natively (see bug # 45021) <vagrantc>civodul: haven't tried guix on the banana pi ... should work <dannym>But I'm not pulling that often on banana (once every few weeks), might not have used the same git fetch code now <dannym>Banana had: Authenticating channel 'guix', commits 9edb3f6 to 19f1307 (291 new commits)... (in order for us to know which git code was being used) <civodul>dannym: do you think you could run 'guix pull' on the novena under 'rr'? <civodul>that'd be the beginning of a long journey though <civodul>i suspect there might be a memory corruption issue <civodul>and with rr we could let the program run until it crashes, and then replay execution possibly backwards until we find when data got corrupted (assuming data is getting corrupted) <civodul>maybe you had other plans for the coming days ;-) <dannym>If you want I can give you access though--there's nothing on there anyway, and it is a server <dannym>I mean it's next to banana, and that one is accessible via the internet <guixy_>My local checkout has diverged from origin/master. Rebased, now I'm rebuilding. <vagrantc>well, that would explain the issues, at least :) <dannym>That means guix didn't auto-resize the sd card partition <dannym>guix gc: error: executing SQLite statement: database or disk is full <guixy_>Now I checkout origin/master, where origin points to my most recent fetch from savannah <lfam>guixy_: Okay. I do recommend starting from a Git commit in our repo, and a clean worktree. You might as well rebuild the repo from scratch at that point. If you still have trouble, it will help to know which Git commit you are building from, the commit you are "building with" — `guix describe` for whatever Guix you are using for `guix environment --pure guix`, the CPU arch you are using, and any other detail that you think might b <lfam>These details will help us try to reproduce your bug <dannym>I take it guix system init to the SATA drive doesn't work either if there's no space, right? <lfam>guixy_: For further error messages, please include the entire output of the failing command, and include the command itself too <dannym>(The SD card has 30 GiB, and guix allocated only 1.4 GiB of it) <vagrantc>dannym: i'd recommend only using 80-90% to save room for wear-levelling ... guix is pretty harsh on media <nckx>jorge[m]: I don't think that's what I said. <dannym>I'll set it up to boot from SATA HDD anyway (not SSD) <guixy_>I'll run './pre-inst-env guix build hello |& cat >/tmp/output.log' and pastebin the result when it's done building. <vagrantc>there's some trick in the installer to mount the installation directory when running "guix system init" so that new writes go to the installed system's store only <vagrantc>dannym: maybe you could do something like that? <vagrantc>in theory it owuld be possible, probably not there yet <vagrantc>but you can implement the same sort of workaround <Formbi>how to disable the escape sequences in guix output? <lfam>My understanding is that, to save the SD card, it's best to mount the fs with something like commit=600 <vagrantc>dannym: not sure how to get the cow-store service onto a regular install, but it would seem useful <lfam>Yeah, although I thought that was a default these days <lfam>commit changes the write interval <vagrantc>noatime will save you one write per accessed file per day over relatime <vagrantc>as it doesn't have to check if atime was updated on every file before deciding to write a new atime or not <lfam>I think the experts are at armbian <dannym>herd: service 'cow-store' could not be found <dannym>I'll just cp -a everything over to sda and chroot :P <dannym>like it's 1995 all over again ;) <dannym>At least it's only 1.5 GiB, so it's gonna be fast <guixy_>well, I'm out of time. Sending bug report that openrct2 can be upgraded and needs duktape. <civodul>guixy_: that sounds like a wish list more than a bug report :-) <jorge[m]><nckx "jorge: I don't think that's what"> Fue eso lo que entendi,de todas maneras lo descargue de la pagina de GNU pero no se ejecuta. <nckx>jorge[m]: No releases in 4 years, especially in a fast-moving field, is only a red flag. We package software that hasn't seen releases for a long time if it's useful: if it's ‘done’. But not if it's ‘abandoned’. I don't know which describes Gneural Network. How did you try to compile and run it? <nckx>Well, ‘abandoned unfinished’, I mean. <nckx>That's what a 4-year old v0.91 suggests to me... <guixy_>ok then, I won't send a bug report. At least I'm not the only one who knows about it now. <nckx>jorge[m]: Actually, gneural_network-0.9.1.tar.gz builds fine with ‘guix environment hello -- sh -c './configure && make && src/gneural_network’. I just don't know what to do with it now. <nckx>OK, I can run it on the *.input files in tests/... <nckx>...and it creates ‘final_results.dat’ with numbers, which I guess is good. <jorge[m]><nckx "jorge: No releases in 4 years, e"> Me parece super interesante,imagina construir IA que cree un efecto cascada con todo el sofwared libre,el mantenedor es autor de otros paquetes en GNU. voy a escribirle por que solo informa por correo segun lo que vi. <rekado>mbakke: no, I haven’t used pipewire yet. I’ll use JACK until it becomes unmaintained or all software I regularly use supports pipewire. <rekado>I like the conceptual minimalism of JACK; it’s easy to understand. From the little I know about pipewire it seems more ambitious. <nckx>jorge[m]: I think this would be a very easy package to write: just a name, version, gnu-build-system, home-page, synopsis etc. It doesn't seem to need any custom phases. Are you interested in trying to package it and sending a patch? We're always here to help you if you get stuck. <rekado>I wonder if I can fix at least one mumi bug tonight. <nckx>Well, figuratively always, I'm going to bed. o/ ***jonsger1 is now known as jonsger
<ces>Hey, anyone use zsh (or any non bash)? I can't use chsh (due to pam for some reason, even with sudo) and i also assume that i have to point it to a profile binary? I couldn't find anything with a quick search on the documentation. <mbakke>ces: see (info "(guix) User Accounts") <ces>mbakke: Thanks! I'll check it ***daniel is now known as Guest52790
***Guest52790 is now known as daniel_molina
<kozo[m]>Hey, did something change with guix environment? I am now getting <kozo[m]>guix environment: error: cannot create container: unprivileged user cannot create user namespaces <kozo[m]>guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1" <dannym>Ah, guix pull finished just fine on SATA on novena! Sorry for the noise. <hurricos>I'm asking about their Asus C201 veyron-speedy. <hurricos>Or if anyone knows the state of a u-boot replacement for the 'veyron' chromebook line of boards via the 4MB SPI flash (GD25Q32SIG) <lfam>hurricos: If they are not here now, they are around fairly often <lfam>I recommend waiting a while <hurricos>lfam: gotcha, thanks. I will. I'm finding IRC helpful enough that I've started keeping weechat open indefinitely from my server so I miss nothing lol <lfam>In this channel, we also have the 'sneek' bot, which can be used to hold messages for people until they show up <lfam>sneek: later tell hurricos: Hello! <lfam>And then when you speak, you'll get the message <sneek>Welcome back hurricos, you have 1 message! <hurricos>sneak: later tell vagrantc: Hi there, you talked about linux-libre on your Asus C201 / veyron around September last year, did you replace u-boot on flash to attempt to boot it, and did it ever boot? <hurricos>sneek: later tell vagrantc: Hi there, you talked about linux-libre on your Asus C201 / veyron around September last year, did you replace u-boot on flash to attempt to boot it, and did it ever boot? <lfam>It also knows "sneek: later ask name", for a more natural way to type questions, but there is no practical difference <hurricos>And for the SEO that brought me here: all veyrons have basically identical motherboards and basically all of them boot using u-boot as an SPL to Coreboot <jeko>what can I do with that xD <hurricos>which is frustrating because I want to replace boards that are locked and or have no display! <lfam>jeko: Not sure! What were you trying to do 