Re: [PATCH] gnu: xterm: Accept $SHELL even if not in /etc/shells
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> IMO, it's not reasonable to have to add
>>> /home///bin/ for every combination of ,
>>> , and to /etc/shells, in order to prevent 'xterm' from
>>> overriding your $SHELL setting.
>>
>> On NixOS, /etc/shells contains this:
>>
>> /run/current-system/sw/bin/bash
>> /var/run/current-system/sw/bin/bash
>> /bin/sh
>>
>> Where {/var/,}/run/current-system contains the “global” profile, like on
>> our QEMU images.
>>
>> Perhaps that’s good enough no?
>
> If a user wants to set $SHELL to be the one in their private profile,
> I think 'xterm' shouldn't ignore it and modify $SHELL just because it
> hasn't been authorized by the administrator of the system.
Agreed.
However, we’re just packaging an existing application. IMO, when we
find such limitations (it’s really a limitation, and not something that
makes it completely unusable), we should submit the improvement
upstream, unless upstream no longer exists (I’m not sure if this is the
case here.)
WDYT?
Thanks!
Ludo’.
Re: [gnu.org #881181] Package synopses and blurbs translation
"Ineiev via RT" skribis: >> [karl - Sat Jan 11 18:34:38 2014]: >> >> > What would you prefer? >> >> I prefer plain text, but I don't feel that strongly about it, as such. >> >> > about not introducing HTML markup in the translated text? >> >> If the "translation" you're referring to is the home-pkgblurbs.html file >> which the web translators work with, that is (obviously) specifically >> for the web site, so it doesn't make sense to not be HTML. > > So, are we to change the source format of blurb items to HTML? if yes, > I'd file > a patch to bug-womb. I became convinced that we (Guix) could just get files from the Web translators and patch occurrences of . Really a hack, but it’s probably less intrusive for the rest of us. I was planning to email the TP coordinator to work out the details of the coordination process with the GNU web translators, but I haven’t yet taken the time to do it. Thanks, Ludo’.
Re: [gnu.org #881181] Package synopses and blurbs translation
"Ineiev via RT" skribis: >> [karl - Sat Jan 11 18:34:38 2014]: >> >> > What would you prefer? >> >> I prefer plain text, but I don't feel that strongly about it, as such. >> >> > about not introducing HTML markup in the translated text? >> >> If the "translation" you're referring to is the home-pkgblurbs.html file >> which the web translators work with, that is (obviously) specifically >> for the web site, so it doesn't make sense to not be HTML. > > So, are we to change the source format of blurb items to HTML? if yes, > I'd file > a patch to bug-womb. I became convinced that we (Guix) could just get files from the Web translators and patch occurrences of . Really a hack, but it’s probably less intrusive for the rest of us. I was planning to email the TP coordinator to work out the details of the coordination process with the GNU web translators, but I haven’t yet taken the time to do it. Thanks, Ludo’.
Re: [PATCH] gnu: xterm: Accept $SHELL even if not in /etc/shells
On Fri, Feb 14, 2014 at 11:59:32AM +0100, Ludovic Court??s wrote: However, we???re just packaging an existing application. IMO, when we find such limitations (it???s really a limitation, and not something that makes it completely unusable), we should submit the improvement upstream, unless upstream no longer exists (I???m not sure if this is the case here.) I think the following are true (please correct me if not): * Most (all?) the files in gnu/packages/patches fall into the category of "limitations" to upstream. * In principle, those patch files could be directly applied to upstream without modification. This being the case, would it not be a good idea, to have some kind of web interface to these patch files to make it easy for upstream maintainers to fetch them. (perhaps there is sucha page already) Then we can publish this page and say "hey upstream maintainer! Your package has limitations. Please apply these patches." J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Re: [PATCH] gnu: xterm: Accept $SHELL even if not in /etc/shells
Hello, Not the most experienced "upstream maintainer", but … John Darrington writes: > This being the case, would it not be a good idea, to have some kind of web > interface to these patch files to make it easy for upstream maintainers to > fetch them. (perhaps there is sucha page already) Then we can publish this > page and say "hey upstream maintainer! Your package has limitations. > Please apply these patches." This sounds like a pretty nifty idea! Alex
Re: [PATCH] gnu: xterm: Accept $SHELL even if not in /etc/shells
John Darrington skribis: > On Fri, Feb 14, 2014 at 11:59:32AM +0100, Ludovic Court??s wrote: > However, we???re just packaging an existing application. IMO, when we > find such limitations (it???s really a limitation, and not something that > makes it completely unusable), we should submit the improvement > upstream, unless upstream no longer exists (I???m not sure if this is the > case here.) > > > I think the following are true (please correct me if not): > > * Most (all?) the files in gnu/packages/patches fall into the category of > "limitations" to upstream. > > * In principle, those patch files could be directly applied to upstream > without modification. I think most of the patches in there are fixes (normally submitted upstream), or adjustments so that things can build/run in our environment (patches we don’t want to submit.) > This being the case, would it not be a good idea, to have some kind of web > interface to these patch files to make it easy for upstream maintainers to > fetch them. (perhaps there is sucha page already) Yes, the page is: http://www.gnu.org/software/guix/package-list.html It lists patches and ‘patch snippets’ for each package. Ludo’.
Re: [bug-womb] [gnu.org #881181] Package synopses and blurbs translation
So, are we to change the source format of blurb items to HTML? It seems ugly to me in principle, but if the consensus is that that is the most useful approach, ok, I won't object (i.e., will install the patch :). I don't have strong feelings about it. karl
Re: [bug-womb] [gnu.org #881181] Package synopses and blurbs translation
So, are we to change the source format of blurb items to HTML? It seems ugly to me in principle, but if the consensus is that that is the most useful approach, ok, I won't object (i.e., will install the patch :). I don't have strong feelings about it. karl
