Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES="sign" on error
On 06/20/2013 05:27 AM, Zac Medico wrote: > On 06/19/2013 08:25 PM, Zac Medico wrote: >> On 06/19/2013 07:59 PM, "Paweł Hajdan, Jr." wrote: >>> I was surprised by repoman just dropping FEATURES="sign" . I'm aware >>> that at that time it has to commit an updated Manifest to prevent >>> breakages, so if gpg fails it proceeds, but is there something it could >>> do to check gpg sanity before committing anything? Failing at the password prompt (two chances on regular pinentry) also results in this behaviour. >> It seems the simplest way to go would be to do a test signature before >> commit, as suggested here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=298605 >> >> Is it okay to assume that everyone uses gpg-agent, so they won't have to >> enter the passphrase more than once? I have a remote (ssh) test-box to work on the tree, I don't want to cache my decrypted key there. Having the crypted version there is bad enough, but GPG_AGENT protocol only exchanges passwords (unlike SSH_AGENT). GPG_AGENT forwarding over SSH can be done with a general unix domain socket forwading hack [1]. > Or, we could skip the test signature if the GPG_AGENT_INFO variable is > not set? It's a clue, but the key-cache can be expired and a bad password entry can still result in failure. [1] http://25thandclement.com/~william/projects/streamlocal.html -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
Does this mean the QA lead finally gets to suspend people who are patently not suited for developing a stable distribution without asking devrel? Because last time we got into the same judge, jury, and executioner argument, which I guess was just sent for the gallows (pun intended). Mind, it's not like I disagree with at least one of the actions that you took recently, but given your surge approach I would like to point out that is not your task judging code quality, and yes that does make me uncomfortable, that you want to pick up the full power at once, and not collaborate with whom should have been involved in the process. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Wed, Jun 19, 2013 at 6:35 PM, Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > It is unfortunate to observe constant bullying, insults and trolling > across our public media. Developers have been warned over and over that > such behaviour is not acceptable and they should try to behave > properly. However, people have ignored such warnings for a very long > time. This ends today. > > The DevRel policy states that: > "If the issue is deemed critical, the developer in question may have > his or her access suspended while a vote takes place. In such > situations, the Developer Relations lead may act without a vote of the > remaining Developer Relations team; this power is granted by Council. > Except in critical situations where immediate action is required, such > disciplinary action is determined by members of the Developer Relations > project."[1] > > For me, this problem is critical. Devrel is working on formalizing a new > policy, and we will announce news on this soon. In the meantime, to > prevent further escalations, I will use my lead powers to request > immediate bans whenever I see one of you violate the CoC[2] and ignore > the previous warnings. > > My fellow developers, it's time you finally realize that > you are part of a community and you must learn to behave > and respect each other even if you have different technical views. > We are all people sharing a common interest: Gentoo. > > [1] http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2 > [2] http://www.gentoo.org/proj/en/council/coc.xml > > - -- > Regards, > Markos Chandras - Gentoo Linux Developer > http://dev.gentoo.org/~hwoarang > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.20 (GNU/Linux) > > iQJ8BAEBCgBmBQJRwev1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw > OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88CgkQAMPF0Uf8r92+ne4D1CghUQKC > ujo2B9UDBx6jOs//XZ6A+az2bWQdBUm+ca6v755VasVMnDmcfHM+0+ibqtPcVMaK > XHUMZhkgok9KlWptKqJOdSLlInY2KhHmA0jjktUyByIILgMKcqlL5pVd/jUN6bXU > y54nDCgne4zx0fiK0QGV6hzRqCn9RFtxTsW4qIoxRIaM7oME0Zm6LmdFJrFLhpPC > 9N9JDuxKdKgmN4njT3sNDa2dQD/InZm+k2ZejLFWZqmlvbo54xQTA2YvjrRa+jTr > yJjLTiKvt7pZLZrF7QlzvQULR2966Jlh3wdXhDJRrvvIFgWCZCW7x1VatnLde+z0 > fM5cAuBWCVHyKFJUJXlgvzPJVTmBD4mjJUzhI9Co6eJbkauZ1VKzlHzDZPsdDgrw > DmuXUfSsll+1tIg8Mjq0CAO8jqvTMQKbdcrthMAvcpWw8FKa+HIddFa60H0sKeXH > TmXUPLP+7RwgLIoMtTelrpb5yoJsNeFG9Hlhwhn6Sh68ItYKkeg7Qopi8IhpdmKR > x3mrWXXY1k4SdChhQ4vgiQLOGA7KJquZQJ43i1phe7RGvsXHBU9M65/IHNkWxODE > ZdwS20di9WoIulvep9P3b0wHsY/zL4HLmQEjPsqriGScZdJM/bcIpu1Dn34ZgXhy > 6NvYvqpCfyoXN757mwOs > =2cCK > -END PGP SIGNATURE- > >
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES="sign" on error
On 06/19/2013 08:25 PM, Zac Medico wrote: > On 06/19/2013 07:59 PM, "Paweł Hajdan, Jr." wrote: >> I was surprised by repoman just dropping FEATURES="sign" . I'm aware >> that at that time it has to commit an updated Manifest to prevent >> breakages, so if gpg fails it proceeds, but is there something it could >> do to check gpg sanity before committing anything? > > It seems the simplest way to go would be to do a test signature before > commit, as suggested here: > > https://bugs.gentoo.org/show_bug.cgi?id=298605 > > Is it okay to assume that everyone uses gpg-agent, so they won't have to > enter the passphrase more than once? Or, we could skip the test signature if the GPG_AGENT_INFO variable is not set? -- Thanks, Zac
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES="sign" on error
On 06/19/2013 07:59 PM, "Paweł Hajdan, Jr." wrote: > I was surprised by repoman just dropping FEATURES="sign" . I'm aware > that at that time it has to commit an updated Manifest to prevent > breakages, so if gpg fails it proceeds, but is there something it could > do to check gpg sanity before committing anything? It seems the simplest way to go would be to do a test signature before commit, as suggested here: https://bugs.gentoo.org/show_bug.cgi?id=298605 Is it okay to assume that everyone uses gpg-agent, so they won't have to enter the passphrase more than once? -- Thanks, Zac
[gentoo-dev] repoman commit unexpectedly drops FEATURES="sign" on error
Today an interesting thing happened to my repoman, as I was committing a change: >>> Creating Manifest for /home/ph/gentoo-x86/dev-lang/v8 gpg: no default secret key: Unusable secret key gpg: /home/ph/gentoo-x86/dev-lang/v8/Manifest: clearsign failed: Unusable secret key !!! !!! gpg exited with '2' status !!! Disabled FEATURES='sign' /var/cvsroot/gentoo-x86/dev-lang/v8/Manifest,v <-- Manifest new revision: 1.321; previous revision: 1.320 Indeed my private key on that machine was expired: pub 1024D/30427902 2009-08-05 [expired: 2013-06-10] But after refreshing it (I have extended the expiration date) it is fine: pub 1024D/30427902 2009-08-05 [expires: 2014-02-10] I was surprised by repoman just dropping FEATURES="sign" . I'm aware that at that time it has to commit an updated Manifest to prevent breakages, so if gpg fails it proceeds, but is there something it could do to check gpg sanity before committing anything? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On 06/19/2013 09:15 PM, g...@malth.us wrote: > Sorry to hear you have such a low opinion of the socialization of Gentoo > developers. Since I'm not one of them, I'll just put forth my 2c in on > this, without fear of "consequences." Yet even users not behaving will get a friendly warning and might be restricted in their access to our media. > Am I the only one who feels that trolling, abuse, and so forth, are largely > in the eye of the beholder, and that lively, impassioned, constructive > debate may seem to many readers like hyperbole and ad hominem attack? So better to try to think twice and write when you are sure you are as clear as possible =) > As long as I can remember, candid and even ostensibly hostile debate and > argument have been a part of the Gentoo process (the same goes for a great > many open-source projects). Thus far, although not without some frustration > and angst, Gentoo has weathered these storms, and somehow managed to make > sound decisions based on technical and practical merit, after all is said > and done. Sure, but since we are getting more and more people burnt by the process and nothing is gained or lost between: "You suck and this idea is not going to fly at all" and "I'm sure it will not work" > Have you considered the possibility, Markos, that, although not pretty to > look at, such conflicts provide an important cathartic channel to relieve > certain "psychological pressures?" In environments where everyone is > expected, on pain of discipline, to "be civil" all the time, my experience > is that folks start to build up resentments which eventually "explode" > forth, spectacularly, despite -- indeed, one might say, because of -- their > best efforts to conform to those expectations. You can be direct and yet not infringe the CoC. > IIRC, Gentoo already has rules forbidding a laundry-list of antisocial > behaviors like racism, sexism, threats of violence, and so forth, and some > provisions in place to handle violators of that policy, does it not? Yes and now is being enforced fully. > Further -- and please take this as more of a rhetorical flourish than a > genuine concern, but, I wonder, whose job it is to muzzle you, Markos, if > you, yourself get out of line, and will they dare perform it? The rest of devrel still does have full power, the quick action of the devrel leader is just a in between once we got to agree on the quick-action protocol. We have a lengthy procedure for major infringement and it doesn't work for small infringements. > Has a clear consensus emerged that existing rules are not strong enough? Is not a matter of rules, but procedures to enforce the rules. > Or perhaps, are a vocal minority just butt-hurt about some particular > discussion that happened recently? I'm asking fully in earnest, and I > sincerely hope -- and genuinely presume -- I don't have to worry that I'll > be muzzled for doing so, on the basis that I'm "trolling" or what-have-you. No minorities had been considered, vocal or silent. > Why should I even feel the need to say so? Perhaps, that is my problem and > sheer paranoia, but surely, you can appreciate how such an announcement can > potentially have certain "chilling effects," and that the merits of strict > enforcement of such well-intended policies are not necessarily so clear as > they might seem on first glance. Having a gentler tone would just keep the technical field less prone to be encrusted with pointless emotional hindrances. Everybody likes to side between Good and Evil, here we should just have Working and Broken. lu PS: I'd advise to try to tone down another notch your vocabulary if you are afraid of getting some penalty for foul language.
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On Monday 17 June 2013 16:37:06 Rick "Zero_Chaos" Farina wrote: > On 06/17/2013 04:19 PM, Diego Elio Pettenò wrote: > > On 17/06/2013 17:54, Rick "Zero_Chaos" Farina wrote: > >> I make all my files with "tar cJf" > >> > >> zero@ozzie ~ % file /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz > >> /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz: XZ compressed data > > > > cJ with _current_ tar will generate XZ > > cJ with _past_ tar could generate lzma > > xJ with _current_ tar will extract both XZ and lzma > > zJ with _past_ tar will only extract lzma > > tar for the last several years properly and automatically detects the > format of the input using just 'x'. This is true for gnu and bsd tar > which should cover all of gentoo. and that relies on the magic being in the output format which, as we pointed out, wasn't the case. it's one of the reasons why the XZ format came to be. build lzma-utils and compress some files and see how well tar & file handle it: http://tukaani.org/lzma/ -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On Wed, Jun 19, 2013 at 3:15 PM, wrote: > Am I the only one who feels that trolling, abuse, and so forth, are largely > in the eye of the beholder, and that lively, impassioned, constructive > debate may seem to many readers like hyperbole and ad hominem attack? Hence my comment that this is a bit of a sledgehammer approach. I really wouldn't want to see "current head of devrel becomes judge, jury, and executioner" as a long-term strategy. However, the status quo is not acceptable either. He did say he was working on long-term proposals, and I think we ought to at least let him offer his suggestions before we jump down his throat. If things get out of hand as a community I'm sure we'll deal with it, but the pendulum is far to the opposite side right now. The fact is that we already trust every Gentoo dev with the equivalent of root on our systems, so I think we can give Markos the benefit of the doubt when he aims to reform Devrel. Rich
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On Wed, Jun 19, 2013 at 03:43:41PM -0400, Alexandre Rostovtsev wrote: > Gentoo developers have been resigning from the project because they got > burned out by dealing with ad-hominems, insults, and flames. I do not see CoC > enforcement as some sort of plot to enforce groupthink or silence debate, but > as an attempt to fix the real problem of burnout and talent drain. Agreed. This has nothing to do with chilling good technical debate. People are leaving the project because they are getting tired of the flaming, personal attacks, etc, and I am fully behind devrel doing something about that. imo it should have been done a long time ago. William signature.asc Description: Digital signature
RE: [gentoo-dev] Temporary DevRel actions for CoC violations
Gentoo developers have been resigning from the project because they got burned out by dealing with ad-hominems, insults, and flames. I do not see CoC enforcement as some sort of plot to enforce groupthink or silence debate, but as an attempt to fix the real problem of burnout and talent drain.
RE: [gentoo-dev] Temporary DevRel actions for CoC violations
on Wed, 19 Jun 2013, at 10:35, Markos Chandras thusly quipped: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > It is unfortunate to observe constant bullying, insults and trolling > across our public media. Developers have been warned over and over that > such behaviour is not acceptable and they should try to behave > properly. However, people have ignored such warnings for a very long > time. This ends today. Tough talk. We'll see... > The DevRel policy states that: "If the issue is deemed critical, > the developer in question may have his or her access suspended > while a vote takes place. In such situations, the Developer > Relations lead may act without a vote of the remaining Developer > Relations team; this power is granted by Council. Except in > critical situations where immediate action is required, such > disciplinary action is determined by members of the Developer > Relations project."[1] > > For me, this problem is critical. Devrel is working on formalizing a new > policy, and we will announce news on this soon. In the meantime, to > prevent further escalations, I will use my lead powers to request > immediate bans whenever I see one of you violate the CoC[2] and ignore > the previous warnings. Hmm... that's a serious responsibility you've assigned yourself. I hope you'll be a benevolent, impartial and reasonable interim judge, jury and muzzler. > My fellow developers, it's time you finally realize that > you are part of a community and you must learn to behave > and respect each other even if you have different technical views. > We are all people sharing a common interest: Gentoo. > > [1] http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2 > [2] http://www.gentoo.org/proj/en/council/coc.xml Sorry to hear you have such a low opinion of the socialization of Gentoo developers. Since I'm not one of them, I'll just put forth my 2c in on this, without fear of "consequences." Am I the only one who feels that trolling, abuse, and so forth, are largely in the eye of the beholder, and that lively, impassioned, constructive debate may seem to many readers like hyperbole and ad hominem attack? As long as I can remember, candid and even ostensibly hostile debate and argument have been a part of the Gentoo process (the same goes for a great many open-source projects). Thus far, although not without some frustration and angst, Gentoo has weathered these storms, and somehow managed to make sound decisions based on technical and practical merit, after all is said and done. Have you considered the possibility, Markos, that, although not pretty to look at, such conflicts provide an important cathartic channel to relieve certain "psychological pressures?" In environments where everyone is expected, on pain of discipline, to "be civil" all the time, my experience is that folks start to build up resentments which eventually "explode" forth, spectacularly, despite -- indeed, one might say, because of -- their best efforts to conform to those expectations. IIRC, Gentoo already has rules forbidding a laundry-list of antisocial behaviors like racism, sexism, threats of violence, and so forth, and some provisions in place to handle violators of that policy, does it not? Further -- and please take this as more of a rhetorical flourish than a genuine concern, but, I wonder, whose job it is to muzzle you, Markos, if you, yourself get out of line, and will they dare perform it? Has a clear consensus emerged that existing rules are not strong enough? Or perhaps, are a vocal minority just butt-hurt about some particular discussion that happened recently? I'm asking fully in earnest, and I sincerely hope -- and genuinely presume -- I don't have to worry that I'll be muzzled for doing so, on the basis that I'm "trolling" or what-have-you. Why should I even feel the need to say so? Perhaps, that is my problem and sheer paranoia, but surely, you can appreciate how such an announcement can potentially have certain "chilling effects," and that the merits of strict enforcement of such well-intended policies are not necessarily so clear as they might seem on first glance. Wishing you the best in your effort to make Gentoo a more civil and friendly community, -gmt <>
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
On Wed, Jun 19, 2013 at 06:35:49PM +0100, Markos Chandras wrote: > For me, this problem is critical. Devrel is working on formalizing a new > policy, and we will announce news on this soon. In the meantime, to > prevent further escalations, I will use my lead powers to request > immediate bans whenever I see one of you violate the CoC[2] and ignore > the previous warnings. Thank you for stepping up and working to address this, it's much appreciated. greg k-h
[gentoo-dev] Temporary DevRel actions for CoC violations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, It is unfortunate to observe constant bullying, insults and trolling across our public media. Developers have been warned over and over that such behaviour is not acceptable and they should try to behave properly. However, people have ignored such warnings for a very long time. This ends today. The DevRel policy states that: "If the issue is deemed critical, the developer in question may have his or her access suspended while a vote takes place. In such situations, the Developer Relations lead may act without a vote of the remaining Developer Relations team; this power is granted by Council. Except in critical situations where immediate action is required, such disciplinary action is determined by members of the Developer Relations project."[1] For me, this problem is critical. Devrel is working on formalizing a new policy, and we will announce news on this soon. In the meantime, to prevent further escalations, I will use my lead powers to request immediate bans whenever I see one of you violate the CoC[2] and ignore the previous warnings. My fellow developers, it's time you finally realize that you are part of a community and you must learn to behave and respect each other even if you have different technical views. We are all people sharing a common interest: Gentoo. [1] http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2 [2] http://www.gentoo.org/proj/en/council/coc.xml - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRwev1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88CgkQAMPF0Uf8r92+ne4D1CghUQKC ujo2B9UDBx6jOs//XZ6A+az2bWQdBUm+ca6v755VasVMnDmcfHM+0+ibqtPcVMaK XHUMZhkgok9KlWptKqJOdSLlInY2KhHmA0jjktUyByIILgMKcqlL5pVd/jUN6bXU y54nDCgne4zx0fiK0QGV6hzRqCn9RFtxTsW4qIoxRIaM7oME0Zm6LmdFJrFLhpPC 9N9JDuxKdKgmN4njT3sNDa2dQD/InZm+k2ZejLFWZqmlvbo54xQTA2YvjrRa+jTr yJjLTiKvt7pZLZrF7QlzvQULR2966Jlh3wdXhDJRrvvIFgWCZCW7x1VatnLde+z0 fM5cAuBWCVHyKFJUJXlgvzPJVTmBD4mjJUzhI9Co6eJbkauZ1VKzlHzDZPsdDgrw DmuXUfSsll+1tIg8Mjq0CAO8jqvTMQKbdcrthMAvcpWw8FKa+HIddFa60H0sKeXH TmXUPLP+7RwgLIoMtTelrpb5yoJsNeFG9Hlhwhn6Sh68ItYKkeg7Qopi8IhpdmKR x3mrWXXY1k4SdChhQ4vgiQLOGA7KJquZQJ43i1phe7RGvsXHBU9M65/IHNkWxODE ZdwS20di9WoIulvep9P3b0wHsY/zL4HLmQEjPsqriGScZdJM/bcIpu1Dn34ZgXhy 6NvYvqpCfyoXN757mwOs =2cCK -END PGP SIGNATURE-
Re: [gentoo-dev] netsurf.eclass proposal
On Wed, Jun 19, 2013 at 8:30 AM, Michael Weber wrote:
> On 06/19/2013 02:16 PM, Michał Górny wrote:
>> Dnia 2013-06-19, o godz. 14:09:26
>> Michael Weber napisał(a):
>>
>>> - multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
>>
>> And why exactly do you need multilib for a web browser?
>>
>
> No need for the browser package (just fun) but I'd like to provide it
> for the ten library packages.
>
I guess the follow-up question is this:
Are there any consumers of these libraries which require the 32-bit
(x86) ABI to be installed?
I'm all for having fun, but I think the intent was to keep the
multilib-build eclass usage to a minimum. If there is some pre-built
32-bit application that needs them, then that's fine. Otherwise,
you'll end up installing libraries that will never be used.
Re: [gentoo-dev] netsurf.eclass proposal
Michael Weber schrieb:
> On 06/19/2013 02:16 PM, Michał Górny wrote:
>> Dnia 2013-06-19, o godz. 14:09:26
>> Michael Weber napisał(a):
>>
>>> - multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
>>
>> And why exactly do you need multilib for a web browser?
>>
>
> No need for the browser package (just fun) but I'd like to provide it
> for the ten library packages.
>
If you have any library build systems depending on ABI-specific
binaries, you should wrap the binaries, otherwise you will have to add
and maintain custom hacks for all consumers and for the complete
lifetime of the consumers.
If you want to add such wrapper, you can look into the multilib-portage
overlay for such a wrapper, which has now been working and tested for
some years.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] netsurf.eclass proposal
On 06/19/2013 02:16 PM, Michał Górny wrote:
> Dnia 2013-06-19, o godz. 14:09:26
> Michael Weber napisał(a):
>
>> - multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
>
> And why exactly do you need multilib for a web browser?
>
No need for the browser package (just fun) but I'd like to provide it
for the ten library packages.
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: [gentoo-dev] netsurf.eclass proposal
Dnia 2013-06-19, o godz. 14:09:26
Michael Weber napisał(a):
> - multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
And why exactly do you need multilib for a web browser?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] netsurf.eclass proposal
Hello,
I'd like to add a new eclass for www-client/netsurf related ebuilds and
seek your review and approval. I'll add it in two days, if unchallenged.
=== Motivation ===
The browser projects started out as a stray set of components [1], some
without releases.
In the meantime, all stuff is presented on one web-git [2] and
download page [3]. The browser components is available as bundled tar
[4] and solo [5].
[1] http://www.netsurf-browser.org/projects/
[2] http://git.netsurf-browser.org/
[3] http://download.netsurf-browser.org/libs/releases/
[4] http://download.netsurf-browser.org/netsurf/releases/source/
[5] http://download.netsurf-browser.org/netsurf/releases/source-full/
Handling this the "Gentoo way" I added all components as single
packages. All relying on the same - separate - buildsystem tarball.
The presented eclass is intended to master this buildsystem for
- binary components (www-client/netsurf, dev-libs/nsgenbind)
- shared and static library components
- multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
- verbose building
- repecting FLAGS, warn about stray -O? and -g flags in components.
and reduce code duplication within the ebuilds.
=== Eclass consumers (flattened DEPENDS tree) ===
dev-libs/libwapcaplet-0.2.0
dev-libs/libparserutils-0.1.2
dev-libs/libcss-0.2.0
net-libs/libhubbub-0.2.0
net-libs/libdom-0.0.1
dev-libs/libnsfb-0.1.0
dev-libs/nsgenbind-0.0.1
media-libs/libnsbmp-0.1.0
media-libs/libnsgif-0.1.0
media-libs/librosprite-0.1.0
media-libs/libsvgtiny-0.1.0
www-client/netsurf-3.0
=== Implementation ===
see attachment
[future] add live git multiple repo fetch voodoo.
=== Concerns ===
This eclass relies on multilib-minimal and the "inherit" tree
netsurf -> multilib-minimal -> multilib-build -> multibuild might be a
little fragile.
Only 12 consuming packages. No other rdeps, yet, so the whole set could
have been done in one ebuild.
*My first eclass* so there might be issues with bash array quoting.
Are the DEPEND and IUSE inside the eclass added to the ebuilds?
It looks ok, but I'd better ask.
Any good way to disable the CFLAGS sanity check on
(dev-libs/nsgenbind should be relocated to dev-utils)
( www-client/netsurf[abi_x86_32] on amd64 misses working curl version. )
=== TL;DR ===
see attachment for the real thing.
Constructive feedback is very welcome.
Thanks
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
=== eclass/netsurf.eclass ===
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: netsurf.eclass
# @MAINTAINER:
# Michael Weber
# @BLURB: Handle buildsystem of www.netsurf-browser.org components
# @DESCRIPTION:
# Handle unpacking and usage of separate buildsystem tarball and manage
# multilib build, static-libs generation and debug building.
#
# Supports PATCHES and DOCS as in base.eclass
case ${EAPI:-0} in
0|1|2|3|4) die "this eclass doesn't support EAPI<5" ;;
*) ;;
esac
inherit base toolchain-funcs multilib-minimal
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install
LICENSE="MIT-with-advertising"
# @ECLASS-VARIABLE: NETSURF_BUILDSYSTEM
# @DESCRIPTION:
# Select version of buildsystem tarball to be used along the component
# defaults to buildsystem-1.0
NETSURF_BUILDSYSTEM="${NETSURF_BUILDSYSTEM:-buildsystem-1.0}"
# @ECLASS-VARIABLE: NETSURF_BUILDSYSTEM_SRC_URI
# @DESCRIPTION:
# Download link for NETSURF_BUILDSYSTEM, add to SRC_URI iff set explicitly.
NETSURF_BUILDSYSTEM_SRC_URI="http://download.netsurf-browser.org/libs/releases/${NETSURF_BUILDSYSTEM}.tar.gz
-> netsurf-${NETSURF_BUILDSYSTEM}.tar.gz"
# @ECLASS-VARIABLE: NETSURF_COMPONENT_TYPE
# @DESCRIPTION:
# Passed to buildsystem as COMPONENT_TYPE, valid values are
# lib-shared, lib-static and binary. Defaults to "lib-static lib-shared"
NETSURF_COMPONENT_TYPE="${NETSURF_COMPONENT_TYPE:-lib-static lib-shared}"
# @ECLASS-VARIABLE: SRC_URI
# @DESCRIPTION:
# Defaults to http://download.netsurf-browser.org/libs/releases/${P}-src.tar.gz
# and NETSURF_BUILDSYSTEM_SRC_URI.
if [ -z "${SRC_URI}" ] ; then
SRC_URI="http://download.netsurf-browser.org/libs/releases/${P}-src.tar.gz
${NETSURF_BUILDSYSTEM_SRC_URI}"
fi
IUSE="debug"
if has lib-static ${NETSURF_COMPONENT_TYPE} ; then
IUSE+=" static-libs"
fi
DEPEND="virtual/pkgconfig"
# @FUNCTION: netsurf_src_prepare
# @DESCRIPTION:
# Run base_src_prepare for PATCHES support and multilib_copy_sources for
# in-source build.
netsurf_src_prepare() {
base_src_prepare
multilib_copy_sources
}
# @ECLASS-VARIABLE: netsurf_makeconf
# @DESCRIPTION:
# Configuration variable bash array to be passed to emake calls.
# Defined at netsurf_src_configure and can be altered afterwards.
# @FUNCTION: netsurf_src_configure
# @DESCRIPTION:
# Setup netsurf_makeconf and run multilib-minimal_src_configure.
# A default multilib_src_configure is provided by this eclass.
netsurf_src_configure() {
