3.1.92 is out. Reproducible: Always
Github pull request submitted for 3.2.16: https://github.com/gentoo/gentoo/pull/325
Robin, could you take a look at the pull request and let me know if it's fine to merge?
Also, Robin should decide on this, but I suggest using SRC_URI -> arrows to rename the downloaded distfiles so we don't end up constantly replacing the same file on bumps.
Goturk: 1. Why did you delete the old ebuild? Please do not do that. 2. I also strongly agree on using the arrows. Rebase your PR please, so that it's a single commit that adds the new ebuild, with your second change merged as well.
(In reply to Robin Johnson from comment #4) > Goturk: > 1. Why did you delete the old ebuild? Please do not do that. I guess he removed it because distfiles was no longer fetchable ;-).
(In reply to Robin Johnson from comment #4) > Goturk: > 1. Why did you delete the old ebuild? Please do not do that. Like mgorny mentioned, upstream does not version the tarballs and I couldn't find a tarball archive. As such, you cannot download the old version. > 2. I also strongly agree on using the arrows. > I did do that for the tarball. I'm not sure about handling browser extension files. They don't follow the same versioning scheme as the package itself. If they get updated, repoman manifest may not catch it. Should I rename them using arrows too? > Rebase your PR please, so that it's a single commit that adds the new > ebuild, with your second change merged as well. PR is updated as requested. @robbat2: there is also a proxy maintainer bug open for this package (Bug 525912). It looks like nobody CC'd proxy-maint and there has been no progress. If you have no time to maintain this package, would you consider dropping it to maintainer-needed so it can potentially be picked up by somebody else again?
Also, this ebuild uses unzip in src_unpack. unzip is provided by app-arch/unzip which is not part of @system. Should I add unzip to DEPEND?
(In reply to Gokturk Yuksek from comment #7) > Also, this ebuild uses unzip in src_unpack. unzip is provided by > app-arch/unzip which is not part of @system. Should I add unzip to DEPEND? Does unpack correctly handle the zip? If it does, please use it instead (I suggest an variant prefix of ./filename.zip). It will add the relevant tools as needed. You'll have to use mv instead of the -d "${S}"/crx.
(In reply to Gokturk Yuksek from comment #6) > (In reply to Robin Johnson from comment #4) > > Goturk: > > 1. Why did you delete the old ebuild? Please do not do that. > Like mgorny mentioned, upstream does not version the tarballs and I couldn't > find a tarball archive. As such, you cannot download the old version. I have an archive already. > > 2. I also strongly agree on using the arrows. > I did do that for the tarball. I'm not sure about handling browser extension > files. They don't follow the same versioning scheme as the package itself. > If they get updated, repoman manifest may not catch it. Should I rename them > using arrows too? Yes, use arrows for all distfiles. I've seen them change independently of the zipfiles, so at times we're going to have to bump this anyway, we might want to consider adding $PR in the local distfile name for the extensions if upstream does continue that trend. > > Rebase your PR please, so that it's a single commit that adds the new > > ebuild, with your second change merged as well. > PR is updated as requested. Thanks. See above. > > @robbat2: there is also a proxy maintainer bug open for this package (Bug > 525912). It looks like nobody CC'd proxy-maint and there has been no > progress. If you have no time to maintain this package, would you consider > dropping it to maintainer-needed so it can potentially be picked up by > somebody else again? See my often-posted policy to -dev, that anybody is free to update my packages. Changing it to maintainer-needed would do it a disservice. I'm not stopping anybody from updating it anyway.
(In reply to Robin Johnson from comment #8) > (In reply to Gokturk Yuksek from comment #7) > > Also, this ebuild uses unzip in src_unpack. unzip is provided by > > app-arch/unzip which is not part of @system. Should I add unzip to DEPEND? > Does unpack correctly handle the zip? If it does, please use it instead (I > suggest an variant prefix of ./filename.zip). It will add the relevant tools > as needed. You'll have to use mv instead of the -d "${S}"/crx. According to devmanual[1], we still have to add unzip to DEPEND. Not being able to specify a destination dir, or a source dir with absolute path is pretty problematic. I want to do something like this but not sure if this is preferred: dd [..] of="${S}"/crx/lpchrome_linux.zip [..] cd "${S}"/crx && unpack ./lpchrome_linux.zip || die [1] https://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/other-formats/index.html
(In reply to Robin Johnson from comment #9) > (In reply to Gokturk Yuksek from comment #6) > > (In reply to Robin Johnson from comment #4) > > > Goturk: > > > 1. Why did you delete the old ebuild? Please do not do that. > > Like mgorny mentioned, upstream does not version the tarballs and I couldn't > > find a tarball archive. As such, you cannot download the old version. > I have an archive already. > But there is no way for the ebuild to know which version you have. It will simply fail for other users who don't have it. We are keeping a version in the tree that there is no publicly available source for. How do we exactly close bugs like Bug 550834 in this case?
(In reply to Gokturk Yuksek from comment #10) > According to devmanual[1], we still have to add unzip to DEPEND. Read EAPI5's handling of zipfiles. It adds it automatically. > Not being > able to specify a destination dir, or a source dir with absolute path is > pretty problematic. I want to do something like this but not sure if this is > preferred: > dd [..] of="${S}"/crx/lpchrome_linux.zip [..] > cd "${S}"/crx && unpack ./lpchrome_linux.zip || die What you're doing is fine, but I'd not put the zipfile in the target directory.
(In reply to Robin Johnson from comment #12) > (In reply to Gokturk Yuksek from comment #10) > > According to devmanual[1], we still have to add unzip to DEPEND. > Read EAPI5's handling of zipfiles. It adds it automatically. > EAPI 5-progress document[1] mentions: "Dependencies on packages required to unpack archives specified in SRC_URI are automatically appended to DEPEND." However, EAPI 5 document[2] does not contain the same clause, perhaps it's been taken out later on? Moreover, PMS for EAPI 5 [3] section "11.3.3.13 Misc Commands" has the following clause under "unpack": "zip files (*.zip, *.ZIP, *.jar). Ebuilds must ensure that Info-ZIP Unzip is installed." > > Not being > > able to specify a destination dir, or a source dir with absolute path is > > pretty problematic. I want to do something like this but not sure if this is > > preferred: > > dd [..] of="${S}"/crx/lpchrome_linux.zip [..] > > cd "${S}"/crx && unpack ./lpchrome_linux.zip || die > What you're doing is fine, but I'd not put the zipfile in the target > directory. The problem is that unpack does not take absolute paths for EAPI 5. So something like: "unpack ${T}/lpchrome_linux.zip" fails. I am not sure how do I fix this. [1] https://dev.gentoo.org/~zmedico/portage/doc/ch06s03s09.html [2] https://dev.gentoo.org/~zmedico/portage/doc/ch06s03s08.html [3] https://projects.gentoo.org/pms/5/pms.pdf
(In reply to Gokturk Yuksek from comment #13) > (In reply to Robin Johnson from comment #12) > > (In reply to Gokturk Yuksek from comment #10) > > > According to devmanual[1], we still have to add unzip to DEPEND. > > Read EAPI5's handling of zipfiles. It adds it automatically. > > > EAPI 5-progress document[1] mentions: "Dependencies on packages required to > unpack archives specified in SRC_URI are automatically appended to DEPEND." > However, EAPI 5 document[2] does not contain the same clause, perhaps it's > been taken out later on? EAPI 5-progress is a 'fork' of EAPI 5 and not used in Gentoo. You can safely ignore it ;-). > Moreover, PMS for EAPI 5 [3] section "11.3.3.13 Misc Commands" has the > following clause under "unpack": "zip files (*.zip, *.ZIP, *.jar). Ebuilds > must ensure that Info-ZIP Unzip is installed." Yes, that's what I recall as well. > > > Not being > > > able to specify a destination dir, or a source dir with absolute path is > > > pretty problematic. I want to do something like this but not sure if this is > > > preferred: > > > dd [..] of="${S}"/crx/lpchrome_linux.zip [..] > > > cd "${S}"/crx && unpack ./lpchrome_linux.zip || die > > What you're doing is fine, but I'd not put the zipfile in the target > > directory. > The problem is that unpack does not take absolute paths for EAPI 5. So > something like: "unpack ${T}/lpchrome_linux.zip" fails. I am not sure how do > I fix this. You could switch to EAPI 6 then, if Robin doesn't mind. Just please note to quote "${T}" to keep it whitespace-safe. > [1] https://dev.gentoo.org/~zmedico/portage/doc/ch06s03s09.html > [2] https://dev.gentoo.org/~zmedico/portage/doc/ch06s03s08.html > [3] https://projects.gentoo.org/pms/5/pms.pdf
(In reply to Robin Johnson from comment #8) > (In reply to Gokturk Yuksek from comment #7) > > Also, this ebuild uses unzip in src_unpack. unzip is provided by > > app-arch/unzip which is not part of @system. Should I add unzip to DEPEND? > Does unpack correctly handle the zip? If it does, please use it instead (I > suggest an variant prefix of ./filename.zip). It will add the relevant tools > as needed. You'll have to use mv instead of the -d "${S}"/crx. Given the nature of the package, I'm not sure if there's value in using unpack. Even if I use unpack on the zip file, manual use of unzip will be required for the .xpi file because the suffix isn't recognized by unpack. Also we have to jump through hoops because unpack doesn't take an absolute path as a source, no destination directory can be specified and tarballs extract to the current directory.
InGit.
