Re: [gentoo-dev] new developers' keyword requests
On Fri, 20 May 2016 16:00:02 +0200 Jeroen Roovers <j...@gentoo.org> wrote: > On Thu, 19 May 2016 18:36:22 -0700 > Daniel Campbell <z...@gentoo.org> wrote: > > > To make sure I understand what you're getting at, are you saying > > some devs get on board and then request to add keywords to packages > > that they already maintain? If said arches are already supported in > > Gentoo I see little problem with that, especially if they intend on > > being part of the arch testing team for that arch or have access to > > the hardware. > > I am not talking about adding architecture keywords to profiles/. > I am talking about adding architecture keywords to ebuilds. > > > Regards, > jer > Firstly I think previous replies have been de-railed on talking about new alternate arches, which personally I think is the last thing we need. If there is any confusion it is because the term keyword, like most terms in I.T. gets pushed and pulled and stretched until it breaks. To my understanding, KEYWORDS are arches. But being told to 'keyword' a package could mean perhaps, well, Hu knows. Supporting users doing just this lately, I have come across this a few times. Users and new devs are expected to be very ignorant of minor arches, and despite having docs already informing them that they are short staffed and have enough to do, the practicalities of how and why to keyword request or not are still veiled in mystery. Users want to keyword according to what they see supported upstream just because they can. They appear to need it made manually clear to them that there are qualifiers and conditions for putting something up for keywording. These also I believe are as much as mystery to users as they are to devs. How to establish a level of desire form userland to have gentoo support the arch in the package?? How to establish sane rationale for it being put up for stable?? The last I heard was along the lines of, well, only put it up if it has already been put up in the past.(someone in the past had a check list?) If anyone, the members of the arch teams might have some insights based upon first hand dealing with packages and their categories. Frankly, how you can expect or achieve users and new devs to assess these is more the issue, and I do not see there is any obvious path of becoming informed of the interest of an invisible audience; userland Hu knows -- kind regards Ian Delaney
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, 7 May 2016 23:25:58 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> On Sat, 7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel" <hd_bru...@gentoo.org> wrote:
>
> > commit: 66afcab271f65b97330e610040ad3acc1b812a03
> > Author: Joerg Bornkessel gentoo org>
> > AuthorDate: Sat May 7 21:18:48 2016 +
> > Commit: Joerg Bornkessel gentoo org>
> > CommitDate: Sat May 7 21:18:48 2016 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> >
> > fixed einstall vs. emake install for eapi=6
> >
> > eclass/vdr-plugin-2.eclass | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> > index ae09a34..65f1409 100644
> > --- a/eclass/vdr-plugin-2.eclass
> > +++ b/eclass/vdr-plugin-2.eclass
> > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
> > local SOFILE_STRING=$(grep SOFILE Makefile)
> > if [[ -n ${SOFILE_STRING} ]]; then
> > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install
> > }}
> > - einstall ${BUILD_PARAMS} \
> > + if [[ ${EAPI} == 6 ]]; then
> > + emake install ${BUILD_PARAMS} \
> > + else
> > + einstall ${BUILD_PARAMS} \
> > + fi
> > ${BUILD_TARGETS} \
> > TMPDIR="${T}" \
> > DESTDIR="${D}" \
> >
>
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
>
Do you seriously expect us to sit and absorb this form of pious
put down? From one who knows far better who is entitled to speak down
to colleagues as is completely lacking a cerebral cortex? Those times
are drawing to an end. Did anyone ever teach you to treat folk in such
manner and expect them to respect it? I don't think so
Not over my dead cvs perhaps
- --
kind regards
Ian Delaney
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1
iQJ8BAEBCgBmBQJXNZW5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw
QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6mzcP/1BmrZw/EiuPlJh6MuufJ1/U
Zlg26d99Vvvji0VVHcz9lrDhk6ubYB3WrcrG3E2M1pVwXDTuy+z5ez7RXvuUMSSY
XiP4uWVWmlQoBlkAzAAvzKKVNsQvfOCif1x/b59Qjm9qAKQOwawTzCjOCHIrB08V
EXFuuo5gpHfkq5vtU7jK22/6Zo56w+A7xfgSKl96byepA4F++3vDH4kX3XTBVmtE
vlPn230CQqgP/YMZ/TBcQ4AE3r0fxPmGnAniZn/o5v2Zpzo1SZjrRlYJXDq3PnIa
Rjs6fWEvfA7xu8wDt05Xz+8bzVXmS//1ga0VB1dmcNlVelUY7Pwi1kR+nUF174Vo
/xLlTvK/EboliAMbviRwX9extWycWCB+iyBH/RkazaQQmSiW5tHlVPx8Wu7LiRay
O8eFks7LgenetNBymMaiPBNZJMo/I+Fnebk43qx0XfUyuANLsg3JnsY4WG+Evcjc
3XqkTePuDyFLQEgQlU417JSFRkyZ0odMqpVShqOxgv4EA/HAiCpWCHkE1ZuiLi1V
7bKQodOclD3jTmy6eJgLpoEhqphXCaX9bl5QcFyu3+La8r3YXOqErCbOECoJy0Np
lXwOCKZ9kvcv8iLygxKqP/0rxuAP0kzs5NSWd2zhHLRBihNvP+xkc2Pi4ztRT2LN
Hju+wa0/WdLLTEPCAe78
=4iJI
-END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 7 Feb 2016 04:13:38 -0800 Daniel Campbell <z...@gentoo.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/07/2016 03:09 AM, Michał Górny wrote: > > On Sun, 7 Feb 2016 11:38:27 +0100 "M.B." <tombo...@sina.cn> wrote: > > > [...] > ies#Games_team_policies_issue > [...] > (A mere deprecation notice). > [...] > > > > For reference, this is the reference decision: > > > > https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt > > > > I'm going to open a bug asking games team how they're going to > > proceed. > > > Please let us know when you do; there are a few Humble Bundle games > I'd like to bring to the tree and I, too, don't have much to go on as > far as guidelines beyond our usual. > > - -- > Daniel Campbell - Gentoo Developer It's not just M.B. being confused about this. There appears to be a spurt of interest by other users to tackle games - -- kind regards Ian Delaney -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWuqUkXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6QaQQAJ1yzMeSO6JrFjdzEq1sTILr Jwuf7NvdEdr33IyMbcwji03CLvR6+yMwtVOlOMYaJM1ZzAZLw+MFbjiTQzNTMeLN S49AzHwyWs6WgQhD9I4Flr9oOm5HraU/yyE7JK+42EXcW5dkXCAXDp6bLI0AEiYJ DX3t8285l7GiytnK4/sHvyF1LkXoz2Jpk8n9bfUu8q0enWFHcNKA6ZoH1OqFAg/Z kkLr3R8DlITdAAsQwSolsUf03iIXbxCy7d89Pskj4+lMiw8Ju8IK+fh2baRWlHDm x3xXmF1foaR0DJCTQzRZV+DTBpk5ecxX9dnHoYwg/y4d0Oi2Jf0GYLLVjYK8yc3K sWJW/9NkNDfTYEzLjrTUYYzlQal+jTzOL8wYBbwmz7Yaft4lc/4IKwQMk5ME9sYD 3b9Kh8AWfyXaBRFwczCoxIicU2MZCdE8mFCQH/8Yx1Ai4unGn6sYgM2Teq4zgcir zhj8/r7/Ke3CtrFy2QTDlN1mC+9A5aJBUU/pl94W336NP7OeNjaDoDyDhXVOuQjx ervuud3cGgYRUWQ6+MVIMXYroVhltFxWdGDNAOcKPsNsgh9NU8t9Z6WFDev+PgdP RHVv5nQJWTkW3G9I4R2Zh03bLO9S0ZTdA5om8pdJW9yid/TSFtzTgv6XAPJGiBcR o4i+IEEjhhxQOEWsnmZA =/aU1 -END PGP SIGNATURE-
[gentoo-dev] abusive behaviour / communications from a user
Members of comrel The source of concern with possible violations of CoC source form Bug 566168, which I know has already been perused by dilfridge. The inflammatory tone of the content is self evident. While my comments or reply may return their own critique, they always observed the practice of focussing on his comments and replies and not the person. In reply, he does blatantly accuse the replies as being defamatory. Conclusions / judgements of this nature are for you to ascertain. In discussion with another developer of the list of members of the project, we agreed that the anti-social and troll like responses of the user warrant bringing to the attention of comrel for overall assessment. The main act of offence occurred in fact outside the bug itself. The user took the id of the keen user awilfox, sourced the personal blog, and entered comments that were in essence, bigotted and prejudicial and in today's society frowned upon. These comments will have to be lodged separately as a second form of 'evidence'. In short, the user concludes that he has been disrespected and implies that we cannot work together as a unit, and that he has been wronged, apparently some time in the past of which I know nothing. Please consider this and assess as you see fit. -- kind regards Ian Delaney
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
emains, traditionally, an endemic gap in the fabric that is modern gentoo environment. 5. At the risk of sounding like Patrick, gentoo lacks some forms of documentation pertaining to established proxy maintainers and to forms of stats analysis. In discussions, points were raised regarding the gathering of stats data re packages' tally of downloads and instances of emerging into a gentoo system. Most of the desired stats appear to lack any form of tools available to gather and report data that would prove helpful in evaluating packages of either the m-w or m-n lists. The topic of recruitment and recruiting are tied, but imo, quite disparate. - -- kind regards Ian Delaney -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWpOAmXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6ECAQAJnDqx7EBbAa8tl5/A9HiF6t 8ajaf9NqJYYQZApNjaa6SY60/EP7a5trYW7QOGxE8EvRpNDYlxRIzTZZmb2uCsER GOgovqYAelaPhwBBGYGGU91i4wKtJ+U+ujrFRLb3eE9Bsv3NcOOzhRIn6zWr9KuB OBkwYHi37xc8WUsJKR7rBjmOx+OG5Izs5z4gRF3BZVV3+MHgH2zb6Q4W4u13lhOg BtYBqN5/Y52bzFKgcX0tYeTt9xoYI/Zk1szwX1M3rYizKmYGZwh/lCmUO7PA+Q8V ZoRhHAaZIgm4eRScnoQBWWm8aStw9nFFRIWcxRKVIx5aEYODWcFz6JEO/zKseNqD LH/67ssc1/y4JIw0MbZ1YyFrouATs0TnSgbJzKAiMLSJsjHI+EEjdKyEhlRVLVHk FjM3RzyGTcZWfzFBWXKdYgfCR2GzJZ4Q3rYMZKZARW2t1om1pRJo6JK66JHDErVA GQiQpEsGQgjOFmp1DyhEJpziBIuTL6l8TwaLamqvJeWhgFEzuaqqfv+Lh/5H8jFB ghRYkeGiqX6p1pPV+bBYNfxrAlpNeNRoyyKt8Jupuwnr63QA1QevBko/2ngfNgGl 5OQBJhcjs+BJ4KlS/3X1v5rKqSK/eLf1Yy87CY52+2P2rEabfKjB8JHxzu6E7O7/ XaQEesz4Egp1ZOrfMJC+ =sq9P -END PGP SIGNATURE-
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 21 Jan 2016 16:30:14 -0800 Daniel Campbell <z...@gentoo.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 01/21/2016 02:41 PM, waltd...@waltdnes.org wrote: > > On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote > [...] > [...] > [...] > > > > I think you misunderstood Roy. He was speaking about > > "unmaintained but perfectly functional software". You're talking > > about "a package that clearly doesn't build or otherwise simply > > doesn't work, could not have worked for past 3 years". Between > > those 2 extremes will be many cases of > > doesn't-work-for-me/works-for-me. Who'll be the final arbiter? > > > > Maybe we should start a "gentoo-ebuilds" mailing list to help > > regular users learn the ins and outs of making ebuilds. Once > > regular users run a lot of their own ebuilds from their local > > overlays, then it would be possible to do draconian pruning of the > > "official portage tree", without so adversely affecting regular > > users. This would fit in with the mantra of Gentoo being about > > freedom of choice. > > > > E.g. I use Pale Moon, a fork of Firefox. Currently, I have to > > build as regular user, su, and copy the binary to /usr/local. You > > can see "Walter's excellent adventure" as I learn the build > > process at... > > https://forum.palemoon.org/viewtopic.php?f=37=10002 > > > > I'd like to have Portage manage the process. The ebuild from > > Firefox should serve as a template, because they both use the same > > weird Mozilla build setup. The main change should be where the > > source is pulled from. > > > > The idea sounds nice, but there's already the devmanual to cover > ebuild development, and now that the gentoo repo is in git, any > ebuilds that get treecleaned can be fetched again through history, and > users can then add those to their personal overlay(s) and keep the > piece if they break. > > I like the idea of encouraging people to learn good ebuild writing, > but who really has the time and skill to teach it? > me. Been doing it for months. You had not noticed? via #gentoo-proxy-maint, which I made from scratch, despite the notion initially being discounted by one mrueg. He now is a colleague in the channel. > - -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWoXgPAAoJEAEkDpRQOeFwPvUP/1cOdVx0Mnm2yF6DU9BCXCzn > 6LdE4/g05CnkggQkQEPsL6U+oiU/C2wu9nsSSRwrHNKEoIvly/pZEz75+FFoEnF5 > RQTltJQi4lyG63bzaHYCx1nzmqAHBVbCBGDPqEC8whV8C8YAufk3SxqocBaIsD5Z > IbujCelJNGvRGBPmsIOD38aaVbcyJZFGG+m9nTTJyRQtdFGxfccE/K+xuZMLKFS/ > BQkyJdAyvGscRBLAx80o5TgZ+h7BTNW78b8aIubWaeMyqYrvQhdwaDTK7xj0cb5M > uxC7fg493PphNLLYY5sL9yHPKtyJzuWhE6r9IXtMSH3b8sTEUU4cXxF4Ep1af+k0 > 9BafYy+vAxv6fM/3VS8KGcGCwElNrCiNLJYjEdW7mCDRFNQR8cja5IVRF8KGlXD3 > 33eKUviyPtx9LB5GNS2bZNSayeJbIENr1LsY2gZ4C6nfXUOzsUp7KhM4P4WmFKWV > TOn/DbigDQjMa07L0+G+cwvrc2X2QJWG8kstD16iARvaRAnlvlO+HQeSAtO1LWwU > 7O44z0eQDxpGO6RZrBDVKNGe8dAaObQT+ueCL/sOHV2Co71Iz8zCu8z75OIhSWWM > 8Tu4pa+doFetFLmOkfkcFTxuAjcxJAJomxnLD9rNcdjDtuWF2wxATdWFruFmYPm+ > u0/PNb0YQg4Xx5M2qV63 > =FxNx > -END PGP SIGNATURE- > - -- kind regards Ian Delaney -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWoz9TXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6jrcQAI70DMC1K2H5cyPs9sia+3ml 6teGcQLNm8DbtBLkJu5R/4Tj+idn9BinMYx7VuxlGBBXSLbDMZlJYBQd5G3fTP6r 1++oqBzVdkA2h6RaYp04NeJsJDRLrHvMh4jX+k0izR9G7kHOVwda15sdmYthcojs ++khE85mgleS9mio/a1gy2EEyY3+lkGCUSs13AU+epzioe/ZCz1zFlNqH/uDmG6+ COZaFbVuW3YlC30as5yvpoKRselx9TD/saZyMwwx2l61jMT6i8Rvo2XD/1Sp0kvb 4PPyBN8VwUId5HDhFvBKPbKezyu5K7xA01hOLFEEC+SH9Q13tfHhIiyCnogHGlDA iXZ37Q4LcXQeJnM5xjuPWVaA9SDbkv4fkUq6r7w6mXbIOtnM3hMceM+xO8eHT6CO 8jykUiNyuXd2hWiJ+oQUiQEbWrAWhqP67e63ScRpH+e1AlpFpKcwJ9mskMaMkbFm L3LWNJFnewn8ouKh2YtQro76/cW+XptK7OMfCGzHKa9eTlGUrG9y10YhBufMNktx o7K7rVSxQrizsSvGl1c/lqbanQsHB12SxGZFSyFHwG4ES1Uii/Lbx64Hw9Jhs+Wv sTIdp7bR8lBNI1YILDb4UY/ksfHIVFlB9ZVS+jwOsYYTTk/wDJri8fZhZt9ciOsF pvGUwOslCyWnhC7zY5AG =LdOn -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFD] Adopt-a-package, proxy-maintenance, and other musings
On Tue, 19 Jan 2016 22:02:21 -0500 Göktürk Yüksek <gokt...@binghamton.edu> wrote: > Duncan: > > NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted: > > > [...] > > > > That gave me the idea of a maintainer-needed eclass. When packages > > are set to maintainer-needed, they can simply inherit this eclass > > and add whatever function to the pkg_postinst, that will add a > > message that will in effect say "adopt-me please", probably > > printing a proxy-maintainer invitation URL to go to for more > > information. > > > > Talking about pkg_postinst messages, unless I missed it there's no > > simple way to add a one ATM, without coding up the whole function, > > making it problematic for eclasses, etc. For EAPI-7, what about > > either a helper function that can be called, or an array variable > > that can be simply added to, that simply adds the supplied message > > to a list of messages printed at pkg_postinst time, and of course > > an appropriate default_pkg_postinst to go along with it? Then > > ebuilds and eclasses can call this helper or set this var in > > whatever phase they need to, and the message will be printed at > > pkg_postinst time without having to worry about setting up your own > > pkg_postinst or stepping on anything pkg_postinst related setup > > elsewhere. > See: > sys-apps/portage: show an elog message when merged package is > maintained by maintainer-needed > https://bugs.gentoo.org/show_bug.cgi?id=398633 > > Can we reconsider implementing this idea perhaps? > Given the thrust of this whole discussion this is a good idea. It naturally advertises packages of this unmaintained status to users as they emerge. > -- > gokturk > > -- kind regards Ian Delaney
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
On Thu, 21 Jan 2016 19:51:51 -0500 Michael Orlitzky <m...@gentoo.org> wrote: > On 01/21/2016 05:41 PM, waltd...@waltdnes.org wrote: > > > > Maybe we should start a "gentoo-ebuilds" mailing list to help > > regular users learn the ins and outs of making ebuilds. > > Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on > IRC. > > We should be trying to get these things proxy maintained at least > since they don't do anyone else any good in a personal overlay. > > Are you not missing something here? -- kind regards Ian Delaney
[gentoo-dev] last rite; dev-db/drizzle, dev-php/pecl-drizzle
# Ian Delaney <idel...@gentoo.org> (07 Dec 2015) # "The drizzle project is long dead, it should be removed, # along with dev-php/pecl-drizzle", note by grknight # in Bug #501060 # Masked for removal in 30 days. dev-db/drizzle dev-php/pecl-drizzle -- kind regards Ian Delaney
[gentoo-dev] last rite; all versions of xen-4.2.5
# Ian Delaney <idel...@gentoo.org> (29 Nov 2015) # versions of 4.2.x supporting the hypervisor for x86 # no longer supported upstream. The purging of 4.2.x # has been held off longer than required already. # Unless otherwise directed, masked for removal in 30 days <=app-emulation/xen4.2.5-r12 <=app-emulation/xen-tools-4.2.5-r11 =app-emulation/xen-pvgrub-4.2.5 -- kind regards Ian Delaney
Re: [gentoo-dev] EAPI 6 portage is out!
On Wed, 18 Nov 2015 11:47:01 -0500 Rich Freeman <ri...@gentoo.org> wrote: > On Wed, Nov 18, 2015 at 10:10 AM, Brian Dolbec <dol...@gentoo.org> > wrote: > > On Wed, 18 Nov 2015 06:59:19 -0500 > > Rich Freeman <ri...@gentoo.org> wrote: > > It is a bit ironic that you chose this as the part to quote when > adding a snide remark. My whole point was that we shouldn't > NEEDLESSLY drop old versions, You seemed to have taken this as a > complaint about dropping old versions when there is a valid reason for > doing so. > > Your tone here is anything but helpful. My intent was really to > contribute to the discussion constructively and point out a pain point > for people running mixed-keywords. Perhaps I didn't explain my point > as well as I could have. When somebody is saying something that > doesn't seem sensible to you, it is usually better to assume that they > just didn't make their point well than to assume that they don't have > anything worth saying. > Bravo. Lemme think of an example of similar replies I have had to endure in this style. 'Your logic / code makes no sense' (Well logical thinking is a tad beyond me yeah) One will do. Other authors might recognise their closed minded retorts and other such blunders. What ever was so hard about politely prompting to please re-phrase, or, more casually, run that by me again, or "I need you to re-state that", or even plain 'huh'. Alternatively; wtf are you saying? (Love that one) Let's consider the lack of virtues of leaping to the wrong interpretation aka misunderstanding the data put, then jumping in head first & retorting to the 'sender' with what amounts to a blatant smack down. But, as the guides to use of irc tells us in the first place; pure text, absent of the remainder of visual and auditory metadata, offers a highly restricted context, highly prone to error. aka, text on a screen. In other words, a disaster looking for a location. Oh and dol-sen don't feel you're being picked on. You of all folk are NOT one to typically fall over this one. Wish it were someone far more 'typical'. But I stray, NOT troll. What were we talking about again? -- kind regards Ian Delaney
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 30 Oct 2015 18:20:08 +0100
Michał Górny <mgo...@gentoo.org> wrote:
> On Fri, 30 Oct 2015 12:03:59 + (UTC)
> "Justin Lecher" <j...@gentoo.org> wrote:
>
> > commit: df8e399c9bac2dc30d7cf69c2462a81729a3ae69
> > Author: Justin Lecher gentoo org>
> > AuthorDate: Fri Oct 30 10:18:05 2015 +
> > Commit: Justin Lecher gentoo org>
> > CommitDate: Fri Oct 30 12:03:49 2015 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8e399c
> >
> > eclass: Use consistent place for then in if clause
>
> Excuse me but who are you exactly to take a random eclass and commit
> random style changes inside without even bothering to contact
> the author?
>
Well, what's this? he selected a random eclass? Then he recklessly
committed a random style change? To my observation, the lead recruiter
specifically selected the distutils-r1 eclass, not some random one like
base.eclass, and carefully edited a couple of lines to put "; then" at
the end of a line as is done in most any ebuild. So how RANDOM is that?
In fact it isn't, however you have no hesitation in taking him to task
not only over its randomness which isn't, but that he had the gaul to do
it at all.
Was it not you who insisted that I assign a bug over the func
distutils_install_for_testing and you insisted I assign it to the
python team, not to you as I did. You lectured me to follow the rules
stating that it belongs to the python herd / project / w/e which may
be authored by its members any time in the future. It seems you want it
both ways.
jlec is not only a member of python team but he is high ranked. That
exactly is who he is.
> Not to mention this commit message is incorrect as it doesn't state
> which eclass was modified.
>
This is in fact correct.
> >
> > Signed-off-by: Justin Lecher gentoo.org>
> >
> > eclass/distutils-r1.eclass | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> > index 185dd4f..dbd27a7 100644
> > --- a/eclass/distutils-r1.eclass
> > +++ b/eclass/distutils-r1.eclass
> > @@ -322,8 +322,7 @@ distutils-r1_python_prepare_all() {
> >
> > _distutils-r1_disable_ez_setup
> >
> > - if [[ ${DISTUTILS_IN_SOURCE_BUILD} && !
> > ${DISTUTILS_SINGLE_IMPL} ]]
> > - then
> > + if [[ ${DISTUTILS_IN_SOURCE_BUILD} && !
> > ${DISTUTILS_SINGLE_IMPL} ]]; then
>
> This was intentionally wrapped to stay within 72-column line width.
> Not saying the eclass is perfect in keeping text width, especially
> with others committing random changes to it, but that's no reason to
> introduce further offenders.
>
there's that random again. Once and for all mgorny get off your high
horse.
> > # create source copies for each implementation
> > python_copy_sources
> > fi
> >
>
>
>
- --
kind regards
Ian Delaney
-BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1
iKYEARECAGYFAlY0u/1fFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDdDQUM1OUY0ODkzMERBREU1NUQ1RjJBRkIy
OEVDMjEzQjgwNzJCMEQACgkQso7CE7gHKw3xZQCgyQb6Tyuw73CiBHgxXm/bvPX7
L1EAn0UfLOZTERZpMJN1VQXIgb81AkE6
=yt+k
-END PGP SIGNATURE-
--
kind regards
Ian Delaney
[gentoo-dev] new entry to metadata.dtd tag
A user wishes to set the remote-id type to gitlab where a package is located that he maintains. gitlab is both a software and a code hosting site. See https://bugs.gentoo.org/show_bug.cgi?id=563578 -- kind regards Ian Delaney
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Mon, 12 Oct 2015 08:19:34 -0700 Matt Turner <matts...@gentoo.org> wrote: > On Mon, Oct 12, 2015 at 7:23 AM, hasufell <hasuf...@gentoo.org> wrote: > > > > I'm not a native speaker and people have more than once told you > > that your language is difficult to understand. > > > > So, can you elaborate what your sarcastic (that's how I read it) > > anecdote was meant for then? Preferably off-list, since this doesn't > > seem to help any of us. > > I am a native speaker and I cannot understand what he's saying, for > what it's worth. > > I think he's indicating that the "right" in his earlier message was > indicative of sarcasm, and so then he chides you for responding to his > sarcastic message without knowing it was sarcasm. fwiw how about not sure what you mean by that please re-sate. Better that than misinterpreting and responding to a totally wrong message. This was an innocent accident mostly. is to help all us who cannot write ebuilds correctly or proficiently? I generally don't do sarcasm however with this thread it can be hard to avoid. right is ambiguous here. He read it as: all us who cannot write ebuilds, right? or all us who cannot write ebuilds? Right? completely changing the meaning to all us who cannot write ebuilds at all? The sentence started out as a question so finishing with ebuilds right? unfortunately mislead him. Never intended. The sentence was too long. I should have simply stopped it with How exactly may I ask does anyone actually offer help to the Reviewers Project? Confusing or misleading him was never my intent or goal. He has enough of that already. The absurd thing is > that he then says "Please stop taking words out of my mouth and > distorting my message" (which of course you weren't doing), which was > *precisely* what he was doing. > I was doing no such thing and I resent this accusation in the strongest terms. My meaning here was that he took the 'right' out or the sentence, or question, equating to taking out. Any distortion here was accidental and unfortunate and you need not add to the tension by accusing me of distortion. The user here is indeed the exception to the rule, or the norm. And as rich0 said, the 80% 20% rule may apply. The fact is however that the 20% were grossly unimpressed. Users are neither seasoned nor prepared for the type of review put upon them by him and mgorny. Even Amynka struggled with it. Read the rest of the emails dev to dev and it's a walk in the park. It all works. His efforts aimed at devs developing ebuilds are fine and happy with them. These users still needed support and a voice to help them speak up, and they did. Still, these members have fashioned themselves to teach and service users, They have alot of adapting to do before users will embrace their attempts to educate them. > In another subthread I really got the sense that he's simply > attempting to provoke a response. I suggest not giving him that. > I won't be giving any more to him I suspect. enough it's late -- kind regards Ian Delaney
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Mon, 12 Oct 2015 13:16:01 +0200 hasufell <hasuf...@gentoo.org> wrote: > On 10/12/2015 06:56 AM, Matt Turner wrote: > > > > So work with the reviewers to ensure the communication is tactful > > and graceful. > > > > That would be appreciated. So far, we mostly got people complaining > (and some setting up sieve filters to throw all our mails to trash), what does this tell you? > but not people offering help. The latter has a bigger chance of > actually having an impact. > > Not sure how to read this. The whole idea is for provider / client to communicate and negotiate a workable solution. At a glance this reads as the user needs to adapt to the service that the client is offering and appease the provider. What's wrong with this picture? How exactly may I ask does anyone actually offer help to the Reviewers project whose whole aim it seems is to help all us who cannot write ebuilds right? By going along with your flow, with neither question nor comment? Where is the part about the educators leading the way with tact and grace? Who is the leader here? -- kind regards Ian Delaney
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Mon, 12 Oct 2015 15:47:19 +0200 hasufell <hasuf...@gentoo.org> wrote: > On 10/12/2015 03:29 PM, Ian Delaney wrote: > > > > Not sure how to read this. The whole idea is for provider / client > > to communicate and negotiate a workable solution. At a glance this > > reads as the user needs to adapt to the service that the client is > > offering and appease the provider. What's wrong with this picture? > > > > How exactly may I ask does anyone actually offer help to the > > Reviewers project whose whole aim it seems is to help all us who > > cannot write ebuilds right? > > > > Nowhere did way say that people cannot write ebuilds, nor did we > impose that picture. That all happened in your own mind. > Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds RIGHT'. Please stop taking words out of my mouth and distorting my message. > Your picture about our goals is completely incorrect and you seem to > respond to something that's not really our project. So I'd like to ask > you to take a few moments and actually read our replies and the > project page, before we derail even further here. > Yes Julian. You have it right and I have it wrong. I feel relieved now -- kind regards Ian Delaney
Re: [gentoo-dev] [PATCH] metadata: add slots element
On Mon, 12 Oct 2015 20:01:15 +0200 hasufell <hasuf...@gentoo.org> wrote: > On 10/12/2015 07:49 PM, Alexis Ballier wrote: > > On Mon, 12 Oct 2015 19:19:33 +0200 > > Julian Ospald <hasuf...@gentoo.org> wrote: > > > >> There seems to be some general confusion about specific package > >> SLOTs and their meaning, since there can be several naming schemes > >> applied and documentation is either non-existent or is inside the > >> ebuild via comments. > >> Because of that it should be part of metadata.xml. > > > > Oh that word should. You appear to state this as fact. > > Why not, but what's the advantage of xmlizing it vs comments in the > > ebuilds? > > > > Because metadata.xml is the place for metadata and has a defined, > verifiable and useful (in terms of actual processing/parsing data) > form. > > Even if you want those things to be in the ebuild, it would definitely > not be comments, but actual syntax (like exheres). > > So basically the same arguments for not having random comments for USE > flags in the ebuilds apply. > random? RANDOM? How about a carefully thought out and pertinent one then? While use of xmlizing appears fine, I fail to see anything wrong with entering a commented line in an ebuild as developers do all the time as standard 'workflow'. Just my 2 phennigs worth. -- kind regards Ian Delaney
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Sun, 11 Oct 2015 19:17:58 +1100 wraeth <wra...@wraeth.id.au> wrote: > On 11/10/15 18:52, Ian Delaney wrote: > > On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier > > <aball...@gentoo.org> wrote: > > > > I am one of the users who spoke to idella4 about this, but I wanted to > repeat this publicly in order to highlight the point of view of > contributing user as opposed to a developer. > > Firstly I would like to say that I appreciate feedback on my work - it > helps me to improve the quality of my work both for Gentoo and > personally. > > I also agree whole-heartedly to the concept of the Reviewers project, > in that highlighting common improvements that could be made would > benefit both contributors who participate and Gentoo as a whole. > > Having said that, however, I do not appreciate the method in which > these criticisms were delivered, and believe it extends beyond the > idea of the Reviewers project. > > I feel that it is inappropriate for criticisms of contributor's work > to be broadcast on a mailing list that is read not only by the > developer community, but by users as well, without their consent. > This is not a case where I am particularly embarrassed or upset - if > others can learn from my mistakes, then they are mistakes I am happy > to make (preferably only once). But doing so publicly, with > identifying information, is inappropriate. > > Like I said, I welcome input that would improve my contributions, but > I am concerned that the way that the Reviewers project has been > undertaken so far is leading more into an extended QA with standards > that go beyond the enforcement of established Gentoo policy. > > Kind Regards; > I support wraeth's views. He is a keen and fine contributor to gentoo -- kind regards Ian Delaney signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier <aball...@gentoo.org> wrote: > On Sat, 10 Oct 2015 10:09:11 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > Hello, developers. > > > > I have the pleasure :? > > to announce that we have formed a new Reviewers > > team [1] for Gentoo. The team is going to assemble developers > > willing to perform ebuild reviews and help contributors improve > > their ebuild skills. > > > > The main goal of the team is to handle GitHub pull requests. We are > > going to review incoming PRs, communicate with maintainers and merge > > them as appropriate. In particular, we're going to help willing > > contributors get high-quality, PGP-signed commits into Gentoo, > > therefore helping them prepare to become Gentoo developers. > > This is cool > > > The side goal is to review current Gentoo commits for major QA > > violations and other issues, aiming at improving the quality of > > ebuilds in Gentoo and helping other developers using bash, ebuilds > > and git effectively. > > This is completely unrelated: since we've had gentoo-commits ml, which was promptly utlised > every one has been able to do commit reviews easily, and most devs > have done so. Self-proclamed reviewers project certainly does not > have the monopoly of best practices nor perfect knowledge. I hope > they do keep the monopoly of being harassing though :) > > Also, you should probably focus on what's really important: reviews > like "this is weird, care to explain?" or stylistic nitpicks are just > a waste of every one time, meaning more important stuff does not get > done. > To my observation the reaction to this has been between displeasure and dismay. Yesterday the dev-ML was flooded with the first day's publication of the members' reviews. Firstly the gentoo-commits ML to my understanding is intended to be used for and by qa members. This project has one whom we presume has the discretion to declare the use of the qa hat at whim. As someone once put it, it's not the product or message it's the delivery of the package. This project in its creation is made of self appointed members who assume the status and qualification to suddenly launch their evaluations upon unsuspecting folk the community wide with neither warning nor their prior knowledge nor consent. The editing to the page illustrates already significant back pedalling from feedback already challenging its selected mode of delivery. The project goals and 'would be' mission statement are in fact legitimate and have the backing of Council members. The execution has been done independently, unilaterally and with no input or collaboration with Council to my knowledge. The actions of this project potentially impact on every developer / user of the gentoo project, addressing the core skills of both. Yet it has been made, announced and executed in this style. I invested study time in several units in teaching and lecturing in my university education under the education department. Sorry but the modi operandi by these self proclaimed teachers and educators thus far violate almost every fundamental principle in the art of teaching that I learned from the course. There have also been users who have expressed concern to me over this directly, some of which have indicated they will also email this list to make their views known. -- kind regards Ian Delaney
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Sun, 11 Oct 2015 09:56:28 -0700 Matt Turner <matts...@gentoo.org> wrote: > On Sun, Oct 11, 2015 at 1:17 AM, wraeth <wra...@wraeth.id.au> wrote: > > > > I feel that it is inappropriate for criticisms of contributor's > > work to be broadcast on a mailing list that is read not only by the > > developer community, but by users as well, without their consent. > > This is not a case where I am particularly embarrassed or upset - > > if others can learn from my mistakes, then they are mistakes I am > > happy to make (preferably only once). But doing so publicly, with > > identifying information, is inappropriate. > > Good grief. Seriously? > > Mailing list review is the *norm* in the free software world. > Oh, the norm > I haven't seen anything noted that should have caused embarrassment. > Nor I. > This whole thing, as far as I can see, is about improving the quality > of Gentoo. I have learned from the reviewers reviewing my commits and > the commits of others. The you haven't been embarrassed or demeaned or nitpicked. So far. Good. > It's extremely valuable to do this in public > and the idea that noting an error on a public mailing list is somehow > bad is simply misguided. > You throw your opinion on that of a user offering his personal reaction. What do you want here? Users to comply to your perspective and fit in? Users to tough out the exposure to full public view even if they don't like it? Once and for all this is a review put onto recipients whether they wanted it or not without their request or consent. A key aspect of learning is that the informative experience be made a positive one. This user is not alone. These self appointed educators have background in technical prowess and that's all. Quite simply, dishing out lessons that make users cringe and recoil is counter productive. This exercise is about educating, so these educators had better get their heads around some the fundamental requirement to command respect from their target audience. To date they have managed to deliver their product as they see fit. Now they get the feedback that follows from delivering their lessons. These educators have already started to learn some lessons of their own. An intrinsic aspect of the flow of teaching / educating is the impact of teacher behaviour upon their learners and a teacher's responsibility as an educator to deal with it productively. What's happening here? Teacher says take it because I gave it to you,now be quiet ? This is not a captive audience. It's an immediately convenient one. Educators snubbed by their students are not educators. At least not effective ones. These students are so by nature of their own voluntary participation. They have the option of rejecting these lessons at their whim. -- kind regards Ian Delaney
Re: [gentoo-dev] [RFC/announcement] Reviewers project
On Sun, 11 Oct 2015 19:37:23 -0700 Matt Turner <matts...@gentoo.org> wrote: > >> > >> Mailing list review is the *norm* in the free software world. > >> > > > > Oh, the norm > > You're being quite rude with attempted mockery -- actually, the rest > of your reply is pretty abrupt as well. > > If you want to fight, find someone and some place and else. Otherwise > if you're interested in having a reasonable discussion, please read > on. > Oh so this is a fight? Your words not mine. I thought this was a discussion. Please stop putting words into my mouth. > > > > These educators have already started to learn some lessons of their > > own. An intrinsic aspect of the flow of teaching / educating is the > > impact of teacher behaviour upon their learners and a teacher's > > responsibility as an educator to deal with it productively. What's > > happening here? Teacher says take it because I gave it to you,now be > > quiet ? > > No. It's a discussion. Review can be responded to -- reviewers aren't > intrinsically right. > Oh thanks for reminding me. > > This is not a captive audience. It's an immediately convenient one. > > Educators snubbed by their students are not educators. At least not > > effective ones. These students are so by nature of their own > > voluntary participation. They have the option of rejecting these > > lessons at their whim. > > Patch review is widely accepted as a quality-improving tool. Some have > had difficulty adjusting to it when coming from, for instance, the > closed-source world, primarily because they equate making a mistake to > personal failure (and as such, having it pointed out in public makes > it worse). > > http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/ > offers a good explanation. > > "The most productive contributors see each mistake they make as a > growth opportunity, instead of a personal failure." > The main target learners here are keen users. You can take told a mistake with the background and status of a dev. They don't. They are often intimidated and fearful if gentoo devs. We wonder why. -- kind regards Ian Delaney
Re: [gentoo-dev] Python 3.5 is in, Python 3.3 deprecation
On Sun, 4 Oct 2015 10:11:48 -0400 Mike Gilbert <flop...@gentoo.org> wrote: > Hi all, > > Python 3.5 has been added to ~arch this morning. Please feel free to > test and add python3_5 to PYTHON_COMPAT as appropriate. > > Also, to keep the number of supported implementations manageable, I > would like to deprecate Python 3.3. This means that it should not be > added to PYTHON_COMPAT in new packages. Does anyone object to this, or > have some reason we should keep it as "supported"? > > See the wiki for the current status of python implementations. > > https://wiki.gentoo.org/wiki/Project:Python/Implementations > Frankly Mike I don't follow the rush behind trying to deprecate 3.3. I'd have thought let py3.5 bed in some then take on the task of 3.3, however I suppose it wouldn't hurt. Though "should not be added to PYTHON_COMPAT in new packages" should be fine. I take it here you're only talking about skipping over py3.3 from this point. Adding support to 3.5 systemically would be another topic. -- kind regards Ian Delaney
[gentoo-dev] Last rite defunct packages of net-firewall/shorewall-
commit 1e714de7382390bc75eb0a939f8dfcaea39763da Author: Ian Delaney <idel...@gentoo.org> Date: Sun Sep 20 17:31:41 2015 +0800 pmask defunct packages of net-firewall/shorewall listed in bug #560392 net-firewall/shorewall-core net-firewall/shorewall-init net-firewall/shorewall-lite net-firewall/shorewall6 net-firewall/shorewall6-lite
Re: [gentoo-dev] NPM / NodeJS project
On Sun, 28 Jun 2015 12:30:25 -0400 Michael Orlitzky m...@gentoo.org wrote: I recently found a need for the CoffeeScript compiler[0] that runs on top of NodeJS. Its test suite requires a bunch of other javascript packages, and I wound up packaging enough of them to test CoffeeScript. In the process I wrote an eclass to handle packages hosted on the npm registry[1] and install them globally. I put all of this in an overlay for now: https://github.com/orlitzky/npm We don't have any standalone javascript packages in the tree at the moment but I know there's been some interest before. Is anyone still (planning on) working on javascript stuff in-tree? If not, I'll probably commit dev-lang/coffee-script to the tree without its test suite. But if so, the eclass and few dev-js packages I have might be a good start. Then I could add coffee-script with its test suite working. [0] http://coffeescript.org/ [1] https://www.npmjs.com/ Is this what I prompted about a year or more ago, and drew no interest in pursuing the npm path? I cited an eclass called npm.eclass in a dev's overlay. The conclusion was that using npm to install anything competed with portage at a level that made it a 'no go'. This came from members of the portage 'team'. It is a very awkward topic. -- kind regards Ian Delaney
[gentoo-dev] lastrite; dev-python/gevent-zeromq
# Ian Delaney idel...@gentoo.org (13 May 2015) # package unused, no revdeps, obsolete. # masked for removal in 30 days dev-python/gevent-zeromq -- kind regards Ian Delaney
Re: [gentoo-dev] Re: New website: Where the .... is the ....ing documentation link?
On Wed, 8 Apr 2015 00:11:56 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Ian Delaney posted on Tue, 07 Apr 2015 16:02:39 +0800 as excerpted: Personally I found your post most entertaining and had me riti (rolling in the isles). Like the use of cap, humour is rather an inexact science Thanks. That's the way it was intended, haha but serious, making the point in what was intended to be a funny way. But as people who forget the sarcasm tags so often find out to their misfortune, forgetting the humor tags can just as effectively create a lead balloon. =:^( Glad someone took it as intended, and for those that didn't, the previous apology stands... Mistake, made, apologized for. As for the bug, looks like events overtook my need to file one. Thanks, website team. =:^) I think you've apologised enough. Shame it was required to state the obvious. -- kind regards Ian Delaney
Re: [gentoo-dev] Re: New website: Where the .... is the ....ing documentation link?
On Mon, 6 Apr 2015 05:10:30 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Alec Warner posted on Sun, 05 Apr 2015 09:33:24 -0700 as excerpted: No need to shout. Apology to you and others. And thanks. While I am of course familiar with CAPS=shout, I always considered it entire phrases or whole sentences in caps, not single words, which was simply emphasis. But it seems others consider even single caps-words shouting, so from now on I'll try to use either *bold* or /italics/ emphasis instead. Also, as I was reminded, a bug would have been more appropriate. If events don't make it unnecessary, I'll try to file one later this week. Thanks again. Personally I found your post most entertaining and had me riti (rolling in the isles). Like the use of cap, humour is rather an inexact science -- kind regards Ian Delaney
Re: [gentoo-dev] RFC News item: FFmpeg default
On Tue, 7 Apr 2015 07:13:16 +0800 Ben de Groot yng...@gentoo.org wrote: On 6 April 2015 at 17:35, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-04-06, o godz. 14:10:12 Ben de Groot yng...@gentoo.org napisał(a): On 30 March 2015 at 00:23, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-03-30, o godz. 00:07:16 Include example code. Updated version: Title: FFmpeg default Author: Ben de Groot yng...@gentoo.org Content-Type: text/plain Posted: 2015-04-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav Since the choice between ffmpeg and libav has been made more explicit, there has been a lot of discussion about what the default implementation should be. It can be concluded that media-video/ffmpeg has wider support, and would be somewhat more convenient for most end-users. For this reason the default implementation has been switched back from media-video/libav to media-video/ffmpeg by removing the libav useflag from the base profile. 'Switched back' is suggesting there was some 'unintentional' switch from ffmpeg to libav. Keep this free of politics, and just 'switched'. No, it does not suggest that. It simply reflects the history of the issue: once upon a time we had ffmpeg. Then libav was introduced and at some point made the default implementation. Now we are switching back to ffmpeg as default implementation. There is no politics in my statement. This is off-topic, and strongly biased. The original statement may give the impression that mpv is to libav what mplayer is to ffmpeg. Many users were surprised to find out that mpv upstream actually recommends ffmpeg, and that some of mpv's features do not work with libav. If we are going to specifically recommend mpv, then it is something users need to be aware of. We could change it to: media-video/mpv works with both ffmpeg and libav, though some of its features require ffmpeg. Or something along those lines. Please do not alter the state of 'libav' flag on a per-package basis (e.g. via package.use). The flag needs to be set globally to have FYI: since Council's meeting in one week, I have added this to the agenda. I'm really concerned about Gentoo's PR when users suffer due to developers ping-ponging implementations/defaults. It's not so much ping-ponging as stumbling upon what is the best solution for our users. Some years ago libav was made a soft default. And if I recall correctly, that was done with very little discussion. Recently this default was made harder by adding USE=libav to the base profile. This resulted in quite a backlash from users. Moreover, many upstreams of consuming packages actually prefer ffmpeg. Add to that the upstream ffmpeg policy of merging in changes from libav. All in all, from an end-user point of view it makes more sense to have ffmpeg as default. And when users were asked, they overwhelmingly expressed support for changing the default to ffmpeg. I see no reason to stick with libav as default, except political (which I'm trying to avoid here). +1 -- kind regards Ian Delaney
Re: [gentoo-dev] Re: RFC: News item for net-firewall/shorewall all-in-one package migration
On Sun, 5 Apr 2015 04:12:17 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Thomas D. posted on Sat, 04 Apr 2015 22:09:36 +0200 as excerpted: Title: New net-firewall/shorewall all-in-one package But I'm not wedded to either idea; they're just what I came up with off the top of my head. If someone has a better idea... (FWIW I had a /terrible/ time finding that glep on the new website to double-check, and it's good I did as I thought it was 42, but that's a gripe for a new thread...) It seems these keen folk ought be given support for a reasonable idea with user support / desire and presented with due attention to glep requirements. -- kind regards Ian Delaney
[gentoo-dev] Fw: reviewboard and its bugs
Begin forwarded message: Date: Wed, 20 Aug 2014 08:45:21 +0800 From: IAN DELANEY idel...@gentoo.org To: gentoo-pyt...@lists.gentoo.org Subject: reviewboard and its bugs cancel the gentoo-python@lists, was intended for gentoo-dev@lists The package reviewboard has reached a stage of warranting this submission to the ML. A simple search of reviewboard in bugzilla lists a few 'user submitted' bugs and no less than 3 sec bugs. This package I added initially because interest was expressed mainly by my final mentor and the other (prior) co-maintainer. Because of changes to reviewboard upstream, we need a new eclass and category to cater to certain js packages. Now wishing to re-write all I have already written in the bugs, in summary, reviewboard has become unworkable by the developers of reviewboard itself going down the path of nodejs. Enter npm. npm was an unknown to me until Djblets and django-pipeline ebuilds failed due to the absence of UglifyJS and some related js deps. On being informed of ebuilds for this and related deps in the overlay of neurogeek, I discovered they required npm which it seems comes in nodejs. The response drawn by fellow devs over npm is in my limited experience unprecedented. The overall reaction was leave it and don't go there. What became apparent from the ebulds in neurogeek's overlay was that these deps didn't lend themselves well to writing ebuilds for them for portage. In the overlay there is in fact an npm eclass to overseer their installation into the system. After some somewhat reluctant discussion of npm in irc, it has at least been suggested that the use of nodejs' UglifyJS in django-pipeline could be patched out to relieve us all of any reliance or involvement of npm to install these js oriented deps. That has not ofcourse been attempted or tested and allows for the probability of breaking Djblets and or reviewboard which I suspect has been written by reviewboard developers to explicitly depend on and call these deps. The decision it seems isn't whether to allows npm into portage, it already comes with nodejs correct me if I misunderstand. The question is whether to support this npm installing packages into a gentoo system by ebuilds essentially outside of portage. This requires an eclass and it has been suggested a whole new category for portage under which to categorise these npm type packages. Such an eclass has already been written, however, that it has never been added to portage along with js style packages in the overlay, to me at least, strongly suggests the author always had reservations with its addition. There is ofcourse the alternative; to write ebuilds to install these packages without npm involvement. This would still require an eclass anyway. Either way, nodejs and java script are totally outside the realm of pythonic packages and are therefore outside my realm of knowledge and experience. Reviewboard developers have essentially created a huge dilemma for users of reviewboard in gentoo by going electing to use this js 'toolchain'. While I normally go to any lengths to maintain any and all packages within the python realm, this reviewboard has gone way beyond that realm. Until this, its underbelly was pure python and posed no real problem. Now I have a growing and unwelcome list of bugs of this package assigned to me as the sole remaining maintainer which are now unworkable. The real problem here is that there is an apparent keen set of would be users of this package, one of whom is a gentoo dev, who is to be found in at least one of those bugs. To delete or mask the package amounts to a clean solution, and also abandons gentoo users looking to have the package made work for them. In summary, because of changes to reviewboard upstream, we need a new eclass and category to write ebuilds to these packages and add them to portage. -- kind regards Ian Delaney -- kind regards Ian Delaney
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/eapi-5-files: ChangeLog package.use.stable.mask
On Thu, 26 Sep 2013 11:05:54 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, Sep 26, 2013 at 5:52 AM, Ian Delaney (idella4) idel...@gentoo.org wrote: idella4 13/09/26 09:52:25 Modified: ChangeLog package.use.stable.mask Log: Delete temp. entry of =app-emulation/xen-tools-4.2.1-r3 wrt Bug #484524 Revision ChangesPath 1.23 profiles/eapi-5-files/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/eapi-5-files/ChangeLog?rev=1.23view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/eapi-5-files/ChangeLog?rev=1.23content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/eapi-5-files/ChangeLog?r1=1.22r2=1.23 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/profiles/eapi-5-files/ChangeLog,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- ChangeLog 21 Sep 2013 17:25:23 - 1.22 +++ ChangeLog 26 Sep 2013 09:52:25 - 1.23 @@ -1,6 +1,11 @@ # ChangeLog for Gentoo eapi-5-files profile directory # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/eapi-5-files/ChangeLog,v 1.22 2013/09/21 17:25:23 floppym Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/eapi-5-files/ChangeLog,v 1.23 2013/09/26 09:52:25 idella4 Exp $ + + 26 Sep 2013 Ian Delaney idel...@gentoo.org use.stable.mask: + Remove invalid entry for xen-tools-4.2.1-r3 which was removed + 04 Jul 2013 on stabilising xen-tools-4.2.2-r3.ebuild; see + Bug #484524 21 Sep 2013; Mike Gilbert flop...@gentoo.org package.use.stable.mask: Stable-mask sys-boot/grub[libzfs] 1.25 profiles/eapi-5-files/package.use.stable.mask file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/eapi-5-files/package.use.stable.mask?rev=1.25view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/eapi-5-files/package.use.stable.mask?rev=1.25content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/eapi-5-files/package.use.stable.mask?r1=1.24r2=1.25 Index: package.use.stable.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/eapi-5-files/package.use.stable.mask,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- package.use.stable.mask 21 Sep 2013 17:25:23 - 1.24 +++ package.use.stable.mask 26 Sep 2013 09:52:25 - 1.25 @@ -1,6 +1,6 @@ # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/profiles/eapi-5-files/package.use.stable.mask,v 1.24 2013/09/21 17:25:23 floppym Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/eapi-5-files/package.use.stable.mask,v 1.25 2013/09/26 09:52:25 idella4 Exp $ # This file requires eapi 5 or later. New entries go on top. # Please use the same syntax as in package.use.mask @@ -29,11 +29,9 @@ # The dependencies for these flags are still in ~arch. sys-fs/lvm2 clvm cman -# Agostino Sarubbo a...@gentoo.org (24 May 2013) -# Justin Lecher j...@gentoo.org (30 May 2313) -# Temporary mask because it needs texinfo-5 -# hvm needs qemu #471122 -=app-emulation/xen-tools-4.2.1-r3 qemu hvm ocaml +# Mike Gilbert flop...@gentoo.org (09 Jun 2013) +# Requires dev-python/pillow to be stable. +virtual/python-imaging python_targets_python3_2 python_targets_python3_3 # Chris Reffett creff...@gentoo.org (23 Nov 2012) # CMake's PHP module can't find our install location, so Ian: Why did you add an entry to package.use.stable.mask with my name attached to it? An entry that I removed several weeks ago, no less. Also, your ChangeLog entry is auto-merged an old versionadly formatted (missing semicolon after the date). ok it auto-merged an old version which I wrongly deduced as valid. Between your re-removal and touching up the format all is fixed. -- kind regards Ian Delaney
[gentoo-dev] last rite of dev-python/elixir
# Ian Delaney idel...@gentoo.org (06 Jun 2013) # Masked for removal in ~ 30 days. Upstream inactive dev-python/elixir -- kind regards Ian Delaney
[gentoo-dev] Last rites; dev-python/{etsdevtools,blockcanvas,envisagecore}
# Ian Delaney idel...@gentoo.org (12 May 2013) # Recommended by upstream's own maintainer to drop the # package, no longer valid. # Masked for removal in 30 days dev-python/etsdevtools # Ian Delaney idel...@gentoo.org (12 May 2013) # Recommended by upstream's own maintainer to drop the # package, no longer valid. # Masked for removal in 30 days dev-python/blockcanvas # Ian Delaney idel...@gentoo.org (12 May 2013) # version 3 package now superseded by # dev-python/envisage version 4. # Masked for removal in 30 days dev-python/envisagecore -- kind regards Ian Delaney
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-emulation/xen: xen-4.2.0-r1.ebuild ChangeLog
On Mon, 04 Feb 2013 16:48:50 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:
On 04/02/13 16:41, Ian Delaney (idella4) wrote:
idella4 13/02/04 14:41:03
Modified: xen-4.2.0-r1.ebuild ChangeLog
Log:
Added acquired but missed sec patch 2012-5513-XSA-29.patch to
set of sec patches in 4.2.0-r1
(Portage version: 2.1.11.40/cvs/Linux x86_64, signed Manifest
commit with key 0xB8072B0D)
Revision ChangesPath
1.5 app-emulation/xen/xen-4.2.0-r1.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-emulation/xen/xen-4.2.0-r1.ebuild?rev=1.5view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-emulation/xen/xen-4.2.0-r1.ebuild?rev=1.5content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-emulation/xen/xen-4.2.0-r1.ebuild?r1=1.4r2=1.5
Index: xen-4.2.0-r1.ebuild
===
RCS
file: /var/cvsroot/gentoo-x86/app-emulation/xen/xen-4.2.0-r1.ebuild,v
retrieving revision 1.4 retrieving revision 1.5
diff -u -r1.4 -r1.5
--- xen-4.2.0-r1.ebuild 2 Feb 2013 21:16:34 - 1.4
+++ xen-4.2.0-r1.ebuild 4 Feb 2013 14:41:03 - 1.5
@@ -1,6 +1,6 @@
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-#
$Header: /var/cvsroot/gentoo-x86/app-emulation/xen/xen-4.2.0-r1.ebuild,v
1.4 2013/02/02 21:16:34 ago Exp $ +#
$Header: /var/cvsroot/gentoo-x86/app-emulation/xen/xen-4.2.0-r1.ebuild,v
1.5 2013/02/04 14:41:03 idella4 Exp $
EAPI=5
@@ -85,6 +85,7 @@
${FILESDIR}/${PN}-4-CVE-2012-4538-XSA-23.patch \
${FILESDIR}/${PN}-4-CVE-2012-4539-XSA-24.patch \
${FILESDIR}/${PN}-4-CVE-2012-5510-XSA-26.patch \
+ ${FILESDIR}/${PN}-4-CVE-2012-5513-XSA-29.patch
${FILESDIR}/${PN}-4-CVE-2012-5514-XSA-30.patch \
You forgot a \ there and it makes this ebuild fail.
- Samuli
ah thx
--
kind regards
Ian Delaney
Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?
On Mon, 31 Dec 2012 15:24:40 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31/12/2012 15:17, Ben de Groot wrote: Looking back at 2012, I wonder what we consider our achievements for this past year. What is the state of Gentoo? How have we brought it forward and improved it this past year? Have we? Well, is this an exercise in posing of the rhetorical? Repeating of the fundamental question at hand achieved well, nothing really, rather like treading water instead of actual breast stroke. The pen having writ (well the keyboard actually), the question thus put, beckons a reply. i.e. an answer, So, answer it. Give the man a breast stroke; something like; Gentoo is up and running and doing fine. We have brought it forward, and happily not down. Just look at the new nifty eclasses and their docs to match. Of one thing I am assured; the feisty temperament of the archetypical gentoo dev is at its feisty best. -- kind regards Ian Delaney
Re: [gentoo-dev] [PATCH] Check for USE_PYTHON - PYTHON_TARGETS equiv.
On Tue, 6 Nov 2012 14:40:19 -0800 Brian Harring ferri...@gmail.com wrote: On Tue, Nov 06, 2012 at 12:31:07PM -0500, Mike Gilbert wrote: On Mon, Nov 5, 2012 at 7:48 PM, Brian Harring ferri...@gmail.com wrote: Either way, I'm honestly not trying to piss folks off here nor stop the efforts to dig us out of the python.eclass mess. Oh really? Well just as well you weren't actually trying. Not there is any doubt without deliberate intent. That said, *this time around* that eclass should actually have a plan so that we don't wind up in the same cluster fuck scenario as prior. Ah, ye have a way with words of the expletive kind. Pity that. It's a simple enough request; document your roadmap. Asking for reviews w/out that, frankly, is pointless er yep. point here with some merit. The steps to filling that gap are well in underway. mgorny has been busily beavering away making guides of the -r1 kind and you ought note that some have been reviewed, edited, submitted and commited to the gentoo land bank of docs. (and sooner or later some asswipe like me is going to start -1'ing things till that's addressed). eeer yep, well, what more can we say. If anyone wants to help in drafting a GLEP, I would appreciate it. I'll try to start that this week. There will definitely be some holes, since I really don't have an all encompassing plan in my head. But it will be good to fill those in. Holes in the glep can be sorted/fleshed out; trust me, way more preferable sorting it there then in a live implementation the tree relies upon. :) Thanks- ~harring not knowing Brian from any prior encounters, am pleased to make yr acquaintance. I've been following mgorny's -r1 efforts with interest from a front row seat in gentoo-python. I couldn't help but notice the metaphorical steam shooting from his ears when came the prompt to follow the plan suggested by on harring. It seems that the style of reply from one harring to this one man band (mgorny's) effort has indeed made an impact of resentment and hostility. One can only ponder as to what brought this about. That anyone has finally stepped up to make the alleged wrongs of the python.eclass is is a watershed moment in itself. To take a watershed moment and then hit it with such a volley of critique is, may I suggest, pure folley. The young man has taken on a mammoth task and it surprises me not that from time to time he discovers that he has bitten off more than he intended to chew. Dare I say, cut him some slack and a sense of gratitude for grabbing such a poisoned chalice with both hands and running with it. Remembering the ways of the python state, be they simple or complex, easily understood or macabe, ripple and reverberate through to every corner of the gentoo portage list. It's no trivial task in process. He needs support, dollups and dollups of it. He has at least a trickle at this point. -- kind regards Ian Delaney
[gentoo-dev] A news item covering PYTHON_TARGETS
On Mon, 29 Oct 2012 15:45:01 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, Since some ebuilds are using that variable already and we still didn't inform most of our users if and how they should set it, I'd like to commit the following news item: Title: PYTHON_TARGETS deployment Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2012-10-29 Revision: 1 News-Item-Format: 1.0 Lately, a new Python eclasses were deployed and the way of supporting multiple Python implementations changes with ebuilds being migrated to them. While before the implementations being installed were used by default, the migrated packages will instead use explicit choice based on PYTHON_TARGETS USE flags. This may require action from some of our users. If you are running a modern system with Python 2.7 3.2, and you didn't set USE_PYTHON, then you don't have to do anything. The defaults will fit you. Otherwise, you will want to set PYTHON_TARGETS in your make.conf file. This is a regular USE_EXPAND variable listing requested Python implementations like: PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 The variable should list all requested Python implementations. A complete list of possible values can be obtained using a command like: emerge -1pv dev-python/python-exec this might be slghtly be reudundant, but how about set PYTHON_TARGETS in place of PYTHON_ABIS or USE_PYTHON in /etc/make.conf. Technically it's not essential. PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 is just right, a clear example of each. While before the implementations right and doesn't read quite right, either just delete before or While the implementations being installed were used by default by python.eclass deleting the word before. I think a simple comma might make the original valid; While before, the implementations being installed were used by default -- kind regards Ian Delaney -- kind regards Ian Delaney
