- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #921: Use NECEntry

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #921 was: FAILURE. The Pull Request #5033 was integrated: "Use NECEntry" Pull request url: https://github.com/pharo-project/pharo/pull/5033 Issue Url: https://github.com/pharo-project/pharo/issues/UseNECEntry Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 30, 2019

Re: [Pharo-dev] PLZ fix it for Pharo8...

by Ben Coman

Casimiro, I tested your change and it works well. btw, for such a simple change, you don't even need to connect your Pharo image to github. Just fork the repo and make your edit directly with github's text editor at your equal location location to this... https://github.com/pharo-project/pharo/blob/39a50d3d/src/Tool-Catalog/Catal… <https://github.com/pharo-project/pharo/blob/39a50d3d5196eeaf74d0ad336cfb6b2…> Then submit that as a PR to leave your mark on Pharo (with a good PR description a bug entry not required). Could you give it a go? :) :) cheers -ben On Wed, 16 Oct 2019 at 22:47, ducasse <stepharo(a)netcourrier.com> wrote: > Thanks Casimiro > > Why donât you open a bug entry on github.com? > > > On 16 Oct 2019, at 14:53, Casimiro de Almeida Barreto < > casimiro.barreto(a)gmail.com> wrote: > > In the last builds of Pharo8, CatalogBrowser comes with an easily fixable > glitch... Please could someone take a look? My humble suggestion is: > > =============================================================== > > createRepositoryURLtoNameMappings > "Return a mapping between repositories URLs and their user names" > > <script: 'self createRepositoryURLtoNameMappings inspect'> > |repos| > repos := Dictionary new. > 3 to: SystemVersion current major do: [:v | > repos > at: ('http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo{1}0/main' > format: (Array with: v)) > put: ('Pharo{1}.0' format: (Array with: v)]. > repos at: 'http://www.squeaksource.com/MetacelloRepository' put: > 'Unsorted'. > ^repos > > ================================================================ > > > Best wishes, > > > Casimiro Barreto > > >

Oct. 29, 2019

Re: [Pharo-dev] Git URL issues

by Sven Van Caekenberghe

Hi Esteban, I tried your snippets, see comments below. > On 29 Oct 2019, at 11:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi Sven, > > You are facing two different problems at the same time :) > 1) a problem with Metacello api. There is a mismatch between git and metacello because the apis are not equivalent (specially having iceberg in the middle). > If you want to use HTTPS in metacello you have to explicit you want to use HTTPS, but you still has to use the GitHub:// identifier. > > If you execute first: > > ./pharo build.image eval --save "Iceberg remoteTypeSelector: #httpsUrlâ > > Then your execution: > > ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp > > Will work without warnings. Yes, this now removes the warning (not that that was a real problem). I do not think I understand the implications of changing the remoteTypeSelector though. > Now, you have another problem: > 2) You cannot use an url as this with iceberg/metacello: https://deploy:secret@.../scm/xyz/xyz-pharo.git > And yes, we could do a parse of it and use it (also solving your metacello command problem), but this is not easily doable and it would take time. > The usual way of doing this is not using HTTPS but distributing public/private keys (then you use the regular SSH protocol). > But if you still want/need to use HTTPS, then you need to provide your plaintext credentials. > For iceberg, your credentials are stored in your preferences directory, at credentials.fuel (so you could add them to your CI server, if you have them). > To add them programatically you need to do something like this: > > ./pharo build.image eval --save "IceCredentialStore current > storeCredential: (IcePlaintextCredentials new > username: 'esteban'; > password: 'secret'; > yourself) > forHostname: âgithub.comâ" > > Then you full script will be like this: > > ./pharo build.image eval --save â > Iceberg remoteTypeSelector: #httpsUrlâ. > IceCredentialStore current > storeCredential: (IcePlaintextCredentials new > username: 'esteban'; > password: 'secret'; > yourself) > forHostname: 'github.com' > â > ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp > > I hope this solves your problem :) This worked as well, but since ZTimestamp is a public GitHub.com project, I am not sure the authentication is really used. I tried with my GitHub.com credentials (username/password) and it loaded, but when I altered the password for a wrong one, it still worked ;-) Now, the problem is: how do I access the private, password protected repository of my company ? I tried to add a host to the github:// URL but I do not have the impression that this works. Since making this more concrete involves some sensitive information, I will send you a private email with the details of a test project/repository/user that I made. Sven PS: I want to stress that for me Iceberg works really well on my local development machine: I created the test project/code/baseline without encountering any issue (Pharo 7). > Esteban > > On Mon, Oct 28, 2019 at 11:58 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am still at a loss with this issue. > > When loading from github://svenvc/ztimestamp using Metacello (see original mail) the code in MCGitBasedNetworkRepository>>#createIcebergRepositoryWithFallbackFor:url: clearly switches to using https://github.com/svenvc/ztimestamp.git - I traced it. > > So obviously, Pharo 7 is capable of accessing it. > > However, starting directly with https://github.com/svenvc/ztimestamp.git I end up in a totally different place. Why ? > > This code is so complex... > > > On 25 Oct 2019, at 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > I asked this before, but I still have trouble with this. > > > > What I ultimately want is what I used for years now: use the zero config tools to point to my private repo and install my code and all its dependencies from a single Metacello config. > > > > Basically, > > > > $vm $image config _CONFIG_REPO_ _CONFIG_NAME_ --username=_CONFIG_USER_ --password=_CONFIG_PASS_ --install=_CONFIG_VERSION_ --group=_CONFIG_GROUP_ > > > > towards a private server. > > > > In the new world of git(hub)/tonel/iceberg I am trying the following (not using the 'config' but the new 'metacello' command line handler): > > > > $ uname -a > > Linux audio359 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > > > $ curl get.pharo.org/64/70+vm | bash > > % Total % Received % Xferd Average Speed Time Time Time Current > > Dload Upload Total Spent Left Speed > > 100 3054 100 3054 0 0 57622 0 --:--:-- --:--:-- --:--:-- 57622 > > Downloading the latest 70 Image: > > http://files.pharo.org/get-files/70/pharo64.zip > > Pharo.image > > Downloading the latest pharoVM: > > http://files.pharo.org/get-files/70/pharo64-linux-stable.zip > > pharo-vm/pharo > > Creating starter scripts pharo and pharo-ui > > > > $ ./pharo Pharo.image printVersion > > [version] 'Pharo7.0.4' 'Pharo-7.0.4+build.168.sha.ccd1f6489120f58ddeacb2cac77cd3a0f0dcfbe6 (64 Bit)' > > > > $ ./pharo Pharo.image save build > > > > $ ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp > > > > 3. using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) I will try to clone the HTTPS variant. > > Fetched -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] > > Loaded -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] > > Loading baseline of BaselineOfZTimestamp... > > Fetched -> ZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] > > Loaded -> ZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- cache > > ...finished baseline > > > > $ ./pharo build.image eval ZTimestamp now > > 2019-10-25T12:28:34Z > > > > So although it gave a warning, it worked fine. > > > > The warning said, > > > > using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) I will try to clone the HTTPS variant. > > > > so let's try that after cleaning everything: > > > > $ rm -rf pharo-local/ build.* > > > > $ ./pharo Pharo.image save build > > > > $ ./pharo build.image metacello install https://github.com/svenvc/ztimestamp.git BaselineOfZTimestamp > > > > ...RETRY->BaselineOfZTimestamp > > ...RETRY->BaselineOfZTimestamp > > ...FAILED->BaselineOfZTimestampCould not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in /home/sven/pharo7/pharo-local/package-cache https://github.com/svenvc/ztimestamp.git > > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > > > > WTF ? Why does this not work (I can perfectly git clone that URL) ? > > > > Of course, this would just be the first step, eventually I want to use my own private server with a URL like > > > > https://deploy:secret@bitbucket.myserver.be/scm/xyz/xyz-pharo.git > > > > How do you build/deploy non-public production code using the command line ? > > > > Help would be much appreciated. > > > > Sven > > > >

Oct. 29, 2019

Re: [Pharo-dev] Git URL issues

by Christopher Fuhrman

