IRC channel logs

<ZombieChicken>hrm

<ZombieChicken>GRUB won't install because "This GPT partition label contains no BIOS Boot Parition; embedding won't be possible"

<adfeno>j-r: Forgot to tell you: To post free/libre software-related job opportunities, there is <fsf.org/jobs>.

<adfeno>j-r: You can hire someone by outlining what is needed for such position.

<kyamashita>Common_Era: You can add objconv to your PATH variable in the terminal, if you haven't done that.

<adfeno>j-r: e.g.: If I would want to have a Guix package maintainer for LibreOffice, I would need someone who knows Guile, GTK+, GNU Make, and C++.

<kyamashita>ZombieChicken: If you install gptfdisk, you can use that to create a small BIOS boot partition for GRUB.

<Common_Era>Sorry. Yes, I've compiled ObjConv already, kyamashita

<Common_Era>It's in a different location though.

<kyamashita>Common_Era: You can add it to your PATH variable if you haven't done that.

<kyamashita>export PATH="/path/to/objconv/binary:${PATH}"

<Common_Era>I'll try.

<ZombieChicken>kyamashita: I just overwrote the start of the drive and started over

<Common_Era>Should I just use a Debian live image?

<Common_Era>Doing this from OSX is superfluous

<kyamashita>Common_Era: I think it would be easier if you did.

<Common_Era>I will.

<kyamashita>ZombieChicken: That works too. Now that I think about it, I don't know if we have gptfdisk preinstalled on the installation image.

<ZombieChicken>kyamashita: gf <TAB> doesn't list anything, so I'm going to say no

<kyamashita>I thought it was {,c,s}gdisk.

<ZombieChicken>Now you tell me

<adfeno>ZombieChicken: "gf" or "gp" <TAB>?

<kyamashita>Is it there?

<ZombieChicken>No. I just rebooted the VM

<ZombieChicken>I'll check real quick

<Common_Era>I'm going to start writing about getting GuixSD working on here.

<Common_Era>If anyone would like to see it, just tell me.

<ZombieChicken>cfdisk is installed

<ZombieChicken>fdisk

<ZombieChicken>sfdisk

<kyamashita>ZombieChicken: I don't know if GNU parted is installed, or if it can designate a BIOS boot partition.

<adfeno>Common_Era: How is your experience so far?

<kyamashita>Common_Era: That would be very useful if you are successful.

<ZombieChicken>parted is installed

<adfeno>Common_Era: I had to leave earlier, but I recall that you had a problem unsolved. This is why I asked.

<adfeno>ZombieChicken: Prefer parted

<ZombieChicken>Boot stopped asking for my to type out some random data???

<Common_Era>adfeno: I'm getting a live image of Debian ready. GuixSD is now installed, but it doesn't support EFI. I installed with the --no-grub option and now I'm reinstalling Grub.

<ZombieChicken>s/my/me

<Common_Era>kyamashita: I believe that this may work.

<kyamashita>ZombieChicken: Downloading GNU parted to see if it supports the correct partition type. For future reference, I guess.

<ZombieChicken>Like I said, I just overwrote the start of the drive and used cfdisk to set it to DOS

<kyamashita>Sorry, accidentally nuked my X server.

<adfeno>Common_Era: Oh... So, you'll be using Debian's copy of GRUB to boot GuixSD?

<adfeno>kyamashita: Wow!

<Common_Era>That might work. My first thought is to run grub-install on /dev/sda again from a live Debian.

<ZombieChicken>So the entire init system and package manager are in Scheme/Guile?

<adfeno>ZombieChicken: Yep.

<ZombieChicken>Interesting

<adfeno>And the packages can reuse themselves.

<ZombieChicken>reuse?

<ZombieChicken>you mean load and overwrite themselves to patch itself?

<adfeno>s/packages /package recipes/

<adfeno>E.g.: In Guix, a package recipe can get information about other package recipe, and even copy the whole recipe as its own.

<ZombieChicken>I don't guess there are any LTS libre kernels out there, huh?

<kyamashita>ZombieChicken: There are! Same versions as upstream, and updated along with them.

<ZombieChicken>nice. Now to figure out what about them might cause my systems to break

<ZombieChicken>and I just noticed the linux-libre kernel isn't in the Portage tree

<adfeno>ZombieChicken: About what would break the system, see http://h-node.org/

<adfeno>This is a collaborative place to test hardware and document the results.

<adfeno>s/test/test with only free distros/

<ZombieChicken>Does the Libre kernel just strip out the non-free blobs from the kernel?

<ZombieChicken>If so, all I'd have to do is see what I'm loading that would be on that list

<adfeno>ZombieChicken: Check the classification/rate on each item, and their notes.

<adfeno>If you can't find your hardware, it means no one tested. It doesn't mean it doesn't work.

<kyamashita>ZombieChicken: Yes (about the blobs).

<ZombieChicken>I'll mess with it later

<adfeno>About Linux-libre goal: What was inteded was to only remove the non-free parts. However, due to a **bug** (perhaps in Linux itself?), the user is not allowed to force installation of non-free parts manually.

<adfeno>... after the installation of the kernel.

<adfeno>(if you want to know why I called it a "bug", I can show you a reference)

<ZombieChicken>Sure

<ZombieChicken>sounds like it might be an interesting read

<adfeno>ZombieChicken: <http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html>. Search for the question "Is there anything that the project wants to do that it can't do now?".

<adfeno>Also, lxo is here, >)

<adfeno>:D

<Common_Era>Alright, now using Debian's Grub as the loader, let's see how this goes.

<kyamashita>ACTION awaits Common_Era's result

<adfeno>:)

<Common_Era>I'm getting an unknown filesystem error from Refind, but I believe I can fix it.

<ZombieChicken>What is the patch policy for guix packages?

<kyamashita>ZombieChicken: What do you mean by this?

<ZombieChicken>Well, are packages in GuixSD patched, or is the source the same as upstreams?

<adfeno>I can't speak for the Guix project all by myself, but I personally prefer to send patches upstream instead.

<ZombieChicken>Ditto, but it seems that most distros patch the code they use so you aren't actually using foo, your using their patched version of foo

<kyamashita>Ah. GuixSD keeps packages as close to upstream as possible while being secure, working with our odd filesystem, and fully free.

<adfeno>Besides, if the patches improve reproduceability of the package, then it's best to send it upstream.

