[gentoo-dev] Re: Please stop useless removals

On 2/02/2013 00:36, Wulf C. Krueger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01.02.2013 14:26, Rich Freeman wrote: As long as it builds on 80%+ of systems and has no serious issues (security in particular) there is no reason to remove a package. And how will you get to know abo

[gentoo-dev] Re: On the good usage of subslots

Hi, On 9/02/2013 23:15, Alexis Ballier wrote: Dear fellow developers, I hope this will be trivial to most of you but after seeing bug #455900 and the vast majority of developers not even thinking twice before sedding their dep strings, I believe this needs some attention. What is wrong with m

[gentoo-dev] Re: On the good usage of subslots

On 10/02/2013 00:47, Samuli Suominen wrote: On 09/02/13 14:15, Alexis Ballier wrote: Dear fellow developers, I didn't find anything to reply directly here, so sorry for stealing this message. I just wanted to point out that people have lately been adding deps like: media-libs/libpng:= dev-li

[gentoo-dev] Re: On the good usage of subslots

On 9/02/2013 23:52, Alexis Ballier wrote: On Sat, 09 Feb 2013 23:38:35 +1100 Michael Palimaka wrote: I even noticed some maintainers adding subslots dependencies on libraries that do not yet define subslots. This too seems reasonable, given that there would be no impact until the library

[gentoo-dev] Re: On the good usage of subslots

On 10/02/2013 03:06, Zac Medico wrote: On 02/09/2013 06:05 AM, Michael Palimaka wrote: Is there a difference in behaviour between 'media-libs/libpng:=' and 'media-libs/libpng' with no slot information at all? I don't know if you phrased your question as intended. An

[gentoo-dev] Re: Gentoo Bugday

On 27/02/2013 11:39, Pavlos Ratis wrote: Hello everyone, I would like to announce you a new try to 'revive' the Bugday event. As most of the open source projects have their own bugday, I thought it would be great to have this event back. For those who don't know, its a monthly 24h event that ta

[gentoo-dev] Re: [RFC] New category for LeechCraft

Hi, On 6/03/2013 18:07, Maxim Koltsov wrote: Hi, Currently there are 61 leechcraft packages in tree scattered across several categories. We propose to move them to one new category to make maintaining easy as well as rsync --exclude'ing. So, two questions: 1) Do you agree with adding new categor

[gentoo-dev] Re: Expanding categories' descriptions

On 1/04/2013 04:29, Denis M. wrote: Hello, (I was redirected from gentoo-doc@ to ask this here.) I think it's a good idea to expand the categories' descriptions (found in the corresponding metadata.xml files) with more accurate descriptions of which packages are welcome to fit in which categori

[gentoo-dev] Re: sys-apps/texinfo vs @system

On 31/03/2013 16:59, Mike Frysinger wrote: one option would be to make the makeinfo stuff into a USE flag so all the perl junk isn't pulled in by default. only the packages that actually generate info pages can DEPEND on that. it'd be simpler if we just dropped it altogether from @system. if

[gentoo-dev] Last rites: kde-base/printer-applet kde-base/system-config-printer-kde

# Michael Palimaka (01 Apr 2013) # Obsoleted by kde-base/print-manager. Removal in 30 days. kde-base/printer-applet kde-base/system-config-printer-kde