On Tue, 29 Oct 2019 at 06:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 29 Oct 2019, at 11:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Also, I was reading the implementation (hard), and it seemed as if the > only real solution would be to make a new type (scheme), for this case, like > > > > githttps://user1:passw1@server.company.com/scm/bla/foo-pharo.git > > And thatâs why we use another solution more generic. Otherwise we will > need to add GitHubHTTPS, GitLabHTTPS, etc., etc. > I'm someone using 2FA on many systems (I use Authy for a key generator on my android phone) and I've been using it on GitHub now for years. I am forced to use the SSH approach since there is no viable Iceberg solution with HTTPS (there is actually a work-around with a GitHub application-defined key, but that is just a special password that isn't really 2FA IMO). If there's a redesign of the Iceberg API, it would be good to consider the 2FA dimension, too. Cris > > > > which would then preserve the username/password/host/port and do the > proper thing directly. IIUC, https git URLs are described as the most > common ones. > > > > It might be that there is then still a problem with branches/tags, but > maybe they are not needed. > > > > Sven > > > >> On 29 Oct 2019, at 11:07, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > >> Hi Sven, > >> > >> You are facing two different problems at the same time :) > >> 1) a problem with Metacello api. There is a mismatch between git and > metacello because the apis are not equivalent (specially having iceberg in > the middle). > >> If you want to use HTTPS in metacello you have to explicit you want to > use HTTPS, but you still has to use the GitHub:// identifier. > >> > >> If you execute first: > >> > >> ./pharo build.image eval --save "Iceberg remoteTypeSelector: #httpsUrlâ > >> > >> Then your execution: > >> > >> ./pharo build.image metacello install github://svenvc/ztimestamp > BaselineOfZTimestamp > >> > >> Will work without warnings. > >> > >> Now, you have another problem: > >> 2) You cannot use an url as this with iceberg/metacello: > https://deploy:secret@.../scm/xyz/xyz-pharo.git > >> And yes, we could do a parse of it and use it (also solving your > metacello command problem), but this is not easily doable and it would take > time. > >> The usual way of doing this is not using HTTPS but distributing > public/private keys (then you use the regular SSH protocol). > >> But if you still want/need to use HTTPS, then you need to provide your > plaintext credentials. > >> For iceberg, your credentials are stored in your preferences directory, > at credentials.fuel (so you could add them to your CI server, if you have > them). > >> To add them programatically you need to do something like this: > >> > >> ./pharo build.image eval --save "IceCredentialStore current > >> storeCredential: (IcePlaintextCredentials new > >> username: 'esteban'; > >> password: 'secret'; > >> yourself) > >> forHostname: âgithub.comâ" > >> > >> Then you full script will be like this: > >> > >> ./pharo build.image eval --save â > >> Iceberg remoteTypeSelector: #httpsUrlâ. > >> IceCredentialStore current > >> storeCredential: (IcePlaintextCredentials new > >> username: 'esteban'; > >> password: 'secret'; > >> yourself) > >> forHostname: 'github.com' > >> â > >> ./pharo build.image metacello install github://svenvc/ztimestamp > BaselineOfZTimestamp > >> > >> I hope this solves your problem :) > >> > >> Esteban > >> > >> On Mon, Oct 28, 2019 at 11:58 AM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> I am still at a loss with this issue. > >> > >> When loading from github://svenvc/ztimestamp using Metacello (see > original mail) the code in > MCGitBasedNetworkRepository>>#createIcebergRepositoryWithFallbackFor:url: > clearly switches to using https://github.com/svenvc/ztimestamp.git - I > traced it. > >> > >> So obviously, Pharo 7 is capable of accessing it. > >> > >> However, starting directly with > https://github.com/svenvc/ztimestamp.git I end up in a totally different > place. Why ? > >> > >> This code is so complex... > >> > >>> On 25 Oct 2019, at 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> Hi, > >>> > >>> I asked this before, but I still have trouble with this. > >>> > >>> What I ultimately want is what I used for years now: use the zero > config tools to point to my private repo and install my code and all its > dependencies from a single Metacello config. > >>> > >>> Basically, > >>> > >>> $vm $image config _CONFIG_REPO_ _CONFIG_NAME_ --username=_CONFIG_USER_ > --password=_CONFIG_PASS_ --install=_CONFIG_VERSION_ --group=_CONFIG_GROUP_ > >>> > >>> towards a private server. > >>> > >>> In the new world of git(hub)/tonel/iceberg I am trying the following > (not using the 'config' but the new 'metacello' command line handler): > >>> > >>> $ uname -a > >>> Linux audio359 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 > UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > >>> > >>> $ curl get.pharo.org/64/70+vm | bash > >>> % Total % Received % Xferd Average Speed Time Time Time > Current > >>> Dload Upload Total Spent Left > Speed > >>> 100 3054 100 3054 0 0 57622 0 --:--:-- --:--:-- > --:--:-- 57622 > >>> Downloading the latest 70 Image: > >>> http://files.pharo.org/get-files/70/pharo64.zip > >>> Pharo.image > >>> Downloading the latest pharoVM: > >>> http://files.pharo.org/get-files/70/pharo64-linux-stable.zip > >>> pharo-vm/pharo > >>> Creating starter scripts pharo and pharo-ui > >>> > >>> $ ./pharo Pharo.image printVersion > >>> [version] 'Pharo7.0.4' > 'Pharo-7.0.4+build.168.sha.ccd1f6489120f58ddeacb2cac77cd3a0f0dcfbe6 (64 > Bit)' > >>> > >>> $ ./pharo Pharo.image save build > >>> > >>> $ ./pharo build.image metacello install github://svenvc/ztimestamp > BaselineOfZTimestamp > >>> > >>> 3. using HTTPS instead SSH (Just use an url in the form > HTTPS://etc.git) I will try to clone the HTTPS variant. > >>> Fetched -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- > https://github.com/svenvc/ztimestamp.git[master] --- > https://github.com/svenvc/ztimestamp.git[master] > >>> Loaded -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- > https://github.com/svenvc/ztimestamp.git[master] --- > https://github.com/svenvc/ztimestamp.git[master] > >>> Loading baseline of BaselineOfZTimestamp... > >>> Fetched -> ZTimestamp-CompatibleUserName.1554735117 --- > https://github.com/svenvc/ztimestamp.git[master] --- > https://github.com/svenvc/ztimestamp.git[master] > >>> Loaded -> ZTimestamp-CompatibleUserName.1554735117 --- > https://github.com/svenvc/ztimestamp.git[master] --- cache > >>> ...finished baseline > >>> > >>> $ ./pharo build.image eval ZTimestamp now > >>> 2019-10-25T12:28:34Z > >>> > >>> So although it gave a warning, it worked fine. > >>> > >>> The warning said, > >>> > >>> using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) > I will try to clone the HTTPS variant. > >>> > >>> so let's try that after cleaning everything: > >>> > >>> $ rm -rf pharo-local/ build.* > >>> > >>> $ ./pharo Pharo.image save build > >>> > >>> $ ./pharo build.image metacello install > https://github.com/svenvc/ztimestamp.git BaselineOfZTimestamp > >>> > >>> ...RETRY->BaselineOfZTimestamp > >>> ...RETRY->BaselineOfZTimestamp > >>> ...FAILED->BaselineOfZTimestampCould not resolve: BaselineOfZTimestamp > [BaselineOfZTimestamp] in /home/sven/pharo7/pharo-local/package-cache > https://github.com/svenvc/ztimestamp.git > >>> > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > >>> > >>> WTF ? Why does this not work (I can perfectly git clone that URL) ? > >>> > >>> Of course, this would just be the first step, eventually I want to use > my own private server with a URL like > >>> > >>> https://deploy:secret@bitbucket.myserver.be/scm/xyz/xyz-pharo.git > >>> > >>> How do you build/deploy non-public production code using the command > line ? > >>> > >>> Help would be much appreciated. > >>> > >>> Sven > >>> > >> > >> > > > > > > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)*

