<div dir="ltr">Hello,<div><br></div><div>Regarding draconian firewalls, I have spent more time than I would like to admit working around git:// protocol issues. Last time I checked the git protocol didn't follow very well git proxy rules nor the system's rules. This issue is especially painful when you have git repos with submodules where the submodules are connected through git:// instead of http(s), because you have to discover and manually change every URL to http. </div><div>I have worked around this issue by creating a SOCKS proxy and forcing git proxy every connection through it. This is only possible because I am allowed to connect to external SSH server. </div><div>In summary, you have to create a connection with a remote server (non-firewalled) through ssh, creating a SOCKS proxy:</div><div><br></div><div>ssh -D 9052 user@external_server<br></div><div><br></div><div>Then you need this small script that essentially uses socat to force git to connect to that SOCKS server:</div><div><a href="https://gist.github.com/cdcs/bc00ba3121c09013f2c057b549e6930d">https://gist.github.com/cdcs/bc00ba3121c09013f2c057b549e6930d</a><br></div><div><br></div><div>Then you need to mark the script as executable and tell git to use it.</div><div><br></div><div><div>chmod +x gitproxy</div><div>git config --global core.gitproxy gitproxy</div></div><div><br></div><div>This workaround is able to use other types of proxies besides SOCKS. So if you have a less restricted proxy available, just change the SOCAT options to use it. </div><div>It's better to unset the option after you are through with git protocol clones as every git connection in unnecessarily being proxied through it (git config --unset core.gitproxy). </div><div><br></div><div>Anyway the long term solution is to migrate every PATH to HTTPS.</div><div><br></div><div><div>Thanks, </div></div><div>Best Regards,</div><div>Cláudio</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 3, 2016 at 9:41 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/11/2016 07:00, Ricardo Derbes wrote:<br class="gmail_msg">
> Hello.<br class="gmail_msg">
> About rtems 4.11.0-rc4 release building:<br class="gmail_msg">
> Following Chris instructions, I have built rtems 4.11.0-rc4 release,<br class="gmail_msg">
> for i386/pc686 target, without any glitch.<br class="gmail_msg">
> I issued the --without-rtems option when running<br class="gmail_msg">
> ../source-builder/sb-set-builder in rtems-source-builder/rtems folder,<br class="gmail_msg">
> because I wanted to build later the pc686 BSP, without networking<br class="gmail_msg">
> support, as to add libbsd.<br class="gmail_msg">
><br class="gmail_msg">
> After that, using i386 BSP and tools (i386-rtems-gcc et al) I made a<br class="gmail_msg">
> checkout of rtems-libbsd from git://<a href="http://git.rtems.org/rtems-libbsd.git" rel="noreferrer" class="gmail_msg" target="_blank">git.rtems.org/rtems-libbsd.git</a> and<br class="gmail_msg">
> built it, also without any issue, so now I have libbsd.a library and<br class="gmail_msg">
> includes along with pc686 files.<br class="gmail_msg">
<br class="gmail_msg">
Are you using the libbsd 4.11 branch with 4.11.0-rc4?<br class="gmail_msg">
<br class="gmail_msg">
I have forgotten to include the libbsd source in the release which is a<br class="gmail_msg">
mistake on my part. I will add it for RC5. Thanks for reporting this.<br class="gmail_msg">
<br class="gmail_msg">
> The host used was Fedora19 x86-64 host (on a VM), and the only package<br class="gmail_msg">
> I had to install was waf (yum install waf).<br class="gmail_msg">
><br class="gmail_msg">
> Only one caveat: for corporative users like me, who live behind a<br class="gmail_msg">
> draconian proxy with only port 80 available, it's not possible to<br class="gmail_msg">
> download the packages needed by RSB, nor even git://...<br class="gmail_msg">
> Will be possible to add http and proxy support for RSB, and http<br class="gmail_msg">
> protocol for git repos?<br class="gmail_msg">
<br class="gmail_msg">
There are two issues here, first if I add the 4.11 branch of libbsd as a<br class="gmail_msg">
tar file to the sources directory you should be able to fetch the needed<br class="gmail_msg">
source from the RTEMS ftp server using http which solves your problem<br class="gmail_msg">
for 4.11.<br class="gmail_msg">
<br class="gmail_msg">
The second issue of git verses http in the RSB means changing all the<br class="gmail_msg">
git:// paths in the configuration files. Maybe we can do this but not<br class="gmail_msg">
for 4.11.0. I am not sure what I need to do to add proxy support so some<br class="gmail_msg">
help there would be most welcome. I suspect a --proxy option would be<br class="gmail_msg">
needed.<br class="gmail_msg">
<br class="gmail_msg">
Having restricted firewalls is common with RTEMS users so we are willing<br class="gmail_msg">
to do what we can to help. One of the important goals of our releases is<br class="gmail_msg">
to have _all_ referenced source in the sources directory of a release to<br class="gmail_msg">
help here. This means all source even source from outside RTEMS.<br class="gmail_msg">
<br class="gmail_msg">
> Thank you<br class="gmail_msg">
<br class="gmail_msg">
Thank you for taking the time to test and report what you have found.<br class="gmail_msg">
Every little bit helps improve 4.11.<br class="gmail_msg">
<br class="gmail_msg">
Chris<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
users mailing list<br class="gmail_msg">
<a href="mailto:users@rtems.org" class="gmail_msg" target="_blank">users@rtems.org</a><br class="gmail_msg">
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br class="gmail_msg">
</blockquote></div></div>