Re: [gentoo-dev] dev-embedded/tigcc needs an urgent bump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/12 07:48, Pacho Ramos wrote: > El lun, 23-04-2012 a las 20:35 +0200, Pacho Ramos escribió: >> Our stable versions are broken for a long time, they even don't compile, >> but we cannot stable latest testing version because of a buffer overflow >> problem. A bump could help, but looks like embedded team doesn't have >> enough time for it. Is anybody interested in taking care of it? >> >> Its bugs: >> https://bugs.gentoo.org/buglist.cgi?quicksearch=tigcc&list_id=978701 >> >> Thanks > > Or maybe we should simply treeclean it if nobody is willing to > fix/maintain it and since nothing in the tree needs it... > I've submitted what I hope is fix for the buffer overflow problem to bug 337059. Will that be sufficient to remove the block on stabilization? - --Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+dm5gACgkQ23laikJhg1Q2aQCeOOHS3tB0gVfCxQ79ldSBMV3N gEYAn3Ek1hpIhU/CSjsLxMEa13bx8R0t =0uOv -END PGP SIGNATURE-
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2012 08:52 AM, Tomáš Chvátal wrote: > 2012/10/31 Dirkjan Ochtman : >> That's rather unsurprising... >> >> If you're going to file bugs "in a semi-automated manner", might >> as well try to assign to the correct maintainer? >> > Yep he should've assign them, but anyway the annoying elog > messages are an issue. And quite few packages suffer from it :-) > > Tom > I disagree on most of them (and have marked the KDE-related bugs as WONTFIX appropriately). Messages that tell the user about config options, or "for x functionality install y" (at least until we get SDEPEND or something similar added to portage) should show up every time in my opinion. Only initial config and "you just enabled (flag)" really merits this. Basically, I would rather the user get too many elog messages than not enough, since I feel that a lot of people skip over them anyway and so the "only display once" method makes it far too easy for important messages to get lost in the shuffle. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCRQQAACgkQ23laikJhg1Q+aQCeLfXsAmbtXNGOcBzM/vJaMat2 ly0AoKFzB3tPLaSO2RK0p2rWd6CoKMXm =J+3S -END PGP SIGNATURE-
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
On August 14, 2016 5:49:48 PM EDT, Kent Fredric wrote: >On Sun, 14 Aug 2016 22:45:07 +0100 >Ciaran McCreesh wrote: > >> What's a Working Group, and how is it related to a Project? Shouldn't >> there be a GLEP to define what a Working Group is first? > >So if a group of people wanted to write such a GLEP ... would they have >to be part of a defined Project first, or would they form a Working >Group, and then be stuck in a recursive loop needing themselves >defined before they can define themselves? Friendly reminder that anyone may submit a GLEP, it doesn't need to be on behalf of an official group. If memory serves, there isn't even a requirement that the submitter/"champion" even be a Gentoo dev. So although there is a theoretical recursion issue, in practice it's a silly question. creffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Last rites: app-office/openproj-bin
# Chris Reffett (08 Jan 2017) # Superseded by projectlibre-bin, please migrate to that. # Masked for removal in 30 days. app-office/openproj-bin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new "qt" category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/17/2013 08:57 AM, Ben de Groot wrote: > Hi guys, > > Presently we already have a good number of split qt-* library > packages in x11-libs. With the arrival of Qt5 upstream has gone a > lot further in modularization, so we expect the number of packages > to grow much more. We, the Gentoo Qt team, are of the opinion that > the time has come to split all these out into their own category. > This category is to be used for the various modules and > applications that belong to the upstream Qt Framework only (these > include e.g. assistant and linguist). Third-party applications > should remain in the current categories. > > After some initial bikeshedding we came to the conclusion that > naming the category simply "qt" is the most elegant solution. We > will then also be dropping the qt- prefix in package names. This > means x11-libs/qt-core will be moved to qt/core, and so on. > > Please let us know your thought on this. > +1ish. I'm all for a new category (specific naming scheme to be bikeshedded, no preference there), but I think dropping the qt- prefix will lead to overly generic/already existing package names: "gui" "declarative" "dbus" "core" "opengl" etc. I don't see any value from dropping the prefix that would justify this. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlD4RbIACgkQ23laikJhg1SUngCfatp7/zOP4iGym3sitfH6xpA6 mPAAn2+4HWyOF5+qj2DNIn9IjflOXYc4 =TuOb -END PGP SIGNATURE-
Re: [gentoo-dev] theology herd is empty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2013 04:34 AM, Pacho Ramos wrote: > If we agree on keeping this herd instead of trying to find one > maintainer per package, somebody should join. Otherwise I will > move their packages to maintainer-needed in a week > > Thanks > I will join this herd, but anyone who wants to add themselves as a maintainer to a package is welcome to do so. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD8LQYACgkQ23laikJhg1SqkgCfbVyh/gK1lCwGJMkuP0I+HDPM VSwAn2rlVv6TCuvTP8EldDfXruWkHk8v =dWxs -END PGP SIGNATURE-
[gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, At the beginning of July, the KDE team will be removing EAPI 0/1 support from cmake-utils.eclass and inlining the functions from base.eclass in order to remove that inherit [1]. The modified eclass is currently available in the KDE overlay. There is one package [2] remaining in-tree which has EAPI<2 which will be handled soon, but please update any overlay packages using the eclass. I have also added a deprecation warning to the in-tree cmake-utils.eclass for packages using EAPI 0/1. Chris Reffett [1] https://bugs.gentoo.org/show_bug.cgi?id=459678 [2] https://bugs.gentoo.org/show_bug.cgi?id=460572 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlG6PmRfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QIkgCfV+VLuCg3bC880EhaTiol4ggB jhQAoJaBwxZHwH9l4g48olShsnWDZBos =qeh9 -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass dropping EAPI 0/1 support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/13/2013 06:37 PM, Alexis Ballier wrote:
>> At the beginning of July, the KDE team will be removing EAPI 0/1
>> support from cmake-utils.eclass and inlining the functions from
>> base.eclass in order to remove that inherit [1].
>
> So, instead of fixing what you consider wrong in base.eclass, you
> inline it so that if someone improves base.eclass he has to do it
> for cmake-utils too?
>
We did not actually inline most of the complicated logic from
base.eclass, as to the best of my knowledge epatch itself will handle
all of the corner cases that base_src_prepare covers. The new patching
code essentially consists of [[ ${PATCHES[@]} ]] && epatch
"${PATCHES[@]}"; epatch_user. As for the reason for the change, the
request and rationale can be seen in the first bug that I linked in
the email.
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlG6TDVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S3SACgitmH0FVRUNwmJE9e/4JmrwqV
ucwAnj+/+V9ECy9OoCK6eDqSsuiiTgDU
=5QKk
-END PGP SIGNATURE-
[gentoo-dev] Request for testing: plasma-active
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, The KDE team has added Plasma Active to the KDE overlay, under the (provisional) category name kde-active. Plasma Active is based on KDE and is designed for mobile devices. We are not able to test it at present as none of the KDE team has a mobile device running Gentoo, so we would be very appreciative if community members would help us by testing and reporting bugs to us. To install it, add the overlay (layman -a kde) and emerge all of the packages in the kde-active category. Thanks, Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlHE4LdfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1RYvwCgpqhdNy0VJJFPnpmQr46mCS77 mt4AnAi8c78k109hpsTPYqdcNFYpTC7j =EURc -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass and bug 475502
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2013 04:57 PM, hasufell wrote: > I know there was an announcement about the upcoming change to > cmake-utils.eclass, however... it is not enough to give a deadline > without caring if people actually fixed it by then. > > By doing that you risk breaking stable packages which is not > trivial. > > You _must_ do a tinderbox run, test that stuff in an overlay or > whatever. You are responsible for ALL reverse deps. > > The way it was done... was not appropriate. Please be more careful > next time. There are still incoming bugs about broken base_src_* > calls. (see the tracker) > I discussed this with hasufell on IRC, but I'll lay out the response on the list too. Yes, this was my fault. We (KDE team) tested in our overlay, but none of the packages there use the base_src_* calls, which is why it didn't come up in testing, and I did not realize that there were packages that did rely on the implicit base inherit to call base_src_* directly. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlHnCfVfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T6ZACcC5cDNBCODxrnzlPCTm+L4EgS wCkAniqjyBFXhIXeXyb0Wbvufkbw68yS =QM3o -END PGP SIGNATURE-
Re: [gentoo-dev] Re: KDE/semantic-desktop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/08/2013 01:52 PM, Rich Freeman wrote: > On Thu, Aug 8, 2013 at 1:44 PM, Martin Vaeth > wrote: >> Sorry for reposting: Somehow the first line got lost making the >> whole posting not understandable... >> >> Andreas K. Huettel wrote: >>> >>> answer is about 10 additional megs of ram at idle and about 2 >>> extra seconds to boot. >> >> ..and two huge database servers which lots of disk and ram space >> and a huge waste of compile time (not so much for KDE but more >> for the databases), opening to all sort of possible attacks by >> bugs in these databases whose servers need to be running etc. >> > > Do those servers still run if you disable the features in the > control panel? I already run MySQL so the only annoyance for me > was getting it to use the existing instance rather than spawning a > new one. > > If somebody is willing to join the KDE team to support keeping > that option (even as a proxy maintainer) I think the team should > work with them. I think that we should generally offer any choice > as long as somebody steps up to support it properly (and I do mean > properly). While I'm sure the KDE team has their faults they do > announce their meetings/etc and I suspect it would be an easy team > for an outsider to get involved with as a result. > > Rich > Lies! Blatant lies! The KDE team has no faults! :) ...but seriously, if someone were willing to work with us and put in the effort, I'm sure we could work something out. I'll skip the usual part about explaining our motivations behind the original removal since that's been discussed ad nauseam in bugs and on the -desktop list. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlID4FpfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TlrQCfXM1Pmi1lwwBCsSEfwyC3E5MJ zQUAn2OZ8pvujwUnu+bLtCZ0e4lacuui =tus9 -END PGP SIGNATURE-
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Indeed I have. If you want to start such a project, I would certainly be interested in joining. Plasma Active is basically untested because I don't have a mobile device with Gentoo and installing it on a normal computer leads to display sizing issues, but I welcome any suggestions or bug reports you have for that. What I would really like to see come out of this is some pre-made Gentoo stage4s for different kinds of devices, which I think would be a big draw for users. Chris Reffett On 8/13/2013 1:09 PM, Andreas K. Huettel wrote: > Benda, > > while I won't have the time to contribute much, I would like to tell you that > this is definitely a very cool and worthwhile project! I think you should make > a project page and sign yourself up as team lead immediately... :) > > Chris Reffett from KDE team has done already a lot of work on packaging Plasma > Active, see http://plasma-active.org/ - it's in the KDE overlay but mostly > untested so far. You might be interested! > > Best, > Andreas > >> Dear Fellows, >> >> Canonical is raising money by pushing their concept of Ubuntu for >> Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) >> in parallel to Android to drive the external HDMI output with X11 >> protocal, so that desktop applications can run on the smartphone. >> >> The idea is cool, but not new. The idea is general to all android >> devices, while Canonical is binding the concept with its own new device. >> >> The project is developed underground by Canonical, so far nothing, not >> to say repository, is available except advertisements and the call for >> people to donate. >> >> As a natual consequence of the on-going Google Summer of Code project, >> Gentoo on Android[3], we can run native Gentoo on *all* the Android >> devices. Compiling out an Xorg and output to HDMI has no theoretical >> difficulty. Furthermore, sharing of graphic output with Android (instead >> of a separate HDMI output) can be explored with wayland x11[4]. >> >> I feel sorry to the behavior of Canonical. We, people from the Gentoo >> community, can show the general public what is the cooperative way to >> develop desktop/smartphone hybrid to benefit all. >> >> I would like to kick out a sub-project of Gentoo targeting smartphone >> and tablets. It would be nice to find out a solution based on Gentoo for >> desktop/smartphone hybrid *before* Canonical's release. >> >> Comments welcome. >> >> Cheers, >> Benda >> >> 1. http://www.ubuntu.com/phone/ubuntu-for-android >> 2. http://www.indiegogo.com/projects/ubuntu-edge >> 3. http://www.awa.tohoku.ac.jp/~benda/projects/android.html >> 4. http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29
[gentoo-dev] Last rites: dev-games/neotools, dev-games/neoengine
# Chris Reffett (03 Sep 2013) # Dead upstream, outstanding security bug #260956. # Masked for removal in 30 days. dev-games/neoengine dev-games/neotools signature.asc Description: OpenPGP digital signature
[gentoo-dev] mobile-phone herd needs help
Hi folks, I'm currently the only dev in mobile-phone, and I don't actually use any of the packages in the herd (I added myself just to keep the packages from going into m-n, but I don't have the time to attend to the bugs lately). There aren't too many bugs assigned to the herd at this point. If nobody joins, I will be removing myself and we'll do the usual herd-removal procedure within the next couple weeks. Chris Reffett
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/8/2013 7:14 PM, Markos Chandras wrote: > Hi, > > I see nobody seems to take care of nagios packages anymore. > There are numerous bugs (and many of them are pending version bumps). > > Is the sysadmin@ herd still interested in this package? If not, could > you please consider moving it to maintainer-needed@? Maybe users are > interested in working with proxy-maintainers to bring this package up > to date. > > https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios > If sysadmin@ doesn't want it, I know a user/potential dev who would be interested in maintaining it with me as a proxy. Just let me know. Chris reffett
Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC
On 12/11/2013 3:41 PM, William Hubbs wrote: > All, > > We got a request from Debian to rename the "rc" binary of OpenRC due to > a naming conflict they have. They have a port of the at&t plan 9 shell, > which has a binary named "rc" as well[1]. > > My thought is to rename our "rc" to "openrc", since that would be > unique. > > I know at least one thing that will break is everyone's inittab, so > should I sed their inittab in our live ebuild or expect them to fix it > and give a warning? I know that once OpenRC with this change is > released, it will need to probably be p.masked until there is a new > release of sysvinit that updates the inittab. > > I'm not sure what else will break. > > Does anyone have any ideas wrt other things to look for, or should I > make the changes upstream and have people let us know what > else breaks? > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=493958 The idea of running a sed on inittab in an ebuild, no matter what the context, terrifies me. Perhaps we can ease this in slowly by renaming rc -> openrc and symlinking rc -> openrc and making a release with that change concurrent with a news item? Or even just do that in the ebuild rather than in the actual sources. I don't think Debian will keel over and die if it takes a little extra time for the change to go through, and it beats a ton of broken systems. Chris Reffett
Re: [gentoo-dev] Re: Portage QOS
On 01/09/2014 03:42 PM, Igor wrote: > Hello Duncan, > > Thursday, January 9, 2014, 9:59:50 PM, you wrote: > > Thank you for the reply. I started to comment first... but it was more > philosophy a mature and grown up, experienced man and I don't think > I have right to comment it. > > Statistically if you have more users the probability of the system > survival of any architecture, philosophy or type is higher. People > learn, they're not fixed and if they at the beginning do not share > the philosophy of the system but they can use it - they may like it, > understand it and follow it and support later. Many people I asked > are not minding to help Gentoo getting better by turning on > feedback. If you remember - feedback worked well for Perl once and > many used it and Perl is very traditional. > > It's like a chess game. You have the system in it's prime. There is > already one fork from Gentoo. There will be more. It's inevitable. You > have to understand that not all the developers share the same > philosophy - and it OK. > And they may fork Gentoo with time and pull half of the team to their > side. > > When there is a competition between systems with equal philosophy the > only thing that stands between who is going to live and who is going > to die is the number of users. > The fight will focus not around philosophy or system but around gaining > user support. The competitor can build a better, more friendly system > sharing basically the same design and he will win it over. > > To keep in power it's in your deepest interest to close the open gates that > invite competition while the power is in your hands. This is a failure > many grown up companies made they belive they're forever and gods. I could > share with you privately with several examples that prove that concept > wrong. > > Your competitors will build basically the same system targeting the > same philosophy but more user oriented, friendly. User oriented - means > each user opinion matters. > > There might be millions of users but each is treated like he is the only one. > > > PortageQOS is small step, it's not everything or main part of the > system, it's a just small contribution. But it will close the door and > you'll have another peaceful 8 years to rule. > Right here is the big problem: you're not looking at this from the perspective of the average Gentoo developer. We don't care about market share. We don't care whether we're on top for another few years. There are several forks of Gentoo. I doubt most devs care about them. I personally know that we're not going to compete with Debian, which has a huge contributor, or Ubuntu or Red Hat, which have whole companies behind them. You're selling this as if you're selling to a company which wants to be on the top of the market and beating out competitors, and that's not what we are. We are a source-based distro that requires some effort from users, and people want that or they don't want it. > What we need is a vote YES or NO. If you against it - vote NO. It's > perfectly normal, if there would be no NO there would be no need voting. > > >> Actually, in that regard it's very possible that gentoo's long planned >> and worked toward cvs-to-git conversion will help finally bust that >> barrier for gentoo as well. Time will tell I guess, but that's one more >> reason to try to help make it happen. > > > > Chris Reffett
Re: [gentoo-dev] Regarding long delays on GLSA generation
On Jan 18, 2014 1:35 PM, Pacho Ramos wrote: > > El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: > [...] > > So you observed correctly there's still plenty of delays. There are > > three parts to an advisory that take time: > > - Drafting: Collecting information, linking references, getting package > > versions done right (slots are a huge pain still). > > > > - Reviewing: Our current process asks for two independent positive > > reviews from other team members before an advisory can be sent. > > > > - Sending: The original author gets a .txt to email and have to check in > > the .xml to CVS. > > > > Going through these three steps requires at least three people, and the > > (group of) people whose action is required shifts twice. That overall > > process is spot #1 we are planning to improve. The current plan contains > > requiring only one review and the reviewer sends the advisory directly. > > So we go from author -> reviewer 1 -> reviewer 2 -> author to just > > author -> reviewer. > > This looks a nice improvement indeed :) > > > > > Concerning the single steps here are other measures: > > - Drafting: Implement a new GLSA format to > > * reduce the amount of editorial text written by us > > * support slots (makes specifying vulnerable ranges in slotted package > > much easier) > > * (cleanup old stuff no longer needed) > > That looks interesting as doing all the draft manually is really a huge > work (with leads to not so enhancement). I am unsure how will the > cleanup be done, as soon as the portage tree doesn't break (due some > other package requiring the old buggy version), why are not all devs > allowed to drop (or, at least, hardmask if needed for some base-system > package :/) the vulnerable versions? Looks like currently security team > waits for maintainers to do that, I try to do it fast but maybe will > take much more time in other situations. I think this could be improved > if other people like security team members or the last one stabilizing > the fixed version could do the cleanup too. We prefer that the maintainers do the drop in case there's some dependency situation we're not aware of, but we will drop if maintainers are unresponsive. > Also, currently looks like, when we (maintainers) get asked to bump the > package fixing it, we tend to wait for security team members to CC > arches, maybe the maintainers could do that directly to gain a bit of > time. By all means, maintainer should be the one to call for the stable. It's your package, I cannot think of any situation where security would not want the maintainer to do that. > > > > - Reviewing: Reduced editorial text means less to review. > > > > - Sending: We want to improve our tooling to automatically send > > advisories and push them to a git repository. > > > > The new GLSA format was up for review on -security last week. Next up > > will be getting it specified formally, implemented in our tooling, > > glsa-check and a new security.g.o frontend. [1] > > Then, we can adopt the new workflow. > > > > > > > > Then, instead of blaming on how should I have asked for clarification on > > > this (well, looks like the main topic here is that I have asked about > > > this in ML instead of the real problem :O), I think you should focus on > > > explaining how are you fixing this problem. > > > > Your original email didn't reflect actual interest in the details. Now > > that we've established you do care, I hope my explanations helped you > > out there. > > > > They helped for sure :) and I appreciate them, I simply thought nothing > was being worked out as I explained in previous mail (I was still saying > long delays) > > > > I have been long time wondering about this because: > > > 1. I usually get lots of bugs from alias I am a member whose we go fast > > > bumping, calling for stabilization and dropping vulnerable versions and, > > > the, the bugs get stalled. > > > 2. Once of the machines I maintain would benefit from being able to use > > > glsacheck to only update vulnerable packages as not always have enough > > > time for updating the full world > > > > > > > > > > > > > [1] Lots of code to be written here. .py+.rb, help wanted! > > > > >
[gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
After some discussion on good ways to communicate optional
dependencies to users, I was shown the optfeature() function in
net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up with
a cleaned up and expanded version of it, and I would like to add it to
eutils.eclass to provide a standard way of notifying users of optional
dependencies. The patch to eutils.eclass is attached.
Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iKYEARECAGYFAlLhQklfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1TDkwCeJ7MQliIiI6ViSkZzD+eIYM/J
0F4AoIVMP32HenJcjOkTIJkd6vGniiSi
=+oIe
-END PGP SIGNATURE-
--- eutils.eclass 2014-01-22 23:36:35.81900 -0500
+++ eutils.eclass.patched 2014-01-23 00:37:07.90700 -0500
@@ -1729,4 +1729,49 @@
check_license() { die "you no longer need this as portage supports ACCEPT_LICENSE itself"; }
+# @FUNCTION: optfeature
+# @USAGE: [other atoms]
+# @DESCRIPTION:
+# Print out a message suggesting an optional package (or packages) which
+# provide the described functionality
+#
+# The following snippet would suggest app-misc/foo for optional foo support,
+# app-misc/bar or app-misc/baz[bar] for optional bar support
+# and either both app-misc/a and app-misc/b or app-misc/c for alphabet support.
+# @CODE:
+# optfeature "foo support" app-misc/foo
+# optfeature "bar support" app-misc/bar app-misc/baz[bar]
+# optfeature "alphabet support" "app-misc/a app-misc/b" app-misc/c
+#
+optfeature() {
+ debug-print-function ${FUNCNAME} "$@"
+ local i j msg
+ local desc=$1
+ local flag=0
+ shift
+ for i; do
+ for j in $i; do
+ if has_version "$j"; then
+flag=1
+ else
+flag=0
+break
+ fi
+ done
+ if [[ $flag -eq 1 ]]; then
+ break
+ fi
+ done
+ if [[ $flag -eq 0 ]]; then
+ for i; do
+ msg=" "
+ for j in $i; do
+msg="${msg} ${j} and"
+ done
+ msg="${msg:0: -4} for ${desc}"
+ elog "${msg}"
+ done
+ fi
+}
+
fi
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 11:28 AM, Michał Górny wrote: > Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett > napisał(a): > >> After some discussion on good ways to communicate optional >> dependencies to users, I was shown the optfeature() function in >> net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up >> with a cleaned up and expanded version of it, and I would like to >> add it to eutils.eclass to provide a standard way of notifying >> users of optional dependencies. The patch to eutils.eclass is >> attached. > > This was discussed already: > > http://thread.gmane.org/gmane.linux.gentoo.devel/72162 > First of all, this is a short patch for a function, not a full eclass. Further, people are doing this sort of thing already (printing messages to say "if you want support for x, install y," this is just making it easier to do so. Of course full support for an SDEPEND variable would be much better, but unless you have a patch for that ready to go for the next EAPI I don't see that happening anytime soon, so a short function in eutils seems like a reasonable choice to me. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLhRPZfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QaawCeM3GnYAc83Czei2r1l2XHFFB4 sAgAn21yARrui9E+ZsNnk75UCk0j0oEp =VTT0 -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2014 05:12 AM, Markos Chandras wrote: > On 01/23/2014 04:48 PM, Michał Górny wrote: >> Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett >> napisał(a): >> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> >>> On 01/23/2014 11:28 AM, Michał Górny wrote: >>>> Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett >>>> napisał(a): >>>> >>>>> After some discussion on good ways to communicate optional >>>>> dependencies to users, I was shown the optfeature() >>>>> function in net-misc/netctl. Gentoo contributor Andrew >>>>> Hamilton and I came up with a cleaned up and expanded >>>>> version of it, and I would like to add it to eutils.eclass >>>>> to provide a standard way of notifying users of optional >>>>> dependencies. The patch to eutils.eclass is attached. >>>> >>>> This was discussed already: >>>> >>>> http://thread.gmane.org/gmane.linux.gentoo.devel/72162 >>>> >>> First of all, this is a short patch for a function, not a full >>> eclass. >> >> Ah, sorry, this changes *a lot*. Let's start the bikeshed again >> then, whatever. >> > I haven't looked at the implementation, but I wonder if we need a > function for such trivial stuff. Most maintainers deal with this > problem using pkg_postinst() einfo/elog messages. Why do we need a > dedicated function for that? Just for consistency reasons...? > Consistency, and because it removes the need for a bunch of "if has_version" lines, instead only displaying if you don't satisfy the deps (and supports both "and" and "or" groupings for packages satisfying the dep). This also stems from a complaint I've seen a lot about how optional dep messages should only display if the requisite package isn't installed, this makes that job a little simpler. But mostly consistency, this gives us one nice function that we can standardize on. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLjt6NfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1SAZACgqLjfMMmvPNa/6Nwxzlpm5sde kwQAniZMjvFkQ7H/1+wpYnDjyezplMud =6E+E -END PGP SIGNATURE-
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 01/25/2014 12:22 PM, Andrew Hamilton wrote: > On 1/25/2014 9:24 AM, Markos Chandras wrote: >> On 11/10/2013 06:12 AM, Johann Schmitz wrote: >>> - gpg control packet >>>>> I already have too many packages to take care of but my company >>>>> is using nagion on Gentoo so I take care of it. Although I >>>>> wouldn't mind if somebody else helps with the packages as well. >>> >>> We use Nagios on many servers at work, so i can help out with these >>> packages too. >>> >>>> ... git overlay for easier nondev contributions? :) >>> >>> A git repo would be useful if there are many changes to the code (e.g. >>> plugins). From what i see in the buglist, most of the bugs are ebuild >>> related (bumps, compile and installation issues). >>> >>> >> (picking a random email from the thread) >> >> ping again. 3 months later, the list of bugs remain the same. Shall we >> consider dropping it to maintainer-needed? >> > I would be happy to proxy-maintain these packages. > > Andrew Hamilton > I will proxy for him, will update metadata shortly. Chris Reffett
[gentoo-dev] January 2014 QA Policy Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, The new QA team has completed its first meeting, and so I would like to announce policy changes agreed upon during the meeting which are relevant to the developer community. In the future, when a meeting results in changed or amended policy, we will notify the community via - -dev and -dev-announce, so there will probably be a summary email like this coming out about once a month. Changes to policy from this meeting: - -USE-controlled optional RDEPENDs policy clarified to say that those dependencies are not allowed, but QA will grant exceptions for certain circumstances (such as a package not working unless one of a set of optional deps is installed) - -The QA team policymaking workflow will look like the following: * User/dev/team member brings us an issue * Team investigates * Team discusses at the next meeting ** If the person is violating policy, we inform them of that and request that they stop violating policy ** If the existing policy is unclear, we update it ** If there is no existing policy, make one If we think a developer's actions are causing problems, we may ask them to stop/undo pending discussion by the QA team at the next meeting. - -Rules for the QA team editing peoples' packages: *For trivial fixes, such as repoman errors, we fix the issue and send the developer a friendly reminder *For large but non-critical fixes, we open a bug, wait 2 weeks, and if it is not fixed within that time frame we make the change. *For critical fixes, such as a problem that breaks the tree or a package, we fix the issue and send the developer a notice about our change - -The QA team will communicate changes to policy via emails to gentoo-dev and gentoo-dev-announce and by updating the QA policy page on the Gentoo Wiki. For anyone interested, the summary of the meeting can be found at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries and the current set of QA policies can be found at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If you have any questions or concerns about these policies, feel free to discuss them with us in #gentoo-qa or by emailing q...@gentoo.org. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLp51VfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1R6zwCfXY0q7Ig3d40Xq2hScLcT4Hm6 zE8AoJfIWsuV9yAKdsuxwB6JSDr8KbZY =sheY -END PGP SIGNATURE-
Re: [gentoo-dev] January 2014 QA Policy Updates
On 01/30/2014 03:10 PM, William Hubbs wrote: > On Thu, Jan 30, 2014 at 12:47:01AM -0500, Chris Reffett wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hello all, >> The new QA team has completed its first meeting, and so I would like >> to announce policy changes agreed upon during the meeting which are >> relevant to the developer community. In the future, when a meeting >> results in changed or amended policy, we will notify the community via >> - -dev and -dev-announce, so there will probably be a summary email like >> this coming out about once a month. Changes to policy from this meeting: >> >> - -USE-controlled optional RDEPENDs policy clarified to say that those >> dependencies are not allowed, but QA will grant exceptions for certain >> circumstances (such as a package not working unless one of a set of >> optional deps is installed) >> >> - -The QA team policymaking workflow will look like the following: >> * User/dev/team member brings us an issue >> * Team investigates >> * Team discusses at the next meeting >> ** If the person is violating policy, we inform them of that and >> request that they stop violating policy >> ** If the existing policy is unclear, we update it >> ** If there is no existing policy, make one >> If we think a developer's actions are causing problems, we may ask >> them to stop/undo pending discussion by the QA team at the next meeting. >> >> - -Rules for the QA team editing peoples' packages: >> *For trivial fixes, such as repoman errors, we fix the issue and send >> the developer a friendly reminder >> *For large but non-critical fixes, we open a bug, wait 2 weeks, and if >> it is not fixed within that time frame we make the change. >> *For critical fixes, such as a problem that breaks the tree or a >> package, we fix the issue and send the developer a notice about our change >> >> - -The QA team will communicate changes to policy via emails to >> gentoo-dev and gentoo-dev-announce and by updating the QA policy page >> on the Gentoo Wiki. >> >> For anyone interested, the summary of the meeting can be found at >> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries >> and the current set of QA policies can be found at >> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies. If >> you have any questions or concerns about these policies, feel free to >> discuss them with us in #gentoo-qa or by emailing q...@gentoo.org. > > I have one. > > The way I read that email, we are saying that our only policies are on > the wiki. > > Is that right, or is the DevManual stil relevant? > > If it is, I would suggest that on the wiki we make it clear that our > technical policies are all in the devmanual. Along that line, I would > suggest moving the stabilization policy to the devmanual. I'll look for > a place for a patch. > > William > That's my mistake, the devmanual is still relevant. My idea is to use the wiki page for smaller or more specific items which probably don't go in the devmanual (for example, policy which is about specific packages or USE flags, or policies which just affect the QA team). Stabilization should go to the devmanual, then. Chris Reffett signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] January 2014 QA Policy Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2014 09:07 AM, Peter Stuge wrote: > Alec Warner wrote: >>> hmm? >> >> To be fair, I had a long discussion with this regarding when QA >> has the authority to temporarily ban a developer. > > Cool. > > >> In the case where policy is missing, QA does not have a clear >> case of authority there. It becomes a more murky area. I've tried >> to very much encourage QA to both publish the policies they want >> to enforce, and automate enforcement with better tooling (repoman >> or otherwise). Being transparent and consistent in enforcement >> of policy goes a long way for getting developers on your side. > > Absolutely. > > >> So in short, while one could read that passage as you did, I >> don't think that is their intention. > > To be clear, I don't think so either. > > > Rich Freeman wrote: >> I was really happy to see a public notice of meeting and a >> published summary. > > Yes, me too! > > > I still think it seems like QA could essentially introduce > arbitrary new policies and 2 weeks later be expected to effect > them. > > Fine when everyone agrees. Not so much at other times. The > responsibility is with QA to build support among the developers, > and I agree that the transparency goes a long way! > > > //Peter > Regarding the question in your first email: We will not create a policy then immeiately use the policy as justification to to go edit packages. The intention of the "we may ask the developer to stop" line is for cases where we suspect that what the developer is doing is causing a problem and would like to discuss it further. I feel that that is well within the bounds of GLEP 48. As for the "when/how we make and communicate fixes," I think that just about any policy we make will fall into the middle ground you omitted of "file a bug, wait 2 weeks, fix." So no, we will not be making arbitrary fixes just because we can. Regarding your concern about us introducing arbitrary policies: again, most will fall into the "file a bug" middle ground. We also are perfectly aware that you can't expect people to change overnight, and we will not be shouting at devs just because they didn't implement $(new-policy) right away. We will file bugs asking for changes, and we will try to offer suggestions or patches wherever possible to make it easier for maintainers. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLrv0hfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QZ+wCeJre5n44E9BdZcUBgZdC5DjPe WR8AoJ1W9QuqVIFXxsVAWBO23yx+etak =5CIT -END PGP SIGNATURE-
[gentoo-dev] February 2014 KDE team meeting
Hello all, The next KDE team meeting will take place on Feb 20 at 1900 UTC in #gentoo-meetings. Our agenda (yet to be filled in) can be found at https://wiki.gentoo.org/wiki/Project:KDE/Meeting/2014-02. All are welcome to attend. Chris Reffett signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
ers and/or developers interested in arch > testing (and/or Gentoo)? Do we want to make a policy change now, or > delay considering it till a later meeting in the future? ...?" > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda > > I really didn't want to get involved in this mess, but here goes: - -Due to concerns about the wording of the policy, it is currently on hold pending review at an upcoming QA team meeting. - -Any further input/attempts at interpretation by QA team members at this point would needlessly confuse the issue, therefore, I would appreciate it if the QA team would stop trying to do so. We will have a meeting, argue it there, and vote. Right now, all this arguing just makes everyone more confused about what our opinion is. - -I realize that our policy was unclear and may conflict with existing policy on ebuild removal. I apologize for that, and will keep this episode in mind in the future. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLzAFBfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T76QCeOCFk8ClakUmKMqD0ldJEFQE2 kxkAn1Zw/6sSOghbc43KC4QEVzolYIvn =+Pmi -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote:
> Thanks for attaching link to team's policy which tries to lift any
> kind of ambiguities people may have for what concerns gnome team's
> packages, I hope it proved useful in your discussions.
>
>
> Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit
> :
>> Hello fellow developers,
>>
>> In the first meeting of the new QA team, we discussed the state
>> of the gtk{,2,3} USE flags in the main tree. [0]
>>
>> In its current state, USE="gtk" means gtk2. The Gnome team is
>> trying to change this into "the most recent gtk version" (it is a
>> work in progress).
>
> Wrong, gtk USE flag means "enable gtk support", whether this is gtk
> 1, 2 or 3 depends on what the package (presumably library) supports
> and whether is can be slotted or not and whether current gentoo
> maintainer decides what can be reasonably supported.
>
>> Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in
>> packages that may support either or both the toolkits. To handle
>> this, a few developers have introduced the "gtk3" useflag, that
>> prefers gtk3 over gtk2 when both toolkit versions are supported.
>> At this point, the Gnome team highly recommends prefering gtk3 if
>> possible, skipping the useflag altogether. [1]
>
> Wrong, as is written in policy whether to prefer gtk2 or 3 is up to
> the maintainer of the package. We point people to the fact that
> upstream says gtk2 is a dead end and support will stop (if not in
> fact already stopped) in the near future.
>
> We also recommend to have maintainers support slots for their libs
> where possible considering man-power and to only choose one toolkit
> for applications considering where upstream development is going
> and maturity of the port, and again, this is up to package
> maintainers.
This doesn't make sense to me at all. I can't see why slotted
libraries can't just use USE flags to specify what toolkit they're
built against, just like any other package in the tree (so, for
example, a package that needs webkit-gtk built against gtk3 would
depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware
that there could be limitations I'm unaware of (maybe the package only
can build one at a time?), but this is how it looks to me. By
switching to versioned gtk flags, this kills two birds with one stone:
it makes it obvious to the end user which version they're trying to
build their package against, and it gets rid of the need for (ab)using
revision numbers to implement slots like that.
>
>> Some developers choose to follow the Gnome team's highlights,
>> while others choose to go their own way. The QA team would like
>> to establish a guideline that solves this problem in the best way
>> possible.
>>
>> During our discussion, it was pointed out that keeping a generic
>> USE="gtk" is sub-optimal. The non-straightforward nature of new
>> toolkit versions makes transitioning from one to the other a
>> slow, tedius process and we think that a non-versioned USE flag
>> makes things even worse.
>>
>> A few of our members recommended a move away from the unversioned
>> USE="gtk" to versioned-only USE flags. Qt managed to do this
>> quite successfully when they transitioned from the unversioned
>> USE="qt" (that actually meant qt3) to USE="qt4". The benefits can
>> be seen now that qt5 is around the corner. USE="qt5" is
>> straightforward, does not mess with qt4 packages and was
>> introduced to the tree without messing with current packages too
>> much - other than adding a new use flag where appropriate. There
>> is also no need for USE="qt" anymore.
>>
>> To achieve this, version 3 of gtk should always be enabled by
>> USE="gtk3". At some point in the future, when gtk2 consumers
>> reach zero, we will retire "gtk" for good. Then, if some day gtk4
>> comes around, we will be able to introduce support for it in the
>> tree by simply adding USE="gtk4", without having to re-structure
>> half the tree.
>>
>> We are reaching out to the developer community to hear your
>> thoughts and ideas on the matter. We would like to reach a
>> decision that could possibly affect and direct the state of whole
>> tree. This decision could then be turned into a policy, improving
>> Gentoo's consistency across the tree.
>
> Imho the whole discussion stems for packages maintainers which, as
> you have written, did not follow our recommendation and tried to
> provided application with both gtk2 and gtk3 support.
>
> I agree that "Gentoo is about choice..." however as a maintainer of
> a lot of packages, it is unreasonable to try to support two
> configuration where one is dying slowly due to upstream (gtk)
> maintainer focus being elsewhere, hence why we wanted maintainers
> to choose. Instead, it occurs that some decided not to choose or to
> stop users from annoying them with 100 of duplicate bugs about not
> providing the alternative.
>
> Looking at the situa
Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 2/12/2014 3:09 AM, Michał Górny wrote: > Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett > napisał(a): > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: >>>> Unfortunately, the concurrent nature of gtk2/gtk3 has >>>> resulted in packages that may support either or both the >>>> toolkits. To handle this, a few developers have introduced >>>> the "gtk3" useflag, that prefers gtk3 over gtk2 when both >>>> toolkit versions are supported. At this point, the Gnome >>>> team highly recommends prefering gtk3 if possible, skipping >>>> the useflag altogether. [1] >>> >>> Wrong, as is written in policy whether to prefer gtk2 or 3 is >>> up to the maintainer of the package. We point people to the >>> fact that upstream says gtk2 is a dead end and support will >>> stop (if not in fact already stopped) in the near future. >>> >>> We also recommend to have maintainers support slots for their >>> libs where possible considering man-power and to only choose >>> one toolkit for applications considering where upstream >>> development is going and maturity of the port, and again, this >>> is up to package maintainers. >> This doesn't make sense to me at all. I can't see why slotted >> libraries can't just use USE flags to specify what toolkit >> they're built against, just like any other package in the tree >> (so, for example, a package that needs webkit-gtk built against >> gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). >> I'm well aware that there could be limitations I'm unaware of >> (maybe the package only can build one at a time?), but this is >> how it looks to me. By switching to versioned gtk flags, this >> kills two birds with one stone: it makes it obvious to the end >> user which version they're trying to build their package >> against, and it gets rid of the need for (ab)using revision >> numbers to implement slots like that. > > Except when you end up rebuilding the huge thing twice. Or trying > to live with binpackages -- the thing that most Gentoo developers > don't care about at all. They just love their precious USE flags > so much they'd shove them everywhere for the sake of it. > You'll have to build it twice anyway, this just splits it into two separate packages, and I suspect that the times where you will have to rebuild are when a package needs webkit-gtk to support another toolkit (which should happen only once), and when you upgrade (in which case you would be updating them separately anyway). I also fail to see what this has to do with binpkgs: if something needs webkit-gtk[gtk2], you add a dep on webkit-gtk[gtk2]. The user adds USE=gtk2 to webkit-gtk if needed, webkit-gtk binpkg gets rebuilt. I see no breakage there. Chris Reffett
[gentoo-dev] February 2014 QA policy updates
Hello all, The following are the policy changes from this month's QA team meeting: -USE=multislot (and other USE-dependent SLOT values) need to be removed from the tree. Toolchain can keep it in an overlay if they want. We would consider it acceptable to remove USE=multislot from the tree but keep the eclasses as-is, so that toolchain doesn't need to maintain multiple eclasses. This does not affect sys-boot/grub's USE=multislot, as that does not mangle the SLOT value like the others (as I understand it). -Regarding the gtk/gtk2/gtk3 USE flag situation: we mandate that gtk move to versioned USE flags. For simplicity of migration, we will allow USE=gtk to mean "depend on gtk2," since there are only a few USE=gtk2 remaining in tree. USE=gtk3 will mean "depend on gtk3," and in the future, USE=gtk4 will mean "depend on gtk4," and so on. USE=gtk may not be used to mean "depend on some version of gtk." -More generally: we recommend that in future situations like this (a package can optionally depend on different versions of a library), we recommend the use of versioned USE flags. It should be discussed with the QA team either way. Also, on a non-policy note, we recommend that the Council deprecate EAPIs 0 and 3 (0 pending discussion with toolchain) and ban EAPI 1. As always, if you have questions, feel free to ping us in #gentoo-qa. The meeting summary and these policies will be available on the Quality Assurance page on the Gentoo Wiki tonight or tomorrow. Chris Reffett Gentoo QA Lead
Re: [gentoo-dev] can we get a clang herd/project?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 03:19 PM, Michał Górny wrote: > Dnia 2014-03-03, o godz. 20:01:25 hasufell > napisał(a): > >> I'm tired of looking all the maintainers up manually and adding >> each one to CC list of bug reports. >> >> Why is there no herd or project? > > Not sure what gentoo-dev ml has to do with it... > > ...but I've filed bug 503354 [1] to create the alias. > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=503354 > "Any dev may create a new project just by creating a new project page on the wiki.gentoo.org (see Gentoo_Wiki:Developer_Central/Project_pages) and sending a Request For Comments (RFC) e-mail to gentoo-dev. Note that this GLEP does not provide for a way for the community at large to block a new project, even if the comments are wholly negative." (GLEP39) If he wants there to be a herd/project, this is entirely the right place to say so :) Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlMU5thfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1S9DACeNLZGwG6XqsHwl3caNwOIEsKq 7g0AoJ7IQq2dcIM0qqVGur0sDLBh9sTT =sKf+ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2014-04-27 23h59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/28/2014 9:41 AM, Sergey Popov wrote: > 28.04.2014 17:30, Ciaran McCreesh пишет: >> On Mon, 28 Apr 2014 17:08:28 +1000 Michael Palimaka >> wrote: >>> On 04/28/2014 04:56 PM, hasufell wrote: >>>> What is going on here? Doesn't look right. The commit >>>> messages don't give an understandable reason. >>>> >>> >>> It was added to the tree by someone outside the Qt team >>> without permission. Since it's not ready for the tree yet, it >>> was immediately removed again. >> >> So the Qt team is overriding the QA team now? Is it >> alphabetical? >> > > As a Qt team lead i want to say that there is no permission for me > or pesa(as the main maintainer of Qt Framework packages) for > importing Qt 5 in tree. So, i kindly asks zlogene to remove that > stuff from main tree. > > As QA team member - there was no serious QA issue here - ebuilds, > even semi-broken, was bringed with apropriate masks, so - no damage > on users's systems. > Saying that a Qt team member did something wrong because he reverted an action taken by someone who happens to be a member of the QA team is like saying that I can't revert something done by a council member to one of my packages just because they happen to be on the council. As Pinkbyte said, there was no QA issue here, just a developer being quick on the trigger, so the membership of any parties in QA is irrelevant to the discussion. Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNeW8IACgkQ23laikJhg1RQ6wCbBVdKKUe0J9n74CPBOmOdWmvz JqEAmgM5PuT29aF5Djyp6X1thdo2z/WX =E9g0 -END PGP SIGNATURE-
Re: [gentoo-dev] Making a common sub-profile for no-multilib
On June 25, 2014 2:44:57 PM EDT, "Michał Górny" wrote: >Dnia 2014-06-25, o godz. 13:01:48 >Ian Stakenvicius napisał(a): > >> At the moment there are two profiles in particular that do this, >> amd64/no-multilib and hardened/linux/uclibc/amd64 .. It's possible >or >> likely there are others, too, on other arches perhaps. >> >> In general, it's good that repoman notices this because those >profiles >> don't support having the 32bit deps installed. However, if one of >> those profiles ever moves from a dev profile to a stable one (and >> blueness mentioned he would like to make uclibc/amd64 stable), then >> those dependency.badindev warnings will suddenly turn into >> dependency.bad errors. >> >> The solution to this would seem to be to package.mask all of these >> 32-bit packages in the pure 64bit profiles. However, having to do >> this in multiple locations is annoying. >> >> I would like to propose adding 'no-multilib/[arch]/package.mask' >> sub-profile(s), to allow all of these masks to go in one place. >> >> Populating package.mask should be fairly easy for amd64 at least, >> since anything depending on an app-emulation/emul-* will need to be >> masked. However the merits of where the package.mask will go needs >> discussion. Perhaps, for instance, it's time to adjust the profile >> tree hierarchy more aggressively instead of "piling on" with yet >> another subdir. > >Forgive me for using such a words, but the profile tree is a well >stacked pile of crap. We have a dozen random profiles for each arch >then a dozen other profiles forked off them 'because the generic >arch profiles have crap' and a lot of profiles that inherit others >in a complex and semi-random manner. > >For example, abi_x86_64 and abi_x86_32 each need to be forced in 4 >profiles. This proves that we have 4 distinct profiles for amd64 which >need to be kept in sync. If I change something, I need to perform >the change in 4 different profiles and make sure I didn't screw >something up. > >Then there's the x32 profile that inherits amd64 profile and therefore >requires reverting some of the stuff done on amd64. To do a complete >common change to x86-family multilib (like adding IUSE_IMPLICIT) I have >to modify 9 profiles. > >Now let's add to this circa 8 mips profiles, around 3 ppc profiles, 4 >arm profiles and some more. Every arch organized in somewhat different >and totally non-documented manner. > >Long story short, doing anything to Gentoo profiles is utter pain >and comes with random breakage guarantee. Therefore, I'm asking -- nuke >those damn profiles, and start over! The current situation is >completely unmaintainable. +1, I'm all for replacing it with something more usable. I personally would favor the mix-in approach, but just about anything would be better than the weird setup we have right now. Chris
[gentoo-dev] Help with EAPI bumps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, It's been a QA team objective for some time to help get rid of older EAPI ebuilds in-tree. I personally will be spending some time in the next couple weeks working on this, but I we on the QA team would appreciate it if the developer community in general could contribute, especially with packages that are either maintainer-needed or in herds which have low activity. To play things safe, please revbump and file stable requests when doing the EAPI change (rather than directly bumping EAPI). Thanks in advance for the help! Chris Reffett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPhekUACgkQ23laikJhg1Q12ACfZgY5sei2KvpBbimA5QTaT85K etIAnA1AbRs2AsrqFKiaVWgvtxAERaxe =chii -END PGP SIGNATURE-
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor wrote: [snip] >Just the main blockers are: > >- Somebody has to implement this technology >- That requires time and effort >- People have to be convinced of its value >- Integration must happen at some level somehow somewhere in the >portage toolchain(s) >- People must opt in to this technology in order for the reports to >happen >- And only then can this start to deliver meaningful results. > > > >IMHO seriously, it could be done if ONLY portage dev team would >implement >an interface CAPABLE for HTTP reporting. Once the interface is there >but turned off >by default - server side statistics are feasible. Personally I don't >see any future of >this system unless it's coded in portage. Today - portage support >without server side >- tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor wrote: [snip] >Just the main blockers are: > >- Somebody has to implement this technology >- That requires time and effort >- People have to be convinced of its value >- Integration must happen at some level somehow somewhere in the >portage toolchain(s) >- People must opt in to this technology in order for the reports to >happen >- And only then can this start to deliver meaningful results. > > > >IMHO seriously, it could be done if ONLY portage dev team would >implement >an interface CAPABLE for HTTP reporting. Once the interface is there >but turned off >by default - server side statistics are feasible. Personally I don't >see any future of >this system unless it's coded in portage. Today - portage support >without server side >- tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 10:56:49 AM EDT, Igor wrote: [snip] >Just the main blockers are: > >- Somebody has to implement this technology >- That requires time and effort >- People have to be convinced of its value >- Integration must happen at some level somehow somewhere in the >portage toolchain(s) >- People must opt in to this technology in order for the reports to >happen >- And only then can this start to deliver meaningful results. > > > >IMHO seriously, it could be done if ONLY portage dev team would >implement >an interface CAPABLE for HTTP reporting. Once the interface is there >but turned off >by default - server side statistics are feasible. Personally I don't >see any future of >this system unless it's coded in portage. Today - portage support >without server side >- tomorrow - server side. Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere. Chris Reffett
Re: [gentoo-dev] minimalistic emerge
On August 9, 2014 11:46:54 AM EDT, Chris Reffett wrote: >On August 9, 2014 10:56:49 AM EDT, Igor wrote: >[snip] >>Just the main blockers are: >> >>- Somebody has to implement this technology >>- That requires time and effort >>- People have to be convinced of its value >>- Integration must happen at some level somehow somewhere in the >>portage toolchain(s) >>- People must opt in to this technology in order for the reports to >>happen >>- And only then can this start to deliver meaningful results. >> >> >> >>IMHO seriously, it could be done if ONLY portage dev team would >>implement >>an interface CAPABLE for HTTP reporting. Once the interface is there >>but turned off >>by default - server side statistics are feasible. Personally I don't >>see any future of >>this system unless it's coded in portage. Today - portage support >>without server side >>- tomorrow - server side. > >Then write it. Portage's source is available to anyone. I remember that >you were on this list earlier this year pushing for "Portage QOS" or >something. Keep in mind what a significant number of people told you >then: first, if you want to make some change, just do it and show us >what you have, rather than asking for votes and permission and changes. >Second, repeatedly saying "we should have (some feature)" doesn't work >if the people who would do the work (the portage team) don't see value >in it. From the general response on the list, I would say this is the >case. This means that if you want the feature, write it and come back >with an implementation, since complaining about it is getting you >nowhere. > >Chris Reffett Apologies for multiple emails getting sent, on a mobile connection here and it reported a failure to send. My bad. Chris Reffett -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/12/2014 9:26 AM, Rich Freeman wrote: [snip] > I don't have a problem with QA recommending new tree policies, but > if they're going to do this the QA team ought to first ensure that > the team agrees (however they want to govern that), and then > communicate the policy before implementing it. I'd also implement > it in documentation before doing so in repoman, otherwise we're > going to have a repoman full of 800 rules whose origin is a > mystery. I'm fine with QA policies going into effect by default, > but communicating them allows objections to be raised and an > appeal made to Council if necessary before we get too far along. > This isn't just about due process - it is hard for developers to > even comply with a policy they are unaware of. > > Rich > This isn't a QA policy, was not run by us as far as I can tell, and I don't know where it came from or why it was added. +1 for revert, if people want to run this by Council or QA later and actually get an official decision we can talk about putting it back, but for now it's generating a lot of noise for no real benefit. It's useless checks like this that make people ignore repoman warnings. Chris Reffett QA Team Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlPqXvAACgkQ23laikJhg1QvTQCffjAZYIzBGBRlp1l/y6iydzTQ 3d0An12lbTbzr7nWe37qtoay7ktWUAs6 =6c3E -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On 8/18/2014 8:56 AM, hasufell wrote: > hasufell: >> >> Even more interesting... you can work around this by inheriting >> base.eclass explicitly before e.g. unpacker.eclass, something like >> >> inherit base unpacker games >> >> => unpacker_src_unpack() is carried out by default (and the ebuild >> breaks if someone thinks the base.eclass is useless and removes it) >> >> inherit unpacker games >> >> => unpacker_src_unpack is not carried out by default although >> games.eclass does not directly overwrite it >> >> If you think any of this is sensible... >> > > Almost forgot, of course this does not work if you expect > unpacker_src_unpacker() to run: > inherit unpacker games base > > as well as > inherit unpacker base games > > however > inherit games unpacker base > > will work. > > And now... guess why the games herd made it a policy to always inherit > games.eclass last. Because of the unpredictability of eclasses and that > they may randomly add exported phase functions. It's a bit paranoid, but > understandable, since we don't have any real rules here. > > So in the end 3 eclasses all tell you "inherit me last! really!". Good > luck with figuring out how to make a gnome game with python and multilib > support work together. I can predict the days such a review would take > in #gentoo-sunrise. Not less than 3. > Would it be feasible to add a repoman check for situations like this, where the behavior of a phase is dependent on inherit order? If so, it seems reasonable to me to require explicit calls to eclass functions in these cases to make it clear what's being called when. Chris Reffett
Re: [gentoo-dev] rfc: calling all eclass phase functions by default
On August 18, 2014 11:11:56 AM EDT, "Michał Górny" wrote: >Dnia 2014-08-18, o godz. 09:22:46 >Chris Reffett napisał(a): > >> On 8/18/2014 8:56 AM, hasufell wrote: >> > Almost forgot, of course this does not work if you expect >> > unpacker_src_unpacker() to run: >> > inherit unpacker games base >> > >> > as well as >> > inherit unpacker base games >> > >> > however >> > inherit games unpacker base >> > >> > will work. >> > >> > And now... guess why the games herd made it a policy to always >inherit >> > games.eclass last. Because of the unpredictability of eclasses and >that >> > they may randomly add exported phase functions. It's a bit >paranoid, but >> > understandable, since we don't have any real rules here. >> > >> > So in the end 3 eclasses all tell you "inherit me last! really!". >Good >> > luck with figuring out how to make a gnome game with python and >multilib >> > support work together. I can predict the days such a review would >take >> > in #gentoo-sunrise. Not less than 3. >> > >> Would it be feasible to add a repoman check for situations like this, >> where the behavior of a phase is dependent on inherit order? If so, >it >> seems reasonable to me to require explicit calls to eclass functions >in >> these cases to make it clear what's being called when. > >Right now, we have no kind of repoman for eclasses. If you have time to >work on such a thing, please do. Otherwise, all we can do is put more >checks in ebuilds but that triggers the warning for the wrong people... I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like "src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function." I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here. Chris Reffett
Re: [gentoo-dev] RFC: ban EAPI 1
On 6/10/2015 4:43 PM, Ulrich Mueller wrote: > Hi, > The number of EAPI 1 ebuilds in the Portage tree has decreased to > a total of 60, corresponding to 0.16 %. > > We briefly discussed in the QA team if we should demote EAPI 1 in > layout.conf from "eapis-deprecated" to "eapis-banned". This would > have the consequence that repoman would refuse to commit packages > containing such ebuilds. AFAICS there would be no impact on users. > > What do you think? > > Ulrich > Make it so.
[gentoo-dev] New project: Theology
A bit late, but official announcement of the herd->project conversion of theology to follow GLEP 67. https://wiki.gentoo.org/wiki/Project:Theology creffett signature.asc Description: OpenPGP digital signature
