Re: Staging branch is OPEN
Never mind, I see that it was already updated. -- Alex Griffin On Thu, Dec 12, 2019, at 5:38 PM, Alex Griffin wrote: > Is eudev 3.2.9 an appropriate update for staging? It contains an > important fix for Librem laptop keyboards. > > $ guix refresh -l eudev > Building the following 964 packages would ensure 1723 dependent > packages are rebuilt: ... > > -- > Alex Griffin > > On Wed, Dec 11, 2019, at 10:34 PM, Marius Bakke wrote: > > Guix, > > > > The 'staging' branch is awaiting your patches. Please submit your > > changes by the end of this week (i.e. before Monday, 2019-12-15). > > > > Thanks, > > Marius > > > > Attachments: > > * signature.asc > >
Re: Store channel specification in profile
I've seen the "provenance" field mentioned a couple of times before, but I can't see any "provenance" in my $PROFILE/manifest file. Am I missing something? I install profiles with manifests. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello, zimoun ezt írta (időpont: 2019. dec. 12., Csü 17:47): > Hi Gábor, > > Thank you for summarizing the discussion on IRC that I missed. > > Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option > with a different effect? Or why do we want to conserve this option > name? > It appears to me simpler to give another name, for example > "--inputs-of". And it is more meaningful. > Sorry for the confusion. Ad-hoc should be retained with the same effect, so that we do not break existing scripts. Renamin the option would be ok. It even makes sense to me. > > > To be concrete, the different cases; (-) means current behavior and > (+) the new one: > > 1. > - guix environment foo > + guix environment --inputs-of foo > > 2. > - guix environment --ad-hoc bar > + guix environment bar > > > First, when "--ad-hoc" is used then it reports a warning: deprecated > option and falls in the current behavior. > When "--inputs-of" is used then it falls in the new behavior. > Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > That could be done. The problem is caused by uses of guix environment that does not use any of these options. Those mean different things after the change. > > > In other words, with the same future guix version, > > # Alice > $ guix environment foo --ad-hoc bar > Warning: deprecated... explanations... >instead use: > guix environment bar --inputs-of foo > > # Bob > $ guix environment bar --inputs-of foo > > > Second, the previous "guix environment foo" (dependencies of foo) is > inconsistent with the new "guix environment bar" (only the package > bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED > variable to distinguish both, as you said. > Ok. > > # Alice > $ guix environment foo > Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 >turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 > > And Alice has now a new shell with the package foo. If she wants the > dependencies, she has two options: > > $ GUIX_ENVIRONMENT=1 guix environment foo > or > $ guix environment --inputs-of foo > > > # Bob > $ guix environment bar > Warning: previous behavior requires GUIX_ENVIRONMENT > > And if Bob is annoyed by the warnings each time, he globally turns off > with the variable GUIX_ENVIRONMENT_NOWARNING=1. > > > Couple of months later -- after the period adoption -- we remove the > variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; > still keeping the warning with the "--ad-hoc" option. And then, after > we can remove the "--ad-hoc" option if required. > > > Maybe a miss a point. But the addition of the flag appears > "--too-long-to-type" to me ugly. > We could recommend simply to use something like: GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... Instead in existing scripts that are fixed to use the new syntax. This indeed looks like a better solution, and it is less of a maintenance burden. Good idea. > > > What do you think? > > All the best, > simon > Summarizing: Introduce the environment variable. For fixed scripts recommend unsetting the environment variable. That looks like a better plan. Thanks for your insights. Best regards, g_bor >
Re: Guix and pygtk
On Thu, 12 Dec 2019 12:24:27 +0300 Николай Воропаев wrote: > Hi, there is a python2-pygtk package for python 2 in the guix repository, but > no python-pygtk for python 3. Could you add python-pygtk to the repository? I wasn't aware that there is such a thing. Have you tried to use "gi" (Guix package "python-pygobject") ? It uses gobject introspection and can use everything from GNOME. (to be clear: I have no opinion on whether we should add python-pygtk to Guix) pgpqJl19krvLy.pgp Description: OpenPGP digital signature
Re: Store channel specification in profile
Hi Pierre,
On Mon, 9 Dec 2019 at 18:22, Pierre Neidhardt wrote:
>
> Ludovic Courtès writes:
>
> > This is exactly what’s currently implemented if you look at
> > ~/.guix-profile/manifest, under ‘provenance’.
>
> But does "provenance" tell about the channels?
Yes, I think so.
For example, ~/.guix-profile/manifest looks like that:
--8<---cut here---start->8---
("diffoscope"
"131"
"out"
"/gnu/store/h8zr4rxhvpikv9p07kdjkf2dsrja35wm-diffoscope-131"
(propagated-inputs ())
(search-paths ())
(properties
(provenance
(repository
(version 0)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
"b5d4d5b9bcf267fddd02fcc14b88eac0bebf979f")
--8<---cut here---end--->8---
> > Like zimoun writes, it would be nice to have some sort of a “describe”
> > command for a regular profile. Actually maybe “guix describe -p”?
> >
> > Actually ‘guix describe -p ~/.guix-profile’ works but doesn’t display
> > anything useful. We could fix that by recognizing the kind of profile,
> > somehow.
>
> Seems like a good idea. How do we define "anything useful" though?
> The provenance of packages? How would we format it?
As I explained elsewhere, the file /manifest already
contains almost all the information we need (at least I think we need
;-)). But its format is not complaint with the other format (channels,
manifest). And you answered: it is plumbing! :-)
My point is: this plumbing manifest file should be more
"format-friendly" -- still being plumbing -- and easily compliant with
the --channel or --manifest option, IMHO.
Cheers,
simon
Re: The Guix Days: stream?
On Thu, Dec 12, 2019 at 06:57:27PM +0100, zimoun wrote: > Hi! > > > On Tue, 10 Dec 2019 at 13:51, Pjotr Prins wrote: > > > We can only receive up to 40 people for the Guix days (last year we > > had 35) and we need to reserve the catering. So, please sign up on the > > libreplanet link above, if you intend to come. If we happen to have > > too many people to attend the meeting the 40 who signed up have a > > guaranteed entry. If you don't want to subscribe to the wiki you can > > send us a request to add. > > Previously, we discussed on the possibility to video stream chunks of > these 2 days. > > First question: do we want? I think recording is a fine idea. > Other said, are people interested in remotely watch because they > cannot attend? (live roughly between 9am and 5pm, Brussels hours, so > UTC+1, I guess) > > > If yes, second question: will the ICAB network be strong enough? How > can we test? Nope. Going by other years you should not rely on that. It is unstable.
The Guix Days: stream?
Hi! On Tue, 10 Dec 2019 at 13:51, Pjotr Prins wrote: > We can only receive up to 40 people for the Guix days (last year we > had 35) and we need to reserve the catering. So, please sign up on the > libreplanet link above, if you intend to come. If we happen to have > too many people to attend the meeting the 40 who signed up have a > guaranteed entry. If you don't want to subscribe to the wiki you can > send us a request to add. Previously, we discussed on the possibility to video stream chunks of these 2 days. First question: do we want? Other said, are people interested in remotely watch because they cannot attend? (live roughly between 9am and 5pm, Brussels hours, so UTC+1, I guess) If yes, second question: will the ICAB network be strong enough? How can we test? IMHO, I should be nice to at least share the video projector and the sound. For example with Jitsi (unfortunately not yet packaged :-)). Does anyone have experience? Moreover, we could imagine that someone remotely presents a short (well prepared) demo about an amazing hack. Well, if we agree on sharing what is projected and said, it means that we need a microphone to capture the voice. Anyone? Third question: do we want to video stream the floor/room? If yes, we need a camera. Anyone? And if yes, we probably also need some copyright assignments for the attendees. Well, IMO, I am not sure it is useful to share what happens on the floor... I do not know. WDYT? All the best, simon
Re: Staging branch is OPEN
Is eudev 3.2.9 an appropriate update for staging? It contains an important fix for Librem laptop keyboards. $ guix refresh -l eudev Building the following 964 packages would ensure 1723 dependent packages are rebuilt: ... -- Alex Griffin On Wed, Dec 11, 2019, at 10:34 PM, Marius Bakke wrote: > Guix, > > The 'staging' branch is awaiting your patches. Please submit your > changes by the end of this week (i.e. before Monday, 2019-12-15). > > Thanks, > Marius > > Attachments: > * signature.asc
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Thank you for summarizing the discussion on IRC that I missed. Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option with a different effect? Or why do we want to conserve this option name? It appears to me simpler to give another name, for example "--inputs-of". And it is more meaningful. To be concrete, the different cases; (-) means current behavior and (+) the new one: 1. - guix environment foo + guix environment --inputs-of foo 2. - guix environment --ad-hoc bar + guix environment bar First, when "--ad-hoc" is used then it reports a warning: deprecated option and falls in the current behavior. When "--inputs-of" is used then it falls in the new behavior. Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". In other words, with the same future guix version, # Alice $ guix environment foo --ad-hoc bar Warning: deprecated... explanations... instead use: guix environment bar --inputs-of foo # Bob $ guix environment bar --inputs-of foo Second, the previous "guix environment foo" (dependencies of foo) is inconsistent with the new "guix environment bar" (only the package bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED variable to distinguish both, as you said. # Alice $ guix environment foo Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 And Alice has now a new shell with the package foo. If she wants the dependencies, she has two options: $ GUIX_ENVIRONMENT=1 guix environment foo or $ guix environment --inputs-of foo # Bob $ guix environment bar Warning: previous behavior requires GUIX_ENVIRONMENT And if Bob is annoyed by the warnings each time, he globally turns off with the variable GUIX_ENVIRONMENT_NOWARNING=1. Couple of months later -- after the period adoption -- we remove the variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; still keeping the warning with the "--ad-hoc" option. And then, after we can remove the "--ad-hoc" option if required. Maybe a miss a point. But the addition of the flag appears "--too-long-to-type" to me ugly. What do you think? All the best, simon
Guix and pygtk
Hi, there is a python2-pygtk package for python 2 in the guix repository, but no python-pygtk for python 3. Could you add python-pygtk to the repository?
Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello guix, Based on discussion on IRC the following plan for deprecation might work. Comments are welcome: 1. Make guix environment aware of an environment variable: GUIX_ENVIRONMENT_DEPRECATED_AD_HOC if this is defined, then fall back to the current behaviour. Motivation: this would enable most script users to bypass the problem, while fixing them, but it makes the users aware that they are using a deprecated feature. At the same time this should come with a news entry, an any other announcements should be made that we usually do, so that support don't get overloaded. Is should also be announced that two releases later the code supporting this will be removed, so that we don't have to maintain it, but allow enough time for adoption. 2. add a flag to guix environment, something like --ignore-deprecated-ad-hoc, that makes guix environment ignore the environment variable, and default to the new behaviour. Motivation: so that scripts can be fixed individually by modifying the guix environment call to the new version, and adding the flag, so that it does not cause a problem in the trasitional period while the environment variable is defined. 3. on the specified release remove the environment variable support code, and make the flag a noop, and also deprecated. 4. later if needed after an adoption period we can remove the flag. Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
