[gentoo-dev] [warning] the bug queue has 81 bugs
Our bug queue has 81 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 89 bugs
Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 97 bugs
Our bug queue has 97 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 85 bugs
Our bug queue has 85 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 89 bugs
Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 87 bugs
Our bug queue has 87 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 86 bugs
Our bug queue has 86 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 85 bugs
Our bug queue has 85 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 94 bugs
Our bug queue has 94 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 98 bugs
Our bug queue has 98 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 86 bugs
Our bug queue has 86 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 85 bugs
Our bug queue has 85 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 84 bugs
Our bug queue has 84 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 88 bugs
Our bug queue has 88 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 95 bugs
Our bug queue has 95 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 99 bugs
Our bug queue has 99 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 92 bugs
Our bug queue has 92 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 84 bugs
Our bug queue has 84 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 90 bugs
Our bug queue has 90 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 88 bugs
Our bug queue has 88 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 84 bugs
Our bug queue has 84 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 95 bugs
Our bug queue has 95 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 97 bugs
Our bug queue has 97 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 94 bugs
Our bug queue has 94 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 89 bugs
Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 85 bugs
Our bug queue has 85 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 88 bugs
Our bug queue has 88 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 96 bugs
Our bug queue has 96 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 93 bugs
Our bug queue has 93 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 85 bugs
Our bug queue has 85 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 86 bugs
Our bug queue has 86 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 86 bugs
Our bug queue has 86 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 95 bugs
Our bug queue has 95 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 93 bugs
Our bug queue has 93 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 84 bugs
Our bug queue has 84 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 90 bugs
Our bug queue has 90 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 96 bugs
Our bug queue has 96 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 81 bugs
Our bug queue has 81 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 96 bugs
Our bug queue has 96 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 87 bugs
Our bug queue has 87 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 94 bugs
Our bug queue has 94 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 86 bugs
Our bug queue has 86 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 98 bugs
Our bug queue has 98 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 98 bugs
Our bug queue has 98 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 91 bugs
Our bug queue has 91 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 89 bugs
Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 95 bugs
Our bug queue has 95 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 105 bugs
Our bug queue has 105 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 88 bugs
Our bug queue has 88 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 131 bugs
Our bug queue has 131 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 119 bugs
Our bug queue has 119 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 111 bugs
Our bug queue has 111 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 108 bugs
Our bug queue has 108 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 81 bugs
Our bug queue has 81 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 97 bugs
Our bug queue has 97 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 101 bugs
Our bug queue has 101 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 108 bugs
Our bug queue has 108 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 102 bugs
Our bug queue has 102 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 82 bugs
Our bug queue has 82 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 89 bugs
Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 81 bugs
Our bug queue has 81 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] [warning] the bug queue has 92 bugs
Our bug queue has 92 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] Packages looking for new maintainers.
I've dropped myself from the maintainer list in the following packages. Feel free to pick them up if you use them, they deserve better :) app-misc/vifm x11-misc/okindd (also in Qt herd, dead?) x11-misc/whaw x11-misc/qsynergy (also in Qt herd) www-client/luakit this one hasn't had a release for a while, but it has an active github network. www-client/uzbl no recent releases for this either, but it has an active branch on github. The last two need work if you plan to make your own releases or backports, a lot of things have changed. Thanks, -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] Re: RFD: new global USE flag gtk3
On Sun, Feb 23, 2014 at 6:59 PM, Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: I'd say that if around 7 people vote on the matter that that is based on a necessary amount of understanding. That is just incredibly naïve. [...] In history lessons you may have learned about majorities of populations supporting something the same individuals consider a pretty darn bad idea in hindsight, but which they were unable to decide on correctly at the time. You need to learn to respect what you don't know that you don't know. You assume too much. Which is ironic, considering that you're calling us naive. We are not playing guessing games here. Making a decision means that we have the proper knowledge on the matter at hand. We can't guarantee that our decision will be correct, but we can sleep at night knowing we did our best, with the best of intentions. Cheers, -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] RFD: new global USE flag gtk3
On 20 Feb 2014 10:12, Michał Górny mgo...@gentoo.org wrote: Dnia 2014-02-20, o godz. 01:44:17 Steev Klimaszewski st...@gentoo.org napisał(a): On Thu, 2014-02-20 at 07:55 +0200, Samuli Suominen wrote: On 20/02/14 00:23, Ulrich Mueller wrote: Following up to today's QA meeting: The gtk3 USE flag is used by 27 packages, so I suggest making it a global flag: gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3 Ulrich that would suggest it's fine to use, and is anything but temporary -1 from here MATE desktop (which I hope to bring in to Portage soon) can be built against gtk+ 2 or gtk+ 3, and upstream supports doing both, so +1 from me. Except that now users have to use USE='gtk gtk3' to get GUIs in random applications that support only one toolkit. And then handle REQUIRED_USE mess for packages that support choosing one of the two. Just because gtk+ 3 is the latest, does not mean it's the greatest, and I really wish people would realize that newest != bestest. Yet it's supported, unlike GTK+2. I really wish people would actually step up to fix bugs when the time comes rather than shouting about their right to choose. The main idea here is to create a system that is consistent. Yes, gtk2 is still used and IMO we need to provide support for it as long as there are apps linked to it with no real alternatives. But we also need to think about the future. The situation today is a total mess. In an ideal world, gtk3 would replace gtk2 everywhere in an instant, making this discussion pointless. Unfortunately, this is not the case. Versioned USE flags solve most of the problems with minimum fuss, while paving the road for a much cleaner gtk3 - gtk4 transition. We don't really need generic use flags anyway. Adding gtk3 to your USE is really easy and I expect our user base to be able to handle these things with ease. Alex
Re: [gentoo-dev] Re: RFD: new global USE flag gtk3
On 20 Feb 2014 12:30, Samuli Suominen ssuomi...@gentoo.org wrote: On 20/02/14 12:07, Duncan wrote: Samuli Suominen posted on Thu, 20 Feb 2014 07:55:44 +0200 as excerpted: On 20/02/14 00:23, Ulrich Mueller wrote: Following up to today's QA meeting: The gtk3 USE flag is used by 27 packages, so I suggest making it a global flag: gtk3 - Add support for x11-libs/gtk+ (The GIMP Toolkit) version 3 Ulrich that would suggest it's fine to use, and is anything but temporary -1 from here You must have missed the news implied by that following up wording, then. See the announcement/thread February 2014 QA policy updates, posted by creffett, just a few minutes before this thread started. I find it sad the QA team has been taken over by some of the new and semi-new developers who don't completely understand the implications of this decision yet since they haven't lived through the older transitions. Well, I find it sad that Gentoo is trying really hard to resist change - although things have been improving lately. Honestly, I really like the new QA team, we actually push things forward! Sure, not everyone will always agree with us, but that is natural. By the way, we did not take over. We were entrusted with this role, we discuss everything with the community and try to take decisions that are good for Gentoo. We don't have some secret ulterior motive to take over the world through Gentoo. For what it's worth, as a QA member I always vote with what I believe is best for Gentoo in mind. Cheers, Alex
[gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
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).
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]
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.
Cheers
[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3
--
Alex Alexander | wired@gentoo
signature.asc
Description: Digital signature
Re: [gentoo-dev] Doing and then undoing slotmoves
On Wed, Dec 18, 2013 at 11:11 AM, Fabio Erculiani lx...@gentoo.org wrote: Hi, 6 days ago gienah committed a bunch of slotmoves for the haskell glib/gtk stuff [1], basically moving the pkgs to slot 0 (from slot 2). This was done in file 4Q-2013. It turns out that the same gienah moved those pkgs to slot 2 (from slot 0) in 2Q-2013 [2]. I have never seen something like that and this generated an interesting bug in entropy (well, I fixed it...). What I am asking is quite simple though. Is this allowed? Should the previous slotmove be removed? Did a few quick tests, seems to me that the old slotmove should be removed. Alex
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 9 Nov 2013 12:16, Lars Wendler polynomia...@gentoo.org wrote: Am Fri, 08 Nov 2013 20:17:27 -0500 schrieb Chris Reffett creff...@gentoo.org: 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 Oh dear... 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. I would like to help as well. Nagios herd + git overlay for easier nondev contributions? :) Alex | wired
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On Sat, Nov 9, 2013 at 5:20 PM, Diego Elio Pettenò flamee...@flameeyes.euwrote: I don't understand people's insistence with a single product herd given we don't have enough manpower yet and I don't want to have an explosion of aliases I need to subscribe to, the spam is enough as it is. Herds are definitely not the solution for everything, but they make sense when you have multiple people interested in maintaining large sets of ebuilds. If nothing else, they make life easier for bug wranglers, especially when you have 2 maintainers. -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On Sat, Nov 9, 2013 at 5:43 PM, Diego Elio Pettenò flamee...@flameeyes.euwrote: On Sat, Nov 9, 2013 at 3:30 PM, Alex Alexander wi...@gentoo.org wrote: On Sat, Nov 9, 2013 at 5:20 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: I don't understand people's insistence with a single product herd given we don't have enough manpower yet and I don't want to have an explosion of aliases I need to subscribe to, the spam is enough as it is. Herds are definitely not the solution for everything, but they make sense when you have multiple people interested in maintaining large sets of ebuilds. If nothing else, they make life easier for bug wranglers, especially when you have 2 maintainers. You read my comment the wrong way (or I wrote it too hastily to be understood). I mean I don't see the need to split sysadmin herd in three or more. Sure there is stuff in sysadmin that I don't care about because I don't use, but nothing forces me to maintain all of it. And if nobody cares about I'm perfectly fine to mark it as m-n. But I don't see the point in saying well, nobody cares about nagios but two people, so we're moving it to a nagios herd. Might as well just use the two maintainers there, then. Yes I know I haven't been active at all. My time management is terrible and even after meeting Tom Limoncelli in person I doubt I'll magically start getting better at it, but I'll try to work on it. I misunderstood you, I thought you were comparing having herds to not having herds at all, my bad. I replied hastily and didn't consider that nagios and friends are part of a herd already. I agree that splitting herds is not necessary in a case like this. -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] [warning] the bug queue has 89 bugs
On Wed, Nov 6, 2013 at 6:08 PM, Tom Wijsman tom...@gentoo.org wrote: On Wed, 6 Nov 2013 14:00:02 +0200 (EET) Alex Alexander wi...@gentoo.org wrote: Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Is this notice automated? Feel free to ping us (b-w) as well or instead. Thank you to everyone whom helped along here and there. Spent a full two hours on helping to empty the queue; there are some bugs with pending information left, and one I don't know how to assign. It's automated, check runs once a day. Good work everyone, queue is down to 9 bugs at the moment :) Cheers, -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer patr...@gentoo.org wrote: On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: Greetings, Gnome Herd decided to target stablilization of 3.8 [1] which requires systemd. What are the reasons to stable 3.8 and not 3.6, a version w/o this restriction, enabling all non systemd users to profit from this eye-candy as well. I raise the freedom of choice card here. And deliberately choosing an uncooperative version doesn't shine a good light. Facts, pls! Michael [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 To stabilize gnome-3.6, we would need 1. one or (preferably) two *active* gentoo developers; 2. who are familiar with gnome's internals and are able to backport bugfixes from 3.8/3.10 without support from upstream developers; and 3. who volunteer to run openrc+gnome-3.6 for a long time on their main machines so that they can give a stable 3.6 the support that the word 'stable' implies. We do not have such people on the gnome team. Seeing the noise in #gentoo from people getting whacked in the kidney by the systemd sidegrade ... that's a very optimistic decision. It'll cause lots of pain for users that suddenly can't start lvm properly and other nasty landmines hidden in the upgrade path. By stabilizing this early you're causing lots of extra work for others. I hope you understand that some of us will be very rude and just suggest to unmerge gnome on all support requests as it now moves outside our support range ... Have a nice day, Patrick Although I understand your frustration, I don't see any other options for the Gentoo gnome team. People who don't like this should take their complaints upstream. -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
[gentoo-dev] revbumping ebuilds after USE dependency changes
Hello, Please revbump an ebuild after changing its USE dependencies. Using net-p2p/transmission as an example, it used to depend on dev-qt/qtgui:4=[dbus] however, qtgui lost the dbus useflag, so the dependency was changed to dev-qt/qtgui:4=[dbus(+)] without revbumping the transmission ebuild. [0] Portage fails to notice this when resolving dependencies if the package was installed prior to the change, resulting in errors like the following: (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts with dev-qt/qtgui:4/4=[dbus] required by (net-p2p/transmission-2.80::gentoo, installed) which, I imagine, could be very frustrating for a user who doesn't mess with the internals of Gentoo often. You might think that such a revbump is overkill, but in reality the user will have to re-emerge the package anyway in order to get rid of the error, so there is no point in avoiding it, unless portage changes the way it handles these changes. [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1r2=1.2 Thanks, -- Alex Alexander | wired@gentoo + www.linuxized.com ++ www.leetworks.com signature.asc Description: Digital signature
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander wi...@gentoo.org wrote: Hello, Please revbump an ebuild after changing its USE dependencies. Using net-p2p/transmission as an example, it used to depend on dev-qt/qtgui:4=[dbus] however, qtgui lost the dbus useflag, so the dependency was changed to dev-qt/qtgui:4=[dbus(+)] without revbumping the transmission ebuild. [0] Portage fails to notice this when resolving dependencies if the package was installed prior to the change, resulting in errors like the following: (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts with dev-qt/qtgui:4/4=[dbus] required by (net-p2p/transmission-2.80::gentoo, installed) which, I imagine, could be very frustrating for a user who doesn't mess with the internals of Gentoo often. You might think that such a revbump is overkill, but in reality the user will have to re-emerge the package anyway in order to get rid of the error, so there is no point in avoiding it, unless portage changes the way it handles these changes. [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1r2=1.2 Actually, Portage normally handles this situation gracefully by using the dependencies from the portage tree instead of vdb. However, in the case of a slot-operator dep, it always uses vdb. See bug 477544. https://bugs.gentoo.org/show_bug.cgi?id=477544 Aha, thanks for the bug, missed it. Well, my recommendation is still valid until portage gets fixed. Glad to know someone's looking into it though. -- Alex Alexander | wired@gentoo + www.linuxized.com ++ www.leetworks.com signature.asc Description: Digital signature
Re: [gentoo-dev] Draft news item: preserve-libs default for portage-2.1.12
On Sun, Jun 02, 2013 at 05:41:21PM -0700, Zac Medico wrote: Please review the attached news item which announces the preserve-libs default for portage-2.1.12. Note that our council has discussed this change in their 2013-05-14 meeting [1], and they were in favor of allowing it. [1] http://thread.gmane.org/gmane.linux.gentoo.project/2448/focus=2452 -- Thanks, Zac Title: Portage preserve-libs default Author: Zac Medico zmed...@gentoo.org Content-Type: text/plain Posted: 2012-06-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =sys-apps/portage-2.1.12 Beginning with sys-apps/portage-2.1.12, FEATURES=preserve-libs is enabled by default. This feature will preserve libraries when the sonames change during upgrade or downgrade. Libraries are preserved only if consumers of those libraries are detected. Preserved libraries are automatically removed when there are no remaining consumers. Run `emerge @preserved-rebuild` in order to rebuild all consumers of preserved libraries. If you would like to disable this behavior by default, then set FEATURES=-preserve-libs in make.conf. See the make.conf(5) man page for more information about this feature. Looks good. Perhaps you'd like to add that this replaces revdep-rebuild in case it's not obvious to some users. By the way: Wh h xD I almost believed this would never happen. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com signature.asc Description: Digital signature
Re: [gentoo-dev] GCC 4.7 unmasking
On 25 Feb 2013 06:53, Ryan Hill dirtye...@gentoo.org wrote: I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs blocking the 4.7 tracker, so if any are yours now would be a good time to take a look at them. https://bugs.gentoo.org/390247 Can't you just smell all those Gentoo systems gearing up for long emerge -e sessions? xD Thanks for working on this. Alex | wired
Re: [gentoo-dev] Packages up for grabs
On Thu, Jan 3, 2013 at 12:57 AM, Panagiotis Christopoulos pchr...@gentoo.org wrote: On 22:52 Thu 20 Dec , Pacho Ramos wrote: Due araujo no longer taking care of them: dev-lang/gnu-smalltalk ... I'm taking this one. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) o_O xD -- Alex http://www.linuxized.com
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sep 22, 2012 10:58 AM, Michał Górny mgo...@gentoo.org wrote: Hello, The current dependency syntax: [VERSION-OP] PACKAGE-NAME [- PACKAGE-VERSION] suffers a few problems: The syntax you are describing is used all over portage, not just dependencies. Some examples are the /etc/portage/package.* files, has_version or exact version matching when emerging. Changing it just for dependencies would most certainly confuse people and tbh I like the current syntax :-) Alex | wired
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sep 22, 2012 7:38 PM, Michał Górny mgo...@gentoo.org wrote: emerge 'foo = 1.1' 'bar 1.0'? emerge foo '=' 1.1 bar '' 1.0? How is the above easier to read than emerge =foo-1.1 bar-1.0 ? I think your example is working against you*.* The current syntax is much easier to read than the quote-and-whitespace-tracking horror of your example :-P Alex | wired
Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
On Sep 22, 2012 8:25 PM, Michał Górny mgo...@gentoo.org wrote: On Sat, 22 Sep 2012 20:11:48 +0300 Alex Alexander wi...@gentoo.org wrote: On Sep 22, 2012 7:38 PM, Michał Górny mgo...@gentoo.org wrote: emerge 'foo = 1.1' 'bar 1.0'? emerge foo '=' 1.1 bar '' 1.0? How is the above easier to read than emerge =foo-1.1 bar-1.0 Did you even test it? That would create '=foo-1.1' and then fail trying to read 'bar-1.0'. It's rather: emerge '=foo-1.1' 'bar-1.0' Yes, you are right, still much easier to read than your example tho. Testing things is limited to very important stuff atm, I only have an android phone and intermittent 3g available and ssh without a real kb is a pain :-) I think your example is working against you*.* The current syntax is much easier to read than the quote-and-whitespace-tracking horror of your example :-P It's no less quoting than in the current case. And it could be simply extended to supporting quoting-less syntax, e.g.: emerge foo -gt 1.1 bar -lt 1.0 I still find whitespace inappropriate for this kind of things. You are trying to replace a single atom that instantly gives you all required information with a format that does not clearly separate atoms, IMHO anyway :-) Alex | wired
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sep 17, 2012 6:13 AM, Brian Harring ferri...@gmail.com wrote:
On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
On Sep 16, 2012 4:55 PM, Brian Harring [1]ferri...@gmail.com
wrote:
Folks-
Keeping it short and quick, a basic glep has been written for what
I'm
proposing for DEPENDENCIES enhancement.
The live version of the doc is available at
[2]
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
ndencies.html
Am I the only one who thinks that this dep:{build,...} thing looks
really ugly and is hard to read?
IMO simply removing the dep part would greatly improve things:
That 'dep' part isn't great, but it's added for a reason; to unify
with USE_EXPAND/use group intended syntax. There's a reference in
there to
http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
I'll formalize soon enough.
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
For your suggestion, consider it if we *do* fxi USE expand- via using
the same namespace:setting form.
Using app-admin/mcollective ad an example, it's deps are thus:
DEPEND=ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
RDEPEND=dev-ruby/stomp
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
Which, if USE_EXPAND targets were groupped, would go from this
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
dep:run? ( dev-ruby/stomp )
to this:
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
:run? ( dev-ruby/stomp )
Ok, now I get it. I've read the other threads as well, but failed to put it
all together. Happens when you barely sleep every night :-)
I don't like this mix of dependency types and use flag deps. It smells
trouble. Dependency types should be easy to separate and read, but the
above example is a mess, dep: or no dep:.
Why? Because you have to scan the whole thing to sort out which lines are
dependency types and which lines are use deps and even then it would be
easy to misread something.
If we want to stay away from labels (which aren't that bad IMO), I'd
recommend the following instead:
Force explicit setting of the dependency type and disallow the mix of
dependency types and use flag deps at the same level / block.
DEPENDENCIES=
:build,run? ( lib/foo )
:run? (
lib/bar
someuseflag? ( random/app )
)
:*? (
thing? (
:build? ( lib/thing )
:run? ( lib/thingrunner )
)
Or, using your example:
:build,run? (
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
)
:run? ( dev-ruby/stomp )
Alex | wired
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Sep 16, 2012 4:55 PM, Brian Harring ferri...@gmail.com wrote:
Folks-
Keeping it short and quick, a basic glep has been written for what I'm
proposing for DEPENDENCIES enhancement.
The live version of the doc is available at
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
Am I the only one who thinks that this dep:{build,...} thing looks really
ugly and is hard to read?
IMO simply removing the dep part would greatly improve things:
DEPENDENCIES=
:build,run? ( ... )
:run? ( ... )
s/:/@/ would also be interesting
DEPENDENCIES=
@build,run? ( ... )
@run? ( ... )
Alex | wired
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:22 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 20:23:13 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 23 Jun 2012 19:06:38 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 20:09:03 +0200 Michał Górny mgo...@gentoo.org wrote: That's just it, though -- this no longer holds. -r300 is now being used for something that is exactly the same version as -r200. Did you look at SONAME? Look at SONAME before deciding what package to install? Kindly explain how that works. I'm just saying that these are two different versions of the package. If you want GTK+3, you take the newer one. If you want GTK+2 compat, you take the older slot. What's wrong with that? The package mangler does not know that 1.1-r300 is not a better version than 1.1-r200, or that 1.2-r200 is not a better version than 1.1-r300. Indicating packages where this kind of strangeness happens allows manglers to know that things that are usually true about the relationship between slots and versions no longer hold, and that in these specific cases it should consider slots to be heavily independent. You already have this info, it's called a slot dependency. -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:37 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 21:35:47 +0300 Alex Alexander wi...@gentoo.org wrote: The package mangler does not know that 1.1-r300 is not a better version than 1.1-r200, or that 1.2-r200 is not a better version than 1.1-r300. Indicating packages where this kind of strangeness happens allows manglers to know that things that are usually true about the relationship between slots and versions no longer hold, and that in these specific cases it should consider slots to be heavily independent. You already have this info, it's called a slot dependency. It's not a property of individual packages that happen to depend upon the problematic package. The property holds or not for a package regardless of whether anything depends upon it. They are part of the deal. If your package has reverse deps, you don't want to update it before figuring out it's reverse dependencies anyway, you never know what slot/version restrictions you're going to get. If it is a package without reverse dependencies, updating to the most recent slot and/or version should be expected unless the user has the slot defined in the world file. -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 22:14:32 +0300 Alex Alexander wi...@gentoo.org wrote: If it is a package without reverse dependencies, updating to the most recent slot and/or version should be expected unless the user has the slot defined in the world file. That's the part that no longer holds. The package mangler now needs a way of knowing that for a certain few packages, bringing in new slots when not explicitly required is undesirable. Or the PM can notify the user that a new slot has come up and instruct them to specify their desired slot in their world file. -- Alex
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Mar 31, 2012 12:57 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 31 Mar 2012 12:44:03 +0300 Alex Alexander alex.alexan...@gmail.com wrote: @preserved-libs works very well and is awesome. hack or not. IMO it should be in stable already. I've been using it on stable production boxes for years without any issues :) ...and here we see the problem. You think that I haven't noticed it break means it works. The problem with preserved-libs (and emerge --jobs, for that matter) is that the design is I can think of a few ways where it might break, so I'll hard-code in special cases to handle those, but in general I can't think of what other problems there are so it's fine. That's a bad way of doing things. -- Ciaran McCreesh No. I didn't say I think it works, I said I have proof it works. You can argue about the implementation details all you want and it'll still work. If you can make it better then, by all means, send a patch. Otherwise stop spreading false FUD, please. Thanks :) Alex | wired
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Mar 31, 2012 5:57 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 31 Mar 2012 15:08:29 +0300 Alex Alexander alex.alexan...@gmail.com wrote: No. I didn't say I think it works, I said I have proof it works. Well that's interesting, because there are plenty of examples where it doesn't work, and all that it takes to disprove a theory is a single counterexample. So I think you're misunderstanding what constitutes proof here -- some evidence certainly isn't it. -- Ciaran McCreesh Boring. You conveniently ignored the other part of my message. I'll repeat it: no matter how much you argue, it'll still work fine for me. That said, I think we can end this conversation now :) Gentoo \o/ Alex | wired
