git revert inside a -9999 package sources?

[M95D]

Hi.

I'm testing Xlibre. The package is one of those a -9999 packages that clone a git repo and then compile from the master branch and installs it.

1) I found a bug and I wish to revert a commit. What's the easiest way to do that?

2) How about a git bisect? Can I automate a git bisect that runs emerge and a simple bash test command?

I prefer emerge instead of building and installing manually because there is no alternative (that I know of) for "emerge --unmerge" when installing with "make install".

Thanks.

[CaptainBlood]

I recall having successfully set patches as in /etc/portage/patches for 9999 packages.
Maybe this could help?

Thks 4 ur attention, interest & support.

[logrusx]

I recall having successfully set patches as in /etc/portage/patches for 9999 packages.
Maybe this could help?

Thks 4 ur attention, interest & support.

That's the way to go. You could define EGIT_COMMIT on the command line but that would give you a checkout at that commit, not revert it. If you're OK with syncing the previous commit, you can use it though.

Best Regards,
Georgi

[CaptainBlood]

As logrusx says, EGIT_COMMIT variable can help you to prevent building up to the latest commit, but the one you defined in the variable instead.
Copying the 9999 package to local repository should really help to do so. Once done patch ebuild like

Code: Select all

EGIT_REPO_URI="https://github.com/X11Libre/xserver.git"
EGIT_COMMIT=4d5e5558ba2002847febfd6ff62e5656e50abf2f

Set the commit value accordingly.

/etc/portage/patches can now contain the patche(s) you wish to apply atop.

Thks 4 ur attention, interest & support.

[M95D]

I know about patches.

So there is no way to somehow do a git revert inside distfiles/git3-src/<package>.git and have portage use the checked out branch as it is?

[logrusx]

I know about patches.

So there is no way to somehow do a git revert inside distfiles/git3-src/<package>.git and have portage use the checked out branch as it is?

Maybe you could ammend src_prepare but to me that looks like going to great lengths just to make it that way.

Best Regards,
Georgi

[szatox]

I know about patches.

So there is no way to somehow do a git revert inside distfiles/git3-src/<package>.git and have portage use the checked out branch as it is?

This is just "patches" with extra steps.

Besides, reverting whatever commit is in your way doesn't really mean anything unless you upstream it. Emerge is in no position to do that.

[SCR4MBL3]

I prefer emerge instead of building and installing manually because there is no alternative (that I know of) for "emerge --unmerge" when installing with "make install".

Hello,

Can't you just do

Code: Select all

$ make uninstall 'package'

?

[logrusx]

I prefer emerge instead of building and installing manually because there is no alternative (that I know of) for "emerge --unmerge" when installing with "make install".

Hello,

Can't you just do

Code: Select all

$ make uninstall 'package'

?

The problem with that is in Gentoo you don't run make install yourself first place. The second problem is the way its written suggests you're considering make a package manager.

[Hu]

I prefer emerge instead of building and installing manually because there is no alternative (that I know of) for "emerge --unmerge" when installing with "make install".

Hello,

Can't you just do

Code: Select all

$ make uninstall 'package'

?

In the general case, no. Build systems are not obligated to even have an uninstall target, much less have it work correctly. This is one of the major reasons people prefer a package manager, which can collect up all the installed files in a staging area, log where they go, and then clean up later using that machine-readable log.

[M95D]

Thank you for your answers. I'll use a patch.

[sam_]

2) How about a git bisect? Can I automate a git bisect that runs emerge and a simple bash test command?

I wrote this a few years ago: https://wiki.gentoo.org/wiki/Bisecting_ ... ve_ebuilds

[M95D]

Yes, that seems to be what I'm looking for.
But I don't understand the test script used in the examples.

First there's this:
export EGIT_OVERRIDE_COMMIT_OPENZFS_ZFS=$(git rev-parse HEAD)
export EGIT_OVERRIDE_BRANCH_OPENZFS_ZFS=zfs-2.1.5-staging

then:
export EGIT_OVERRIDE_COMMIT_GLIBC=$(git rev-parse HEAD)
export EGIT_OVERRIDE_BRANCH_GLIBC=release/2.35/master

and then:
export EGIT_OVERRIDE_REPO_GCC=file:///home/sam/git/gcc
export EGIT_OVERRIDE_COMMIT_GCC=$(git rev-parse HEAD)

The variables are different for each tested package.
EGIT_OVERRIDE_COMMIT_<something>
EGIT_OVERRIDE_BRANCH_<something>
EGIT_OVERRIDE_REPO_<something>

