Re: [gentoo-dev] supporting static-libs
On Tuesday 28 of August 2012 02:15:40 hasufell wrote: > Is there a reason not to support static-libs in an ebuild if the package > supports it? > > It seems some developers don't care about this option. What's the gentoo > policy on this? Isn't this actually a bug? A little remark. For CMake controlled buildsystem (as you're coming here from latest dev- games/simgear), there's no automatic way of building both static and shared libs (simgear allows to choose just one). This is why I removed static libs support that you proposed for dev- games/simgear (similar to ruby eclass abi handling - manually calling phases twice to build package 1st as shared, 2nd time as static). This is what I called "not worth the effort" in private discussion with you, not quite "I don't care for static libs" :) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] stripping escape sequences from build logs
On Sat, 2012-09-01 at 17:39 -0500, William Hubbs wrote: > All, > > I find the included escape sequences to be annoying when I am reading a > build log. > > Is there a way to strip these? > > Thanks, > > William > Porthole's terminal strips most of them, processes some. It also does message filtering and highlighting for warnings, errors, and an emerge process summary. The filtered messages are also double click-able to bring you to the exact spot in the log. Making it easy to find the errors. The filtered messages can also be easily configured (well, if you can do python reg expressions ;). It can load build logs for viewing, "Actions" ==> "Open Emerge Log" menu items in portholes main window. It also has dynamic automatic line wrapping, so resizing the window reformats the viewed text. P.S. It did message filtering long before portage got the capability. -- Brian Dolbec signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: RFC: PROPERTIES=funky-slots
Patrick Lauer gentoo.org> writes: > > On 06/23/12 21:21, Ciaran McCreesh wrote: > > There's been a move towards using slots for "clever" things that don't > > fit the traditional way of how slots worked. Examples include the new > > gtk2 / gtk3 handling and Ruby gems virtuals. > > > > Aside from being abusive, > No, it solves a real problem. > > this screws things up for Paludis users. > -EDONTCARE, use a supported package manager So if the packagemanager is struggling to resolve whether a package belongs in a slot or not, would this be a case for encoding such metadata in the ebuild filename. foo-slot2-3.2.1.ebuild This way the PM would be able to determine exactly what it has todo before it starts to parse the ebuild
[gentoo-dev] Re: [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
Ciaran McCreesh posted on Sun, 02 Sep 2012 20:04:11 +0100 as excerpted: > The big issues you're ignoring: > > * What to do if a package has an SDEPEND upon cat/pkg[x] and the user > has cat/pkg[-x] installed, or if another package in the resolution > depends upon cat/pkg and the user hasn't specified USE=x. Similarly, > an SDEPEND upon >=cat/pkg-2.1 and the user has cat/pkg-2.0 (which is > in the same slot as 2.1) installed. The right answer is to force a > reinstall with [x] / force the upgrade, and for the spec to explicitly > require this from implementations, but *why* this is the case is > fairly subtle. > * What use? blocks in SDEPEND actually mean. Again, there's a right > answer here: it's for when a particular suggestion requires the base > package to be built in a particular way. Reading here, the above "right answers" look self-evident to me, but I'm assuming the "somebody else did it so it looks simple" principle applies and I'm simply not seeing the too easy but wrong trap-answers. It would be quite helpful if you'd briefly describe them as you did the "right answers", along with (if it's not apparent given both them and right answers) why they're traps, as well. You mention the significant work it was to get these right for kbuilds and exherbo down-thread, and I'd imagine so. But with these "right answers" looking self-evident and no knowledge of the traps you had to avoid to get to them, it ends up looking far simpler than I imagine it was, and given that we're discussing specs for the gentoo solution to the same problem, having someone explicitly point out what and where the traps are in ordered to avoid them could be quite helpful indeed. Thanks. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
Fabio Erculiani posted on Sun, 02 Sep 2012 21:38:26 +0200 as excerpted: > On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh > wrote: >> >> The big issues you're ignoring: > > And you call them "big issues"? > Ah, the "you're ignoring" part looks a bit arrogant, are you short with > arguments ;-) ? Observation here, but he looks to have at least /had/ arguments. Your post OTOH was rather "content free" other than the flaming. If you can't post anything substantive please just avoid the post entirely. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
