IRC channel logs


back to list of logs

<freepotion>Hi! May I ask, which hardware is supported by GuixSD? And is there an easy way to enable the mainline kernel (Linux instead Linux-libre)?
<emacsomancer>rekado: so should `guix pull` reveal it? or is it not merged yet?
<emacsomancer>freepotion: it depends on how you define 'easy'. the mainline kernel is not officially supported. but you could define your config.scm to pull the mainline kernel.
<emacsomancer>quiliro: you could convert the html version to .epub or .mobi for use on an ereader
<emacsomancer>ng0: it seems like a pretty nice display for references to me (of course the ones with long abstracts muck up the formatting a bit)
<brettgilio> is throwing a gateway error.
***Copenhagen_Bram is now known as Guest1958
<brettgilio>Hi all. I am working on packaging the dotnet language components. Is lldb packaged anywhere on Guix? I am not seeing it.
<ng0>yes, still experimenting with options
***rekado_ is now known as rekado
<rekado>emacsomancer: core-updates hasn’t been merged yet.
<rekado>it looks like someone’s unhappy with flatpak:
<kmicu>Alas it’s in very negative/shaming style.
<efraim>"Red Hat's flatpack", wonder if they only hate flatpack
***Piece_Maker is now known as Acou_Bass
<wingo>i always forget what i need to do to avoid a 2.5GB download of texlive
<g_bor>hello guix!
<efraim>wingo: you can add it as a GC root or keep a local copy
<wingo>i think in this case i am building it for the first time on a machine, so there's no avoiding it
<civodul>wingo: is it because you're installing the "texlive" package directly?
<civodul>normally packages don't depend on the big "texlive" package anymore
<wingo>civodul: yes! maybe i needed something else
<wingo>this is for texi2dvi
<wingo>for a distcheck
<civodul>maybe "texlive-tiny" is enough
<wingo>i didn't know about that one, thanks!
<civodul>yw :-)
<g_bor>civodul: I've just pinged the Outreachy applicants on the mailing list for a status report.
<g_bor>is staging open?
<efraim>i guess? I think unofficially we're looking at merging core-updates then gnome-upgrades
<civodul>g_bor: great, thank you!
<civodul>efraim: that's my understanding too, but it looks like we're all hoping someone else will take care of it ;-)
<civodul>rekado: the latest version of Pierre's tutorial LGTM, FWIW
<civodul> \o/
<rekado>civodul: I haven’t read through the latest version yet, but aside from my last comments I thought the previous version was fine, too.
<rekado>civodul: I think it’s okay to publish it.
<rekado>kmicu: yeah, the style is not helpful, which makes the argument suspect in my opinion.
<HarvettFox96>Well, you know what? I can't take it anymore because being bloated and waste of bandwidth.
<kmicu>Not everyone can respectfully accept trade-offs 🤷
<ng0>what bloated?
<g_bor>hello guix!
<g_bor>so, now I think staging is open, is that correct?
<g_bor>Also, is it ok to do java bootstrap related work there?
<g_bor>I am under the impression, that our java package base is growing fast, so should we work on a feature branch instead?
<g_bor>also what is the status of jdk11? I haven't been following these things lately...
<roptat>g_bor: I have jdk10 (and 9), I'll send them later today
<roptat>of course they aren't reproducible
<g_bor>roptat: that's why I asked about staging...
<g_bor>is this still the javadoc problem, or do we have other differences?
<roptat>I can't build jdk9 or 10 on top of staging because of a bug in our gcc package, but it builds fine on core-updates
<roptat>I think it's only a javadoc issue
<g_bor>ok, I see.
<roptat>I'll try to build openjdk11 too
<g_bor>i got the info, that we will merge core-updates soon, and I think we will rebase staging, but I'm not sure about the processes regarding this yet.
<g_bor>Can someone confirm?
<g_bor>also, we should unpatch our builds that are patched because of the gcc bug. Is this done on core-updates, or do we target that for core-updates-ext?
<roptat>it should be for core-updates since it fixes the issue I think
<g_bor>roptat: It's just I don't want to push something tiggering a lot of rebuilds just before the merge.
<roptat>I see
<rekado>g_bor: you can push to core-updates-next for things that would normally go to core-updates.
<rekado>core-updates should only get merges from master or minor fixes at this point.
<civodul>rekado: awesome, i can push the blog post
<g_bor>rekado: thank for the clarification, that's just what I thought.
<g_bor>Actually these unpatchings are not critical, but should be done.
<rekado>civodul: I’m looking at (guix channels) and I see that the Guix channel is determined by name and its build rules by the existence of a file build-aux/build-self.scm..
<rekado>a channel containing a file of this name would be treated differently.
<rekado>I wonder if this could be a problem.
<rekado>similarly, I wonder if this mechanism could already be used to support channels with slightly more complicated setup needs.
<rekado>I think that we probably should not make this mechanism available to channels other than the Guix channel.
<civodul>rekado: i agree with this last sentence
<civodul>so yeah, instead of (file-exists? %self-build-file), we should probably use (eq? 'guix name)
<civodul>well, (string=? "guix" name) i guess
<civodul>for more complicated setup needs, i'd rather go for a purely declarative meta-data file in the channel
<civodul>though i think we should probably ignore "complicated setup needs" for now :-)
<rekado>yes, I’d prefer that
<rekado>I wouldn’t want to allow Guix to run arbitrary code on “guix pull”
<rekado>civodul: I also need your opinion on channel dependencies. I’d prefer for channel developers to specify channel dependencies rather than having users specify dependencies manually.
<rekado>this means that dependencies are derived from a well-known file that is part of the repository.
<rekado>you mentioned “.guix-channel.scm” in a comment.
<rekado>I’d like to assume that when this file exists and optionally specifies dependent channels, that these channels will also be instantiated.
<rekado>that would be “a purely declarative meta-data file in the channel”.
<civodul>yes, we could do that
<civodul>(so we'd drop the ".scm" suffix)
<g_bor>rekado: how could we ensure that we don't get to a situation similar to java,so we don't depend on a lot of versions of the same channel?
<civodul>so that file would contain a simple sexp, like (channel (version 0) (dependencies (channel ...) (channel ...)))
<rekado>civodul: exactly.
<civodul>and the (channel ...) sexps would essentially mirror the <channel> record
<civodul>we're in sync :-)
<rekado>civodul: now I just wonder if we should make room in that file to replace the hard-coded “dependencies” value in channel-instance-derivations for the core-instance.
<rekado>we could ignore this problem as the core-instance is special anyway.
<rekado>this means that all third-party channels may not use Guile modules that are not provided by themselves or by Guix.
<rekado>I think that’s reasonable.
<rekado>g_bor: it’s possible that two channels depend on different branches or commits of another channel, but that should be avoided.
<rekado>g_bor: I strongly advise against making channels depend on one another, especially when they are not provided by the same organisation.
<rekado>g_bor: dependent channels are most useful when they merely augment another channel (and so users would only add that augmented channel to their channels.scm, not both).
<g_bor>rekado: yes, that's also what I think about this, however we should make this very explicit, as we see the result of this in virtually all language specific package managers.
<civodul>rekado: that hard-coded list of dependencies (guile-gcrypt & co) should be fixed in a different way, probably by spawning an inferior and letting it do the job or provide info
<rekado>g_bor: this is a social problem, which I think we’ve been successfully avoiding, even with GUIX_PACKAGE_PATH.
<rekado>g_bor: this should never lead to deeply chained channels across organisations. Therein lies confusion and pain.
<g_bor>rekado: ok, thanks for the clarification.
<pkill9>like npm
<g_bor>pkill9: yes, actually that's what I meant.
<roptat>I finally found a suitable list of configure flags for openjdk11, building now :)
<civodul> o_O
<wingo>wtf nixlisp :)
<davexunit>typo in guix packaging tutorial: the quasiquote example says "colon" where it should say "comma"
<roptat>openjdk11 built, but there's a change in the way it should be installed that broke the installation phase
<civodul>davexunit: fixed, thanks!
<janneke>kudos on the packaging tutorial!
*lfam 🤦 ghostscript
<nckx>'A hand shown pressing against the head of a person, commonly written as facepalm. Used to display frustration or embarrassment at the ineptitude of a person or situation.'
<nckx>Oh. What now?
<lfam>I'm not embarassed by anyone else's ineptitude :) I am frustrated at the difficulty of finding the right patch series to fix CVE-2018-17961. Tavis Ormandy helpfully identified the two commits that fix the bug but, of course, figuring out how to apply them is up to me
<lfam>It's really frustrating that postscript support is so widespread and yet so dangerous, when approximately nobody is using it directly
<lfam>And also that the upstream is completely uninterested in helping redistributors of their code
*nckx just copied a description from a Web search since the Noto version of that moji is useless.
<nckx>Although 'frustrated' at that last point seems appropes. :-/
<lfam>I really wanted a picture of me banging my head against a wall ;)
<lfam>Like, to apply one of the patches, a prerequisite patch changes a buffer size variable from unsigned to signed. Is this safe to cherry-pick this patch too? Who knows?
<lfam>And in practice, is anyone actually intending to download postscript files and use them somehow?
<lfam>It seems like a big misfeature in 2018
<lfam>I gave up and asked oss-sec for help
*vagrantc was hoping to rewrite guix in postscript when some free time is available
<bavier>how to scp or sftp to a guixsd system? I get connection errors like "scp: command not found" or "/usr/libexec/sftp-server: no such file or directory"
<lfam>bavier: Probably you'll need to specify the remote path of the executable
<lfam>Not sure how to achieve that here :/
<bavier>sftp doesn't seem to have such an option afaict...
<lfam>bavier: I think you can add a line like this to sshd_config: 'Subsystem sftp /usr/lib/openssh/sftp-server'
<lfam>But with the correct path
<lfam>Really this should work out of the box on GuixSD
<efraim>I can't run 'ssh machine -t screen -RD', I have screen in my profile but it isn't found
<lfam>Our service creates an sshd_config that tells it to run `internal-sftp` for the sftp subsystem. Our package doesn't provide that executable. I wonder if it is some magic name?
<bavier>I guess I'll just do this some other way
<rekado>bavier: I always installed scp/openssh into the global profile.
<rekado>bavier: that is on the target machine. That way it usually just works.
<bavier>rekado: oh, ok, I'll try that some time
<lfam>It seems like the 'internal-sftp' thing should just work when deployed on the remote
<bavier>anyone else see "wrong type argument in position 1 (expecting port that supports 'setvbuf': #<output: r6rs-custom-binary-output-port 30093340>" running 'make check'?
<bavier>I think the latest (guix status) stuff effectively makes guile 2.2.0 a requirement
<bavier>i.e. >= 2.2.0
<civodul>bavier: i suppose we could comment out that setvbuf call on Guile 2.0, if we wanted
<bavier>civodul: iirc that's done elsewhere for 2.0
<bavier>have to find it...
<civodul>bavier: re scp, one way to "fix" the issue is to have openssh installed in the system profile
<bavier>civodul: do you know off-hand if the cond-expand else-case in (guix status) was meant for guile@2.0 specifically?
<civodul>bavier: yes, it was for 2.0, but as you found out it's pointless: we should put the whole setvbuf call into 'cond-expand'
<civodul>then you should run "make check TESTS=tests/status.scm" to make sure it's okay
<civodul>(i think it is)
<bavier>civodul: yes, that fixes that bit; one other failure in "current-build-output-port, UTF-8 + garbage"
<bavier>expected-value: ((build-log "garbage: \ufffdlambda: \u03bb\n"))
<bavier>actual-value: ((build-log "garbage: ?lambda: \u03bb\n"))
<civodul>bavier: oh right, that because Guile 2.0 would use question mark instead of REPLACEMENT CHARACTER here
<civodul>the fix is to cond-expand the expected value as well
<civodul>note that there's no 'guile-2.0' cond-expand feature
<civodul>so to be accurate, you need (and guile-2 (not guile-2.2))
<civodul>(i think i made the mistake in a couple of places...)