IRC channel logs


back to list of logs

<NiAsterisk>I do understand this Nix file right, that I only need to substitute paths in the Makefile. is it enough to use python-setuptools and try the rewriting in the #arguments section?
<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
<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
<NiAsterisk>currently I don't have nixos here.
<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
<davexunit>you heard correctly
<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
<davexunit>and the pybitmessage executable into /bin
<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
<lfam>Here is the filesystem tree produced by the nix package:
<davexunit>NiAsterisk: look for things like 'install-file'
<davexunit>'substitute*' for patching files
<davexunit>(tons of those around)
<davexunit>'mkdir-p' even
<lfam>Oh, that tree doesn't include hidden files
<NiAsterisk>i think i can work with that
<NiAsterisk>which timezone is the gnunet bot in? would be easier for me to look back at the logs there instead of saving this.
<NiAsterisk>okay i see it's already on there
<davexunit>use this link
<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/
<lfam>Among other things
<NiAsterisk>yes, that's the main executable
<lfam>I wonder if they would accept help getting set up with
<NiAsterisk>not really..
<NiAsterisk>i mean yes
<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?
<NiAsterisk>right now it's on 0.5.5
<lfam>What is mailchuck?
<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>so far they don't collide, can use th same db
<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>afaik they should have access now
<NiAsterisk>the one behind mailchuck runs 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
<NiAsterisk>or used to run?
<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
<NiAsterisk>part of what EDN wants to achieve.
***zch_ is now known as zch
<NiAsterisk>https: // , 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 or 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.
<NiAsterisk>good night
<zch>How active is the development for dmd <>? I'm curious because the git repo is not up <>
<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
<zch>Ahh okay
<davexunit>so the GuixSD manual from the last release still refers to dmd
<calher>I'm hanging at
<calher># ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild
<calher>So when I do
<calher># guix archive --authorize < ~root/.guix-profile/share/guix/
<calher>It gives an error --
<davexunit>calher: it's not hanging. it's a daemon.
<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/
<calher>warning: failed to install locale: Invalid argument
<davexunit>that warning is harmless
<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>calher: okay.
<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"
<civodul>Hello Guix!
<gchriss>I'm having trouble with the live usb installer: running 'guix system init' hangs on attempting to download nss from
<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?
<efraim>if you have the corrected url you can feed it to guix manually with `guix download http://new.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
<civodul>how's that possible?
<efraim>there's a revert in the middle
<efraim>can I pass --fallback to guix-daemon?
<civodul>oh right, i thought the revert happened after
<civodul>efraim: no
<jubalh>hello folks
<rekado_>ACTION just moved to a new office and noticed that the ports for IRC, XMPP and git are blocked here...
<jubalh>all the good things :-)
<foobarry>rekado_: read your post on guix and hpc
<foobarry>noticed any issues?
<foobarry>we currently provide a diverse range of research apps on hpc via module command
<foobarry>bio guys asking for guix
<efraim>rekado_: can you pass it through through tor?
<rekado_>foobarry: no serious issues.
<rekado_>we have problems with the performance of NFS, but I suspect this is a network configuration problem
<rekado_>building profiles is really slow
<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.
<rekado_>foobarry: for example?
<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 don't have to update.
<rekado_>you can keep known good versions, both of build artifacts and of package expressions (e.g. by using git branches)
<foobarry>is that managed by the user?
<foobarry>e.g. the bio tools, do they download specific versions
<foobarry>of they usually try to pull the latest
<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.
<rekado_>I have had no issues with support.
<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_>I only support as much as I want.
<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>our main cluster is GPFS
<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>what are the arguments for/against?
<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.
<foobarry>are you a sole support guy for the hpc?
<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.
<rekado_>and that just by accident.
<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.
<foobarry>i bet
<foobarry>"bypass the admins"
<foobarry>get software now
<rekado_>I think that's okay.
<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 at a uni?
<rekado_>it's a research facility.
<rekado_>public service.
<foobarry>USA? Europe?
<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)
<foobarry>which queue scheduler are you using?
<foobarry>we are on grid engine
<rekado_>we used to use Sun GridEngine, but I'm not sure which variant is currently in use. (Univa?)
<foobarry>we are about to move to 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
<rekado_>(always ".drv-0", always "/tmp")
<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.
<mark_weaver>sorry for the mess :-(
<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.
<rekado_>I see
<rekado_>hmm, rms speaks on the 29th in Brussels until 9pm (according to, but the GNU hackers' dinner is at 8:15pm
<civodul>mark_weaver: i see, got it; maybe a git graft would have worked?
<civodul>rekado_: re .drv-0, see "Build Environment Setup"
<civodul>lots of fun:
<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
<civodul>and cannot get changes in
<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>this is crazy
<civodul>the reactions there are all about discussing features and such
<bavier>some mention of gitlab too
<davexunit>gitlab is unfortunately not much better.
<Xe>I prefer gogs
<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.
<rekado_>it's beautiful.
<rekado_>no need for yet another account.
<davexunit>rekado_: that's what I do.
<davexunit>we use the same theme
<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.)
<davexunit>I have the same fear.
<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.
<rekado_>(or just regular potatoes)
<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>friends are starting a commune in 5 years, t
<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
<davexunit>yeah, I'm not a fan either.
<rekado_>free software is quite exceptional in that it took off without a "business case"
<davexunit>yeah, it's really remarkable.
<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.
<NiAsterisk>it's difficult
<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.
<civodul>speaking of free software & education:
<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'?
<davexunit>zch: yup!
<zch>love it
<civodul>davexunit: interesting bug with user name spaces:
<pizzaiolo>civodul: saluton! nice to see another esperanto-speaking GNU lover :)
<pizzaiolo>was dmd renamed to shepherd?
<taylan>pizzaiolo: yes
<civodul>saluton pizzaiolo ;-)
<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>but... but!
<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>that stores state
<paron_remote>I guess at that point I'm just not using the "system profile"
<paron_remote>but otherwise, it's theoretically the same guix right?
<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>here are the 5 points:
<davexunit>1) ease of installation
<davexunit>2) integration (i.e. can I use the system package manager to install this?)
<davexunit>3) user autonomy and control
<davexunit>4) security
<davexunit>5) reproducibility
<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?
<davexunit>I'm writing a critique of github.
<pizzaiolo>NiAsterisk: yes, considerably
<NiAsterisk>refering to what
<NiAsterisk>davexunit: iirc wubthecaptain had a post on github
<NiAsterisk>one sec
<NiAsterisk>yes. easy to spot directly on
<NiAsterisk>maybe it helps with what you are writing
<NiAsterisk>ah, okay I got it pizzaiolo . thanks
<davexunit>NiAsterisk: thanks.
<NiAsterisk>it's rather shocking and made me use github only for filing bugreports etc
<davexunit>NiAsterisk: thanks this article is perfect
<mark_weaver>davexunit: here's a discussion we had on #guile a while ago about github:
<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 this year, hope it'll be worth to report about.
<davexunit>mark_weaver: thanks
<davexunit>does anyone want to get mad? in response to the critical "dear github" open letter:
<NiAsterisk>thank you github, but thanks no?
<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
<tsyesika>dmesg's of both systems are on: and lsmod of both are:
<davexunit>this is an interesting read:
<NiAsterisk>opened an issue on the thank-you-github repo, was closed faster than anything I've ever opened o_O
<davexunit>NiAsterisk: lol can you send?
<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
<Gamayun>NiAsterisk: Gee!
<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
<pizzaiolo>oh, this looks neat
<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
<NiAsterisk>it's as pointless as their repo. yes
<pizzaiolo>mmn wrote a nice piece on github today
<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>it only exists for the mouse.
<rekado>does the mouse/touchpad work?
<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?
<rekado>tsyesika: the info is here:
<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
<davexunit>but no full video most likely.
<lfam>Hm, screencast + voice is better than nothing.
<lfam>Remind me the date of your presentation?
<lfam>paron_remote: Very nice :)
<lfam>Of course it works!
<davexunit>lfam: wednesday the 20th
<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
<davexunit>yeah write that blog post first
<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 ;)
<davexunit>I will try my best to record the talk
<lfam>I have family and friends there, I like to go often.
<davexunit>it will be very amateur
<davexunit>but first I must write my talk!
<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: hey sorry
<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>I hope we can get this fixed.
<tsyesika>me too
<rekado>tsyesika: when booting GuixSD could you try editing the kernel boot line in GRUB, adding this parameter: "modprobe.blacklist=usbkbd"
<tsyesika> i can yep
<rekado>if I'm right and everything is as simple as I'm hoping this should fix it.
<tsyesika>i'll try that
<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.
<rekado>lfam: what kind of issues?
<lfam>I'll try offering that parameter to the kernel
<lfam>Keyboard didn't work at all
<lfam>It used to work
<tsyesika>rekado: didn't make any difference, the keyboard still doesn't work
<rekado>that's too bad
<rekado>I'm sorry
<rekado>thanks for trying!
<tsyesika>no problem, thanks for trying to help
<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
<rekado>this might be useful.
<tsyesika>give me 5
<tsyesika>the HIDBP line is still in there
<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>I guess that's ... good.
<rekado>is there also a line containing "usbkbd"?
<tsyesika>hm lemmi look
<tsyesika>i'll paste the whole thing too hold on
<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>I see.
<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).
<tsyesika>ACTION nods
<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'?
<rekado>I saw "modprobe.blacklist=modname1,modname2,modname3" mentioned here
***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)