Re: Problems with `arc` and `phabricator`

[Ben Gamari]

Iavor Diatchki  writes:

> Ah good, that worked.  I've pushed before, I wonder what happened to my key?
>
It's quite possible you never had one. A key has only been mandatory for
uploads for a few months now.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Problems with `arc` and `phabricator`

[Iavor Diatchki]

Ah good, that worked.  I've pushed before, I wonder what happened to my key?

On Thu, Jan 26, 2017 at 1:39 PM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Hello Iavor,
>
> You need to upload you ssh key to phabricator.
>
> You can do it here,
>
> https://phabricator.haskell.org/settings/user/yav/page/ssh/
>
> If you need any more help with phab then feel free to ping me on IRC
> or by email.
>
> Matt
>
>
> On Thu, Jan 26, 2017 at 9:35 PM, Iavor Diatchki
>  wrote:
> > Hello,
> >
> > I just fixed a small bug in GHC (#11406) and I'm trying to push the
> change
> > to `phabricator` for review, but the command is failing.  Here is my
> output,
> > could you please advise on what to do?
> >
> >> arc diff
> > Linting...
> >  LINT OKAY  No lint problems.
> > Running unit tests...
> > No unit test engine is configured for this project.
> >  PUSH STAGING  Pushing changes to staging area...
> > Permission denied (publickey,keyboard-interactive).
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights
> > and the repository exists.
> >  STAGING FAILED  Unable to push changes to the staging area.
> > Usage Exception: Failed to push changes to staging area. Correct the
> issue,
> > or use --skip-staging to skip this step.
> >
> > Clearly, there is some sort of permission issue...
> >
> > -Iavor
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Problems with `arc` and `phabricator`

[Matthew Pickering]

Hello Iavor,

You need to upload you ssh key to phabricator.

You can do it here,

https://phabricator.haskell.org/settings/user/yav/page/ssh/

If you need any more help with phab then feel free to ping me on IRC
or by email.

Matt


On Thu, Jan 26, 2017 at 9:35 PM, Iavor Diatchki
 wrote:
> Hello,
>
> I just fixed a small bug in GHC (#11406) and I'm trying to push the change
> to `phabricator` for review, but the command is failing.  Here is my output,
> could you please advise on what to do?
>
>> arc diff
> Linting...
>  LINT OKAY  No lint problems.
> Running unit tests...
> No unit test engine is configured for this project.
>  PUSH STAGING  Pushing changes to staging area...
> Permission denied (publickey,keyboard-interactive).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>  STAGING FAILED  Unable to push changes to the staging area.
> Usage Exception: Failed to push changes to staging area. Correct the issue,
> or use --skip-staging to skip this step.
>
> Clearly, there is some sort of permission issue...
>
> -Iavor
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Problems with `arc` and `phabricator`

[Iavor Diatchki]

Hello,

I just fixed a small bug in GHC (#11406) and I'm trying to push the change
to `phabricator` for review, but the command is failing.  Here is my
output, could you please advise on what to do?

> arc diff
Linting...
 LINT OKAY  No lint problems.
Running unit tests...
No unit test engine is configured for this project.
 PUSH STAGING  Pushing changes to staging area...
Permission denied (publickey,keyboard-interactive).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
 STAGING FAILED  Unable to push changes to the staging area.
Usage Exception: Failed to push changes to staging area. Correct the issue,
or use --skip-staging to skip this step.

Clearly, there is some sort of permission issue...

-Iavor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot build GHC using the Newcomers guide

[Alan & Kim Zimmerman]

FWIW, I use the docker image, as per
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#Docker,
where I have the invocation in a one-line script

Alan

On 26 January 2017 at 19:38, Phyx  wrote:

> But do you really want to do this?
>
> It seems to me you don't want to keep using your stage0 while working on
> ghc. As you don't want to break it and spend hours wondering why your build
> failed.
>
> Fair enough, if people want to do this. So long as it's not the defacto
> method.
>
> On Thu, 26 Jan 2017, 17:28 Matthew Pickering, 
> wrote:
>
>> I think the intention is that if you are already using stack to manage
>> your GHC installations then it is desirable to use their managed
>> version of GHC rather than have to install another version.
>>
>> It seems to me that the solution that Harendra suggests is the easiest
>> for anyone with this setup.
>>
>> Fwiw, the easiest way I found to setup a clean development environment
>> for GHC was to use the nix ghcHEAD derviation.
>>
>>nix-shell '' -A haskell.compiler.ghcHEAD
>>
>> but of course, this only works if you are using nix!
>>
>> Matt
>>
>> On Thu, Jan 26, 2017 at 5:18 PM, Phyx  wrote:
>> > Can I ask a silly question. I can't seem to find where stack is
>> recommended
>> > for ghc development on the newcomers page, but why is it? I don't want
>> to
>> > start another flame war but I can't imagine any scenario where this is
>> > useful. As far as I understand the whole benefit of stack is the curated
>> > packages.
>> >
>> > Which are moot here since almost everything you need is in the tree
>> aside
>> > from Happy and Alex. Seems to me this is just overcomplicating a very
>> simple
>> > process.
>> >
>> > Not to mention if you have to go through stack - - exec etc all for
>> > interactions with the build artifacts it would get old quickly. Also it
>> > doesn't seem reliable especially if stack is modifying the environment
>> and
>> > or flags passed to the compiler.
>> >
>> > Let me reiterate, I have nothing against stack, I just don't see the
>> > benefits here. Ideally you'd want your environment as simple and
>> vanilla as
>> > possible and *totally* in your control IMHO.
>> >
>> > What am I missing here?
>> >
>> > Thanks,
>> > Tamar
>> >
>> >
>> > On Thu, 26 Jan 2017, 14:21 Harendra Kumar, 
>> wrote:
>> >>
>> >> I use "export PATH=`stack path --bin-path`" to make the stack installed
>> >> ghc available in the PATH before building ghc. And that's all.
>> >>
>> >> Setting the PATH works better because we do not get any extra env
>> >> variables set by stack in the environment and we do not go through the
>> stack
>> >> wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH
>> >> variable set by the stack command is especially troublesome in some
>> cases.
>> >> You can try "stack exec env" to check all vars that stack puts in your
>> >> environment.
>> >>
>> >> -harendra
>> >>
>> >> On 26 January 2017 at 15:52, Marius Ghita  wrote:
>> >>>
>> >>> Following is a list of steps that I ran and their output linked:
>> >>>
>> >>>  - clone repo
>> >>> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b
>> >>>  - build.mk configuration
>> >>> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675
>> >>>  - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf
>> 3f
>> >>>  - configure
>> >>> https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
>> >>>  - make FAILS
>> >>> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c
>> >>>
>> >>> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run
>> >>> ghc from stack (since I don't have a globally installed ghc) (source
>> >>> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ),
>> and I
>> >>> also have 'ghc-pkg' wrapped in the same way with
>> >>> a stack-ghc-pkg script (source
>> >>> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )
>> >>>
>> >>> --
>> >>> Google+: https://plus.google.com/111881868112036203454
>> >>>
>> >>> ___
>> >>> ghc-devs mailing list
>> >>> ghc-devs@haskell.org
>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>>
>> >>
>> >> ___
>> >> ghc-devs mailing list
>> >> ghc-devs@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot build GHC using the Newcomers guide

[Phyx]

But do you really want to do this?

It seems to me you don't want to keep using your stage0 while working on
ghc. As you don't want to break it and spend hours wondering why your build
failed.

Fair enough, if people want to do this. So long as it's not the defacto
method.

On Thu, 26 Jan 2017, 17:28 Matthew Pickering, 
wrote:

> I think the intention is that if you are already using stack to manage
> your GHC installations then it is desirable to use their managed
> version of GHC rather than have to install another version.
>
> It seems to me that the solution that Harendra suggests is the easiest
> for anyone with this setup.
>
> Fwiw, the easiest way I found to setup a clean development environment
> for GHC was to use the nix ghcHEAD derviation.
>
>nix-shell '' -A haskell.compiler.ghcHEAD
>
> but of course, this only works if you are using nix!
>
> Matt
>
> On Thu, Jan 26, 2017 at 5:18 PM, Phyx  wrote:
> > Can I ask a silly question. I can't seem to find where stack is
> recommended
> > for ghc development on the newcomers page, but why is it? I don't want to
> > start another flame war but I can't imagine any scenario where this is
> > useful. As far as I understand the whole benefit of stack is the curated
> > packages.
> >
> > Which are moot here since almost everything you need is in the tree aside
> > from Happy and Alex. Seems to me this is just overcomplicating a very
> simple
> > process.
> >
> > Not to mention if you have to go through stack - - exec etc all for
> > interactions with the build artifacts it would get old quickly. Also it
> > doesn't seem reliable especially if stack is modifying the environment
> and
> > or flags passed to the compiler.
> >
> > Let me reiterate, I have nothing against stack, I just don't see the
> > benefits here. Ideally you'd want your environment as simple and vanilla
> as
> > possible and *totally* in your control IMHO.
> >
> > What am I missing here?
> >
> > Thanks,
> > Tamar
> >
> >
> > On Thu, 26 Jan 2017, 14:21 Harendra Kumar, 
> wrote:
> >>
> >> I use "export PATH=`stack path --bin-path`" to make the stack installed
> >> ghc available in the PATH before building ghc. And that's all.
> >>
> >> Setting the PATH works better because we do not get any extra env
> >> variables set by stack in the environment and we do not go through the
> stack
> >> wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH
> >> variable set by the stack command is especially troublesome in some
> cases.
> >> You can try "stack exec env" to check all vars that stack puts in your
> >> environment.
> >>
> >> -harendra
> >>
> >> On 26 January 2017 at 15:52, Marius Ghita  wrote:
> >>>
> >>> Following is a list of steps that I ran and their output linked:
> >>>
> >>>  - clone repo
> >>> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b
> >>>  - build.mk configuration
> >>> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675
> >>>  - boot
> https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f
> >>>  - configure
> >>> https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
> >>>  - make FAILS
> >>> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c
> >>>
> >>> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run
> >>> ghc from stack (since I don't have a globally installed ghc) (source
> >>> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ),
> and I
> >>> also have 'ghc-pkg' wrapped in the same way with
> >>> a stack-ghc-pkg script (source
> >>> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )
> >>>
> >>> --
> >>> Google+: https://plus.google.com/111881868112036203454
> >>>
> >>> ___
> >>> ghc-devs mailing list
> >>> ghc-devs@haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>>
> >>
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot build GHC using the Newcomers guide

[Matthew Pickering]

I think the intention is that if you are already using stack to manage
your GHC installations then it is desirable to use their managed
version of GHC rather than have to install another version.

It seems to me that the solution that Harendra suggests is the easiest
for anyone with this setup.

Fwiw, the easiest way I found to setup a clean development environment
for GHC was to use the nix ghcHEAD derviation.

   nix-shell '' -A haskell.compiler.ghcHEAD

but of course, this only works if you are using nix!

Matt

On Thu, Jan 26, 2017 at 5:18 PM, Phyx  wrote:
> Can I ask a silly question. I can't seem to find where stack is recommended
> for ghc development on the newcomers page, but why is it? I don't want to
> start another flame war but I can't imagine any scenario where this is
> useful. As far as I understand the whole benefit of stack is the curated
> packages.
>
> Which are moot here since almost everything you need is in the tree aside
> from Happy and Alex. Seems to me this is just overcomplicating a very simple
> process.
>
> Not to mention if you have to go through stack - - exec etc all for
> interactions with the build artifacts it would get old quickly. Also it
> doesn't seem reliable especially if stack is modifying the environment and
> or flags passed to the compiler.
>
> Let me reiterate, I have nothing against stack, I just don't see the
> benefits here. Ideally you'd want your environment as simple and vanilla as
> possible and *totally* in your control IMHO.
>
> What am I missing here?
>
> Thanks,
> Tamar
>
>
> On Thu, 26 Jan 2017, 14:21 Harendra Kumar,  wrote:
>>
>> I use "export PATH=`stack path --bin-path`" to make the stack installed
>> ghc available in the PATH before building ghc. And that's all.
>>
>> Setting the PATH works better because we do not get any extra env
>> variables set by stack in the environment and we do not go through the stack
>> wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH
>> variable set by the stack command is especially troublesome in some cases.
>> You can try "stack exec env" to check all vars that stack puts in your
>> environment.
>>
>> -harendra
>>
>> On 26 January 2017 at 15:52, Marius Ghita  wrote:
>>>
>>> Following is a list of steps that I ran and their output linked:
>>>
>>>  - clone repo
>>> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b
>>>  - build.mk configuration
>>> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675
>>>  - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f
>>>  - configure
>>> https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
>>>  - make FAILS
>>> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c
>>>
>>> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run
>>> ghc from stack (since I don't have a globally installed ghc) (source
>>> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I
>>> also have 'ghc-pkg' wrapped in the same way with
>>> a stack-ghc-pkg script (source
>>> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )
>>>
>>> --
>>> Google+: https://plus.google.com/111881868112036203454
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot build GHC using the Newcomers guide

[Phyx]

Can I ask a silly question. I can't seem to find where stack is recommended
for ghc development on the newcomers page, but why is it? I don't want to
start another flame war but I can't imagine any scenario where this is
useful. As far as I understand the whole benefit of stack is the curated
packages.

Which are moot here since almost everything you need is in the tree aside
from Happy and Alex. Seems to me this is just overcomplicating a very
simple process.

Not to mention if you have to go through stack - - exec etc all for
interactions with the build artifacts it would get old quickly. Also it
doesn't seem reliable especially if stack is modifying the environment and
or flags passed to the compiler.

Let me reiterate, I have nothing against stack, I just don't see the
benefits here. Ideally you'd want your environment as simple and vanilla as
possible and *totally* in your control IMHO.

What am I missing here?

Thanks,
Tamar

On Thu, 26 Jan 2017, 14:21 Harendra Kumar,  wrote:

> I use "export PATH=`stack path --bin-path`" to make the stack installed
> ghc available in the PATH before building ghc. And that's all.
>
> Setting the PATH works better because we do not get any extra env
> variables set by stack in the environment and we do not go through the
> stack wrapper, so it may be a little bit faster as well. The
> GHC_PACKAGE_PATH variable set by the stack command is especially
> troublesome in some cases. You can try "stack exec env" to check all vars
> that stack puts in your environment.
>
> -harendra
>
> On 26 January 2017 at 15:52, Marius Ghita  wrote:
>
> Following is a list of steps that I ran and their output linked:
>
>  - clone repo
> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b
>  - build.mk configuration
> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675
>  - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f
>  - configure
> https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
>  - make FAILS
> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c
>
> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc
> from stack (since I don't have a globally installed ghc) (source
> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I
> also have 'ghc-pkg' wrapped in the same way with
> a stack-ghc-pkg script (source
> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )
>
> --
> Google+: https://plus.google.com/111881868112036203454
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot build GHC using the Newcomers guide

[Matthew Pickering]

Can you try with the "--no-ghc-package-path" option in your wrapper?

Matt


On Thu, Jan 26, 2017 at 10:22 AM, Marius Ghita  wrote:
> Following is a list of steps that I ran and their output linked:
>
>  - clone repo
> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b
>  - build.mk configuration
> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675
>  - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f
>  - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
>  - make FAILS
> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c
>
> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc
> from stack (since I don't have a globally installed ghc) (source
> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I
> also have 'ghc-pkg' wrapped in the same way with
> a stack-ghc-pkg script (source
> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )
>
> --
> Google+: https://plus.google.com/111881868112036203454
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Cannot build GHC using the Newcomers guide

[Marius Ghita]

Following is a list of steps that I ran and their output linked:

 - clone repo https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad62
0b
 - build.mk configuration https://gist.github.com/mhitza/
2d979c64a646bdd3e097f65fd650c675
 - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf3f
 - configure https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
 - make FAILS https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a
2c

I'm using a 'stack-ghc' executable, that's only a shell wrapper to run ghc
from stack (since I don't have a globally installed ghc) (source
https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), and I
also have 'ghc-pkg' wrapped in the same way with
a stack-ghc-pkg script (source https://gist.github.com/mhitza/
6c2b1978ef802707161041abe1d2699e )

-- 
Google+: https://plus.google.com/111881868112036203454
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs