IRC channel logs

2020-07-07.log

back to list of logs

<zimoun>why IPFS could not be used to store the raw tarballs?
<vagrantc>sounds like a lookup issue?
<civodul>yes
<zimoun>I should have missed how IPFS works
<civodul>zimoun: sway, guile-xapian, etc. were archived: https://archive.softwareheritage.org/save/#requests
<civodul>but "guix lint -c archival" still complains
<civodul>we must be doing something wrong
<civodul>maybe tag resolution is wrong?
<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 :-/
<zimoun>civodul: yeah now sway 1.4 is in. https://archive.softwareheritage.org/browse/origin/releases/?origin_url=https://github.com/swaywm/sway.git&timestamp=2020-07-06T21:29:29Z But maybe tag resolution, maybe other. I do not know.
*civodul -> zZz
<civodul>night!
<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>yup
<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
<bavier1>(I think the cutoff is maybe 90)
<hendursaga>bavier1: It complains the package is not found. I installed it with --from-file or something.
<hendursaga>(Following the packaging tutorial)
<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>hi there
<clodeindustrie>question, I would like to try using Wayland but I don't want to mess up my current set up
<clodeindustrie>is using profiles a good idea?
<clodeindustrie>reading the blog article I don't feel like it is
<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
<alextee[m]>Unless sway needs to be in config.scm
<clodeindustrie>alextee[m]: I'll have to investigate :)
<clodeindustrie>thnaks
***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]>we need a search functionality here! https://guix.gnu.org/packages/
<zimoun>alextee[m]: you could be interested by this thread https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00096.html :-)
<alextee[m]>zimoun: why would a search box need js?
<alextee[m]>debian's package search doesn't use js
<alextee[m]>im imagining something like debian/ubuntu's package search
<nckx>Morning Guix.
<bricewge>alextee: https://hpc.guix.info/browse It uses JS tho
<nckx>alextee[m]: https://packages.debian.org/ doesn't look like a static site to me…
<bricewge>Hello nckx
*alextee[m] uploaded an image: Screenshot from 2020-07-07 11-02-06.png (48KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/GvTzOakDKkjQWUfiTgMrESwW >
<alextee[m]>nckx: you're telling me that this uses JS? ^
<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]>yeah server-side logic is fine
<alextee[m]>is guix's website completely static?
<nckx>Correct.
<nckx> http://hpc.guix.info/browse uses JS.
<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
<alextee[m]>same package name*
<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.
<alextee[m]>yeah CGI much preferred over JS
<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>zimoun: https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00289.html
<nckx>I think there is consensus.
<nckx>Just no code (yet) 🙂
<alextee[m]>oh ^ that sounds great!
<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…
<alextee[m]>i see
<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>zimoun: ☝
<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.
<mothacehe>hey Guix!
<mothacehe>Interesting news at: https://www.phoronix.com/scan.php?page=news_item&px=GNU-Guix-Hurd-Images
<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.
<zimoun>me neither
<nckx>Your leading Fropen Source news source.
*nckx AFK to yell at printing.
***rgherdt_ is now known as rgherdt
<raghavgururajan>Hello Guix!
***rekado_ is now known as rekado
<efraim>hello!
<efraim>speaking of printers, I couldn't find my new printer in the CUPS interface
<efraim>any special tricks?
<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>efraim: Great!
<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?
<raghavgururajan>I tried "releases/^.\\.xml" and did not work.
<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.
<raghavgururajan>Oh
<raghavgururajan>I already have:
<raghavgururajan> (substitute* '("notification-spec.xml"
<raghavgururajan>"reference/libnotify-docs.sgml"
<raghavgururajan>"releases/^.\\.xml")
<nckx>"^.\\.xml" would only match single-character XML files (a.xml, 9.xml, …).
<nckx>Yeah, that won't work.
<raghavgururajan>No meant two other files
<nckx>(cons* "blah" "blah" (find-files "blah" "\\.xml$")).
<nckx>raghavgururajan: ‘No meant two other files’ = ?
<raghavgururajan>> nckx‎: raghavgururajan: ‘No meant two other files’ = ?
<raghavgururajan>Never mind! I need some beans.
<raghavgururajan>> (cons* "blah" "blah" (find-files "blah" "\\.xml$"))
<raghavgururajan>Thank you!
<nckx>We all do! ☕
<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.
<raghavgururajan>nckx: https://paste.debian.net/1155472/
<raghavgururajan>Correct?
<nckx>raghavgururajan: Looks good. In theory, ‘http://www.oasis-open.org/docbook/xml/4.1.2/’ matches too much (. being a wildcard), but in practice I think it's better this way.
<raghavgururajan>Cool!
<nckx>Nobody benefits from having to write or read http://www\\.oasis-open\\.org/docbook/xml/4\\.1\\.2/ 🙂
<hendursaga>Anyone have a link to a Docker OS configuration? I'm looking at https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html and am wondering how much smaller I can get it/what it'd look like in practice
<NieDzejkob>hendursaga: as in, an operating-system for being deployed in Docker, or a host for running docker containers?
<hendursaga>NieDzejkob: Being deployed IN Docker, yes.
<NieDzejkob>see gnu/system/examples/docker-image.tmpl in the repository
<hendursaga>Oh! A BeagleBone Black image! Nice.
<bhartrihari>Hello, how can I specify the number of cores to be used when invoking guix system reconfigure?
<nckx>--cores <N> or -c<N>.
<nckx>Sorry, =.
<nckx>--cores=<N>.
<bhartrihari>Where is it documented btw? I don't see it in invoking guix system section in the manual.
<hendursaga>bhartrihari: guix system --help
<bhartrihari>Thanks hendursaga and nckx
<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>hi #guix!
<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?
<NieDzejkob>dustyweb: http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm#n10
<dustyweb>thanks NieDzejkob !
<NieDzejkob>dustyweb: frontend-services are defined here: http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm#n376
<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?
<NieDzejkob>yup
<NieDzejkob>what's going on here? guix copy says I don't have guile in $PATH, but I do and it's working: https://paste.debian.net/1155481/
<apteryx>on the remote host?
<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
<hendursaga>Except apparently there's no docker group, yet. It might be related to this? https://issues.guix.info/41573
<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)
<pmikkelsen___>hi guix
<apteryx>This is following a 'sudo mkswap /swap/swapfile' that succeeded.
<pmikkelsen___>q
<nckx>apteryx: Sparse file?
<nckx>Anything in dmesg?
<apteryx>ah, dmesg was the right place to visit, thanks: swapfile must have single data profile
<apteryx>I'm using Btrfs RAID1
<nckx>Ah, btrfs swap fun 🙂
<nckx>Thought so.
<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.
*apteryx uninterested
<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
<NieDzejkob>I'd recommend adding the service straight away
<hendursaga>NieDzejkob: Probably right. Done.
<raghavgururajan>nckx: I get "configure: error: cargo is required. Please install the Rust toolchain from https://www.rust-lang.org/". What package should I use?
<NieDzejkob>raghavgururajan: rust, with the "cargo" output
<raghavgururajan>NieDzejkob, Thanks!
<raghavgururajan>NieDzejkob, What about for "no binary for interpreter `run-cargo-script' found". rust:cargo did not work for this.
<NieDzejkob>raghavgururajan: could you paste a fuller log?
<NieDzejkob>raghavgururajan: did you add rust itself too?
<raghavgururajan>patch-shebang: ./vendor/xml5ever/examples/simple_xml_tokenizer.rs: warning: no binary for interpreter `run-cargo-script' found in $PATH
<NieDzejkob>raghavgururajan: I think you can ignore that
<raghavgururajan>Cool!
<raghavgururajan>Yes, I added rust itself.
<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>basically as the manual says
<dustyweb>the thing is that I can't seem to connect
<dustyweb>I run ss -tulw on the vm
<dustyweb>and I see that the port is open there
<dustyweb>but
<dustyweb>if I do it on my local machine
<dustyweb>I don't see anything
<dustyweb>for 10022 that is
<janneke>dustyweb: yeah, that does't work for me either
<dustyweb>janneke: interesting
<dustyweb>it's what the manual suggests though
<janneke>or more accurately, it doesn't /always/ work
<dustyweb>!
<janneke>i found out yesterday...
<dustyweb>ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 cwebber@127.0.0.1
<dustyweb>is the command I was running
<dustyweb>ssh: connect to host 127.0.0.1 port 10022: Connection refused
<dustyweb>
<janneke>i /think/ the problem is related to the "-nic ..virtio" bit being insside the /gnu/store/pk335a22lr9h5wrj49r87p4vf70z9rad-run-vm.sh script too
<dustyweb>janneke: oh interesting
<janneke>iow, if you sed-out that bit
<janneke>you only get /one/ eth interface
<janneke>...but commit history suggests we sometimes need that virtio in the script
<janneke>for networking "or something"
<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
<janneke>*too
<dustyweb>janneke: well that seems partway there :)
<dustyweb>janneke: now it can start connecting and hangs
<dustyweb>progress!
<dustyweb>and I see the port open
<dustyweb>I manually edited the script
<dustyweb>janneke: I'll file the bug. Ok to credit you for helping me figure it out? :)
<janneke>sure!
<janneke>and thanks!
<dustyweb>thank you janneke !
<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)
<lispmacs[work]>Hi, I carefully followed the instructions in "Using the Offload Facility" section of the manual, but am getting this error during the offload test: http://dpaste.com/1E5JTDZ
<lispmacs[work]>Is this a bug, or have I done something wrong?
<janneke>helpful dustyweb!
<dustyweb>oh wait
<dustyweb>ahhhhahhahaha
<dustyweb>I wonder if I know what I did wrong :P
<dustyweb>I mean
<dustyweb>there still may be a problem here
<janneke>ahh!?...
<dustyweb>but I may have introduced an *extra* problem :)
<janneke>oh
<dustyweb>janneke: notice that I put the shell script in backquotes
<janneke>oh oh :-)
<janneke>hmm, so maaaybe it's all red herrings?
<janneke>i lead dustyweb deep into the woods
<dustyweb>I also lead janneke deep into the woods if so
<dustyweb>ok
<janneke>in that case, no idea what i saw yesterday...
<dustyweb>yep
<janneke>sorry! ;-)
<dustyweb>I am having another problem in that attempting to connect is just hanging
<dustyweb>but we can blame that on something else
<janneke>i'll have a look at this later, i need to go afk for a bit
<janneke>ttyl
<dustyweb>later janneke and thanks for the help
<dustyweb>janneke: so now I am down a different rabbit hole
<dustyweb>oh
<dustyweb>I said it :)
<dustyweb>yeah I guess I'll just add
<dustyweb>that it's the same with nginx as it is with ssh
<dustyweb>so, not an ssh config problem
<dustyweb>I'll write an email to help-guix since I'm not sure this is a bug really
<hendursaga>Anyone done multi-stage Docker builds in Guix?
<NieDzejkob>with guix inside of the container, or...?
<NieDzejkob>(because if not, then I don't see how guix is relevant)
<hendursaga>Yes, so that the resulting image is potentially much smaller.
<hendursaga>I believe Nix was/has that option somewhere.
<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>I don't follow...
<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.
<hendursaga>Oh. Hmm. That sounds like a better idea.
<nckx>raghavgururajan: Use ("cargo" ,rust "cargo") for outputs in *inputs.
<aidenholmes>hello
<aidenholmes>looking for documentation on how to remove the guix pacakge manager from debian
<raghavgururajan>nckx: Thanks!
<NieDzejkob>aidenholmes: you basically need to follow the installation instructions in reverse
<aidenholmes>oh
<NieDzejkob>basically, stop the daemon, clean up `find /etc -name '*guix*'`, /gnu/store, /var/guix
<aidenholmes>brb
<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?
<raghavgururajan>nckx: https://paste.debian.net/1155506/
<raghavgururajan> https://gitlab.gnome.org/GNOME/librsvg/-/tree/2.49.3
<raghavgururajan>That errror happend during 'build phase
<NieDzejkob>raghavgururajan: take a look at the definition for librsvg-next, I believe it already solves this problem
<raghavgururajan>Oh shoot! I did not know that there was librsvg next
<nckx>raghavgururajan: Those errors are firmly in Rust territory & I'm not a Ruster.
<raghavgururajan>nckx: Okay.
<aidenholmes>back
<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.
<aidenholmes>what about the guix builder users?
<nckx>Indeed! Those too.
<aidenholmes>how to remove them? by editing /etc/passwd?
<nckx>Hence NieDzejkob excellent advice to look at the installer script in reverse.
<nckx>aidenholmes: That's what I do.
<aidenholmes>what about using the userdel command?
<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.
*nckx afkizzle
<aidenholmes>fully removed, thanks
***terpri__ is now known as terpri
<bonz060>When working on a package, how do you normally generate a patch for a library with the paths set appropriately? I don't think this is applied: https://paste.debian.net/1155337/ during a guix build.
<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?
<raghavgururajan>dustyweb: The llibrsvg started using rust for everything.
<dustyweb>raghavgururajan: from a security perspective, probably good. From a packaging irritation perspective, probably not, eh?
<raghavgururajan>dustyweb: I am not sure about the security, but packaging yeah.
<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)
<raghavgururajan>dustyweb: Oh that thing, I thought Go did the job.
<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'
<raghavgururajan>I see.
<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.
<raghavgururajan>Cool!
<efraim>The odd numbers are dev releases, 2.48.8 is the latest librsvg release
<NieDzejkob>That's an odd versioning scheme.
<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
<leoprikler>(Remember this is before semver)
<raghavgururajan>dustyweb, hendursaga : I came across this (https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws). What do you think?
<NieDzejkob>raghavgururajan: Hyperbola seems to like to engage in, well… hyperbole. Many projects have a trademark policy, see Python, for example.
<lfam>I agree with DieDzejkob
<lfam>Also NieDzejkob
<raghavgururajan>NieDzejkob, I see.
<raghavgururajan>NieDzejkob, lfam: If firefox and rust share same trademark policy, then why firefix could not be provided in FSDG distros?
<raghavgururajan>Was there something else?
<NieDzejkob>weren't firefox logos distributed under a non-free license?
<NieDzejkob>I'm not entirely familiar with the situation, to be honest
<raghavgururajan>NieDzejkob, Were they? I am not sure.
<raghavgururajan>Ah I see, me too.
<raghavgururajan>I assumed firefox logos also share same policy.
<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: you've got mail
<raghavgururajan>Copy pasted from GNUzilla.
<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.
<raghavgururajan>Or am I missing something? >.<
<lfam>It's a situation where "the right thing to do" is only determined in court
<NieDzejkob>raghavgururajan: You might be interested in this discussion: https://internals.rust-lang.org/t/rust-s-freedom-flaws/11533
<lfam>And it depends on if Mozilla decides to enforce the trademark against distros
<lfam>Similar to patents
<raghavgururajan>Hmm.
<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>Very important IMO!
<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
<NieDzejkob>:)
<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.
<raghavgururajan>kmicu: I was just thinking about that.
<raghavgururajan>copyright vs trademark.
<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.
<dustyweb>janneke: what was fishy?
<dustyweb>oh
<dustyweb>mail :)
<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.
<raghavgururajan>+1
<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
<raghavgururajan>brown121407, https://ryf.fsf.org/categories/laptops
<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>janneke: yes, that's it
<dustyweb>I can't believe I missed that...
<dustyweb>I was trying to start from scratch and pair down my server config
<dustyweb>... obviously did so too far
<janneke>dustyweb: np, i can imagine
<janneke>see, i experienced a similar problem yesterday and now cannot reproduce it!
<janneke>so weird
<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
<raghavgururajan>Intresting!
<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.
<raghavgururajan>Pardon? I meant something else.
<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 installs bzip2
<rekado>oh…
<janneke>rekado: oh!
<janneke>and no way to ssh it out
<rekado>uhm, I can’t because I need coreutils to build all inputs
<rekado>oh, maybe I can do that
<janneke>bzip2-boot0?
<janneke>it should be in /gnu/store/*bzip*/bin/bzcat
<rekado>ah, good
<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
<rekado>it’s so convenient!
<janneke>yeah!
<janneke>it suprised me how convenient it is!
<janneke>(and we're cross-compiling, so many pkgs are available "cheap")
<janneke>rekado: => https://gitlab.com/janneke/guix/-/blob/wip-hurd-devel/gnu/system/examples/devel-hurd.tmpl
<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
<janneke>that fixes sqlite3
<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
<dustyweb>I think I'm getting the same problem
<dustyweb>it only happens *sometimes*
<dustyweb>there's probably a race!
<blendergeek>brown121407: There very few WiFi chipsets that do not require a kernel loaded nonfree firmware.
<brown121407>lfam: that's a bummer
<lfam>Yeah
<janneke>rekado: => https://issues.guix.gnu.org/42151
<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! :)
<dustyweb>janneke: yes I'm going to file a bug
<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
<lfam>Darn
<janneke>dustyweb: great, thanks!
<rekado>janneke: you’re right, pwd-long.sh fails
<janneke>"good"
<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?
<janneke>hah, "timing is everything"
<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
<raghavgururajan>lfam: Technically, should we rename all the packages?
<lfam>No
<janneke>rekado: where did the test suite pass?
<lfam>We should ignore the issue until we are asked to do sometehing
<raghavgururajan> Mmm..
<lfam>something
<janneke>rekado: we don't test-suite while cross-compiling
<raghavgururajan>Ah
<kmicu>raghavgururajan: actually anyone with a (unofficial) trademark can do that but in practice almost no one enforces that.
<rekado>janneke: oh, I must have misunderstood your reply here: https://issues.guix.gnu.org/42151#6
<janneke>yeah, it passes after i apply the patch
<rekado>ok, got it
<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
<raghavgururajan>kmicu: I see.
<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>not for our childhurd we don't
<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>(except for this bug)
<rekado>hmm!
<janneke>maybe in a couple of months when we build our chilhurds natively, on our childhurds...then that problem is gone
<janneke>this is so exciting!
<kmicu>raghavgururajan: even not registered Guix can legally stop me from distributing my hypothetical and terrible Guix fork under the name Guix.
<raghavgururajan>true
<gnutec>Hurd!!!
<gnutec>o/
<dustyweb>janneke: bug#42252
<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>dustyweb: nice bug report!
<janneke>i don't like the suggestion all that much, i would wait for more discussion/input
<dustyweb>janneke: kk
<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>hmm
<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.
<raghavgururajan>Thank you! :-)
<dustyweb>janneke: or maybe
<dustyweb>probably not really better but
<bonz060>NieDzejkob: wrt the patch, I was wondering what the problem was, since the patch wasn't being applied. Turns out I fixed it like this: https://paste.debian.net/1155529/
<dustyweb>guix system vm config.scm --extra-nic-opts=hostfwd=tcp::10022-:22,hostfwd=tcp::8888-:80
<dustyweb>janneke: kind of grosser ;)
<dustyweb>but lets you put others on that line that might not be hostfwd
<dustyweb>janneke: or, another way to do it
<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
<dustyweb>for testing out nginx
<janneke>sure!
<dustyweb>janneke: but I see
<dustyweb>yes this is also valid
<janneke>i'm just associating whether or not --extra-nic-opts would be good or bad
<dustyweb>but a different bug!
<janneke>sure
<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
<janneke>rekado: great, let's remove it
<janneke>s/remove/disable/ whatever :)
<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
<brown121407>Got it, thanks a lot
<lfam>But, my Thinkpad x200s has an Intel 802.11n chip without free drivers
<lfam>... as an example
<dustyweb>also
<dustyweb>it just struck me
<dustyweb>hm maybe that's not a problem nm
<blendergeek>It seems to me that there is a free driver for the Realtek RTS5129 card reader. I gather that from this thread: https://lists.debian.org/debian-kernel/2014/10/msg00501.html
<blendergeek>oops. I was gonna say it didn't seem to be working for me, but now it is.
*janneke -> zZzz
***sneek_ is now known as sneek