<ZombieChicken>kyamashita: So patches for security problems (I'm assuming backports here), and patches to handle the non-FHS filesystem layout?

<adfeno>I'm not a "reproduceability tester", but I would prefer to do that.

<kyamashita>ZombieChicken: Not really backports, but yes.

<kyamashita>Packages that aren't bootstrap binaries are usually kept up-to-date when possible.

<adfeno>Guix has backports? I always though it didn't. :D

<ZombieChicken>I would be a little suprised given how small the userbase is likely to be, but you never know

<kyamashita>adfeno: I don't think it does, though I may be wrong...

<ZombieChicken>guixbuiler is a member of the kvm group???

<Common_Era>Hey, kyamashita, could you send me that example grub.cfg again, if you have it on hand?

<kyamashita>ZombieChicken: Yes, I assume for the "guix system vm" feature.

<ZombieChicken>Yeah

<ZombieChicken>I'm looking through the docs for the package manager

<kyamashita>Common_Era: Incoming!

<kyamashita>menuentry "GNU with Linux-Libre 4.7.2 (beta)" {

<kyamashita> search --label --set /dev/sda1

<kyamashita> linux /gnu/store/1w33nqlw4il84i4xr3pif45insmz82ln-linux-libre-4.7.2/bzImage --root=/dev/sda1 --system=/gnu/store/a4lbnf541sz9ps8pyh7zdmg0bm1lccnc-system --load=/gnu/store/a4lbnf541sz9ps8pyh7zdmg0bm1lccnc-system/boot iomem=relaxed modprobe.blacklist=kvm,kvm_intel

<kyamashita> initrd /gnu/store/a4lbnf541sz9ps8pyh7zdmg0bm1lccnc-system/initrd

<kyamashita>}

<Common_Era>Thanks.

<ZombieChicken>I'm used to Portage, so this feels a little like upgrading from an old pickup to a fixed up old truck

<ZombieChicken>Probably not the best comparison

<kyamashita>:P

<ZombieChicken>I don't like new trucks

<ZombieChicken>You can't work on them

<ZombieChicken>Debian would be a new truck

<ZombieChicken>it's nice and all, but you can't touch anything without everything breaking

<kyamashita>ACTION remembers their Ubuntu days

<kyamashita>Good times until I starting tweaking lots of stuff.

<ZombieChicken>I used Ubuntu for a few months back in the 9.x days

<ZombieChicken>I havn't touched it since

<ZombieChicken>I basically went from SuSe (back when you had to pay for it) to Gentoo

<kyamashita>Big jump!

<adfeno>I'm using Trisquel (based on Ubuntu), and do like it, and recommend it to new-commers. But I'm looking into installing GuixSD along with Trisquel.

<ZombieChicken>kyamashita: I got into Linux because I was annoyed how I couldn't do anything with my old Window XP install. After using SuSe for awhile, I got comfortable enough to mess with some of the more delicate things

<ZombieChicken>I like to tinker is all I can really say

<kyamashita>Trisquel is excellent for newcomers!

<adfeno>ZombieChicken: Are you sure you were using "Linux" at that time?

<adfeno>I meant: only Linux?

<ZombieChicken>Hmm?

<ZombieChicken>When I was on SuSe?

<adfeno>Yep. I asked because it seems the people at SuSe forgot to tell you that you were using the GNU operating system, with Linux as the core/kernel.

<Common_Era>:P

<ZombieChicken>It was SuSe linux 9.3

<kyamashita>ZombieChicken: I got into it after I looked up "how to be a hacker". I already hit walls on Windows XP when trying to tweak it for performance. I left for technical advantages and stayed for the freedom.

<adfeno>Historically and still today, most projects that have "Linux" in their names are actually "GNU with Linux" (when spoken) or "GNU+Linux".

<ZombieChicken>Pretty sure there is at least one distro that uses the NetBSD userland

<adfeno>ZombieChicken: My emphasis on "most" word.

<Common_Era>Alright, I've set Refind to use Debian's grubx64.efi as the loader, but I'm getting "error: unknown filesystem" because it's not set to find GuixSD's bzImage... I can't think of a way to set it to both.

<kyamashita>Common_Era: I wish I had the EFI experience to help more. :-/

<Common_Era>Does anyone know if there's a way to altogether skip Refind?

<adfeno>Common_Era: I'll check it out...

<Common_Era>I want to just boot to the Grub boot manager and be able to add my menuentry to that.

<adfeno>I.e.: I'll look for ways to help.

<Common_Era>Thank you.

<ZombieChicken>I am curious why the packages in /gnu/store/ are in base32 instead of ASCII or something otherwise human-readable?

<adfeno>ZombieChicken: Perhaps it's because the directories are supposed to represent a hash of some sort.

<kyamashita>Common_Era: My experience tells me that there's an EFI partition where you can put the GRUB image.

<Common_Era>I have access to the EFI partition. What Grub image?

<hugo_dc>What is the name for the SSH server?, I tried starting it using: herd start sshd but didn't work

<kyamashita>adfeno: Yep. A hash of the package and all of its dependencies, followed by the package name and version.

<adfeno>ZombieChicken: that hash would tell the system which package to use.

<adfeno>ZombieChicken: See kyamashita's message.

<kyamashita>Common_Era: You have to build one. You're using a 64-bit Macintosh, so I'd say a 64-bit EFI compatible image

<Common_Era>Okay, yes, but how can I get that? I'm inexperienced.

<kyamashita>Or maybe you can copy it from the Debian partition if it's the right type.

<kyamashita>Let me look it up.

<Common_Era>I already have a Debian grubx64.efi in my ESP, if that's what you mean, and I did boot from that, but it then can't find the bzImage.

<ZombieChicken>ah, ok

<adfeno>Common_Era: If you're using rEFInd, it seems to look for ".efi" files around all disk/block devices.

<adfeno>These ".efi" files are considered other bootloaders...

<kyamashita>adfeno: So Common_Era would need one for GuixSD?

<ZombieChicken>Hrm. How do I tell what packages are installed? guix package -I returns nothing (when run as root)

<Common_Era>So, it's impossible?

<adfeno>So one could have grub.efi at the root of the file system, and that file would have something (which I don't know) to tell where to find GRUB).

<adfeno>I'll read up on how to make an .efi file for GRUB to be used in rEFInd.

<Common_Era>I am too.

<kyamashita>ZombieChicken: For each user, that method shows only packages installed by that user.

<ZombieChicken>kyamashita: How do I tell what is installed in the system profile?

<kyamashita>ZombieChicken: I know that "M-x guix-installed-system-packages" works. I'm not sure about the commandline equivalent to that.

<adfeno>Common_Era: i just found something of interest: https://lists.gnu.org/archive/html/help-guix/2016-02/msg00013.html

<ZombieChicken>Well, if the system profile is in /gnu/store/, apparently the bare-bones.scm actually installs 2.2k packages...

<kyamashita>Whaaaa...

<kyamashita>That's not right. That's over half of the available packages!

<Common_Era>I've already done exactly that without that post, adfeno. Thank you, though.

<ZombieChicken>827M in /gnu/store, and ls /gnu/store | wc -l is 2283

<kyamashita>ZombieChicken: That total includes derivations, source tarballs, etc.

<ZombieChicken>Yeah, so something is wrong somewhere

<kyamashita>I get 11385 when I run it on my Guix store.

<kyamashita>Nothing is wrong, it's just what Guix puts in it's store.

<adfeno>Common_Era: So... that should have worked...

<adfeno>Common_Era: If you did exactly what was there.

<Common_Era>I did.

<hugo_dc>nevermind, I'll install Ubuntu

<adfeno>hugo_dc: What is the issue in detail?

<hugo_dc>haha, just kidding

<adfeno>:)

<hugo_dc>I'm just trying to start the ssh service

<adfeno>Hm....

<adfeno>Let me see...

<kyamashita>ACTION is afk

<adfeno>hugo_dc: Have you tried 'openssh"?

<adfeno>or "ssh"?

<hugo_dc>I've just tried and didn't work

<hugo_dc>but don't worry, I'm reading the manual, I think I found something that may help

<adfeno>Herhaps: herd status

<adfeno>s/Her/Per/

<kyamashita>ACTION is back

<adfeno>hugo_dc: Yep... `herd status` should list **all** available services.

<hugo_dc>Ok, thanks, let me take a look

<Common_Era>I'm building GRUB on OS X.

<Common_Era>It's past the configure script and make is working.

<adfeno>Wow! :D

<Common_Era>Yeah, this might work.

<kyamashita>Yes!

<adfeno>That's awesome, and might work indeed.

<kyamashita>ZombieChicken: Got your command.

<kyamashita>guix package --profile=/var/guix/profiles/system/profile -I

<ZombieChicken>thanks

<kyamashita>I forgot about the --profile option. :-)

<kyamashita>I get a much more sane 49 packages now, piping it through wc -l.

<ZombieChicken>Seems like tab completion is breaking in my fresh install

<kyamashita>How so?

<ZombieChicken>hrm

<ZombieChicken>I tried --profile=/va then tabbing to finish it and it didn't

<ZombieChicken>Might be some weird VM-related lag, though

<kyamashita>That doesn't work on my installation either.

