IRC channel logs


back to list of logs

<jonsger[m]>apteryx assuming you are Maxime, do you know how to get stuff like building again, after your recent QT build system changes?
<podiki[m]>jonsger: they are not, unless you delete the 'e'
<podiki[m]>(maxim and maxime are two different people, as far as I know)
<Kabouik_>Say I want to temporarily enable password-authentication in my ssh config (I need it to then do a ssh-copy-id to copy a new ssh pair and then disable password-authentication again)
<Kabouik_>Given that my ssh parameters are in my system.scm with (password-authentication? #f), do I really need to reconfigure to just change #f into #t temporarily?
<Kabouik_>Thanks unmatched-paren, just found your comments on my package. It's greatly appreciated, thanks for your time! I'll try to make it work with git after reading through all your commnents
<atka>sneek: botsnack
<efraim_>Kabouik_: you could track down the ssh service and relaunch it by hand with the change. Another option is to modify the ssh service to already have your key as accepted
<efraim_>not pretty, but here's an example of it:
<sneek>Welcome back atka!
<sudognu>Good morning
<sudognu>I think threre's a bug where downloads would randomly freeze.
<sudognu>left a build for hours and saw a frozen download...
<unwox>sudognu: does "ping" gets through for you?
<sudognu>I'm building without substitutes, but I should have a fine internet
<sudognu>simply restarting the build works fine
***rgherdt__ is now known as rgherdt
<ulfvonbelow>today I learned that keyword arguments that fall back to their default value aren't included in a #:rest list. This means, for example, that in the 'lower' procedure of (guix build-system qt), if #:qtbase isn't explicitly specified, and is instead bound to (default-qtbase), it doesn't get passed on to the bag, and so doesn't get passed on to qt-build, and doesn't get passed to the qt-wrap phase.
<ulfvonbelow>this is a long-winded way of reporting that kguiaddons is broken atm, and that's why
<ulfvonbelow>ah, never mind, I see it's already been fixed
<AwesomeAdam54321>Do contributions to the GNU Shepherd assign copyright to the FSF?
<Kabouik_>Thanks efraim_. I don't change my keys often but when I add a new devices, sometimes I'm reasonable and use a new pair instead of duplicating the first one (which I know is bad practice), so I can't know in advance which keys to authorize in my config. I usually just use ~/.ssh/authorized_keys but populating it with ssh-copy-id requires ssh access in the first place, so usually I just re-enable password authentication just for
<Kabouik_>the time of this manipulation.
<Kabouik_>Password authentication is currently disabled in my system.scm so I assume changes there would need reconfiguring to enable it, and then reconfiguring to disable it again, which seems suboptimal. You said I can track down the service with just that change, how could I do that?
<Kabouik_>On a similar matter, I tried to open my ssh port to WAN with iptables but that doesn't seem to work, I assume it's not how it's done on Guix?
<Kabouik_>For the temporary sshd change, I tried "/run/current-system/profile/sbin/sshd -o "PasswordAuthentication no"" but it complained thatthere is no /etc/ssh/sshd_config, which I think might be specific to Guix.
<Kabouik_>I ended up sharing my public key in another way and pasting myself into the Guix server's ~/.ssh/authorized_keys, but still curious if there would be better ways to change the sshd config without reconfiguring the system
<rekado>Kabouik_: you can pass a config file with -f. It doesn’t have to be at /etc.
<Kabouik_>My problem is I don't really know where the config is in Guix since my only custom ssh settings are in system.scm
<Kabouik_>If I can find the config, I guess I can edit it temporarily, then herd restart sshd
<iyzsong>you can't edit it, it's in /gnu/store and readonly, ls /gnu/store/*sshd_config should find it though.
<Kabouik_>Hum, it found five :<
<iyzsong>having choices, that's fine :)
<Kabouik_>(That's weird though, no? I ran guix gc recently so I didn't expect duplicates)
<iyzsong>old system generations (may have differenet sshd_config) are still there for boot (via grub menus).
<Kabouik_>I see, thanks
<Kabouik_>Sadly that still seems like a rabbit hole. I give it a config file with -f but then it complains that there's no hostkeys (despite ssh-keygen -A)
<rekado>Kabouik_: if sshd is running you can do ‘pgrep -fa sshd’ and see the location.
<jonsger[m]>podiki ah I meant Maxim Cournoyer :)
<Kabouik_>I'm afraid I won't be able to solve that sshd despite your help iyzsong and rekado, even when I supply my `sshd -o "PasswordAuthentication yes" with -f /gnu/store/pathtoany_sshd_config, it complains about hostkeys, even after ssh-keygen and herd restart sshd. Not a big deal, I should change my ssh config too often, and I guess I'll just go through altering the service in my system.scm and reconfiguring when I have to. And for
<Kabouik_>new key pairs, I'll just share pub keys manually instead of using ssh-copy-id.
<Kabouik_>What's more critical is ssh not being reachable from WAN, which I suspect is because my port (in the 3000s) is not opened. I opened it with iptables, but this had no effect, so perhaps this is something that could only be done from Guix config too
<rekado>sshd takes ‘-h /path/to/hostkey’
<rekado>when I had to run a modified sshd I would copy the config from the store and then pass it to sshd with -f.
<iyzsong>um, i see sshd is started by inetd-style by shepherd. 'ps' won't print its command line arguments.
<rekado>oh, used to be different
<Kabouik_>This might be a trivial issue and maybe also a corner case, but since reconfiguration literally takes hours, it can be a significant annoyance when one does need just temporary ssh changes (or trials and errors)
<rekado>that’s how I did it on build nodes, for example
<rekado>why does it take hours?
<rekado>it should be fairly quick when you use the same guix
<Kabouik_>I can't really tell, the last few reconfigurations I ran took more than 2 hours I believe
<Kabouik_>Or maybe 1 hour
<rekado>that’s not normal
<rekado>when you use the same guix it only needs to build the new configuration which is almost trivial.
<Kabouik_>"using the same guix" would be the same grub entry with the same /gnu/store symlinks?
<rekado>the same guix that you used for the current system.
<civodul>Hello Guix!
<Kabouik_>Ok rekado, I'll have to try again, not sure why it was this long the last times but maybe there was something I did not notice. I'll time it better next time I'll do it. And good to know it's supposed to be quicker, that means I can actually reconfigure more easily for small changes like my sshd custom settings.
<Kabouik_>Or opening my ssh port to WAN, which I think is better done from system.scm too
<abrenon>hi guix
<ngraves>Hi ! I was wondering if there is a counselled way to deal with one's patches and contributions. I often end up with several patches in my local guix repo and have to think about how I should order them (also sometimes some future contributions depend on not yet accepted ones etc).
<ngraves>I stumbled upon stacked-git and think it might be quite good for doing this task, but someone probably already has a better solution.
<ngraves>There's the solution of having several forks for each patch series and rebasing (for now I only had a stack of patches waiting, it would already be an improvement).
<gnucode>morning guix!
<gnucode>I have been playing with my new guix server for a few hours now. It's pretty cool!
<gnucode>also what is the best way to auto-magically mount an nfs directory in guix?
<gnucode>It would be nice if the (system (filesystems supported it...)
<unmatched-paren>ignore me :)
<gnucode>ok it looks like file-systems does support nfs mounting! But the documentation doesn't really show that. Good to know.
<muradm>guix, how do you keep local copy of guix-devel mailing list?
<mrvdb>has anyone been able to build 'x265' for powerpc64le? It's a dep of many others through ffmpeg.
<gnucode>muradm I use a maildir :)
<gnucode>and I set up isync to fetch it.
<gnucode>I also, filter incoming guix-devel message into a specific folder.
<muradm>gnucode: what is the endpoint for isync?
<gnucode>I would like to set up my maildir to have the entire guix devel archive, but I haven't yet done that. I've got an idea of how to do it, but not done yet. :)
<muradm>ah, i was asking exactly that
<ngraves>there's a feature for that in rde
<ngraves>it uses l2md
<muradm>but l2md is for git based mailing lists, are gnu's mailing lists are git based?
<ngraves>they aren't but there's a copy
<ngraves>the copy is here
<ngraves>the link shows how it is implemented in a dotfiles repo
<nckx>AwesomeAdam54321: No.
<muradm>ngraves: that is not enough/feasible
***wielaard is now known as mjw
<AwesomeAdam54321>nckx: alright
<gnucode>muradm: you could try downloading the entire mail archive...
<nckx>I hope it was good news.
<gnucode>you are downloading the mbox archive. If you use mbox, then that should be all set.
<gnucode>If you want to use maildir, then you will have to convert those files into a maildir
<muradm>gnucode: yeah, i did that, but you need syncing it, which seems to be a gap now
<philip>Does anyone know if `-msse2 -mfpmath=sse` are ok for the Hurd?
<AwesomeAdam54321>nckx: I think one of the contributions to the Shepherd that I could make is add a #:logger #t/#f option to the services so having a syslogd isn't necessary and will do log rotation
<AwesomeAdam54321>I'm not sure how to do that yet though
<gnucode>AwesomeAdam54321: we already have log rotation enabled by default. :)
<gnucode>and I think civodul had a WIP patch for the shepherd to enhance it's logging capabilities.
<Kabouik_>If I add `(service nftables-service-type)` in my system.scm, how to I tell nftables to open one port? The Guix manual is not very detailed on the nftables example:
<ulfvonbelow>Kabouik_: 'guix system edit nftables' will get you right to the service-type definition, which is right next to the definition of %default-nftables-ruleset.
<ulfvonbelow>I'm no expert, but it looks like you'd add a rule right next to "tcp dport ssh accept", of the form "(tcp|udp) dport <port you want open> accept"
<gnucode>guix should just have an ufw service...uncomplicated firewall
<gnucode>Kabouik_: if you figure out how to set up nfs, please let me know. :)
<Kabouik_>gnucode I'm going to solve fusion nuclear reactions before I can open my port
<gnucode>Kabouik_: haaha
<civodul>gnucode: shepherd 0.9 features Improved Logging Facilities™!
<civodul>(TBH, it could only be improved)
<Kabouik_>Thanks ulfvonbelow. I didn't know about guix system edit, it's kinda mindblowing to see it all show up, but I am not comfortable as to how to use and edit it
<civodul>philip: for the Hurd we target i586-gnu, and i'm not sure SSE2 is within i586
<civodul>so, icecat 91.12.0-guix0-preview1 seems to be broken for me on a number of JS-heavy sites
<civodul>like mattermost
<civodul>i see NS_ERROR_FILE_NO_DEVICE_SPACE errors in the browser console
<civodul>anyone else suffering the same pain?
<civodul>and if i restart it, the very same site works
<mroh>civodul: maybe this workaround works.
<AwesomeAdam54321>Could anyone take a look at my patch? It's pretty old but I think it's still useful for the Shepherd documentation:
***efraim_ is now known as efraim
<philip>civodul: Yeah, that's what I was dubious about. I'll leave them out for now.
***civodul` is now known as civodul
<civodul>philip: now you could add the 'tunable?' property to that package if you think it makes sense
<rekado>civodul: I had icecat errors like this in the past, and resetting localstorage worked for me.
<civodul>rekado: how do you do that?
<rekado>civodul: mroh posted a link above. Deleting the sqlite db should do the trick.
<civodul>oh right, thanks mroh!
<civodul>i'll give that a try
<civodul>it's one of these situations where i have no idea what i'm doing
<civodul>i feel more at ease fiddling with PID 1
<drakonis>a world of contrasts right there.
<civodul>(that's also because PID 1 sends us periodic reminders that it needs love)
<philip>Bikeshedding question: Racket currently uses these symbols to identify a system type "refined to a specific operating system … instead of a generic … classification": '(darwin macosx windows linux freebsd openbsd solaris qnx) Should the Hurd's symbol be 'gnu, 'hurd, 'gnu-hurd, or … ?
<civodul>in theory it should be 'gnu
<civodul>but then again, GNU/Linux should be 'gnu as well if the goal is to know what libc we have
<civodul>these classifications are always inaccurate because it's not clear if you want to know about kernel features, libc interfaces, or something else
<muradm>is there something like map-with-index in guile?
<philip>Yes—mostly, these are an attempt to give a bit mor information than just 'unix. For the Chez machine type I'm proposing 'ti3gnu, where linux (GNU/ and otherwise) is be 'ti3le, and Illumos/OpenIndianna is 'ti3s2, reflecting branding Sun *stopped* using for their kernel c. 1998. The Racket symbols aim to be a bit less cryptic, though.
<Maya[m]1>i was just looking at php and it looks like i need to write a packagist importer lol
<drakonis>muradm: what do you mean with index?
<philip>I'm currently leaning toward 'gnu-hurd for this reason:
<unmatched-paren>drakonis: something like (map-with-index (lambda (elem index) ...) lst) i guess
<rekado>muradm: (let ((lst '(hello world how art thou ?))) (map (lambda (thing index) (pk index thing)) lst (iota (length lst))))
<unmatched-paren>(define (indexed-map func lst) (map func lst (iota (length lst))) i guess :)
<drakonis>shouldn't the messages that prompt for updating the package path and sourcing the profile not show up if you're installing guix as a distribution?
<muradm>rekado: thanks!
<drakonis>gonna write me a fancy trick for installing guix on a existing partition
<unmatched-paren>drakonis: They appear if you've just installed a package that adds a search path
<unmatched-paren>because to get the search path's env var, you need to either relogin or source the profile
<drakonis>ah i see
<phf-1>Hello! I've a problem entering accents. While using `emacs -Q` I usually input the dead key `^' then `e' which gives me `ê' but, for some reason, on a new install of Debian11 nothing happens. I have: then nothing.
<unmatched-paren>phf-1: did you mean to post that in #emacs? ;)
<phf-1>I ask here because when installed via APT accents work but not when emacs is intalled with guix
<drakonis>i admit that i still prefer that guix doesn't play dangerous games with shell scripts
<unmatched-paren>what sort of dangerous games do you mean?
<drakonis>wrapping every binary with shell scripts containing environment variables that complicates the binary's ability to see the environment
<unmatched-paren>We do wrap *some* binaries :)
<drakonis>some of them
<drakonis>not all of them
<drakonis>nix plays dangerous games like wrapping all of them, becoming the leading cause of having to generate wrapper scripts for including dependencies into runtime scope
<drakonis>for every language
<drakonis>basically, want your fancy package to see its dependencies? gotta add it into path with a script
<drakonis>then multiply that by a thousand times
<drakonis>its fairly rickety and breaks expectations
<drakonis>plus a lot of patches are requried
<unmatched-paren>I suppose it only does that for e.g. python and scheme? Because it seems like you could just modify the rpath for actual ELF binaries
<drakonis>you mean guix or nix here?
<drakonis>because nix does that everywhere, i'm not kidding
<drakonis>if you want to do something as trivial as letting a game see addons, you need to wrap that mfer good
<unmatched-paren>even for binaries that don't need it?
<drakonis>cataclysm cdda lol
<drakonis>let me grab one
<drakonis>you need a wrapper for the tilesets
<phf-1>accents works when when using `emacs -Q -nw`
<phf-1>so there is something going on acquiring inputs from the keyboard when using emacs installed with `guix install emacs` on Debian11.
***cedb is now known as zced
<drakonis>unmatched-paren: its a horrid time tbh
<drakonis>imagine needing to wrap language runtimes or compilers so they can see the packages
<drakonis>they take closures too far
***zced is now known as cedb
<civodul>i've done years of Nix but nowadays, each time i see a .nix file, my eyes hurt
<unmatched-paren>the language doesn't look too bad to me
<unmatched-paren>except for the perl/shell parts
<nckx>It didn't used to hurt my eyes but now it does.
<vivien>Oh the package depends on the list of patch file names, not patch content
<vivien>I learnt something today :)
<vivien>Ah no, that’s another problem then.
<vivien>Mmh I get error: failed to compile 'guix/build/clojure-build-system.scm' on master, is someone on it?
<vivien>I’ll clean and retry
<vivien>Guix has some puzzles up its sleeves, especially when using tangled gexp, quasiquotes, ungexp, unquotes, and their splicing variants.
<unmatched-paren>vivien: I saw that before
***aweinsto1k is now known as aweinstock
<apteryx>vivien: not a bug, it's some stale .go
<vivien>It disappears when I rebuild everything, so my room is a little bit hotter but I’m otherwise satisfied :)
<vivien>Wait! Don’t apply 56892 just yet!
<vivien>I’ll need to update it.
<apteryx>jonsger[m]: what is the package name that broke? hime?
<acrow>vagrantc: I hope your day is starting off well. Do you have time to talk about the licensing/copyright sorting rube-goldberg mousetrap?
<antipode>I'm wondering what kind of mutated mouse invasion you have that requires such a mousetrap.
<antipode>Do you have a link to relevant material?
<unmatched-paren>Lawyer mice are the worst kind.
<nckx>antipode: Debian?
<unmatched-paren>You can't even catch lawyer mice with mousetraps; you have to devise truly devious legal loopholes to catch them.
<acrow>antipode: As an engineer I focus on what is wrong -- hence my comments; but, in truth there is some good in this thing that helps create the machine-readable debian copyright notice from one of our source trees.
<antipode>Which comments, what part of Debian, etc.?
<antipode>I am unaware of context here beyond your "vagrantc: I hope ..."
<acrow>antipode: vagrantc builds the debian guix package. It requires a painful copyright file I've been working on a guile script to help automate that process.
<unmatched-paren>IoT mousetrap powered by a Guile script? :)
<acrow>unmatched-paren: Hardly IoT, but mousetrap, yes. guile, yes.
<acrow>antipode: unmatched-paren: I'll post it for those that want to at a medusa. It's way better than doing it by hand and the hope would be that it could be leveraged for other such tasks.
<unmatched-paren>Excerpt from its patent: "...the derive keeps score of the number of mice caught, and uploads the score daily to a global leaderboard..." :P
<unmatched-paren>s/derive/device/ (how did that happen?!)
<acrow>yeah, that's the reaction I was anticipating.
<acrow>Note that when applied to our guix source tree --- it painfully identifies tiny problems we have.
<acrow>For example -- guix/text/import-git.scm -- The email address of the sole copyright holder is mangled.
<vagrantc>acrow: soonish i think!
<vagrantc>acrow: a little nervous about "2. Convert organizational names like Free Software Foundation, Inc to a normalized form." ... there is some potential to misattribute there
<vagrantc>acrow: better to have potential duplicates than misattribute
<acrow>vagrantc: group/organizations could/should follow the same rules as everybody else. At least in my perfect world or one that honors machine readable materials like source code.
<vagrantc>acrow: but when defining "who is a copyright holder" it is much safer to specify it exactly and not normalize it
<vagrantc>acrow: you're just making a reasonable guess that two entities are actually the same
<acrow>vagrantc: In this case I just forced the 'Free Software Foundation' copyright claim to have a faux email address, like everyone else. Otherwise they don't get handled. It's kinda like not managing the Type I errors so you don't have to worry about the Type II errors. (statistical reference in intended there)
<acrow>vagrantc: granted -- but through I documented it as a general case -- so far, it's a class of only one, a big one, the Free Software Foundation.
<vagrantc>acrow: making a claim to an email address that maybe doesn't exist and isn't asserted in the copyright notice is very wrong
<vagrantc>acrow: don't add imperfections in the name of perfection :P
<vagrantc>copyright doesn't require an email address, only a named entity
<vagrantc>it makes it easier to contact that entity if they specify contact information, but it is not at all required
<singpolyma>Doesn't even require a named entity, though it's hard to do much if you have no guess who the owner is
<acrow>vagrantc: I need a primary key for copyright holders. I've only made an assumption for one prominent one.
<acrow>vagrantc: oh, of course if a real email address could be identified! I would use it.
<vagrantc>singpolyma: fair
<acrow>or better, ask that the source be modified to reflect that.
<vagrantc>acrow: there is no email address provided, don't make one up
<vagrantc>acrow: this will sabotage the utility of what you're writing ... you're writing a program for how things should be, not how they are :)
<vagrantc>acrow: you could generate a hash of the entity name instead of requiring it be an email address
<vagrantc>singpolyma: anonymous copyright holder? is it plausible to license something if you don't know who licensed it?
<vagrantc>acrow: and then use that hash for all of the entities instead of an email address ...
<acrow>vagrantc: I tried using names for the keys and other difficulties arrived. I will certainly remove this if it is sabotage (harsh) but this was how I was dealing with failed attributions. Otherwise these things get missed and nobody notices.
<acrow>s/arrived/arose/ don't know how that happened....
<acrow>vagrantc: I have some notional rules that I'm trying to apply. First it has to be easier than doing it by hand. Second, maximize giving credit (or minimize omissions). Third, avoid special case file filters (this one is very problematic for the patches).
<vagrantc>acrow: all sound good, though in the world of documenting copyright/license issues, the third is going to be hard to pull off realistically ...
<acrow>vagrantc: recall that many copyright holders identify multiple email addresses and we want to presume they are all different people to avoid misattributions.
<vagrantc>acrow: i mean, guix is what i would call an overall shining example, and even it has some rough territory, as you're well aware :)
<vagrantc>acrow: exactly
<vagrantc>acrow: so hash the whole copyright line, not treating email addresses as special
<vagrantc>or don't hash it at all, just use the line itself as a key
<acrow>vagrantc: ok, I'm thinking about that. That might work.
<vagrantc>the years are "special" in that they would be nice to consolidate ... i might normalize on whitespace ... e.g. "foo bar" i might feel ok with normalizing to "foo bar" ... though maybe there are names where whitespace is significant? :)
<acrow>vagrantc: The problem I forsee is that these notices pop up everywhere and are prefixed with all the possible and some impossible comment prefixes.
<vagrantc>this reminds me of
<acrow>vagrantc: so using the whole line is going to generate some additional degeneracy.
<vagrantc>acrow: yes, you'll have to split on Copyiright or some such
<vagrantc>and you have to remove the dates
<acrow>vagrantc: It's all engineering compromise. Nothing can work perfectly. It just has to be better than what we can do manually.
<vagrantc>basically, i would hash it on everything after the dates
<vagrantc>acrow: absolutely
<vagrantc>acrow: if it requires some manual fiddling after running it, but mostly gets it right, that would be fine by me
<vagrantc>acrow: e.g. a list of "needs manual review" files that is reasonable is fine
<acrow>vagrantc: ok, 'needs manual review' is a proxy for the current 'any licensing but it could also be the case for files that have no copyright holders. I'm comfortable with our ability to manage these things. The bigger technical issues are: 1. compression using globbing and 2. (way further out but possibly related to #1) generalization to other than the guix source tree.
<vagrantc>acrow: yeah, the globbing is the tricky part ... the good news is the vast majority of guix is GPL3+ i think
<vagrantc>acrow: so you pretty much only need to document the exceptions, and add all the copyright holders to that initial Files: *
<vagrantc>for the non-exceptions
<vagrantc>acrow: obviously wouldn't generalize to other projects ... but you could skip the globs entirely and just group by license
<acrow>vagrantc: Ok, that seems practical. I was going to suggest just listing all the files bc it is supposed to be machine readable anyway and globbing results in some data loss.
<vagrantc>acrow: technically globbing doesn't result in data loss if you do it correctly :)
<vagrantc>acrow: and again, just like you're writing this as a tool to make generating this file easier, the file you're generating is just a tool to make knowing what licensing a project is affected by easier :)
<acrow>vagrantc: What about the knowledge that Frank is copyright holder on file/glob/a but not on file/glob/b. Boxing all the copyright holders together increases entropy.
<acrow>vagrantc: specificity is lost.
<vagrantc>acrow: i see what you mean ... though i think the debian/copyright file is a tool and you're trying to solve a different problem
<vagrantc>acrow: it is just suppose to give you a list of relevent licenses and copyright holders
<vagrantc>acrow: at the end of the day, the files themselves are the canonical source of accuracy
<vagrantc>acrow: basically, it is a summary ... you don't write a summary by copying the whole thing :)
<vagrantc>acrow: and, this file is shipped in each binary package uncompressed ... so some amount of space-savings is desireable
<vagrantc>but, like all things, it is a balancing act
<acrow>vagrantc: perhaps. This leads to project specialization. eg... (and I tried this) if you decide that your project (guix) is licensed gpl-3.0+ then pull all the files/copyrights that fall under that license together you are likely to get a reasonable shorting of the copyright summary and still meet the debial criteria. But, what do we gain? The length of the file doesn't change that much and if someone really wants to compress it --
<acrow>there are many straightforward, better ways to do it. So, I think we should just list every darn file with all the imperfections exposed.
***Dynom_ is now known as Guest72
<acrow>vagrantc: agreed. I think we are getting a pretty detailed summarization at this point.
<vagrantc>acrow: just the list of files alone is ~96k ... having at least one or more copyright holders per file will more than double that, plus the License: header ... vs. if you consolidate the vast majority into a "Files: *" with one consolidated copyright line for each identified copyright holder ... you can probably keep it down significantly
<vagrantc>acrow: the current debian/copyright is ~32k using file globbing for most of it
<vagrantc>acrow: so at a minimum, and surely more, that's well over 288k vs ~32k
<vagrantc>64k ought to be enough for anyone
<vagrantc>acrow: for packages that ship multiple packages (which i might split guix into two packages on debian at some point) that file will be installed once per package
<vagrantc>acrow: which isn't a lot, per say, but if every package does it that way, it adds up.
<vagrantc>per se
<vagrantc>weather debian's requirements for debian/copyright files are reasonable is pretty much neither here nor there ...
<vagrantc>acrow: another example, a much larger project, linux, has a debian/copyright of 16k ... and numerous packages ... if they listed every single file individually ...
<acrow>vagrantc: ack. Given only the glob techniques to achieve this compression I think each project
<acrow>is going to need to be handled idiosyncratically. I'm thinking about a simple description notation to allow that to be done.
<acrow>vagrantc: but, at this moment, I'm going to choose to implement the simplest thing: a glob by primpary license type. Let's see how much we get from that..
<acrow>vagrantc: I know, you would think that we could easily glob all the GPL-3.0+ files in gnu/packages togther but there are problems like patches and syntax errors (like identified above) that break that model. So, I'm doing what is currently possible.
<apteryx>tigervnc is pretty cool; fast and dynamic resize of windows is working, as well as copy-pasting
<muradm>rekado: i'm trying to parse guix-devel mbox with (email email) and i face "In procedure open_iconv_descriptors: invalid or unknown character encoding Y"
<muradm>do you have any idea?
<podiki[m]>apteryx: ever get a chance to try out the FHS container? I've been using it as needed in my day to day, though I'm guessing some experts will have some thoughts on improving it (the start script is a bit hacky?)
<apteryx>podiki[m]: hey! had you sent updated patches? I haven't tried it yet. I had some idea recently; tor-browser
<apteryx>since upstream don't want downstream users to package it, it seems a good use case
<podiki[m]> was a polished version of what I sent on the mailing list
<podiki[m]>(maybe got unnoticed in the server outages recently)
<podiki[m]>I did do a quick v2 to correct a manual text formatting issue
<podiki[m]>apteryx: and a tip I found was do use -D ungoogled-chromium to get basically all the deps anyone wants for lots of things; I also put in the command I use to share/expose from the host what I've needed
***cedb is now known as roulette
***roulette is now known as cedb
<apteryx>OK! I'll try taking a look again
***mark_ is now known as mjw
<jab>Hey guix! Can we still be friends if I use OpenBSD to configure my local router?
<drakonis>eh, sure?
<singpolyma>jab: extra points if you convince guix to run under openbsd ;)
<drakonis>openbsd and not *checks notes* hyperbolabsd
<jab>drakonis: why not hyperbolabsd? Too much effort to get it working?
<drakonis>its more like a pipe dream
<jab>singpolyma: That would be the miracle of the century!
<unmatched-paren>jab: I believe hyperbola doesn't really exist yet
<drakonis>hyperbola is pretty much vaporware and comes off as someone's pipe dream
<unmatched-paren>it's basically openbsd with a few seds run on the repo, last i heard
<jab>unmatched-paren: yeah that's what I've heard...but I do believe they have a got sed to work! And it runs!
<drakonis>i think it has really questionable motivations
<unmatched-paren>"evul rust!!!111"
<drakonis>that too
<drakonis>they also did that to java and node
<unmatched-paren>(bad software != evil software)
<drakonis>they also went and axed c#?
<unmatched-paren>"our ultra-minimal distro only allows programs written in assembly"
<drakonis>also deleted dbus from the distribution and sudo?
<unmatched-paren>dbus is basically required for anything
<drakonis>and systemd too
<unmatched-paren>at least, anything desktoppy
<unmatched-paren>well, guix system doesn't have systemd either, soo...
<drakonis>i mean, it doesnt have systemd because it has shepherd
<drakonis> and
<drakonis>there's a mix of misunderstanding how certain kinds of software work and a lot of fear, uncertainty and doubthere
<drakonis>while dbus is not without flaws, complaining about machine identifiers is weird
<unmatched-paren>sure, many of the red hat things are overengineered and sometimes stupid, but that's no reason to refuse to include them entirely
<drakonis>it exists for communicating with machines inside a same network
<drakonis>have they never worked with clusters?
<drakonis>its not specifically a red hat problem in this instance i suppose
<jab>singpolyma: it would be cool if guix were ported to OpenBSD! I don't think the OpenBSD would help that effort. :)
<drakonis>jab: they definitely wouldn't!
<drakonis>something something bsds
<unmatched-paren>given the high buzzword density of, it isn't *really* a surprise that some of their projects are a bit gross
<drakonis>it would also incur a maintenance cost for guix the project if it becomes unmaintained and nobody gets involved
<drakonis>unmatched-paren: its a lennart poettering project anyways
<drakonis>also red hat's website is not a metric for anything.
<unmatched-paren>aren't they sort of developed under the auspices of fedora?
<unmatched-paren>systemd i mean
<drakonis>systemd has its own dbus implementation at this point
<unmatched-paren>which thankfully has been extracted in the manner of elogind :)
<drakonis>it was the first thing that systemd directly subsumed
<drakonis>dbus did not cease to exist though
<drakonis>ah, there's that.
<drakonis>cool beans.
<jackhill>say, my default `guix pull` profile uses a custom channels.scm. Is there a convienient way, perhaps with time-machine, to run guix commands using just the default channels withour writing a separate channels.scm file, or moving the one that's in the default location? I would like, for provanance/reproducability reasons to document the sofware I used, and don't need my custom cruft to be included.
<drakonis>ah, are you trying to pin an environment?
<drakonis>or have it load a specific channel list?
<jackhill>drakonis: a specific channel list. I'm actually creating packs to run on non-guix systems
<jackhill>and want a simple (but maybe not airtight) way to say, this pack came from this commit with just the default guix channel
<drakonis>does the manifest not have that?
<unmatched-paren>an inferior, maybe?
<unmatched-paren>(define inferior (inferior-for-channels %default-channels))
<unmatched-paren>and then
<unmatched-paren>(packages->manifest (list (map (compose car (cute lookup-inferior-packages <>)) (list "gcc-toolchain" "markdown" "perl")))
<unmatched-paren>replace the (list (map ...)) with just (map ...)
<jackhill>It does, but by default I think the manifest will include my custom channels too. Anyway, I guess it's not the hard to do it the correct, airtight way, so I'll just do that.
<unmatched-paren>and to lock to a commit:
<unmatched-paren>(define inferior (inferior-for-channels (list (channel (inherit %default-guix-channel) (commit ...))))
<jackhill>thanks for brainstorming with me :)
***lukedashjr is now known as luke-jr
<jab>pretty off topic, but I made a very basic intro blog post about IP address, ports and LAN vs. WAN. suggestions for improvement are welcome
<Guest95>Hello. Am I right that package cairomm-1.14 propagates 2 different versions of libsigc++ (libsigc++ which is now 3.0.6 and libsigc++-2)? Essentially the same problem as this fixed:
<apteryx>how do we extend pam services? VNC has for example /etc/pam.d/tigervnc
<apteryx>seems I have to translate that file into a bunch of <pam-entry> records?
<GNUtoo>Hi, I've updated Guix on a computer I use for running tests, and after entering the disk decription passphrase in GRUB, I have "error: symbol `grub_calloc` not found."
<GNUtoo>Is it a known issue?
<GNUtoo>On that same computer I've been having many segmentation fault and kernel panic, so I'm unsure if it comes from me or from Guix
<apteryx>GNUtoo: I've never encountered that error
<GNUtoo>We probably need to bugreport then
<GNUtoo>Ah I didn't see the never (I read too fast)
<GNUtoo>ok, I'll try to workaround and then try to sudo guix system reconfigure again
*GNUtoo wants to test how phoronix-test-suite works without risking to run nonfree software
<GNUtoo>We have a different patch in Parabola so we need to sync to make sure that users don't end up in a situation where they install nonfree software because 2 distros had different ways of fixing it (like I run Guix on top of Parabola and it lists nonfree stuff)
<GNUtoo>So I'm trying to install a recent guix on a separate computer for that
<GNUtoo>(to make sure the patch works fine on 100% guix and pinpoint the issue without having nonfree software run on computers that I use for real)
*civodul shaves yak, sends the result ->