Oct. 29, 2019

Re: [Pharo-dev] make github issues clearer?

by Gabriel Cotelli

Hi! I think one of the problems is that not everybody can set labels. I've created a lot of issues but the only thing I can do is to set the description and title, even if I already know if it's a bug or feature, or the Pharo version it affects. For ba-st projects we have a set of standardized labels (see for example https://github.com/ba-st/Stargate/labels) and using it in every project makes it easy to filter them. AFAIR the permissions on GitHub are pretty crappy, so I think it's not possible to give permissions to external collaborators to change labels on issues without giving it write permissions over the repository. In any case having templates for bugs and feature issues sounds like a good idea. And I love the option to not have to open an issue if I will immediately provide a PR with code, because this avoids duplicating the discussion in two places. Best, Gabriel On Mon, Oct 28, 2019 at 7:13 PM Myroslava Romaniuk via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Hi everyone > > Maybe it makes sense to generate some github issue templates and encourage > people to fill in the related information from a prompt? I think with bug > reports the situation is better, but for feature requests the state of > things could be very much improved by adding a template that goes: > "describe problem", "describe solution you'd like", "other alternatives", > "additional context". > > Because right now github issues are a mess. I get it that some projects > have particular maintainers and they know what the issues are and the > phrasing doesn't matter, ok, but a lot of the issues that don't have a tie > to any particular project and are labeled "easy" or "beginner" take a while > to understand because you have no idea what the person who created the > issue actually means. > > Just a suggestion, but i think there's really a lot of room to improve > with labels and templates for issues, and make them more accessible to > outsiders. > > Best, > Myroslava >

Oct. 29, 2019

Re: [Pharo-dev] make github issues clearer?

by Torsten Bergmann

Oct. 29, 2019

Re: [Pharo-dev] make github issues clearer?

by Marcus Denker

> On 29 Oct 2019, at 09:16, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Maybe this is possible with people with enough privilege to edit the issues in order to provide more details ? > > I try for the PolyMath project to have more elaborate labels: https://github.com/PolyMathOrg/PolyMath/labels <https://github.com/PolyMathOrg/PolyMath/labels> > with different status, priorities and types like describe here: > https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63 <https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63> > but you need people to tag correctly issues and labelling is more complex. > And I guess for Pharo, you will have to use a label to know what is the area of the system impact (like Compiler or UI). > for that the Kanban boards are nice: https://github.com/orgs/pharo-project/projects > More people are needed to the triage of issues and polish them for sure. The problem is that GitHub only allows people with *write* access to the repo to add labelsâ¦ or add issues to âprojectsâ. They suggest to put the issue tracker into itâs own repo and give everyone write access there: https://help.github.com/en/github/creating-cloning-and-archiving-repositori… Marcus

Oct. 29, 2019

Re: [Pharo-dev] make github issues clearer?

by Marcus Denker

> On 28 Oct 2019, at 23:22, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > +1 for improving the issues. > I call that the "checkbox attitude": > Opening an issue is mandatory for a change to be merged? > No problem, i open an issue (just a title), check the box, et voilÃ ... > It actually is not mandatory anymoreâ¦ and we should encourage people to just do PRs without opening an issue. (as the issue is really not useful in this case and tends to be empty). > That's applying the letter of the law rather than the spirit of the law. > Either the law is bad (too cumbersome for trivial changes?), or we are at degree zero of quality... > I also call that quality-dry: > It has the color of quality, the smell of quality, but it's not quality ;) > I have added the robot that complaints when people do not add a description. This seems to help a little, as it forces people to add some explanation. > > Le lun. 28 oct. 2019 Ã 23:12, Myroslava Romaniuk via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> a Ã©crit : > Hi everyone > > Maybe it makes sense to generate some github issue templates and encourage people to fill in the related information from a prompt? I think with bug reports the situation is better, but for feature requests the state of things could be very much improved by adding a template that goes: "describe problem", "describe solution you'd like", "other alternatives", "additional context". > > Because right now github issues are a mess. I get it that some projects have particular maintainers and they know what the issues are and the phrasing doesn't matter, ok, but a lot of the issues that don't have a tie to any particular project and are labeled "easy" or "beginner" take a while to understand because you have no idea what the person who created the issue actually means. > > Just a suggestion, but i think there's really a lot of room to improve with labels and templates for issues, and make them more accessible to outsiders. > > Best, > Myroslava

