Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On 05/11/16 04:45, Kent Fredric wrote: > On Fri, 4 Nov 2016 23:09:07 -0400 > Mike Gilbert wrote: > >> On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein wrote: >> [...] >>> >> [...] >>> Yes, that is a good idea. >>> >>> cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH | >>> grep "\@" | sort | uniq | sed "s/@/__/g" >>> >>> I prefer to protect the list at least by substitution. It will not help >>> much, but makes me happier ;-) >> Let me know which of the packages I maintain, and I will attempt to >> update them. I have touched too many packages over the last few years >> to know them on site. >> >> Your sorted list of obfuscated emails does not help at all. >> > ( curl http://dev.gentoo.org/~jstein/googlecode-shutdown.txt | cut -f1 -d":" > | while IFS="" read -r arg; do echo -n "$arg: " ; equery meta -mH $arg > 2>/dev/null | tr "\n" " "; echo ; done ) | tee /tmp/package_owners.txt > > sed 's/:\s*$/: maintainer-needed/;s/\@//g' < /tmp/package_owners.txt > > /tmp/owners_obfu.txt > > cut -d" " -f 2- < /tmp/owners_obfu.txt | tr " " "\n" | grep "^\w" | sort | > uniq -c | sort -n -k 1 > /tmp/owner_histogram.txt > ( Attached ) > > sort -k 2 < /tmp/owners_obfu.txt > /tmp/packages_by_owner.txt > ( Attached ) > > grep floppym /tmp/packages_by_owner.txt > # dev-util/open-vcdiff-0.8.3: floppymgentoo.org > # sys-fs/fuse-exfat-1.0.1: floppymgentoo.org base-systemgentoo.org > # net-misc/ps3mediaserver-1.82.0: floppymgentoo.org vapiergentoo.org > > tail -n 5 /tmp/owner_historgram.txt > # 25 javagentoo.org > # 38 pythongentoo.org > # 43 proxy-maintgentoo.org > # 56 maintainer-needed > # 60 cjkgentoo.org > > Kent+++ I'll have a look-see at the maintainer-needed@ set and see how bad it is. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On Fri, 4 Nov 2016 23:09:07 -0400 Mike Gilbert wrote: > On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein wrote: > [...] > > > [...] > > > > Yes, that is a good idea. > > > > cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH | > > grep "\@" | sort | uniq | sed "s/@/__/g" > > > > I prefer to protect the list at least by substitution. It will not help > > much, but makes me happier ;-) > > Let me know which of the packages I maintain, and I will attempt to > update them. I have touched too many packages over the last few years > to know them on site. > > Your sorted list of obfuscated emails does not help at all. > ( curl http://dev.gentoo.org/~jstein/googlecode-shutdown.txt | cut -f1 -d":" | while IFS="" read -r arg; do echo -n "$arg: " ; equery meta -mH $arg 2>/dev/null | tr "\n" " "; echo ; done ) | tee /tmp/package_owners.txt sed 's/:\s*$/: maintainer-needed/;s/\@//g' < /tmp/package_owners.txt > /tmp/owners_obfu.txt cut -d" " -f 2- < /tmp/owners_obfu.txt | tr " " "\n" | grep "^\w" | sort | uniq -c | sort -n -k 1 > /tmp/owner_histogram.txt ( Attached ) sort -k 2 < /tmp/owners_obfu.txt > /tmp/packages_by_owner.txt ( Attached ) grep floppym /tmp/packages_by_owner.txt # dev-util/open-vcdiff-0.8.3: floppymgentoo.org # sys-fs/fuse-exfat-1.0.1: floppymgentoo.org base-systemgentoo.org # net-misc/ps3mediaserver-1.82.0: floppymgentoo.org vapiergentoo.org tail -n 5 /tmp/owner_historgram.txt # 25 javagentoo.org # 38 pythongentoo.org # 43 proxy-maintgentoo.org # 56 maintainer-needed # 60 cjkgentoo.org dev-libs/liblouis-2.5.3: accessibilitygentoo.org app-accessibility/emacspeak-39.0-r2: accessibilitygentoo.org gnu-emacsgentoo.org dev-python/platinfo-0.15.0-r1: aidecoegentoo.org pythongentoo.org sci-mathematics/geogebra-4.1.120.0: amynkagentoo.org x11-misc/tint2-0.11-r2: amynkagentoo.org media-libs/lib3ds-1.3.0-r1: amynkagentoo.org gamesgentoo.org 3dprintgentoo.org media-libs/lib3ds-2.0.0_rc1: amynkagentoo.org gamesgentoo.org 3dprintgentoo.org dev-python/ipaddr-2.1.10-r1: andreis.vinogradovsgmail.com maksbotangentoo.org proxy-maintgentoo.org pythongentoo.org net-misc/linux-eoip-0.5: andreis.vinogradovsgmail.com pinkbytegentoo.org proxy-maintgentoo.org games-misc/fortune-mod-gentoo-ru-0.25: andreis.vinogradovsgmail.com proxy-maintgentoo.org games-misc/fortune-mod-gentoo-ru-0.26: andreis.vinogradovsgmail.com proxy-maintgentoo.org dev-util/plan9port-20140306: andy753421gmail.com bluenessgentoo.org proxy-maintgentoo.org dev-util/plan9port-20140306-r1: andy753421gmail.com bluenessgentoo.org proxy-maintgentoo.org dev-util/plan9port-20140306-r2: andy753421gmail.com bluenessgentoo.org proxy-maintgentoo.org app-i18n/fcitx-anthy-0.1.1: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-chewing-0.2.0: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-cloudpinyin-0.3.1: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-configtool-0.4.6: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-hangul-0.2.1: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-libpinyin-0.2.1: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-sunpinyin-0.4.0: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-table-extra-0.3.3: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-unikey-0.2.0: arfrever.ftagmail.com cjkgentoo.org app-i18n/mozc-1.10.1390.102-r1: arfrever.ftagmail.com cjkgentoo.org app-i18n/mozc-1.13.1651.102: arfrever.ftagmail.com cjkgentoo.org app-i18n/mozc-2.16.2037.102: arfrever.ftagmail.com cjkgentoo.org app-i18n/fcitx-rime-0.2.0: arfrever.ftagmail.com dlangentoo.org cjkgentoo.org net-libs/serf-1.3.8: arfrever.ftagmail.com proxy-maintgentoo.org net-libs/serf-1.3.8-r1: arfrever.ftagmail.com proxy-maintgentoo.org dev-games/aseprite-0.9.5-r1: azamat.hackimovgmail.com proxy-maintgentoo.org sys-apps/mtree-1.0.1: base-systemgentoo.org sys-apps/mtree-1.0: base-systemgentoo.org net-libs/pacparser-1.3.1: bicataligentoo.org net-proxy/torsocks-1.2-r2: bluenessgentoo.org dev-libs/leveldb-1.10.0-r1: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.11.0-r1: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.12.0-r1: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.13.0-r1: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.14.0: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.15.0: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.15.0-r1: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.9.0-r5: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org dev-libs/leveldb-1.9.0-r6: bugsbergstroem.nu patrickgentoo.org proxy-maintgentoo.org net-misc/openr2-1.3.0: chainsawgentoo.org app-benchmarks/i7z-0.27.2: chewigentoo.org dev-libs/re2-0_p20130115: chromiumgentoo.org dev-libs/re2-0_p20130115-r1: chromiumgentoo.org dev-libs/re2-0_p20130
Re: [gentoo-dev] newsitem: important fstab update
On Thu, 27 Oct 2016 10:25:39 -0400 Rich Freeman wrote: > It would be nice if standards like USB incorporated some kind of GUID. > I ended up having to write a udev rule for a pl2303 RS232 adapter to > tie it to a specific USB port precisely so that I could have more than > one and know which one talked to which device. > > I'd argue that the udev network interface names were a better (if > painful to transition to) solution to a problem created by somebody > else. Being able to use wildcards in configuration files is probably > an adequate solution for those who are using a single device. > You mean like a device serial number? Which is totally part of the USB standard, but many devices don’t bother to include one because they would have to be serially programmed in the factory? If your device has a serial number, you can generally see it as a udev attribute and use it to set up meaningful persistent names for multiple otherwise-identical devices. -- Christopher Head pgphi7PNcCbPu.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein wrote: >>> If you maintain one of these packages, please fix the SRC_URI and >>> HOMEPAGE variables. > >> It would probably be better if the output included the maintainer. > > Yes, that is a good idea. > > cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH | > grep "\@" | sort | uniq | sed "s/@/__/g" > > I prefer to protect the list at least by substitution. It will not help > much, but makes me happier ;-) Let me know which of the packages I maintain, and I will attempt to update them. I have touched too many packages over the last few years to know them on site. Your sorted list of obfuscated emails does not help at all.
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
>> If you maintain one of these packages, please fix the SRC_URI and >> HOMEPAGE variables. > It would probably be better if the output included the maintainer. Yes, that is a good idea. cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH | grep "\@" | sort | uniq | sed "s/@/__/g" I prefer to protect the list at least by substitution. It will not help much, but makes me happier ;-) Best, Jonas = 3dprint__gentoo.org accessibility__gentoo.org aidecoe__gentoo.org amynka__gentoo.org andreis.vinogradovs__gmail.com andy753421__gmail.com arfrever.fta__gmail.com azamat.hackimov__gmail.com base-system__gentoo.org bicatali__gentoo.org blueness__gentoo.org chainsaw__gentoo.org chewi__gentoo.org chromium__gentoo.org chutzpah__gentoo.org cjk__gentoo.org cluster__gentoo.org cpp__gentoo.org crypto__gentoo.org desktop-misc__gentoo.org dev-zero__gentoo.org dirk.vdb__gmail.com dlan__gentoo.org dominik.kriegner+gentoo__gmail.com dotnet__gentoo.org DuPol__gmx.de embedded__gentoo.org ercpe__gentoo.org floppym__gentoo.org fonts__gentoo.org forensics__gentoo.org freedesktop-bugs__gentoo.org games__gentoo.org gienah__gentoo.org givi-zurabovich__mail.ru gnu-emacs__gentoo.org god__politeia.in graphics__gentoo.org grozin__gentoo.org hanno__gentoo.org haskell__gentoo.org hwoarang__gentoo.org hypnos75__gmail.com idl0r__gentoo.org ikelos__gentoo.org java__gentoo.org jlec__gentoo.org johu__gentoo.org jstein__gentoo.org kde__gentoo.org kensington__gentoo.org leechcraft__gentoo.org maksbotan__gentoo.org matthias__dsx.at media-video__gentoo.org mgorny__gentoo.org ml__gentoo.org monsieurp__gentoo.org mrueg__gentoo.org mysql-bugs__gentoo.org naota__gentoo.org net-mail__gentoo.org netmon__gentoo.org nikoli__gmx.us nils__nils-andresen.de office__gentoo.org oleg__kaa.org.ua ottxor__gentoo.org pacho__gentoo.org patrick__gentoo.org perl__gentoo.org phajdan.jr__gentoo.org php-bugs__gentoo.org pinkbyte__gentoo.org polynomial-c__gentoo.org proaudio__gentoo.org prometheanfire__gentoo.org proxy-maint__gentoo.org python__gentoo.org qt__gentoo.org radhermit__gentoo.org rafaelmartins__gentoo.org rhill__gentoo.org rini17__gmail.com robbat2__gentoo.org sautier.louis__gmail.com scheme__gentoo.org sci-biology__gentoo.org sci-chemistry__gentoo.org sci__gentoo.org sci-mathematics__gentoo.org sergio.rodriguez.inclan__gmail.com shell-tools__gentoo.org slawomir.nizio__sabayon.org slis__gentoo.org slyfox__gentoo.org sound__gentoo.org spiderx__spiderx.dp.ua tcltk__gentoo.org tex__gentoo.org tomboy64__sina.cn tomka__gentoo.org vapier__gentoo.org vikraman__gentoo.org vim__gentoo.org virtualization__gentoo.org volkris__gmail.com web-apps__gentoo.org williamh__gentoo.org xfce__gentoo.org xmw__gentoo.org zerochaos__gentoo.org ziapannocchia__gmail.com zlg__gentoo.org
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On 05/11/16 01:20, Rich Freeman wrote: > On Fri, Nov 4, 2016 at 8:30 PM, M. J. Everitt wrote: >> Apologies, getting ahead of myself here .. there must be a portage >> utility, but I've forgotten which one interrogates metadata .. I'll >> defer to a more authoritative source ... >> > There might be a command line utility if you're doing things the shell way. > > But, from that python script I linked the relevant part is: > > from portage.xml.metadata import MetaDataXML > > metxml = path+"/"+category+"/"+pkgname+"/metadata.xml" > maints=[] > try: > pkg_md = MetaDataXML(metxml,"/usr/portage/metadata/herds.xml") > for maint in pkg_md.maintainers(): > maints.append(maint.email) > except IOError: pass > > Just feed that api call with a metadata.xml. Hopefuly it works with > the projects.xml syntax as herds.xml is of course defunct.I'd > check the portage API docs as there might be some improvements there. > > The portage api is actually fairly powerful and far superior to a lot > of stuff that gets done with grep. It just needs a bit of time > getting used to it since there aren't a lot of docs/examples/etc > floating around. The script that came out of was designed to find > packages that depend on packages that expose subslots but which don't > define slot operator deps. Granted, not everything in that list > should be using them, and by now I imagine it is almost entirely false > positives, but it shows the sort of thing you can do with a couple of > lines of python that would be an incredible pain to do any other way. > I believe paludis also exposes some APIs that probably could also be > used. > Bit beyond my python-fu .. but I get where you're going with that. If I wasn't banging my head against cups/hplip, I might give it a shot ... :P !! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
> Apologies, getting ahead of myself here .. there must be a portage > utility, but I've forgotten which one interrogates metadata .. I'll > defer to a more authoritative source ... You can try to fetch the maintainers per package with equery meta -mH foo/bar Best, -- Jonas
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On Fri, Nov 4, 2016 at 8:30 PM, M. J. Everitt wrote: > Apologies, getting ahead of myself here .. there must be a portage > utility, but I've forgotten which one interrogates metadata .. I'll > defer to a more authoritative source ... > There might be a command line utility if you're doing things the shell way. But, from that python script I linked the relevant part is: from portage.xml.metadata import MetaDataXML metxml = path+"/"+category+"/"+pkgname+"/metadata.xml" maints=[] try: pkg_md = MetaDataXML(metxml,"/usr/portage/metadata/herds.xml") for maint in pkg_md.maintainers(): maints.append(maint.email) except IOError: pass Just feed that api call with a metadata.xml. Hopefuly it works with the projects.xml syntax as herds.xml is of course defunct.I'd check the portage API docs as there might be some improvements there. The portage api is actually fairly powerful and far superior to a lot of stuff that gets done with grep. It just needs a bit of time getting used to it since there aren't a lot of docs/examples/etc floating around. The script that came out of was designed to find packages that depend on packages that expose subslots but which don't define slot operator deps. Granted, not everything in that list should be using them, and by now I imagine it is almost entirely false positives, but it shows the sort of thing you can do with a couple of lines of python that would be an incredible pain to do any other way. I believe paludis also exposes some APIs that probably could also be used. -- Rich
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On 05/11/16 00:23, M. J. Everitt wrote: > On 05/11/16 00:20, Rich Freeman wrote: >> On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein wrote: >>> If you maintain one of these packages, please fix the SRC_URI and >>> HOMEPAGE variables. >>> >> It would probably be better if the output included the maintainer. >> Hopefully this isn't using anything deprecated, but you should be able >> to steal from this: >> https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py >> >> Somebody else might have something more up-to-date to use. >> > Yeah that's not the best qgrep output for this target ... ;P > Apologies, getting ahead of myself here .. there must be a portage utility, but I've forgotten which one interrogates metadata .. I'll defer to a more authoritative source ... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On 05/11/16 00:20, Rich Freeman wrote: > On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein wrote: >> If you maintain one of these packages, please fix the SRC_URI and >> HOMEPAGE variables. >> > It would probably be better if the output included the maintainer. > Hopefully this isn't using anything deprecated, but you should be able > to steal from this: > https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py > > Somebody else might have something more up-to-date to use. > Yeah that's not the best qgrep output for this target ... ;P signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein wrote: > > If you maintain one of these packages, please fix the SRC_URI and > HOMEPAGE variables. > It would probably be better if the output included the maintainer. Hopefully this isn't using anything deprecated, but you should be able to steal from this: https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py Somebody else might have something more up-to-date to use. -- Rich
[gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016
Dear all, Google announced in 2015 to close the "Google Code" repositories [1]. They will provide the repositories in read only state till end of 2016. Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree [2] and should get these fixed before end of 2016. If you maintain one of these packages, please fix the SRC_URI and HOMEPAGE variables. We have also a wiki page [3] and thanks to Andreas Huettel we can monitor our daily effort in a plot [4]. [1] http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html [2] http://dev.gentoo.org/~jstein/googlecode-shutdown.txt [3] https://wiki.gentoo.org/wiki/Shutdown_of_google_code [4] http://www.akhuettel.de/~huettel/plots/googlecode.php -- Best, Jonas
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On piątek, 4 listopada 2016 20:58:23 CET James Le Cuirot wrote: > On Fri, 4 Nov 2016 13:37:42 +0100 > > Alexis Ballier wrote: > > On Fri, 4 Nov 2016 12:33:37 + > > > > James Le Cuirot wrote: > > > On Fri, 4 Nov 2016 13:20:16 +0100 > > > > > > Alexis Ballier wrote: > > > > On Thu, 3 Nov 2016 00:52:17 +0100 > > > > > > > > Maciej Mrozowski wrote: > > > > > From: Maciej Mrozowski > > > > > > > > > > --- > > > > > > > > > > eclass/cmake-utils.eclass | 6 +++--- > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass > > > > > index 88d2163..23cc094 100644 > > > > > --- a/eclass/cmake-utils.eclass > > > > > +++ b/eclass/cmake-utils.eclass > > > > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() { > > > > > > > > > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake > > > > > cat > ${toolchain_file} <<- _EOF_ || die > > > > > > > > > > - SET (CMAKE_C_COMPILER $(tc-getCC)) > > > > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX)) > > > > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC)) > > > > > > > > > > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE > > > > > > > > > > FILEPATH > > > > > > > > Have you tested cross compiling ? > > > > IIRC toolchain file is used *before* getting those vars from env and > > > > is used to determine system & compiler type. Without this you get > > > > bugs like #503216 > > > > > > I was dubious (since I filed that bug) but I briefly tested by > > > cross-compiling media-libs/openal and it worked. I didn't think to > > > try older CMake versions though. The behaviour might have changed. > > > > could you please send me (in private) build logs with & without the > > changes please ? > > > > (dont have easy access to a x compile setup atm) > > I diff'd the logs (needed MAKEOPTS="-j1") and they were practically > identical, save for the expected change in configure arguments. I also > tested with CMake 2.8 and that worked too. To further convince myself, > I took the current eclass and loosely reversed the change we made for > bug #503216. It failed with CMake 3.6 in exactly the same way it failed > back then. I am therefore happy for this to proceed. Would you agree? Env way w/ CMake is used (without toolchain file) where I work for a couple of years with quite a bunch of exotic cross-compilers so I never doubted it would work (with toolchain file lacking CMAKE__COMPILER variable). The only thing surprised me here was CMake handling CC/CXX var multi-param abuse acceptably. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On Fri, 4 Nov 2016 13:37:42 +0100 Alexis Ballier wrote: > On Fri, 4 Nov 2016 12:33:37 + > James Le Cuirot wrote: > > > On Fri, 4 Nov 2016 13:20:16 +0100 > > Alexis Ballier wrote: > > > > > On Thu, 3 Nov 2016 00:52:17 +0100 > > > Maciej Mrozowski wrote: > > > > > > > From: Maciej Mrozowski > > > > > > > > --- > > > > eclass/cmake-utils.eclass | 6 +++--- > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass > > > > index 88d2163..23cc094 100644 > > > > --- a/eclass/cmake-utils.eclass > > > > +++ b/eclass/cmake-utils.eclass > > > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() { > > > > > > > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake > > > > cat > ${toolchain_file} <<- _EOF_ || die > > > > - SET (CMAKE_C_COMPILER $(tc-getCC)) > > > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX)) > > > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC)) > > > > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE > > > > FILEPATH > > > > > > > > > Have you tested cross compiling ? > > > IIRC toolchain file is used *before* getting those vars from env and > > > is used to determine system & compiler type. Without this you get > > > bugs like #503216 > > > > I was dubious (since I filed that bug) but I briefly tested by > > cross-compiling media-libs/openal and it worked. I didn't think to > > try older CMake versions though. The behaviour might have changed. > > > > could you please send me (in private) build logs with & without the > changes please ? > > (dont have easy access to a x compile setup atm) I diff'd the logs (needed MAKEOPTS="-j1") and they were practically identical, save for the expected change in configure arguments. I also tested with CMake 2.8 and that worked too. To further convince myself, I took the current eclass and loosely reversed the change we made for bug #503216. It failed with CMake 3.6 in exactly the same way it failed back then. I am therefore happy for this to proceed. Would you agree? pgpuKc3mIbo4_.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake op
On 04/11/16 11:55, Maciej Mrozowski wrote: > On czwartek, 3 listopada 2016 07:31:10 CET Michał Górny wrote: >> On Thu, 3 Nov 2016 00:52:16 +0100 >> >> Maciej Mrozowski wrote: >>> From: Maciej Mrozowski >>> >>> --- >>> >>> eclass/cmake-utils.eclass | 54 >>> ++- 1 file changed, 21 >>> insertions(+), 33 deletions(-) >>> >>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass >>> index 393ee28..88d2163 100644 >>> --- a/eclass/cmake-utils.eclass >>> +++ b/eclass/cmake-utils.eclass >>> @@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() { >>> >>> includes="" >>> >>> fi >>> cat > "${build_rules}" <<- _EOF_ || die >>> >>> - SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive > manager" >>> FORCE)> >>> SET (CMAKE_ASM_COMPILE_OBJECT " $ > {includes} >>> ${CFLAGS} -o -c " CACHE STRING "ASM > compile >>> command" FORCE) SET (CMAKE_C_COMPILE_OBJECT " >>> ${includes} ${CPPFLAGS} -o -c > " >>> CACHE STRING "C compile command" FORCE) SET > (CMAKE_CXX_COMPILE_OBJECT >>> " ${includes} ${CPPFLAGS} > -o >>> -c " CACHE STRING "C++ compile command" FORCE) > SET >>> (CMAKE_Fortran_COMPILE_OBJECT " > >>> ${includes} ${FCFLAGS} -o -c " CACHE > STRING >>> "Fortran compile command" FORCE)> >>> - SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH > "Archive >>> index generator" FORCE) - SET (PKG_CONFIG_EXECUTABLE $(type -P >>> $(tc-getPKG_CONFIG)) CACHE FILEPATH "pkg-config executable" FORCE)> >>> _EOF_ >>> >>> local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake >>> >>> @@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() { >>> >>> SET (CMAKE_C_COMPILER $(tc-getCC)) >>> SET (CMAKE_CXX_COMPILER $(tc-getCXX)) >>> SET (CMAKE_Fortran_COMPILER $(tc-getFC)) >>> >>> + SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive > manager" >>> FORCE) +SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE >>> FILEPATH >>> "Archive index generator" FORCE)> >>> _EOF_ >>> >>> if tc-is-cross-compiler; then >>> >>> @@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() { >>> >>> # in Prefix we need rpath and must ensure cmake gets >>> our > default >>> linker path # right ... except for Darwin hosts >>> IF (NOT APPLE) >>> >>> - SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE) >>> - SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH >>> "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u >>> sr/$(get_libdir);${EPREFIX}/$(get_libdir)" -CACHE >>> STRING "" > FORCE) >>> - >>> + SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE) >>> + SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH >>> "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u >>> sr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE STRING "" FORCE)> >>> ELSE () >>> >>> - >>> - SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE >>> STRING "" > FORCE) >>> - SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE) >>> - SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE) >>> - SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "") >>> - SET(CMAKE_INSTALL_RPATH >>> "${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/$ >>> {CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE >>> STRING "" FORCE) - SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH > TRUE CACHE >>> BOOL "" FORCE) -SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}$ > {PREFIX}/lib" >>> CACHE STRING "" FORCE) - >>> + SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" >>> CACHE > STRING "" FORCE) >>> + SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" >>> FORCE) >>> + SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE) >>> + SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE >>> BOOL "") >>> + SET(CMAKE_INSTALL_RPATH >>> "${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/$ >>> {CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE >>> STRING "" FORCE) + >>> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH > TRUE CACHE >>> BOOL "" FORCE) +SET(CMAKE_INSTALL_NAME_DIR >>> "${EPREFIX}$ > {PREFIX}/lib" >>> CACHE STRING "" FORCE)> >>> ENDIF (NOT APPLE) >>> >>> _EOF_ >>> >>> fi >>> >>> # Common configure parameters (invariants) >>> >>> - local common_config=${BUILD_DIR}/
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On Fri, 4 Nov 2016 12:33:37 + James Le Cuirot wrote: > On Fri, 4 Nov 2016 13:20:16 +0100 > Alexis Ballier wrote: > > > On Thu, 3 Nov 2016 00:52:17 +0100 > > Maciej Mrozowski wrote: > > > > > From: Maciej Mrozowski > > > > > > --- > > > eclass/cmake-utils.eclass | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass > > > index 88d2163..23cc094 100644 > > > --- a/eclass/cmake-utils.eclass > > > +++ b/eclass/cmake-utils.eclass > > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() { > > > > > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake > > > cat > ${toolchain_file} <<- _EOF_ || die > > > - SET (CMAKE_C_COMPILER $(tc-getCC)) > > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX)) > > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC)) > > > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE > > > FILEPATH > > > > > > Have you tested cross compiling ? > > IIRC toolchain file is used *before* getting those vars from env and > > is used to determine system & compiler type. Without this you get > > bugs like #503216 > > I was dubious (since I filed that bug) but I briefly tested by > cross-compiling media-libs/openal and it worked. I didn't think to try > older CMake versions though. The behaviour might have changed. > could you please send me (in private) build logs with & without the changes please ? (dont have easy access to a x compile setup atm)
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On Fri, 4 Nov 2016 13:20:16 +0100 Alexis Ballier wrote: > On Thu, 3 Nov 2016 00:52:17 +0100 > Maciej Mrozowski wrote: > > > From: Maciej Mrozowski > > > > --- > > eclass/cmake-utils.eclass | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass > > index 88d2163..23cc094 100644 > > --- a/eclass/cmake-utils.eclass > > +++ b/eclass/cmake-utils.eclass > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() { > > > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake > > cat > ${toolchain_file} <<- _EOF_ || die > > - SET (CMAKE_C_COMPILER $(tc-getCC)) > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX)) > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC)) > > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE > > FILEPATH > > > Have you tested cross compiling ? > IIRC toolchain file is used *before* getting those vars from env and > is used to determine system & compiler type. Without this you get > bugs like #503216 I was dubious (since I filed that bug) but I briefly tested by cross-compiling media-libs/openal and it worked. I didn't think to try older CMake versions though. The behaviour might have changed. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On Thu, 3 Nov 2016 00:52:17 +0100 Maciej Mrozowski wrote: > From: Maciej Mrozowski > > --- > eclass/cmake-utils.eclass | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass > index 88d2163..23cc094 100644 > --- a/eclass/cmake-utils.eclass > +++ b/eclass/cmake-utils.eclass > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() { > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake > cat > ${toolchain_file} <<- _EOF_ || die > - SET (CMAKE_C_COMPILER $(tc-getCC)) > - SET (CMAKE_CXX_COMPILER $(tc-getCXX)) > - SET (CMAKE_Fortran_COMPILER $(tc-getFC)) > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH Have you tested cross compiling ? IIRC toolchain file is used *before* getting those vars from env and is used to determine system & compiler type. Without this you get bugs like #503216
Re: [gentoo-dev] Revisiting version-related tree policies
On Fri, 4 Nov 2016 10:24:28 +0100 Ulrich Mueller wrote: > I would assume to be high enough, even if you use multiples of > 100 to label the slot. Or do you expect having more than 100 slots for > Perl? Well, the desire is for the -r (or similar) part correspond to something representative of which version of Perl the virtual is an "underwriter" for. So it would naturally start at one of the following: 522, 524, 526 5022, 5024, 5026 And then you realise upstream are getting crazy and you'll need a seperate virtual only for 5.22.1, so you'll need -r5221 But that's only enough for a prefix for the identifier ... so you'll want -r52210, -r52211, and at this point, it very much is getting into the weeds of confusing. Granted I'm still at "worry about things that aren't actually a problem yet" stage. Mostly because we're not yet employing this technique until we're sure its going to be a good idea, and the only place we've *kinda* needed such a solution is virtual/perl-Test-Simple ( https://bugs.gentoo.org/show_bug.cgi?id=584238#c11 ) The problem however is reduced as follows: 1. Slots are not appropriate, because they can't be concurrently installed 2. versions must indicate an upgrade path to coerce portage to install and remove things as needed 3. versions on the virtual themselves must correlate with upstream, because we use the virtuals to ensure "X version of Y exists somehow" and the /desire/ is to have an -r scheme that we could consider making automated one day. There's just not a lot of wiggle room, because most of PV is "upstreams version", and the '-r' part is really the only part we can have some flexibility with. pgp2wxLp58yzJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Revisiting version-related tree policies
> On Fri, 4 Nov 2016, Kent Fredric wrote: >> 1. Revision number must be no longer than : >> 1a. to make <=X-r reliable, >> 1b. to prevent pathological uses of revision as date. > I think most the arguments you've made for this stem from subjective > and social problems, not technical ones. Exactly. That's why this is not intended for PMS but for the devmanual. Developer time is one of our most valuable resources. > I'd hate to be artificially limiting the utility of what can be done > with "-r" versions just because *some* of those versions *may* be > confusing for humans. > I could just as easily argue that using -r200 and -r300 is > "confusing", and that 1.2r-300 "could be a problem" and maybe we > should abolish -r'vs entirely. > The -r200 and -r300 were also not just arbitrary numbers, but they > followed the slot version, and so the "-r" suffix was itself not > purely a "X < Y", but also conveyed data about what it was for, and > served as a predictable anti-collision mechanism ( due to the whole > 2-slots-cant-have-identical-versions deal ) I think nobody is arguing against using r200 etc. for special purposes. > And as you know I was considering a similar strategy to be able > to have several variations of the same perl virtual for upgrade > reasons, but that would predictably have a much wider variety of > '-r ' prefixes to represent the wider variety of significant Perl > versions. I would assume to be high enough, even if you use multiples of 100 to label the slot. Or do you expect having more than 100 slots for Perl? Ulrich pgpNzqA8Yentt.pgp Description: PGP signature
Re: [gentoo-dev] Revisiting version-related tree policies
> On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote: > On 11/03/2016 05:11 PM, Michał Górny wrote: >> == Policy changes? == >> I think that the following new policies could make sense: >> >> 1. Revision number must be no longer than : > You likely mean "no higher than ", longer than would give large > values The wording would be similar to "no longer than 4 digits". >> 1a. to make <=X-r reliable, >> 1b. to prevent pathological uses of revision as date. > Given revision in most cases is incremental (except for some -r100, > -r200) cases, some structure here is likely good. I take it we're > talking about devmanual changes in this case for policy? Yes, it would be purely devmanual/tree policy. PMS will still mandate that the package manager can handle arbitrary long versions. Looks like using multiples of 100 is best practice if there is the same PV in different slots. Not sure if we should codify that somewhere. (If nobody contradicts, this message could be used as future policy reference, though. :) Ulrich pgplaCg2C9bC_.pgp Description: PGP signature
Re: [gentoo-dev] Revisiting version-related tree policies
On Thu, 3 Nov 2016 17:11:22 +0100 Michał Górny wrote: > 1. Revision number must be no longer than : > 1a. to make <=X-r reliable, > 1b. to prevent pathological uses of revision as date. I think most the arguments you've made for this stem from subjective and social problems, not technical ones. I'd hate to be artificially limiting the utility of what can be done with "-r" versions just because *some* of those versions *may* be confusing for humans. I could just as easily argue that using -r200 and -r300 is "confusing", and that 1.2r-300 "could be a problem" and maybe we should abolish -r'vs entirely. The -r200 and -r300 were also not just arbitrary numbers, but they followed the slot version, and so the "-r" suffix was itself not purely a "X < Y", but also conveyed data about what it was for, and served as a predictable anti-collision mechanism ( due to the whole 2-slots-cant-have-identical-versions deal ) And as you know I was considering a similar strategy to be able to have several variations of the same perl virtual for upgrade reasons, but that would predictably have a much wider variety of '-r ' prefixes to represent the wider variety of significant Perl versions. > 2. I think we could use a policy to make >=X_alpha reliable. However, > I have no clue how to word it without making it weird and artificially > restricting valid version numbers. pgpxetCnBlBeS.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Revisiting version-related tree policies
On 11/03/2016 05:11 PM, Michał Górny wrote: > == Policy changes? == > I think that the following new policies could make sense: > > 1. Revision number must be no longer than : You likely mean "no higher than ", longer than would give large values > 1a. to make <=X-r reliable, > 1b. to prevent pathological uses of revision as date. Given revision in most cases is incremental (except for some -r100, -r200) cases, some structure here is likely good. I take it we're talking about devmanual changes in this case for policy? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: kde-misc/networkmanagement
# Johannes Huber (04 Nov 2016) # Masked for reomval in 30 days. Superseded by kde-plasma/plasma-nm. # Only support for deprecated Plasma 4. Exported to kde-sunset overlay. kde-misc/networkmanagement -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID FDF4F788 signature.asc Description: This is a digitally signed message part.