<civodul>for software with several parallel stable series, i thought we could have properties to describe what series to upgrade to
<civodul>like gcc 5.3 would upgrade to 5.4, not 6.2
<dvc>to be fair to jullien - we don't have a section on what specifically a package definition should look like - it's details like (sha256 (base32 on the same line. I only reviewed it as being technically good and made some examples of what I think it should look like for the first 20 packages. I thought he'd see the difference...
<civodul>i wonder if this would be too sophisticated though
<davexunit>that would work. we have like 3 or 4 versions of ruby at this point, for example.
<davexunit>I definitely don't like the version constraint stuff that other package managers do
<civodul>dvc: (sha256 (base32 on the same line is not nice, but it's not the end of the world either ;-)
<dale>Can you explain what a `property' is exactly?
<rekado>dale: it's another field in a package definition
<davexunit>a package can have an arbitrary set of key/value pairs in addition to the regular package data
<civodul>dvc: you could point them at etc/indent-code.el next time
<rekado>dale: we currently use properties to record the upstream package name in some instances
<rekado>civodul, dvc: indent-code.el doesn't fix having the (sha256 ...) expression on one line, though.
<dale>The problem is, it is not really at the package-definition level, is it? The version stem you want to stay confined in is determined by the --install command.
<dvc>yes - but if everyone starts doing it differently we have an unreadable codebase over time. A good codebase is one where you can't tell that it wasn't all written by the same author. If I can tell who wrote what without looking at the git history - that's not good.
<dale>To put that more concretely, if I execute `guix package --install firstname.lastname@example.org', that is the point at which restriction of --upgrade to the 1.0 branch should actually be established.
<void__>as I said IceCat is currently broken here in parabola waiting for the packagers to fix it
<Apteryx>rekado: Thanks for your reply regarding my question about %default-authorized-guix-keys. I thought this value should contain a "list of string-valued gexps" as is written in the guix-configuration Data Type summary in the Base Services node of the guix info.
<Apteryx>Rather than the opaque looking "(#<<file-append> base: #<package email@example.com gnu/packages/package-management.scm:228 4060f00> suffix: ("/share/guix/hydra.gnu.org.pub")>)".
<Apteryx>My exercise is to try to programatically add a public key entry to the acl list structure which has the default value of %default-authorized-guix-keys.
<Apteryx>So I can get some confidence in Scheme/Guile.
<Apteryx>Looks like the %default-athorized-guix-keys is a file-append record defined in gexp.scm, and that it I want to see a lower representation (hopefully the string content of the file?) I must use the "file-append-compiler".
<Apteryx>Is it possible to inherit from a record type and to extend (rather than override) one of its field?
<davexunit>there's no syntax for it, if that's what you mean
<Apteryx>Yes, I guess that's what I meant. I'm not at the level of hacking my way through yet. ;)
<davexunit>for example: (package (inherit emacs) (synopsis (string-append (package-synopsis emacs) " Also, it's way better than Vim.")))
<Apteryx>I'm still lost regarding how to extend (gnu services base)'s %default-authorized-guix-keys with an an entry of my own :/. I now understand that its value is a list containing a file-append record, but I have no clue how to use it.
<davexunit>the modify-services macro can help with that
<alezost>mekeor: no problem, did you install emacs-guix from Guix or from melpa?
<rekado>mekeor: a lot of the guix-specific procedures are defined in the manual. If you’re using an info viewer (like Emacs or “info” or “pinfo”) you can often use the index to find the correct place in the manual.
<mekeor>i have set temporary-file-directory to "~/.emacs.d/temporary/"...
<alezost>The problem is that there is "~" in the file name of --listen argument. I will fix it in Emacs-Guix to make sure it is expanded. But this is rather surprising for me. Did you maybe set `temporary-file-directory'? I always thought it's default value is "/tmp/" while for you it's apparently "~/.emacs.d/temporary/"
<alezost>jmi2k_: you can't start GuixSD's services as user; you need to make your own shepherd config file with services
<jmi2k_>alezost: I'll look in your config, I think it's enough. Thanks ;)
<mekeor>btw, i fixed my issue concerning text not appearing on some pages in icecat by changing my default font family from Noto to something different. i'm not sure what causes this issue. anyone using Noto in Icecat?
<alezost>jmi2k_: well, my config is not simple, I don't recommend to look at it for the beginning :-) Basically, you need to make "~/.config/shepherd/init.scm", then start "shepherd", and then you can use "herd" commands as user
<kyamashita>Is there a way to access the source code of another package from within a package definition?
<kyamashita>Wait... I found some documentation. Maybe there is another way. Is anyone familiar with the Tcl Extension Architecture? :-D