I wrote ebuild for dev-util/depot_tools which is used for getting chromium source code and building it. Reproducible: Always
Please attach the ebuild.
I think making it an ebuild is problematic. depot_tools do a self-update via svn, and it doesn't really fit to be a Gentoo package.
You can see the ebuild with the link in "URL" field. Also, it is in sunrise overlay waiting for review.
(In reply to comment #2) > I think making it an ebuild is problematic. depot_tools do a self-update via > svn, and it doesn't really fit to be a Gentoo package. > It self-updates inly if .svn dir is present. Portage removes it automarically.
(In reply to comment #4) > It self-updates inly if .svn dir is present. Portage removes it automarically. Yeah, but it's *supposed* to be self-updated (at least in the usual development scenario). At least for me (I'm an upstream dev also), an ebuild for depot_tools wouldn't be useful.
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/dev-util/depot_tools/depot_tools-9999.ebuild
Thankyou so much for creating this ebuild. I wanted to build Google Chromium OS for a virtual machine and I needed to install these. I installed it and I am now syncing with Google's Chromium OS git repository. No special configuration was needed. :)
(In reply to comment #7) > Thankyou so much for creating this ebuild. I wanted to build Google Chromium OS > for a virtual machine and I needed to install these. I installed it and I am > now syncing with Google's Chromium OS git repository. No special configuration > was needed. :) > I`m GLaD to hear that! :)
I've just added dev-util/chromium-tools to the portage tree. I think it's a better approach that does the same thing.
(In reply to comment #9) > I've just added dev-util/chromium-tools to the portage tree. I think it's a > better approach that does the same thing. > Just tested "chromium-depot-tool gclient" and v8-create-tarball on amd64 if you would care to keyword it.
Please resolve the bug as WONTFIX instead of FIXED if depot_tools is obsoleted by chromium-tools or otherwise not needed any more.
*** Bug 389175 has been marked as a duplicate of this bug. ***
As noted before, we have chromium-tools (which are not optimal either and may get removed), and depot_tools are not suitable for packaging, not even as a live ebuild. They inherently rely on being able to update themselves at any time (I'm also upstream developer and have been using those tools for 3 years, and asked their authors just to confirm).
chr(In reply to comment #13) 1. chromium-tools doesn't includes tools required to build chromiumos (repo, cros_sdk, etc) 2. self-updating software is too insecure 3. I think its better to provide patch, that fixes this "requirement on self-update" I just think, its better to be more user friendly: 1. working ebuild always better than non-working 2. users always can re-emerge live ebuild As for me, I'm not "upstream" developer. I just want try use/merge chromiumos binary package generationg system to Gentoo.
(In reply to comment #14) > 1. chromium-tools doesn't includes tools required to build chromiumos (repo, > cros_sdk, etc) Right, I think you should just follow upstream workflow. > 2. self-updating software is too insecure Sorry, that's what upstream provides. Feel free to ask them to change this. > 3. I think its better to provide patch, that fixes this "requirement on > self-update" Feel free to take that upstream. As mentioned before, this is unlikely to change. You can disable the auto-update. > I just think, its better to be more user friendly: > 1. working ebuild always better than non-working The problem is that outdated ebuild may stop working with more recent sources, or might even fail in a more subtle way, i.e. mysterious breakages. > 2. users always can re-emerge live ebuild See above, this has no advantages over regular workflow.
If there is interest in having depot_tools as separate package, as it apparently contains functions that are not present in chromium-tools, then this bug can be reopened (and depot_tools added back to sunrise). The intentions from upstream are only of secondary importance, as long as the license is followed.
(In reply to comment #16) > If there is interest in having depot_tools as separate package, as it > apparently contains functions that are not present in chromium-tools, then this > bug can be reopened (and depot_tools added back to sunrise). Feel free to add this to some overlays, but I'm against adding it to main portage tree.
Please leave this bug open since it is now maintained in sunrise overlay
*** Bug 391329 has been marked as a duplicate of this bug. ***
The ebuild has been broken since svn revision 79715. Here is a workaround for anyone who needs it: ESVN_REVISION="79714" emerge dev-util/depot_tools
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
