<g_bor>rekado: also, if you have some time when you can access the firmware interface of the host, you can check, if the devices are available from there. Grub actually piggybacks on services provided by the firmware.
<g_bor>So, if they are not available from there, then you can't see them in grub either.
<g_bor>rekado: you might also have to enable some options/map the storage in the storage configuration of the host.
<g_bor>Unfortunately our configuration is not exactly as yours, but these might help.
<mbakke>I've made some progress on removing the libstdc++ hack on core-updates-next.
<mbakke>The main culprit seems to be that "g++ -v" exits with status 1 and the error:
<mbakke> /gnu/store/qachfs4q8dk5cwgzpygifqhp260m6a3f-glibc-mesboot-2.16.0/lib/crt1.o: In function `_start': /tmp/guix-build-glibc-mesboot-2.16.0.drv-0/glibc-2.16.0/csu/../sysdeps/i386/start.S:113: undefined reference to `main'
<Laalf>my problem is mainly plugins. i just looked through mine and i dont have any plugins that are not at least open source. the problem that plugins might not work with the finished product (you have to tell chromium to phone home, which maybe gets patched out?) really bugs me. stuff like browserpass might be additional pain
<lfam>Yes, it's possible that an FSDG Chromium will be missing some features we find useful
<Laalf>how would you put 20 different librejs plugins into a patched chromium if you cant use plugins?
<lfam>IMO the really important thing is that it can render HTML / CSS / JS without allowing remote code execution, and that it handles TLS properly. This is suprisingly hard
<lfam>I should clarify... *unwanted* remote code execution :)
<pkill9>how would an FSDG chromium create that problem? (i might have misread what you meant)
<lfam>Sorry, I was unclear. I was saying that even if things like plugins don't work, it will still be valuable to have a solid codebase that does basic browser stuff like rendering sites and doesn't screw up TLS
<lfam>So, even though our package will be lacking some features / misfeatures compared to upstream, it will still be useful to some people
<roptat>g_bor: for the confusion about hstore in my patches, I wonder if I should rename the extensions field to extension-packages?
<roptat>it would make it more explicit that the field should contain a list of packages, no?
<nckx>That could easily be done as an mcron one-liner now, for long values of line.
<rockandska>Is there anyone who played with the last manifest format with "properties->provenance" ?
<jas4711>nckx: some intelligence is required to determine if the systems needs to be rebooted for the upgrade to have effect (i.e., if the kernel is updated, or if some upgraded service is unable to restart (shepherd?))
<rockandska>civodul: Hi ludo, Yoann there, do you have some time to spare to chat about our discussion to how reproduce a profile from the instantiate manifest ?
<nckx>jas4711: The latter should be done by 'guix system reconfigure' itself (I believe Carlo is working on it). I don't agree that rebooting is the job of an automatic updater. Who will enter your LUKS passphrase twice? ;-)
<civodul>rockandska: we can chat but i won't be 100% behind my IRC client :-)
<jas4711>nckx: i'm happy to add tiny bits of code :)
<rockandska>civodul: just wanna ask what is the true purpose of the instantiate manifest ? and there will be anyway to reuse the new informations inside it ( git repository ) ? could sound stupid, but is there no possibilities to write a file when generating the profile who contain all the original packages definitions + the list of the packages to reproduce the exact same environment ?
<civodul>rockandska: to reproduce the same environment you need the same Guix (+ additional channels), which is roughly what the 'repository' metadata gives us
<Laalf>nckx: they shouldnt be "deleted" or another symlink created while running. if i am at version 9 and upgrade to 11, i cannot use 11s modules. so i want 9s modules to persist until i reboot. i never tried out if they get removed
<rockandska>civodul: but a channel could be a local directory too. when you say "metadata", you talk about your last addition ( properties->provenace) ?
<rockandska>civodul: i understand your point for using "guix package -m" but from the point of view as a user, i think the users need an easy way to be able to put their env into a vcs and share them easily and use the instantiate manifest sound great at first for me before discovering it was not the purpose of it
<nckx>Laalf: Hm... By symlink or "deleted" (why the quotes?), do you mean /run/booted-system?
<nckx>Because note that it's distinct from /run/current-system.
<nckx>'current' is updated, 'booted' isn't. The booted kernel looks for its modz in $LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules.
<rockandska>civodul: so for now, there is no way to reproduce the exact same environment from the instantiate manifest but only with a source manifest with the same guix / channels ?
<civodul>rockandska: the thing to keep in mind is that files you pass to "guix package -m", along with what "guix describe" shows, provide all you need to reproduce a profile
<Laalf>nckx: i spent very little time with nixos and went into guixsd. when i have a new gpu and ovmf with libvirt finally i am moving full time to it. but for that i need some help with libvirt. i will ask tomorrow since i need to get up in time. i guess i will get deeper into the technical stuff of guix when i am using it full time (at least privately)
<civodul>rockandska: trying to do it "the other way around" (i.e., starting from the result and from there inferring the source) is necessarily harder
<rockandska>civodul: sorry but not sure to clearly understand due to my lack of sleep ^^ and I just discovered the "guix describe" addition you add.
<rockandska>civodul: from what i understand , the "provenance meta-data" are only here to helping people to reproduce the env but the instantiate manifest could not be digest directly by "guix package -m" and for now, there is no way to reproduce an env directly from the instantiate manifets file ?
<civodul>rockandska: correct; the recommended way currently is to have a file that you then pass to "guix package -m"
<rockandska>civodul: ok got it thanks, and with "provenance meta-data" there will be eventually in a future a command to accept the instantiate manifest to be able to directly reproduce the env from it.
<civodul>rockandska: possibly, though like i said, it can't be as good as "guix package -m" since it has to infer bits of info
<rockandska>civodul: not sure to be the only one who need it, but maybe others would be interested to see how we could create a manifest from a current profile and containing the channel from where the package coming from and could be subject to a blog post ? :) i didn't see a manifest with the channel specifications for each package yet
<civodul>rockandska: we could definitely blog about this!
<rockandska>civodul: i don't get all the implication and sorry to bothering you because of my lack with guix, but it will be really a nice feature to have "guix package -i" etc.. generating a "file" (including provenance meta-data) who could be used directly to reproduce an env
<civodul>all i'm saying is that it's not that easy, and using 'guix package -m' works today
<rockandska>it will be a killer feature (like relocatable !!!^^) because i encounter many times in my work the hell to reproduce an env and the fact that some package disappear from distribution repo or cause conflicts etc... and would love to push Guix
<rockandska>i fully understand that is not easy as i think and you all already do a awesome job :)
<rockandska>last question about "guix package -m" civodul, not sure it was clear in my last email, but did you see my request about be able to read the manifest file from stdin cause it is not possible at now ?
<pkill9>rockandska: not sure if it's helpful, but you can run previous builds of guix and it will use the package definitions that came with it, so as long as you have a record of the git commit, you can use `guix pull --commit=<commit> --build` and then it will create a symlink to that build of guix, then you do `<symlink>/bin/guix environment --ad-hoc <package1> <package2>` to drop into a shell with whatever packages
<rekado>pkill9: it’s easier with the new “inferior Guix” support for manifests.
<rockandska>pkill9: thanks, but i would like to use it as a profile too and be able to use custom definitions not only the guix "commit" repository
<rockandska>pkill9: as discuss with ludovic, even if it seems not easy at it sounds, from a point of view as a user, the best experience will be to be able to reproduce a profile just be having it "manifest" inside vcs and be able to reproduce just by providing this file to a guix command who will be aware that X package is coming from channel X and package Y coming from channel Y