<kyamashita>It might just be missing bash completion scripts.

<ZombieChicken>Seems so

<ZombieChicken>Thanks again. Now to muck about with things

<kyamashita>ZombieChicken: You're welcome.

<ZombieChicken>I guess the best way to add packages to the system profile is via config.scm and then using that system arguement to rebuild?

<kyamashita>Yes, that's the intended way.

<adfeno>Yep.

<ZombieChicken>Now to decide what makes more sense in a user profile and system profile

<adfeno>I can foresee ZombieChicken saying: "So many possibilities" ... :D

<ZombieChicken>adfeno: That goes without saying

<ZombieChicken>I figure anything multiuser should go into the system profile, whereas something like window managers and such should go in a user profile

<adfeno>:D

<ZombieChicken>Okay

<ZombieChicken>Am I misreading this, or are multiple packages defined in one file?

<ZombieChicken>like wm.scm for window managers

<adfeno>Yes, multiple packages can be defined in one file.

<ZombieChicken>I thought so

<ZombieChicken>Just feels weird

<ZombieChicken>is there any value in installing something as root but not putting it into the system profile?

<kyamashita>You can use that package as root only. So if you want root (and only root) to be able to use a package, that's how you do it.

<ZombieChicken>So it would make sense for root to install iptables, but something like clamav should probably be in the system profile?

<kyamashita>Yes.

<adfeno>jamesrichardson: Where you j-r here in #guix some time earlier?

<jamesrichardson>I was j-r earlier.

<adfeno>Oh, for a moment I though that I mistyped.

<adfeno>I'm glad I didn't.

<jamesrichardson>Haven't really been using irc for that long. Haven't decided which nick to really use.

<adfeno>Did you read my memos?

<jamesrichardson>I did.

<adfeno>Oh, thank you. :D

<jamesrichardson>Were you asking for help with libreoffice or were those just general statements?

<adfeno>Just general statements.

<jamesrichardson>ok, thanks.

<adfeno>Examples on how the organization you work with could define who to hire.

<adfeno>You could easiliy repplace the C++ language and LibreOffice example, with:

<adfeno>For graphics design: GIMP, Inkscape, Blender, and related languages.

<adfeno>For virtualization or server maintainance: QEMU, KVM, and related languages.

<adfeno>The key is to define which things you want for the employee to package to Guix, and which skills are needed.

<jamesrichardson>I've not really convinced management that this is a good solution yet.

<ZombieChicken>hmm

<adfeno>I know how he might be feeling...

<adfeno>... It's tricky, there's indeed some level of risk. But in the other case (if they decide to use CentOS, RHEL, or Ubuntu) and rely on support for these instead, they are **also** subject to that risk.

<adfeno>Besides, with CentOS, RHEL, and Ubuntu, they are all non-(free/libre). so the loss is in double.

<adfeno>Because **the organization** (in which you work) won't have control over its own computing.

<jamesrichardson>We've already run into several issues that were difficult to solve because we run slightly outside of the vendor's use cases.

<jamesrichardson>That was actually one of the driving forces to even consider leaving AIX for GNU/Linux.

<ZombieChicken>in (packages ...) in config.scm, how do I add additional packages? It seems like a waste to just make a huge list of cons for that

<jamesrichardson>I just add to the list... (packages (cons* ratpoison stumpwm nss-certs %base-packages))

<ZombieChicken>and changed cons to cons*

<adfeno>jamesrichardson: What do you use at work in your AIX workstations?

<kyamashita>ZombieChicken: Just type the name of the package. (packages (cons* <package> <package> <package> %base-packages))

<ZombieChicken>Yeah. Apparently the default was using cons instead of cons*

<adfeno>jamesrichardson: I mean, which software.

<kyamashita>cons* concatenates any amount of atoms into a list. cons only allows two.

<ZombieChicken>yeah. Like I said, cons was what was in there by default

<Common_Era>I've got it booting to and from Grub, but Grub says that the search command in grub.cfg is unknown and that the kernel should be loaded first.

<jamesrichardson>adfeno: it's a in house written app that handle point of sale operations. 1800 sites across US and CA.

<jamesrichardson>mine had cons* originally.

<kyamashita>Common_Era: Instead of using search, try using set root=<partition>

<kyamashita>set root=/dev/sda1

<adfeno>jamesrichardson: And you use IBM DB2 to manage every database?

<kyamashita>for example

<Common_Era>Okay, thanks.

<Common_Era>Should the kernel option --root be set to root or the partition, then?

<kyamashita>Common_Era: The partition, to be safe.

<Common_Era>Okay, thanks.

<Common_Era>error: no server is specified error: you need to load the kernel first

<Common_Era>Hmm.

<kyamashita>That's your boot error?

<Common_Era>It's those two on separate lines.

<kyamashita>This is my first time seeing it.

<kyamashita>Common_Era: Your hardware is on high difficulty mode, lol.

<Common_Era>Always is. :P

<Common_Era>There's literally one Google result and it's from the Ubuntu Forums and is about a live image. Does it, for some reason, think I'm trying network booting.

<Common_Era>I don't understand what the server is.

<kyamashita>Neither do I, unless it's a fancy name for a service.

<Common_Era>Hmm.

<Common_Era>Should --root be equal to one of the devices listed on the GRUB command line with ls? The ones that are called (hd0) and all that.

<adfeno>jamesrichardson: I'm doing some research about IBM DB2... And it seems to be a software, and there seems to be free/libre software to replace it too.

<adfeno>Perhaps the people who require using IBM's DB2 in a non-(free/libre) distribution don't actually want to package it to free/libre ones like Guix or Trisquel, or Parabola?

<kyamashita>Common_Era: All of mine say /dev/sda1.

<lfam>Reminder: Don't use `guix download` to learn the hash of source code: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24466

<lfam>Download it out of band and then use `guix hash`

<Common_Era>Well, if I set them to that, it gives error: no suitable video mode found. It does so with or without nomodeset

<Common_Era>It says Booting in Blind Mode.

<jamesrichardson>adfeno: at the moment db2 is a hard requirement. Too much stuff depends on it.

<ZombieChicken>so apparently xorg-server isn't a valid packag

<kyamashita>Common_Era: Wow! I've yet to see these error messages.

<Common_Era>It's weird.

<adfeno>jamesrichardson: I'll see if Parabola provides it.

<kyamashita>ZombieChicken: The file name of each necessary package module must be included in (use-package-modules ...)

<ZombieChicken>(packages (cons* xorg-server tcpdump %base-packages)) doesn't work

<ZombieChicken>ah, ok

<kyamashita>So, in your case, (use-package-modules admin xorg <other-modules>)

<ZombieChicken>yeah, I saw that

<ZombieChicken>and it's working now

<kyamashita>:)

<kyamashita>Common_Era: You might try different "vga=" arguments.

<Common_Era>Alright.

<lfam>Can anyone try building gnupg@2.1? I'm getting a test failures for tofu.test and sometimes gpgtar.test

<Common_Era>Even using vga=ask, I get the "no suitable video mode" thing.

<kyamashita>Huh...

<Common_Era>It appears that the vga= stuff isn't really used in Grub2.

<Common_Era>From what I've seen online.

<kyamashita>Really? I'll have to look into that.

<Common_Era>That's what I've been able to find.

<lfam>Looks like the intermittent failures of gpgtar.test were fixed in 2.1.14

<lfam>And I bet the tofu.test failure is a test with an expiration date: https://bugs.gnupg.org/gnupg/issue2393

<jamesrichardson>*sigh* I suspect there is no way to get an intel Wireless radio to work without the iwlfirmware...

<lfam>Yup. tofu.test was set to start failing on September 17... sigh

<lfam>I guess I will backport that patch

<lfam> https://bugs.gnupg.org/gnupg/issue2393