[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean

On 7/04/2013 04:22, Markos Chandras wrote: On 6 April 2013 19:08, Michał Górny wrote: Hello, ... What are your thoughts? Maybe it is time to setup a patch tracking system like Debian[1]? Sometimes it is really hard to understand what patches are applied by an ebuild (especially when all the

[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean

On 7/04/2013 16:53, Kacper Kowalik wrote: On 06.04.2013 20:08, Michał Górny wrote: Hello, As far as I'm aware, we don't really have much of a patch maintenance policy in Gentoo. There a few loose rules like «don't put awfully big files into FILESDIR» or the common sense «use unified diff», but

[gentoo-dev] Re: [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean

On 7/04/2013 07:01, Robin H. Johnson wrote: On Sat, Apr 06, 2013 at 08:08:43PM +0200, Michał Górny wrote: The above-listed policy will apply to the patches kept in the gx86 tree (in FILESDIRs) and patch archives created by Gentoo developers. They will not apply to the patch archives created upst

[gentoo-dev] Re: Opportunities to use slot operators

On 14/04/2013 23:09, Rich Freeman wrote: For whoever is interested I tossed together a script to identify packages that would immediately benefit from slot operator dependencies but which are not doing so. The list can be found at: http://dev.gentoo.org/~rich0/missedslotops.txt This was generat

[gentoo-dev] Re: devmanual moved to github

On 13/05/2013 02:08, Rich Freeman wrote: Second, I think this really points to there being value for something like Gerrit available on Gentoo, which might be the best of both worlds. I've never used it myself but I'm tempted to install it just to start messing with it personally. I'd be intere

[gentoo-dev] Re: devmanual moved to github

On 13/05/2013 03:20, Peter Stuge wrote: I agree that Java is sucky, but I don't think that rejecting Gerrit for that reason alone makes sense. Look at what the application does and how it works, to determine if it fits the project or not. I agree, but if infra is not willing to maintain something

[gentoo-dev] Re: devmanual moved to github

On 13/05/2013 04:24, Peter Stuge wrote: Michael Palimaka wrote: I agree that Java is sucky, but I don't think that rejecting Gerrit for that reason alone makes sense. Look at what the application does and how it works, to determine if it fits the project or not. I agree, but if infra i

[gentoo-dev] Re: robo-stable bugs

On 19/05/2013 23:40, Jeroen Roovers wrote: OS: Linux Status: CONFIRMED Severity: enhancement Is a stabilisation an enhancement per se? Usually I think so yes. If it is an urgent stabilisation there is priority field. If all stabilisations are enhance

[gentoo-dev] Re: robo-stable bugs

On 22/05/2013 18:58, Tom Wijsman wrote: On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill wrote: Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. Why are they enhancements? Them having been this way is not a reason not to change the pr

[gentoo-dev] Re: robo-stable bugs

On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming th

[gentoo-dev] Re: robo-stable bugs

On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days

[gentoo-dev] Re: robo-stable bugs

On 22/05/2013 20:41, Thomas Sachau wrote: Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb

[gentoo-dev] Re: robo-stable bugs

On 22/05/2013 21:00, Tom Wijsman wrote: On Wed, 22 May 2013 11:07:26 +0200 Ulrich Mueller wrote: Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Why are th

[gentoo-dev] New global USE flag: qt5

Hi all, Qt 5 has been available for some time, and we are making preparations to move it to the tree. As we will be supporting user choice where packages can be build against both Qt 4 and Qt 5, we will require a new global USE flag: qt5 - Adds support for the Qt 5 application and UI framewo

[gentoo-dev] Re: New global USE flag: qt5

On 28/05/2013 01:34, Nikos Chantziaras wrote: On 27/05/13 18:06, Michael Palimaka wrote: Hi all, Qt 5 has been available for some time, and we are making preparations to move it to the tree. As we will be supporting user choice where packages can be build against both Qt 4 and Qt 5, we will

[gentoo-dev] Review Board for Gentoo

Hi, I have set up a Review Board instance[1] for testing / evaluation / whatever-you-want purposes. If you are not familiar with what happens in a review, there are a number of established Review Boards to look at.[2] This instance is currently configured for gentoo-x86, as well as a coupl

[gentoo-dev] Re: Review Board for Gentoo

On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind?

[gentoo-dev] Re: Review Board for Gentoo

On 29/05/2013 21:18, Alexey Shvetsov wrote: Yep I'm thinking about gerrit like workflow. But seems it doesnt make sense with RB and CVS. Yes, Review Board and Gerrit target different things.

[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE

On 28/05/2013 01:35, Jonathan Callen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A quick reminder for anyone using python-r1.eclass or python-single-r1.eclass: These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should be included in REQUIRED_USE under the same USE conditio

[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE

On 30/05/2013 01:06, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 04:51 PM, Michael Palimaka wrote: Would it be possible to add repoman checks for this, and other common failures like missing PYTHON_USEDEP? The latter is impossible. Repoman has no way to

[gentoo-dev] Re: cmake-utils.eclass dropping EAPI 0/1 support

On 14/06/2013 09:05, Alexis Ballier wrote: On Thu, 13 Jun 2013 18:48:21 -0400 Chris Reffett wrote: -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 an

[gentoo-dev] Re: [RFC] SRC_URI behaviour

On 15/06/2013 23:47, Ulrich Mueller wrote: On Sat, 15 Jun 2013, Diego Elio Pettenò wrote: "restrict+http:" (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. nofetch+http and nomirror+http ? Or the other way around: {fetch,

[gentoo-dev] Re: Packages up for grabs

On 16/06/2013 23:02, g...@malth.us wrote: There'd be no problem resurrecting it from the grave, if need be, would there? Please note that being unmaintained does not mean the package will be removed. That would only happen if there are long term unresolved issues with the package. Best rega

[gentoo-dev] Re: [RFC] SRC_URI behaviour

On 16/06/2013 10:24, Zac Medico wrote: How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package mana

[gentoo-dev] Re: Soliciting input for a non-maintainer update (NMU) GLEP

On 22/06/2013 11:42, Robin H. Johnson wrote: This needs to be in the above data: So we have: Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER} What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES} So most of my packages might be coded with: - If you're a

[gentoo-dev] Re: Gentoo Hangouts

On 24/06/2013 07:30, Pavlos Ratis wrote: That's why I'd like to propose Gentoo Hangouts. Gentoo Hangouts will be Google+ video Hangouts(video calls) held by teams or developers independent of a team. The main goal is to have the teams introduce themselves and discuss about different issues in th

[gentoo-dev] Re: Gentoo Hangouts

On 25/06/2013 22:42, Egg Plant wrote: I don't know whether a new gentoo user like me have any say here, I would like to point out some problems about this proposal ! 1. Video requires high bandwidth internet, so useless in developing countries, where even today you can not think of 24x7 intern

[gentoo-dev] Re: Gentoo Hangouts

On 26/06/2013 01:09, Egg Plant wrote: According to Pavlos Ratis proposal, it will be another channel of communication. I am not protesting to setup an unofficial channel there. I am fearing that it will gradually become an avenue for talent show, similar to other binary distros. That is why I

[gentoo-dev] Re: new category: games-adventure/

On 15/07/2013 03:17, Rich Freeman wrote: I agree that precedence alone isn't really a good basis for this. I don't really have concerns with the initial category size so much as the general lack of a definition for this category. I agree. The boundaries between games-rpg and games-adventure, a

[gentoo-dev] Re: new category: games-adventure/

On 15/07/2013 03:38, Damien Levac wrote: What immediately comes to mind as a "decent" way to split games is the wikipedia page for video game genres: http://en.wikipedia.org/wiki/Video_game_genres That would make 7 categories and the game description could include the subcategory if necessary.

[gentoo-dev] Re: revbumping ebuilds after USE dependency changes

On 25/07/2013 05:17, Michał Górny wrote: Actually per PMS you are required to revbump (and therefore require upgrade on users' side) whenever you change the deps and don't expect to add a new version soon enough. Can you please provide a link/reference to that part? I am interested in reading

[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies

On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot operator being specified at all? I don't see those packages defining any subslots.

[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies

On 5/08/2013 21:58, Samuli Suominen wrote: On 05/08/13 13:56, Michael Palimaka wrote: On 5/08/2013 19:33, Samuli Suominen wrote: This is a friendly reminder. I've found the tree again to have dependencies like: dev-libs/openssl:= virtual/jpeg:= Is there any reason for the subslot ope

[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies

On 6/08/2013 01:06, Samuli Suominen wrote: The plan is to change SLOT of virtual/jpeg from "0" to eg. "0/1" after next SONAME change in the default of the virtual, so it's useful to have everything depend on virtual/jpeg:0= ready, to get the benefits of the subslot. Does that mean that anyone t

[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies

On 6/08/2013 01:07, Rich Freeman wrote: I suspect most maintainers would rather upgrade their package once to EAPI5 and not keep checking back every month to see if there is a new opportunity to add another slot operator dep. If maintainers don't add them up-front even with the deps don't suppor

[gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies

On 6/08/2013 02:13, Ciaran McCreesh wrote: On Tue, 06 Aug 2013 02:03:28 +1000 Michael Palimaka wrote: How often does this situation even come up? If 9/10 times the libraries are set up as maintainers expect them to be, it is probably better to deal with the odd unnecessary rebuild until

[gentoo-dev] Re: Response to a "friendly note" about changing bug reports

On 7/08/2013 20:34, Kacper Kowalik wrote: * every atom needs a "=" in front, and * "Please stabilize XXX" should always be replaced by "XXX stabilization". Those two are actually useful. There are many scripts used by ATs that parse title field. One could argue: "Fix your damn scripts" but in t

[gentoo-dev] Re: Response to a "friendly note" about changing bug reports

On 7/08/2013 07:46, Jeroen Roovers wrote: Besides the finer technical points of bug maintenance, it simply infuriates me that anyone would think of bug reports in the possessive. This is not the way to improve the distro. You're on the wrong track there. And you weren't being friendly. In this ca

[gentoo-dev] Re: Response to a "friendly note" about changing bug reports

On 7/08/2013 22:18, Tom Wijsman wrote: We usually take it a step further, putting the actual error there; if the maintainer reads the error, it will be clear it failed to build: "=kde-base/kmail-4.8.10 with GCC 4.8 - File:Line:Char: Error: Reason" Is there any benefit to adding = in this case?

[gentoo-dev] Re: Response to a "friendly note" about changing bug reports

On 7/08/2013 22:41, hasufell wrote: You are a bug wrangler and should have the authority to mess with anything in bugzilla. Don't forget that anybody can start a project, even if it conflicts with other projects. While Jeroen's experience certainly gives him a more insight regarding bugzilla

[gentoo-dev] Re: Response to a "friendly note" about changing bug reports

On 8/08/2013 07:52, Gilles Dartiguelongue wrote: Guys, please, if you want to bikeshed about bug summary, please do it in a constructive way and get the automated bug assignment project going. I think at least one bug wrangler already uses a local script to do something similar to that. Any id

[gentoo-dev] Sets in the tree

Now that portage-2.2 is in ~arch, we should now be able to add sets to the tree. How should we go about doing this? In some overlays, the repository root has sets/{foo,bar,etc} and sets.conf which might look like this: [gentoo sets] class = portage.sets.files.StaticFileSet multiset = true dir

[gentoo-dev] Re: Sets in the tree

On 14/08/2013 23:02, Michał Górny wrote: No, we can't. Sets are portage-specific, the tree needs to follow PMS. Are you saying we can't use sets at all in the tree, or we can't use them to replace existing meta packages?

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 05:31, Tom Wijsman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius wrote: I see a few issues with ~arch -> table migrations: #1 - things just sit in ~arch. The auto-stablereq script should help with this one I think; w

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 05:24, Tom Wijsman wrote: On Tue, 20 Aug 2013 13:19:10 -0500 William Hubbs wrote: All, I'm not really sure what the answer to this problem is, so I want to know what the group thinks about how we can handle it. During the last release of OpenRC, I learned that people *do* run p

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 17:54, Sergey Popov wrote: Why we should bring new half-stable, half-testing keyword for this? I think that this is no way to go. We should improve current situation with arches by some other ways(e.g., recruiting people). Maybe drop some damn-bad understaffed arches to unstable onl

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 18:10, Tom Wijsman wrote: On Wed, 21 Aug 2013 16:51:37 +1000 Michael Palimaka wrote: On 21/08/2013 05:31, Tom Wijsman wrote: On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius wrote: That script has been running for long enough now. It doesn't work out... What do you

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 18:30, Tom Wijsman wrote: On Wed, 21 Aug 2013 17:04:45 +1000 Michael Palimaka wrote: We would probably benefit from formalising a clearer definition of arch/~arch - it seems to mean a lot of different things to different people. http://devmanual.gentoo.org/keywording lists a

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 07:05, Tom Wijsman wrote: See `imlate --mtime=180 -s | less`. (From app-portage/gentoolkit-dev) I quote: == 4392 Stable candidates for 'gentoo' on 'amd64' == Let's double the number to a yea

[gentoo-dev] Re: rfc: stabilization policies

On 21/08/2013 20:31, Tom Wijsman wrote: On Wed, 21 Aug 2013 20:13:00 +1000 Michael Palimaka wrote: For those not familiar with imlate, please note that these numbers include packages that have never been stabilised. True, this brings up two questions: 1. How do we filter out those that

[gentoo-dev] Re: Moving more arches to dev profiles

On 21/08/2013 21:04, Markos Chandras wrote: I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc +1

[gentoo-dev] Re: Moving more arches to dev profiles

On 22/08/2013 01:56, Michael Weber wrote: On 08/21/2013 01:04 PM, Markos Chandras wrote: The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'in

[gentoo-dev] Re: Moving more arches to dev profiles

On 22/08/2013 01:32, Matt Turner wrote: I want some level between "stable and completely supported" and "loses all its stable keywords.", at least for alpha. Is switching their profiles to dev the way to do that? What would you feel about instead of dropping stable completely, re-evaluating whi

[gentoo-dev] Re: About perl-5.18 unmasking

On 9/09/2013 02:40, Markos Chandras wrote: Moreover, I don't think raising this issue to the mailing list is appropriate as a first step. Based on the number of replies to -commits that end up on here, it's no surprise that it can appear appropriate to raise an issue like this here initially.

[gentoo-dev] Re: [Bug 483274] app-text/poppler-0.22.5 Please stabilize

On 16/09/2013 23:01, Markos Chandras wrote: On 16 September 2013 13:41, Andreas K. Huettel wrote: Please stop pointless bugspam. Am Montag, 16. September 2013, 14:20:51 schrieben Sie: DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To com

[gentoo-dev] Re: [Bug 483274] app-text/poppler-0.22.5 Please stabilize

On 16/09/2013 23:33, Alex Legler wrote: On 16.09.2013 15:19, Rich Freeman wrote: Additionally, can anybody who knows more about bugzilla comment on how easy it would be to have some way to mark modifications as trivial, and take this into account in the bugspam? Either make it configurable as t

[gentoo-dev] Re: [Bug 483274] app-text/poppler-0.22.5 Please stabilize

On 17/09/2013 15:58, Duncan wrote: Note that it wasn't JUST punctuation/capitalization that changed in the given example, but the version number, 1.2.3 => 1.7.3, as well. Is that still a trivial change? Altho I'm not sure whether kensington changed the version number in his example deliberately

[gentoo-dev] Re: RFC: FEATURES="binchecks strip" for plain file packages e.g. latex, perl, python

On 21/09/2013 10:49, Duncan wrote: In addition to what the others have said, FEATURES= ?? AFAIK, FEATURES is PM-implementation-specific and not part of PMS. It's not something ebuilds/eclasses should be messing with or care about at all, as it's PM- private-implementation domain, not ebuild dom

[gentoo-dev] Re: RFC: FEATURES="binchecks strip" for plain file packages e.g. latex, perl, python

On 22/09/2013 00:26, Michał Górny wrote: This is just another of portage's deviations from the standard. PMS doesn't list RESTRICT=binchecks, and I suppose this makes using it in the tree at least a little wrong. It does however say: "Package managers may recognise other tokens, but ebuilds may

[gentoo-dev] Re: unstable/testing keywords

On 23/09/2013 22:03, Ciaran McCreesh wrote: On Mon, 23 Sep 2013 13:59:37 +0200 Chí-Thanh Christopher Nguyễn wrote: Jack Morgan schrieb: I find this confusing and hope to clear it up. According to emerge/portage man pages we have stable keywords (ARCH) and unstable packages (~ARCH) while the ha

[gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords

On 23/09/2013 21:34, Samuli Suominen wrote: [ ... ] Stealing random mail from this thread. Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm wri

[gentoo-dev] Re: News item: m68k, s390, and sh are dropping stable keywords

On 23/09/2013 22:52, Ulrich Mueller wrote: On Mon, 23 Sep 2013, Samuli Suominen wrote: Because I've seen some commits today for reverting the mentioned KEYWORDS to ~arch in some ebuilds I'm not sure if everyone is aware that the arch status is set using profiles/profiles.desc and as I'm writin

[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots

On 26/09/2013 17:53, Michał Górny wrote: Dnia 2013-09-26, o godz. 15:15:38 Patrick Lauer napisał(a): Thus I suggest declaring a policy: "" Any library bump that would trigger revdep-rebuild should be done with the affected library package.mask'ed until all its consumers have been properly bum

[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots

On 26/09/2013 20:55, Ciaran McCreesh wrote: On Thu, 26 Sep 2013 20:51:26 +1000 Michael Palimaka wrote: There isn't a 100% perfect solution currently, and I agree that hurrying people will simply move us from "not enough rebuilds" to "too many rebuilds". This is still

[gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots

On 27/09/2013 00:12, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/09/13 06:51 AM, Michael Palimaka wrote: On 26/09/2013 17:53, Michał Górny wrote: How do we handle packages which install multiple libraries? I'm afraid forcing such a policy and/or hur

[gentoo-dev] Re: official games repository

On 21/10/2013 09:43, Tom Wijsman wrote: An alternative would probably be gerrit which vapier seems to be a fan of. But we don't even have an ebuild. Since I have just noticed this is Java, CC-ed us on the bug and this is on my list; but given its size, I can't make any promises as to when we wi

[gentoo-dev] Re: Reminder: open season on robbat2's packages

On 31/10/2013 09:10, Robin H. Johnson wrote: dev-util/checkbashisms As described in bug #426828, this package currently uses an abandoned upstream, with a much more recent version maintained by Debian. I'd like to, at a minimum, update to a newer version. The better long-term solution is to

[gentoo-dev] Re: About preferred ntp provider

On 12/11/2013 08:13, Pacho Ramos wrote: Reading: https://bugs.gentoo.org/show_bug.cgi?id=489044 https://bugs.gentoo.org/show_bug.cgi?id=489040 I don't know what should be preferred, personally I use net-misc/ntp simply because I have always being using it, also looks like we don't have any virtu

[gentoo-dev] Re: RFC: cleaning away old news items

On 25/11/2013 01:35, Petteri Räty wrote: Hi everyone, when doing a fresh installation I noticed that during I get to see many old news items. There used to be a problem with Portage so no news items could be removed. I think that has now been fixed for years so we should be able to do this witho

[gentoo-dev] Re: rfc: revisiting our stabilization policy

On 01/15/2014 03:49 PM, William Hubbs wrote: > On Wed, Jan 15, 2014 at 10:48:53AM +0700, gro...@gentoo.org wrote: >> On Tue, 14 Jan 2014, William Hubbs wrote: >>> 1. I think maintainers should be able to stabilize their packages on arch's >>> they have access to. I think this is allowed by some arc

[gentoo-dev] Re: rfc: revisiting our stabilization policy

On 01/16/2014 05:27 PM, Sergey Popov wrote: > > Thanks, for the proposal. IIRC, there was similar backroom agreement in > some minor arches, look at how armin76 stabilized packages earlier - > sometimes he drops vast amount of keywords on ia64/sparc/m68k to > unstable in stabilization requests. >

[gentoo-dev] Re: New eclass: xdg-basedir

On 01/30/2014 02:37 PM, Mike Gilbert wrote: > Here's a simple eclass that pretty much just extracts the XDG stuff from > the gnome2_environment_reset function. > > One difference: it creates 3 of the 4 directories under ${HOME} instead > of ${T}, just to mimic the default behavior in the XDG based

[gentoo-dev] Re: New eclass: xdg-basedir

On 01/31/2014 04:32 AM, Mike Gilbert wrote: > On Thu, Jan 30, 2014 at 6:48 AM, Michael Palimaka > wrote: >> On 01/30/2014 02:37 PM, Mike Gilbert wrote: >>> Here's a simple eclass that pretty much just extracts the XDG stuff from >>> the gnome2_environment_res

[gentoo-dev] Packages up for grabs

These packages are not used by anyone in the KDE herd, and they are not KDE-related, so they are now up for grabs. There are a few bugs open, but nothing major. net-misc/csync net-misc/mirall

[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/11/2014 11:36 AM, Jason A. Donenfeld wrote: > Hey folks, > > Late night clicking-while-drooling, I came across something a few > minutes ago that mildly piqued my interest -- mbox > . It's a sandbox that uses a > combination of ptrace and seccomp bpf; neither

[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/11/2014 11:34 PM, Rich Freeman wrote: > On Tue, Feb 11, 2014 at 1:56 AM, Michael Palimaka > wrote: >> >> Looks interesting. It reminds me somewhat of autodep[1]. >> > > Interesting - does this work? I don't see it in portage. It used to work pretty we

[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/12/2014 01:03 AM, Rich Freeman wrote: > On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka > wrote: >> On 02/11/2014 11:34 PM, Rich Freeman wrote: >> >>> One of those ideas I've always wanted to implement is to create a >>> portage hook/patch that

[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/12/2014 04:56 PM, Brian Dolbec wrote: > On Wed, 12 Feb 2014 01:36:01 +1100 > Michael Palimaka wrote: > >> On 02/12/2014 01:03 AM, Rich Freeman wrote: >>> On Tue, Feb 11, 2014 at 7:39 AM, Michael Palimaka >>> wrote: >>>> On 02/11/2014 11:34 PM

[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/13/2014 06:36 PM, Александр Берсенев wrote: > Hi, It was my project. The portage changed a lot since that time, I can > try to renew it, if it's still used. I used to use it a lot until it stopped working because of not understanding EAPI 5. I think others would find it useful, but I don't t

[gentoo-dev] Re: [PATCH] mysql-cmake.eclass respect flags wrt #497532

On 02/15/2014 01:36 AM, hasufell wrote: > https://bugs.gentoo.org/show_bug.cgi?id=497532 > Is there a good reason to set CMAKE_BUILD_TYPE="RelWithDebInfo" at all? Changing the build type is not generally recommended, and may cause other flags to be set automatically. If you are using the default

[gentoo-dev] Re: repoman feature request / profiles.desc profile types

On 02/17/2014 03:58 AM, Andreas K. Huettel wrote: > Why not make it possible to keep an ~arch only deptree consistent?! amd64-fbsd already does this with a stable profile. They just choose to not actually have any stable keywords. In my opinion, the profile type is better as a description of that

[gentoo-dev] Re: repoman feature request / profiles.desc profile types

On 02/17/2014 05:36 AM, Andreas K. Huettel wrote: > Am Sonntag, 16. Februar 2014, 18:18:56 schrieb Michael Palimaka: >> On 02/17/2014 03:58 AM, Andreas K. Huettel wrote: >>> Why not make it possible to keep an ~arch only deptree consistent?! >> >> amd64-fbsd already d

[gentoo-dev] Re: New categories: mate-base and mate-extra

On 02/23/2014 05:02 AM, Tom Wijsman wrote: > On Sat, 22 Feb 2014 17:33:57 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> Tom Wijsman posted on Sat, 22 Feb 2014 18:08:24 +0100 as excerpted: >> That seems a little on the small side? Can we just do a single category for all of it,

[gentoo-dev] Re: mbox -- looks sort of interesting

On 02/22/2014 08:50 PM, Александр Берсенев wrote: > Hello, > > I've updated the autodep and testing it now. Thanks for taking the time to do this!

[gentoo-dev] Last rites: media-gfx/kgraphviewer

# Michael Palimaka (26 Feb 2014) # Doesn't build with recent graphviz. Dead upstream. # Masked for removal in 30 days. Bug #491760. media-gfx/kgraphviewer

[gentoo-dev] Re: Possibility of overriding user defined INSTALL_MASK from an ebuild?

On 03/01/2014 12:28 AM, Samuli Suominen wrote: > It would be very helpful if INSTALL_MASK could be overriden from an > ebuild, if user hasn't > set otherwise. > So it could be configured like USE_ORDER which is > "env:pkg:conf:defaults:pkginternal:repo:env.d" > So INSTALL_MASK_ORDER like "ebuild:${

[gentoo-dev] Re: Adding slot and subslot deps to others' packages

On 03/02/2014 07:37 PM, Michał Górny wrote: > Hi, > > Few months ago I have written a small FAQ on how to use slots > and subslots for library dependencies properly [1]. However, today > I see that most of the developers didn't care to properly update their > packages and when I introduced binary

[gentoo-dev] Last rites: kde-misc/youtube-servicemenu

# Michael Palimaka (14 Mar 2014) # Not compatible with latest KDE. Backend script can't # fetch videos anymore. Dead upstream. # Masked for removal in 30 days. Bug #504550. kde-misc/youtube-servicemenu

[gentoo-dev] New category: kde-frameworks

Hi, With the tentative release date of KDE Frameworks looming, we would like to propose the new category 'kde-frameworks'. The category would initially contain approximately 60 new packages, with the potential for more in the future. KDE Frameworks is being released independently of other compon

[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2014-04-27 23h59 UTC

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.

<    1   2   3   4   5   >