Oct. 29, 2019

Re: [Pharo-dev] Git URL issues

by Esteban Lorenzano

> On 29 Oct 2019, at 11:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Esteban, > > Thanks for the reply, I will test all this as soon as I can and report back. > > However, in your final script, are you sure the host (or port) can be specified (so no defaulting to GitHub.com) Indeed it Is not needed, but I recommend to do it :) > Also, I was reading the implementation (hard), and it seemed as if the only real solution would be to make a new type (scheme), for this case, like > > githttps://user1:passw1@server.company.com/scm/bla/foo-pharo.git And thatâs why we use another solution more generic. Otherwise we will need to add GitHubHTTPS, GitLabHTTPS, etc., etc. > > which would then preserve the username/password/host/port and do the proper thing directly. IIUC, https git URLs are described as the most common ones. > > It might be that there is then still a problem with branches/tags, but maybe they are not needed. > > Sven > >> On 29 Oct 2019, at 11:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi Sven, >> >> You are facing two different problems at the same time :) >> 1) a problem with Metacello api. There is a mismatch between git and metacello because the apis are not equivalent (specially having iceberg in the middle). >> If you want to use HTTPS in metacello you have to explicit you want to use HTTPS, but you still has to use the GitHub:// identifier. >> >> If you execute first: >> >> ./pharo build.image eval --save "Iceberg remoteTypeSelector: #httpsUrlâ >> >> Then your execution: >> >> ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp >> >> Will work without warnings. >> >> Now, you have another problem: >> 2) You cannot use an url as this with iceberg/metacello: https://deploy:secret@.../scm/xyz/xyz-pharo.git >> And yes, we could do a parse of it and use it (also solving your metacello command problem), but this is not easily doable and it would take time. >> The usual way of doing this is not using HTTPS but distributing public/private keys (then you use the regular SSH protocol). >> But if you still want/need to use HTTPS, then you need to provide your plaintext credentials. >> For iceberg, your credentials are stored in your preferences directory, at credentials.fuel (so you could add them to your CI server, if you have them). >> To add them programatically you need to do something like this: >> >> ./pharo build.image eval --save "IceCredentialStore current >> storeCredential: (IcePlaintextCredentials new >> username: 'esteban'; >> password: 'secret'; >> yourself) >> forHostname: âgithub.comâ" >> >> Then you full script will be like this: >> >> ./pharo build.image eval --save â >> Iceberg remoteTypeSelector: #httpsUrlâ. >> IceCredentialStore current >> storeCredential: (IcePlaintextCredentials new >> username: 'esteban'; >> password: 'secret'; >> yourself) >> forHostname: 'github.com' >> â >> ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp >> >> I hope this solves your problem :) >> >> Esteban >> >> On Mon, Oct 28, 2019 at 11:58 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> I am still at a loss with this issue. >> >> When loading from github://svenvc/ztimestamp using Metacello (see original mail) the code in MCGitBasedNetworkRepository>>#createIcebergRepositoryWithFallbackFor:url: clearly switches to using https://github.com/svenvc/ztimestamp.git - I traced it. >> >> So obviously, Pharo 7 is capable of accessing it. >> >> However, starting directly with https://github.com/svenvc/ztimestamp.git I end up in a totally different place. Why ? >> >> This code is so complex... >> >>> On 25 Oct 2019, at 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> I asked this before, but I still have trouble with this. >>> >>> What I ultimately want is what I used for years now: use the zero config tools to point to my private repo and install my code and all its dependencies from a single Metacello config. >>> >>> Basically, >>> >>> $vm $image config _CONFIG_REPO_ _CONFIG_NAME_ --username=_CONFIG_USER_ --password=_CONFIG_PASS_ --install=_CONFIG_VERSION_ --group=_CONFIG_GROUP_ >>> >>> towards a private server. >>> >>> In the new world of git(hub)/tonel/iceberg I am trying the following (not using the 'config' but the new 'metacello' command line handler): >>> >>> $ uname -a >>> Linux audio359 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux >>> >>> $ curl get.pharo.org/64/70+vm | bash >>> % Total % Received % Xferd Average Speed Time Time Time Current >>> Dload Upload Total Spent Left Speed >>> 100 3054 100 3054 0 0 57622 0 --:--:-- --:--:-- --:--:-- 57622 >>> Downloading the latest 70 Image: >>> http://files.pharo.org/get-files/70/pharo64.zip >>> Pharo.image >>> Downloading the latest pharoVM: >>> http://files.pharo.org/get-files/70/pharo64-linux-stable.zip >>> pharo-vm/pharo >>> Creating starter scripts pharo and pharo-ui >>> >>> $ ./pharo Pharo.image printVersion >>> [version] 'Pharo7.0.4' 'Pharo-7.0.4+build.168.sha.ccd1f6489120f58ddeacb2cac77cd3a0f0dcfbe6 (64 Bit)' >>> >>> $ ./pharo Pharo.image save build >>> >>> $ ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp >>> >>> 3. using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) I will try to clone the HTTPS variant. >>> Fetched -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] >>> Loaded -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] >>> Loading baseline of BaselineOfZTimestamp... >>> Fetched -> ZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] >>> Loaded -> ZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- cache >>> ...finished baseline >>> >>> $ ./pharo build.image eval ZTimestamp now >>> 2019-10-25T12:28:34Z >>> >>> So although it gave a warning, it worked fine. >>> >>> The warning said, >>> >>> using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) I will try to clone the HTTPS variant. >>> >>> so let's try that after cleaning everything: >>> >>> $ rm -rf pharo-local/ build.* >>> >>> $ ./pharo Pharo.image save build >>> >>> $ ./pharo build.image metacello install https://github.com/svenvc/ztimestamp.git BaselineOfZTimestamp >>> >>> ...RETRY->BaselineOfZTimestamp >>> ...RETRY->BaselineOfZTimestamp >>> ...FAILED->BaselineOfZTimestampCould not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in /home/sven/pharo7/pharo-local/package-cache https://github.com/svenvc/ztimestamp.git >>> MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: >>> >>> WTF ? Why does this not work (I can perfectly git clone that URL) ? >>> >>> Of course, this would just be the first step, eventually I want to use my own private server with a URL like >>> >>> https://deploy:secret@bitbucket.myserver.be/scm/xyz/xyz-pharo.git >>> >>> How do you build/deploy non-public production code using the command line ? >>> >>> Help would be much appreciated. >>> >>> Sven >>> >> >> > >

