IRC channel logs


back to list of logs

<habs>lfam: Sorry for being late to respond here, but yes, I run guix pull with regularity. Remembering it now, I believe I got a kernel panic while I was trying to install emacs so I had to force reboot the computer, which could be a different issue than just getting disconnected.
<habs>lfam: There were a few files listed for that echo, so I did a "for i in $(echo /gnu/store/*-emacs-* | tr ' ' '\\n'); do guix gc -d $i; done" but I'm still getting the same error when I try to "guix package -i emacs"
<habs>Oh looks like he left, but if anyone can help me debug not being able to install emacs it would be much appreciated! Here is the error I get:
<kraji>hello. i installed guixsd today. is it possible to install telegram-
<fhmgufs>kraji: telegram-messenger? Is that a free software package?
<kraji>it is gplv3
<kraji>according to the site
<fhmgufs>Oh, wow, I didn't know.
<efraim>I don't believe there is a package written for it yet
<fhmgufs>It's even GPL 3, that's rare.
<fhmgufs>(for mainstream applications)
<efraim>looking at , I don't think we've packaged the dependencies google breakpad, google crashpad, lzma sdk (?), and we have qt 5.5 atm
<efraim> hmm modified qt-5.6
<fhmgufs>Anyway, I wouldn't use it, just because the server is proprietary.
<fhmgufs>And I remember our "Stiftung Warentest" (German product testing foundation) to rate it as "critical"
<kraji>mmh. so what would you recommend as chat application
<efraim>I don't know how long the qt-base compile time is, but full qt-5 on hydra is 6-8 hours
<fhmgufs>Yes, here it is:
<efraim>everyone here, including my kids schools, uses whatsapp, so I side-load it on my phone regularly
<fhmgufs>kraji: I dont know any good chat application, that respects your freedom and is commonly used.
<fhmgufs>Just use email or IRC. :)
<kraji>where is the clear command
<fhmgufs>kraji: Which command?
<kraji>the console command to clear the terminal
<kraji>sorry for all the stupid questions .p
<fhmgufs>Ah, I think it belongs to the ncurses package.
<kraji>ok. more questions .
<kraji>i-m checking the emacs interface and it seems that my system packages have some outdated packages - in red.
<kraji>i try to upgrade but it says that i should do guix system reconfigure
<fhmgufs>I don't know (not using GuixSD at the moment) but maybe just do what ir says?
<fhmgufs>* ir/it
<kraji>yes. but i don't understand the procedure very well.
<fhmgufs>guix system reconfigure rereads your system configuration if you changed it and applies the changes.
<fhmgufs>With system packages, do you mean the ones you specified in your configuration file?
<efraim>have you run `guix pull` since you installed? and as root?
<fhmgufs>And you have run guix pull since you installed?
<fhmgufs>Oh :)
<kraji>i think so
<kraji>i was reading the documentation
<fhmgufs>Then just reconfigure.
<fhmgufs>Then it will use the new package versions.
<kraji>so what distro do you use
<fhmgufs>Currently I'm at Debian.
<fhmgufs>Until I have a new (= old) computer which doesn't require non-free firmware
<fhmgufs>(for being able to use linux-libre)
<kraji>the texlive package in guixsd corresponds to the full installation of texlive?
<fhmgufs>kraji: Yes, there's also texlive-minimal.
<kraji>how to configure fonts? hinting, etc
<efraim>sneek: later tell kraji I have font-terminus and font-dejavu installed in my profile to help with rendering
<sneek>Will do.
<efraim>sneek: botsnack
<kraji>helllo. does anyone knows how to configure fonts in guixsd
<sneek>Welcome back kraji, you have 1 message.
<sneek>kraji, efraim says: I have font-terminus and font-dejavu installed in my profile to help with rendering
<kraji>@sneek I installed dejavu but I want to configure hinting.
<bon_>How does "guix import nix" work? It fails for me on all pkgs.
<bon_>guix import nix ~/code/src/nixpkgs/ scheme48
<bon_>guix/import/snix.scm:215:6: Throw to key `parser-error' with args `(#<input: #{read pipe}# 11> "XML [22], unexpected EOF")'.
<bon_>similar for all other packages
<catonano>yesterday I posted 2 messages on the dev mailing lust but only one is showing in the web archive here
<catonano>is the list moderated ?
<catonano>Ok I made a mistake. I posted the second one to guile-dev :-/
<efraim>bon_: I've never tried guix import nix, but I think we have scheme48 in guix already
<bon_>efraim: scheme48 was just an example. It fails in the same way on any nix pkg.
<efraim>ah ok
<efraim>yeah I have nothing other than the output of `guix import nix --help'
<davexunit>bon_: you're better off just writing the package recipe. no importer can do all of the work for you.
<davexunit>for example, with the Nix importer (when it works), you won't get an imported build script because those are written in Bash.
<bavier>any way to force the daemon to always offload builds?
<bavier>or is that the default...
<efraim>guix-daemon with N=0 is unlimited, maybe N=-1?
<efraim>that is if N is number of simultaneous builds and not number of cores
<efraim>that might work
<efraim>not now since I'm with the kids, but i'll have to pick your brain later about setting up offloading
<bavier>and I have yet to respond to your gsoc email. sry for the delay
<bon_>davexunit: thanks, any pointers on how to write a guix package recipe from a nix one?
<davexunit>nah. just use it as a point of reference.
<efraim>ah its ok, I think everyone was moving slowly with the servers down
<efraim>although in the end my wife nixed the new computer, so I might have to get creative
<bavier>efraim: I think for your project it shouldn't be an issue
<bavier>hopefully it won't involve building much
<efraim>I guess it wouldn't too much
<datagrok>immediately after installing guix 0.10.0, if I run "guix package -A guix" it offers only 0.9.0. Am I doing something wrong?
<davexunit>Guix cannot package the same version of itself
<davexunit>its important to keep up to date by running 'guix pull'
<davexunit>0.10.0 is old from a security perspective.
<datagrok>tyvm davexunit
<datagrok>after running 'guix pull' successfully, 'guix --version' still reports 0.10.0. is this normal?
<mthl>datagrok: it is a know problem
<mthl>there is a bug report
<datagrok>mthl: ah, thanks. I should have looked in the bug database for that problem too before asking.
<mthl>datagrok: Asking before looking at the bug database is not a problem. My answer was not meant as a critic. Sorry if I wasn't clear. :)
<datagrok>given the existence of that bug, I would like to report a different bug I'm experiencing. What version number should i provide to the bug reporting system?
<datagrok>in other words, how do I discover the version of guix I have installed after running "guix pull"?
<mthl>you can report version 0.10.0 and precise that you have run ‘guix pull’. I don't know a better way.
<datagrok>the error I'm seeing is "Error downloading release information through the GitHub API" upon "guix refresh." Is it expected that most guix users will need to set up GitHub API tokens?
<datagrok>thanks mthl
<efraim>I haven't tried, but you should only come up against the github api limit while doing `guix refresh -t github'
<datagrok>efraim: -t github is included in the set of selected types when -t is unspecified, correct? if so then that's what I'm seeing. Should I not be running 'guix refresh' to keep my packages up-to-date?
<alezost>datagrok: yes, as a user you never need to run "guix refresh"
<efraim>yeah, its included when no updater is specified
<efraim>guix refresh checks to see if there are updates, it doesn't update the packages by itself
<alezost>datagrok: I think you confused it with "guix pull"
<kyamashita>If someone is available to help me with a package definition, I'd appreciate it.
<kyamashita>I'm trying to package Tor Browser using a definition from Nix as a reference.
<datagrok>hmm. i've been under the (mistaken?) impression that 'guix pull' updates guix (the program) itself, while 'guix refresh' updates its list of available packages and versions, like 'apt-get update'
<kyamashita>In the patch-binaries phase, guix says that (string-append (assoc-ref inputs [input]) "/lib") is not a string.
<kyamashita>Am I doing anything visibly incorrect?
<bavier>kyamashita: if assoc-ref returns #f for any of the inputs, string-append will complain. is that the case here?
<davexunit>datagrok: no, 'guix refresh' isn't like 'apt-get update'. that's 'guix pull'
<janneke>kyamashita: this looks fishy: (string-join ... '((string-append (assoc-ref inputs "gcc:lib") "/lib")
<davexunit>datagrok: in guix, packages aren't binary blobs sitting on someone's server, they are source code that comes with the rest of the guix source code.
<davexunit>so updating guix itself gets the latest package recipes, too.
<janneke>don't you mean: (string-join (list (string-append ...) (string-append ...)))
<kyamashita>janneke: I thought backquotes and (list element1 element2 ...) were equivalent.
<kyamashita>bavier: I'm not sure how to tell
<davexunit>'guix refresh' is a developer tool for either updating package recipes in-place, automatically, or seeing what affect a package update would have on the rest of the system.
<datagrok>davexunit: aha! i understand now (mostly), thank you
<bavier>kyamashita: I think janneke has the right idea
<bavier>kyamashita: is there a way to build torbrowser without downloading a binary?
<kyamashita>bavier: Guile reports (equal? '(1 2 3) (list 1 2 3)) as true.
<kyamashita>bavier: Yes, but it looks like the official tools are Ubuntu/Debian specific.
<bavier>kyamashita: right, but that isn't true if there are evaluation sexps in the list
<janneke>kyamashita: i don't see backquotes used, and you would also need to unescape it again, which I also do not see...
<kyamashita>bavier and janneke: Really? TIL.
<janneke>kyamashita: try: (equal? (list car cdr) '(car cdr))
<janneke>kyamashita: and then: (equal? (list car cdr) `(,car ,cdr))
<kyamashita>janneke: Ah. I see what you mean.
<kyamashita>janneke: '(car cdr) doesn't return the car and cdr procedures.
<janneke>yes, same goes for executing your: ,(string-append ...)
<kyamashita>bavier: Also, even if I managed to package the tools for Guix, I don't think I have enough RAM to build and test on my machine. I only have 2GB RAM.
<kyamashita>janneke: Right. I'm going to correct the definition and see if it works. Thanks to you and bavier!
<bavier>yeah, I'm browsing the torbrowser build scripts for the first time now; seems like a mess
<bavier>I'm just not sure about a recipe that downloads the bundle
<kyamashita>bavier: That's understandable. Perhaps it should not be officially added if that is a problem?
<paroneayea>content addressed storage support in guix master now???
<davexunit>bavier: this is the problem that I was anticipating
<paroneayea>that is THRILLING!
<bavier>davexunit: we're already struggling with compiler binaries
<davexunit>bavier: yeah, this is a pretty clear case of "no" for me.
<bavier>I don't think we want to start adding recipes to download everyone's bundles
<davexunit>a web browser can surely be built from source.
<davexunit>bavier: right, we definitely do not want this.
<davexunit>that nullifies the advantages of guix.
<davexunit>and our mission.
<ng0>kyamashita: many thanks for starting with this, this is one the huge things missing.. and I'm too much invested in debugging other things to do them :)
<kyamashita>davexunit: Okay. Has anyone managed to build a Firefox-based browser on an X200 with 2GB RAM?
<davexunit>kyamashita: yes
<davexunit>and even if a beefier machine were needed, I'm not sure what your point is.
<kyamashita>ng0: No problem!
<kyamashita>davexunit: I wasn't sure about how much computing power was necessary to do so. I've never had to build IceCat on this machine.
<ng0>kyamashita: you need 4GB diskspace for 38.8.0 based torbrowser, ram shouldn't be a problem
<davexunit>I've never built it myself, but I know other people here have built it with limited resources
<ng0>8GB needed for debug+test
<kyamashita>ng0: I have more than enough space.
<ng0>I also think the bundle shouldn't be officially included, the browser itself is no problem
<kyamashita>davexunit: So I'll see about attempting to port the browser's build tools over.
<ng0>the bundle like it currently is. torproject eyes with Nix i think, or at least some part of the trac mentions monitoring reproducible builds
<kyamashita>ng0: eyes with Nix?
<ng0>bad translation sorry. "is looking into NixOS". I'm afk again
<bavier>kyamashita: Could a tor-browser package simply inherit from our icecat recipe, but use the source at
<efraim>on my i686 guixsd machine I have 1GB of ram, 10GB of /tmp and 10GB of swap (and a dead power supply)
<kyamashita>bavier: That would be cool if so! How does the inherit procedure work? I've seen it with regards to gcc.
<bavier>kyamashita: (define tor-browser (package (inherit icecat) (name "tor-browser) ...)
<bavier>kyamashita: the inherit form says to copy all fields from the named package, but override with any fields given.
<efraim>the examples in python.scm are shorter and easier to grasp
<kyamashita>bavier: Okay, simple enough. Would all of the modules imported in gnuzilla.scm need to be imported in tor.scm?
<efraim>just gnuzilla
<kyamashita>How do I inherit a package from a different file?
<davexunit>kyamashita: you need to import the module that the variable belonging to that package
<bavier>kyamashita: use the module
<kraji>why is necessary root permissions to write in the .config in the home folder of a user?
<davexunit>kyamashita: to dispel any sense of magic, (package (inherit foo) ...) isn't doing anything like trying to look up a package named "foo". 'foo' is simply the name of a variable whose value is a package object.
<kyamashita>davexunit: I see.
<davexunit>any expression that evaluates to a package is valid for the 'inherit' field
<davexunit>(package (inherit (package (name "foo") ...)) ...)
<davexunit>(package (inherit (package-with-python2 some-python-package)) ...)
<davexunit>ACTION groans at latest bug-guix message
<janneke>does that mean that gnome no longer crashes when dragging windows to different workspaces :-/
<datagrok>paroneayea: say more about CAS in guix master? I thought the package store was already a flavor of CAS?
<paroneayea>datagrok: packages generally were downloaded from their actual origin, if not from hydra
<cfd>Has anyone else experienced having trouble building guile? It seems to hang at the following line: UILEC ice-9/eval.go
<paroneayea>this means that if a file went away from the web, and Hydra didn't have a cache of it
<paroneayea>you might lose access to that program forever
<paroneayea>datagrok: the new CAS stuff, my understanding is, uses a mirror of tarballs by looking up their hash
<paroneayea>the same hash we already have committed
<paroneayea>so if the tarball goes down because maybe say disappears, it's ok, pull it down from the CAS mirror
<paroneayea>that's my understanding.
<bavier>cfd: compiling ice-9/eval.go generally does take a looong time
<cfd>Is there a way to avoid building Guile without using the Substitutes. I'm using a non-default (/gnu/store) location.
<davexunit>cfd: no
<davexunit>Guile runs everything
<datagrok>paroneayea: awesome! could it evolve into a distributed CAS, maybe use IPFS? where did you learn about this? I'd like to go read more
<cfd>Alright! I'll keep on waiting and see what happens! Thanks!
<kyamashita>davexunit: Why were you groaning earlier?
<datagrok>paroneayea: tyvm!
<davexunit>kyamashita: the same person keeps complaining about one particular bug and isn't very understanding.
<davexunit>couldn't help but reply...
<kyamashita>davexunit: I guess we'll see in 30 minutes.
<efraim>can someone else try `guix build perl-uri -S --no-substitutes' and see if they get a backtrace too?
<kyamashita>davexunit: I see now what you were talking about..
<bavier>efraim: I'm getting 404s
<efraim>after the 404s
<bavier>efraim: no backtraces; some errors regarding gnutls module
<efraim>ok, so I'll make clean
<efraim>i was getting some error about nix tarballs after it finished the cpan mirrors
<lfam>efraim: I do get a backtrace with `./pre-inst-env guix build perl-uri -S --no-substitutes`, from 44877dcc6
<lfam>Do you want a paste?
<efraim>don't think I need one
<bavier>efraim: oh, might be the CAS code, I haven't pulled that yet
<lfam>Yes, the backtrace seems to begin at uri->string
<lfam>With a content addressed nix tarball URI
<lfam>ImageMagick tagged a new release yesterday but they still haven't uploaded a tarball
<lfam>But, there is another release between yesterday's tag and the recent bug fix.
<efraim>debian-security tagged several CVEs against their version in stable
<efraim>according to the screen printout in qtbase, the license is lgpl2.1, lgpl3
<lfam>efraim: I believe davexunit fixed those bugs in d663e5e600
<davexunit>I upgraded to 6.9.3-10 awhile back
<davexunit>in response to "ImageTragick"
<efraim>ah that one
<lfam>They continue to fix bugs that haven't received a CVE yet
<davexunit>we should be quick to upgrade whenever they release a new tarball
<lfam>Okay, I'm going to update to the latest tarball. They'll probably release another today, since the cut the tag last night
<efraim>i'm working on qt-5.6.0 as modules atm
<efraim>took a swing at a bunch of source-not-available packages from the linter
<davexunit>lfam: there's been a release since 6.9.3-10 ?
<lfam>davexunit: Yes
<lfam>Or, 6.9.4-1
<davexunit>just making sure you weren't talking about the 7.x series
<lfam>And they also tagged 6.9.4-2
<lfam>Yes, thanks for checking. I appreciate it
<davexunit>which I imagine a lot of software won't support yet
<davexunit>imagemagick bindings like rmagick do not, for example.
<lfam>They just uploaded 6.9.4-2. Doing that instead
<lfam>Oh, that's the beta release directory. Never mind
<habs>lfam: Hi, sorry for being late to respond earlier
<habs>lfam: But yes, I run guix pull with regularity. Remembering it now, I believe I got a kernel panic while I was trying to install emacs so I had to force reboot the computer, which could be a different issue than just getting disconnected.
<habs>lfam: There were a few files listed for that echo, so I did a "for i in $(echo /gnu/store/*-emacs-* | tr ' ' '\\n'); do guix gc -d $i; done" but I'm still getting the same error when I try to "guix package -i emacs"
<lfam>habs: you should send a bug report to
<GNUtoo-irssi>I've found how to configure guix not to write to /tmp:
<GNUtoo-irssi>in parabola, I added Environment="TMPDIR=/gnu/tmp"
<GNUtoo-irssi>to the systemd unit file
<GNUtoo-irssi>Maybe I should bugreport to parabola to add a way to configure guix-daemon
<paroneayea>oh hey GNUtoo-irssi
<paroneayea>GNUtoo-irssi: nice to see you in #guix
<cfd>I'm having an issue compiling Guile. It reaches the following point and then errors out: GUILEC ice-9/eval.go
<cfd>building of `/home/me/gnu/6z9y2gmhvzrxsrizijna4bss0ffc5f2y-guile-2.0.11.drv' timed out after 3600 seconds of silence
<lfam>cfd: Check `guix build --help` for the --max-silent-time and --timeout parameters
<lfam>I'm not sure you should need them, though... Is your machine not very fast?
<GNUtoo-irssi>hi, is the following correct:
<GNUtoo-irssi>(especially the chown without a chmod)
<cfd>It is pretty old. You think the timeout is just too short? I didn't know that option existed. I'll look into those. Thanks!
<lfam>cfd: I think it fails because the build process is "silent" for 1 hour.
<lfam>GNUtoo-irssi: I use a non-default TMPDIR but I don't chown it to anything special. The default of /tmp doesn't either. But, the individual build directories in TMPDIR are.
<lfam>That is, the build directories are own by their build user
<GNUtoo-irssi>so it's ok that way, thanks
<kyamashita>I don't think the plan to inherit IceCat to build the Tor Browser will work. The two source trees are too different.
<kraji>hello. just to say that to configure fonts (hinting, etc) one can edit the fonts.conf file in /home/user/.config/fontconfig/fonts.conf
<bavier>kyamashita: I'd assume the recipe would need some tweaking, yes
<kraji>(for some reasons it needs root)
<kraji>and to solve emacs and other apps problems create the .Xdefaults file
<kraji>xft configuration
<GNUtoo-irssi>kyamashita: hi,
<GNUtoo-irssi>kyamashita: Assuming the users don't need javascript nor any add-ons, why not disable both?
<habs>lfam: Thanks, I reported the bug and it's here: Any responses would be very appreciated!
<GNUtoo-irssi>kyamashita: Would blocking the tor-browser on maximum security, and disabling add-ons makes it automatically FSDG compliant?
<lfam>habs: Thanks. You will get more readers there
<kyamashita>GNUtoo-irssi: All of the add-ons are free software, and I don't think that they recommend nonfree software.
<GNUtoo-irssi>kyamashita: if so we would have something that works, with the same network signature, and with less work from the developers
<GNUtoo-irssi>ok, I didn't try, the Tor project strongly advise not to install any anyway
<adfeno>There is a possibility that the add-ons repository doesn't have the *goal* to include only free software.
<GNUtoo-irssi>(it could change the way the browser behanve, and hence change its network signature)
<kyamashita>GNUtoo-irssi: Yes.
<GNUtoo-irssi>So disabling add-ons is easy to do
<adfeno>Remember that one of the sections of the GNU FSDG talks about the repositories involved.
<GNUtoo-irssi>however disabling javascript has a cost for the user
<GNUtoo-irssi>and if you enable it, you end up making user use non-free javascript
<GNUtoo-irssi>and if you add librejs, you end up breaking annonimity
<GNUtoo-irssi>(the browser would probably have a different signature)
<GNUtoo-irssi>So I'd suggest to have the FSDG version of tor-browser have the security slider blocked on the maximum, and with add-ons disabled
<kyamashita>GNUtoo-irssi: Those are good points.
<GNUtoo-irssi>Also check with the tor project mailing list,
<GNUtoo-irssi>this will make sure you don't break annonimity
<GNUtoo-irssi>(peer review)
<davexunit>does compiling tor browser from source yield a different browser signature because it won't be bit identical to what tor project provides?
<kyamashita>ACTION loads the TBB
<GNUtoo-irssi>Once we have an FSDG tor browser, we could also have a tails-like distro
<GNUtoo-irssi>Currently, it's sad to have to use non-fsdg software to have annonimity
<kyamashita>GNUtoo-irssi: Or we could just modify Tails build scripts.
<davexunit>in GuixSD land, that would just be a special operating-system expression
<davexunit>no need to make a new distro
<GNUtoo-irssi>yes, anyway the lack of FSDG tor-browser is really problematic
<lfam>You could also use the result of `guix system vm` so that it booted a bit-identical system each time
<kyamashita>davexunit: If we don't use the Ubuntu/Debian build tools or a VM, it shouldn't be bit identical.
<davexunit>kyamashita: right, that confirms what I thought.
<davexunit>this is the point I keep trying to make when people bring up the tor browser bundle
<lfam>We should make a demo of building it with Guix, and explain the advantages providing by specifying the dependency graph and build environment with our toolks
<GNUtoo-irssi>kyamashita: could we modify the official binaries?
<kyamashita>Also, it doesn't seem that the Tor Browser explicitly says "You should run this nonfree software". But the reproducibility won't be there if one doesn't build it using the tools they provide.
<davexunit>lfam: right, but then what about NixOS users that want to build it with their tools? or another distro?
<davexunit>there's a critical software freedom issue here.
<davexunit>it's basically the same thing going on with Signal on Android
<kyamashita>GNUtoo-irssi: I've done that personally using patchelf and LD_LIBRARY_PATH.
<lfam>davexunit: Creating a Nix or Guix build recipe and publishing the git commit gives everyone the graph and content-named sources. They can build those sources with their preferred tools
<GNUtoo-irssi>Can disabling the add-ons package manager, setting it to the maximum in the security slider, and removing the less secure level be done in a way that is visible with diff
<davexunit>lfam: the "problem" here is that now tor browser users can be grouped by OS
<GNUtoo-irssi>that way you could diff it with an official release
<davexunit>harming anonymity
<davexunit>GNUtoo-irssi: you mean modifying the binary? I'm afraid that is not sufficient for inclusion in Guix.
<lfam>If I use the Debian provided TBB, will I appear the same as if I use it on, say, Fedora?
<davexunit>that's a good question. I don't know.
<GNUtoo-irssi>lfam: how does debian package it?
<GNUtoo-irssi>in Tails it's not packaged
<davexunit>do Debian and Fedora build from source or use the pre-built bundle?
<lfam>We can use Guix as a way to make the dependency graph transparent, and then work towards reproducible builds across platforms
<kyamashita>lfam: Yes. But you are only anonymous if you use the officially compiled binary.
<GNUtoo-irssi>There is no deb in for it Tails
<davexunit>lfam: the builds from different OSes, while they may be reproducible, will never be bit-identical across distros.
<lfam>Debian uses the pre-built bundle
<GNUtoo-irssi>reproducibility and the network signature are two different issues
<kyamashita>lfam: Debian packages the Tor Browser Bundle?!
<bavier>I don't understand how the builds being slightly different might affect anonymity
<GNUtoo-irssi>The annonimity depends on the network signature being the same accross different machines
<davexunit>GNUtoo-irssi: I'd like to know with certainty whether Tor Project considers building TBB from source violates something they find valuable.
<davexunit>if we can build it and appear the same as other users, then great. no issues here.
<GNUtoo-irssi>The reproducibility between distros only increase the protection against tempering
<lfam>Agreed. We should definitely work with them to do this properly
<GNUtoo-irssi>davexunit: you could ask them, on their mailing list
<GNUtoo-irssi>I think that we should care the most about the network signature
<kyamashita>davexunit: Probably not, it's just that their current official build process requires Ubuntu, Debian, or their specified VM.
<GNUtoo-irssi>The rest can come later, we'd of course need to have it reproducible in guix.
<bavier>I would expect our own tor-browser package to pass --rounds=...
<davexunit>as long as we can build from source, with our own build tools, then there is no problem.
<kyamashita>davexunit: Correct.
<GNUtoo-irssi>And given that their build system requires a vm, they may even adopt guix for it later
<davexunit>however, I suspect that there may be a problem.
<GNUtoo-irssi>(At least for the GNU/Linux builds)
<davexunit>but I don't use TBB nor do I plan to, so someone else would have to find out.
<GNUtoo-irssi>The tor browser is my main browser (The other ones are for localhost or captive portals only)
<GNUtoo-irssi>but I'm really new to guix
<GNUtoo-irssi>I successfully bootstraped only some days ago
<GNUtoo-irssi>And I'm not really sure I want to use it as a distro yet
<GNUtoo-irssi>(not enough binary packages, and I've slow computers)
<GNUtoo-irssi>My main computer is 10 years old (Lenovo X60)
<bavier>GNUtoo-irssi: feel free to suggest packages
<GNUtoo-irssi>It's i686 and can have less than 4G of RAM maximum
<GNUtoo-irssi>bavier: I meant that guix package -i result in building stuff
<GNUtoo-irssi>even if I enabled binary packages trust
<GNUtoo-irssi>guix package -i hello builds the toolchain
<davexunit>GNUtoo-irssi: something is wrong
<GNUtoo-irssi>ah ok
<GNUtoo-irssi>it downloads some binary packages though
<davexunit>the mostly likely thing is that you are using too old of a release
<GNUtoo-irssi>how do I aptitude update with guix?
<GNUtoo-irssi>yes, that's my guess too
<davexunit>'guix pull'
<kyamashita>GNUtoo-irssi: Hydra garbage collects old binaries on the server.
<GNUtoo-irssi>ahh thanks
<habs>lfam: Thanks, also here is the ML archive post link:
<lfam>That's also important for receiving security updates
<davexunit>its important to keep up with the master branch as best as you can while we're in beta
<GNUtoo-irssi>I asked the other day, and had now answer
<GNUtoo-irssi>thanks a lot
<GNUtoo-irssi>right now I'm just testing guix
<GNUtoo-irssi>I'd have several uses cases for it
<GNUtoo-irssi>as a GNU/Linux distribution with guixSD
<kyamashita>davexunit: What was the problem you suspected earlier?
<GNUtoo-irssi>as a tool to build standalone applications (like the tor-browser)
<lfam>habs: Okay, now we wait for some responses :)
<GNUtoo-irssi>as a tool to build rootfs for embedded devices (assuming I find how to have global package configurations)
<GNUtoo-irssi>as a tool to build development environment (think of old toolchains)
<davexunit>kyamashita: I suspect that TBB has the same issue as Signal: building it yourself (with your own bootstrap binaries) breaks a critical feature, such as anonymity.
<GNUtoo-irssi>It's really nice, and it's GNU and FSDG
<GNUtoo-irssi>Yocto for instance would do most of theses things, but it's not FSDG, adn it doesn't do the distro part
<GNUtoo-irssi>so I cannot share builds with the distro I'd use for instance
<davexunit>GNUtoo-irssi: for global packages, GuixSD has a system-wide profile in /run/current-system
<kyamashita>davexunit: We'll see. I hope for more clarification from Tor Project developers.
<davexunit>I keep a small list of essential stuff in my system profile
<davexunit>but most things I install in my main user profile
<lfam>Have we decided who will contact the Tor Project?
<GNUtoo-irssi>davexunit: example of global configuration: strip binaries, remove -dbg, remove man
<adfeno>I also don't use Tor Browser Bundle. I'm not too found of "extreme" security. I like to encrypt things using OpenPGP keys, but most of my contacts aren't using it.
<GNUtoo-irssi>That way the rootfs becomes tiny
<davexunit>GNUtoo-irssi: oh, that's not what I meant.
<davexunit>GNUtoo-irssi: we don't do that.
<GNUtoo-irssi>Also sstrip or strip
<adfeno>Actually... I don't use Tor all-together.
<davexunit>that would require rebuilding everything
<GNUtoo-irssi>indeed, I was told that it could be done somehow
<davexunit>I mean, anything is possible.
<GNUtoo-irssi>davexunit: no need, at installation it would need to rm the man for instance
<davexunit>you cannot rm
<GNUtoo-irssi>or to strip the binaries at the installation
<lfam>We need to get Sphinx to stop embedding timestamps in manpages
<GNUtoo-irssi>ah because it symlinks?
<davexunit>you can modify package recipes to strip things
<davexunit>but once a package is built, it's immutable
<davexunit>which is a critical feature
<GNUtoo-irssi>davexunit: I get that, let's say you do guix vm-image, you produce an image from immutable packages
<GNUtoo-irssi>the packages of course have to stay immutable once built, but you can produce an output that is modified from them, right?
<GNUtoo-irssi>Example: immutable package -> some processing (strip, remove mans, etc) -> rootfs image
<kyamashita>GNUtoo-irssi: You'd want to do that beforehand.
<davexunit>sure, you can write additional build functions that make a copy of a store item and change some things
<davexunit>usually it makes sense to change the package's build script
<GNUtoo-irssi>copy, modify and ship in an image
<kyamashita>Example: Modify package definitions -> build package -> immutable and reproducible image
<GNUtoo-irssi>that way no rebuild of the binary packages takes place
<GNUtoo-irssi>and the build is shared with the host
<kyamashita>GNUtoo-irssi: Oh! I see what you mean now.
<davexunit>GNUtoo-irssi: yeah, you can make that work
<GNUtoo-irssi>ok, nice
<davexunit>but again, typically this is done in the package recipe's themselves
<GNUtoo-irssi>ok, the goal would really be to produces rootfs images to be used in non-selfhosting ways
<GNUtoo-irssi>Example uses cases: embedded devices (ARM) with very few storage space
<GNUtoo-irssi>or even have a kernel and rootfs in less than 16M or 8M (to fit inside your BIOS's flash, along with coreboot or libreboot)
<GNUtoo-irssi>Typically yocto or openWRT would be the tools to use for such things
<davexunit>the sky's the limit, really.
<davexunit>once you understand the guix framework.
<GNUtoo-irssi>but I'd prefer to have something FSDG that is well maintained
<GNUtoo-irssi>If you take libreWRT/libreCMC, it removed x86 supports and lags behind openWRT
<GNUtoo-irssi>as for yocto, I'd have to free it myself, and in both cases it's not as well maintained as parabola for instance, it lags behind
<davexunit>GuixSD is basically a distro framework.
<GNUtoo-irssi>indeed, that's the interesting point for that use case, yocto is one too.
<GNUtoo-irssi>and unlike yocto it's FSDG, seem to be well maintained, and also applies to my host machines
<GNUtoo-irssi>so I could share configuration, management, packages and so on
<GNUtoo-irssi>As I understand it, it's still beta and lack many packages (libvirt for instance), but that'll eventually be fixed
<GNUtoo-irssi>Parabola is also very nice but has some shortcommings, namely no reproducible builds yet, no -dbg packages and so on
<davexunit>I've packaged a bunch of stuff that I wanted. it's pretty easy to get started.
<GNUtoo-irssi>right now with guix pull, I'd be able to try stuff much faster
<GNUtoo-irssi>Since it's TV time here, my Internet connection speed is drastically reduced, but I'd be able to try making a vm soon
<sneek>So noted.
<GNUtoo-irssi>(when speed will be back)
<lfam>sneek: botsnack
<kraji>how to unrar?
<kraji>is there a way to decompress rar files using free software
<kraji>in guixsd?
<lfam>kraji: There is a python module packaged as python-rarfile. It was a required dependency of beets, so I added it, but I can't say how well it works.
<kraji>@lfam thanks
<lfam>kraji: Let me know if you try it. I'm interested to know if it works or not. I wouldn't mind asking beets to remove it from their requirements
<bavier>maybe we need an entropy-service for lsh :P
<janneke>or an easy example for how to re-use a test key?