Status of OpenGL in Arch Haskell?

gdweber＠iue.edu

10 Jul 2012 10 Jul '12

4:11 p.m.

"hoko" requested adding the OpenGL package and others in issue #73 on archhaskell/habs. I made a pull request (issue #82) two weeks ago which would add OpenGL and related packages. I'm puzzled by the lack of response (no comments or other action). Does it mean: - The addition of OpenGL is unwelcome? - My commits need improvement before they can be pulled? Please tell me how.* - The habs maintainers are very busy? If this is the case, I'm sorry to be a pest. I'm a little nervous about its being "closed due to age" like #52. *From somewhere I have the impression that I should "rebase" my branch onto master, maybe something like this: $ git checkout master $ git pull upstream # upstream is archhaskell/habs $ git push myfork master # myfork is gdweber/habs $ git checkout opengl # opengl is my topic branch $ git rebase master $ git push myfork opengl But there is a very stern warning, "Do not rebase commits that you have pushed to a public repository" from the Pro Git book, http://git-scm.com/book/en/Git-Branching-Rebasing so I'm hesitant to do that without explicit instructions. I'm very inexperienced with git. -- 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 []

Show replies by date

Magnus Therning

11 Jul 11 Jul

3:08 a.m.

On Tue, Jul 10, 2012 at 10:11 PM, wrote:

...

"hoko" requested adding the OpenGL package and others in issue #73 on archhaskell/habs.

I made a pull request (issue #82) two weeks ago which would add OpenGL and related packages.

I'm puzzled by the lack of response (no comments or other action). Does it mean: - The addition of OpenGL is unwelcome? - My commits need improvement before they can be pulled? Please tell me how.* - The habs maintainers are very busy? If this is the case, I'm sorry to be a pest. I'm a little nervous about its being "closed due to age" like #52.

*From somewhere I have the impression that I should "rebase" my branch onto master, maybe something like this:

$ git checkout master $ git pull upstream # upstream is archhaskell/habs $ git push myfork master # myfork is gdweber/habs

$ git checkout opengl # opengl is my topic branch $ git rebase master $ git push myfork opengl

But there is a very stern warning, "Do not rebase commits that you have pushed to a public repository" from the Pro Git book,

http://git-scm.com/book/en/Git-Branching-Rebasing

so I'm hesitant to do that without explicit instructions. I'm very inexperienced with git.

It's mostly due to inactivity by me. If you were to do the following: 1. rebase on archhaskell/master 2. build for both i686 and x86_64 3. upload the built packages to a place where I can get them all before I make the next set of updates (will most likely not happen until the weekend), then you have minimised my work and maximised your chances of getting your work pulled. ## On working with git My policy on rebasing in git: never rebase any published branch that others are supposed to base their work on. That means I never rebase `master` or any hotfix branch. My development branches on the other hand I rebase as I like, and sometimes I publish them in order to easily work on them from different computers. ## On working with git in archhaskell The `cblrepo.db` file isn't very well suited for version control as it is managed by `cblrepo` at the moment. I think that a simple alphabetic sort on the file would improve the situation, but I haven't added that to the tool yet. In practice this means that at the moment pull requests are of limited value since rebasing a changeset that touches `cblrepo.db` is more work than using `cblrepo` to add the packages 'manually'. Also, modifying the git repo is the minor part of adding or updating a package. What takes time is building the affected packages for both supported platforms. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

gdweber＠iue.edu

11:41 a.m.

On 2012-Jul-11, Magnus Therning wrote:

...

On Tue, Jul 10, 2012 at 10:11 PM, wrote:

...
"hoko" requested adding the OpenGL package and others in issue #73 on archhaskell/habs.

I made a pull request (issue #82) two weeks ago which would add OpenGL and related packages.

I'm puzzled by the lack of response (no comments or other action). Does it mean: - The addition of OpenGL is unwelcome? - My commits need improvement before they can be pulled? Please tell me how.* - The habs maintainers are very busy? If this is the case, I'm sorry to be a pest. I'm a little nervous about its being "closed due to age" like #52.

*From somewhere I have the impression that I should "rebase" my branch onto master, maybe something like this:

$ git checkout master $ git pull upstream # upstream is archhaskell/habs $ git push myfork master # myfork is gdweber/habs

$ git checkout opengl # opengl is my topic branch $ git rebase master $ git push myfork opengl

But there is a very stern warning, "Do not rebase commits that you have pushed to a public repository" from the Pro Git book,

http://git-scm.com/book/en/Git-Branching-Rebasing

so I'm hesitant to do that without explicit instructions. I'm very inexperienced with git.

It's mostly due to inactivity by me.

If you were to do the following:

1. rebase on archhaskell/master

I will give this a try.

...

2. build for both i686 and x86_64

I can do this for x86_64, but I do not have access to any i686 with Arch Linux, so as far as I know, I can't build packages for i686.

...

3. upload the built packages to a place where I can get them

I think I can find such a place.

...

all before I make the next set of updates (will most likely not happen until the weekend), then you have minimised my work and maximised your chances of getting your work pulled.

## On working with git My policy on rebasing in git: never rebase any published branch that others are supposed to base their work on. That means I never rebase `master` or any hotfix branch. My development branches on the other hand I rebase as I like, and sometimes I publish them in order to easily work on them from different computers.

## On working with git in archhaskell The `cblrepo.db` file isn't very well suited for version control as it is managed by `cblrepo` at the moment.

I agree.

...

I think that a simple alphabetic sort on the file would improve the situation, but I haven't added that to the tool yet. In practice this means that at the moment pull requests are of limited value since rebasing a changeset that touches `cblrepo.db` is more work than using `cblrepo` to add the packages 'manually'. Also, modifying the git repo is the minor part of adding or updating a package. What takes time is building the affected packages for both supported platforms.

Oh, I see! So you don't really want pull requests, but built packages. Would it be better for me to just email you, when I have packages to contribute, or open an issue, instead of a pull request?

...

/M

Thanks for the instructions and clarifications. Greg

...

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

_______________________________________________ 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 []

Magnus Therning

2:20 p.m.

On Wed, Jul 11, 2012 at 11:41:07AM -0400, gdweber@iue.edu wrote:

...

On 2012-Jul-11, Magnus Therning wrote: [...]

...
2. build for both i686 and x86_64

I can do this for x86_64, but I do not have access to any i686 with Arch Linux, so as far as I know, I can't build packages for i686.

Ah, but that's the beauty of it. Just use the makeahpkg script and pass in '-a i686' and you're golden :)

...

...
3. upload the built packages to a place where I can get them

I think I can find such a place.

Good.

...

...
I think that a simple alphabetic sort on the file would improve the situation, but I haven't added that to the tool yet. In practice this means that at the moment pull requests are of limited value since rebasing a changeset that touches `cblrepo.db` is more work than using `cblrepo` to add the packages 'manually'. Also, modifying the git repo is the minor part of adding or updating a package. What takes time is building the affected packages for both supported platforms.

Oh, I see! So you don't really want pull requests, but built packages. Would it be better for me to just email you, when I have packages to contribute, or open an issue, instead of a pull request?

Yeah, though if the packages need any patches then I'd appreciate them too so I can rebuild later on :-)

...

Thanks for the instructions and clarifications.

Hopefully they were clear and simple. Git is a beast, and my not so humble opinion is that it still is rather far from being ready for use ;-) What rocks with git though, is github! /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