How do I determine the name of the variables then? How do I know what <something> I should use? It's not the name of the package, it's not the repo name, it's not the branch, what is it then? That "OPENZFS_ZFS" looks like it's completely unrelated to anything.
Where are these variables documented? What do they do? What does "mirror" mean in "EGIT_CLONE_TYPE=mirror"? What does "fatal" in "USE="-pgo" fatal ebuild /var/db/repos/gentoo/sys-devel/binutils/binutils-2.40.ebuild clean compile install" do? I don't have that command installed and I can't find that command anyhere on the internet.

Could you (gentoo devs) please stop using examples as documentation and start writing proper documentation, please? Thank you!

[sam_]

How do I determine the name of the variables then? How do I know what <something> I should use? It's not the name of the package, it's not the repo name, it's not the branch, what is it then? That "OPENZFS_ZFS" looks like it's completely unrelated to anything.
Where are these variables documented? What do they do? What does "mirror" mean in "EGIT_CLONE_TYPE=mirror"?

It comes from the URL it is cloning from, in this case github.com/openzfs/zfs. The variables to use are all listed when you emerge a package using git-r3.eclass (it tells you what to set and how to override them).

The 'mirror' part could do with a comment or two which I'll add now.

Could you (gentoo devs) please stop using examples as documentation and start writing proper documentation, please? Thank you!

I think you could phrase that in a way which is less antagonistic. I wrote that article specifically as a guide for somebody who wanted help with bisecting ZFS, and then tried to make it a bit more general. It could be better, though it could be made better by anybody (certainly doesn't have to be me). I'm sorry that didn't meet your expectations.

I agree that the variables should be documented in the eclassdoc for git-r3, see bug 764422.

What does "fatal" in "USE="-pgo" fatal ebuild /var/db/repos/gentoo/sys-devel/binutils/binutils-2.40.ebuild clean compile install" do? I don't have that command installed and I can't find that command anyhere on the internet.

It's a function defined a few lines above in the same script.

[M95D]

The variables to use are all listed when you emerge a package using git-r3.eclass (it tells you what to set and how to override them).

You could have at least write this information under the first example, no? Didn't you think it was relevant?

I think you could phrase that in a way which is less antagonistic. I wrote that article specifically as a guide for somebody who wanted help with bisecting ZFS, and then tried to make it a bit more general. It could be better, though it could be made better by anybody (certainly doesn't have to be me). I'm sorry that didn't meet your expectations.

Well, I'm sorry. I find it very annoying. Gives examples of features but no expanation, no nothing. Completely unusable for someone who didn't study that "eclassdoc for git-r3" you're talking about. I don't even know what it is.
No, the article can't be improved by anyone. Only by those who know how it works, which I suspect is just you + 2-5 other people.

What does "fatal" in "USE="-pgo" fatal ebuild /var/db/repos/gentoo/sys-devel/binutils/binutils-2.40.ebuild clean compile install" do? I don't have that command installed and I can't find that command anyhere on the internet.

It's a function defined a few lines above in the same script.

Yeah, I completely missed it. I got so frustrated by the time I got to that part I simply skipped to the end.

I see that you updated it. Much more usable now. Thank you.
But it's still examples-as-documentation.

[sam_]

You can be 'annoyed' and still be respectful and ask for a change without implying nobody cares about 'proper' documentation. "Could you explain XYZ more please?" without any implication of laziness or wrongdoing would be just fine.

I wrote that article as a transcription with some edits of some private email I had with a user that asked me for help. I figured having the page was better than no page at all. You may not agree.

The documentation is in the eclass (git-r3.eclass and man git-r3.eclass which is provided by app-doc/eclass-manpages). The article is describing a particular combination of some eclass functionality and some unrelated software, so I think it's hard in this case for that page to not be mostly examples. The combination is also kind of an advanced topic rather than something all users will need to do.

There are certainly (many) users who make use of this functionality often, just not the bisect part.

[Hu]

No, the article can't be improved by anyone. Only by those who know how it works, which I suspect is just you + 2-5 other people.

As a Wiki article, anyone who chooses to create a Wiki account can edit it and improve it. While you may not have the expertise today to improve it, there are no procedural barriers to you being the person to improve it after you study the relevant documentation and become more proficient with the feature. This is distinct from other parts of the Gentoo project, where only someone who has been explicitly granted commit permission can change those parts.