<NiAsterisk>or is #arguments only for build instructions? where in this case, I find in python.scm : python-pytest there's a (snippet) which looks like it could/would do such a replacement. <lfam>NiAsterisk: I think the python-pytest example is usually called an origin snippet because it is some Scheme procedure applied to the source "origin" of the file. So, if you did `guix build -S python-pybitmessage`, the resulting tarball would incorporate the effect of the origin snippet. If you performed the substitution in #:arguments, then it would be applied during the build process. I don't know which is more appropriate here. <davexunit>lfam: origin snippets should only be used for things that aren't Guix-specific changes to make them build in a container <lfam>I don't think you'd be able to refer to the build inputs (like the python interpreter) in the origin snippet <lfam>davexunit: Right, I think the only times I've used them were to work around upstream bugs that hadn't been fixed yet <davexunit>it sounds like what NiAsterisk wants is to patch the makefile dynamically. <davexunit>via adding a new build phase before the 'build' phase <lfam>It it correct that you can't refer to build inputs in the origin? <lfam>The origin scope, that is <davexunit>lfam: correct, because an origin is not a package. <davexunit>it has no knowledge of the package that uses it as source <NiAsterisk>right. yes, it seems like this is what i want to do <NiAsterisk>because when I tried, the upstream bug is that is has no setup.py <NiAsterisk>or it has one, but it is not setuptools compatible or something <lfam>Yeah, I looked into bitmessage recently and found that. I think you are supposed to run bitmessage directly out of the unpacked source code <NiAsterisk>this, or packaged versions of your systems distro <lfam>Not knowing much about Python I decided not to try packaging it <NiAsterisk>I would prefer to have at least the upstream (not mailchuck) packaged and in the system <NiAsterisk>mailchuck (dev preview) i can handle myself if I would want to <lfam>NiAsterisk: Do you have access to a nix system where you can see what their resulting package looks like? If not, I can take a look <davexunit>you can experiment directly with building/running pybitmessage without guix/nix to learn about what needs to be done to package it. <NiAsterisk>my guess is, at some point I need to fix the shebangs (heard python-build-system does this), but also fix paths in the makefile <davexunit>the build systems automatically patch shebangs <NiAsterisk>best I'll continue tomorrow with it on my debian. <lfam>yes, davexunit, but I remember looking at the bitmessage source tree and thinking it looked very weird. I wasn't sure at all how it would translate into a package. <NiAsterisk>gentoo just copied stuff to folders in the system <davexunit>I would guess that python modules need to be moved into PYTHONPATH <NiAsterisk>and that they continue to provide build bashscripts for distros is weird <NiAsterisk>so it sounds like some kind of manual, copy-move install instructions to pass if not in the makefile (i don't have it open anymore). is there an example i can look at tomorrow? else I'll just go through the sources until i find one <davexunit>NiAsterisk: look for things like 'install-file' <lfam>Oh, that tree doesn't include hidden files <NiAsterisk>which timezone is the gnunet bot in? would be easier for me to look back at the logs there instead of saving this. <lfam>Anyways, the bin/pybitmessage is a wrapper to a hidden file that is probably autogenerated by the nix python build system. The hidden file cd's to the 'share' directory and executes share/pybitmessage/bitmessagemain.py <lfam>I wonder if they would accept help getting set up with setup.py <NiAsterisk>but it's on roadmap v.0.8 for mailchuck working repository <lfam>I'm not saying we should do it. It's more... why haven't they done it yet? <lfam>I hope we never let our user-facing tools get as bad as nix's. They are really inscrutable <NiAsterisk>it's run by one developer who is or is not (bitmessage forums said he's now part of the main dev team) working hard on contributing and fixing things, as merges to Bitmessage/PyBitmessage took very long <NiAsterisk>so there is Bitmessage/PyBitmessage and mailchuck/PyBitmessage <NiAsterisk>but stable one is still 0.4.4 while mailchuck is at 0.5.5 or something, and no merges happened, at least last time i compared <lfam>So it's a fork caused by lack of access to the main repo? <NiAsterisk>the one behind mailchuck runs mailchuck.net or something. which imo is a weird, unnecessary service and introduces all kinds of email related stuff into bitmessage ecosystem, but for those who need it it can be good i guess <lfam>I looked into a bunch of the privacy oriented messaging systems recently. They all seemed half-baked unfortunately. For example, the lack of a build system for bitmessage <NiAsterisk>there's a larger group focused on fixing and merging efforts ***zch_ is now known as zch
<NiAsterisk>https: // wiki.c3d2.de/EDN , I could explain more but I guess this is were it would get too offtopic for a guix related channel. I'm (slowly) in the progress of translating and writing subtitles for one of the videos back in november about EDN, but afaik there should be videos on gnunet.org or youbroketheinternet.org about it, more recent videos. they had sessions at 32c3 i couldn't attend <lfam>Cool, thanks for the link <NiAsterisk>i should go to bed. interesting group and goal, from my perspective the most rational approach at it. <zch>'No repositories found' <davexunit>zch: dmd has been renamed to Shepherd due to a name collision with another project <zch>Ahh, well there was reference to dmd in some GuixSD manual I believe <davexunit>zch: it was just renamed and moved a few days ago <davexunit>so the GuixSD manual from the last release still refers to dmd <calher># ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild <calher># guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <calher>ok, then why didn't they put a & after it like I suspected I should have done? <davexunit>calher: because people handle daemons in different ways? it would be awfully noisy to leave that daemon backgrounded in the same terminal that you are doing other things in. <calher># guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <calher>warning: failed to install locale: Invalid argument <davexunit>the manual should have some information on installing and configuring locale information to prevent that warning. <calher>davexunit: It's called "background it and close the tmux window." <davexunit>the documentation could include a note along the lines of "Since the above spawns a daemon, you should use a different terminal session to perform the rest of the tasks, or consider integrating with your distribution's init system" <gchriss>I'm having trouble with the live usb installer: running 'guix system init' hangs on attempting to download nss from ftp://ftp.mozilla.org <gchriss>which has been discontinued in favor of http(s) access only. how can I update the live usb key? or otherwise edit the download url? <gchriss>am I actually running a guix instance? or still in "installer" mode? <gchriss>and should I do this before the 'guix system init' command? <efraim>the usb image is an actual guixsd instance <efraim>if it needs to download the file i'd do that first <efraim>yay ambiguous language. I'd do the download first <gchriss>ok, will try and report back. thanks <civodul>mark_weaver: what happened with the OpenSSH update? <civodul>on guix-commits i see two successive 7.1p1 -> 7.1p2 upgrades <efraim>can I pass --fallback to guix-daemon? <civodul>oh right, i thought the revert happened after <rekado_>ACTION just moved to a new office and noticed that the ports for IRC, XMPP and git are blocked here... <foobarry>we currently provide a diverse range of research apps on hpc via module command <efraim>rekado_: can you pass it through through tor? <rekado_>we have problems with the performance of NFS, but I suspect this is a network configuration problem <rekado_>in the background there are a lot of lstat calls and with poorly performing NFS that's really unpleasant. <foobarry> i found your arguments in favour of using it to be some of the arugments against <rekado_>but we have been having network problems for a while now, so that's unrelated to Guix. <foobarry>if they base their bio tools off the guix packages, the guix packages are getting updated a lot <foobarry>so you lose the reliable nature of building off known good versions <foobarry>and surely new builds get broken by dependency changes? e.g. gcc version bump <rekado_>you can keep known good versions, both of build artifacts and of package expressions (e.g. by using git branches) <foobarry>e.g. the bio tools, do they download specific versions <rekado_>the package expressions specify what exact source tarball to download. <rekado_>the expressions are part of the Guix code. <foobarry>i guess i'm trying to establish whether i am just handing over my app builds to the community when my app builds are known to be reliable <foobarry>have you seen any build issues with the bio tools? <rekado_>users can keep their local Guix clone and not update it, or cherry-pick new commits as they wish. <foobarry>i'm also wary that if we lose control of what versions people are using it will be hard to support <foobarry>although i guess we can checkout the version ourselves and test <rekado_>it just means that at some point they will lose the ability to use substitutes from hydra as we don't keep them around indefinitely. <foobarry>how many users on your hpc are using it? <rekado_>some people want to use a somewhat dated version of bedtools, for example, or a particular version of samtools. <rekado_>we have many groups using the two clusters, but not all of them use Guix yet. <rekado_>at the moment it's maybe 100 people or so. <rekado_>the others have to use whatever was installed on the cluster when it was set up. <foobarry>ok. thanks for chatting. i might try it out on our test cluster <rekado_>or they try building stuff themselves. <foobarry>but we are having performance issues there even <rekado_>on our clusters we use GPFS only for scratch space. <rekado_>the /gnu and the profiles directory are mounted over NFS. <rekado_>I'm currently experimenting with enabling users to manage their own software profiles and letting them use more of guix by exporting the profiles directory as read-writeable. <rekado_>that's something I haven't mentioned in my blog post then. <foobarry>thats probably the mode i envisaged that you were running already <foobarry>so they can get new versions of tools at will <rekado_>pro is that users gain more flexibility; less work for me; I no longer need to respond to requests for software that has already been packaged. <rekado_>right now they can only do this from one central machine. <rekado_>and for convenience the sysadmins only gave me access to that server. <rekado_>no, we have dedicated hpc support; I'm just doing the software part. <foobarry>ok. we have a team but a dedicated post for building and also tuning hpc apps <rekado_>originally I was just supposed to support our small group, but word of the advantages of Guix quickly spread and now more people request to use it. <rekado_>users could always build software on their own <foobarry>i just wondered how it worked in reality and if it made admins cry <rekado_>here the hpc admins are happy they're off the hook. <rekado_>and users are happy that they get what they want <rekado_>and I'm happy because I get to work on free software. <foobarry>are you native english speaker? you sound like it <rekado_>thanks; no, I'm not a native English speaker. <rekado_>(I was born in Germany, but I haven't spoken German on a regular basis for more than ten years) <rekado_>we used to use Sun GridEngine, but I'm not sure which variant is currently in use. (Univa?) <mark_weaver>civodul: the reason for the messy openssh commits is that I messed up the commit log in the first one. <rekado_>I'm running the daemon with TMPDIR=$HOME/tmp, but the build process will output /tmp all the time. The files are in fact located at $HOME/tmp. <rekado_>only at the very end I see this: note: keeping build directory `/home/rwurmus/tmp/guix-build-sssd-1.13.3.drv-1' <mark_weaver>I copied a bad CVE number that has been propagated to a few places, including the post I was looking at. <rekado_>during the build the directory is called /tmp/guix-build-sssd-1.13.3.drv-0 <mark_weaver>and also, it became unclear to me whether the new openssh release actually fixed the problems or only made them irrelevant by disabling the functionality that contained the bugs. <rekado_>is this because of the "fix" to keep the build from retaining references to the build directory? <mark_weaver>rekado_: iirc, regardless of where the directory exists in the main system, within the build container's namespace it is located at /tmp, to avoid leaking unnecessary system-specific details into the build logs. <civodul>mark_weaver: i see, got it; maybe a git graft would have worked? <civodul>rekado_: re .drv-0, see "Build Environment Setup" <civodul>people use proprietary software hosted by a for-profit company <civodul>and all of a sudden they realize that they don't know what's going on <davexunit>civodul: that was my reaction to skimming that article <davexunit>wow, a for-profit company isn't listening to you? what a shocker. <davexunit>GitHub is one of those companies that you just can't criticize without people jumping on you about how great they are. <civodul>the reactions there are all about discussing features and such <Xe>it's at least not partially closed source <davexunit>I don't know if anyone knows how to build gitlab from source <davexunit>because everyone just uses the "OmniBus package" <davexunit>which is a giant bundle containing every dependency needed. <davexunit>the people that say gitlab is easy to self-host aren't aware of the issues with the omnibus approach. <davexunit>on the subject of self-hosting, has anyone ever put together a criteria for what makes a good, self-hostable web application? <petter>i was just about to suggest we help get the discussion where it should be, but i see civodul just did that :) <rekado_>I really like gitweb; it's so simple. <rekado_>and people can send patches via email. <davexunit>I just wish I could have better syntax highlighting <rekado_>(I'm afraid I'll soon be completely out of touch with the way most other people use computers; maybe I already am.) <rekado_>yeah, syntax highlighting is also something I'd like to see improved. <davexunit>in fact, I'm worried that in some number of years, I won't even be able to successfully use tools like Emacs in the industry. <NiAsterisk>i tried to setup kallithea-scm for git, but found out it has many dependencies. <rekado_>davexunit: when that time comes I'll take my coat, turn off the lights, lock the door and farm potatatoes. <davexunit>rekado_: yeah, I think I need to plan for something similar. <davexunit>in my ideal world, Guix will take off and I'll join or create a free software development coop based around it. <NiAsterisk>hat's what I can have as a backup plan if all else fails. <davexunit>I see a few ways that a business can be built around guix, without comprimising free software principles. <davexunit>from basic consultancy to providing continuous integration services. <NiAsterisk>one way could involve educational purposes, integration with schools/classes/interested companies <rekado_>I'm annoyed at how often we feel the need to phrase things in business terms <rekado_>free software is quite exceptional in that it took off without a "business case" <rekado_>I often wonder if this could be applied to things beyond software. <davexunit>software and other things digital have the advantage of being copied for essentially 0 cost. <rekado_>education, too. Similar costs apply ("practitioners" have their expenses), yet we don't really see anything like the free software model applied to education. <df_>artistic movements (sometimes) don't have a business case <civodul>rekado_: in France there's the "université populaire", which unfortunately is often a bit elitist <rekado_>(partial contradiction of my statement above: we do have libraries offering free access to books) <rekado_>civodul: thanks for the pointer! I didn't know about this one. <NiAsterisk>teachers are often locked into closed source software, the few which use free software probably got interested before studying and the ones who want to use free software later on get problem with exchanging documents in their workflow if other schools they communicate with are using incompatible software. I went through this with one school and their head staff <rekado_>(got to tell my like-minded mates about it; maybe some ideas can be copied) <NiAsterisk>plus depending on school and country, the privileges and integration of administration and computers are bad <NiAsterisk>one district close to me, and possibly all others, have seen this in another federal state too, have external contractors managing all the IT infrastructur, giving teachers about 0 privileges. <NiAsterisk>talking about free software usually involves talking about how things work first, i had to explain the internet to them (technically) when we tried to move their website or do changes to it. <NiAsterisk>it's a businessmodel based on this, and it works. but I think one could also make some sort of "business" in trying to deconstruct these businesses, and teach free software to pupils and students, the basics, hands on, which could involve guixsd or guix as an example unit. <NiAsterisk>there was a longer thread last month on the fsfe-de maillinglist, serving as an perfect example of lock-in in one federal state of germany.. it involved MS and other accounts + forcing parent(s) to buy laptops or tables with the latest windows. <NiAsterisk>but then again you have the move of more and more cities towards free software, and soem schools realizing and applying it too <NiAsterisk>but to make more young people curious, before they start studying, that would be better <zch>how is guix pronounced? is it 'geeks'? <pizzaiolo>civodul: saluton! nice to see another esperanto-speaking GNU lover :) <NiAsterisk>are esperanto basics relatively easy to learn when you know (but have to refresh, so this would be after refreshing them) spanish and french? <paron_remote>who's willing ot help me think through a crazy idea and check for sanity? :) <paron_remote>so the other day I was talking about how I was dual booting guixsd and debian, right <paron_remote>but since I have separate /gnu/store/ on debian than on guixsd because I have a separate root <paron_remote>~/.guix-profile/ now no longer points to stuff that appropriately exists, which is clearly a problem <paron_remote>what if on debian I bind-mounted the guix root's partition's /gnu/ to /gnu/ on debian <paron_remote>and also bind-mounted the /var/foo (I forget what) directory <paron_remote>I guess at that point I'm just not using the "system profile" <davexunit>paron_remote: using the same store and the same localstatedir sounds like it will be just fine <davexunit>so, I just came up with a criteria consisting of 5 points to differentiate good software installation mechanisms from bad ones. <davexunit>I'd like to use it in my talk next week and I would like some feedback from whoever would like to offer it. (I could maybe make a mailing list thread later) <davexunit>2) integration (i.e. can I use the system package manager to install this?) <davexunit>perhaps 3 is better expressed by 4 and 5 and can be dropped. <davexunit>because having reproducibility gives the user control. <davexunit>mark_weaver: do you remember some of the particularly terrible provisions in the GitHub ToS? <NiAsterisk>davexunit: iirc wubthecaptain had a post on github <NiAsterisk>it's rather shocking and made me use github only for filing bugreports etc <NiAsterisk>there are many bad service providers out there once you actually read the ToS & related terms. after some months of ping pong emails I'll get the EFF to do something about change.org this year, hope it'll be worth to report about. <tsyesika>ugh, github is not a force for good in free software >.< <davexunit>tsyesika: this is the mentality we fight against :/ <tsyesika>hey, I'm just wondering if anyone in here has any suggestions for fixing the bug I'm having with guix 0.9 install image on my macbook, the keyboard just doesn't function it does in trisquel and every other linux distro <NiAsterisk>opened an issue on the thank-you-github repo, was closed faster than anything I've ever opened o_O <NiAsterisk>if my health insurance would work that fast, I would be amazed <pizzaiolo>someone needs to fork and rename to fuck-you-github <NiAsterisk>that's below what I like in language, even for greedy companies <rekado>tsyesika: do you have the ability to check trisquel with a more recent kernel? The differences in the dmesg output are a bit too many to figure out what might be important. <NiAsterisk>and I can understand why people use hosted solutions, it's the facebook - email problem all over again <rekado>one thing that stands out about the [ cut here ] part in the dmesg output <rekado>tsyesika: have you tried to install GuixSD (using an external USB keyboard) and then boot the latest kernel? <NiAsterisk>but maybe i will go ahead, fork it and rename it next week <rekado>NiAsterisk, pizzaiolo: what's the point of forking and renaming it? <rekado>(am I too dispassionate about all of this?) <rekado>it seems like a really unnecessary and unproductive action <rekado>(I found myself shrugging a little too often) <NiAsterisk>git is perfect for hosting on hiddenservices on your own machine, that's one thing I like about git in generaland what I used to do. <rekado>tsyesika: one more difference is that 05ac:820a is mentioned in an "input:" line on both sides, but the "hid-generic" line talking about the keyboard is not mentioned in the Guix dmesg output. <rekado>tsyesika: the kernel docs say this about USB HIDBP: <rekado>"Say Y here only if you are absolutely sure that you don't want <rekado>to use the generic HID driver for your USB keyboard and prefer <rekado>to use the keyboard in its limited Boot Protocol mode instead. <lfam>davexunit: I saw your criteria of good software installation mechanisms in the log. I think it's an important issue. I'm pretty new to this but the last few months of packaging have convinced me that if users cannot figure out how to compile your "free" software from scratch, then it's not really free software. <rekado>This is almost certainly not what you want. This is mostly <rekado>useful for embedded applications or simple keyboards." <davexunit>lfam: that's exactly the point I'm trying to make <rekado>tsyesika: according to dmesg when booting GuixSD, the HIDBP driver is used for the keyboard. <rekado>tsyesika: this could be why it isn't working <lfam>There's more to it than just words in COPYING <davexunit>lfam: in my talk next week, I want to contrast Guix against other tools and show why Guix is the only one that satisfies all of the categories. <lfam>Did you make any progress on figuring out how to record the talk? <davexunit>for example, OmniBus packages may be easy to install and integrated with your system package manager, but they are not secure nor reproducible. <paron_remote>my guix + debian setup is now sharing the same /gnu/ and state stuff <rekado>tsyesika: so, I'd suggest we try to find out how to disable this driver. <paron_remote>so I can switch between guixsd and debian and use the same user profile just fine <davexunit>lfam: unfortunately, no. I think I could record a screencast + my voice <lfam>davexunit: Yeah, doing this has made me realize how much I depend on the ingenuity of some Debian developer somewhere. Just because they figured out how to build something that nobody else can <lfam>Hm, screencast + voice is better than nothing. <lfam>Remind me the date of your presentation? <lfam>paron_remote: Very nice :) <paron_remote>now I should properly blogpost how to do a nicely working guix + debian dual booting setup <lfam>paron_remote: Even better, how about a distillation of the blog post for the manual! <paron_remote>lfam: how about blogpost first, then I can worry about cleaning it up for the manual after :) <lfam>Heh, okay :) I'll be happy to help. I like getting things into the manual. I remember how useful the blogs and pjotr's git repo were for me, but OTOH, it's annoying to have the information scattered around the net <lfam>davexunit: You know, I currently do this sort of thing (AV presentations) for my day job. But I am rather far along the BAMA and I'm not sure if I could borrow the camera or not. <bavier>yay, finally got boost tests running; only had to skip 22/120 test suites <davexunit>lfam: I wish you were in the Boston area then ;) <lfam>I have family and friends there, I like to go often. <davexunit>gotta get the bulk of it done over the weekend <lfam>When explaining Guix to people I have been trying to draw a parallel between inscrutable build processes and reproducible science like rekado is working on. They are directly correlated and help lay-people understand what's at stake more clearly, since most people don't even realize there is a free software movement. <lfam>Most people see the problem of poor software practices making scientific experiments unreproducible <tsyesika>rekado: I'm unable to instll guix, the macbook only has 2 usb ports, one of which is used for the usb to boot guix and the other for the keyboard <tsyesika>rekado: I don't have a trisquel install so i'm unable to update the kernel on there, though i could always install one temporarily if it helps get guix installed <rekado>tsyesika: no problem. I'm replying to the bug report. <rekado>tsyesika: when booting GuixSD could you try editing the kernel boot line in GRUB, adding this parameter: "modprobe.blacklist=usbkbd" <rekado>if I'm right and everything is as simple as I'm hoping this should fix it. <rekado>(just sent out the email to the bug tracker to document why I guess that this might work) <lfam>I started having issues with an external USB keyboard in my tester GuixSD installation recently. But that machine is so old and unreliable that I didn't choose to report it. <lfam>I'll try offering that parameter to the kernel <lfam>Keyboard didn't work at all <tsyesika>rekado: didn't make any difference, the keyboard still doesn't work <rekado>I wonder if it has the effect we want it to have, i.e. whether it makes the HIDBP line disappear or not. <rekado>if the HIDBF line has disappeared then that probably wasn't the cause. <rekado>if the line is still there, then the kernel parameter hasn't had the effect I hoped for and we'd need to try harder to disable HIDBP. <tsyesika>want me to get a another dmesg with the kernel parameter <tsyesika>[ 2.607737] input: USB HIDBP Keyboard 05ac:820a as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1/1-3.1:1.0/input/input5 <rekado>is there also a line containing "usbkbd"? <tsyesika>rekado: yeah you can see it on the kernel command but then you can also see it registers a device with the module, despite it being blacklisted <rekado>well, does anyone else here know how to disable the usbkbd kernel module at boot time? <rekado>if we cannot do it at boot time, we might have to change the kernel config to explicitly disable HIDBP (which seems to be only used for embedded devices anyway). <rekado>a possible hack would be to modify the USB image such that usbkbd.ko is renamed to something else, so that it cannot be loaded automatically. <lfam>There may be an answer in a channel like ##kernel <lfam>Or ##linux. There are some jokers there but also some helpful people. <lfam>Much thanks to mark_weaver. Debian testing still doesn't have a patched OpenSSH but it doesn't matter since I can build it with Guix :) <rekado>could this failure to blacklist be because the module is part of the initramfs? <civodul>what is supposed to honor 'modprobe.blacklist'? ***aeva` is now known as aeva
<civodul>oh it's honored by kmod, as noted in modprobe(8) <civodul>and we use kmod, so normally we're fine <civodul>rekado, tsyesika: problem is, we explicitly load usbkbd in the initrd, see (gnu packages linux-initrd) 