inconsistent unpack location for custom ebuild.

geosword · n00b Joined: 16 Apr 2015 Posts: 10

Hi Everyone,
Im trying to write an ebuild for rdiff-backup-1.2.8. I have two gentoo hosts I work on regularly, and the ebuild works fine on one, but not the other. The problem is at the unpack stage, specifically where the archive is extracted to:[/code]

Working host:

Genone · Posted: Wed Jan 10, 2018 8:42 am Post subject:

Lets go for the obvious things first: Verify that both hosts use the same ebuild file, source tarball and ebuild repository. It's easy to miss stale copies.

geosword · n00b Joined: 16 Apr 2015 Posts: 10

Thanks for replying.

>Verify that both hosts use the same ebuild file,

Host that works:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21591

You showed that both ebuilds ask for the same URL. You did not show whether the downloaded tarball is actually the same in both cases. If one of the two downloads came from a mirror with a bad tarball, you could get strange results (although this particular strange result seems unlikely). Please post also the emerge --info for both hosts, and verify from that output that both are synced to the same commit in the Gentoo tree. This can rule out any oddities with eclass differences.

geosword · n00b Joined: 16 Apr 2015 Posts: 10

>You showed that both ebuilds ask for the same URL. You did not show whether the downloaded tarball is actually the same in both cases. If one of the two downloads came from a mirror with a bad tarball, you could get strange results (although this particular strange result seems unlikely).

Fair point. Worth checking. However they are the same:

Genone · Mar 16 2009

geosword · n00b Joined: 16 Apr 2015 Posts: 10

Hi there

>Any explanation for that timestamp? Probably not related to your problem as it's the same for both systems, but looks quite strange.

Looks like it comes from the archive.

Genone · Posted: Fri Jan 12, 2018 9:29 am Post subject:

Hmm, try debugging the ebuild with `ebuild --debug /path/to/your/rdiff-backup.ebuild unpack`
Hopefully that will reveal at what point the target name is screwed up.

krinn · Watchman Joined: 02 May 2003 Posts: 7470

did you check this is correct?

geosword · n00b Joined: 16 Apr 2015 Posts: 10

Genone:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21591

On the non-working machine, if you extract that archive manually to a temporary directory, do the resulting filenames come out good or bad?

geosword · n00b Joined: 16 Apr 2015 Posts: 10

You're on the right track Hu.
I actually tracked down the problem.
Im afraid there's a significant element of PEBCAK.
What I hadnt noticed was that the NON working host, wasnt actually downloading the archive. It was using a pre-existing archive (where that came from Im not sure) in the DISTDIR.
Once I deleted that, things started going my way again, although not completely.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21591

Above, I asked that you compare the two tar.gz files, and you reported that they were the same. Your most recent post says that there was a bad one that needed to be replaced. I don't see how both can be true.

Separately, why are you writing this ebuild? There are newer versions in the main Gentoo tree. If you want an ebuild for this specific version, you can get it from the attic. Regardless, you should not be putting this ebuild in $PORTDIR. Put it in your local overlay.

geosword · n00b Joined: 16 Apr 2015 Posts: 10

cboldt · Veteran Joined: 24 Aug 2005 Posts: 1046

I view making a local overlay as trivially easy. Create /usr/local/portage, then from there a directory branch "parallel to" the ebuild you are planning to modify.

Now that you have modified an ebuild in (probably) /usr/portage, just copy that branch of the /usr/portage limb to /usr/local/portage and the task is done.

charles17 · Advocate Joined: 02 Mar 2008 Posts: 3664

Hu · Moderator Joined: 06 Mar 2007 Posts: 21591

Regarding the checksum difference, I understand now. To me, the key sentences were "Verify that both hosts use the same ebuild file, source tarball ..." (Genone) and "You did not show whether the downloaded tarball is actually the same in both cases." (me) I suggested a bad mirror as one cause, but it never occurred to me that you would perform new downloads just for that; I expected you to compare the two already sitting in the respective DISTDIR or that you would sync the Manifest and rely on its checksums, since both of those would work on the respective downloaded tarballs. I will take as a lesson for next time to be more specific when I request a comparison.

Regarding version parity, that's reasonable, but I still wonder why you chose not to retrieve the appropriate ebuild from the attic.

Regarding an overlay, beware that if you sync your main tree, the sync will delete local modifications, including the local creation of this obsolete ebuild. That is why you should put the ebuild in an overlay first, before you even try to get it working. Otherwise, you risk deleting all your work if a sync happens before you move to the overlay.

geosword · n00b Joined: 16 Apr 2015 Posts: 10

Hu · Moderator Joined: 06 Mar 2007 Posts: 21591

I see. Yes, distutils.eclass was retired after all ebuilds were converted to its successor. You would have needed to convert the recovered ebuild to the successor eclass, or done what you did.