Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
On 00:13 Wed 12 Feb , Gilles Dartiguelongue wrote: Right now, I don't really get the point of this discussion given all the precedent threads about this, be it 2 years ago and 8-10 years ago. I spent a while tonight digging up this post from 2005, which nicely describes where we were with gtk1 vs gtk2 back then. http://marc.info/?l=gentoo-devm=111212920310822w=2 -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpiDAYuRO_lp.pgp Description: PGP signature
Re: [gentoo-dev] Add support for rsync patches
On 12:48 Tue 28 Jan , Michał Górny wrote: Dnia 2014-01-28, o godz. 11:59:33 Jauhien Piatlicki jpiatli...@gmail.com napisał(a): net-misc/rsync upstream provides a tarball with additional patches that can be useful for some users. I think it would be nice to have them handled automatically by portage using e.g. USE_EXPAND. Of course these patches can be just picked by user an applied using epatch_user, but I think it would be much easier and convenient to do this with just setting a use flag. ...and what do you want from gentoo-dev@? You need someone to file the bug for ya? This is not the level of friendliness that is going to welcome potential new contributors into our community. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp1ny54yNMQ0.pgp Description: PGP signature
Re: [gentoo-dev] Re: [OT] pkgcore bikeshed
On 11:02 Mon 13 Jan , Steven J. Long wrote: On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote: Realistically, we have to keep updating them both in parallel. pkgcore needs to be brought up to portage-level functionality, Yeah but it already outshines under the hood: all you're talking about is EAPI and radhermit is working on it; I'm sure he and dol-sen would be happy for more help as well, so long as it's supportive. ISTR TomWij is involved too. Working on the UX of the emerge frontend is also of extreme importance if you want people actually using it. Speed is absolutely a usability feature but it's not the only one that matters. Maintaining EAPI parity is table stakes. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpQJ5K5w1XJT.pgp Description: PGP signature
Re: [gentoo-dev] Default USE changes for fortran and mudflap?
On 01:53 Sun 12 Jan , Ryan Hill wrote: fortran: Do we want to keep enabling fortran by default? The majority of users will never get the urge to install a fortran package, and the fortran eclass handles those that do. I think it should be treated as all the other optional languages and disabled by default, but I'd like to know if there are other opinions. It's essentially only used by the small minority of people installing sci-* packages so I'd be fine with that. Reasonable defaults FTW. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpKSLofMizut.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: storing predefined INSTALL_MASK directory lists in repos
On 19:59 Sat 11 Jan , Peter Stuge wrote: Duncan wrote: Michał Górny wrote: INSTALL_MASK=systemd bash-completion What are your thoughts? It seems like this will generally duplicate all -USE flags. Would it make sense to instead have a single setting which changes the meaning of USE to be that everything not USEd is install-masked? No, this would not be a duplicate. I did generalize, but think more about this - certainly for both Michał's examples I have already either set or unset systemd and bash-completion in USE. It would largely be a duplicate, since we've already made a decision about whether the ability to build without a feature is important enough to merit a USE flag. This is essentially rethinking the same decision and adding complexity to it. I think having this as an additional feature in the core PM would be confusing to users. It would probably be a better fit in gentoolkit or a similar tool. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpcJ3C4i8c3x.pgp Description: PGP signature
Re: [gentoo-dev] Doing and then undoing slotmoves
On 12:31 Mon 23 Dec , Jeroen Roovers wrote: On Sun, 22 Dec 2013 20:07:21 -0600 Donnie Berkholz dberkh...@gentoo.org wrote: Seems we should add repoman support to check profiles/. Spec mandates that are not implemented in any tool are unlikely to be adhered to. repoman does not work in profiles, to my knowledge. It expects ebuild in package directories in categorie directories. I'm confused. Isn't that exactly what I just said? add repoman support -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpK6B9Oku7YA.pgp Description: PGP signature
Re: [gentoo-dev] Doing and then undoing slotmoves
On 10:19 Wed 18 Dec , Ulrich Mueller wrote: On Wed, 18 Dec 2013, Fabio Erculiani wrote: 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? The PMS does not allow it: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-390004.4.4 Seems we should add repoman support to check profiles/. Spec mandates that are not implemented in any tool are unlikely to be adhered to. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpl051gaF9bu.pgp Description: PGP signature
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On 11:03 Thu 26 Sep , JD Horelick wrote: My only issue here is that I feel like we should give users a bit longer than one month (34 days, close enough) to make this change. In some cases, it may require a large, architectural change which may take a while to be engineered and organized. I'd suggest making the cutoff for this January 1, 2014. I know that impedes our progress, but I feel it provides significant benefit to our users who may use seperate /usr. In reality it should be more like 60 days before any of those users are affected. We stop support in 30 days (which can't be done directly in stable), then we test that in ~arch for the usual 30 days before stabilizing. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp_W_sG3SI4M.pgp Description: PGP signature
Re: [gentoo-dev] Changes in libreoffice ebuild
On 14:37 Tue 13 Aug , Rich Freeman wrote: If a maintainer is holding something up for months by all means escalate it if you think it is justified, but if a maintainer just wants a few days to look into things, that isn't asking too much. If this were a security patch I might feel differently, or a stable regression (though as has been pointed out that shouldn't happen with reverse dep testing). Turns out we already wrote this down. See Touching other developers ebuilds: http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpFgfbAJDv3x.pgp Description: PGP signature
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On 08:00 Thu 08 Aug , Patrick Lauer wrote: On 08/08/2013 04:47 AM, hasufell wrote: I'd say let's push for it. I am willing to do a lot of testing. Good plan. I hope I find some time to figure out a roadmap so we have an idea what needs to be done - or someone else might just want to read through some old threads and do the same. There's https://bugs.gentoo.org/show_bug.cgi?id=333531 -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpL7_AlSQmu9.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On 15:36 Fri 02 Aug , William Hubbs wrote: All, This message is an announcement and a reminder. OpenRc-0.12 will be introduced to the portage tree in the next few days. If you are using ~arch OpenRc, the standard disclaimer applies: remember that you might be subject to breakage. I do not know of any breakage personally. It does work on my system, and I know of others who are using OpenRc from git successfully. Some are OpenRc team members, and at least one is a Gentoo user. If you are not comfortable with the possibility of breakage, I recommend that you make sure you do not upgrade right away. If, on the other hand, you are comfortable with that possibility and you are willing to help us test and get rid of bugs before we go stable, feel free to run ~arch. In other words, this is the standard Gentoo disclaimer, so consider yourself warned. Man, in terms of how to phrase things, this is way wrong. If you're comfortable with your stuff breaking really? No. If you want to help improve Gentoo. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpR7xYCntyTZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: toolchain-r1.eclass
On 22:30 Thu 25 Jul , Ryan Hill wrote: I don't think we will be moving to 5 very soon. I have nothing against it but Mike might be a harder sell. I want USE deps so I'm going to do 2 at least, then get the prefix guys on board for 3. The council deprecated 1/2 in April so I'd avoid those. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpk8YyXSSTTY.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: fortran-2.eclass - Support for bin package system without compiler
On 10:44 Thu 18 Jul , Justin wrote:
+fortran-2_pkg_setup() {
+ case ${EAPI:-0} in
+ 0|1|2|3)
+ eqawarn Support for EAPI 4 will be removed from the
+ eqawarn fortran-2.eclass in near future.
+ eqawarn Please migrate your package to a higher EAPI
+ eqawarn or file a bug at https://bugs.gentoo.org;
+ _fortran-2_pkg_setup ;;
It's more useful if you provide a date here (30+ days from the commit)
after which things are no longer guaranteed to work, versus near
future.
I didn't catch it in your original email — have you run a scan to see
how many ebuilds are affected?
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/
pgp6OhBSU0BAC.pgp
Description: PGP signature
Re: [gentoo-dev] Gentoo Hangouts
On 18:52 Mon 08 Jul , Pavlos Ratis wrote: As far as I can see, opinions about VCs are 50-50. However, I don't see any disadvantages adding video hangouts to the project. VCs _are not_ mandatory and doesn't replace any of our current communication methods. You are not forced to participate. It's all about choice. If there are no objections and if the PR team gives an ack. I'd like to add video hangouts under the PR project (I'll create a simple faq page in wiki about VCs). Go ahead. Experiments are always welcome. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpSNOnrgt6NR.pgp Description: PGP signature
Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.
On 20:19 Thu 04 Jul , Mike Pagano wrote: I have 'relaxed' a tad about what I think should be in g-s, but maybe it has gone a bit farther than I wanted it too. I would like to see a -experimental use flag and base,extras,geek (whatever) so that g-s goes back to what it's original goal was with nothing non-upstream unless the user does a configuration change themselves. This will actually help us solve both issues. 1) it will allow us to pull g-s back to it's original goal as a minimal kernel sources with upstream only patches. Original? Not true. gentoo-sources has, for ages, carried feature patches that were considered useful to Gentoo as a whole or to releng in particular. It's carried whole filesystems like XFS, it's carried EVMS, it's carried pretty much the whole ck- patchset (Con Kolivas), grsec, FreeS/WAN and OpenS/WAN, the bootsplash stuff, etc. 2) we can carry some patches from upstreams trees that possibly aren't yet in -next, or not yet accepted to mainline but do provide some benefit to a smaller group of our users. (Thinking about our thinkpad patches) -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpGcbFM00xhl.pgp Description: PGP signature
Re: [gentoo-dev] new category: games-adventure/
On 17:26 Sun 14 Jul , Diego Elio Pettenò wrote: I would object... 10 games are wa too few for a new category and especially pkg moves.. I wrote a script years ago to make recommendations for this. I just updated it to do things a little smarter. It bases its suggestions on percentiles of existing category sizes. http://dev.gentoo.org/~dberkholz/scripts/category-size $ category-size Statistics for /usr/portage: Median packages per category = 51 Suggested category size (25%–75%): 18 to 91 Split categories with more than 91 packages, and do not create categories with fewer than 18 packages. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpOocMKQ8ulN.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo Hangouts
On 09:21 Mon 24 Jun , Mike Pagano wrote: Sometimes it helps to realize that the people on the other end of the wire are just that: people. I've seen behaviors change among team members for the better. ^^ This. Seeing people as close to in person as we can get without a conference really does help to improve the quality of our interactions. It's a lot harder to be a jerk when you can picture the person you're writing to as a living, breathing person. Given recent, and more distant, actions by some of our community with DevRel consequences, it should be clear that treating our fellow developers decently is a problem. And seriously, hopping on a video chat once or twice a year should be doable for most of us. I don't necessarily care a lot about the PR value of any replays, I see it as much more important to strengthening Gentoo than to do outreach. That said, I've gotten over 10,000 views of an intro talk on Gentoo that's posted on YouTube despite its pretty bad audio quality, and nearly 2,000 views of a Gentoo talk targeted at developers, so there's clearly people looking for this stuff. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgphu4DSZRfgK.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean
On 23:41 Sat 06 Apr , Michał Górny wrote: Optionally, after the last paragraph you can add a few lines with tags in form of 'Tag: value'. AFAICS git itself uses only 'Signed-off-by' but you can find more tags in various 'submitting patches' docs. 'Signed-off-by' lists the one responsible for the patch. Some upstreams require that line, some take over authorship of patches if you don't add it (like X.org), some just hate it :). The X.org wiki lists also 'Fixes' for bugtracker URL [2] and a few tags for reviewing patches [3] (those are probably not useful for us). This is the part that would be most useful to document more. Suggesting which tags would be valuable to include. Fixes, Reviewed-by, Signed-off-by, etc. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpMghgyMMro7.pgp Description: PGP signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 18:03 Sat 05 Jan , Andreas K. Huettel wrote: Am Samstag, 5. Januar 2013, 16:46:07 schrieb Roy Bamford: I agree its not 'core business' but Gentoo isn't a business. Even if you're not a business you should care about maintainable solutions. More importantly, even if you aren't a business (although we are, technically, albeit a not-for-profit one), you should still have a mission that you're focused on accomplishing. Otherwise you can justify anything in the context of Gentoo, when in reality we need to limit our scope to increase our impact. I actually suspect this is a byproduct of Gentoo being many contributors' first OSS development experiences. They're nervous to branch out on their own w/ e.g. a GitHub repo so they initiate *everything* under the Gentoo umbrella. I would argue that defining a clear vision and audience for Gentoo would significantly increase our ability to get useful things done. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpzBhWAtbiqb.pgp Description: PGP signature
Re: [gentoo-dev] Re: Wordiness
On 05:31 Fri 21 Dec , Matt Turner wrote: My point is that you consistently write long essays that I, and apparently most others, don't bother to read. I'm not sure if you're aware of this. Someone said on IRC this morning in response to this thread the tragic thing is that guy would be able to make valuable contributions if it weren't for the excessive length of his mails So, your emails are way too long. A huge percentage of recipients don't bother to read them. I don't know whether you just enjoy writing (you must!) or if you hope to actually be heard, but as it stands now you're not being heard by most. Just coming back from Christmas vacation, but ... Yeah. Duncan, you need to learn how to be pithy. Invest the effort to cut your writing down to its essence; consider the time of the 100s/1000s who read it. Your value and impact will increase exponentially. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpR4IRW1xeQ_.pgp Description: PGP signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 10:26 Sat 22 Dec , Pacho Ramos wrote: Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using elog messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? Bikeshedding ... would go with README.gentoo, because people are already used to looking for README files. Every time we can eliminate Gentoo-specific weirdness, we should. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp3sbsAFBIVY.pgp Description: PGP signature
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 10:43 Mon 17 Dec , Markos Chandras wrote: On 16 December 2012 18:53, Andreas K. Huettel dilfri...@gentoo.org wrote: How to do this, however, and what software to target should probably be decided by people who know more than me... and in the end it all boils down to who has the time and motivation. Outsource it to someone who has the knowledge and interest in doing this. The foundation has the funds to support it, and none of us actually have the time to invest in a complete webpage redesign. I did much of the design work nearly 2 years ago: http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_black.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_install.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook.png http://dev.gentoo.org/~dberkholz/gentoo_website/gentoo_landing_handbook2.png Some early work on it using Bootstrap: http://a3li.li/~alex/g.o/ That said, why the hell are we wasting time implementing our own website backend when we should be using a CMS? We're here to make a distro, not a website framework. No reason we should care, day to day, about anything but frontend theming and content. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpSKkhPZZeQ4.pgp Description: PGP signature
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 04:22 Fri 23 Nov , Robin H. Johnson wrote: On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote: On 11:11 Sun 18 Nov , Robin H. Johnson wrote: Here's a list of every package where I'm a maintainer and there is no herd listed (but their might be other maintainers): I didn't say I was dropping any of the packages, merely making an explicit list of packages I maintain, that other developers are welcome to touch - if they want to take them over explicitly, that would be great too. Gah, my bad, trying to run through email too fast. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpZBv5vUx4gN.pgp Description: PGP signature
Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux
On 10:24 Fri 16 Nov , Dirkjan Ochtman wrote: On Thu, Nov 15, 2012 at 8:42 PM, Justin j...@gentoo.org wrote: does anybody like to setup an Organization[1] profile @ ohloh for Gentoo? I've shot them a message, let's see what happens. Lemme know if you need any help pushing this through, I know the guy running it pretty well. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpeD65iNmfgq.pgp Description: PGP signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 23:57 Sat 17 Nov , Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote: I'm unsure on what grounds you disapprove. People start (and abandon) projects often in Gentoo. Suddenly you dislike one such project and object to this practice? Certainly if we had to get some sort of Foundation consensus (for anything) nothing would happen. We can't even get more than 40% of foundation members to vote. I object if this is seen as a Gentoo blessed fork of a community project that is worked on by all other major Linux distros. That is the type of decision that can be made by the Gentoo Council, which is fine, but it sure would be nice if it were publicly stated, instead of having to see it on the Gentoo github site instead. And if that is the decision of the council, I would expect the ability to have some type of discussion about it, wouldn't you? Sorry to follow up late but I feel like the critical point never made it clearly into this discussion. The key misunderstanding here seems to be that initiation of a Gentoo project means that the council explicitly supports it, because in most distributions there is no choice available to end users at this level of detail. Instead, in Gentoo, the council-level decision typically happens when the *default* changes. Non-default or non-mandatory things are handled in a nearly anarchic, ad hoc manner, where anyone can do pretty much whatever they want as an official Gentoo project. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpFP4Q0Esq9W.pgp Description: PGP signature
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 11:11 Sun 18 Nov , Robin H. Johnson wrote: Here's a list of every package where I'm a maintainer and there is no herd listed (but their might be other maintainers): dev-util/wiggle dev-vcs/cvs2svn Suppose I could take these. dev-vcs/git I'm hoping somebody is taking this? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgplPH1rn4ntA.pgp Description: PGP signature
Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
On 16:27 Sun 13 May , Mike Gilbert wrote: To make ebuilds utilizing python-distutils-ng.eclass usable I didn't read any farther because I couldn't stop laughing. What will the next version of this eclass be called, -ng-ng? -really-ng? =) -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpIBXHy7OxqK.pgp Description: PGP signature
Re: [gentoo-dev] Keeping older versions around
On 21:33 Sat 28 Jan , Ryan Hill wrote:
I've run into this three times today, so I'm a little grumpy. When you bump
to a new ~arch version, please consider keeping at least one previous ~arch
version around, so if people run into major issues they can at lease try the
previously installed version to determine if it's your package at fault.
Recent version bumps to two libraries have completely trashed a package I
maintain, and the only option for my users is downgrading them to stable,
which requires downgrading several other libraries. In both cases, the
previous ~arch version, which worked fine, was removed.
Personally I always try to keep two versions in ~arch and one stable,
excepting security or other major bugs that render an older version useless.
Agreed with a slight modification — once you've kept the old
{stable,~arch} version around for a reasonable amount of time (say 30
days), you should be safe pulling it.
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com
Analyst, RedMonk http://redmonk.com/dberkholz/
pgpSKypfDxmlZ.pgp
Description: PGP signature
Re: [gentoo-dev] Free Gentoo
On 21:01 Sat 21 Jan , . wrote: Hello there! Is there a chance that Gentoo may become a free distro? I'm so unhappy with the fact that there are some non-free packages in the main tree. The main goal of the GNU project was to replace the proprietary Unix system. You are actually ruining this goal. I'm also dissatisfied with the name of the distro. Linux is the kernel not the whole system. Hi, You should be using the Gentoo derivative Utoto GNU/Linux [1], which consists entirely of FSF-approved free software. 1. http://en.wikipedia.org/wiki/Ututo -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgpwhwggqOB6o.pgp Description: PGP signature
Re: [gentoo-dev] How help in arch testing work
On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: 3) Check your rdepend, where is possible with scanelf[3] and if you declare it, please, as you said, exclude gcc/glibc and all package from @system portage generates a NEEDED file in the vdb Awesome, never seen that before! -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ pgp3cdeT1u02G.pgp Description: PGP signature
Re: [gentoo-dev] RFC: news item for sys-apps/systemd - /usr migration
On 10:25 Fri 06 Jan , Michał Górny wrote: On Thu, 05 Jan 2012 20:29:53 -0500 Alexandre Rostovtsev tetrom...@gentoo.org wrote: I would suggest not removing the symlink unless there is a technical reason why its presence is undesirable. The symlink is distro-specific. Honestly, I'd get rid of it sooner -- but almost four months seem to be a safe period considering that we are still in 'testing' stage mostly. So other systemd-using distros have it in /usr? I'd follow their convention. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpz8wIaHHzi3.pgp Description: PGP signature
Re: [gentoo-dev] News Item - MythTV
On 21:03 Mon 12 Dec , Peter Volkov wrote: В Птн, 09/12/2011 в 20:38 -0500, Rich Freeman пишет: I'm considering sending out this news item in a few days - comments are welcome. It is a bit different in tone from a typical news item but MythTV has been in not-so-great shape for a while and my goal is to reel things in a bit and commit to something we can continue to maintain, while soliciting help from the community. This does not look like a news item, but more like a project status update or blog post. Probably it's much better to create webpage (or news item) on www.gentoo.org and add elog/ewarn to point there. Once mythtv team changes this information may change, but all users will see it anyway. I like it fine as a GLEP42 news item, I hate it as a news item on the homepage for sure. Seems to me that pointing to the website for plaintext docs like this is kinda defeating the point of these news items. It's certainly more news rather than a long-term useful document, because at some point the change will happen, and then things are just the way they are. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp89aeKXo0TJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bleeding edge hardened-sources: move PaX markings from ELF to Extended Attributes
On 05:16 Fri 02 Dec , Duncan wrote: TL;DR: reiserfs (v3), for both caps and XT_PAX ?? A bit OT, but I find it incredibly ironic that perhaps the shortest email you've ever written contained a TL;DR segment. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpHC27Ef40KM.pgp Description: PGP signature
Re: [gentoo-dev] rewritten epatch
On 18:45 Wed 23 Nov , Mike Frysinger wrote: personally, i've never found .rej useful. It's nice if you use dev-util/wiggle. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgptppoeNYKdB.pgp Description: PGP signature
Re: [gentoo-dev] huse: new helper for low level eclass writers
On 01:26 Thu 20 Oct , Mike Frysinger wrote: On Wednesday 19 October 2011 15:40:50 Brian Harring wrote: Name's a bit off though considering if the host was amd64, `huse amd64` would return 1 since it's not in IUSE. good point. how about iuse_use ? or use_iuse ? -mike use_in_iuse ? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpZNI8F46o3g.pgp Description: PGP signature
Re: [gentoo-dev] huse: new helper for low level eclass writers
On 12:22 Thu 20 Oct , Mike Frysinger wrote: On Thursday 20 October 2011 11:58:44 Donnie Berkholz wrote: On 01:26 Thu 20 Oct , Mike Frysinger wrote: On Wednesday 19 October 2011 15:40:50 Brian Harring wrote: Name's a bit off though considering if the host was amd64, `huse amd64` would return 1 since it's not in IUSE. good point. how about iuse_use ? or use_iuse ? use_in_iuse ? to me, that sounds like is the use flag in iuse. but maybe i'm over thinking things. alright, use_if_iuse. That's my last bikeshed for today. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpdYd1xNOUgU.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.
On 09:55 Mon 10 Oct , Michał Górny wrote: On Sun, 9 Oct 2011 21:08:43 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: On 10:21 Sun 09 Oct , Michał Górny wrote: We're calling it with '--patch-only' to avoid heavy changes to ebuilds. This should handle gracefully eautoreconfed packages and those not using libtool as well (in worst case, it should try to apply patches twice). What kind of testing have you done? Simple testing on a few packages of mine. If you have something specific in mind, please be more accurate. It's probably better to test on other people's code, since your own will always use eclass code in the way you imagine it being used. For changes to popular eclasses like this, I'd go find a cross-section of 25+ packages written by a variety of people besides yourself (or just test all 87 in the tree). Bonus points for those written by the most and least experienced devs, who I'd expect to use things in more unexpected/unlikely ways. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpZSatUY3Hl9.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-utils] Use elibtoolize from libtool.eclass to fix libtool magic.
On 10:21 Sun 09 Oct , Michał Górny wrote: We're calling it with '--patch-only' to avoid heavy changes to ebuilds. This should handle gracefully eautoreconfed packages and those not using libtool as well (in worst case, it should try to apply patches twice). What kind of testing have you done? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpqkkgxxy6L7.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On 00:31 Mon 03 Oct , Chí-Thanh Christopher Nguyễn wrote: It may be obvious to you, but it certainly is not obvious to me why linux-headers downgrade is so bad. If vapier's unsupported out-of-tree software fails to build against old linux-headers, then he has to make sure to have the correct version installed before proceeding. Blaming that on qutecom is far-fetched IMO. There's like a million packages that use features in linux-headers, so it's not a isolated effect as with xorg-server. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpJmQC6XLYVa.pgp Description: PGP signature
Re: [gentoo-dev] git-2: a bunch of patches to review
On 16:41 Thu 22 Sep , Andreas K. Huettel wrote: Am Donnerstag 22 September 2011, 13:27:47 schrieb Michał Górny: The style change was approved by Donnie already. You mean that Donnie agreed with the style change. It's not up to any individual developer to approve such a change for the entire tree. What kind of 'entire tree'? It is just a single eclass, and its maintainer approves coding style change. Where do you see a problem with that? As Scarabeus wrote 99% of the eclass it's probably not obvious to everyone that Donnie is listed as its maintainer. And as Michał is making many of the changes recently because scarabeus got busy and the eclass works fine for me already, I figure it's his prerogative. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpu61cwgFUSG.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 09:37 Wed 21 Sep , Alec Warner wrote: On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz dberkh...@gentoo.org wrote: Not really, because when you update a bundled lib you actually make your whole app compile with it. People change the APIs of eclasses and then just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if we put the burden on the one who changed the API, like the Linux kernel model, it would bother me less. I think people do this for three reasons. 1) There are no refactoring tools that I know of for bash. 2) There exist some package maintainers that will yell at you if you touch their packages for any reason. To refer to the Linux model again, you send patches to the maintainers, and they just commit them. This is much less effort than figuring out to handle some incomprehensible change to an already weird eclass and then sorting out how to deal with it across 20 or 30 packages. 3) Breaking things means they get fixed. We have this notify - deprecate - break workflow; I actually don't mind it (but only because I've seen it used elsewhere.) I do, because I don't have time to deal with other people breaking my packages, whether they're in gentoo-x86, the science overlay, or my personal one. I've got more important things to deal with, within Gentoo and in the rest of my life. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpSPCiSQYwz8.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 18:04 Thu 22 Sep , Alec Warner wrote: On Thu, Sep 22, 2011 at 5:41 PM, Donnie Berkholz dberkh...@gentoo.org wrote: I do, because I don't have time to deal with other people breaking my packages, whether they're in gentoo-x86, the science overlay, or my personal one. I've got more important things to deal with, within Gentoo and in the rest of my life. You don't have time to fix breakages but you have time to do code reviews? If someone else I trust makes the changes and tells me they work, I can review code in an email on my cell phone in 15 seconds. I have to be on my single dev laptop with Gentoo repos and have a good 15 *minutes* to spare to figure out all the changes required, make them, test them, and do the commit. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpwzQq4wvFJa.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 14:20 Tue 20 Sep , Brian Harring wrote:
On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
OK, so the implication of what you're saying is that everything in
eutils.eclass, base.eclass, toolchain-funcs.eclass,
flag-o-matic.eclass, versionator.eclass, multilib.eclass,
prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass
and autotools{,-utils}.eclass should go into EAPI. All that stuff is
pretty generally useful features.
Approximately... yes. Some of that (base.eclass for example) is EAPI
compatibility that can't be folded in (would require retroactively
addding to an EAPI), others aren't yet stabilized (true multilib for
example, seems to still be under discussion), etc.
You get the jist.
Yep, and I'm completely on the opposite end of the spectrum. =)
They should, but api compatibility of an eclass *can* be fluid- in
the past it was a locked API purely because of portage environment
saving issues. That's been resolved, there isn't any strict
requirement that the eclass maintain API compat now. You're
trying to rely on people doing best practices- for format building
blocks (use_with/usex/unpack/etc), that's not sane.
Which still pisses me off. It's like a shared library changing its
API without bumping SONAME.
I think you're viewing this wrong; if we're talking about openssl
breaking API/ABI w/out bumping soname, sure. It's one component that
is distributed alone, but consumed by others. There is no way to
atomically deploy the new API at the same time as all of the consumers
being updated for it.
That is /not/ the case of gentoo-x86; eclasses for us are equivalent
to bundled libs. Overlay stacking just makes it possible for a third
party component to reach in and use what is effectively an internal
lib.
Not really, because when you update a bundled lib you actually make your
whole app compile with it. People change the APIs of eclasses and then
just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if
we put the burden on the one who changed the API, like the Linux kernel
model, it would bother me less.
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
pgp6JYY1kT8uQ.pgp
Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On 10:00 Tue 20 Sep , Corentin Chary wrote: Could someone write ebuilds for euscan and euscanwww ? It should not take a lot of time, but my ebuilds skills are probably not good enought to do that. Sounds like good practice for when you become a Gentoo dev. =) -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp3w1etPQaXu.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 04:22 Sun 18 Sep , Brian Harring wrote:
On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote:
On 13:43 Fri 16 Sep , Brian Harring wrote:
What I said from the getgo and you're missing is that pushing EAPI
implementation into the tree and ignoring EAPI, or having this notion
that every repository must automatically use gentoo-x86 (pushing the
format into the tree) is /wrong/;
I'm not necessarily requiring that every repository must automatically
use gentoo-x86 ??? just the ones that want to use features in an eclass
distributed with gentoo-x86. It sounds to me like the logical
consequence of what you're saying is that every useful function that's
now or could eventually be in an eclass must instead be incorporated
into EAPI. I guess I just don't see where you're drawing the line.
Drawing it back to what spawned it; usex. This isn't git.eclass, this
isn't svn.eclass, nor is it any of the other complex eclass
functionality. It's a core function that benefits the rest and should
be in EAPI.
OK, so the implication of what you're saying is that everything in
eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass,
versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass,
and maybe even linux-info.eclass and autotools{,-utils}.eclass should go
into EAPI. All that stuff is pretty generally useful features.
What I'm suggesting is that we should add useful stuff to eclasses
by default. If people want to use that stuff, they can stack on the
gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs
to come into it at all.
Stacking on gentoo-x86 means you get *everything* for that repository.
If all you want is a random function out of eutils, that's a *lot* of
uncontrolled change to have intermixed with your overlays eclasses
(even worse, if the eclasses truly overlay into gentoo-x86, that
introduces compatibility issues there too).
Yeah, it seems like the ability to do partial stacking would be nice.
Perhaps to do so, one wouldn't stack by default but would have a way to
specify cross-repo dependencies (including eclasses) or file-specific
UUIDs of some sort.
aside from meaning that the format definition can now *vary*,
which is great for wasting dev time and screwing up compatibility,
it opens up tweaking/customizing that functionality- aka,
fragmentation/divergence.
People doing that outside gentoo-x86 should do it the same way as
ones within it, by bumping the eclass to a new unique name. Ideally
one that's not just a numeric value so it won't conflict with ours,
in the same way as EAPI naming.
They should, but api compatibility of an eclass *can* be fluid- in the
past it was a locked API purely because of portage environment saving
issues. That's been resolved, there isn't any strict requirement that
the eclass maintain API compat now. You're trying to rely on people
doing best practices- for format building blocks
(use_with/usex/unpack/etc), that's not sane.
Which still pisses me off. It's like a shared library changing its API
without bumping SONAME. That makes me wonder whether there's some way we
could enforce it, at least on the level of repoman or test suites to
examine whether the public interface changed, perhaps by generating a
cache of the interfaces and comparing to them.
I suspect an easier way to wrap this thread up is if you just state
what you want for backwards compatibility- in a seperate thread you
already proposed basically locking out systems older than 6 months,
and this discussion (moreso the eapi slows our development subtext)
is along the same lines.
Actually Zac said that, and I was trying to clarify if that's really
what he was saying. 9-12 months is more my feeling, as it gets extremely
difficult to maintain Gentoo systems without guru-level knowledge around
there. (Spoken as someone who still gets support emails from a couple of
previous positions.)
While I would like there to be a proper way to express repo-level
dependencies, properly announce deprecation and updates (e.g. to bash 4)
in advance as a feature integrated with the PM, and so on, I don't think
we should block our ability to move forward on these things. The
situation is essentially the same as it's always been, but our old
solution is no longer considered good enough and we don't have a new one
in place, so we're just sitting here.
Layout what you think it should be,
Layout of what, exactly?
how you think EAPI should be managed (what goes in, what doesn't,
etc),
If it can go in an eclass without strange contortions, put it there.
how derivatives should be handled,
With white gloves. More seriously, people making derivatives should have
maximal freedom to experiment, and I'm guessing most of them don't want
to deal with modifying 3 different PMs written at least partially in 3
different languages
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On 14:06 Fri 16 Sep , Zac Medico wrote: Bumping the EAPI of the root profiles/eapi file would be a different matter, since it applies to the whole repository. If you want to version bump that repository-level EAPI, then you need to wait until at least 6 months after supporting package managers have been available in stable. So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 now? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpT74nMsKtpS.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 13:43 Fri 16 Sep , Brian Harring wrote: What I said from the getgo and you're missing is that pushing EAPI implementation into the tree and ignoring EAPI, or having this notion that every repository must automatically use gentoo-x86 (pushing the format into the tree) is /wrong/; I'm not necessarily requiring that every repository must automatically use gentoo-x86 — just the ones that want to use features in an eclass distributed with gentoo-x86. It sounds to me like the logical consequence of what you're saying is that every useful function that's now or could eventually be in an eclass must instead be incorporated into EAPI. I guess I just don't see where you're drawing the line. What I'm suggesting is that we should add useful stuff to eclasses by default. If people want to use that stuff, they can stack on the gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to come into it at all. aside from meaning that the format definition can now *vary*, which is great for wasting dev time and screwing up compatibility, it opens up tweaking/customizing that functionality- aka, fragmentation/divergence. People doing that outside gentoo-x86 should do it the same way as ones within it, by bumping the eclass to a new unique name. Ideally one that's not just a numeric value so it won't conflict with ours, in the same way as EAPI naming. If we did the sort of thing you're basically pushing for, how long do you think it would be till funtoo added support for a new archive format to unpack? That's a *simple*, and *likely* example of how this can diverge. So, what I'm getting out of this is that we should make it harder for derivative distributions to innovate? Why should I care if they want to do stuff with new archive formats? Further, doing as you propose means we're flat out, shit out of luck /ever/ distributing a usable cache for standalone repositories. If they're bound to the changes of another repository, distributing a cache in parallel is pointless (and not doable in current form since metadata/cache lacks necessary eclass validation data for overlay inheritance). Not much different from other cross-repository dependencies; you have to keep everything in lockstep because who knows what other people will do with their repos. Maybe people would want to distribute their own copies of forked dependent repositories too, I haven't thought much about it. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgptazUS3EHSs.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 02:06 Fri 16 Sep , Brian Harring wrote: Specious argument; the point of controllable stacking was to avoid the issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds (which may not support those modified eclasses) via the old PORTDIR_OVERLAY behaviour. This is why multiple repositories have layout.conf master definitions- to explicitly mark that they require/consume a seperate repo. So let me get this straight — instead, you want overlay users to maintain a copy of every eclass they use, which will almost automatically become outdated and stale because it won't track the gentoo-x86 version? What you're basically proposing is a variation of the push format definitions into a central tree, and require everyone to use that central tree. This discussion has come and gone; I say that being one of the folks who was *pushing for the repository solution*. The problem there is it fundamentally enables (more forces) fragmentation. I think Gentoo will always provide one or a set of official central repositories, that's pretty much the definition of a distribution. So yes, I'm saying that generally useful stuff could go into one of these repositories, which (in the multi-repo case) could be like the eclass metaphor for repos; others would depend on it implicitly or explicitly. Realistically I assume you're taking the stance EAPI gets in the way, lets do away with it- if so, well, out with it, and I'll dredge up the old logs/complaints that lead to EAPI. I see EAPI as a nice thing for standardizing features that are implemented in the PM so they work identically across portage, pkgcore, and paludis. But I don't think that implementing things in the PM when they could go in an eclass is automatically the best choice. It dramatically slows down the speed of iteration, prototyping, and bug fixing. rephrase please; either you're saying everyone uses gentoo-x86 which is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk however which means things can get ugly for derivative repository usage), but still ignores the situations where people have overlays w/ developmental eclasses that they need to selectively control where it overrides (which is where the notion of repo stacking comes into play). I think I explained above, but let me know if that's not the case. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpQi7rzibDrE.pgp Description: PGP signature
Re: [gentoo-dev] x32 fun pants
On 15:34 Thu 15 Sep , Mike Frysinger wrote: ive converted my system over to x86/amd64/x32 multilib for funs. but i can see how some people wont want all three all the time. so the question is how we want to make this available to users at the release/profile level. background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. For anyone interested how the performance compares to amd64 in more comprehensive tests, check out the slides from the Linux Plumbers Conference (particularly 14-21): http://linuxplumbersconf.org/2011/ocw/proposals/531 In summary, on those benchmarks it looks like a small global win (maybe 5%) on integer calculations with a few huge wins of ≥25%, but a net loss around 5% pretty much globally for floating-point calculations. Most people probably do a lot more integer calculations unless they're science geeks like me, plus it should have lower memory use, so my understanding is that it probably makes sense to switch to x32 no matter what you're using now (x86 or amd64). Mike, would you agree? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp9K9W7gd3d2.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding a tiny install-mask directory list to gx86
On 11:36 Fri 16 Sep , Michał Górny wrote: The question is: where to store such a directory list? Keeping it inside project sources doesn't seem right as it would require me to bump and re-release project every time a directory is added. Keeping it in separate package which would need to be kept in sync doesn't seem too good either. That's why I'm considering including a tiny file in gx86 (and possibly other repositories) itself. Such a file could have a simple format and specify mappings of 'install-mask names' (similar to USE flag names) to lists of directories and possibly descriptions. Do something like layman or repoman where it auto-fetches periodically. Layman has the advantage of also supporting add-on files in addition to the main one. I don't want this in my repo. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp9tWKbxQw2E.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
On 21:53 Tue 13 Sep , Nirbheek Chauhan wrote: On Tue, Sep 13, 2011 at 8:43 PM, Dirkjan Ochtman d...@gentoo.org wrote: 2011/9/13 Michał Górny mgo...@gentoo.org: --- eclass/autotools-utils.eclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I don't think sending 9 patches is very useful for this mailing list. Next time just sent a link to a git repo or something? On the contrary, I like that mgorny sent separate completely independent patches for review to the list instead of either sending on huge chunk, or not sending patches at all. +1, except parts of them were dependent. =) Maybe use some `git rebase --interactive` next time.. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp3Hnb8ts55I.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 17:29 Wed 14 Sep , Brian Harring wrote: On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? There are more repositories than just gentoo-x86, and overlay is *not* the only configuration in use. Who else besides you is using any other configuration? Should we really give a crap about the 0.001% population with some weird setup when we're trying to improve things for the 99.999% one? In the old days of the PM only handling a single overlay stack, what you're suggesting would be less heinous- heinous in detail, but pragmatic in reality. These days it's a regressive approach- requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding eapi (resulting in people having to duplicate code into each repository stack). I don't know many people who aren't using gentoo-x86 or a repo that pulls in changes directly from it. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp6FhfQzVVid.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 19:14 Tue 13 Sep , Brian Harring wrote: On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Exactly the wrong approach; it winds up with master repositories/overlays cloning the functionality all over the damn place. Why are people cloning anything if it's in eutils.eclass in gentoo-x86? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpLbZB1u1CsQ.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 06:34 Wed 14 Sep , Ciaran McCreesh wrote: On Tue, 13 Sep 2011 21:02:28 -0500 Donnie Berkholz dberkh...@gentoo.org wrote: On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. Sticking it in an EAPI *shouldn't* be slow and more complex. There are three reasons why it is, and they should all be within Gentoo's ability to solve. [..reasons..] I'm glad we agree about its current state, whatever the reasons. While I wish I could do something about them, I can't at all in some cases or quickly in others. No matter what, it's going to be a slow process to change them, and I'd like to keep things like this from blocking on that. I'm hoping to fix some of the council-related issues with an updated GLEP 39 (WIP), but even being on the council doesn't help much in making others focus on productive issues. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpRPCNKacCwa.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On 06:39 Tue 13 Sep , Joshua Kinard wrote: On 09/13/2011 06:29, Michał Górny wrote: On Tue, 13 Sep 2011 12:21:31 +0200 Michał Górny mgo...@gentoo.org wrote: +# @FUNCTION: has_iuse Ideas for a better name will be appreciated. 'in_iuse' or 'iuse_contains'? I'd prefer to keep consistency with the parent function has(), so it's obvious exactly how it will work. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpA9WTwC02k1.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On 15:02 Tue 13 Sep , Amadeusz Żołnowski wrote: Excerpts from Joshua Kinard's message of 2011-09-13 14:26:02 +0200: You don't need -n/-z with [[. [[ $var ]] == [[ -n $var ]] [[ ! $var ]] == [[ -z $var ]] What about other comparisons, like -f, -e, or -d? Same as inside [, but no need of quotes inside [[. Also, is this a bash4-only thing, or bash3 and/or bash2 as well? I'm not sure. OT: When I was going through recruitment process, dberkholz pointed to me that I use things bash4-only. And again: why we need to stick to ancient 3 version? I would understand pseudo POSIX compatibility, but what is the benefit of bash3 compatibility while bash4 is stable already? It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp6rUsNsnKPn.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On 13:11 Tue 13 Sep , Michal Hrusecky wrote: # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ # @ECLASS: obs-download.eclass Are there going to be lots of packages using this and not the other eclass? I wonder whether there really need to be two of them. # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the downloading from obs. Could you tell us what obs is in the blurb too? I had no clue what this email was about (obs, osc, etc are meaningless to me) until I got down to the eclass description. # @ECLASS: obs-service.eclass # @MAINTAINER: # mi...@gentoo.org # @BLURB: Reduces code duplication in the obs services. # @DESCRIPTION: # This eclass makes it easier to package obs services. Based on provided # information it will all neede variables and takes care of installation. Lots of typos here. HOMEPAGE=http://en.opensuse.org/openSUSE:OSC; LICENSE=GPL-2 SLOT=0 IUSE= RDEPEND+=dev-util/osc You probably want a space here. RDEPEND+= dev-util/osc -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpkPf2od7LwK.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
On 17:58 Tue 13 Sep , Patrick Lauer wrote: On 09/13/11 16:44, Donnie Berkholz wrote: It's because people want to pretend that it's possible for incredibly outdated systems (those with bash-3 only) to be updated. Actually it's worse - PMS enforces this, and the only clean way out is to patch/fix/extend PMS to allow bash4 - but that breaks compatibility in silly ways. The proper way to handle that? I'm not sure, since we had a long fight to get PMS to acknowledge bash 3.2 instead of 3.0 I'm mostly ignoring PMS as it doesn't care about reality. Thanks for the reminder; I looked, and it turns out that we now have a great precedent. Quoting PMS: The required bash version was retroactively updated from 3.0 to 3.2 in November 2009 (see http://www.gentoo. org/proj/en/council/meeting-logs/20091109.txt). So we could just retroactively update it again and let people scream if they're actually affected by this. We're stuck in this limbo because we have apparently decided that just waiting a year, as we used to do, isn't good enough anymore; but at the same time, we don't have a better mechanism in place yet. So we're waffling around, doing nothing. That's not quite correct for this case, but it shows that we need to discuss destructive changes (in the sense that they are not backwards-compatible etc.) to have any decent progress Maybe a way to set tree-level dependencies/EAPIs/features is something we seriously need to get going on. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpdqwj5WnNHA.pgp Description: PGP signature
Re: [gentoo-dev] new `usex` helper
On 17:56 Tue 13 Sep , Mike Frysinger wrote: useful enough for EAPI ? or should i just stick it into eutils.eclass ? OR BOTH !? I prefer to avoid EAPI whenever possible, as it just makes things slower and more complex. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpi0BtNsnWIk.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.
On 21:57 Mon 12 Sep , Michał Górny wrote:
Right now, autotools-utils.eclass punts .la files only with
USE=-static-libs. We'd like to broaden the range of it and strip .la
files when they are not necessary for static linkage as well.
The following patch introduces an initial support for that. It assumes
that the .la file can be removed if the library is mentioned in any of
pkg-config files installed by the package, or if doesn't specify any
dependency libs nor linker flags.
If I understand correctly, this will break for any packages that don't
use pkg-config to link. The maintainers will manually need to add
pkg-config calls to the ebuilds of anything that could statically link
against a library using only libtool and not pkg-config. Is that
accurate?
It might be worthwhile to add an easy way to force this argument on for
every package for the purposes of testing, e.g. an environment variable.
# @FUNCTION: remove_libtool_files
-# @USAGE: [all|none]
+# @USAGE: [all|only-not-required|none]
Is there a way to document the arguments of eclass functions? You added
the name of the arg but didn't describe its purpose or why anyone would
want to use it.
On a semantic note, that argument name (only-not-required) doesn't make
sense to me. I might do something more helpful like pkgconfig-duplicates
instead.
+ if [[ $1 == 'only-not-required' ]]; then
This is way more quoting than you need within double brackets.
local f
for f in $(find ${D} -type f -name '*.la'); do
# Keep only .la files with shouldnotlink=yes - likely plugins
local shouldnotlink=$(sed -ne '/^shouldnotlink=yes$/p' ${f})
if [[ $1 == 'all' || -z ${shouldnotlink} ]]; then
+ if [[ $1 == 'only-not-required' ]]; then
Is there a case where one of those arguments might be $2 but you'd still
want to run this?
I feel like that shouldnotlink thing is really confusing the logic,
because there's multiple nested tests for different values of $1 in here
instead of just testing the args once at the top and setting variables.
+ # remove .la files only when .pc files provide
the libs
+ # already or they don't give any information
+ ! has $(basename ${f}) ${pc_libs} \
+ [[ -n $(sed -n \
The comment says or but I see an and here.
+ -e
s/^dependency_libs='\(.*\)'$/\1/p \
+ -e
s/^inherited_linker_flags='\(.*\)'$/\1/p \
+ ${f}) ]] \
+ continue
+ fi
+
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
pgpMghPH2v6CX.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.
On 00:46 Tue 13 Sep , Samuli Suominen wrote: If I understand correctly, this will break for any packages that don't use pkg-config to link. The maintainers will manually need to add pkg-config calls to the ebuilds of anything that could statically link against a library using only libtool and not pkg-config. Is that accurate? Yes, seems accurate. I can think of 'export PKG_CONFIG=$($(tc-getPKG_CONFIG) --static)' or something like 'export FOO_LIBS=$($(tc-getPKG_CONFIG) --libs --static foo)' to accomplish getting static flags from an ebuild using toolchain-funcs.eclass if required. Or they do it like lvm2 and cryptsetup at upstream level and add support for statically linking the tools in the build-system. The .la files are not helping packages not using libtool in any case, for example, those using cmake as build-system. And I've yet to see a real, in portage residing, example of where this would really break anything and when I will, I'll gladly help migrating it to the example mentioned above... Overall, corner cases that can be easily worked around, yet punting the *harmful* .la files. That's rather shocking. All it would take is trying to statically build a package not using pkg-config that links against anything X11-related (since all of them have .pc files). It's probably more that nobody cares about static building than that there aren't packages that would break. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgphwBqOBZT6Q.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools-utils.eclass: punt unnecessary .la files even w/ USE=static-libs.
On 23:58 Mon 12 Sep , Michał Górny wrote:
On Mon, 12 Sep 2011 16:00:20 -0500
Donnie Berkholz dberkh...@gentoo.org wrote:
local f
for f in $(find ${D} -type f -name '*.la'); do
# Keep only .la files with shouldnotlink=yes -
likely plugins local shouldnotlink=$(sed -ne
'/^shouldnotlink=yes$/p' ${f}) if [[ $1 == 'all' || -z
${shouldnotlink} ]]; then
+ if [[ $1 == 'only-not-required' ]]; then
Is there a case where one of those arguments might be $2 but you'd
still want to run this?
Er? What are you referring to?
Two things.
1. This is only reached if shouldnotlink is false. That means it's only
the things that you are already assuming are plugins, right? If so, why
is this even done?
2. What happens if I call it with `remove_libtool_files all
only-not-required`? Nobody ever does any checking of the # of args.
I feel like that shouldnotlink thing is really confusing the logic,
because there's multiple nested tests for different values of $1 in
here instead of just testing the args once at the top and setting
variables.
As mentioned earlier, the code needs to be refactored. First things
first, then we'll rewrite it to be nice and clean. I don't really want
to waste time doing this if we would need to rewrite it for more logic
in the future.
I'd rewrite it once as soon as you get all the reviews and before
committing. Rewrites tend to never happen, since it turns out that
people have other things to do with their time.
+ # remove .la files only when .pc
files provide the libs
+ # already or they don't give any
information
+ ! has $(basename ${f})
${pc_libs} \
+ [[ -n $(sed -n
\
The comment says or but I see an and here.
Because everything's negated here. Boolean magic :D.
OK, got it. Stop writing confusing logic. =P
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
pgprcOSPCGwcn.pgp
Description: PGP signature
Re: [gentoo-dev] RFC: devqawarn()?
On 14:44 Thu 01 Sep , Petteri Räty wrote: One thing to note is that we should get eqawarn into the next EAPI. Why? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpC80OrHx438.pgp Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
On 15:20 Thu 01 Sep , Tomáš Chvátal wrote: Dne 1.9.2011 15:15, Michał Górny napsal(a): We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. As even if you fix main tree you can't ensure that you won't mess with some overlay (silently as it would not be seen by default). I would then go proactively and fix the packages inheriting the bashcomp eclass and when done just mark the eclass as dead. Yes, please stop breaking backwards compat without version bumps to a new eclass. It's just as annoying in an eclass as in a shared library. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpe4A1WUfHEv.pgp Description: PGP signature
Re: [gentoo-dev] mesa r600 gallium news item
On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote: Existing users will not be switched automatically. Why not? If it's considered the supported route going forward, we should just do it automatically. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgphL8deYJFG4.pgp Description: PGP signature
Re: [gentoo-dev] mesa r600 gallium news item
On 17:51 Wed 31 Aug , Chí-Thanh Christopher Nguyễn wrote: Donnie Berkholz schrieb: On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote: Existing users will not be switched automatically. Why not? If it's considered the supported route going forward, we should just do it automatically. Some users might be using UMS instead of KMS still, which would break 3D acceleration once they are switched to gallium. So migrate them. =) -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpyZdTbs8Ifi.pgp Description: PGP signature
Re: [gentoo-dev] Gentoostats, SoC 2011
On 03:18 Fri 26 Aug , Jorge Manuel B. S. Vicetto wrote: I've picked this message as I want to address one point in this thread that was focused on this sub-thread. I disagree with the idea that adding an application to the Gentoo tree that collects data from users and sends it to a central (or distributed) system is the same as adding any other application to the tree. Having the ability to add ebuilds to the tree is part of what you gain by getting gentoo-x86 access. Issues with significant users privacy concerns and substantial changes like adding packages to the tree that collect data from users and compile it, Like, oh, any package with a built-in bug reporting system? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgplaqzIBXO04.pgp Description: PGP signature
Re: [gentoo-dev] Implicit system dependencies
On 19:08 Tue 23 Aug , Maciej Mrozowski wrote: On Tuesday 23 of August 2011 18:54:04 Paweł Hajdan, Jr. wrote: On 8/22/11 12:21 PM, Michael wrote: I wrote a script to search for discrepancies between linked libraries and what's defined in (R)DEPEND, with the intention of improving QA for minimal package installs. It would be great to integrate this into portage and make it a part of the developer profile. This would just help prevent future breakages. It seems there are a couple of such home-grown solutions already. dberkholz used to have on in his dev webspace[1], we have one[2] in kde overlay... 1. http://dev.gentoo.org/~dberkholz/scripts/ (linking_libs, included_headers) 2. http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation/maintainers;hb=master (dynlink_scanner + try_dlopen.c) Also we've got a couple of really cool GSoC projects along these lines. One is called autodep [1, 2], and it integrates into portage to let you know if you're missing deps or specified too many deps. The other one is an ebuild generator [3, 4] that works for autotools but not a lot else at this point. 1. http://archives.gentoo.org/gentoo-soc/msg_7491f6b5bffdccaedc939beb6e1c4f0d.xml 2. http://dev.gentoo.org/~neurogeek/guidexml/ (temporary homepage) 3. http://archives.gentoo.org/gentoo-soc/msg_e29529cb6f3dfc762f4f7e313b106deb.xml 4. http://soc.dev.gentoo.org/~darkdefender/ebuildgenerator -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp441wcSLJ6h.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposal: ban mirror://gentoo/ from ebuilds
On 17:41 Thu 18 Aug , Roy Bamford wrote: Just as long as we can provide the patch sets for a period of at least three years, in case someone asks. Thats a GPL requirement. Just to be clear, it's only a requirement if you're going with the written offer to provide source clause rather than the providing source at the same time as binary clause (i.e., 3b rather than 3a in GPL-2). -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpKNPzYQVAdA.pgp Description: PGP signature
Re: [gentoo-dev] USE=introspection has been unmasked in the tree
On 21:23 Tue 16 Aug , Nirbheek Chauhan wrote: A side-note that we've wanted to get out to all devs is that everyone should *always* use IUSE=+introspection. Then why is it a flag? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpuI4oupoiUE.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
On 20:55 Sat 06 Aug , Robin H. Johnson wrote: Everything you have mentioned here was previously covered in the discussions about Git conversion models. Please consult the history of this list, as well as the -scm list. Additionally, a large discussion about the pros and cons of all 3 models (package per repo, category per repo, single repo) was had at the GSoC mentor summit last year, and a number of the core Git developers were involved in the discussion. While noting the above [1 and its thread], I'd also like to point out that git submodules are conceptually a good fit but the implementation is lacking. Two examples: - Creating new submodules requires administrative rights on the server. You can't just add one and push it up. This could conceivably be fixed by a hook that ran a specific privileged command to add a submodule, but I'm not really sure how or whether it's currently possible given the times available to run hooks. - What we'd really want with submodules is to have the primary object storage shared in the master repo rather than in the submodule. That way we'd benefit from compression across packages, and furthmore, package moves wouldn't duplicate history. If you're interested in fixing the above problems as well as the ones that exist regardless of repo format (linked on the main tracker bug [2]), then submodules could become a better option. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com 1. http://archives.gentoo.org/gentoo-scm/msg_98932c55ec10fcc5445ab950e62b12dc.xml 2. https://bugs.gentoo.org/show_bug.cgi?id=333531 pgp7n15SHaMHz.pgp Description: PGP signature
Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)
On 09:39 Wed 27 Jul , Michał Górny wrote: As many of us already raged, the Python eclasses are delaying half a year with support of EAPI=4. The reason for that is not actually the lack of time or complexity of needed changes but willingness to use the new EAPI as an excuse to turn the eclass API upside down. The question I'm raising here: should eclasses be actually allowed to do *heavy* changes in their APIs in such cases? Or should the eclass maintainers create a new eclass instead (python-r1.eclass or so)? Eclasses still shouldn't break backwards compatibility — that hasn't changed in the past 5 years, despite what a very small minority of devs appears to think. This has been a huge PITA for python.eclass in particular, which has broken tons of my ebuilds for no particular reason. (And no, a 30-day warning is not an excuse for breaking anything.) If you need to edit an eclass for EAPI/API changes anyway, updating the inherit line to python-2 instead of python isn't a big deal. In the general sense, I think changing the API in arbitrary ways based on the EAPI in use is just plain confusing, and it should go into a new version-bumped eclass instead. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpgLBfaNeoHa.pgp Description: PGP signature
Re: [gentoo-dev] net-misc/pimd RFC for new ebuild
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
W dniu 17.07.2011 10:45, Kfir Lavi pisze:
src_compile() {
emake CC=$(tc-getCC) || die
}
Some systems export CC as gcc -m64.
I guess I'm a little confused here. What exactly is the problem and fix
you're proposing? You stopped halfway through, there should've been a
part at the end that said:
, so you need to do XX to avoid YY from happening.
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
pgpJjW4Wm54GR.pgp
Description: PGP signature
Re: [gentoo-dev] net-misc/pimd RFC for new ebuild
On 14:40 Tue 19 Jul , Mike Frysinger wrote:
On Tue, Jul 19, 2011 at 14:32, Kacper Kowalik wrote:
W dniu 19.07.2011 19:31, Donnie Berkholz pisze:
On 11:43 Sun 17 Jul , Kacper Kowalik wrote:
W dniu 17.07.2011 10:45, Kfir Lavi pisze:
src_compile() {
emake CC=$(tc-getCC) || die
}
Some systems export CC as gcc -m64.
I guess I'm a little confused here. What exactly is the problem and fix
you're proposing? You stopped halfway through, there should've been a
part at the end that said:
, so you need to do XX to avoid YY from happening.
Use quotes: CC=$(tc-getCC). Without it you could get emake CC=gcc -m64
and that would of course fail.
CC=gcc -m64 is a fairly questionable setting in the first place
(you're most likely doing something wrong/stupid already), but quoting
the CC arg on the cmdline as suggested is the right thing.
Ah, yeah, I was forgetting that an extra level of quoting is required
for that use. Weren't we just saying that `VAR=foo emake` would be
better than `emake VAR=foo`, though, to avoid screwing up packages that
mangle those variables? And in that case I don't think it would need
quotes.
--
Thanks,
Donnie
Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
pgpiK3wMnJHFS.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On 11:26 Fri 01 Jul , Nirbheek Chauhan wrote: Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. In my experience, updates become massively difficult after about 6 months unless you have deep expertise in Gentoo. You run into blocker after blocker after USE-flag problem after resolution failure and an ongoing series of confusing messages with no apparent end in sight. We may call it supported (and technically, we're right) but it isn't realistically possible for most users. After handing over administration of about 10 systems to someone else with less experience in Gentoo, I still get called in about once every couple of months to help every time one of these weird problems comes up. I recommended upgrades to the new admin every 3 months, which is a point where nearly everything still works cleanly. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpbxhlF9Fgwu.pgp Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On 14:38 Tue 28 Jun , Peter Volkov wrote: 1. add a use flag to control runtime dependency 2. add elog message into pkg_postinst to notify users that some features depend on installing package A, B, etc. I've got a suggestion that builds a little bit on what both you and Ciaran have said. The UI could probably be clearer if we added a new dependency type like SDEPEND (suggested deps) with USE flags for different features. That would enable portage to show things in a special way if it knew about SDEPEND. Yet it wouldn't do anything weird that broke backwards compatibility or produced strange output from noncompliant PMs (like USE flag modifications). Then PMs would be free to implement their own logic for how to handle it. For Portage, I'd like to see a few cases: 1) If a package is installed, assume it's desired, as Ciaran proposed. 2) Add a way to determine whether to install all/none/groups of them, w/ configuration in /etc/portage/package.suggestions/. Probably CPV followed by the setting (all, none, specific groups, or specific CPVs). Add an option similar to --autounmask that would let Portage write to this file. 3) Something like the --take argument and friends that Ciaran mentioned seems reasonable (perhaps --accept-suggestion, w/ a short option to save typing). Problems? Other thoughts? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpEUroOHMuW9.pgp Description: PGP signature
Re: [gentoo-dev] Don't use / when applying sed with CFLAGS
On 17:23 Mon 27 Jun , Lars Wendler wrote: Am Montag 27 Juni 2011, 17:01:01 schrieb Fabian Groffen: On 27-06-2011 14:08:52 +, Justin Lecher wrote: Please do not use / as seperater when using sed with CFLAGS. I came across a bug today where it failed for crossdev. Here the toolchain header paths in the cflags and consowuently the seds fail. Please also don't use ':' as separator, as some platforms have options for their toolchain that includes colons. Rather than telling us what to _not_ use as separator how about suggesting a list of konwn to be good separators for such cases. How about the @ character? One of my favorites for weird cases is ~. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpaaKjqoCZiQ.pgp Description: PGP signature
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
On 16:27 Tue 14 Jun , Brian Harring wrote: On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote: And no, I don't think that Gentoo should fully support reduced-@system builds, but there is no harm in making them more of a viable option. Personally... I think gentoo should aim for it actually. Question is how close we can get to it w/out overly burdening developers. Where this has been most useful for me is when I'm building out a minimal system (e.g., a diskless terminal or cluster node) using ROOT=/somewhere/else. It's nice to just start emerging stuff there instead of having to unpack a stage1 or something first. I wonder if we need another set that's really @base (truly minimal, like what Mike posted elsewhere), so @system would then serve as what we think is necessary for a running Gentoo installation. On a related note that would accomplish similar purposes, it would also be nice if we could somehow discriminate between DEPEND and RDEPEND for @system packages so build-only deps could be removed. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpPUQh7quVSd.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011
On 17:19 Wed 08 Jun , Paweł Hajdan, Jr. wrote: On 6/8/11 4:36 PM, Vikraman wrote: I'm working on the `Package statistics` project this year. Till now, I have managed to write a client and server[0] to collect the following information from hosts: Excellent, good luck with the idea! I think that better information about how Gentoo is actually used will greatly help improving it. Is there a need to collect files installed by a package ? Doesn't PFL[1] already provide that ? Well, PFL is not an official Gentoo project. It might be useful, but I wouldn't say it's a priority. I would love to see it happen, but it's more important to roll out a minimal working solution now and add on later. By combining installed files with USE flag settings, this project could actually attempt to factor out which USE flags result in which files in an automatic fashion. That would address one of the biggest objections many people have had to such a package-to-file search engine. It would also be pretty useful for some other GSoC projects, like the ebuild generator and the auto dependency scanner. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgp99ZuhwbiGQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: an eclass for github snapshots?
On 13:21 Mon 30 May , Ulrich Mueller wrote:
On Mon, 30 May 2011, Diego Elio Pettenò wrote:
Il giorno lun, 30/05/2011 alle 08.27 +0200, Michał Górny ha scritto:
S=${WORKDIR}/solutious-${PN}-*
I'm surprised if that actually works. I'd say that seems not
PMS-compliant but in fact PMS seems to almost not mention S.
Because you didn't follow the whole eclass tree ;)
ruby-ng handles the star as a special case, given how many of those
we had to use over time, [...]
But it is not compliant with PMS:
If S is assigned in the global scope of an ebuild, then the
restrictions of section 12.2 for global variables apply. (section 12.1)
Global variables must only contain invariant values. (section 12.2)
It seems compliant to me, as S is assigned an invariant value that
happens to contain the character '*', which is overwritten with a new
value as a local variable in ebuild functions. Sample code in listing
12.1 in my copy of the PMS seems to suggest this is perfectly fine
behavior as long as the global invariant is restored after each
function.
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com
pgpm4QVAvdoo9.pgp
Description: PGP signature
[gentoo-dev] Web-design help request
Hi all, If anyone with web-design skills could help out on some improvements to our website, please get in touch with me off-list or on IRC in #gentoo-pr. One of this year's GSoC students (tampakrap) will be rewriting a bunch of the backend website code, which is a great opportunity for us to also fix some of the frontend usability issues. -- Thanks, Donnie Donnie Berkholz Team lead, public relations Gentoo Linux Blog: http://dberkholz.com pgpfcuG38Min8.pgp Description: PGP signature
Re: [gentoo-dev] RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
On 15:05 Wed 27 Apr , Samuli Suominen wrote: The way of setting default URI handlers has changed since dev-libs/glib-2.28 and above. If you used the GConf registry to set them before, they will now be ignored. Do you think all our users will even understand what this means? Can you provide a more plain-English explanation, and give specific examples? For example: The method for setting default applications for specific URI types (https://, mailto://, etc.) changed in dev-libs/glib-2.28 and newer. If you previously set them in GConf using the Configuration Editor, they will now be ignored. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpLMYrMOIz33.pgp Description: PGP signature
Re: [gentoo-dev] openrc portage news item
On 13:32 Thu 14 Apr , Kfir Lavi wrote: When i run world update, I usually don't really check all the written stuff. If I do this, I'm sure a lot more Gentoo users do the same. So do expect people rebooting the machine without checking what your have wrote. This can be a major headache if you have few systems that are doing auto updates. I would solve this issue by stopping the emerge and getting the attention of the user. If I don't get the attention of the user, no openrc will be installed. It should be something like emerge -C ... 1 .2 3 4 5... To conclude, you can't issue such a change without proper confirmation from the user. I know this is the case. You're going to get literally thousands of people (or more) who break their Gentoo systems if that indeed is the consequence of not reading the migration guide and doing some action. From a glance over the guide, it wasn't immediately obvious what in there would result in a broken system. Perhaps it's the run dispatch-conf that's buried in the middle of a paragraph without enough emphasis? That's particularly confusing for people who use etc-update instead, and it *needs* to move somewhere more obvious like a separate code listing with big important tags and bold text. The line of red text just isn't enough, it needs to stand out even more. It seems like nobody's really clear on what exactly happens though, since I've seen people talking about this *maybe* resulting in an unbootable system. Has anyone tested it? One potential cleaner approach to the same idea Kfir suggested is to make it an interactive emerge with an ACCEPT_LICENSE-like feature that pops up something you must read and agree to. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpNuizXUZtxY.pgp Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On 06:29 Sat 16 Apr , Corentin Chary wrote: New website is up and running at http://euscan.iksaif.net/ The git tree is still at http://git.iksaif.net/?p=euscan.git;a=summary TODO: - Make some charts to see how it's going - Finish the scan my world feature - Add a way to subsribe to herds/maintainer/packages in order to receive weekly/monthly reports I'll gladly accept any patch ! :) This is cool! I just looked through the x11-team packages and it seems very useful already. I have a few suggestions if you have time. =) - Some teams have official overlays. Supporting those as an additional source of ebuilds would be pretty nice. - Another useful thing would be a way to supply CPV tokens for any unstable upstream series that we'll never add to the tree. - This looks like a problem (a versioned tarball named cairo-5c): http://euscan.iksaif.net/package/x11-libs/cairo/ -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpKu9VoK0Qtd.pgp Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On 15:48 Mon 18 Apr , Corentin Chary wrote: On Mon, Apr 18, 2011 at 3:32 PM, Donnie Berkholz dberkh...@gentoo.org wrote: - Some teams have official overlays. Supporting those as an additional source of ebuilds would be pretty nice. I'll just checkout these trees on my machine (and only enable them for euscan). euscan use portage, gentoolkit and eix internaly, so overlays are not a problem :). Where could I get a list of official overlays that should be added ? It will be a little tricky to get this perfect automatically. I would start with anything in the layman repository file [1] that has repo ... status=official and owner type=project. 1. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/overlays/repositories.xml?view=log -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgp6LKmU7A8XS.pgp Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On 15:48 Mon 18 Apr , Corentin Chary wrote: On Mon, Apr 18, 2011 at 3:32 PM, Donnie Berkholz dberkh...@gentoo.org wrote: - Another useful thing would be a way to supply CPV tokens for any unstable upstream series that we'll never add to the tree. There is already some kind of blacklist in euscan. Could you provide examples so I can implement that ? Sorry, forgot about this bit. I'm just talking about standard package tokens, the same kind used in package.mask or wherever: =x11-drivers/xf86-video-intel-2.14.90* =x11-base/xorg-server-1.10.900 etc. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgplh0Kf14xcm.pgp Description: PGP signature
Re: [gentoo-dev] openrc-0.8.1 stable candidate
On 13:44 Wed 13 Apr , Marijn wrote: I would be very interested in seeing some kind of list/review of all the advantages of the new system. Idea for the Newsletter? We should certainly get a news item together, since this is a huge deal for Gentoo. Although no doubt non-Gentoo people will start laughing at yet another new init system. =) If there's a guide around already, or a blog post, or you want to draft something, let me know and I'd be happy to polish it up. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpWOkaWzEnHI.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 02:39 Mon 28 Mar , Nirbheek Chauhan wrote: Where did this come from? My entire argument was based around the fact that unmaintained packages that may or may not be broken fundamentally constitute a *bad* experience for the user. If we cannot guarantee that bugs for a package will be fixed, we should not take up the responsibility of the package! Which is worse? Suddenly pulling a package from underneath the feet of users when it inevitably breaks or telling them upfront that it's *completely not* supported by us so they can do something about it before it breaks? Here's the key point: may or may not. Arbitrary criteria with no relevance to whether a package works for users are not helpful. The mere existence of a maintainer-needed package doesn't mean it should be removed. The existence of the same thing with numerous serious, unfixed bugs or tinderbox errors means something much different. We have the ability to do these kinds of intersections today, since our wonderful bug wranglers normally insert the $CAT/$PN into summaries and Diego has tinderbox bugs filed. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpjZzeJgz4hc.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On 17:34 Sun 27 Mar , Ryan Hill wrote: On Mon, 28 Mar 2011 02:55:14 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: If we launch gstats *today*, it'll take us at least a long time before we get decent numbers, and even after that, those numbers will be biased towards those people who are really active in following Gentoo news and developments. Unlike Firefox's usage stats, we have no way of prompting pre-existing gentoo installations with a Do want to take part in gstats? question. Last I checked we had a nifty news system for making announcements. And I thought we were supposed to have Smolt support like two years ago. What happened to it? I wonder the same question too, since it seems statistics is an eternally returning GSoC project. Sebastian, you worked on this in 2009. What needs to happen to get it deployed? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpxww8cShQhy.pgp Description: PGP signature
Re: [gentoo-dev] mono.eclass EAPI3(/4)
On 23:48 Thu 24 Mar , Christoph Mende wrote:
Index: mono.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mono.eclass,v
retrieving revision 1.13
diff -u -b -B -r1.13 mono.eclass
--- mono.eclass 8 Mar 2009 15:46:54 - 1.13
+++ mono.eclass 24 Mar 2011 22:47:08 -
@@ -35,24 +35,26 @@
unset MONO_AOT_CACHE
egacinstall() {
+ [[ -z ${ED+set} ]] local ED=${D%/}${EPREFIX}/
gacutil -i ${1} \
- -root ${D}/usr/$(get_libdir) \
+ -root ${ED}/usr/$(get_libdir) \
-gacdir /usr/$(get_libdir) \
-package ${2:-${GACPN:-${PN}}} \
|| die installing ${1} into the Global Assembly Cache failed
}
mono_multilib_comply() {
+ [[ -z ${ED+set} ]] local ED=${D%/}${EPREFIX}/
local dir finddirs=() mv_command=${mv_command:-mv}
- if [[ -d ${D}/usr/lib $(get_libdir) != lib ]]
+ if [[ -d ${ED}/usr/lib $(get_libdir) != lib ]]
No need for quotes when expanding variables or functions inside [[ ]].
That holds true for the rest of the diff, too. I'd also split this (and
a later find call) into two separate conditionals, with just one test
per [[ ]].
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com
pgp15BGErOV6U.pgp
Description: PGP signature
Re: [gentoo-dev] Re: git-2.eclass final review
On 10:44 Wed 23 Mar , James Cloos wrote: TC So live with it. I cannot. It makes the eclass useless. I have almost 2 gigs of bare repo in distdirs/git-src. A forced re-download of all of that is just not possible! The existing distdir clones *MUST* continue to work. My applogies for not having looked for this kind of breakage in the new eclass before now. The current git eclass finally got the submodules- vs-normal stuff worked out some time ago; the possibility of going backwards never occurred to me ☹ As someone who makes heavy use of live ebuilds, someone who will be directly and severely affected by such a change, I have to beg you to keep the current logic for submodule-less repos. I was discussing a couple of ideas on IRC with scarabeus yesterday but haven't had a chance to look into them in more detail yet: - Providing automatic migration from the old system to the new. This is the simplest approach to deal with your specific problem but still leaves separate codepaths for submodule and non-submodule repos. - Handling submodules in bare checkouts. Perhaps we could detect whether submodules are in use (need to find the right place/way in git), then grab them as separate bare checkouts that would eventually be cloned into TMPDIR by changing the repo location git looks for (again, need to sort out how in git). -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpQLdlUg2rXh.pgp Description: PGP signature
Re: [gentoo-dev] virtual/ffmpeg and media-video/libav
On 11:10 Wed 23 Mar , Mike Frysinger wrote: On Wed, Mar 23, 2011 at 11:01 AM, Jeremy Olexa wrote: When reading about the fork awhile back, I assumed that ffmpeg would die and libav would continue in its place. Do we really need a virtual for this?? might as well hedge our bets. it'd really suck if we threw all our eggs into libav just to have to crash, or for it to move back to ffmpeg. Indeed, this is the same thing we did back in the XFree86/X.Org split. I think x11-base/xfree stuck around for another year or so before we decided it was definitely a zombie and burned it to a crisp. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpKRB5nyAlw6.pgp Description: PGP signature
Re: [gentoo-dev] Re: git-2.eclass final review
On 08:28 Wed 23 Mar , James Cloos wrote: MF == Mike Frysinger vap...@gentoo.org writes: MF ideally, the git eclass should be creating bare checkouts only in its MF store dir, in which case it could use `git archive | tar` to move MF things over ... Or better yet, git clone. This could work well with --shared; even worked for me on separate partitions. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpXPp3orTeuv.pgp Description: PGP signature
Re: [gentoo-dev] Eclass review: xorg-2 virtualx
On 00:18 Tue 22 Feb , Tomáš Chvátal wrote:
+ if grep -q -s disable-all-encodings
${ECONF_SOURCE:-.}/configure; then
+ FONT_OPTIONS+=
+ --disable-all-encodings
+ else
+ FONT_OPTIONS+=
+ --disable-iso8859-2
+ --disable-iso8859-3
+ --disable-iso8859-4
+ --disable-iso8859-5
+ --disable-iso8859-6
+ --disable-iso8859-7
+ --disable-iso8859-8
+ --disable-iso8859-9
+ --disable-iso8859-10
+ --disable-iso8859-11
+ --disable-iso8859-12
+ --disable-iso8859-13
+ --disable-iso8859-14
+ --disable-iso8859-15
+ --disable-iso8859-16
+ --disable-jisx0201
+ --disable-koi8-r
+ fi
Any chance we can just clean out the fonts that still use the old way
and delete most of this?
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com
pgpV233MzoVf4.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Quantity of open bugs
On 15:45 Sat 12 Mar , Diego Elio Pettenò wrote: I actually use the fact that these are still open to judge whether a package has to be removed from the tree, closing them would definitely be a bad idea for two reasons: I'm assuming you're talking only about broken builds here and not QA-only bugs. My opinion is that if a tinderbox QA script is the only thing finding a nonfatal bug, and it's never reported or CC'd by a user, then it's about as low priority as you can get. So this might serve as a pointer to potentially unmaintained packages, but clearly more investigation is required before removal. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpXlUAj6ZLsw.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla 4 migration
On 07:50 Tue 08 Mar , Hans de Graaff wrote: On Mon, 2011-03-07 at 08:13 -0600, Donnie Berkholz wrote: Thanks! One thing I've been very interested about in 3.x and 4.x is API access that's better than screen-scraping. I tried using the python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't seem to work. Do we have anything available? I've tried an ipad application that uses xmlrpc and that seemed to work fine. Confirmed with my iphone one. Guess the Python one's broken with BZ 4. Fiddling around manually with xmlrpclib works alright, too. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpN0Hq8SDQ9s.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla 4 migration
On 09:51 Mon 07 Mar , Robin H. Johnson wrote: The Gentoo for the Bugzilla service went perfectly, a huge thanks to idl0r for the years of work he has put into them. Thanks! One thing I've been very interested about in 3.x and 4.x is API access that's better than screen-scraping. I tried using the python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't seem to work. Do we have anything available? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpThu2dFRGyd.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla 4 migration
On 16:35 Mon 07 Mar , Dirkjan Ochtman wrote: On Mon, Mar 7, 2011 at 15:13, Donnie Berkholz dberkh...@gentoo.org wrote: Thanks! One thing I've been very interested about in 3.x and 4.x is API access that's better than screen-scraping. I tried using the python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't seem to work. Do we have anything available? Is that the one you get if you emerge pybugz? No, pybugz is a screen-scraper. We previously had Bugzilla 2 so we couldn't do anything else. The Mozilla guys made a pretty nice REST API that can be installed as a plugin, I think. Maybe we could run that? I've been somewhat following that too, but I don't know if anyone's written a CLI client for it yet, whereas python-bugzilla already exists (and has an ebuild in the sabayon overlay). -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpXcCnIenCNR.pgp Description: PGP signature
Re: [gentoo-dev] Rewrite java-config in C++ or python
On 20:40 Sat 26 Feb , Petteri Räty wrote: On 02/26/2011 07:08 PM, Daniel Pielmeier wrote: 2011/2/21 Uditha Galgamuwa nandun8...@gmail.com: Hi dev, I am Uditha Galgamuwa from university of moratuwa,Sri Lanka.I am interested in the project idea Rewrite java-config in C++ or python which was in last year Gsoc.As I saw this project has not been implemented in Gsoc 2010.Will this be available for this year's idea list from Gentoo foundation? I have good knowledge on programming with java and some knowledge on C++ and a basic understanding about XSLT as well. It is on the list for 2011 (1), so I guess you can apply for it. (1) http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas The list started out with a copy of ideas from last year that were not finished successfully. That is partially correct but incomplete. Many of them were never even started — just a few were started but not finished. (We had 3 out of 19 students fail, which is about the same level as the broader GSoC program). This means no-one might be interested in mentoring for the projects listed there this year. It should also be remembered that you don't need to restrict yourself to the ideas presented there. For any further discussion I suggest reading the Read this first section and noticing that there is a gentoo-soc mailing list. Indeed, please do join the mailing list! We strongly encourage novel ideas beyond what's on the ideas list, but make sure to discuss them in advance of applying so you find a mentor. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgphB5rIWJQox.pgp Description: PGP signature
Re: [gentoo-dev] gtk 3 preparation work
On 11:13 Sun 27 Feb , Gilles Dartiguelongue wrote: a quick mail to announce that the gnome team, in order to prepare for gnome 3, started slotting a lot of gnome team managed packages. If you find yourself using such a package, please update your ebuilds to use slot notations or other EAPI compliant notation resulting in the same effect. This email would be much more useful if it included a list of affected packages, sorted by maintainer and/or herd. I'm sure that list is pretty huge right now, so if people don't act on this soon, perhaps your next email could have such a list. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpus2FkMRYo4.pgp Description: PGP signature