<lfam>jamesrichardson: You are right, unless there are free software drivers for those wireless cards

<lfam>AFAIK, none exist, but I'd be thrilled to be wrong about that

<kyamashita>Common_Era: I see something online about a unicode.pf2 file.

<kyamashita>GuixSD has one: /boot/grub/fonts/unicode.pf2

<Common_Era>I saw that. Do you think I should copy it over, just in case?

<jamesrichardson>lfam: I've not found any.... hmmm. guess I have to either use the non-free thing or purchase an libre compliant adapter.

<jamesrichardson>or just leave the laptop tethered to a network cable.

<lfam>Yeah, not a great situation :/

<kyamashita>Common_Era: You can try. I'm looking at a help.ubuntu.com webpage.

<Common_Era>I'll do that, I guess.

<kyamashita> https://help.ubuntu.com/community/UEFIBooting

<ZombieChicken>When running guix pull, does it upgrade the system version as well?

<adfeno>jamesrichardson: I have an idea... Perhaps you can keep the databases as they are in the current workstations, and do periodic migrations to databases not dependent on IBM's DB2 software.

<Common_Era>I've been to that page.

<adfeno>If you manage to keep the migrations periodic, you can perhaps switch to a free/libre software database managemnt system someday.

<lfam>ZombieChicken: `guix pull` is per-user. Can you clarify what you mean by "upgrade the system version"?

<kyamashita>ZombieChicken: guix pull only upgrades the user packages and substitutes. Running "guix system reconfigure" after that upgrades the system version.

<Common_Era>I can't find it on this page. Where does it want the file copied to?

<lfam>kyamashita +1 , but remember that `guix pull` is per-user. If you do it as your unprivileged user, root will not see the new version, and vice versa

<ZombieChicken>kyamashita: ok, ty

<Common_Era>Also, I believe because of --no-grub, my installation doesn't have that file.

<kyamashita>#/boot/efi/efi/grub

<Common_Era>I don't even have a fonts directory.

<adfeno>jamesrichardson: If you manage to migrate to a database which doesn't depend on non-(free/libre) software, then there are various free/libre to manage the databases which are already packaged to Guix.

<kyamashita>Common_Era: What do you have, then?

<Common_Era>In the boot folder in GuixSD, all I have is grub/grub.cfg

<kyamashita>I have a bunch of i386-pc modules and some locales.

<kyamashita>So maybe you need those 64-bit EFI modules, too.

<kyamashita>Try copying those over from Debian, too.

<Common_Era>I already got those.

<kyamashita>Hm. I guess we can just try and see if it works.

<Common_Era>It doesn't I don't have a unicode.pf2 file anywhere.

<kyamashita>I don't know if those unicode.pf2 files are portable between installs. And it's not good practice to send and receive files like that over the net, anyway.

<adfeno>I'm not a database expert, but I can see: guile-dbi, postgresql, sqlite, mariadb, and some others.

<adfeno>... with package recipes already made for Guix.

<Common_Era>Yeah...

<jamesrichardson>adfeno: some of the developers are looking at moving to postgresql.

<adfeno>Oh... That's great! :)

<adfeno>I don't know how the information on Wikipedia is up-to-date in regards to comparison of database management systems, but it really competes with IBM's DB2.

<adfeno>Of course, each has it's good and bad points, but that's expected.

<jamesrichardson>* jamesrichardson sorting out what to do about wireless on this lovely laptop.

<adfeno>jamesrichardson: About wireless....

<adfeno>... Are you using GuixSD right now?

<jamesrichardson>adfeno: I've used sqlite a good with one-off projects.

<jamesrichardson>Just load GuixSD on my laptop. The intel wireless card is giving me grief.

<jamesrichardson>I've load the k.o kernel and the non-free drivers. That doesn't seem the proper solution.

<adfeno>jamesrichardson: can you do lspci -knn ?

<adfeno>And paste the output somewhere that doesn't require non-free JS, like: paste.lisp.org ?

<jamesrichardson>It's an intel wireless 7260 [8086:08b2] (rev 83)

<adfeno>OK... Searching about it now.

<kyamashita>Common_Era: Have any other ideas? I think I'm officially stumped at this point.

<jamesrichardson>All I can find is the iwlwifi drivers. If you see a free/libre driver, that would be great.

<kyamashita>i.e. my guess is as good as a search engine's.

<Common_Era>I really don't know anymore.

<adfeno>jamesrichardson: I couldn't find test about it on h-node. This means that no test was registered/tried by us.

<adfeno>See: https://h-node.org/wifi/catalogue/en/1/1/undef/undef/undef/undef/wifi-works/undef?search_string=7260&submit=Search

<adfeno>Names are equal, but revisions change.

<adfeno>jamesrichardson: My best advice is: buy an USB wifi dongle. If you can afford to, do the following: buy an USB wifi dongle from this list: <http://www.fsf.org/resources/hw/endorsement/respects-your-freedom>.

<adfeno>By following the last advice I gave, you'll be supporting the organizations that really care for software freedom.

<adfeno>... in terms of which hardware is made to work with free/libre distros by default.

<adfeno>Well... if you excuse me and my messed words, I must go now, it's 23:00 here.

<kyamashita>Common_Era: So I guess GuixSD isn't gonna cut it on a modern Mac yet. You might try Guix on another distro, such as Debian.

<Common_Era>I'm still thinking.

<kyamashita>Mhm.

<ZombieChicken>Depending on how much work you are willing to put out, LFS with Guix on top might work

<ZombieChicken>or Gentoo

<ZombieChicken>Does guix system container work for users? That might be interesting for things like Steam

<jamesrichardson>Is anyworking on lvm support for GuixSD installations?

<ZombieChicken>I'm wondering if it supports cryptsetup and LUKS myself

<kyamashita>ZombieChicken: I'm not as familiar with Guix's system-level features, due to hardware limitations.

<kyamashita>jamesrichardson: I'm not sure. I know it was mentioned in the past.

<kyamashita>Cryptsetup and LUKS works, but not LVM.

<ZombieChicken>any way to have Guix install without installing GRUB?

<jamesrichardson>I see on the website it says lvm is not supported, but I see a lvm2 package.

<kyamashita>ZombieChicken: Supply the --no-grub option to guix system commands.

<kyamashita>jamesrichardson: I guess it's a work in progress, then.

<jamesrichardson>I probably subscribe to the mailing lists (like I need more email ;) and see where I can help out.

<kyamashita>jamesrichardson: Cool! We're always open to having more help with Guix. :)

<jamesrichardson>I'm currently trying to package a few things that's missing (at least from my view ;)

<jamesrichardson>keychain, which is almost functional, and stumpwm.

<kyamashita>stumpwm is a popular wish among our Lisp/Scheme enthusiasts.

<jamesrichardson>Then I'll sort out what it will take to move the rest of the systems at the house to GuixSD.

<jamesrichardson>I've been doing a lot of work in Clojure lately. I'm going to have to sit down and actually learn Scheme/guile in the near future.

<jamesrichardson>trying to package stumpwm has shown me I don't understand the lisp environment as well as I believed ;)

<ZombieChicken>If you can mess about with one Lisp, I'm fairly sure the others are rather quickly picked up

<kyamashita>Guix got me into Lisp and Scheme.

<ZombieChicken>Only problem I have with Lisp software is they tend towards massive, monolithic programs

<jamesrichardson>elisp actually got me into Lisp. I went to Clojure mainly so I can express solutions to problems and host them on operating systems where I'm unable to compile lisp (either clisp or sbcl or guile)

<ZombieChicken>jamesrichardson: I'm ~90% sure SBCL can compile a stand-alone bin

<kyamashita>But I hear that those binaries can be very large.

<ZombieChicken>I think it depends on the options

<jamesrichardson>ZombieChicken: the monolithic thing seems to happen with Lisps, java also.

