<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) ***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. <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 <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>i didn't know about that one, thanks! <g_bor>civodul: I've just pinged the Outreachy applicants on the mailing list for a status report. <efraim>i guess? I think unofficially we're looking at merging core-updates then gnome-upgrades <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 <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 🤷 <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>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>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. <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>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”. <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 ...))) <civodul>and the (channel ...) sexps would essentially mirror the <channel> record <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>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. <g_bor>pkill9: yes, actually that's what I meant. <roptat>I finally found a suitable list of configure flags for openjdk11, building now :) <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 <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.' <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 <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 <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 <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...)