Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
On Mon, Sep 23, 2013 at 2:24 AM, Ian Stakenvicius a...@gentoo.org wrote: FYI - Spidermonkey is in the exact same situation -- upstream develops with the expectation that projects will embed the code or at best bundle the lib. They also completely break API with every major version bump (ie, every 6 weeks). Fortunately they accepted patches that support installing multiple versions concurrently, and so I've started slotting it in the tree. On the other hand, I'm assuming non-core Mozilla projects and external projects rely only on ESR releases of Spidermonkey, such that the API only changes every 30 weeks or so? Cheers, Dirkjan
Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?
Dnia 2013-09-22, o godz. 17:17:53 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): I'd like maintainers of all packages depending on dev-lang/v8 to make their packages use bundled v8 copy instead (I can file bugs for that, let's discuss here whether it should be done). For now V8 upstream gives no guarantees about API/ABI stability and actually breaks it very often (http://upstream-tracker.org/versions/v8.html). Having a shared library so closely tied to packages (which results in frustrating blockers, since v8 is updated often and chromium is synchronized with that) is not really much different from everyone bundling the library. I'd like that to improve, but for now it's time for a pragmatic solution to this IMHO. If this trend continues, I think we should work on some technical way of tracking bundled libraries, e.g. for security issues. Like ebuilds listing the corresponding Gentoo packages, like: QA_BUNDLES=dev-foo/bar-1.2.3 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
[ ... ] Stealing random mail from this thread. Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts - Samuli
Re: [gentoo-dev] unstable/testing keywords
Jack Morgan schrieb: I find this confusing and hope to clear it up. According to emerge/portage man pages we have stable keywords (ARCH) and unstable packages (~ARCH) while the handbook[1] says we have stable keywords (ARCH) and testing keywords (~ARCH). There is stable and not stable. Whether you call what is not stable unstable or testing does not matter, as Gentoo does not differentiate between the two. FWIW, I think that using the word testing implies some sort of path to stable, which is not the case with many packages. I prefer to say unstable. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] unstable/testing keywords
On Mon, 23 Sep 2013 13:59:37 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Jack Morgan schrieb: I find this confusing and hope to clear it up. According to emerge/portage man pages we have stable keywords (ARCH) and unstable packages (~ARCH) while the handbook[1] says we have stable keywords (ARCH) and testing keywords (~ARCH). There is stable and not stable. Whether you call what is not stable unstable or testing does not matter, as Gentoo does not differentiate between the two. FWIW, I think that using the word testing implies some sort of path to stable, which is not the case with many packages. I prefer to say unstable. Well it should, because ~arch was supposed to mean candidate for becoming arch. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] unstable/testing keywords
On Mon, Sep 23, 2013 at 1:59 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: There is stable and not stable. Whether you call what is not stable unstable or testing does not matter, as Gentoo does not differentiate between the two. FWIW, I think that using the word testing implies some sort of path to stable, which is not the case with many packages. I prefer to say unstable. While your reasoning is sound, I think the word unstable carries a negative connotation that isn't really warranted for most of the testing tree: that something is not stable does not imply that it is unstable, it only implies that whether it is stable isn't really known. So I, too, would prefer if we used some other term to describe the not-stable tree/keyword. Cheers, Dirkjan
[gentoo-dev] Re: unstable/testing keywords
On 23/09/2013 22:03, Ciaran McCreesh wrote: On Mon, 23 Sep 2013 13:59:37 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Jack Morgan schrieb: I find this confusing and hope to clear it up. According to emerge/portage man pages we have stable keywords (ARCH) and unstable packages (~ARCH) while the handbook[1] says we have stable keywords (ARCH) and testing keywords (~ARCH). There is stable and not stable. Whether you call what is not stable unstable or testing does not matter, as Gentoo does not differentiate between the two. FWIW, I think that using the word testing implies some sort of path to stable, which is not the case with many packages. I prefer to say unstable. Well it should, because ~arch was supposed to mean candidate for becoming arch. I tend to agree. I remember someone one saying something like if it will never be a candidate for stable it doesn't belong in the tree.
[gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords
On 23/09/2013 21:34, Samuli Suominen wrote: [ ... ] Stealing random mail from this thread. Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts - Samuli Didn't dev profiles cause issues with prefix profiles due to repoman not reporting unresolved dependencies?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/emelfm2: emelfm2-0.9.0.ebuild metadata.xml ChangeLog
# ChangeLog for app-misc/emelfm2 # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/app-misc/emelfm2/ChangeLog,v 1.56 2013/09/23 09:47:35 ssuominen Exp $ 23 Sep 2013; Samuli Suominen ssuomi...@gentoo.org emelfm2-0.8.1.ebuild, emelfm2-0.8.2.ebuild, emelfm2-0.9.0.ebuild: Remove unused IUSE=fam as per gentoo-dev thread. Oh, there was a gentoo-dev thread, too? On Sun, 22 Sep 2013 20:43:29 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: IUSE has 'fam' but it's not used anywhere in the ebuild. It's apparently had that since your 0.7.4 bump[1]. :) jer [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/emelfm2/emelfm2-0.7.4.ebuild?hideattic=0revision=1.1view=markup
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On Mon, 23 Sep 2013, Samuli Suominen wrote: Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts That's a thing that was never quite clear to me. Should there be a one-to-one correspondence between an arch marked stable in profiles.desc (i.e. having at least one profile labelled as stable there) and the same arch having stable keywords? There is at least one example for an arch that is only dev in profiles.desc but used to have stable keywords (sh), and another arch where it's the other way around (amd64-fbsd). Ulrich
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On 23/09/13 15:52, Ulrich Mueller wrote: On Mon, 23 Sep 2013, Samuli Suominen wrote: Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts That's a thing that was never quite clear to me. Should there be a one-to-one correspondence between an arch marked stable in profiles.desc (i.e. having at least one profile labelled as stable there) and the same arch having stable keywords? of course... There is at least one example for an arch that is only dev in profiles.desc but used to have stable keywords (sh), and another arch where it's the other way around (amd64-fbsd). Ulrich can't believe it was like that for amd64-fbsd and nobody noticed before, fixed that. i'm a bit confused, why do you think sh is not an stable arch? it's still an stable arch like m68k and s390 is... until someone changes those lines as per council's vote.
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On 23/09/13 16:08, Samuli Suominen wrote: On 23/09/13 15:52, Ulrich Mueller wrote: On Mon, 23 Sep 2013, Samuli Suominen wrote: Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts That's a thing that was never quite clear to me. Should there be a one-to-one correspondence between an arch marked stable in profiles.desc (i.e. having at least one profile labelled as stable there) and the same arch having stable keywords? of course... There is at least one example for an arch that is only dev in profiles.desc but used to have stable keywords (sh), and another arch where it's the other way around (amd64-fbsd). Ulrich i'm a bit confused, why do you think sh is not an stable arch? it's still an stable arch like m68k and s390 is... until someone changes those lines as per council's vote. ah, scratch that, got it now -- vapier already started downgrading the 'sh' status earlier, before the council's vote by changing the profiles.desc
[gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords
On 23/09/2013 22:52, Ulrich Mueller wrote: On Mon, 23 Sep 2013, Samuli Suominen wrote: Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts That's a thing that was never quite clear to me. Should there be a one-to-one correspondence between an arch marked stable in profiles.desc (i.e. having at least one profile labelled as stable there) and the same arch having stable keywords? In my opinion the two need not be linked. To me profile stability refers to the status of the profile, nothing to do with keywords. If an arch team does not want to maintain stable keywords, but wants to indicate that a particular profile is stable, why should we try to stop them?
Re: [gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords
On Mon, Sep 23, 2013 at 3:18 PM, Michael Palimaka kensing...@gentoo.org wrote: That's a thing that was never quite clear to me. Should there be a one-to-one correspondence between an arch marked stable in profiles.desc (i.e. having at least one profile labelled as stable there) and the same arch having stable keywords? In my opinion the two need not be linked. To me profile stability refers to the status of the profile, nothing to do with keywords. If an arch team does not want to maintain stable keywords, but wants to indicate that a particular profile is stable, why should we try to stop them? What does eshowkw use to determine what arches should be displayed? Cheers, Dirkjan
Re: [gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords
On 23/09/13 16:18, Michael Palimaka wrote: On 23/09/2013 22:52, Ulrich Mueller wrote: On Mon, 23 Sep 2013, Samuli Suominen wrote: Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writing this, the mentioned arches are still 'stable', not 'dev' No matter what the news item or whatever says, only profiles.desc counts That's a thing that was never quite clear to me. Should there be a one-to-one correspondence between an arch marked stable in profiles.desc (i.e. having at least one profile labelled as stable there) and the same arch having stable keywords? In my opinion the two need not be linked. To me profile stability refers to the status of the profile, nothing to do with keywords. If an arch team does not want to maintain stable keywords, but wants to indicate that a particular profile is stable, why should we try to stop them? profiles.desc status is about how repoman is used to scan KEYWORDS, and those arch maintainers with only ~arch keywording use `repoman --include-dev` so changing the status from 'dev' to 'stable' won't gain anything scanning wise unless we are discussing changing the repoman's default to include the dev profiles in the scan, and exclude them by might-be switch like --without-dev?
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On 23/09/13 16:08, Samuli Suominen wrote: can't believe it was like that for amd64-fbsd and nobody noticed before, fixed that. scratch that too. left it at dev. if the entire tree is fine with some arch being at ~ and no dependencies are broken, that could counted as 'stable' too. then setting it from 'dev' to 'stable' will just make sure nobody breaks the perfect record of no dependencies broken. it might be useful to have another status added to the profiles.desc for that case, like 'semi-stable' or whatever since amd64-fbsd might not fit either, 'dev' or 'stable' :/
Re: [gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords
On Mon, 23 Sep 2013 16:25:40 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: profiles.desc status is about how repoman is used to scan KEYWORDS, and those arch maintainers with only ~arch keywording use `repoman --include-dev` so changing the status from 'dev' to 'stable' won't gain anything scanning wise not entirely true: repoman is for _every_ dev. facts are explained here: http://article.gmane.org/gmane.linux.gentoo.devel/76909 in practice, profiles.desc and arch/~arch are orthogonal.
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On Mon, 23 Sep 2013, Samuli Suominen wrote: if the entire tree is fine with some arch being at ~ and no dependencies are broken, that could counted as 'stable' too. then setting it from 'dev' to 'stable' will just make sure nobody breaks the perfect record of no dependencies broken. The problem with that is that we don't track the keyword status of an arch anywhere in profiles, so tools like ekeyword or ebuild-mode in Emacs have no way of obtaining that information (other than hardcoding it). We tried to rectify the situation in bug 304133, but it didn't work out. it might be useful to have another status added to the profiles.desc for that case, like 'semi-stable' or whatever since amd64-fbsd might not fit either, 'dev' or 'stable' :/ Either that, or add another file to the profiles dir. Ulrich
Re: [gentoo-dev] Re: unstable/testing keywords
Michael Palimaka schrieb: On 23/09/2013 22:03, Ciaran McCreesh wrote: Well it should, because ~arch was supposed to mean candidate for becoming arch. I tend to agree. I remember someone one saying something like if it will never be a candidate for stable it doesn't belong in the tree. There was an extensive discussion about this topic (whether packages unfit or not intended for stable should enter ~arch, or even the tree) some time ago, which I don't plan to restart. Suffice to say, consensus was not reached. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On Mon, 23 Sep 2013 15:57:48 +0200 Ulrich Mueller u...@gentoo.org wrote: On Mon, 23 Sep 2013, Samuli Suominen wrote: if the entire tree is fine with some arch being at ~ and no dependencies are broken, that could counted as 'stable' too. then setting it from 'dev' to 'stable' will just make sure nobody breaks the perfect record of no dependencies broken. The problem with that is that we don't track the keyword status of an arch anywhere in profiles, so tools like ekeyword or ebuild-mode in Emacs have no way of obtaining that information (other than hardcoding it). we do track it with ACCEPT_KEYWORDS either way, in comparison to having broken deps coming out of the wild, this is very minor imho: 'ekeyword all' is a bit doubtful, and I assume emacs uses this to color differently variables in KEYWORDS [...] it might be useful to have another status added to the profiles.desc for that case, like 'semi-stable' or whatever since amd64-fbsd might not fit either, 'dev' or 'stable' :/ Either that, or add another file to the profiles dir. we have 'stable', 'dev' and 'exp'; the difference between 'dev' and 'exp' is unclear to me. it could be changed so that broken deps in 'dev' profiles are a repoman error (without -d) but without stable keywords. Alexis.
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On Mon, 23 Sep 2013, Alexis Ballier wrote: The problem with that is that we don't track the keyword status of an arch anywhere in profiles, so tools like ekeyword or ebuild-mode in Emacs have no way of obtaining that information (other than hardcoding it). we do track it with ACCEPT_KEYWORDS Yeah, but that's scattered all over the place and not easily accessible, without fully resolving all interdependencies between profiles. $ grep -lr ACCEPT_KEYWORDS /usr/portage/profiles | wc -l 99 Ulrich
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On Mon, 23 Sep 2013 16:23:35 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Mon, 23 Sep 2013, Alexis Ballier wrote:
The problem with that is that we don't track the keyword status of
an arch anywhere in profiles, so tools like ekeyword or
ebuild-mode in Emacs have no way of obtaining that information
(other than hardcoding it).
we do track it with ACCEPT_KEYWORDS
Yeah, but that's scattered all over the place and not easily
accessible, without fully resolving all interdependencies between
profiles.
$ grep -lr ACCEPT_KEYWORDS /usr/portage/profiles | wc -l
99
it could be 'fixed' by kindly asking and moving ACCEPT_KEYWORDS
setting to the 'advertised profile', that is in ${dir}/make.defaults
where ${dir} is the directory listed in profiles.desc
Re: [gentoo-dev] unstable/testing keywords
On Mon, Sep 23, 2013 at 01:59:37PM +0200, Ch??-Thanh Christopher Nguy???n wrote: Jack Morgan schrieb: I find this confusing and hope to clear it up. According to emerge/portage man pages we have stable keywords (ARCH) and unstable packages (~ARCH) while the handbook[1] says we have stable keywords (ARCH) and testing keywords (~ARCH). There is stable and not stable. Whether you call what is not stable unstable or testing does not matter, as Gentoo does not differentiate between the two. FWIW, I think that using the word testing implies some sort of path to stable, which is not the case with many packages. I prefer to say unstable. This is not true based on the what the handbook says[1]. If fact this email thread is about the disconnect in our developer community on what the difference is between ARCH and ~ARCH. I can't find any documented details for unstable keywords besides the man pages listed above. From the recent council summary[2], there seems to be some difference in perspective on its meaning. I can't tell if they in fact the council is just talking about keywords or possible talking about unstable/unsupported architecture. Perhaps developers think they can be interchangable? As others have pointed out, unstable or even not stable wasn't the intended meaning. If the meaning has warped over time, then it should be cleared up in a GLEP, handbook corrected, etc. [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=3 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt Thanks, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital signature
Re: [gentoo-dev] unstable/testing keywords
On Mon, 23 Sep 2013, Jack Morgan wrote: I can't find any documented details for unstable keywords besides the man pages listed above. It is defined in the PMS [1]: ~arch: The package version and the ebuild are believed to work and do not have any known serious bugs, but more testing is required before the package version is considered suitable for obtaining a stable keyword. This is referred to as an /unstable keyword/ or a /testing keyword./ Ulrich [1] http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-690007.3.2
Re: [gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords
On 09/23/2013 02:46 PM, Alexis Ballier wrote: On Mon, 23 Sep 2013 16:25:40 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: profiles.desc status is about how repoman is used to scan KEYWORDS, and those arch maintainers with only ~arch keywording use `repoman --include-dev` so changing the status from 'dev' to 'stable' won't gain anything scanning wise not entirely true: repoman is for _every_ dev. facts are explained here: http://article.gmane.org/gmane.linux.gentoo.devel/76909 in practice, profiles.desc and arch/~arch are orthogonal. Yes in practice they are orthogonal. One could argue that all profiles should be marked 'stable' in order to improve the overall dependency coverage and stability because, lets face it, very few devs run repoman -d. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] News item: m68k, s390, and sh are dropping stable keywords
On 09/23/2013 03:07 PM, Alexis Ballier wrote: we have 'stable', 'dev' and 'exp'; the difference between 'dev' and 'exp' is unclear to me. it could be changed so that broken deps in 'dev' profiles are a repoman error (without -d) but without stable keywords. Alexis. I believe the 'exp' profile makes no sense. It might did in the past, but I believe we are fine having only 'stable' and 'dev'. So unless I am missing something obvious, 'dev' can be used to express ~arch only architectures whether they are in a good or bad state. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
[gentoo-dev] Last rites: sys-firmware/amd-ucode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (23 Sep 2013) # dead upstream. The microcode is now in the latest # sys-kernel/linux-firmware. Bug #455208 # Removal in 30 days. sys-firmware/amd-ucode - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iQJ8BAEBCgBmBQJSQJZnXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88keEP/AiDK0QQIoIyp8gtCGYiyQlJ Y5vNNOCZockisNRGoSpuWUmqReQ++QWlaaUye6FWkEY68usdwMh2IbNKUDBGSP7i jCPMtUrwel6QI+cB0gXckRN2F62eIMnRSTwbjRhwe2wFD4tchCT/jvB7hqbSaPsJ +P/qY/z827sW5oRD0AKUpwyLCw+WAjgiM2CQNCcjs/HLadxIeUO+2fyfTqhxUDTo CEpsiDvK0KdcjBgzS/+boAAjdraJ2uK/TCM/JBTWUqMJz34LvqSOHcizekreMiWD giWINHZmn2X25+Yf9C/SLioN4I4dDfsR7TN7sU3hug2dEi9AWIVVf4W3imsuFKw1 yTw7felW+dSBG6FG3LZHHKd6qWJzxMqaewJ/0ulyydZNT8EqZd0D3Jq+mKF0aLEx 9hleMgDjMLIv2qj91K1OavVpo2DYPhGFUUu7AIfJcA6fWsepnXVXiDRfzz2TaJ3p +x7RTnanVeT2rMJtsuBuR0EfoXIRUSGwkx2PWQdGekQPeNm0t1uczySq79vpaSEj 0DMLoELBsbvB6aehSaeUwz0r+ka154j59UA4wtHbtxX40k98VApCNwbGyYrL5qJP UlP1dw/dQ9vMyoOVD4obx8Df/HAvtoJOxnrMN3Odb5y8yzZrwQOma069w5iLCIrP 6dwSmnmAST7/21+eQbQo =5za3 -END PGP SIGNATURE-
[gentoo-dev] Move m68k, sh, s390 to ~arch
Hello, the council has decided[1] to drop m68k, sh, s390 to unstable. If someone has something to say about, this is the last opportunity or in few days I will start to mark them as ~arch. [1]: https://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt -- Agostino Sarubbo Gentoo Linux Developer
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
Am Montag, 23. September 2013, 22:03:49 schrieb Agostino Sarubbo: Hello, the council has decided[1] to drop m68k, sh, s390 to unstable. If someone has something to say about, this is the last opportunity or in few days I will start to mark them as ~arch. [1]: https://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt Hey Ago, please at least wait until the step from the news item is done (next sunday) - the modification of ACCEPT_KEYWORDS in the profiles. If you do anything before that it will only mess things up. Cheers, A -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
On Mon, 23 Sep 2013 22:03:49 +0200 Agostino Sarubbo a...@gentoo.org wrote: Hello, the council has decided[1] to drop m68k, sh, s390 to unstable. If someone has something to say about, this is the last opportunity or in few days I will start to mark them as ~arch. is there a need to waste your time on this ? when mips was moved to ~arch it was done progressively: packages are moved to ~arch (~all) with new versions/revisions, no new stable keywords are added and old versions get removed.
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
On 09/23/2013 09:31 PM, Alexis Ballier wrote: On Mon, 23 Sep 2013 22:03:49 +0200 Agostino Sarubbo a...@gentoo.org wrote: Hello, the council has decided[1] to drop m68k, sh, s390 to unstable. If someone has something to say about, this is the last opportunity or in few days I will start to mark them as ~arch. is there a need to waste your time on this ? when mips was moved to ~arch it was done progressively: packages are moved to ~arch (~all) with new versions/revisions, no new stable keywords are added and old versions get removed. I agree. There is absolutely *no* reason to drop the keywords on existing packages and cause massive downgrades/upgrades for people (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
On Thu, May 2, 2013 at 5:26 AM, Michał Górny mgo...@gentoo.org wrote:
Hi,
I've thought for a bit and got the conclusion that the best solution
for quite an irritating syntax of autotools-multilib is to use
sub-phase functions.
Sorry for the delayed response, but having been playing with this
stuff lately, and I'd like to state for the record that I
whole-heartedly endorse this product and/or service.
autotools_configure()
autotools_install()
autotools_install_all()
I like that you manage to avoid syntax like:
autotools_multilib_${phase}_${applicability-specifier}_${etc}...
:)
The name of the game is to get from where we are now, to where we want
to be (presumably, a future in which we can rm -rf
${PORTDIR}/app-emulation/emul-linux-x86-*), with a minimum of
repetitive and/or difficult retrofit labor.
Ideally, to multilib-retrofit an ebuild, the ebuild-repair-person
would just chop up the code a bit, and indicate to the framework which
snippets pertain to which ABI's or are ABI-independent.
We're nowhere near that now. As you suggest, the problem is that
there's no way to hook any per-ABI script code into the
autotools-multilib phase functions without copy pasting the whole
boilerplate, which shrinks the value-proposition of autotools-multilib
(vs. direct inheritance to multilib-build) down to almost nothing.
All but the most simple pre-USE_EXPAND-abi-ebuilds have snippets of
script code that want to run on a per-ABI basis, often inconveniently
interspersed between src_prepare() and src_configure(), and there is
no low-effort way to wedge that code into the autotools-multilib
framework as implemented.
Often, there is some clever substitution that can be made to bridge
this feature-gap -- but by now the ebuild-repair-person is well into
investigating/thinking deeply/drawing-board mode, precisely where he
doesn't want to find himself if he's trying to quickly blow through a
deeply-entangled batch of 50 or 100 ebuilds requiring simultaneous
retrofitting.
While this seems rather cosmetic...
It's not just a cosmetic problem. ... but, a brief diversion about
aesthetics: I think, in ebuild-writing, there's a fine line between
cosmetically fucked and just plain fucked. Likewise, the converse
also holds: an aesthetically blessed ebuild is probably blessed for
developers, bugzilla worker-bees, and end-users (gentoo sysadmins)
alike.
So, in short, cosmetic improvements are good and intrinsically
important. Furthermore, the term cosmetic has connotations of
ineffectual: that is not the case here, there are real practical
problems being solved -- your proposal ENABLES the
ebuild-repair-person to shuffle around code in a seemingly trivial
manner, but that's NOT an option with the current implementation,
instead the ebuild-repair-person must struggle against the limitations
of the framework (in addition to figuring out whatever true semantic
change is required by the retrofit).
Anyhow, meanwhile, back on planet Earth...
The sub-phases without '_all' suffix are run inside BUILD_DIR, and
repeated for each multilib ABI. The sub-phases with '_all' are always
run only once, and inside S.
It's clearly a move in the right direction. New choke points would
probably reveal themselves once we were freed from the tyranny of
constantly typing in the same code over and over :)
I do think all vs. is dsylexia-inducing and should be changed... perhaps:
at_${phase}_abi: per-abi steps (i.e., probably in per-abi ${BUILD_DIR})
at_${phase}: global steps (i.e., in ${S})
s/at/autotools/ obv or just leave it! short==good here.
Anyhow, those really are trivial semantic matters.
I also think your proposal could go a bit further in the ability to
slice-and-dice the sub-phase functions. For example, there might be
uses for granularity like:
at_${phase}: as before
at_${phase}_all: as before
at_${phase}_${ABI}: single-abi-specific stuff executed before
at_${phase}, i.e., platform-specific configure tweaks
at_${phase}_best: stuff that needs to happen in ${BUILD_DIR}, but
should only happen for DEFAULT_ABI, i.e.:, compile documentation from
source, full emake installs to deploy unwrapped header files and
/usr/share/doc stuff, etc.
Cross-compile support might suggest a couple of additional sub-phases
(i.e.: a sub-phase to generate ${CBUILD}-targeted intermediate tools
(perhaps only during cross-compiles, but I really wish somehow that
could be coded just once, tagged, and the framework could decide
whether to do anything unusual with it based on context.
What are your thoughts? The patch is sent in reply to this mail.
Just saw your message that you are abandoning this proposal due to
lack of interest. I think the lack of comments is not particularly
surprising. How many people are actively getting their hands dirty
attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib?
I'd wager you're the only one, unless you want to count me over the
last 24 hours or so but I'm just
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
Dnia 2013-09-23, o godz. 13:59:48 Greg Turner g...@malth.us napisał(a): What are your thoughts? The patch is sent in reply to this mail. Just saw your message that you are abandoning this proposal due to lack of interest. I think the lack of comments is not particularly surprising. How many people are actively getting their hands dirty attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib? I'd wager you're the only one, unless you want to count me over the last 24 hours or so but I'm just dabbling and will probably lose interest. We have four active Gentoo developers in the team and one very helpful user. Plus a number of developers who are working in their narrow areas and supporting us indirectly. That's more than I expected, and the project has bright future. There are a few people who just like to trip us up but I think it'll all end up well in the end. As for this particular idea, I plan to make autotools-multilib use multilib-minimal and therefore inherit its phase functions. However, I'm still waiting for bug #485046 [1] to be resolved. [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny mgo...@gentoo.org wrote: [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046 Hey, that looks familiar... same basic problem exists in bzip2[static] src_compile: https://bugs.gentoo.org/show_bug.cgi?id=485690
Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils autotools-multilib
On Mon, Sep 23, 2013 at 2:16 PM, Michał Górny mgo...@gentoo.org wrote: [1]:https://bugs.gentoo.org/show_bug.cgi?id=485046 Hey, that looks familiar... same basic problem exists in bzip2[static] src_compile: https://bugs.gentoo.org/show_bug.cgi?id=485690
Re: [gentoo-dev] Move m68k, sh, s390 to ~arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/23/2013 04:41 PM, Markos Chandras wrote: On 09/23/2013 09:31 PM, Alexis Ballier wrote: On Mon, 23 Sep 2013 22:03:49 +0200 Agostino Sarubbo a...@gentoo.org wrote: Hello, the council has decided[1] to drop m68k, sh, s390 to unstable. If someone has something to say about, this is the last opportunity or in few days I will start to mark them as ~arch. is there a need to waste your time on this ? when mips was moved to ~arch it was done progressively: packages are moved to ~arch (~all) with new versions/revisions, no new stable keywords are added and old versions get removed. I agree. There is absolutely *no* reason to drop the keywords on existing packages and cause massive downgrades/upgrades for people (unless of course you want to increase your number of cvs commits which is a worrying argument on its own) The mass upgrades will happen when the profiles change ACCEPT_KEYWORDS from arch to ~arch no matter what. Fixing existing keywords just make things tidy. And ffs, ago has more commits than half the gentoo developers already, I'd be more worried if he wanted less commits. Ago, please keep up the good work, but after the profiles are updated. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQLYxAAoJEKXdFCfdEflK1XIQAJbGU2RKcAJi814P+PqPe4qU p/uC3Tlg06Sa5yHw/BvW1OXOj6Ah/RncRiiQKymQ4CxIp0cbFx4JJZMT3X4KoMMc Skw3u2JjQ3EQaxSpRF2pj1YMuwrajO7jS7143BwfKtH8diIfT5So5xCe05Mz2D2y QYusPIBAHsV4xU+DvCPYQ6cJvOqxXzcqqBLTGP6j27EnWgDuKfTrf5JI0FW5fYbD 4dSEMyyhfh2wgAilLjT63rspZgHajYTo6oVeE6Fv8RqXSotaGqTHiNT9HI8J3Q6S uQUiB3vGl0Af06SGBePvYNizhzklUTf6zlhNkSNg2yRG0ihFOmz4DrtLvhNnJfBJ mF/Mihlq3e0uNbxDag81v66vFnEJcrdZvgk8ty2Mdyc/Wo9HwQyY4p8g3tMtUJe+ B9jaIXD1HENQ9XkmqQrN9HJvgxw3S6eiqCBkgJ+3nUcjfUNbm9U2jbnmoQeZSYJt 5SPC42hbz5vZhdznhxvx24FgOyDHR1hgKHXYJJXqBGs91zYMz3f1lpw08ZLWM3F9 7NbPeDZ7YAhV5MeyjK5NAg/zrcJjHRCptc3WITR8u3mY48tzK+vLPqS1UVYxOfmV keJiN3k+lLgBlJzDfKfeEM7CZkOTNd7ADAkcdrC9eV5iprCfHzKaPm2jCjP24eC1 T/pgVMGmrpGPLOErHYGX =weaO -END PGP SIGNATURE-