<ZombieChicken>iirc, by default SBCL and most CL implementations include the source and a REPL with the bin, so it's everything you could need.

<ZombieChicken>jamesrichardson: I don't know about Java, but Lisp seems to encourage the monolithic thing

<ZombieChicken>and I think most of it is just feature creep

<alienpoop>Does anyone use dwm here?

<ZombieChicken>I used to

<alienpoop>ZombieChicken, I was seeing your name in the chat logs a lot, nice to meet you.

<ZombieChicken>Hello

<ZombieChicken>No clue why you'd see my name a lot. I don't get on IRC much

<alienpoop>Maybe the things I was searching for.

<alienpoop>Do you use another wm now?

<ZombieChicken>awesome

<alienpoop>I tried that out when I installed guixsd but it does not play well with my monitor.

<alienpoop>My monitor uses MST so awesome thinks it is two screens.

<ZombieChicken>Ah

<ZombieChicken>No clue what to suggest then

<alienpoop>Well, dwm works just fine, but I had to compile it myself, which sort of defeats the point of packaging.

<ZombieChicken>dwm wasn't meant to be packaged

<alienpoop>Right, I was just wondering if I was on the right line.

<alienpoop>Trying to get used to guixsd has been a bit of a ride.

<ZombieChicken>I just got it booted in a VM today

<ZombieChicken>It is certainly interesting

<brendyn>Welcome to the crew jamesrichardson

<brendyn>jamesrichardson: I think part of the reason non-ext4 filesystems & lvm aren't supported well yet is because they require services to be made, or something like that, since we aren't using systemd

<jamesrichardson>brendyn: thanks. Have to be careful what I wish for ;)

<brendyn>jamesrichardson: I want to build GuixSD up into a full end user distro. It's going to take some time though

<jamesrichardson>That would be good.

<brendyn>I'm still using Guix on top of Parabola. One of these days I'll switch over.

<jamesrichardson>Actually one of the reasons I'm looking to leave Debian is over the systemd thing, but that's another story.

<brendyn>Personally I have no opinion on the topic. What's the problem with it? Does GNU Shepherd solve those issues?

<ZombieChicken>brendyn: What is your relation to the GuixSD project?

<brendyn>ZombieChicken: I just got started packaging software for it recently and I'm thiking of ways to make it better.

<jamesrichardson>The biggest issue I have is that it is becoming a monolithic thing that wants to take over everything (seemingly) between Linux and GNU. I also seem to have no choice in the matter. I've been using runit as my init for several years.

<ZombieChicken>I don't think systemd's maintainers care about GNU. I seem to recall they were looking to replace everything

<brendyn>Well I hope Guix isn't too monolithic. All Guix stuff is in the same git repo but it technically doesn't need to be that way.

<brendyn>What is "everything"?

<ZombieChicken>From what I've seen they are making a slow effort to take over the Linux userland

<jamesrichardson>everything, outside of things that should be in pid 1. It affects the way sudo/su works, nohup was broken a while back, it now has a mount command to handle filesystem mounts.

<ZombieChicken>Don't forget their attempts to make udev systemd-only

<jamesrichardson>It also replaces syslog and writes binary logs.

<brendyn>So it's breaking the trusty old unix philosophy?

<ZombieChicken>To be fair, there might be a case for binary logging in some enviroments

<ZombieChicken>brendyn: Pretty much

<jamesrichardson>yes, do one thing and do it well.

<brendyn>Well GNU herd currently does half of a thing, so maybe that is a good compromise \\o/

<jamesrichardson>The choice should be left to the admin/owner of the box/application not imposed by the system.