Oct. 29, 2019

Re: [Pharo-dev] Git URL issues

by Sven Van Caekenberghe

Hi Esteban, Thanks for the reply, I will test all this as soon as I can and report back. However, in your final script, are you sure the host (or port) can be specified (so no defaulting to GitHub.com) Also, I was reading the implementation (hard), and it seemed as if the only real solution would be to make a new type (scheme), for this case, like githttps://user1:passw1@server.company.com/scm/bla/foo-pharo.git which would then preserve the username/password/host/port and do the proper thing directly. IIUC, https git URLs are described as the most common ones. It might be that there is then still a problem with branches/tags, but maybe they are not needed. Sven > On 29 Oct 2019, at 11:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi Sven, > > You are facing two different problems at the same time :) > 1) a problem with Metacello api. There is a mismatch between git and metacello because the apis are not equivalent (specially having iceberg in the middle). > If you want to use HTTPS in metacello you have to explicit you want to use HTTPS, but you still has to use the GitHub:// identifier. > > If you execute first: > > ./pharo build.image eval --save "Iceberg remoteTypeSelector: #httpsUrlâ > > Then your execution: > > ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp > > Will work without warnings. > > Now, you have another problem: > 2) You cannot use an url as this with iceberg/metacello: https://deploy:secret@.../scm/xyz/xyz-pharo.git > And yes, we could do a parse of it and use it (also solving your metacello command problem), but this is not easily doable and it would take time. > The usual way of doing this is not using HTTPS but distributing public/private keys (then you use the regular SSH protocol). > But if you still want/need to use HTTPS, then you need to provide your plaintext credentials. > For iceberg, your credentials are stored in your preferences directory, at credentials.fuel (so you could add them to your CI server, if you have them). > To add them programatically you need to do something like this: > > ./pharo build.image eval --save "IceCredentialStore current > storeCredential: (IcePlaintextCredentials new > username: 'esteban'; > password: 'secret'; > yourself) > forHostname: âgithub.comâ" > > Then you full script will be like this: > > ./pharo build.image eval --save â > Iceberg remoteTypeSelector: #httpsUrlâ. > IceCredentialStore current > storeCredential: (IcePlaintextCredentials new > username: 'esteban'; > password: 'secret'; > yourself) > forHostname: 'github.com' > â > ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp > > I hope this solves your problem :) > > Esteban > > On Mon, Oct 28, 2019 at 11:58 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am still at a loss with this issue. > > When loading from github://svenvc/ztimestamp using Metacello (see original mail) the code in MCGitBasedNetworkRepository>>#createIcebergRepositoryWithFallbackFor:url: clearly switches to using https://github.com/svenvc/ztimestamp.git - I traced it. > > So obviously, Pharo 7 is capable of accessing it. > > However, starting directly with https://github.com/svenvc/ztimestamp.git I end up in a totally different place. Why ? > > This code is so complex... > > > On 25 Oct 2019, at 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > I asked this before, but I still have trouble with this. > > > > What I ultimately want is what I used for years now: use the zero config tools to point to my private repo and install my code and all its dependencies from a single Metacello config. > > > > Basically, > > > > $vm $image config _CONFIG_REPO_ _CONFIG_NAME_ --username=_CONFIG_USER_ --password=_CONFIG_PASS_ --install=_CONFIG_VERSION_ --group=_CONFIG_GROUP_ > > > > towards a private server. > > > > In the new world of git(hub)/tonel/iceberg I am trying the following (not using the 'config' but the new 'metacello' command line handler): > > > > $ uname -a > > Linux audio359 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > > > $ curl get.pharo.org/64/70+vm | bash > > % Total % Received % Xferd Average Speed Time Time Time Current > > Dload Upload Total Spent Left Speed > > 100 3054 100 3054 0 0 57622 0 --:--:-- --:--:-- --:--:-- 57622 > > Downloading the latest 70 Image: > > http://files.pharo.org/get-files/70/pharo64.zip > > Pharo.image > > Downloading the latest pharoVM: > > http://files.pharo.org/get-files/70/pharo64-linux-stable.zip > > pharo-vm/pharo > > Creating starter scripts pharo and pharo-ui > > > > $ ./pharo Pharo.image printVersion > > [version] 'Pharo7.0.4' 'Pharo-7.0.4+build.168.sha.ccd1f6489120f58ddeacb2cac77cd3a0f0dcfbe6 (64 Bit)' > > > > $ ./pharo Pharo.image save build > > > > $ ./pharo build.image metacello install github://svenvc/ztimestamp BaselineOfZTimestamp > > > > 3. using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) I will try to clone the HTTPS variant. > > Fetched -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] > > Loaded -> BaselineOfZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] > > Loading baseline of BaselineOfZTimestamp... > > Fetched -> ZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- https://github.com/svenvc/ztimestamp.git[master] > > Loaded -> ZTimestamp-CompatibleUserName.1554735117 --- https://github.com/svenvc/ztimestamp.git[master] --- cache > > ...finished baseline > > > > $ ./pharo build.image eval ZTimestamp now > > 2019-10-25T12:28:34Z > > > > So although it gave a warning, it worked fine. > > > > The warning said, > > > > using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git) I will try to clone the HTTPS variant. > > > > so let's try that after cleaning everything: > > > > $ rm -rf pharo-local/ build.* > > > > $ ./pharo Pharo.image save build > > > > $ ./pharo build.image metacello install https://github.com/svenvc/ztimestamp.git BaselineOfZTimestamp > > > > ...RETRY->BaselineOfZTimestamp > > ...RETRY->BaselineOfZTimestamp > > ...FAILED->BaselineOfZTimestampCould not resolve: BaselineOfZTimestamp [BaselineOfZTimestamp] in /home/sven/pharo7/pharo-local/package-cache https://github.com/svenvc/ztimestamp.git > > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: > > > > WTF ? Why does this not work (I can perfectly git clone that URL) ? > > > > Of course, this would just be the first step, eventually I want to use my own private server with a URL like > > > > https://deploy:secret@bitbucket.myserver.be/scm/xyz/xyz-pharo.git > > > > How do you build/deploy non-public production code using the command line ? > > > > Help would be much appreciated. > > > > Sven > > > >

Oct. 29, 2019