Re: [gentoo-dev] Removing a blocker from a stable package
On Mon, 13 Oct 2014 14:02:55 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 10/13/14 12:58, Michael Orlitzky wrote: I've got two obsolete packages masked currently: app-text/unix2dos and app-doc/djbdns-man. Both of them block other stable packages, app-text/dos2unix and net-dns/djbdns respectively. Fortunately, both of them have had version/revision bumps since the blocker so we can remove the blocker from the newer ebuild and then stabilize that, at which point there's no problem. But I wonder, what would be the best way to handle the situation if no version/revision bump had occurred? In other words, suppose that net-dns/djbdns-1.05-r30 didn't exist. In -r29, I have, KEYWORDS=alpha amd64 hppa ~mips ppc ppc64 sparc x86 DEPEND=!app-doc/djbdns-man and app-doc/djbdns-man is now hard masked. Suppose I remove djbdns-man from the tree -- what do I do about the blocker? I see a couple of options: a) Edit the stable ebuild with ones fingers crossed b) Do a revbump and wait it out c) Do a revbump and file a stablereq immediately d) Do nothing, will repoman tolerate that? (b) is obviously safest, but (c) seems reasonable as well all things considered. Will the answer change when portage drops dynamic deps? You might be okay with rev bumping then then stabilizing yourself on the arches since the package has been already tested on them. The rev bump doesn't change any files on the system but just gets past the blocker. I don't want to speak for all arch teams, but I would be okay with that on the arches I take care of: arm, ppc, ppc64. In other words, go with C and do the stablereq yourself. The only right answer is d), carrying the block over to future versions for some time might even be appropriate.
Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
On Tue, 1 Apr 2014 15:31:56 -0700 Tim Harder radher...@gentoo.org wrote: Currently the java-utils-2 eclass refers to $DESTTREE in the java-pkg_init_paths_ function that gets run during pkg_setup (via the java-pkg-2 eclass that calls java-pkg_init). The java-pkg_init_paths_ function also gets called again for most src_install java-utils-2 eclass functions that use the related variables but the current implementation doesn't allow the variables to be reset. This is an issue for pkg managers that try to follow the spec and don't define DESTTREE outside of src_install. Note that DESTTREE was recently added to pms so you'll probably have to view the live version to see the DESTTREE related info. The attached patch fixes the situation by adding java-pkg_init_paths_ calls to a couple src_install related functions that use the related variables and removes the call to it during pkg_setup (no related variables appear to be used before src_install but I could be missing something). People familiar with various java pkgs should test it to make sure those variables aren't used before src_install. Thoughts or comments welcome, Tim Tim, java-utils-2 does it like that since before PMS, since around the time Portage gained support for EAPIs. PMS leaves it open whether using DESTREE in pkg_setup is allowed or not. Neither Portage, Paludis nor earlier version of Pkgcore did mind this use. Well, one could argue that using DESTREE in pkg_setup is allowed. I would welcome PMS clearly defining the scope of DESTREE and the most logical choice of course would be src_install only where it is currently explicitly required. If we fix java-utils-2 we should fix PMS as well. After all, java-utils-2 is a prime suspect for the different handling of DESTREE and for instance INSDESTREE in PMS. This asymmetry is why I didn't touch java-utils-2 when I looked into exactly this usage of DESTREE 2+ years ago. Ralph signature.asc Description: PGP signature
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
On Tue, 28 May 2013 17:15:40 -0500 William Hubbs willi...@gentoo.org wrote: On Tue, May 28, 2013 at 09:07:37PM +0200, Michał Górny wrote: For the others, how large is the benefit of having them switchable? At least some of them look like something that wouldn't hurt people if it was always-built. The dev manual states that use flags are to control optional dependencies and _settings_ which a user may reasonably want to select [1]. William, each time this comes up you overred the _reasonably_. Controlling dependencies is always reasonable but beyond that it's case by case. Just because you can is never a valid reason. Often there are options you clearly only want to toggle if you are a developer or options meant for porting to alternative operating systems which lack some bells and whistles and the like. Another example is configuring a library for bundling with an app. The world is bigger than linux distros. Since the developer gives us the ability to control this with configure switches, I feel pretty strongly that we should give the user that control. Useless options within the given context are an usability issue and those who want to toggle stuff for it's own sake still have EXTRA_ECONF. Ralph William [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html signature.asc Description: PGP signature
Re: [gentoo-dev] Re: devmanual moved to github
On Mon, 13 May 2013 00:24:09 +0200 Alexander Berntsen alexan...@plaimi.net wrote: On 13/05/13 00:21, Peter Stuge wrote: There is no problem if github is only used for hosting, but if it is the primary point of contact, or if pull requests are accepted, then github is also writing to repositories, and merge commits are enforced for all external contributions. That does not scale at all. Users can still send patches via email even if the project is hosted on GitHub. And for the record I have not had problems with messy merges when commiting pull requests. Once I was asked if I could look into a package. I spent a day writing a couple of ebuilds including fixing the build system of the target package. When I presented a first git-format-patch I was ask to do a github pull request instead. So I asked why not git-am? The answer was - don't be a *beep*. As a result the package never got fixed and I outright ignore any repo not hosted on Gentoo infra.
Re: [gentoo-dev] Re: devmanual moved to github
On Mon, 13 May 2013 09:07:21 +0200 Alexander Berntsen alexan...@plaimi.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/05/13 08:32, Ralph Sennhauser wrote: Once I was asked if I could look into a package. I spent a day writing a couple of ebuilds including fixing the build system of the target package. When I presented a first git-format-patch I was ask to do a github pull request instead. So I asked why not git-am? The answer was - don't be a *beep*. As a result the package never got fixed and I outright ignore any repo not hosted on Gentoo infra. Who was this? Don't know why it would be relevant. Also I intentionally didn't mention any names and wont do so on this list. Feel free to ask me in private if you have a good reason.
Re: [gentoo-dev] Re: [PATCH FIXED] Introduce edefault() as a friendly default sub-phase wrapper.
On Sat, 11 May 2013 11:51:39 -0400 Mike Gilbert flop...@gentoo.org wrote: On Sat, May 11, 2013 at 5:30 AM, Michał Górny mgo...@gentoo.org wrote: Fixed naming the proper default sub-phase and declaring 'edefault' in python_prepare_all(). --- I think I prefer to explicitly name the function I want to call, so I don't really see any great benefit here. I'm not strongly opposed to it, but I don't see myself using it either. Same here for the reason you mention below. Long term I expect it to be more of a hassle than typing a few additional letters now. Also, how would this interact with other eclasses which may define a similar edefault function? Packages using distutils-r1 don't often utilize other phase-happy eclasses, but I'm sure it will happen eventually.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Fri, 10 May 2013 06:09:32 -0400 Rich Freeman ri...@gentoo.org wrote: On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser s...@gentoo.org wrote: The other thing is those unit files really should come from upstream and other distributions urge their developers to work with upstream [1] Therefore I'd require an upstream bug for each unit that we add. Makes sense, though I wouldn't necessarily make it a hard requirement. Also, upstream units may not be usable as-is. They might reference incorrect file locations (though I'd hope not for the most part), and in particular dependency naming will always be a challenge. Adopting a package to distribution specifics is perfectly valid. But here it's about adding functionality to a package that wasn't there before. The usual reaction in such situations is to tell users to bug upstream about it first. Upstream rejection of a unit should certainly not lead to Gentoo rejection of a unit, any more than their rejection of a script for OpenRC should. Upstreams will likely be slow to embrace the init-scripts-aren't-just-for-distros thing. Rich If an upstream bug is filed and upstream says fuck off there is still a bug report which would meet the requirement. Maybe some other distro even filed the bug already for us.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, 8 May 2013 13:37:51 -0400 Rich Freeman ri...@gentoo.org wrote: Bottom line is that none of this should really be inconveniencing maintainers much - nobody is required to create unit files. However, if a friendly user submits a bug with one attached, then the maintainer should strongly consider adding them to the package at the next convenient time. Indeed no maintainer should be bothered with having his package install a unit file, though two points. A maintainer usually dislikes adding something contributed by a user that he doesn't know about / can't verify . So letting systemd herd picking unit files and committing them I think is reasonable. The chance for screwing with a package by just adding the unit file are close to zero even if not familiar with the package. The other thing is those unit files really should come from upstream and other distributions urge their developers to work with upstream [1] Therefore I'd require an upstream bug for each unit that we add. [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wed, 1 May 2013 19:18:52 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Wed, 1 May 2013 10:14:02 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. I was hoping it would set a precedent and then people would start thinking of splitting up test into categories, maybe even start a thread about it ;). Hehe, yes, you forced me to speak up with trying to set a precedent I think will get in the way of solving it in a more complete way. Though for that we have to agree on - split is desirable - which categories and how to classify tests - how to implement the splitting (EAPI support?) [...] ... and improve on how to configure Portage whether to run tests of any given category. Yeah I'd love to be able to do something like emerge TESTS=dev qa system -extradeps -expensive @world. I was thinking about a /etc/portage/package.test that works more like package.use. So most users will want to have something like: # package.test */* cheap Others might use: # package.test */* cheap normal */*::sunrise expensive my-pkg/foo * # broken test suite, bug XXX =dev-foo/bar-1.1 -* This would also be pretty similar to what your regression-tests useflag for gcc would have been. Even though Portage allows you to configure FEATURES=test on a per package basis since a couple years it doesn't seem to have become a common practice. While Portages mechanism is powerful it might be just to complex or tedious for the average user. As for your example command line 'emerge TESTS=dev qa system -extradeps -expensive @world', could you elaborate on what the categories dev qa system are about? signature.asc Description: PGP signature
Re: [gentoo-dev] Handling of tests (was: GCC USE flag changes)
On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) ... and improve on how to configure Portage whether to run tests of any given category. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC USE flag changes
On Wed, 01 May 2013 01:29:05 -0400 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... My beef is not with the existence of this FEATURE but that it's enabled in the dev profile. I was lucky once to not commit a broken testsuite.
Re: [gentoo-dev] New license - adobe-pcfi
On Sun, 10 Mar 2013 11:10:38 + Robin H. Johnson robb...@gentoo.org wrote: On Sun, Mar 10, 2013 at 11:01:55AM +0100, Ulrich Mueller wrote: CMaps for PDF CJK Fonts --- [...] Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. This would imply that the license cannot be added to the MISC-FREE group. Ok, I think @BINARY-REDISTRIBUTABLE may be workable instead for this license. Thanks to both of you. So the current plan is: license name: Adobe-PCFI license group: BINARY-REDISTRIBUTABLE If there are no further objections within a week I'll commit the license. signature.asc Description: PGP signature
[gentoo-dev] New license - adobe-pcfi
Hi, I'm querying this list out of the need of adding a new license[1] for adobe-pcfi[2]. Suggested name for the license is adobe-pcfi. An other possibility could be Adobe-PCFI to better match other Adobe* licenses. The license would be added to the MISC-FREE license group. If you have any doubts let me know before I proceed in about a week. Thanks to ssuominen and robbat2 for their initial guidance. Cheers, Ralph. [1] https://github.com/jukka/pcfi/blob/master/src/main/resources/META-INF/LICENSE.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=448532 A in-lined copy of the license follows: -- = PDF Core Font Information = This package contains PDF font information files downloaded from http://www.adobe.com/devnet/font/#pcfi and elsewhere. See the individual files and the summary below for related copyright and licensing information. Any Adobe patents covering information in these files should be included in the patent pledge they have made to ISO for the PDF 1.7 standard. Here's what Adobe legal wrote when asked about this: Adobe has provided a patent pledge to ISO which states that Adobe will grant a fee and royalty free license to an unrestricted number of applicants on a worldwide, non-discriminatory basis and under other reasonable terms and conditions to make, use, and sell implementations of PDF 1.7 (ISO 32000-1). (private communication to Jukka Zitting, 2008-12-03) See also the following page for more information about patents related to PDF: http://partners.adobe.com/public/developer/support/topic_legal_notices.html Font Metrics for PDF Core 14 Fonts -- The files in com/adobe/pdf/pcfi/afm were downloaded from http://www.adobe.com/devnet/font/pdfs/Core14_AFMs.zip on 2009-06-14. The MustRead.html file contains the following license: This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification, provided that all copyright notices are retained; that the AFM files are not distributed without this file; that all modifications to this file or any of the AFM files are prominently noted in the modified file(s); and that this paragraph is not modified. Adobe Systems has no responsibility or obligation to support the use of the AFM files. The individual AFM files contain further copyright notices. The aggregate of these notices is: Copyright (c) 1985, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1997 Adobe Systems Incorporated. All Rights Reserved. Helvetica and Times are trademarks of Linotype-Hell AG and/or its subsidiaries. ITC Zapf Dingbats is a registered trademark of International Typeface Corporation. CMaps for PDF CJK Fonts --- The CMap files in com/adobe/pdf/pcfi/*/ were downloaded from http://www.adobe.com/devnet/font/pdfs/ and elsewhere. All the individual CMap files in these directories contain copyright sections with a license for redistribution. The aggregate of this information is: Copyright 1990-2007 Adobe Systems Incorporated. All Rights Reserved. Patents Pending NOTICE: All information contained herein is the property of Adobe Systems Incorporated. Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. PostScript and Display PostScript are trademarks of Adobe Systems Incorporated which may be registered in certain jurisdictions. Adobe Glyph List The glyph list in com/adobe/pdf/pcfi/glyphlist.txt was downloaded from http://www.adobe.com/devnet/opentype/archives/glyphlist.txt on 2010-08-06. Copyright (c) 1997,1998,2002,2007 Adobe Systems Incorporated Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation file to use, copy, publish, distribute, sublicense, and/or sell copies of the documentation, and to permit others to do the same, provided that: - No modification, editing or other alteration of this document is allowed; and - The above copyright notice and this permission notice shall be included in all copies of the documentation. Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation file, to create their own derivative works from the content of this document to use, copy, publish, distribute, sublicense, and/or sell the derivative works, and to permit others to do the same, provided that the derived work is not represented as being a copy or version of this document. Adobe shall not be liable to any party for any loss of revenue or profit or for indirect,
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
On Tue, 19 Feb 2013 14:10:33 +0100 Thomas Kahle to...@gentoo.org wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas Gnu sed version 4 is guaranteed by pms [1] [1] http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-12500011.3.1 signature.asc Description: PGP signature
Re: [gentoo-dev] January stabilization candidates
On Sun, 10 Feb 2013 12:22:13 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I can actually batch invalidate all of them. This will generate some further bug spam (I apologize), but can save your time dealing with the mess. Please let me know what's your preference. The URL field is likely not filled out as intended either. So you might want to do that anyway. signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On Mon, 04 Feb 2013 09:16:32 +0800 Patrick Lauer patr...@gentoo.org wrote: On 02/03/2013 09:45 PM, Ralph Sennhauser wrote: On Sun, 03 Feb 2013 13:46:52 +0100 Pacho Ramos pa...@gentoo.org wrote: dev-libs/boehm-gc Will take this one in a few days if no one else grabs it first. Since it's a dependency of one package I maintain (dev-lang/opendylan) I have a marginal interest in keeping it around. Feel free to add me to metadata too if I forget. Added both of us. signature.asc Description: PGP signature
Re: [gentoo-dev] Add test to IUSE_IMPLICIT
On Sat, 2 Feb 2013 23:33:26 + Aaron W. Swenson titanof...@gentoo.org wrote: After years of if use test ; then ... just working when FEATURES=test is declared, it isn't working with EAPI5. I think we could save some bytes and headaches if we just add test to IUSE_IMPLICIT. Portage's emerge's --newuse option won't be affected by this. From `man emerge`: NOTE: This option ignores the state of the test USE flag, since that flag has a special binding to FEATURES=test (see make.conf(5) for more information about FEATURES settings). What say you? That test shouldn't be a useflag in the first place, that there should be a TESTDEPEND and a dedicatated function defined in PMS to let the ebuild check if src_test will be executed. 'test' as we use it is pretty much a hack. Another note, 'if use test; then' is often very similar in nature to conditional patching and should be avoided where reasonably possible. Either way, I'm against adding test to IMPLICIT_IUSE on the basis of 'I was lazy and want to continue to do so'. Regards Ralph signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On Sun, 03 Feb 2013 13:46:52 +0100 Pacho Ramos pa...@gentoo.org wrote: dev-libs/boehm-gc Will take this one in a few days if no one else grabs it first. signature.asc Description: PGP signature
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On Tue, 29 Jan 2013 22:47:26 +0100
Pacho Ramos pa...@gentoo.org wrote:
Also, autoformatting will help to prevent every package setting
messages with different lines length (in some cases really long lines
that I finally reported some bugs in the past to get them fitting in
standard 80 characters per line).
I agree with you, there should be consistency as far as reasonable.
Formatting certainly is a valid means. Some sort of code tags could
be used if formatting isn't desired. Ie similar to eclass-manpages.
The eclass blurb:
readme.gentoo - An eclass for installing a README.gentoo doc file
recording tips
I know it started out as CONFIGURATION, but README.gentoo is generic
enough to contain other package specific info a user or upstream
developer might be interested in. What I have in mind right now are
patches.
This could look like the following in an ebuild:
README_GENTOO_PATCHES=( ${FILESDIR}/*.patch )
epatch ${README_GENTOO_PATCHES[@]}
Then the eclass generates for each patch in README_GENTOO_PATCHES a
note within a standard section containing patch name, author, subject
line. This needs something similar enough to a git format patch to
magically work though, but might be a nice addition and would help the
goal of consistency. Also git-format-patch like patches are anyway
preferable to dangling patches with maybe a bug number in the ebuild
at best.
signature.asc
Description: PGP signature
Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)
On Mon, 21 Jan 2013 13:27:18 +0800 Ben de Groot yng...@gentoo.org wrote: On 21 January 2013 12:16, Peter Stuge pe...@stuge.se wrote: Panagiotis Christopoulos wrote: I don't build server machines every day, others do and it would be much appreciated if they could respond here. I build catalyst stage4s. Any default profiles are kindof pointless for me; I have USE=-* and the flags that I want. Anything else seems a bit too random. This is why I think we do need something like a truly minimal profile to start building from. Too many people are doing this. -* will still be required by those same people for EAPI 1 package defaults. Cleaning a profile won't change that. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, 14 Dec 2012 12:02:40 -0800 Greg KH gre...@gentoo.org wrote: On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: On 14/12/12 01:28 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? Eudev's project announcement is coming soon, should answer your questions. Ok, when is soon? I'm guessing that the result of the council meeting ment that things are progressing, right? If so, in what way? Why would it matter if soon meant a week or a month from now? In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. I am not referring to udev's dependancies, that was never the real issue with a separate /usr/ partition as those could easily be fixed with a configuration option for the package. If some vocal upstream and otherwise respected maintainers claim it to be broken and calls everyone a fool for not following suite, that's what we get. ;) There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. That's the big problem, those need to be fixed. But there is no hurry as separate /usr is broken for years, right? Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. Again, udev itself was never an issue, it could work just fine with a separate /usr/ partition. Now perhaps our ebuild didn't build it in that matter, but that's a configuration/ebuild issue, not a upstream package issue. udev not only could work just fine with a separate /usr but potentially make it a non issue. Let's see if eudev succeeds here. If it's the right place to solve it is another question, though the right place for udev isn't in systemd either. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. If the plan is still to require an initramfs (hint, it's the only way it can work), then why was the eudev package forked and created? sys-fs/udev is systemd-udev, hope we don't have to rename the package to make this clear. Please, I'm totally confused now, especially after reading the commits in the eudev repo, I see nothing that fixed any /usr/ problems, what am I missing? The sentence in the very same mail that it's currently not working / implemented maybe? Oh, you also slowed the build time of the package down in eudev compared to udev, but I'm sure you realized that already, and did it for a good reason. That's always the last straw, spd! confused, greg k-h Seriously, while I agree the eudev fork had an ivory tower start, I don't get what you gain by running around like an elephant in a porcelain shop. I for one welcome yet another fork. Time will tell if it can prevail. Regards Ralph
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On Thu, 29 Nov 2012 17:09:34 +0100 justin j...@gentoo.org wrote: On 29/11/12 16:51, Ian Stakenvicius wrote: [...] ..ok remind me again what the .pc files provide you? this is so that you can have slotted blas providers and various packages can choose their preferred one instead of having to use the eselected one? or... Not exactly. The user can choose for each package newly by eselecting the wanted implementation. This is the user side. From the pm side we ensure that the choice is really respected by linking against package specific names [1] instead of the generic ones e.g. libblas.so. And this can be achieved in an easy way by using pkg-config. justin 1) # eselect blas set atlas-threads # pkg-config --libs blas -lptf77blas -lm -latlas -lpthread # eselect blas set reference # pkg-config --libs blas -lrefblas This immediately bears the following questions: * How do you ensure the linked against implementation doesn't get depcleaned? revdep-rebuild maybe? * How do you let users configure the implementation to be used on a per package basis? Interrupt an emerge world to set the appropriate implementation for the next few packages? signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.
On Fri, 12 Oct 2012 21:10:23 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'd argue against deprecating EAPI 0 any time soon though. Killing EAPI 1 would be a better idea. I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be gone from tree in 3-5 years once the EAPI=0 requirement is lifted. Currently we have only 6 official EAPIs which is still manageable to remember the details of each. Though it might be confusing for new developers. Once we are at 20 EAPIs it will be an issue also for seasoned folks. Therefore deprecation is a given, how to go about it is certainly up to discussion. What do you see as an acceptable path here? signature.asc Description: PGP signature
[gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
From time to time the topic of deprecating EAPIs comes up and usually one suggestion is to keep 0 and start with converting EAPI 1 ebuilds. Then someone comes along and asks what is the point? Indeed, a fair question. The following tries to take a different approach to the topic. It's not all thought through in detail, but that wont happen anytime soon, after all it's on my TODO for long enough. So I present it in the hope others will try to poke holes into it or even pick it up. EAPI=0 requirement pointless? - The EAPI=0 requirement comes from having to provide an update path for systems with a package manager without EAPI support. By now we are talking about really ancient systems and it's questionable if there is any merit in supporting such. Further the situation is that some of the maintainers of must be EAPI 0 ebuilds already moved on as the majority of users will profit from a bump. As a result the clean upgrade path is already borked and the value of keeping others at EAPI=0 deteriorates further and further. Forcing EAPI 0 on some maintainers for all eternity doesn't strike me as brilliant, quite the opposite frankly. After all new EAPIs are supposed to contain bug fixes and new features required to write better ebuilds. If all installed PMs supported EAPI? The issue of an update path is reduced to keeping intermediate versions in tree. Those PMs also support EAPI=1, rendering EAPI=0 obsolete. Base EAPI - Systems without having a package manager installed that supports at least the 'Base EAPI' aren't considered supported any longer. Maintainers of system packages can use the Base EAPI without worrying. Maintainers of system packages can use more recent EAPIs but need to take special care. Value of Base EAPI -- Maintainers of system packages need to be able to use newer EAPIs after some time. They can wait but not forever. built_with_use removal is one example, strong vs weak blockers an other. The value can be based on time ( i.e. after 3 years ) or set by council decision. A combination is fine as well. The value should be kept low enough so the rule maintainers don't have to care about using it holds. The need of derived distributions / package managers should be considered, ie. let them catch up if necessary. Security updates should be possible for some time without full updates. This extends to other packages as well. So maintainers of critical non system packages can use this EAPI as well if they want. Guess EAPI=2 would be a reasonable compromiss. Deprecation? EAPIs below the base EAPI can be considered deprecated if one desires. References in devmanual can be removed and so the document be simplified. Once there are only few ebuild of a deprecated EAPI left, it might make sense to convert them and add a repoman check so the number of used EAPIs is kept reasonable. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Sun, 16 Sep 2012 19:41:14 -0700
Brian Harring ferri...@gmail.com wrote:
On Sun, Sep 16, 2012 at 10:10:47PM -0400, Mike Frysinger wrote:
On Sunday 16 September 2012 03:51:04 Brian Harring wrote:
+ if ! has $EAPI 0 1 2 3; then
+ eqawarn built_with_use should not be used in
$EAPI; use USE deps.
+ elif has $EAPI 2 3; then
+ if [[ $hidden == yes ]] || $missing_was_set; then
+ eqawarn built_with_use in EAPI=$EAPI
without --missing or --
hidden
usage, should use USE deps instead. +else
+ eqawarn built_with_use should not be
used; upgrade to EAPI=4
instead
+ fi
+ fi
i'd do:
case ${EAPI:-0} in
# No support in these EAPIs, so don't warn.
0|1) ;;
# Maybe warn as some functionality exist.
2|3) [[...]] eqawarn ... ;;
# Assume EAPI=4 or newer where all functionality exists.
*) eqawarn ... ;;
esac
I'd be fine w/ it; worth noting, that was a 4am patch, so I'm not
claiming perfect implementatoin there. :)
My main focus here is switching built_with_use to actively nagging
people to stop using it; this includes nagging EAPI0/1 users of it.
Sans the implementation details, anyone got complaints with the
intent?
How about raising the EAPI baseline from 0 to 2 - ie. every package may
use EAPI 2; not the same as deprecating 0 1 - and do:
case ${EAPI:-0} in
0|1|2|3|4) eqawarn From date onwards this will die ;;
*) die ... ;;
esac
as EAPI 2 supports the --missing case via constructs as:
|| (
=foo/bar-1
foo/bar-1[baz]
)
Almost all affected packages can be bumped straight to 4 anyway and
so use the improved syntax.
The aim would be to get rid of built_with_use not only in a distant
future. The corresponding bug [1] is from 2009 and can't be fixed
[1] https://bugs.gentoo.org/show_bug.cgi?id=261562
~brian
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 08:45:22 +0200 Ralph Sennhauser s...@gentoo.org wrote: The aim would be to get rid of built_with_use not only in a distant future. The corresponding bug [1] is from 2009 and can't be fixed ... without something like increasing EAPI baseline.
Re: [gentoo-dev] Re: [PATCH] eutils: Warn on built_with_use usage
On Mon, 17 Sep 2012 00:58:02 -0700
Gregory M. Turner g...@malth.us wrote:
My main focus here is switching built_with_use to actively nagging
people to stop using it; this includes nagging EAPI0/1 users of it.
Sans the implementation details, anyone got complaints with the
intent?
I have a concern about it, yes. But, maybe there's a good answer to
my concern, so please consider this a friendly ebuild development
question disguised as a complaint :)
Unless I'm missing something, it seems that once we deprive the
ebuild developer of this feature, there is no simple, supported way
to retrieve the information except to depend on it.
The issue is that calculating dependencies is not the only reason we
might want to know if a package was built with a particular USE-flag,
and if we get rid of built_with_use, we literally cut ourselves off
from retrieving this information in any officially sanctioned way
(except to DEPEND on it, which may not be semantically correct).
I can think of all kinds of legitimate reasons we might want to know
if the installed such-and-such package was built with so-and-so
use-flags without depending on it. i.e.:
o if the current gcc falls within a certain range of version
numbers and was built with graphite, we are going to trigger
a compiler bug. Suppose that there is no graphite support
or dependency in ${P}, and that we can apply a patch which will
work around the bug, but at a performance cost in ${P} we'd rather not
pay unless we have to.
o We need to modify a Makefile based on how a package we
BDEPEND on was built -- but suppose there is no BDEPEND
/limitation/ to enforce -- in other words, either way, our package
will build, and there is no correlating reverse dependency to
worry about at runtime.
Such needs are fairly unusual, but they do come up in real life.
My concern is that this will lead to people doing things like:
o cut-pasting the old implementation of built_with_use into ebuilds,
-- but that implementation will break if the portage database
layout changes
o creating bogus one-off use-flags as a way of performing these
queries (and, thanks to the upcoming requirement that USE flags
always appear in IUSE, exposing those flags to the end-user,
perhaps with some confusing description like whether such-and-such
was built with so-and-so).
o creating BDEPENDs of -- and sketchy parsers for -- portage-utils
or similar suites, just to ask this question.
Admittedly, it's hard to prevent people from doing
built-with-use foo/bar baz || die ${P} needs foo/bar with baz
since, once upon a time, that was SOP, and we'd have to parse the
bash code or something to qa warn for it automatically.
But any number of similar prohibitions are simply documented in the
developer handbook, including this one.
Am I missing something, here? I kinda think we should go the
opposite direction and un-deprecate the API. It seems like we are
cutting off our nose to spite our face here.
-gmt
has_version foo/bar[baz] can be used in EAPI 2 and later.
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Sat, 28 Jul 2012 14:27:49 +0800 Ben de Groot yng...@gentoo.org wrote: On 28 July 2012 13:59, Nikos Chantziaras rea...@gmail.com wrote: On 28/07/12 08:22, Ben de Groot wrote: In preparation for that, we want to ask maintainers of all ebuilds in the tree with dependencies on Qt4, to make sure that they have the proper slot. Otherwise your package may pull in Qt5 while it may not in fact support it. This can be trouble if the application actually works with Qt5. It might depend on Qt4 but has no problems with Qt5 (contrary to Qt3 vs Qt4, Qt5 is mostly compatible with much of existing Qt4 code), needlessly pulling-in Qt4. Many applications simply build and run as-is and no code changes are necessary. So what would be the methodology of making sure a package has the proper slot? Obviously you would need to make sure that the package actually does support Qt5. Then, as I see it, we could do either: || ( x11-libs/qt-gui:4 x11-libs/qt-gui:5 ) Never prefer an old version in an || ( ) block, this makes for a poor update experience. Also the || ( ) construct can only be used if they are runtime switchable, which I really doubt here, as otherwise you build against one, the user install the other and portage depcleans the one you have built against. or: qt4? ( x11-libs/qt-gui:4 ) qt5? ( x11-libs/qt-gui:5 ) A qt5 useflag will do more harm than good. If I enable qt, I do not care which version, I just want the gui for the particular app. If the app works with qt:5 the usflag qt means qt:5, if it only works with qt:4 the useflags means qt:4. In case it works with both and the maintainer thinks it's worth to let the user choose, use the useflag qt4 to let the user opt out of the latest and greatest. Other thoughts?
Re: [gentoo-dev] Re: Fwd: Heads up for Qt5
On Sat, 28 Jul 2012 15:54:07 +0800 Ben de Groot yng...@gentoo.org wrote: We do not have (nor want to support) a qt useflag. We have opted for qt4 and qt5 useflags as the most straightforward and least confusing. Indeed, the flag qt has almost disappeared from the tree. Good to know.
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On Tue, 24 Jul 2012 08:48:52 + Sven Vermeulen sw...@gentoo.org wrote: Can current users also already use the /etc/portage location? If so, I can already update the docs now (since I'll need to describe both of the locations for a while anyhow). I moved my make.conf to the new location about a year ago.
Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)
On Tue, 24 Jul 2012 12:29:14 +0300 Maxim Kammerer m...@dee.su wrote: On Tue, Jul 24, 2012 at 3:07 AM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: I propose to commit this news item in 2 or 3 days. Does anyone have any comments about it? Several comments: 1. Maybe note that /etc/portage/make.conf takes precedence over /etc/make.conf? 2. New make.conf location (although supported) is not mentioned in portage(5) man page for currently stable sys-apps/portage (2.1.10.65). man 5 portage about files in /etc/portage make.conf The global custom settings for Portage. See make.conf(5). If present, this file will over‐ ride settings from /etc/make.conf. 3. This news item is really useful, since the change has a potential to break automated builds. We aren't discussing dropping support for the old locations here but about makeing the new location the default.
Re: [gentoo-dev] RFC: l10n.eclass
On Mon, 23 Jul 2012 20:29:44 +0800
Ben de Groot yng...@gentoo.org wrote:
# ones. This function is normally used internally in this eclass,
not by # l10n.eclass consumers.
l10n_get_locales() {
I'd mark this function @INTERNAL then, at least until someone can
presents a use case.
If you are sufficiently sure this function shouldn't be used by
consumers you could remove the function
There are use cases, e.g. net-im/qtwitter-0.10.0-r1 for which I have
an editted -r10 revision in my dev overlay. I'm sure it could be
handled with l10n_for_each_locale_do, but the migration is more
straight-forward by simply using l10n_get_locales in this case.
This is why I worded it normally instead of only. Maybe the
wording could be improved?
The primary concern should be expressiveness. That said, qttwitter
looks like a good example use case. You have convinced me.
src_configure() {
qmake4 PREFIX=/usr LANGS=$(l10n_get_locales)
}
Maybe l10n_get_enabled_locales would read even more natural here?
Either way I'd drop the internal entirely as it also provides a simple
way to sanitize LINGUAS without relying on the package manager. ie.
setting 'LINGUAS=$(l10n_get_locales)' in an ebuild would enable the
possible EAPI 5 behaviour described later in this thread, which would
allow direct use of LINGUAS. The only difference being the backup
locale.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 23:37:32 +0800
Ben de Groot yng...@gentoo.org wrote:
I got a few more suggestions on IRC, and I have updated the eclass
accordingly. Please check the attached new version, also available at
https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
Pseudo inlining
# Add linguas useflags
if [[ -n ${PLOCALES} ]]; then
for u in ${PLOCALES}; do
IUSE+= linguas_${u}
done
fi
no need to guard the loop against empty $PLOCALES.
l10n_for_each_locale_do() {
local locs x
locs=$(l10n_get_locales)
if [[ -n ${locs} ]]; then
for x in ${locs}; do
${@} ${x} || die failed to process enabled
${x} locale done
fi
}
same here, no guarding required and ${@} should be quoted as it may
contain args with spaces. Also in l10n_for_each_disabled_locale_do.
# ones. This function is normally used internally in this eclass, not
by # l10n.eclass consumers.
l10n_get_locales() {
I'd mark this function @INTERNAL then, at least until someone can
presents a use case.
If you are sufficiently sure this function shouldn't be used by
consumers you could remove the function in favour of 'use linguas_${x}
|| continue' in l10n_for_each_locale_do resp 'use linguas_${x}
continue' in l10n_for_each_disabled_locale_do.
signature.asc
Description: PGP signature
Re: [gentoo-dev] DESCRIPTION in eclasses
On Thu, 19 Jul 2012 08:57:09 +0200
Ulrich Mueller u...@gentoo.org wrote:
Thanks, this explains why these DESCRIPTIONs are there.
But history left aside, are they still useful today? If not, then they
should be removed.
DESCRIPTION=Based on the ${ECLASS} eclass is never a sufficient
description for a package. So clearly pointless here.
Currently only KEYWORDS are banned from eclasses. I would add
DESCRIPTION and LICENSE to this list as well. DESCRIPTION is individual
to the package and it should never be to much work to come up with a
short description and LICENSE in eclasses greatly increases the chances
for the final listed licenses to be wrong. We have seen the latter
happening with the enlightenment.eclass.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 14:45:39 +0800
Ben de Groot yng...@gentoo.org wrote:
Today I would like to present to you my proposal for a new eclass with
helper functions for treating localizations: l10n.eclass (see the
attached file or [1]). Its functionality can be used in other eclasses
(such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
In order to keep the code simple, and prevent double loops and extra
variables (such as currently used in the media-video/smplayer ebuild),
I am proposing that we should add any missing long-form locales to
profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
This also means that users may have to expand their LINGUAS setting in
make.conf (e.g. LINGUAS=de en - LINGUAS=de de_DE en en_US) to
cover the different variants used in packages.
If you have any comments, spot any mistakes, or have proposals for
improvement, I would love to hear it! I would especially love from
maintainers of complicated packages such as libreoffice-l10n, if there
is any additional functionality that we could include in this eclass
to make their job simpler.
1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
I assume the P in PLOCALS stands for package. Not that obvious if you
ask me. L10N_LOCALS would at least tell me which eclass this variable
belongs to.
Instead of using LINGUAS you should make use of the use function to get
your cross sections. ie.
for locale in ${PLOCALES}; do
if use linguas_${locale}; then
enabled_locales+= ${locale}
else
disabled_locales+= ${locale}
fi
done
First, this is guaranteed by PMS and so independent of package manager
and second, you do not have to care about locales in LINGUAS which are
invalid for the package. Could be that Portage re-exports a sanitized
LINGUAS tough, but I doubt it.
signature.asc
Description: PGP signature
[gentoo-dev] Last rite: app-misc/jbidwatcher
# Ralph Sennhauser s...@gentoo.org (13 Jul 2012 # Mask for removal in 30 days. Fails to build with java 7 #421917. # QA issues #298701. Ceased to be useful long ago. #235124. Thanks # to Michael Weber x...@gentoo.org #235124 for maintaining a # binary package in his overlay. (layman -a xmw) =app-misc/jbidwatcher-1* signature.asc Description: PGP signature
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 13:01:52 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/30/2012 12:42 PM, Ralph Sennhauser wrote: That might be neat, but it would already help if you had to add --allow-downgrades or similar to emerge in case Portage wants to downgrade one or more packages. Besides preventing an accidental downgrade it would raise the awareness of the problem. I think people would just put it in EMERGE_DEFAULT_OPTS and forget about it, since downgrades are a fairly common occurrence, due to changes in version numbering schemes or buggy versions being dropped from the tree. Maybe a RESTRICT=downgrade metadata setting would help to reduce the noise so that people would be less likely to enable --allow-downgrades by default. Nothing wrong with people putting --allow-downgrades into EMERGE_DEFAULT_OPTS if they choose to do so. At least people who'd like this protection could make use of it. Usually both upstream and maintainer put quite a bit of thought into an upgrade path but hardly the other way around. On a system with mixed keywords it's far more common to see downgrades because the unmasked version was removed before stable did catch up than pseudo downgrades because we have no epochs or alike. signature.asc Description: PGP signature
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 20:33:35 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: On 06/30/2012 04:07 AM, Pacho Ramos wrote: I would like to discuss a bit more issues like: https://bugs.gentoo.org/show_bug.cgi?id=423087 Even if there are a lot of packages that can cause this breakage when downgraded, I think it should be prevented and package managers shouldn't try to downgrade this kind of packages as they will later cause a total breakage. People is not supposed to know that downgrading some package system will, for example, have an unusable gcc. It seems like a die in pkg_pretend would serve pretty well. As a comparatively simple, user-oriented workaround, since this only happens at downgrades and these should be pretty rare, I have the following suggestion: Make a portage feature that is **on by default**, which causes portage to generate a binpkg of the version to be unmerged, in the case of a downgrade. Rationale: * if you know what you are doing, you can switch this off easily * does not take much space since downgrades are rare * should help our users a lot, whenever someone accidentally or not-knowingly downgrades something critical. Thoughts? That might be neat, but it would already help if you had to add --allow-downgrades or similar to emerge in case Portage wants to downgrade one or more packages. Besides preventing an accidental downgrade it would raise the awareness of the problem. Cheers, Andreas signature.asc Description: PGP signature
Re: [gentoo-dev] ewarn and package upgrades
On Sat, 23 Jun 2012 07:40:02 -0400 Rich Freeman ri...@gentoo.org wrote: On Sat, Jun 23, 2012 at 7:32 AM, portage@localhost wrote: WARN: postinst Please rebuild both libxcb and xcb-util if you are upgrading from version 1.6 I've read enough warnings like this (many packages use them) that it occurred to me that perhaps there should be some better way of dealing with this. I realize we have a huge discussion going on about suggested depends and such which could resolve it long-term. If that really doesn't work out, then perhaps at least it would be useful if it were obvious in ELOG messages what the old and new version were, or some other stopgap measure. Bonus points if the ebuild can figure it out and only generate the warning conditionally, but I'd be happy if I could just delete the message without having to figure out what version I was previously running... Rich REPLACING_VERSIONS and REPLACED_BY_VERSION added in EAPI 4 can be used to do this things with elog messages.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Wed, 20 Jun 2012 18:24:33 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Can we all agree to just stop this and just restrict the arguing to being between SDEPEND and DEPENDENCIES? Cheers. I clearly favour going with SDEPEND now as this fits better what people are used to and the move to DEPENDENCIES is also a chance to clean up dep-specs after we added all quirks we need(*). Let's name GLEP 54 here which we hopefully can add to EAPI 6. (*) or for when we run out of special chars ;) signature.asc Description: PGP signature
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico zmed...@gentoo.org wrote: On 06/07/2012 01:24 AM, Brian Harring wrote: On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: On Wed, 06 Jun 2012 21:16:05 +0200 Pacho Ramos pa...@gentoo.org wrote: Well, I think reading this thread is more or less clear what it would be supposed to do, also Zac suggested it and looks to have an idea about what should it do. There's a big leap from more or less clear and an idea to the kind of knowledge we want to have. Think REQUIRED_USE for how this can go wrong... If you think ABI_SLOT is essential, why not try implementing it and trying it out in a large number of packages, and reporting your results? It's pretty close to the SLOT operator model, and it seems like it should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and test it in an overlay before we include it in the final EAPI 5. I'd prefer you nailing down the details a bit more before slipping it into an EAPI called 5_pre1; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we can convince him to change it to ABI_SLOT operators. Whether we can convince Ciaran to change the wording of a feature in a draft document is utterly irrelevant. SLOT operator deps solve a large class of issues and wont get in the way of solving the ranged dep problem in a later step, be it ABI_SLOT or something more generic. I'm all for getting SLOT operators into EAPI-5 as actually already intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so don't let us delay the whole thing because of that. If we're going to do this, there should be a way to represent the direction of compatibility. Might be overthinking it, but consider upgrades where new API is added; this does *not* break ABI, it extends it. Going in reverse however *would* break ABI for anything that was using the new additions. This issue can be avoided via usage of version operators w/ appropriate slot binding deps, just seems hanky in light of what we're talking about. That might be nice, but it also complicates things a bit. We might stand a better chance of getting Ciaran to cooperate if we keep it simpler and stay closer to the SLOT operator model. Again, it's not about getting someone to cooperate. Something that you comment with that might be nice isn't ready for inclusion into EAPI 5. I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. What for? So we won't ever get rid of revdep-rebuild resp. @preserved-libs? Except for the ranged dep problem I don't see any additional benefit but potential drawbacks. Please correct me where I'm wrong. Cheers. signature.asc Description: PGP signature
[gentoo-dev] [java-utils-2.eclass] - removal of java-pkg_ensure-test and java-pkg_ensure-gcj
Both java-pkg_ensure-test and java-pkg_ensure-gcj will be removed from
java-utils-2.eclass after the 4 of July 2012. See attached patch.
java-pkg_ensure-test: [1]
Was used to enforce USE=test if FEATURES=test. For quite some time this
is handled by package managers. Relies on the env var FEATURES [2].
There are no known consumers any more.
Solution: Remove the call to java-pkg_ensure-test and rely on the
package manager handling this.
java-pkg_ensure-gcj:
Uses built_with_use [3] and ebeep [4] and is no longer needed with EAPI
2 or later. There are no known consumers for quite some time.
Solution: Migrate to EAPI 2 or later and depend on sys-devel/gcc[gcj]
instead.
[1] https://bugs.gentoo.org/show_bug.cgi?id=278965
[2] https://bugs.gentoo.org/show_bug.cgi?id=174335
[3] https://bugs.gentoo.org/show_bug.cgi?id=261562
[4] https://bugs.gentoo.org/show_bug.cgi?id=377943
Index: java-utils-2.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/java-utils-2.eclass,v
retrieving revision 1.150
diff -u -b -B -r1.150 java-utils-2.eclass
--- java-utils-2.eclass 13 Mar 2012 10:05:46 - 1.150
+++ java-utils-2.eclass 4 Jun 2012 10:15:57 -
@@ -1686,23 +1686,13 @@
}
java-pkg_ensure-gcj() {
- if ! built_with_use sys-devel/gcc gcj ; then
- ewarn
- ewarn You must build gcc with the gcj support to build with gcj
- ewarn
- ebeep 5
- die No GCJ support found!
- fi
+ # was enforcing sys-devel/gcc[gcj}
+ die ${FUNCNAME} was removed. Use use-deps available as of EAPI 2 instead. #261562
}
java-pkg_ensure-test() {
- if has test ${FEATURES} ! has -test ${FEATURES} \
- has test ${IUSE} ! use test;
- then
- eerror You specified FEATURES=test, but USE=test is needed
- eerror to pull in the additional dependencies for testing
- die Need USE=test enabled
- fi
+ # was enforcing USE=test if FEATURES=test
+ die ${FUNCNAME} was removed. Package mangers handle this already. #278965
}
# --
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
On Tue, 29 May 2012 18:27:51 +0200 hasufell hasuf...@gentoo.org wrote: Well then let my clarify: I'm against too many pre-set (meaning activated) features/useflags. Think of it as nouserpriv feature. ;) Either way, to disable userpriv is kind of working against QA as a package really should be build-able as non root user but then. Have userpriv and usersandbox enabled since it's became available, no issues to report. signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Also, there still should be a bug at b.g.o and git format-patch works just fine for that. Maybe it's only github now but how many places is a developer supposed to monitor? signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs willi...@gentoo.org wrote:
On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
New udev and separate /usr partition
Decide on whether a separate /usr is still a supported
configuration. If it is, newer udev can not be stabled and
alternatives should be investigated. If it isn't, a lot of
documentation will have to be updated. (And an alternative should
likely still be provided.)
There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.
Isn't meant /usr without initramfs, independent of how broken some
people precieve it?
Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an
initramfs if you have a separate /usr partition [1]?
That's an effort I welcome either way. So thanks for that.
Also, I am going to reiterate what Greg said. This is not an issue
with udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.
With udev-182 its no longer only the ecosystem which produce some
broken products but udev itself which is broken. Otherwise we would
have gone on like we always did, right?
Also, with the appropriate documentation changes, which are being
worked on (see [1]), I feel that the statement above that newer udev
can't be stabled should be re-evaluated.
Long term newer udevs will be stabilized and I'm positive it wont take
as long as grub2 or portage-2.2 ;)
There is no particular hurry as far as I know so let's give Chainsaw
some time to look into an udev patch and don't go with the 30 day
with bug fixing rule.
Support for initramfs was rather poor until recently. For instance
dracut-0.17-r3 (haven't tested 0.18 so far) was the first to actually
produce a usable initramfs for me. Thus far I crafted them manually if
needed. Personally I would like to see the initramfs situation further
improved, this includes genkernel and dracut stable on all platforms and
then give it time to let the knowlage spread or alternatively an udev
patch which allows current setups to continue to work before the
council re-evaluates the udev stabilization again.
Cheers
Ralph
William
[1] https://bugs.gentoo.org/show_bug.cgi?id=407959
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Wed, 7 Mar 2012 21:41:02 +0100 Ulrich Mueller u...@gentoo.org wrote: Hi all, The way how we currently specify the EAPI in ebuilds has some problems. For example, there is no sane way to allow usage of features of a new bash version in a new EAPI. So we are currently stuck with bash 3.2. Also changes of global scope behaviour, like addition of new global scope functions (similar to inherit) are not possible. These flaws are outlined in GLEP 55 [1]: | In order to get the EAPI the package manager needs to source the | ebuild, which itself needs the EAPI in the first place. Otherwise it | imposes a serious limitation, namely every ebuild, using any of the | future EAPIs, will have to be source'able by old package managers | [...] The council has voted down GLEP 55 more than a year ago, but at the same time requested that a solution for the mentioned issues should be found. [2] However, there was no progress since then. The issue arose again in bug 402167 [3] where several solutions have been discussed. Below, I try to summarise the possible options resulting from that discussion. *** Proposal 1: Parse the EAPI assignment statement *** This first proposal would require that the syntax of the EAPI assignment statement in ebuilds matches a well defined regular expression. A scan of the Portage tree shows that the statement only occurs in the following variations (using EAPI 4 as example): EAPI=4 EAPI=4 EAPI='4' Sometimes this is followed by whitespace or a comment (starting with a # sign). Also, with very few exceptions the EAPI assignment occurs within the first few lines of the ebuild. For the vast majority of ebuilds it is in line 5. Written in a more formal way, appropriate for a specification: - Ebuilds must contain at most one EAPI assignment statement. - It must occur within the first N lines of the ebuild (N=10 and N=30 have been suggested). - The statement must match the following regular expression (extended regexp syntax): ^[ \t]*EAPI=([']?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ Note: The first and the third point are already fulfilled by all ebuilds in the Portage tree. The second point will require very few ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). The package manager would determine the EAPI by parsing the assignment with above regular expression. A sanity check would be added. Citing Zac Medico in [3]: The fact that we can compare the probed EAPI to the actual EAPI variable after the ebuild is sourced seems like a perfect sanity check. We could easily detect inconsistencies and flag such ebuilds as invalid, providing a reliable feedback mechanism to ebuild developers. This proposal comes in two variants: 1a) The change is applied retroactively for all EAPIs. 1b) It is only applied for EAPI 5 and later (which means that the result of the EAPI parsing would be discarded for earlier EAPIs). *** Proposal 2: EAPI in header comment *** A different approach would be to specify the EAPI in a specially formatted comment in the ebuild's header. No syntax has been suggested yet, but I believe that the following would work as a specification: - The EAPI must be declared in a special comment in the first line of the ebuild's header, as follows: - The first line of the ebuild must contain the word ebuild, followed by whitespace, followed by the EAPI, followed by end-of-line or whitespace. Again, the proposal comes in two variants: 2a) It is combined with a one time change of the file extension, like .ebuild - .eb. 2b) The usual EAPI assignment statement in the ebuild is still required, at least for a transition period. In the 2a case, the EAPI variable could be made read-only in bash before sourcing the ebuild. In the 2b case, a sanity check similar to the one mentioned above would be added. What do you think? (I really hope for a constructive discussion here. So, if you want to comment that all of the above proposals suck and GLEP 55 is much superior, then please open a new thread for it.) Ulrich Currently 5 proposals are listed on the wiki. [4] While all of them have some temptations the actual goal is to make obtaining the EAPI the very first step so everything else can be defined in terms of EAPI and so immediately deployable in future. This are changes in atom syntax like needed for GLEP 54 or those bash feature often mentioned besides many other things one can think of. GLEP 55 requires changing ebuild extensions on a regular basis but doesn't impose any limit on the ebuild format or atom syntax, only the file extensions would be imposed. The ebuild extensions for GLEP 55 would likely always be ebuild-integer as integers are reserved for future use by Gentoo. While for example .ebuild-5 is still recognised as an ebuild; .eb .ebld .ebd .bld .dliube .dlbe .be are not. This brings me to the point if not GLEP 55 then only if we
[gentoo-dev] Lastrite: dev-java/sun-j2ee
# Ralph Sennhauser s...@gentoo.org (28 Jan 2012) # Hopelessly outdated, contains broken jars. #91484 # Removal in 30 days. dev-java/sun-j2ee signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Fri, 20 Jan 2012 07:49:07 -0500 Rich Freeman ri...@gentoo.org wrote: On Thu, Jan 19, 2012 at 10:33 PM, Duncan 1i5t5.dun...@cox.net wrote: Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: Maybe it would be enough to add a suggestion about --exclude in the --newuse section of the emerge man page? I don't think this is confusing enough to qualify for an interactive suggestion. However, it could be argued that the various boilerplate handholding we're already doing has set the precedent. I think the manpage is the right place to fix it. Users would find out about -N from the manpage or from following -dev. Fixing it in that place seems appropriate. Right now I think experienced users are more likely to be using it. I'd still like to see our handbook include a recommended workflow for keeping gentoo up-to-date. Perhaps that should include a few options with the pros/cons of each. I'd think that emerge -auDNv world would be one of those options. Perhaps another might be including build deps. One advantage of having people running a uniform update command that tends to keep everything up to date (even if not strictly necessary), is that it would cut down on the diversity of our install base. Right now a stable user could be running various versions of various libraries based on when they first merged them and whether they use -D, and so on. Keeping everybody moving along to newer versions (and more freshly compiled ones) could help to cut down on the bugs. Bugs filed with older versions still in portage would still be legitimate, but unless somebody really needs the older version there is no sense making more work for ourselves. Perhaps this is worth its own thread, as this one is already drifting way off topic. Rich I'm sure there is already such a thread on *-dev and the only sane thing would be to introduce an option along the line of emerge --update world which condenses all best practice options into a single one and which can change over time together with the best practices. Though this doesn't change the fact that messing with stable ebuilds is dangerous and clearly labelled a don't do in the dev-manual even so it is sometimes unavoidable.
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 6 Jan 2012 20:05:47 +0100 Michał Górny mgo...@gentoo.org wrote: [snip] You should consider taking like 1 or 2 hours of your precious time to read about the use and meaning of various directories in the filesystem. The FHS gives different meaning to directories than the systemd folks like it to be. Yes, it's unpleasant how far that sort of breakage already progressed. However, by definition software not adhering to the current standard is what is broken and not the other way around. There is nothing wrong with changing an old standard if there is a need, though until a new standard is approved / accepted there is no ground to change anything and breaking the current standard on purpose is plain stupid. Btw, do you happen to know what is going on with FHS-3.0 and why there are delays. Wasn't it supposed to be announced in summer 2011? Then do you happen to know a technical paper which actually discuss the advantage / disadvantages of changing the current standard. All I have read on this topic so far looks like propaganda material only or lists non arguments like less top level directories. signature.asc Description: PGP signature
[gentoo-dev] Last Rites of dev-java/jrockit-jdk-bin
# Ralph Sennhauser s...@gentoo.org (04 Jan 2012) # Outdated Java version, fails to fetch, no upstream. #228929 # Removal in 30 days. dev-java/jrockit-jdk-bin