<ZombieChicken>They claim that it's all just housed in one repo and is actually several seperate utilities, but I'm betting (I won't touch the project with a ten foot pool myself) that none of it will work without the rest

<jamesrichardson>I can't replace a utility with another one and not expect breakage.

<ZombieChicken>Frankly, Guix doesn't really adhere to the Unix Philosophy very well, either

<ZombieChicken>no reason for a package manager to be able to build a virtual machine image, for example

<alienpoop>Plan9 does but sadly my hardware is not supported.

<ZombieChicken>but Guix/GuixSD seems to resemble a LispM moreso than a Unix system, though

<ZombieChicken>or at least has that potential

<brendyn>ZombieChicken: It's true, but Emacs is proven to be a system people love despite it trying to do everything.

<jamesrichardson>well, Guix seems to be doing things right, or at least the way I like things done.

<ZombieChicken>There is a difference between continuing to support a hack of an editor and writing a Lisp-based userland

<ZombieChicken>I'm apparently not making much sense. I should head off and get some sleep

<ZombieChicken>and let this update finish overnight

<ZombieChicken>Later folks

<brendyn>Right I was wondering what you were trying to say.

<brendyn>Good night.

<jamesrichardson>Doesn't seem to many lispy things packaged yet.

<brendyn>I was thinking of packaging mzscheme 372 and with Arc

<brendyn>Maybe it can run on Racket?

<jamesrichardson>I'm looking at packaging stumpwm. It depends on a few other things.

<freedom0>alienpoop: dwm is much smaller faster and simpler. it suck less xD

<alienpoop>freedom0: Yeah, been using it for the last four years or so. Pretty heavily patched now.

<brendyn>Ok so what do you think about adding donation support to Guix packages? Instead of just having (home-page ..."), we could add (donate ...), then people can build GUI package managers that implement mechanisms for donation

<brendyn>For exmaple (donate (paypal "...")), (donate (bitcoin "..."))

<alienpoop>I would have to trust the package maintainer to put the correct details.

<brendyn>Yes

<jamesrichardson>Well, enough for tonight. Don't think I'll have a stumpwm package anytime soon :(

<brendyn>I suppose I better email the crap I've written to the mailing list ;p

<jamesrichardson>lisp dependancies, and asdf things. Not really an expert there. I'll ask something on the mailing list see what happens.

<brendyn>Go for it, people are friendly there

<jamesrichardson>I'll do that tomorrow after I've had some sleep.

<jamesrichardson>Is the best way to publish new packages to email the list?

<brendyn>jamesrichardson: Yes, there has been talk of adopting some kind of bug tracker like system, but currently the system is quite simple; just email your patches to guix-devel@gnu.org

<brendyn>There are a variety of minor conventions to follow. You can look at `git log' to see how to format commit messages, and look at other packages to see the indentation conventions.

<dvc>so much for getting through university without using proprietary software. They managed to find the one MCU without an open toolchain (68HC08)

<quigonjinn>dvc: it definitely took some extra effort to find one

<dvc>do you know of one? gcc doesn't support it, and the nxp forum says there isn't one

<quigonjinn>dvc: i mean it took some extra effort to find some mcu that doesn't have a free toolchain. I haven't used that chip

<dvc>xD

<dvc>I think I'm just very unlucky

<adfeno>Hi all! :D

<adfeno>I have a question about propagated-inputs

<adfeno>I'm making a package recipe for Python Foolscap. It depends on Python Twisted TLS (for which I'm also making a recipe for, based on the existing Python Twisted recipe). Foolscap depends on Twisted TLS just to get the extra dependencies, and it's failing at test phase.

<adfeno>Foolscap's test phase says that it doesnt have a dependency that was provided by Twisted TLS.

<quigonjinn>dvc: in my case, I have come across SaaSS compilation so...

<adfeno>So, I don't know if I should, and where I should, use the propagated-inputs.

<adfeno>Foolscap → Twisted TLS → (PyOpenSSL, **Service_identity**, IDNA)

<adfeno>The one in double asterisks is the one which Foolscap says it doesn't have.

<adfeno>I'll try passing the Python Twisted TLS dependencies directly to Python Foolscap to see if this one stops complaining. I tested with propagated-inputs, but I don't really know how to use it.

<brendyn>adfeno: You put it in package just like inputs and native-inputs

<adfeno>Indeed.... But the problem is "where" or "in which package definition".

<adfeno>I have an idea...

<brendyn>Hmmm not sure. Try putting it in Twisted TLS and see what happens. The other thing is that you might need a wrapper like with bioinformatics.scm:couger

<adfeno>Hm...

<brendyn>But I still don't understand this that well myself. I'm packaging some python things too and have found a need for progagated inputs too

<brendyn>I would think logically that both Foolscap and TLS would need propagated inputs, otherwise the input wouldn't get "propagated"

<adfeno>As far as I can tell, "prapagated-inputs" are supposed to be things that are used once and stay for a long time to be reused across other packages.

<adfeno>... So the suggestion to test with the Twisted TLS dependencies should have worked, but it didn't.

<dvc>propagated inputs are needed when a packages header files use another packages headers

<dvc>or when it's in the packages pkgconfig requires field

<brendyn>I thought it just meant they also got installed

<adfeno>I'll try putting Twisted TLS itself on propagated-inputs to see what happens.

<adfeno>Now I have Foolscap depending on propagated-input Twisted TLS, which in turn depends on "normal" inputs IDNA, Service_identity and PyOpenSSL.

<brendyn>So how do they affect header files?

<adfeno>I don't really know, I'm not a Python programmer. :)

<adfeno>I know that Foolscap depends on Twisted TLS just to get its dependencies.

<brendyn>I mean in general. Aren't guix packages just files in a directory. How does propagated-inputs change that?

<adfeno>Well... DIdn't work.

<adfeno>Foolscap's test phase says there's no module named service_identity.

<brendyn>Hmm I think I've seen that before

<brendyn>Is this a python2 package?

<adfeno>Note: The name of the Guix recipe is service-identity ("-" instead of "_"), do I need to do some extra work in order for Foolscap recognize it as "service_identity"?

<adfeno>brendyn: Yes, it's a Python2 package.

<brendyn>adfeno: Have you set #:python ,python-2 in arguments?

<adfeno>brendyn: Yes, In all of them.

<brendyn>I don't think guix's variable names have any effect on the packages themselves

<efraim>do you need some (properties `(python2-variant, stuff?

<brendyn>What does properties do?

<adfeno>brendyn: Was about to ask that.

<efraim>it'll make sure you use the correct python2- variant

<adfeno>Well... Not that I know about.

<efraim>otherwise depending on the python2- inputs it might auto-translate the python- version to a python2- version

<adfeno>The recipes I have right now are just "simple", I didn't do extensive testing or reading about the packages I'm creating recipes for.

<iyzsong>adfeno: did you package https://pypi.python.org/pypi/service_identity ?

<adfeno>But as far as I have read, they only talk about Python versions, no "variants" (like "minimal" or others).

<adfeno>iyzsong: I'm trying.

<adfeno>iyzsong: Yes, I have the recipe ready.

<adfeno>I just need to know why Foolscap doesn't see it.

<iyzsong>ok, then next is make sure you can import it in the foolscap's build environment. try 'guix environment python-foolscap -- python3', and then 'import service_identity'.

<adfeno>iyzsong: Are you sure you want me to use Foolscap with Python 2?

<iyzsong>no, I think you should first get python3 version to work.

<adfeno>OK.

<iyzsong>in guix, python-xxx are for python3.

<adfeno>Here, in the recipe I'm making, all of them are python2-

<adfeno>And all their arguments have #:python set to python-2

<brendyn>,python-2

<adfeno>brendyn: Yes..

<adfeno>(arguments `(#:python ,python-2))

<brendyn>I think. Maybe it works without that too.

<dvc>brendyn: yes that's true, but why would you want a package to also install another package? there is a section in the guix manual on this.

<brendyn>I've read all the stuff about propagated inputs

<brendyn>Well, meta packages are useful like for installing desktop environments

<adfeno>Oh...

<adfeno>I think I got it...

<jmd>By jove I think he's got it!

<adfeno>Hahahah

<adfeno>I always forget that when changing the the "inputs", you have a string, and a unquote (","), so when you change one, you have to change the other.

<adfeno>Foolscap had `(("python2-twisted-tls" ,python2-twisted))

<adfeno>Now it should work... :)

<adfeno>Waiting.

<davexunit>ACTION is surprised to see that no one has updated emacs to 25.1

<efraim>Wouldn't it affect bootstrapping?

<davexunit>why?

<efraim>I assumed it would cause a full rebuild so I didn't try

<brendyn>Oh, it's released.

<efraim>In my mind I lump it with guile I guess

<efraim>So that actually wouldn't make any sense

<brendyn>Someone in #emacs was freaking out about guile containing an emacs directory the other day :P

<davexunit>why?

<brendyn>Some people are scared about guile-emacs

<davexunit>oh yeah

<adfeno>OK, I made some great progress with Foolscap.

<adfeno>Now the problem seems to be with my recipe for Python PyCrytopp.

<brendyn>davexunit: Can you publish the Emacs upgrade so I can't start watching Youtube in Emacs plz?

<adfeno>brendyn: You "can't" start?

<brendyn>can

<adfeno>Oh ok.

<paroneayea>o/

<adfeno>PyCrytopp's build phase says: Exception: problem: couldn't get version information from revision control history, and there is no version information in 'src/pycryptopp/_version.py'. Stopping.

<ZombieChicken>Uh, does guix run test on packages that include them?

<brendyn>ZombieChicken: Yes

<ZombieChicken>Pretty sure those are almost entirely useless for end users

<adfeno>I'll download Pycryptopp and see what this means.

<brendyn>ZombieChicken: Why?

<ZombieChicken>brendyn: I'm trying to find where that was discussed for LFS, but mainly those test are for upstream to make sure they didn't screw something up at some point. In fact some packages always fail some test, but upstream still considers them okay since they are supposed to fail. I've run into this kind of thing with Gentoo, and they really don't do the end user any real good

<paroneayea>brendyn: yeah, people are scared of guile-emacs, for reasons I just can't understand

<ZombieChicken>I'm also wanting to know how to disable them since a test is currently failing for gnutls-3.4.7, which means it won't finish updating

<paroneayea>most of them are afraid that it means our elisp history will be thrown out and replaced with scheme

<brendyn>Hmm well I think many tests are useful

<paroneayea>and that's not gonna happen

<brendyn>For example, without the TZDATA test, duplicity could get packaged with broken time zone info, making incremental backups fail

<brendyn>So that test has helped me package duplicity. Why not just disable tests you consider pointless?

<ZombieChicken>And how do I do that?

<brendyn>I guess you would add a patch?

<ZombieChicken>brendyn: I just installed this VM yesterday, and I don't recall seeing docs on how to patch build scripts

<brendyn>Well it depends on the particular program and how it runs tests

<ZombieChicken>brendyn: point me to the docs on how to patch the build script and I'll figure that much out myself

<davexunit>brendyn: I need to figure out how to activate xwidgets

<davexunit>I added cairo and webkitgtk to the inputs but that wasn't good enough to make xwidgets or cairo support work

<brendyn>ZombieChicken: I don't know if there is any documentation on that. Disabling all tests is as simply as adding #:tests? #f to arguments, but disabling particular tests depends on the build system

<davexunit>ah, need to explicitly enable them with configure flags

<adfeno>Is there a definition to tell the Guix builder to "run this script that's inside the source tree, before going to "build" phase of the package".

<adfeno>?

<davexunit>adfeno: add a phase

<davexunit>see the many examples of "modify-phases" in the gnu/packages directory

<adfeno>Oh, ok :)

<davexunit>hmm I don't think our webkitgtk works with emacs

<paroneayea>soon emacs really will be able to be a WM for just about everything, huh :)

<davexunit>that will be a lovely day

<davexunit>I only ever have 1 of 3 windows open full screen usually: emacs, terminal, browser.

<paroneayea>davexunit: http://www.howardism.org/Technical/Emacs/new-window-manager.html of course, some people have done it :)

<paroneayea>davexunit: I use M-x shell and M-x ansi-term a lot, but they aren't always great.

<davexunit>yeah

<davexunit>unfortunately

<paroneayea>ansi-term in theory can do everything, but

<paroneayea>I keep trying to use emacs keybindings for emacs things and forget I need to prefix them, and also the ansi-term gets bound to the size of its initial window (emacs-terminology for window)

<davexunit>I'd like to make guile-wm act as a really window manager and use emacs for most things

<paroneayea>davexunit: well, bipt did do that fun 5 second demo recently of guile-emacs + guile-wm running from the same guile... :)

<davexunit>that was neat

<rekado>I'm having a problem with nginx from Guix on a foreign distro.

<rekado>I tried overriding all the paths, but I still get this error when starting nginx with my new config:

<rekado>2016/09/19 15:58:07 [emerg] 21402#0: mkdir() "/gnu/store/2m86akjk8fqlp58922ipv2j9vgg9bvx0-nginx-1.10.1/client_body_temp" failed (30: Read-only file system)

<rekado>I don't know what client_body_temp is and how I can disable it.

<rekado>any ideas?

<davexunit>rekado: the default value is probably to a place in /gnu/store

<rekado>I'm running it like this in an environment where nginx is available: nginx -c /path/to/my/nginx.conf -t

<davexunit>(our nginx build has a lot of issues like this)

<davexunit>oh yeah, the error message clearly shows this as the case

<davexunit>rekado: see http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_temp_path

<rekado>I just override the prefix with "-p /some/other/path" now

<rekado>at least it starts now

<rekado>ah, thanks

<davexunit>the problem with nginx is that if you configure it to use something like /var/log/nginx for logs or whatever, when you run 'make install' it tries to create that directory!

<davexunit>same with /etc/nginx and /run/nginx

<ZombieChicken>brendyn: So how do I go about forking a build script to make that change to a build?

<rekado>davexunit: looks like passing "-p" is sufficient. Certainly easier than overriding all paths in the config.

<davexunit>okay cool

<brendyn>ZombieChicken: I can't answer that when I don't know what you are building. Some times it's easy like the gstreamer example with modify-phases and deleting some files

<adfeno>Where does Guix stores the build logs?

<ZombieChicken>brendyn: gnutls-3.4.7

<ZombieChicken>Isn't there a general way to patch these scripts or someplace to overlay the script so guix uses the user version instead of the in-tree version?

<brendyn>Not sure sorry :/

<davexunit>emacs building with xwidgets and cairo enabled! time to play the wait and hope the build doesn't fail game

<ZombieChicken>Oh, how well do I know that game...

<ZombieChicken>It's probably the biggest down side to a source-based(ish?) distro

<davexunit>things are looking good

<ZombieChicken>Anyone know if there is an option to see what packages would be updated without actually doing the update?

<davexunit>ZombieChicken: guix refresh -l

<adfeno>How do I test a Guix recipe by, say: Creating the build environment, unpacking the source, and having the root set to the source tree; all in Guix?

<adfeno>Do I need to pass "--container" to guix environment?

<davexunit>you can't test a guix recipe that way

<davexunit>the only way is 'guix build'

<adfeno>It's because I'm trying to figure out why the "build" phase for Python Pycryptopp failed.

<jmd>adfeno: Pass -K to guix build

<adfeno>It has something to do with a function that wasn't run... Although... I still have to find it out.

<jmd>adfeno: Then you can go into the build dir and do any investigation there.

<adfeno>Ah.... :)

