<ZombieChicken>Gentoo ebuilds tend to be a bit patch-happy, they tend to use sed to 'patch' things in ebuilds without actually patching anything, they use a library of shellscript functions (which aren't exactly sourced in the ebuilds) which might be a little rough to migrate about...
<ng0>multiple issues. in addition to the portage issues when you do package for gentoo itself.
<Drakonis_>portage was one of the earlier source package managers
<ng0>thing X could leak into thing Y and that... and so on
<ZombieChicken>That said, I'd like to see a scaled down system where a user can say "I don't want KDE installed", and nothing would pull in a KDE dep. Just enough to avoid massive dependency trees that one may not want
<adfeno>ZombieChicken: You can do it with Guix, sort of, actually.
<Drakonis_>many of gentoo's users seriously prop it up as a really big thing
<ZombieChicken>Drakonis_: For us, it is. It's one of the reasons some of us don't use bin distros
<ng0>while no one needs that unless you really build a system for redistribution or some super customized hardware.
<ZombieChicken>ng0: For me it was a way to avoid pulling in libkitchensink every time I wanted to merge some small package. It's annoying as hell to merge all of Gnome because you want one package that has an optional dep on Gnome, but someone decided to require it
<ng0>speaking of pain.. how are eabis or what they are called constructed on guix? I paused with uclibc-ng packaging, but this is one problem I have. I'd continue packaging it in late 2017 and very low priority while i do the other things
<adfeno>drakonis Perhaps we must report bug to Linux-libre while we gather info on how to at least work around the freezing inssue.
<adfeno>OK, now add... (wait a sec, getting words)...
<ng0>I'll search for it tomorrow or monday. I'll note this somewhere. should i CC guix-devel or email it directly to you? I don't know if i find an guix package of it somewhere, but i've seen an 'remove-most-bundled-deps.patch'
<adfeno>drakonis: Do you see, when editing the boot entry, a line with "splash"?
<lfam>ng0: You can send it to either place. I'll be happy to use it :)
<adfeno>Drakonis_ Do you see a line starting with "linux"?
<ng0>before duplicate work happens.. do we have some bored toolchain experts who is dying to package uclibc-ng? because i have small progress there too, but won't work on it focused again at least before next summer :)
<ng0>my problem is just, I have so many open patches on the list, and the only ones super relevant for me right now are the psyc.scm and gnunet.scm ones, and I fear they could 'drown' in all of the other patches.
<ng0>hm... i don't know. can you enable them and see why it fails? as far as I remember rigt now there was an expectation about bsd or osx things..
<ng0>I shouöld've commented it. I'll be to bed now
<lfam>Okay, I'll try it. Please remember to leave a comment in the future :)
<Drakonis_>maybe the issue is that i copied it to my usb instead of writing it to a clean disk?
<adfeno>Drakonis_: OK, so we are in the same track. Now, to keep things towards the goal: Do note my request: Everytime you boot the USB, until we can fix this, remeber to edit the boot entry and add "debug" in the end of the "linux" line.
<ZombieChicken>Drakonis_: nomodule Disable module load <- That sound like what you might be looking for? It may disable all module loading, however
<adfeno>lfam: Heh... You haven't seen nothing, I must always remeber to pass "-c 1" to every guix command, otherwise I might create an atommic bomb of my 5-year old friend or fry my work/college computer, which is the only one that works decently with free/libre distros.
<ZombieChicken>Drakonis_: Can you load the USB up somewhere and drop a copy of the Debian kernel onto it? I don't know how much that might cause breakage nor where, but that would likely support your hardware
<lfam>Drakonis_: Do you see how 'gnu/system/install.scm' is an operating-system declaration? And operating-system takes a (kernel) argument that you can use to specify something besides the default kernel.
<ZombieChicken>How would I provide you with a copy of the Debian kernel? Well, you /could/ try compiling it yourself if you have a day or two, or you could see if you could download the .deb pkg and run deb2tgz or something over it
<lfam>Actually, my university used Gmail to provide us email, and when I left school I transferred everything to a new account. I must have triggered a bug, because Gmail gave me all the spam I had ever received, everything deleted, even messages from before the account existed. ~90% of it was not my "real" mail. They keep *everything*
<rekado>I’m a little late for this but I’d like to issue a friendly reminder that on this channel we don’t provide support for non-free software.
<rekado>you’re all welcome to discuss these things privatel, but on the channel we should keep things on topic.
<rekado>we shouldn’t offer cut and paste recipes for how to install non-free software. For many people it may be easier to replace part of their hardware with alternatives that work without non-free software.
<rekado>That said: Guix is flexible enough to allow dedicated and knowledgeable people to patch the deblobbing scripts for Linux-libre to suit their needs. This is free software, after all. But we don’t steer people towards this path by giving them instructions on how to achieve this.
<quigonjinn>Building a package, a reference to the build directory ends up in the runpath of a library, so validate-runpath fails. Is it acceptable solving the issue "manually" with the use of patchelf for example?
***[0xAA] is now known as Zer0Pings
<rekado>quigonjinn: it’s preferable to figure out why the reference gets embedded.
<rekado>patchelf is a hack and it doesn’t even work on all supported platforms.
<quigonjinn>older versions of the package do not produce such a reference. I may have to git bisect
<dvc>would doing something like nixos does for rust packages be also an acceptable solution? Since rust binaries are compiled statically anyway, there isn't really a point spliting the source into multiple packages...
<jmd>On my machine, the user "john" seems to be in the sudoers file. But I don't remember putting him there, and there is nothing in /etc/config.scm which seems to explicitly say he is. How is that determined?
<civodul>jmd: maybe the user is in the "wheels" group?
<civodul>dvc: not sure what you mean; are you suggesting not to have separate packages?
<OriansJ>Finally after a month of Development, I am pleased to annouce that the stage0/M0 Line Macro assembler is now self hosting and capable of cross assembly with only the creation of a definition file.
<dvc>they are improving the situation, we no longer need snapshots, and there is a new cdylib crate type for creating shared libraries. but if the crate isn't a shared library or a binary then I'm not sure there is too much point in deduplicating the source into multiple packages...
<davexunit>it's weird that this hasn't been a concern of theirs until recently.
<davexunit>how can you just spend so much time designing a language and tools are forget about all of the operating systems that they are intended to run on?
<dvc>I think they were focused on stabilizing the language for 1.0
<dvc>the tooling works pretty well if you aren't trying to package it for a distro... :)
<davexunit>"it's really great until you want other people to run your software"
<OriansJ>civodul: The most impressive part is that all together it only is 1772 bytes in size and 441 instructions total; ironically I probably should shrink that since I haven't even done any real optimizations yet.
<dvc>I think it's similar to npm. it works great for what it's intended to be used, creating a webapplication inside a docker container. If we'd build our packages locally with network access and just distribute the binaries that would be simple too...
<dvc>not saying we should of course - we shouldn't
<dvc>one core assumption that distro package managers make that lanugage specific package managers don't make, is that the distro package manager assumes that there is only one version of each package that works for all other packages. We do have qt-4 an qt, but that's not what I mean. npm and cargo specify complicated combinations of (small) packages that work together...
<civodul>it might be that for these we should import several versions of each package
<dvc>would it be possible to use something like cargo-vendor inside the importer? that would import a crate, download the package and run cargo-vendor on it to crate a tarball that includes all the source it needs. then we could have a very simple build system that would build cargo with it's dependencies
<dvc>I guess I could setup a small webserver somewhere that distributes already vendored packages that are interesting for distros, most crates aren't interesting to package anyway...
<civodul>dvc: sounds theoretically possible but inconvenient, no?
<civodul>it's best if we don't have to host all the source ourselves
<dvc>yep. One item on the list is publishing cargo source tarballs. I'm assuming that alexcrichton is planning on doing this, so at least for the most important package we'd be covered. I'm just writing to him to ask him about his plans in this regard
<OriansJ>civodul: I wouldn't trust it as much if we didn't atleast have a mirror of the source code because ultimately other systems can be shutdown without us knowing about it before it happens
<OriansJ>If you are worried about bandwidth, use magnet links and let people use bittorrent protocall to get the source/binary files
<civodul>i'm more concerned about infra maintenance and transparency
<civodul>seems like my laptop's SSD is slowly dying
<OriansJ>civodul: infrastructure can be really simple, if you remember to break it up and avoid anything unessential
<civodul>each individual thing is simple, but it all adds up :-)
<dvc> * Simplifies packaging of updates. (Fedora maintainer does not need
<dvc>to keep tabs on unbundling patches to keep in sync for new versions)
<dvc> * Increases the available pool of software that can be packaged
<dvc>substantially (many modern languages such as Ruby and Go are
<dvc>realistically only functional with allowable bundling)
<dvc> * Did I mention the reduction in maintainer burden yet?
<dvc>civodul: I think that we could make exceptions for bundling in "modern" languages. That would include go, rust and js at least. I'm not familiar with ruby...
<kmicu>dvc: If you start making exceptions then why use Guix at all if Nix already exists with plenty of exceptions ( ͡~ ͜ʖ ͡°)
<dvc>kmicu: have you ever tried packaging a rust or js package? ;)
<dvc>many exceptions that nix makes are questionable I guess, but I'm talking about streamlining language support of interpreted/staticlly compiled languages that are very hard to unbundle. nix does something different and hacky for each language they support...
<dvc>we can automate the importer->tarball process...
<dvc>the features that moved me to start using guix where it's nice cli interface, beautiful support for cross compilation, nice qemu support and no need to support windows and macosx
<rekado>I think it’s going to take better arguments than the ones you quoted above to convince us that bundling is okay.
<dvc>well I can build cargo from source in a guix environment, that's enough for my private cargo use...
<OriansJ>and until someone else is willing to put in the effort to support more than that, it is sufficient.
<dvc>rustc might be nice to have in guix, but I can write a blogpost on how to use cargo in guix. my only worry with rustc is that building it without cargo might be non-optional soon and that rustc might be split into multiple crates in multiple repos (at some point in the future)...
<OriansJ>dvc: there is a big difference between nice to have and essential; essential must be there regardless of required effort, nice to have will only be in there if it can be done with a reasonable/acceptable amount of effort.
<OriansJ>Heck, there is about a dozen games; I think would be nice to have in guix but I don't expect them any time soon. Since 1, they are not my top priority and 2 no one else feels they need to be added yet. Maybe once my stage0 bootstrap project is done, I'll do it but until then I'm fine without them being in guix.
<quigonjinn>hello dvc. did you by any chance try the openocd package i sent you?
<dvc>quigonjinn: just saw it now, ended up in spam...
<dvc>quigonjinn: I'll build it now. A few things I noticed was: you implemented your own git submodule fetching? Is there a reason you didn't use (git-reference ... (recursive? #t))
<quigonjinn>dvc: because the submodules need to be initialised, after the configuration phase, if I remember correctly
<dvc>ok, I guess they should be separate packages anyway...
<quigonjinn>dvc: is there a need to, since they are only sources? just to make clear the individual licenses?
<adfeno>I think I found the cause of the bug that makes the "artanis" package to be installed incorrectly.
<quigonjinn>dvc: also, i think the apply-patch phase should be done in the source definition. I couldn't do so, because I had forgot to give a file-name to the checkout.
<dvc>also there's a comment missing for why the patch is needed and why it's built from git...
<Vibrant>Debian has failed in it's primary purpose: security and stability. See Andrew Ayer's Blog. If what Ayer says is true, then this is a very good time to talk to people about GUIX. Constantly. To everybody.
<quigonjinn>dvc: i'll add those before i post it in guix-devel. i was just in a hurry to get it to work. would you like me to mail you the reasoning?
<dvc>quigonjinn: nope - just saying :) builds and works. I'm still getting a OSBDM communication error: invalid swap command reply when trying to connect to my university supplied mc board :/ but I get that with the openocd from nixos too...
<quigonjinn>dvc: which mc are you trying with? does it have a debugger on board?
<adfeno>Vibrant: I'm not a security activist, but this seems to be an interesting read.
<dvc>I'm new to openocd. I played around with it with a sam3x development board I bought years ago but nothing serious. I'm just running it with -f interface/osbdm.cfg - I guess there is a board and a cpu cfg missing...
<quigonjinn>dvc: try adding "osbdm" in the list with the --enable flags in the package definition and rebuild
<dvc>it's already there I checked before building :)
<dvc>ah maybe there is a better aproach to packaging rust than I was taking: recursive importer only imports crates that contain a Cargo.lock file, if there isn't a Cargo.lock file fail. From the Cargo.lock file it can create all required package definitions.
<jmd>Anyway it seems that what works for match, doesn't always work for match-lambda
<adfeno>ACTION starts dancing around as he finds out that he fixed bug on Artanis package recipe.
<adfeno>ACTION stops once he finds out that there was already a proposal.
<marusich>From "(standards) Change Logs" it is clear there is some support for ChangeLog stuff in emcas, but I am not an expert in ChangeLog style or emacs itself, so I don't know how easy it would be to adapt it to use for editing Git commit messages.