Thanks for this advice and also Magnus's. I've made some progress, and have made a pull request to archhaskell/habs -- my first contribution to the project! But since then I've pulled from archhaskell/habs and have conflicts in cblrepo.db. What is the best thing to do here -- should I try to resolve the conflicts on my end (and make another pull request?) or will Magnus resolve the conflicts (assuming he accepts my pull request) and I fetch them later? Also, I've noticed that most pull requests are from master to master. Is this the best way, or is it preferred to make a branch for any set of packages that we want to contribute? On 2012-Jun-19, Alessandro Pezzoni wrote:

On Mon, Jun 18, 2012 at 08:49:55PM -0400, gdweber@iue.edu wrote:

...

I thought I'd give cblrepo a try, and followed the instructions from https://github.com/archhaskell/habs#readme

--but got a bunch of error messages:

$ git clone git://github.com/archhaskell/habs.git Cloning into 'habs'... remote: Counting objects: 28074, done. remote: Compressing objects: 100% (10477/10477), done. remote: Total 28074 (delta 16611), reused 27981 (delta 16526) Receiving objects: 100% (28074/28074), 3.40 MiB | 170 KiB/s, done. Resolving deltas: 100% (16611/16611), done. $ cd habs $ cblrepo sync $ cblrepo pkgbuild $(cblrepo build base|tail -n +2) [...]

Should this prevent me from going further and adding other packages that I want to build that are not in the [haskell] repo?

Do I need to make the PKGBUILD files (and their directories) for all of the packages in the repo before adding my own?

Do I need to actually _build_ the packages that are not my own (in the sense of making the Arch Linux packages that pacman can use, with makeahpkg)? I certainly hope not!

To add some packages not in [haskell] you don't really need to make all the PKGBUILD files, let alone build them (although what you posted mean that we need to update those patches). What you need to do is: $ git clone git://github.com/archhaskell/habs.git $ cd habs $ cblrepo sync $ cblrepo add NAME,VER ... $ cblrepo pkgbuild NAME ... $ ./ghc/helpers/adjust-ghc.sh */PKGBUILD

where NAME is the name of each package not in [haskell] you want to add and VER is it's version number (as on hackage). The last step is a temporary fix to set the correct ghc version number in the dependencies array. Then for each of those packages: $ cd haskell-NAME $ makepkg

If the build fails you should edit the PKGBUILD and submit a patch... or just make a package request.

Hope this helps, Alessandro

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

-- Gregory D. Weber, Ph. D. : Associate Professor of Informatics / \ Indiana University East 0 : Tel. (765) 973-8420; FAX (765) 973-8550 / \ http://mypage.iu.edu/~gdweber/ 1 []

On 2012-Jun-25, Magnus Therning wrote:

On Mon, Jun 25, 2012 at 12:29:26PM -0400, gdweber@iue.edu wrote:

...

Thanks for this advice and also Magnus's.

I've made some progress, and have made a pull request to archhaskell/habs -- my first contribution to the project!

But since then I've pulled from archhaskell/habs and have conflicts in cblrepo.db. What is the best thing to do here -- should I try to resolve the conflicts on my end (and make another pull request?) or will Magnus resolve the conflicts (assuming he accepts my pull request) and I fetch them later?

It's always best to make sure your changes are rebased onto habs/master, that makes it trivial to pull them.

Always, or usually? I think I understand how this would usually be helpful, but not always, and not in the current case. My understanding of "rebase" is not as clear as I would like, but it seems to me that the two main uses are (1) to collapse a series of commits into a single commit, and (2) to convert a series of committed snapshots, beginning at A and culminating in C, into a series of patches (differences), move backward (or maybe forward) to some other commit B in the history, and "replay" or apply the patches from there, resulting in a new snapshot C' which can then be easily merged in to succeed B. (1) does not apply in this case, because I made only a single commit. (2) could have been helpful if commits were made in habs/master (meaning, I think, archhaskell/habs master) between the time of my fork and the time of my pull request, but if I read the network graph correctly, the commits in archhaskell/habs were made after my pull request. Consequently, if I had done a rebase at the time, C' would have been identical with C. Do I understand this correctly?

...

Also, I've noticed that most pull requests are from master to master. Is this the best way, or is it preferred to make a branch for any set of packages that we want to contribute?

Personally I think this stems from peoples' inexperience with git. It's definitely preferred to make a separate branch for your changes and create a pull request from it. Then use the master branch only to track habs/master.

Yes, I also began to think this as I continued reading about git in the meantime. Coming from darcs to git, it was a surprise to learn that my repo, forked and cloned from archhaskell/habs, was not already a "separate branch". I will follow the practice of making a topic branch in the future. In fact, I think I'll just start over and do it right. I'll lose some work, but not much.

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell

-- Gregory D. Weber, Ph. D. : Associate Professor of Informatics / \ Indiana University East 0 : Tel. (765) 973-8420; FAX (765) 973-8550 / \ http://mypage.iu.edu/~gdweber/ 1 []