unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
@ 2017-03-03 21:58 ng0
       [not found] ` <handler.25957.B.14885741929377.ack@debbugs.gnu.org>
  0 siblings, 1 reply; 7+ messages in thread
From: ng0 @ 2017-03-03 21:58 UTC (permalink / raw)
  To: 25957

Our gitolite package currently creates all
(including gitolite-admin.git) git repositories with references to
"/usr/bin/perl" as shebang, which makes it completely useless on
serverside.
Given that the server side in the case of a gitolite from Guix runs an
environment where you will not run perl from /usr/bin/, you will have to
change all hooks manually currently.

When you install perl into the profile of the user which hosts the
repositories and change the shebangs, gitolite can be used.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks)
       [not found] ` <handler.25957.B.14885741929377.ack@debbugs.gnu.org>
@ 2017-03-03 22:27   ` ng0
  2017-03-04 13:32     ` ng0
  0 siblings, 1 reply; 7+ messages in thread
From: ng0 @ 2017-03-03 22:27 UTC (permalink / raw)
  To: 25957

What makes this worse, with every update (push) of gitolite-admin
repository the shebang of "hooks/update" is reset.
Other repositories seem to keep changes in the hooks shebangs so
far.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks)
  2017-03-03 22:27   ` bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks) ng0
@ 2017-03-04 13:32     ` ng0
  2017-03-04 15:43       ` Danny Milosavljevic
  2022-01-05  0:07       ` bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks zimoun
  0 siblings, 2 replies; 7+ messages in thread
From: ng0 @ 2017-03-04 13:32 UTC (permalink / raw)
  To: 25957

On 17-03-03 22:27:43, ng0 wrote:
> What makes this worse, with every update (push) of gitolite-admin
> repository the shebang of "hooks/update" is reset.
> Other repositories seem to keep changes in the hooks shebangs so
> far.
> 
> 
> 

When I build gitolite from guix, this looks trivial to fix.

[user@abyayala /gnu/store/jw252kw9blfh1lrrib3yk4fkbj5mvdpm-gitolite-3.6.5/share/gitolite]$ egrep -nr "/usr/"
commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
lib/Gitolite/Hooks/PostUpdate.pm:62:#!/usr/bin/perl
lib/Gitolite/Hooks/Update.pm:158:#!/usr/bin/perl
lib/Gitolite/Cache.pm:127:    open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server fail
ed: $!"; 


The parts I want to fix as my immediately affect every user, are in
the directory "lib/Gitolite/Hooks/", I have no idea about redis, but
I think there should be a reference to /gnu/store/ reddis and not
"/usr/sbin/redis-server". Different problem, related bug.. This can be
solved in a commit after this bug.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks)
  2017-03-04 13:32     ` ng0
@ 2017-03-04 15:43       ` Danny Milosavljevic
  2017-03-04 17:33         ` ng0
  2022-01-05  0:07       ` bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks zimoun
  1 sibling, 1 reply; 7+ messages in thread
From: Danny Milosavljevic @ 2017-03-04 15:43 UTC (permalink / raw)
  To: ng0; +Cc: 25957

Hi ng0,

> I think there should be a reference to /gnu/store/ reddis and not
> "/usr/sbin/redis-server". Different problem, related bug.. This can be
> solved in a commit after this bug.

Yeah.

I would question why a normal application needs to start a redis *server* in the first place. Sounds strange to me. But I agree that if it wants to do that it should use a store reference.

<https://redis.io/topics/admin> says "Redis is designed to be a very long running process in your server" so that definitely reads to me that a normal program shouldn't just start redis-server when it feels like it (and I hope it stops it again later? After reading the source code it doesn't appear that way...).

<http://gitolite.com/gitolite/cache.html> says "WARNING: this has not been tested in a while. YMMV". Uhhhh. Not confidence-inspiring.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks)
  2017-03-04 15:43       ` Danny Milosavljevic
@ 2017-03-04 17:33         ` ng0
  0 siblings, 0 replies; 7+ messages in thread
From: ng0 @ 2017-03-04 17:33 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: 25957

On 17-03-04 16:43:09, Danny Milosavljevic wrote:
> Hi ng0,
> 
> > I think there should be a reference to /gnu/store/ reddis and not
> > "/usr/sbin/redis-server". Different problem, related bug.. This can be
> > solved in a commit after this bug.
> 
> Yeah.
> 
> I would question why a normal application needs to start a redis *server* in the first place. Sounds strange to me. But I agree that if it wants to do that it should use a store reference.
> 
> <https://redis.io/topics/admin> says "Redis is designed to be a very long running process in your server" so that definitely reads to me that a normal program shouldn't just start redis-server when it feels like it (and I hope it stops it again later? After reading the source code it doesn't appear that way...).
> 
> <http://gitolite.com/gitolite/cache.html> says "WARNING: this has not been tested in a while. YMMV". Uhhhh. Not confidence-inspiring.

It was the first time I read about reddis in gitolite context, and in
all the time I used gitolite I never really needed it when building or
running.
I disregard this as not very important and not really important at all
to fix. It should be fixed in the long run, but my main concern was
usability of gitolite, which has been addressed in one of the two
patches I've sent.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
  2017-03-04 13:32     ` ng0
  2017-03-04 15:43       ` Danny Milosavljevic
@ 2022-01-05  0:07       ` zimoun
  2022-01-12 18:07         ` Efraim Flashner
  1 sibling, 1 reply; 7+ messages in thread
From: zimoun @ 2022-01-05  0:07 UTC (permalink / raw)
  To: 25957

Hi,

This old bug [1] is still relevant.

1: <http://issues.guix.gnu.org/issue/25957>

On Sat, 04 Mar 2017 at 13:32, ng0 <contact.ng0@cryptolab.net> wrote:
> On 17-03-03 22:27:43, ng0 wrote:

This previous…

> [user@abyayala /gnu/store/jw252kw9blfh1lrrib3yk4fkbj5mvdpm-gitolite-3.6.5/share/gitolite]$ egrep -nr "/usr/"
> commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
> lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
> lib/Gitolite/Hooks/PostUpdate.pm:62:#!/usr/bin/perl
> lib/Gitolite/Hooks/Update.pm:158:#!/usr/bin/perl
> lib/Gitolite/Cache.pm:127:    open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server fail
> ed: $!";

…is now…

--8<---------------cut here---------------start------------->8---
share/gitolite/lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
share/gitolite/lib/Gitolite/Cache.pm:127:    open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server failed: $!";
share/gitolite/commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
--8<---------------cut here---------------end--------------->8---

…but…

> The parts I want to fix as my immediately affect every user, are in
> the directory "lib/Gitolite/Hooks/", I have no idea about redis, but
> I think there should be a reference to /gnu/store/ reddis and not
> "/usr/sbin/redis-server". Different problem, related bug.. This can be
> solved in a commit after this bug.

…the package redis is not a dependency of gitolite.  Therefore, the
question is: is our Gitolite package working with Redis?  Even using the
/usr/bin one?  Idem for SVN.

Otherwise, I am favor to remove the 2 “problematic” references.   WDYT?


Cheers,
simon




^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
  2022-01-05  0:07       ` bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks zimoun
@ 2022-01-12 18:07         ` Efraim Flashner
  0 siblings, 0 replies; 7+ messages in thread
From: Efraim Flashner @ 2022-01-12 18:07 UTC (permalink / raw)
  To: zimoun; +Cc: 25957

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Wed, Jan 05, 2022 at 01:07:07AM +0100, zimoun wrote:
> Hi,
> 
> This old bug [1] is still relevant.
> 
> 1: <http://issues.guix.gnu.org/issue/25957>
> 
> On Sat, 04 Mar 2017 at 13:32, ng0 <contact.ng0@cryptolab.net> wrote:
> > On 17-03-03 22:27:43, ng0 wrote:
> 
> This previous…
> 
> > [user@abyayala /gnu/store/jw252kw9blfh1lrrib3yk4fkbj5mvdpm-gitolite-3.6.5/share/gitolite]$ egrep -nr "/usr/"
> > commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
> > lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
> > lib/Gitolite/Hooks/PostUpdate.pm:62:#!/usr/bin/perl
> > lib/Gitolite/Hooks/Update.pm:158:#!/usr/bin/perl
> > lib/Gitolite/Cache.pm:127:    open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server fail
> > ed: $!";
> 
> …is now…
> 
> --8<---------------cut here---------------start------------->8---
> share/gitolite/lib/Gitolite/Test/Tsh.pm:42:# path when cwd is [...] at /usr/share/perl5/File/Temp.pm line 902".
> share/gitolite/lib/Gitolite/Cache.pm:127:    open( REDIS, "|-", "/usr/sbin/redis-server", "-" ) or die "start redis server failed: $!";
> share/gitolite/commands/svnserve:9:$svnserve ||= "/usr/bin/svnserve -r /var/svn/ -t --tunnel-user=%u";
> --8<---------------cut here---------------end--------------->8---
> 
> …but…
> 
> > The parts I want to fix as my immediately affect every user, are in
> > the directory "lib/Gitolite/Hooks/", I have no idea about redis, but
> > I think there should be a reference to /gnu/store/ reddis and not
> > "/usr/sbin/redis-server". Different problem, related bug.. This can be
> > solved in a commit after this bug.
> 
> …the package redis is not a dependency of gitolite.  Therefore, the
> question is: is our Gitolite package working with Redis?  Even using the
> /usr/bin one?  Idem for SVN.
> 
> Otherwise, I am favor to remove the 2 “problematic” references.   WDYT?

Or change it to search the $PATH for the binary, so it would just be
'redis-server' or 'svnserve'

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-01-12 18:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-03 21:58 bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks ng0
     [not found] ` <handler.25957.B.14885741929377.ack@debbugs.gnu.org>
2017-03-03 22:27   ` bug#25957: Acknowledgement (gitolite broken: created repositories keep references to /usr/bin for hooks) ng0
2017-03-04 13:32     ` ng0
2017-03-04 15:43       ` Danny Milosavljevic
2017-03-04 17:33         ` ng0
2022-01-05  0:07       ` bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks zimoun
2022-01-12 18:07         ` Efraim Flashner

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).