<zimoun>why IPFS could not be used to store the raw tarballs? <zimoun>I should have missed how IPFS works <civodul>but "guix lint -c archival" still complains <nckx>NieDzejkob: Weather is currently artificially low because I needed a place to put a 1 TiB disc image, which triggered a panicked GC of 500 GiB :-/ <NieDzejkob>I just noticed that the "commit access" section of the manual mentions "you successfully built it in a chroot setup", but guix's builds are isolated from the environment anyway. What gives? <lfam>NieDzejkob: It's possible to disable the chroot (`--disable-chroot`), and doing this is (was?) really common in Nix-land <lfam>So when Guix was started, I think it was seen as a concern <lfam>In practice we just don't do it here <gnutec>freedink installation fail. The compile of freedink-engine return problems. <hendursaga>So I created my first package definition and am wondering how I might go about getting it reviewed and possibly included in the Guix packages repo. <hendursaga>I packaged xstow, which is/was supposed to be a stow replacement, but without the Perl dependency, instead using C++. <bavier1>hendursaga: send a patch to guix-patches@gnu.org <hendursaga>bavier1: I'm afraid I've never done such a thing yet, I might need a little guidance. <bavier1>hendursaga: clone the guix repo with git if you haven't already <hendursaga>Done. Then modify the file in that repo, and then... perhaps something to do with git patch? <bavier1>commit your change, then create a patch with `git format-patch -1` <bavier1>you can send the generated file with you usual email client, or using `git send-email --to=guix-patches@gnu.org` <hendursaga>Cool. Is there like some character limit? 80? 79? I've never really programmed in Scheme before. <bavier1>run `guix lint xstow` and it might complain to you, including line lengths <hendursaga>bavier1: It complains the package is not found. I installed it with --from-file or something. <bavier1>you should eventually get to a step about building guix from your checkout, at which point `./pre-inst-env guix lint xstow` should work <hendursaga>Wait am I supposed to submit some paperwork first? <clodeindustrie>question, I would like to try using Wayland but I don't want to mess up my current set up <bdju>I don't think it will mess up your current setup. What are you worried about getting messed up? <bdju>I am using Sway, I don't have experience with GNOME/KDE Wayland versions <clodeindustrie>it's just that if I start changing stuff around, PATH, keyboard management, etc... I would prefer to just be able to switch back easily <apteryx>clodeindustrie: if you are using Guix System, that would happen in your config.scm, so you could just version that file and be assured you can go back (combined with 'guix system roll-back'). <clodeindustrie>apteryx: right so that was what I was wondering, if it was something I should be doing at the system level or user level <apteryx>I don't use sway, but I'd say it's going to be configured at the system level <clodeindustrie>I would have to find a way to tie this with my dotfiles, because I surely will have stuff to change in there <bdju>Keyboard management happens in the sway config itself, so your current xinput stuff won't be touched. <ryanprior>re: using IPFS for Guix packages, the different hashing seems like a shallow problem? We could hash Guix packages using the IPFS hash algorithm and also store that hash, either in the package definition or in a separate database. <ryanprior>n hashes for n packages isn't expensive to compute or store <ryanprior>It would be verifiable too, anybody could build a guix package and hash it using the IPFS algorithm if they don't trust the database/package string. <hendursaga>bavier1: I still can't get it to recognize xstow. I got the pre-inst-env to work though, for other packages. <lispmacs>just curious, when you do a guix pull, are you building guix with your current version of guix, or a bootstrap guix? <alextee[m]>clodeindustrie: you have generations for that. Just rollback to a previous generation ***apteryx is now known as Guest60472
***apteryx_ is now known as apteryx
<rekado_>hendursaga: you don’t need to submit any paper work to contribute to Guix ***leoprikler_ is now known as leoprikler
<alextee[m]>im imagining something like debian/ubuntu's package search <alextee[m]>it just redirects to the site with a search query, and the server handles the logic, not JS <nckx>alextee[m]: No. I'm telling you it uses server-side scripting to do the same. <alextee[m]>maybe there could be a subdomain packages.guix.org that has server-side logic too and works like debian's search. that would be the best imo. but this one's fine for now ^ <nckx>alextee[m]: Yeah. What's your use case? <alextee[m]>nckx: i just want to check if a package is in the official guix repos, or what version it is <alextee[m]>i do that often with debian's search when working with dependencies that should work on other distros <nckx>So you don't have Guix installed? <alextee[m]>like "does debian 9 have this library with this version and above"? <alextee[m]>nckx: if i have the same package in my channel as guix then `guix search` shows me only the package in my channel <rekado_>we should just deploy a slightly modified version of the thing at hpc.guix.info <rekado_>we didn’t do that in the past because we had to use a fully static website when we used shared GNU infra <rekado_>now we run this on our own hardware and outside of the GNU CVS, so we can do whatever we want <rekado_>if someone would like to work on this I recommend cloning the artwork.git repository <nckx>So the JS ‘requirement’ is moot, it could be a simple Guile CGI script. <zimoun>alextee[m]: what you want is hpc.guix.info/browse and from the messages in the thread I mentionned, I am not convinced there is consensus about what and how guix.gnu.org/packages should be. <alextee[m]>that took way too long to load the list of packages and doesnt feel right, but does the job for now <nckx>I think there is consensus. <zimoun>nckx: as a good zen says: "Now is better than never. Although never is often better than *right* now." And I feel a "never"... So I am not convinced that's a consensus but The Right Thing plan, instead of Worse is better. :-) Anyway! <rekado_>alextee[m]: the hpcguixweb thing downloads a big JSON blob for all packages. When it was originally written there weren’t quite as many packages… <nckx>Calling it TRT makes a trivial Guile script sound intimidating. Consensus doesn't imply volunteering, especially for such a low-priority feature (guix search exists; booting the HTML5 Runtime to connect to Germany to find out which packages your local channels shadow is bonkers IMO, but more power to who wants it—and writes it). But I admit you lost me halfway through your philosophising. 🙂 <nckx>Ugh, CUPS is a buggy boy… <nckx>Does it just work for anyone? <efraim>I actively avoid printing, I'm pretty sure it doesn't work for me <rekado_>whenever I want to print something (which is rare) I need to debug things (like the tmp directory permissions bug recently) <nckx>Oh, right, I'd even forgot about chmod 775 /var/spool/cups. <nckx>They seem to've missed that the ‘deprecation’ part was the joke. <zimoun>Yeah they did not noticed the good April fool. :-) <nckx>The comments won't load for me or I'd say so. <nckx>Your leading Fropen Source news source. *nckx AFK to yell at printing. ***rgherdt_ is now known as rgherdt
***rekado_ is now known as rekado
<efraim>speaking of printers, I couldn't find my new printer in the CUPS interface <efraim>turns out it works with IPP. got my test page printed and a page of connection negotiations when I tried to connect to port 9100 <hendursaga>Huh, podman isn't packaged yet. I guess I'll have to go with Docker. ***sneek_ is now known as sneek
<jonsger>hendursaga: would be nice to have podman as it doesn't require a running daemon, AFAIK :) <nckx>IPP (Everywhere) is the standard & only supported way to use CUPS. Don't use drivers unless your printer is ancient or weird. Upstream happily breaks them. <nckx>hendursaga: …or package podman 🙂 <raghavgururajan>nckx: In substitute*, to find all files that ends with extension .xml, what should be syntax? <nckx>That… not how it works. substitute* doesn't need to support file searching. Compose. (substitute* (find-files "." "\\.xml$") …). <nckx>(find-files "releases" …) in your case. <nckx>"^.\\.xml" would only match single-character XML files (a.xml, 9.xml, …). <nckx>(cons* "blah" "blah" (find-files "blah" "\\.xml$")). <nckx>raghavgururajan: ‘No meant two other files’ = ? <nckx>raghavgururajan: For more complex lists you can also use (append (list …) (find-files …) (find-files …)) etc. <hendursaga>nckx: It looks like a lot of work. Maybe someone in #podman might know better. <nckx>TBH I hadn't heard of podman 10 minutes ago. First thought was a typoed pod2man until you mentioned Docker. <NieDzejkob>hendursaga: as in, an operating-system for being deployed in Docker, or a host for running docker containers? <NieDzejkob>see gnu/system/examples/docker-image.tmpl in the repository <bhartrihari>Hello, how can I specify the number of cores to be used when invoking guix system reconfigure? <bhartrihari>Where is it documented btw? I don't see it in invoking guix system section in the manual. <NieDzejkob>for some reason, docker@19.03.12 failed on CI, with a truncated log. The build succeeded on bayfront. Could someone re-run the build on CI? <dustyweb>playing around with making my server setup easy in a VM, where I'd like my ssh pub key to appear in authorized keys off the bat. I'm thinking the easiest way to do this is via a service <dustyweb>(as in, wanting ot test my server setup before I deploy) <dustyweb>is this something others in here have done? <dustyweb>NieDzejkob: ah this file is very helpful! <hendursaga>So to add my non-root user to docker group, I modify /etc/config.scm then do a system reconfigure, right? <apteryx>one gotcha is that PATH is often configured for interactive shells but not for ininteractive shells <apteryx>make sure that: ssh bayfront 'sh -c "echo $PATH"' returns the expected PATH <apteryx>eh... would anyone know why I get the following: swapon: /swap/swapfile: swapon failed: Invalid argument <apteryx>(when I issue: sudo swapon /swap/swapfile) <apteryx>This is following a 'sudo mkswap /swap/swapfile' that succeeded. <apteryx>ah, dmesg was the right place to visit, thanks: swapfile must have single data profile <nckx>You can use a loop device to work around that in a pickle but it's rather pointless to mirror your swap file. <hendursaga>How do I add a group in config.scm? I know how to add a user to a group that's already existing. <nckx>hendursaga: Same way, (groups (cons* (user-group …) %base-groups)). See manual. <apteryx>nckx: meh, no swapfile on RAID, so it'd have to resize my main partition to create a new one just for swap. <NieDzejkob>hendursaga: the docker group should get created automatically by docker-service-type <NieDzejkob>apteryx: that returns the expected path, have you looked at the paste I linked? <apteryx>NieDzejkob: oh, I had missed that second ssh command invocation <apteryx>the hint might not be accurate. You could try stracing the remote process, with something like 'strace -f -s320 --attach=PID' <NieDzejkob>hmm, that might be hard. At this point the substitute for the docker I built got baked, so I can just fetch it with `guix build docker --substitute-urls='https://bayfront.guix.gnu.org'`. I guess I'll debug it more if when I need something like this again <hendursaga>NieDzejkob: I did not add the docker service yet. I'm running it manually for now. <NieDzejkob>ah, that will give you a bit more hoops to jump through <raghavgururajan>NieDzejkob, What about for "no binary for interpreter `run-cargo-script' found". rust:cargo did not work for this. <raghavgururajan>patch-shebang: ./vendor/xml5ever/examples/simple_xml_tokenizer.rs: warning: no binary for interpreter `run-cargo-script' found in $PATH <dustyweb>so, this isn't specifically a guix question <dustyweb>but I'm trying to do the "ssh into the local vm" thing, and I'm doing: <dustyweb>`/gnu/store/pk335a22lr9h5wrj49r87p4vf70z9rad-run-vm.sh` -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 <dustyweb>the thing is that I can't seem to connect <janneke>dustyweb: yeah, that does't work for me either <janneke>or more accurately, it doesn't /always/ work <dustyweb>ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 cwebber@127.0.0.1 <dustyweb>ssh: connect to host 127.0.0.1 port 10022: Connection refused <janneke>i /think/ the problem is related to the "-nic ..virtio" bit being insside the /gnu/store/pk335a22lr9h5wrj49r87p4vf70z9rad-run-vm.sh script too <janneke>...but commit history suggests we sometimes need that virtio in the script <janneke>a fix (or possibbly a bug first) would be great! *janneke felt having gtoo vague/finger-pointy/anecdoty info to file a bug report yesterday <dustyweb>janneke: well that seems partway there :) <dustyweb>janneke: now it can start connecting and hangs <dustyweb>janneke: I'll file the bug. Ok to credit you for helping me figure it out? :) <janneke>i looked a little bit at the commit history, and i seem to remember it was changed, removed, added, something like that <janneke>(my initial idea was: i'll send a patch to remove it, but that's prolly too naive) <dustyweb>but I may have introduced an *extra* problem :) <dustyweb>janneke: notice that I put the shell script in backquotes <janneke>hmm, so maaaybe it's all red herrings? <dustyweb>I also lead janneke deep into the woods if so <janneke>in that case, no idea what i saw yesterday... <dustyweb>I am having another problem in that attempting to connect is just hanging <janneke>i'll have a look at this later, i need to go afk for a bit <dustyweb>janneke: so now I am down a different rabbit hole <dustyweb>that it's the same with nginx as it is with ssh <dustyweb>I'll write an email to help-guix since I'm not sure this is a bug really <NieDzejkob>(because if not, then I don't see how guix is relevant) <hendursaga>Yes, so that the resulting image is potentially much smaller. <NieDzejkob>hendursaga: are you aware of `guix system docker-image'? <NieDzejkob>that way you could avoid using Dockerfiles altogether and get much better reproducibility <hendursaga>NieDzejkob: Yes, I am using that right now. I just thought, if I'm going to be installing tools to compile the real software I'll be running... <NieDzejkob>what I'd do is create a guix package for the software <hendursaga>So, for instance, I wouldn't need cmake in the resulting image, but I need that to compile the software that will be running in the resulting image. <nckx>raghavgururajan: Use ("cargo" ,rust "cargo") for outputs in *inputs. <aidenholmes>looking for documentation on how to remove the guix pacakge manager from debian <NieDzejkob>aidenholmes: you basically need to follow the installation instructions in reverse <NieDzejkob>basically, stop the daemon, clean up `find /etc -name '*guix*'`, /gnu/store, /var/guix <NieDzejkob>How do I go about contributing to guix-past? Do I just open a GitLab Merge Request, or is there a mailing list for that? <NieDzejkob>raghavgururajan: take a look at the definition for librsvg-next, I believe it already solves this problem <nckx>raghavgururajan: Those errors are firmly in Rust territory & I'm not a Ruster. <nckx>aidenholmes: Also ‘standard’ left-overs like /var/log/guix* + each Guix-using user's ~/.guix-profile and/or ~/.{cache,config}/guix directories, if you want to be really thorough. Harmless but useless without Guix. <nckx>Hence NieDzejkob excellent advice to look at the installer script in reverse. <nckx>aidenholmes: That's what I do. <nckx>aidenholmes: This is really a Debian question. <nckx>I use emacs, I'm sure there are front-ends but like the infamous adduser/useradd mess they might be distro-specific. ***terpri__ is now known as terpri
<NieDzejkob>I usually use a git repo of the package, but if it's not available, you can do either `cp -r Python-2.4.6{,.orig}` or `cp getplatform.c{,.orig}` <NieDzejkob>(BTW, regexes are quite a heavy-weight tool for that. How often does this code run?) <hendursaga>How do I specify the version of, say, postgresql in package inputs? *raghavgururajan looks up and screams "why gnome, why?", after looking at new versions of librsvg. <dustyweb>raghavgururajan: uhoh, packaging nightmare, or? <dustyweb>raghavgururajan: from a security perspective, probably good. From a packaging irritation perspective, probably not, eh? <dustyweb>raghavgururajan: well, security wise, moving packages from C to Rust seems to be a win <lfam>hendursaga: You don't specify package versions in the list of inputs. You specify packages by variable name <dustyweb>because most vulnerabilities tend to be related to manual memory management <dustyweb>and Rust provides a path away from that when C-like performance is still needed (and C ABI compatilitity must be maintained) <dustyweb>raghavgururajan: Go isn't as performant and has a lot of other design decisions <lfam>hendursaga: So, currently we have Postgres packages defined as 'postgresql', 'postgresql-11', and 'postgresql-9.6' <dustyweb>I wouldn't consider it a "safer C replacement", whereas I think Rust is arguably that <raghavgururajan>I have not learnt more about rust yet. It seems like a separate reality in-itself. <hendursaga>raghavgururajan: You should. It's really cool, albeit I'll need to learn more myself. <efraim>The odd numbers are dev releases, 2.48.8 is the latest librsvg release <lfam>For some reason a lot of older projects do that <leoprikler>I think the reasoning behind that is so that you always have a stable version to default back to, that only gets bug fixes. <leoprikler>Meaning new features can't inadvertently break stuff <NieDzejkob>raghavgururajan: Hyperbola seems to like to engage in, well… hyperbole. Many projects have a trademark policy, see Python, for example. <raghavgururajan>NieDzejkob, lfam: If firefox and rust share same trademark policy, then why firefix could not be provided in FSDG distros? <NieDzejkob>weren't firefox logos distributed under a non-free license? <NieDzejkob>I'm not entirely familiar with the situation, to be honest <lfam>I figure they will probably treat a language implementation differently from a browser <raghavgururajan>Oh wait, I think I read something about this situation in GNUzilla page. <lfam>Ultimately, we don't know what they will do until they do something <raghavgururajan>While the Firefox source code from the Mozilla project is free software, they distribute and recommend nonfree software as plug-ins and addons. Also their trademark license imposes requirements for the distribution of modified versions that make it inconvenient to exercise freedom 3. <janneke>dustyweb: i tried to reproduce my hanging problem, but i couldnt <janneke>did find somithing possibly fishy in your config.scm (if that was complete enough) <lfam>A lot of time has passed since Debian had to rename their package "iceweasel". It's hard to decide what to do based on that <raghavgururajan>NieDzejkob, So according those lines, hyperbola team were right about Rust as well right? It does make it inconvenient to exercise freedom 3. <lfam>It's a situation where "the right thing to do" is only determined in court <lfam>And it depends on if Mozilla decides to enforce the trademark against distros <lfam>I like that discussion NieDzejkob. Especially the part where somebody says "Competition is healthy" and somebody replies "This is ideology, not an axiom." <lfam>At least in the US, it's a radical statement <lfam>I think the trademark should motivate us to do a good job with our Rust packaging. Because if we do it poorly, we will give them a good reason to enforce the trademark <gnutec>Ok! Now I figure out there is a option to found a city in freeciv. I go to my smartphone and see the same on unciv. HAHAHAHAHAHAHA I'm just a newbie. <kmicu>raghavgururajan: claims in that text confuse copyright with trademark. To be honest it’s not the first time when Hyperbola folks shows shallow understanding of the topic. <kmicu>Taking those claims seriously means that you limit my freedom by registering your nick on Freenode and limiting my right to use your nick. <raghavgururajan>Also I think, inconvenient to exercise freedom 3 VS inabilityto exercise freedom 3. The latter is the problem and not the former. <raghavgururajan>Just because there is inconvenience, it does not mean it violates freedom 3. I think this were Hyperbola got wrong. <raghavgururajan>> kmicu: Taking those claims seriously means that you limit my freedom by registering your nick on Freenode and limiting my right to use your nick. <lfam>In general I think that crowd misunderstands the law. They view it like computer code, where it works exactly the way it is written. But it's really quite malleable and enforcement is not automatic or even predictable <janneke>dustyweb: it looks like your config lacks a networking service...could that be it? <raghavgururajan>kmicu: I think GNUzilla should also remove the inconvenience as a reason to create Icecat. Instead, it should eloborate on it's other reason "While the Firefox source code from the Mozilla project is free software, they distribute and recommend nonfree software as plug-ins and addons.". Which is related to FSDG. <brown121407>I'm interested in buying an used Thinkpad so I can run only free software (preferably Guix System) without any dongles or whatever. Do y'all recommend any specific models? <lfam>You'll have trouble with wifi brown121407 <blendergeek>brown121407: Are you hoping for a Free (as in Freedom) BIOS or just the ability to run a FSDG compliant GNU/Linux distro? <dustyweb>I was trying to start from scratch and pair down my server config <janneke>see, i experienced a similar problem yesterday and now cannot reproduce it! <kmicu>raghavgururajan: iirc technically Firefox has support for removing trademark so I have no idea what they have in mind exactly. Guix is in Guile and I’m not familiar with Guile and that make exercising my 3rd freedom inconvenient ergo Guix is non‑free. 😺 <raghavgururajan>> lfam: In general I think that crowd misunderstands the law. They view it like computer code, where it works exactly the way it is written. But it's really quite malleable and enforcement is not automatic or even predictable <rekado>janneke: have you been able to ‘guix build hello’ in the Hurd VM? I see a test failure for coreutils and I wonder if that’s due to my CPU settings. <brown121407>blendergeek: FSDG compliant GNU/Linux distro for now. Shipping costs for stuff preloaded with libreboot are too big for my country and I don't think I want to risk flashing stuff <blendergeek>brown121407: I run GNU Guix on a Dell Inspiron 5567. In order to have dongle-free WiFi, I purchased an M.2 WiFi card from ThinkPenguin to cover that. <raghavgururajan>> kmicu: raghavgururajan: iirc technically Firefox has support for removing trademark so I have no idea what they have in mind exactly. Guix is in Guile and I’m not familiar with Guile and that make exercising my 3rd freedom inconvenient ergo Guix is non‑free. <janneke>rekado: i prolly see the same pwd-long or something? *raghavgururajan 's eyes are closing... <janneke>iow: i have only been able to build "hello" when setting tests? #f; been wanting to look into this failure ad was hoping to postpone it for when we have substitutes <rekado>janneke: I’m not sure, because the relevant output has scrolled by already and I don’t have bunzip or bzless yet to read the log :) <kmicu>raghavgururajan: that was about GNUZilla’s statement. I can apply the same reasoning to anything inconvienient to me and state such thing has freedom issues. <rekado>uhm, I can’t because I need coreutils to build all inputs <janneke>it should be in /gnu/store/*bzip*/bin/bzcat <rekado>I’m really excited about this childhurd service <janneke>rekado: i have this devel-hurd.tmpl DRAFT patch, that adds all kinds of nifty stuff to the VMs packages <janneke>it suprised me how convenient it is! <janneke>(and we're cross-compiling, so many pkgs are available "cheap") <brown121407>lfam: "you'll have problems with wifi". Is that true for older models? I kept hearing about how older models were "great for free software" and had free drivers available and all that stuff. <lfam>brown121407: You'd have to replace the wifi device, but the Thinkpad BIOS doesn't allow this in many cases <janneke>rekado: so...i have offloading working but we need my latest patch set for that <dustyweb>actually janneke I think your issue is an issue! <lfam>brown121407: I'm not 100% sure but I don't believe Thinkpads ever used wifi chips with free drivers. They usually use Intel chips <blendergeek>brown121407: There very few WiFi chipsets that do not require a kernel loaded nonfree firmware. <lfam>There's actually no wifi chips after 802.11n that have free drivers <lfam>And no work is being done to fix that :/ <raghavgururajan>> kmicu: raghavgururajan: that was about GNUZilla’s statement. I can apply the same reasoning to anything inconvienient to me and state such thing has freedom issues. <raghavgururajan>Yeah, that's what I meant. They should change the statement. Remove the reason of inconvienience. And elborate more on the FSDG related issues, as this makes sense. <janneke>dustyweb: you think? i was almost certain yesterday when i couldn't connect...but now it just looks ugly <kmicu>brown121407: some olders models have an old Atheros cards (or a very specific Broadcom card with a reverse engineered firmware) and on those models wifi just works. There’s no wifi with libre firmware on anything modern. <lfam>802.11n is pretty fast but will sooner or later be too slow for video streaming <lfam>For this reason I don't use linux-libre <dustyweb>janneke: and I bet I know exactly which commit <dustyweb>5379392731b52eef22b4936637eb592b93e04318 <janneke>dustyweb: yeah, but this "fixes a regression" fix on bug on fix on ... (terrible! :) <lfam>It's going to be a problem for GNU in the long run, that there is no wifi support for standards from the last decade *kmicu is steered away from linux-libre by lfam xD <rekado>janneke: you’re right, pwd-long.sh fails <rekado>(I just happened to look at the output at the right time…) <janneke>we're already setting a number of coreutils tests to XFAIL for the hurd, we could add it and worry later? <raghavgururajan>dustyweb, lfam, kmicu: Just had a little chat in GNOME's IRC channel. I was told that, technically they can come after distros that modifies source package (via patches or other means) and distributes them under same name. As they have same trademark policy as Mozilla. <lfam>Right. Any significant software project will want to be able to do that <rekado>janneke: the sqlite error is weird considering that the test suite passed <rekado>but it’s good you found a work around <janneke>rekado: where did the test suite pass? <lfam>We should ignore the issue until we are asked to do sometehing <janneke>rekado: we don't test-suite while cross-compiling <kmicu>raghavgururajan: actually anyone with a (unofficial) trademark can do that but in practice almost no one enforces that. <janneke>yeah, it passes after i apply the patch <janneke>and after applying that locking patch (from debian) THEN loading our db.sqlite failed <rekado>I’ll run pwd-long.sh manually, see if I can spot what’s wrong <janneke>that last bit took some time to find the 4/3 patch workaround for -- you know how these things work <rekado>is the load incompatibility a practical problem for us? To demonstrate it you copied the db from the host system over to the childhurd. Wouldn’t we normally create the database on the target, i.e. in the childhurd? <janneke>our childhurd is cross-compiled, with store and db.sqlite and all <janneke>so...we actually inject a linux db.sqlite into the hurd <janneke>which is supposed to work, because sqlite is 100% portable <rekado>right, you wrote that a few lines further down <janneke>maybe in a couple of months when we build our chilhurds natively, on our childhurds...then that problem is gone <kmicu>raghavgururajan: even not registered Guix can legally stop me from distributing my hypothetical and terrible Guix fork under the name Guix. <dustyweb>mbakke: your input also appreciated on that bug if you can get a moment <dustyweb>I could submit a patch with my suggested fix... <kmicu>raghavgururajan: so in the end we should make a legal risk assesment. In this case GNOME has no history of trademark enfrocement, you are doing your best to provide GNOME on a new distro, there’s nothing malicious about it so chill out, enjoy, and thank you for working on GNOME in Guix. <janneke>i don't like the suggestion all that much, i would wait for more discussion/input <janneke>it's nice to be flexible with the forwarding...oh this only applies for the script -- hmm maybe it's a good suggestion <janneke>i worried this would carry over to vm-image and such, but of course that's not the case <janneke>i would hope for more sanity in the qemu command line, but maybe it just has to be so tricksy and difficult <raghavgururajan>> kmicu: raghavgururajan: so in the end we should make a legal risk assesment. In this case GNOME has no history of trademark enfrocement, you are doing your best to provide GNOME on a new distro, there’s nothing malicious about it so chill out, enjoy, and thank you for working on GNOME in Guix. <dustyweb>guix system vm config.scm --extra-nic-opts=hostfwd=tcp::10022-:22,hostfwd=tcp::8888-:80 <dustyweb>but lets you put others on that line that might not be hostfwd <rekado>it’s hard to read the test or run it manually, but it only tests that pwd can print a directory name that’s longer than PATH_MAX. Since PATH_MAX doesn’t exist on the Hurd some assumptions here might be wrong. <rekado>so I think it’s fine to disable this test and move on <dustyweb>guix system vm config.scm --nic=user,model=virtio-net-pci,hostfwd=tcp::10022-:22,hostfwd=tcp::8888-:80 <dustyweb>janneke: just let the user completely override the -nic option <dustyweb>also gross, but in a totally different way :) <janneke>dustyweb: hmm, i wanted an --extra-kernel-arguments options but didn't dare to suggest it until now <janneke>instead of having to edit config.scm, you could do --extra-kernel-arguments="console=ttyS0,57600n8" and run qemu with --nographic <dustyweb>janneke: I don't understand how to use that one for port forwarding? <janneke>dustyweb: no you don't, but it's a similar "theme"? <dustyweb>I still need port forwarding for non-ssh purposes <janneke>i'm just associating whether or not --extra-nic-opts would be good or bad <janneke>it's not even a bug, you can add (kernel-arguments '("console=ttyS0,57600n8")) to config.scm <janneke>..but editing a config.scm just for VM purposes is also not so great <brown121407>lfam: you mentioned that "There's actually no wifi chips after 802.11n that have free drivers". Does that mean that if the specs say 802.11n (and nothing more) it /should/ or /could/ have free drivers? <lfam>brown121407: It means that it could have free drivers. 802.11n is the latest generation of wifi for which there is hardware with free drivers. But you still have to select the right chip <lfam>You basically want something that uses the ath9k driver <lfam>But, my Thinkpad x200s has an Intel 802.11n chip without free drivers <blendergeek>oops. I was gonna say it didn't seem to be working for me, but now it is. ***sneek_ is now known as sneek