gdweber＠iue.edu

5:45 p.m.

On 2012-Jul-11, Magnus Therning wrote:

...

On Wed, Jul 11, 2012 at 11:41:07AM -0400, gdweber@iue.edu wrote:

...
On 2012-Jul-11, Magnus Therning wrote: [...]

...
2. build for both i686 and x86_64

I can do this for x86_64, but I do not have access to any i686 with Arch Linux, so as far as I know, I can't build packages for i686.

Ah, but that's the beauty of it. Just use the makeahpkg script and pass in '-a i686' and you're golden :)

I am amazed! I had no idea that I could put a little Linux installation *for a different architecture* in a chroot. Okay, doing this now. It is even smart enough to install the external libraries, like libgl, needed for the package automatically.

...

...
...
3. upload the built packages to a place where I can get them

I think I can find such a place.

Good.

...
...
I think that a simple alphabetic sort on the file would improve the situation, but I haven't added that to the tool yet. In practice this means that at the moment pull requests are of limited value since rebasing a changeset that touches `cblrepo.db` is more work than using `cblrepo` to add the packages 'manually'. Also, modifying the git repo is the minor part of adding or updating a package. What takes time is building the affected packages for both supported platforms.

Oh, I see! So you don't really want pull requests, but built packages. Would it be better for me to just email you, when I have packages to contribute, or open an issue, instead of a pull request?

Yeah, though if the packages need any patches then I'd appreciate them too so I can rebuild later on :-)

...
Thanks for the instructions and clarifications.

Hopefully they were clear and simple. Git is a beast, and my not so humble opinion is that it still is rather far from being ready for use ;-) What rocks with git though, is github!

I have an unusual need for clarity, and I think they were reasonably clear. Glad I am not alone in my feelings about Git. I guess the reason we are using git instead of darcs, is the absence of a suitable darcshub?

...

/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 []

4696

Age (days ago)

4697

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

gdweber＠iue.edu
Magnus Therning