<adfeno>That's good :)

<adfeno>Hm...

<adfeno>Fouund something. :)

<ZombieChicken>davexunit: ty

<adfeno>It seems Pycryptopp depends on the cryptopp library... What a mess. :)

<adfeno>And it wasn't really clear to me at the beginning.

<rekado>I tried cairo in 25.1 rc2, but it segfaulted :(

<davexunit>I got emacs 25.1 but webkit browsing was borked

<rekado>the xwidgets stuff is a little too experimental for my taste. And the fact that it builds on top of the old webkit API is a little sad.

<davexunit>no https support

<davexunit>rekado: yeah that tripped me up a bit. I tried using the new webkit.

<rekado>I started hacking on this. First thing is moving to the webkit2 API.

<rekado>this will also simplify getting JS return values

<rekado>right now this is done by setting the title of the website.

<davexunit>I was unable to get the web pages to scroll correctly or resize when I change the size of a buffer

<rekado>i.e. serialising the value, storing it in the title, then reading it out again.

<rekado>yeah, same here.

<davexunit>that's a nasty hack

<rekado>I can scroll only with space and backspace.

<rekado>otherwise the containing buffer will be scrolled in odd ways

<davexunit>yeah...

<davexunit>I thought things were more polished than this

<rekado>I'm a little surprised to see code like this in Emacs. It looks a little premature.

<davexunit>well they've made it opt-in with a configure flag, at least.

<davexunit>not confident enough to enable it by default

<ZombieChicken>I'm noticing a lack of file-level comments in the guix source. Even the Commentary sections are only section comments

<davexunit>what does that mean?

<davexunit>the source in gneral is very well commented.

<adfeno>How do I add an option to a phase? E.g.: I want to make sure that the unpack phase uses unzip with -a option.

<davexunit>adfeno: you need to replace the phase

<davexunit>there is no build system argument for doing what you want

<davexunit>you should read the source code to know what you can/can't do

<davexunit>in this case, see 'unpack' in guix/build/gnu-build-system.scm

<adfeno>I asked because I was looking at "guix/build/gnu-build-system.scm" and saw "#:allow-other-keys" so I was thinking that it could be possible.

<davexunit>allow-other-keys means that it's not an error to pass keyword args that aren't specified in the arguments list

<adfeno>Which script defines the "add-after" procedure?

<adfeno>Or is it defined in Guile or Scheme?

<davexunit>adfeno: add-after is not a procedure

<davexunit>it's part of the modify-phases syntax

<adfeno>Oh... :)

<davexunit>I don't understand the second question

<davexunit>modify-phases is in (gnu build utils) I think

<adfeno>oh... I see.

<ZombieChicken>I think he was wanting to know if (add-after) was Guile or standard Scheme

<rekado>ZombieChicken: neither

<adfeno>Yep.

<rekado>Scheme allows you to write your own syntax.

<davexunit>it's a meaningless distinction

<davexunit>standard scheme provides very little

<rekado>"modify-phases" is syntax provided by a macro.

<davexunit>would be pretty odd for standard scheme to have a macro for guix ;)

<adfeno>Hahaha

<davexunit>ugh, I'm stumped.

<davexunit>I have two machines. one builds stuff and runs 'guix publish' so the other machine can download what it's built

<davexunit>they are using the same guix

<davexunit>yet due to a graft the second machine is building stuff from source

<davexunit>I don't understand. same guix. should have built the same derivations.

<quigonjinn>Should i reference arch (parabola takes it from them) on a patch I want to use on a guix package? It is a modified version of a patch that was posted in the gcc-patches mailing list.

<adfeno>While reading the info page for `unzip`, I was thinking if I should really go into the trouble of replacing the "unpack" phase just to add the `-a` option.

<adfeno>I don't have full understanding on reproducible builds, but I guess that option might break reproducibility.

<adfeno>So I'll just ignore the recommendations of the Crypto++ project, and use the default unpack phase.

<bavier>quigonjinn: you may mention the source of the patch in its header, if appropriate

<quigonjinn>bavier: the original source is being mentioned. should i mention arch as well?

<quigonjinn>arch linux, that is

<bavier>quigonjinn: if it includes modifications from arch, then I'd say yes

<ZombieChicken>Is there a way to pass special CFLAGS to the build process, like -pipe or --march=native?

<adfeno>ZombieChicken: I guess you can do:

<davexunit>#:make-flags

<adfeno>(arguments `(#:make-flags: [What you want]))

<ZombieChicken>Please don't tell me I'd have to do that with every package I want to install...

<davexunit>if you want to alter the build in this way, yes.

<adfeno>ZombieChicken: It depends.

<adfeno>ZombieChicken: See davexunit's message.

<davexunit>I don't understand why it would have to be done for every package. presumably there's a specific package you are trying to build that needs those flags in order to build correctly.

<ZombieChicken>it's less of a case of needing them for something to build correctly (actually, when I asked how to patch build scripts before, no one was able to tell me, so that doesn't help anyways), but being able to build packages for one's individual system.

<davexunit>what does "build packages for one's individual system" mean here?

<adfeno>ZombieChicken: Also, to patch something, perhaps there are examples on this.

<davexunit>there are tons of examples

<bavier>davexunit: cpu optimization flags, etc

<adfeno>I recall seeing gnu/packages/python.scm with tons of examples on patches.

<ZombieChicken>davexunit: --march compiles code specific to the target architecture, whereas -pipe speeds up build time by avoiding the use of intermediate files, iirc

<davexunit>I'm guessing this another "why isn't this gentoo?" question

<davexunit>we don't use global use flags.

<davexunit>package builds are intended to be deterministic

<davexunit>not tweaked based upon the specific machine it's being compiled on, which is nondeterministic.

<adfeno>davexunit: Then, I was right about not using `unzip` with `-a` option. :)

<adfeno>↑ (seems to create OS-specific text files).

<davexunit>I don't know much about those flags, but if they are useful to have on every build then the gnu build system could be changed to include them by default. this would require rebuilding every package.

<ZombieChicken>davexunit: So in effect guixSD is meant to be a bin-based distro?

<davexunit>no

<bavier>ZombieChicken: if you're interested in such things, and you know that you'd be building everything from source yourself, you could try adjusting the default compiler flags in guix/build-system/gnu.scm

<davexunit>guix is clearly a source-based distro.

<davexunit>but also does binary distribution

<adfeno>As an extra goal: The project aims to make the packages deterministic or reproducible across all archtectures.

<adfeno>... and all environments.

<adfeno>This means that the behaviour of the package shouldn't change according to environment.

<davexunit>correct

<adfeno>This of course, is an extra goal, you can contribute by making a normal package recipe, and some time later, people will try testing it and fixing it for reproducibility.

<ZombieChicken>bavier: Wouldn't making changes to the build profile like that get clobbered on update?

<davexunit>ZombieChicken: you would maintain your own fork at that point

<davexunit>which many people do

<bavier>ZombieChicken: indeed, you'd need to maintain a fork/branch that you rebase as necessary

<ZombieChicken>So let me see if I understand this

<ZombieChicken>GuixSD is meant to be a source-based distro (with binary option) that doesn't let a user sanely configure their packages or build enviroment, and in essense removes one of the biggest advantages of a source-based distro?

<davexunit>there are no global settings that a user can tweak to affect all builds.

<davexunit>on purpose.

<davexunit>because our goal is reproducibility.

<adfeno>ZombieChicken: The user is welcome to make his own package recipes based on other ones, and even breaking the deterministic advantages of those.

<davexunit>yes, since every package is just a Scheme object, the user can freely hack away on them.

<ZombieChicken>adfeno: If I was up for forking a significant number of packages, I'd look at LFS

<davexunit>I maintain a few custom packages

<davexunit>if there is a problem with a significant number of packages, we should fix them upstream.

<davexunit>but as of now we don't know what those problems are.

<janneke>ZombieChicken: what kind of change would you want to make, globally; do you have a practical example?

<adfeno>ZombieChicken: One extra goal of Guix or GuixSD is: Avoid the extreme sides of Conway's law. As described here: <https://wingolog.org/archives/2015/11/09/embracing-conways-law>

<davexunit>ZombieChicken: the purpose of being source-based isn't for gentoo-style global compiler tweaks, it's for users to be able to reproduce the work of others so that they don't have to trust binaries from a third party.

<davexunit>no single point of trust.

<davexunit>a gentoo-like system where everyone's builds are different because every user makes special configuration is fine, too, but it's just not what we're after.

<jmd>davexunit: Well I think both purposes are pertinent.

<davexunit>jmd: yes, both are valid.

<adfeno>Extreme sides we want to avoid: 1) dependency-based dependent on single point of trust, might have slow updates; 2) source-based, where things can break easily when updated; 3) everything bundled, making different versions of the same thing appear in different "bundles"; 4) make everything into a container (ala Docker); 5) language-specific package management.

<adfeno>3,4,5 can bring special problems to free/libre software movement since these packages come from places not always aligned to the GNU Free System Distribution Guidelines, and might provide non-(free/libre) software to the end user.

<adfeno>And since the system distribution project has no control over 3,4,5 then there are only three options: a) make a list of accepted/blocked packages; b) make our own server; c) do as Guix and GuixSD do (take the packages out from those places).

<adfeno>Does #:use-module (guix build-system python) make the package recipe implicitly use: #:use-module (gnu packages python) ?

<bavier>adfeno: no

<adfeno>bavier: Thanks :)

<adfeno>Which one should I choose when building libraries: static or dynamic building?

<adfeno>Crypto++'s make targets allow either one.

<bavier>shared libraries are preferred

<bavier>but installing both is fine too

<adfeno>Wow... I just noticed that if I choose to run just `make` it'll build statically, and will produce an .exe file... ugh (reminds me of WC).

<adfeno>Shared = static ?

<bavier>adfeno: shared ~= dynamic

<bavier>"dynamic" typically refers to binaries that link against shared libraries

<adfeno>Hm...

<adfeno>Now I just have to find out how to tell make to use "dynamic" instead of plain "make".

<jmd>adfeno: If the static libraries are very large, then sometimes we put them in a seperate output.

<adfeno>That is, use: make dynamic

<adfeno>jmd: I don't know how large they are since the recipes I'm making will need further review by others to improve them.

<adfeno>But as far as I know, Crpyto++ provides one library with a lot of supported cryptographic schemes.

<bavier>adfeno: you can replace the 'build phase to have it call 'make dynamic'

<nichi_>is there a way to specify a different store dir for guix-daemon to use?

<jmd>nichi_: Not dynamically I don't think.

<davexunit>I believe the NIX_STORE environment variable controls that

<jmd>But you can pass --with-store-dir at configure time.

<jmd>

<adfeno>Why does most "replace"s inside "modify-phases" have "zero?"?

<adfeno>Is it to check for the exit status of the previous phase?

<bavier>adfeno: correct

<davexunit>adfeno: it was nothing to do with 'replace'

<davexunit>zero? is a predicate procedure that returns true if the argument is the number 0

<bavier>phases are expected to return a boolean value

<davexunit>in guix it is often used to verify that a system* call was successful

<davexunit>since a process exits with a status code of 0 upon success

<davexunit>it has nothing to do with modify-phases or previous phases

<adfeno>So if I do: (zero? (system* "make" "dynamic")) I'm expecting the "make dynmaic" to succeed?

<adfeno>Oh... I think I got it.

<adfeno>:)

<adfeno>Thanks

<jmd>Actually it is used so often that I think a convenience wrapper in guix/build/utils.scm is justified.

<davexunit>adfeno: yes

<davexunit>jmd: yeah, I agree.

<adfeno>Well... I have made some good progress today. :)

<adfeno>I must leave now, have a college test to attend/do.

<davexunit>good luck

<adfeno>Thanks :)

IRC channel logs

2016-09-19.log