[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Peter Volkov <[EMAIL PROTECTED]> writes: > This variable will be used in eclasses so it's better to avoid portage > in it's name, since not only portage will work with it. GENTOO_JOBS is > really something new in sense of consistency. EJOBS looks most terse for > me but I'll be ok with any name... It's just I don't want to end up colliding with other stuff like EclipseJobs or something else. And my reason to not propose PORTAGE_JOBS is actually that it suggests relation with -j option to emerge rather than make ;) > For load average may be it's good to use another variable to avoid > overloading of "JOBS" meaning? Agreed, easier than ending up having to parse a variable content, after all environment variables are kinda cheap. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpymSA9M4q04.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
"Alec Warner" <[EMAIL PROTECTED]> writes: > Looks Good To Me, but I would prefix the JOBS variable with some sort > of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other > systems that may use JOBS internally already (seems vaguely likely). Good point, GENTOO_JOBS sounds good to me. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp8ZBisU9A7b.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Tiziano Müller <[EMAIL PROTECTED]> writes: > What do you do for other build systems which also decide on load-basis > how many jobs to run? Parse again? > In that case I'd like to see a more abstract definition of "how many > jobs to run in parallel" which gets translated to the correct > make-options for emake and which is query'able either via a variable or > a function (something like JOBS="load=0.7||max=3" maybe?). If you can come up with a good enough syntax. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp0CultBim8Q.pgp Description: PGP signature
[gentoo-dev] [RFC] Create a JOBS variable to replace -jX in MAKEOPTS
Since not all the buildsystem we support use make for the actual build,
and they don't necessarily support make-like options (-jX -s and so on),
it would be nice to be able to express a JOBS variable that could be
used for parallel build with any build systems.
Right now there are ebuilds like openoffice or some scons-based ebuilds
that parse MAKEOPTS and get out of that the number of jobs from the -j
option, but this is a) suboptimal b) error-prone.
One has to consider people might be using -l for parallel building too,
for which reasons I'd be suggesting doing something like this to make
the change transparent:
- ebuilds using non-make build systems would use JOBS;
- ebuilds using make builds systems would just use emake as usual;
- Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS;
- if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS};
- if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l).
The result is that you can finally combine -l with parallel build on
OpenOffice and other packages, with a fallback number of maximum jobs
instead of using load-based decisions.
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
pgpcOEYmHztqL.pgp
Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
James Cloos <[EMAIL PROTECTED]> writes: > Searching is an important reason for every package to specify its homepage. And? metadata.xml already contains data that eix and other software should be able to search in (like longdescriptions), and having each package in kde-base report http://www.kde.org/ as its homepage is kinda pointless if you think about search, since that's not data, it's noise. Which only adds to my point. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpS3fcWfM3UH.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
"Alec Warner" <[EMAIL PROTECTED]> writes: > That being said I still don't see the usefulness here. > > You seem to think that using the existing APIs for this data is wrong, > and I think the opposite, so I guess we will agree to disagree on this > matter. Yeah I still think that there is no point in requiring using of a specific API when the same data can easily be available in a format that is more or less parsable with ease in any modern (and non) programming language. Beside, I find expanding the HOMEPAGE syntax to allow more than one link a bit ... overkill, if the same thing can be achieved in metadata.xml... >> Beside, if you really want to go down that road you should be counting >> that beside ReiserFS with tail, I don't remember any other Linux FS that >> has block smaller than 512bytes, which means that each file in metadata >> cache is taking up much more than just its size in characters. >> >> All your math is thus wrong. > > As was pointed out on IRC, UTF8 characters are not a fixed size, > making my math even more wrong ;) If we consider HOMEPAGE, the assumption that characters are fixed size to 1 byte is good enough; URLs are usually encoded in pure ascii character space for compatibility; while IDN would break that assumption, we can't even assume that IDN is always available and so on. For description maybe it's different because there is space there for UTF-8 characters, but that's going to bring us even farthest than the point. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpfg98QhGFq3.pgp Description: PGP signature
[gentoo-dev] Re: debug/release builds extensions/clarification proposal
Maciej Mrozowski <[EMAIL PROTECTED]> writes: > - USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not appropriate What are you saying here? I'm afraid you're mistaken here. For the most part, USE=debug means "enable debug code paths", which for lots of projects simply means "enable assertions"; there are packages that take this as "enable debug symbols too" but I don't think that's very valid since users might want debug code paths but not symbols and vice-versa (I indeed have debug symbols bug no debug codepaths enabled). Now just to make sure the common misconceptions don't hit again: - -ggdb *does not have any runtime performance hit*; neither in execution time nor in memory usage; the debug sections are not mapped into memory at all; this is true for both non-stripped and split executables; - -O0 is not always a good idea; beside bugs in packages concealed by -O1+ [1], there are some further points: missing registers on x86 causes build failures, and if ( 0 ) cases are not optimised away, resulting in stuff like FFmpeg not to link properly since undefined references are not pruned away; this means that using -O0 unconditionally for any package for debug is not really an option; [1] http://blog.flameeyes.eu/2008/09/02/testing-the-corner-cases -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpJ5ioEeo3pE.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
Jan Kundrát <[EMAIL PROTECTED]> writes: > But also the need to replicate http://www.kde.org/ to metadata.xml of > all KDE split ebuilds -- right now, this is set by an eclass. The usefulness of this is IMHO debatable; why not just writing it one package (say kde-base/kde or kde-meta) and just there? Having each mini-package express itself as having that as its homepage is not very useful to me, but I guess it's debatable. >> - allows proper handling of packages lacking a HOMEPAGE; > > Could you elaborate a bit about how different is handling of an > empty/uninitialized shell variable from an empty XML element? That you can provide _other_ links beside an homepage, like "unmaintained", "gentoo:userguide" and stuff like that so that user don't just get no homepage at all, and they are not misdirected by homepage being http://www.gentoo.org/ or something. >> - users can check the metadata much more easily by just opening the xml >> file or interfacing to that rather than having to skim through the >> ebuild, the xml files are probably more user readable then ebuilds >> using multiple eclasses; > > Haven't we already agreed that accessing ebuilds/... directly is > broken by design? For a software sure, but as an user I am automatically brought to just look at the files if I'm looking for the homepage of a package I know, and seeing a metadata.xml file I'm more likely to look at that rather than the metadata cache in /var/db/... . And it's certainly more user-readable an XML file than HOMEPAGE with depend-like syntax for labels and conditionals and whatever else seems like Alec is proposing for EAPI=3 >> - webapps like packages.gentoo.org would be able to display basic >> information without having to parse the ebuilds or the metadata cache. > > Except for the ebuilds which still use the old format (that is 100% of > the tree right now) This of course is meant as "whenever this is fully implemented" -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpfOxlYEmqMh.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
"Alec Warner" <[EMAIL PROTECTED]> writes: > - Space savings. Certainly your scheme may be smaller, but the XML > tag overhead may eat into the savings. You should do some estimates > to show the community how much smaller the tree will be from this > proposal. Sorry but you lost me on any point you might have brought across since after this I feel like you were trying to put words in my mouth. Beside, if you really want to go down that road you should be counting that beside ReiserFS with tail, I don't remember any other Linux FS that has block smaller than 512bytes, which means that each file in metadata cache is taking up much more than just its size in characters. All your math is thus wrong. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpcFFtmtOt8h.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
"Alec Warner" <[EMAIL PROTECTED]> writes: > Diego, What are the concrete benefits of your proposal? As I said: - no need to replicate homepage data between versions; even though forks can change homepage, I would expect that to at worse split in two a package, or have to be different by slot, like Java; - allows proper handling of packages lacking a HOMEPAGE; - less data in metadata cache; - users can check the metadata much more easily by just opening the xml file or interfacing to that rather than having to skim through the ebuild, the xml files are probably more user readable then ebuilds using multiple eclasses; - displaying info about the package does not require parsing the full ebuild file, with its eclasses; - extensible to provide more links than just the homepage (forums, trackers, gentoo-specific documentation, ...); - if we also move DESCRIPTION, search software can ignore everything about ebuild parsing, and just use the metadata.xml files; considering how many people actually use or used eix, it would make sense to allow third-party applications to be able to search through the tree; - webapps like packages.gentoo.org would be able to display basic information without having to parse the ebuilds or the metadata cache. - as much as people might think metadata is easier to parse than anything, XML has one huge advantage: there are plently of parsers for any language without having to actually write one, even as easy as it can be, and it's easily interfaced with anything; I wrote a simple XSL file that outputs the basic metadata details for packages without having any parser or executable code but xsltproc (or any other XSLT software), correlating data with herds.xml too; - it really is metadata, and it makes very little sense to need parsing of eclasses and EAPI handling to get some data from a package that is non-functional in nature and free form (just like DESCRIPTION, and unlike LICENSE like Alec said), and that changes at worse once each slot (unlike LICENSE that can change at any given version). Disadvantages: - it requires user-interface software to parse metadata.xml to show data for a package; which is already needed to show per-package USE flag meaning; General points: - it does not solve unrelated problems like code replication; Can someone come up with any other point beside "I don't like XML" (which I already said is a puny answer) and "it can theorically be 10 different homepages for 10 different versions" (which I have sincerely some beef with myself since if you fork a software you might as well change its name)? As I said, moving out the HOMEPAGE field from a package manager prospective is non functional; if you're showing to the user some data about a package you might as well show as much as you can, like long descriptions, other links, and USE flags. And the fact that you can ask the package manager for something is for me not a valid reason to avoi moving something in a more approchable place for other software. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpJevDGzJEf0.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
Tobias Scherbaum <[EMAIL PROTECTED]> writes: > "dev-java/sun-jdk" unnecessarily. Reducing this to restrict="1.4" isn't > easily readable as you'd need to know that restrict would specify a > slot. If your plan is to make it easier to find useful information about > a package (without using a fancy frontend, just reading the metadata.xml > with $EDITOR) slot="1.4" (or a version attribute) might be a tad more > human readable. Well if we go to these things we should just apply the same to the other attributes using restrict, since we want to have something coherent, don't we? ;) -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpqrcOBdsryo.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
Tobias Scherbaum <[EMAIL PROTECTED]> writes: > But what about additional slot or version attributes like > http://java.sun.com/j2se/1.4.2/ > (or a version attribute)? If slot and version aren't specified they'd be > interpreted as wildcards. The restrict attribute exists already and it's better to reuse the same code, isn't it? -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpJJ5dlUYEV7.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: > I have a very quick proposal: why don't we move the packages' homepage > in metadata.xml (since it's usually unique for all the versions) and we > get rid of the variable for the next EAPI version? I forgot to say that this also addresses, for the future EAPI, the problem of what to do with missing HOMEPAGE. We still have to find a solution for that on the EAPI 0, 1 and 2 though since it's a bit of a big problem when we point to domain squatters. If it was feasible to just make missing HOMEPAGE a softfail for the other three it would be even better. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp3NTn0n5kOR.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
Jan Kundrát <[EMAIL PROTECTED]> writes: > I believe the reason was that HOMEPAGE might change with new versions > and that metadata.xml didn't (doesn't?) support version-specific data. At least the maintainer and (iirc, at least that's how we proposed it the first time around) flag tags support a restrict attribute. But I really expect that as long as the package is the same, homepage is unlikely to change with version; maybe with slot I guess, but even that is debatable and somewhat rare I think. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpB5SH1b5Viy.pgp Description: PGP signature
[gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
I have a very quick proposal: why don't we move the packages' homepage in metadata.xml (since it's usually unique for all the versions) and we get rid of the variable for the next EAPI version? This makes it easier to get the package's homepage for submitting bugs upstream (you just do a single lookup for the metadata.xml file rather than checking the ebuild; ensures that homepage changes don't get stale for old revisions, avoids commits on old ebuilds for home page changes (and thus changes that propagates on mirrors, and so on. It also makes searching by homepage easier (a search program would take much less time to parse XML that an ebuild). I would propose an implementation of this that takes in consideration also older proposals of having a way to specify upstream and gentoo-specific information, something among the lines of this: http://package.foobar.com http://package.foobar.com/bugs and for gentoo-specific http://www.gentoo.org/proj/en/foo/foobar http://www.gentoo.org/doc/en/foobar.xml Please submit all comments, as long as they are not "I don't like XML" or "XML is the wrong answer" and similar since the point here is not to discuss the format of metadata but rather where to have it. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpKz8EqcCHvB.pgp Description: PGP signature
[gentoo-dev] Re: Name change s/drac/ssuominen/ for people wondering.
Samuli Suominen <[EMAIL PROTECTED]> writes: > This is for the people wondering who I am. And there goes for people not knowing the realnames of colleagues I guess ;) I'm glad I started calling people by first name whenever I write something :P By the way, I really hope you feel better now, and I certainly understand that sometimes when you hit the bottom you feel like changing your appearence, which online is... your nick ;) Keep it up and try to make it fun! -- Diego E. "Flameeyes" Pettenò -- who recently legally changed his first name http://blog.flameeyes.eu/ pgpfoekrffmOI.pgp Description: PGP signature
[gentoo-dev] Re: Please avoid absolute paths in patched filenames
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: > Fun, I didn't really notice it was an epatch specific code that failed, > I know it fails when the paths don't add up between systems and I > thought that was it.. Okay, I guess I'll get to fix the rest tonight > after Bones... All the tree should be sanitised now for what concerns patches in $FILESDIR ... It's up to you to see if there are broken patches on mirrors, I guess. My tinderbox will try its best to find them anyway. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp6W1we1FJi0.pgp Description: PGP signature
[gentoo-dev] Re: Please avoid absolute paths in patched filenames
Serkan Kaba <[EMAIL PROTECTED]> writes: > This check was added to epatch all of a sudden breaking all working > patches in the tree, although defending those patches having absolute > paths, we as Java team had several bugs filed due to that. Maybe the > tree should be scanned for those and fixed. Fun, I didn't really notice it was an epatch specific code that failed, I know it fails when the paths don't add up between systems and I thought that was it.. Okay, I guess I'll get to fix the rest tonight after Bones... -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpkepw47URBE.pgp Description: PGP signature
[gentoo-dev] Please avoid absolute paths in patched filenames
I ask it here as a favour, please avoid using absolute paths in the filenames of patched files. This mean avoid having stuff like --- foobar/foo.c +++ /tmp/foobar/foobar.c This tends to break from time to time, and I had to fix at least three packages since I started my treewide build for these problems. I already asked Zac about adding such a check on repoman, but in the mean time I'd like to ask here for people to verify their packages. I actually am culprit of doing this some time ago but I learnt my lesson the hard way :P My suggestion for everybody else is to use quilt when you need to write patches. And if you have patches with the filenames like I shown above, you can change it the git way so that it becomes: --- a/foobar/foo.c +++ b/foobar/foo.c and the problem is usually solved. Thanks, -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp1IcCBfPorv.pgp Description: PGP signature
[gentoo-dev] Re: Remember: workarounds don't warrant RESO FIXED!
Serkan Kaba <[EMAIL PROTECTED]> writes: > I think, resolving as UPSTREAM might be more logical as we can't force > every upstream to fix their *borked* build system and the bug will be > left open forever. If upstream refuses to fix an issue that _is an issue_ we have to fix it, not work it around forever and ever. RESO UPSTREAM is good for crashes that are left to upstream, but since Gentoo si abuilt building, build problems needs to get fixed. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpdnNkROqeW7.pgp Description: PGP signature
[gentoo-dev] Remember: workarounds don't warrant RESO FIXED!
Guys, please remember that if you work something around, you should _not_ close the bug as RESO FIXED but keep the bug open so that the issue can be addressed and fixed _properly_. Otherwise we'll end up with ebuilds full of workarounds without even documentation on why the workaround is applied! With workarounds I mean, as examples: - FEATURES=test failures; - broken parallel make that requires -j1; - flags filtering, included -Wl,--no-as-needed appending This is important because: a) we want test to work or get fixed upstream; b) we want users to get parallel build if they request parallel build; c) we want --as-needed to be used, not ignored. If the bug is open and comes out on searches and all the rest, then we have higher chances that someone might _fix_ it, without having to look to see if there actually is one... Thanks! -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp9wm4rF3mnl.pgp Description: PGP signature
[gentoo-dev] [RFC] simple-build eclass
I've already written about the possibility of creating an ebuild to
simply _replace_ the entire buildsystem of a package if it's
non-existant (simple .c file thrown around by upstream), too minimal
and/or impossible to get upstream do adapt, or as a temporary measure
until upstream is beaten into common sense.
The whole story can be found at
http://blog.flameeyes.eu/2008/10/15/fixing-cflags-ldflags-handling-with-a-single-boilerplate-makefile
I'm attaching a proof of concept of the eclass, it's certainly not ready
for prime time: it does not support C++ programs, it does not have
pkg-config support, and so on. But in general it should work, I'm also
attaching a reworked ebuild for uif2iso (package I maintain and for
which I had to _rewrite_ the whole Makefile already).
This gets especially interesting to consider if we want to enable
--as-needed by default, since this will allow easy fix for packages that
don't otherwise build with --as-needed, like habak that I had to fix,
and takes care of quite a few different problems at once.
HTH,
# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Author: Diego Pettenò <[EMAIL PROTECTED]>
inherit toolchain-funcs
EXPORT_FUNCTIONS src_compile src_install
simple-build_src_compile() {
cat - > Makefile <# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit simple-build flag-o-matic
DESCRIPTION="Converts MagicISO CD-images to iso"
HOMEPAGE="http://aluigi.org/mytoolz.htm#uif2iso";
SRC_URI="mirror://gentoo/${P}.zip"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""
RDEPEND="sys-libs/zlib"
DEPEND="${RDEPEND}
app-arch/unzip"
SIMPLE_SOURCES='src/*.c'
SIMPLE_LIBRARIES='-lz'
src_compile() {
append-flags -DMAGICISO_IS_SHIT
simple-build_src_compile
}
src_install() {
simple-build_src_install
dodoc "${WORKDIR}"/${PN}.txt "${WORKDIR}"/README || die "dodoc failed"
}
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
pgp7HRsrICOry.pgp
Description: PGP signature
[gentoo-dev] Re: packages up for grabs
Daniel Drake <[EMAIL PROTECTED]> writes: > dev-dotnet/evolution-sharp I was going to ask you about this last week, I guess I'll look into it (although it makes me feel dirty to work with .NET stuff, I've been working with worse stuff :P). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpg2jdRM4KaJ.pgp Description: PGP signature
[gentoo-dev] Re: virtualx eclass
Doug Goldstein <[EMAIL PROTECTED]> writes: > It'd be a lot more consistent if ebuilds provided a USE flag or directly > depended on the xorg-server and then used the functions in the eclass. > So in summary, those are the changes I plan on making very shortly. If > someone's got some input, please speak up. Kinda like good ol' kde.eclass: VIRTUALX_ONLY_TEST="yes" inherit virtualx and instead of using IUSE=X for that, IUSE=test. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp02mjr9xxds.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
Fabian Groffen <[EMAIL PROTECTED]> writes: > - x64 is what the vendors (Apple, Sun) advertise themselves Err I'm sure I haven't seen any x64 in the documentation or advertisement of my MacBook Pro, are you sure _Apple_ uses that totally bogus name? Anyway, em64t might be better, but then again you're to the same point: an Opteron using an Intel name? I think amd64 is totally fine since it's the first commercial name it got by uh, those who introduced it, I guess, but the only thing I don't ever want to see officially is endorsing the x64 commercial speak. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpfWJJfNdLak.pgp Description: PGP signature
[gentoo-dev] Re: Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
Jeroen Roovers <[EMAIL PROTECTED]> writes: > http://www.gentoo.org/proj/en/abandoned/ What about www.unmaintained-free-software.org? Possibly opening a page? -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/
[gentoo-dev] Re: sci-libs/scipy -> dev-python/scipy ?
"Alec Warner" <[EMAIL PROTECTED]> writes: > 'epkgmove' invokes bad memories for many ;) Thanks for ruining the few hours of sleep I'll get in the next days by bringing that name up... J/K -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpr7bNm44sJj.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: ChangeLog quassel-9999-r1.ebuild quassel-0.2.0_rc1.ebuild quassel-0.2.9999.ebuild
Thomas Anderson <[EMAIL PROTECTED]> writes: > The reason it's failing is because you have things after the . You > can do this: I actually don't... and it doesn't file for the git case, it fails for the non-git case (I only updated the git versions so the next time I copy over the git ebuild I don't have to fix it again) > Doing it my way doesn't fail for, say, -r1 -r1 has this values: P=quassel- PN=quassel PV= PF=quassel--r1 PVR=-r1 (was this the right variable name? I sincerely forgot) the -r1 part is only ever used for the revisions in PVR, not on PV. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpDthx7fgu6m.pgp Description: PGP signature
[gentoo-dev] Re: Suggested default LDFLAGS+="-Wl,-O1,--hash-style=gnu,--sort-common"
Fabian Groffen <[EMAIL PROTECTED]> writes: > as long as it doesn't go in /base, but in the linux/freebsd profiles > instead, it's fine with me. --has-style=gnu should not be used on non-GLIBC systems (I'm unsure about uclibc, but I'd be surprised if they do implement the GNU style hash). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpmivCa8PtPJ.pgp Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
"Santiago M. Mola" <[EMAIL PROTECTED]> writes: > * media-sound/amarok: live version is 1.4.. Next version is 2.0, > but that's a different branch so I'd expect 2.0.live to give me the > latest 2.0 version available, not 1.4's. 1.4. has been switched from because of the 2.0/1.4 branches, would be 2.0 (if I ever care enough to add that, not before a beta is released for sure, and not before I can use KDE 4.1 daily, which is not something I expect to happen soonish). Just FYI. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpvaSuTaiUhN.pgp Description: PGP signature
[gentoo-dev] Re: glibc-2.8 / gcc-4.3 build failures
Robert Buchholz <[EMAIL PROTECTED]> writes: > # [tracker] GCC 4.3 porting > https://bugs.gentoo.org/show_bug.cgi?id=198121 or https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.3 > > # [TRACKER] ebuilds failing to build against sys-libs/glibc-2.8 > https://bugs.gentoo.org/show_bug.cgi?id=225459 or https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.8 I love aliasing :) -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgprbDcyCeB7l.pgp Description: PGP signature
[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
Donnie Berkholz <[EMAIL PROTECTED]> writes: > I usually do something like this: I used to do that too, but it's quite slower than the */*/$blah, because it has to visit all the directories on the grep. Give it a try, took me quite a while to get used to it but it works nicely. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpG5kcB0pK0f.pgp Description: PGP signature
[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
Alin Năstac <[EMAIL PROTECTED]> writes: > According to my local copy, we have 12876 metadata.xml files. > Something tells me that your command line will exceed the maximum > command line length supported by any shell ;) I actually checked before saying that :) Both zsh and bash on my system can get that command line going just fine. I was sure of that already because I use very often egrep $something */*/*.ebuild to scan the tree for particular stuff. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpYjdQR0tGev.pgp Description: PGP signature
[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
"Chip Parker" <[EMAIL PROTECTED]> writes: > Although it'll be a bit slower than a direct grep: for m in `find > /usr/portage -name metadata.xml `; do grep -Rn foo $m;done Uh no you want xargs in that case. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpeHdSVH8uGY.pgp Description: PGP signature
[gentoo-dev] Re: lastrite: dev-cpp/libherdstat and app-portage/herdstat
"Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> writes: > The tree's small enough that grep -r gives enough performance. Even better grep */*/metadata.xml the tree is not big enough that it exceeds the maximum arguments from bash. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpQqdIwTnEXe.pgp Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Roy Bamford <[EMAIL PROTECTED]> writes: > 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider > it broken) Need to address better when a meeting is considered official (right now it's not addressed at all, so anything is better), for the rest is fine as it is. > 2. As one of the first priorities will be setting policy for pending > appeals what policy do you propose ? Council handles appeals, there's no conflict of interests: who gets voted in is already known to not be entirely impartial and/or being in charge of other decsion-making teams. > 4. How do you think the council and trustees can work together to make > Gentoo better? > Not just the code base but the cooperative environment we all work > together in too. > Disclosure - I have a personal interest in responses as a trustee. Staying independent one of the other, with no hierarchical relationship one way or the other. > 5. Tell us a little about yourself - the skills and experience you can > bring to the council? If you know me you know what I do, if you don't, I suggest just looking at my blog (http://blog.flameeyes.eu/) there it's all you have to know, and probably something you don't care about. > 6. Tell us one outstanding (in your own mind) contribution you made to > Gentoo in the last year. Last year? Being a council member already, I'd say. > Any candidate who does not have time/interest to prepare a manifesto > addressing the above and anything else they want to say to the > electorate will have a hard time convincing me that they have the time/ > interest to undertake the duties of a council member. You might want to revisit your ideas, unless you expect next council elections to require primaries first. I sincerely don't want to spend time to rewrite this as a "manifesto" because it makes really not much sense. I don't take an opinion _just_ for the election, my opinions are open to anybody to see. And I did have time and interest in stayin in the council for two terms already. With all sincerity, your "threat" makes me want to puke: if we're being forced to write manifestos, I might just as well reject my nomination, as I find that just useless bureaucracy. And no I won't be wearing a Gentoo logo pin on my lapel. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpTH5y8bbTuP.pgp Description: PGP signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
"Łukasz Damentko" <[EMAIL PROTECTED]> writes: > Nominations for the Gentoo Council 2008/2009 are open now and will be > open for the next two weeks (until 23:59 UTC, 18/06/2008). I wish to nominate Halcy0n, Cardoe and leio. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpeaQMLjTTgU.pgp Description: PGP signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Josh Saddler <[EMAIL PROTECTED]> writes: > flameeyes I'm glad to accept the nomination. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpLZOrCacFcT.pgp Description: PGP signature
[gentoo-dev] Re: Remember, please don't use upstream-provided bootstrap unless necessary
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: > Please refrain from using those if you can. As I was asked for an example see this commit I made today: http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-backup/boxbackup/boxbackup-0.10.ebuild?r1=1.9&r2=1.10 the original ebuild used the bootstrap script (in src_compile by the way, which is very bad for me), and depended on autoconf directly, without forcing which version should have been used. The new version instead uses autotools.eclass, calls eautoreconf, sets its AT_M4DIR as the bootstrap script did (and again, ACLOCAL_AMFLAGS is what upstream should have used). This way warnings and errors from autotools won't be seen by the users, but will be logged in case stuff fialed, and you don't have to rely on the bootstrap script not making stupid stuff. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpL2ZKCbyV3n.pgp Description: PGP signature
[gentoo-dev] Remember, please don't use upstream-provided bootstrap unless necessary
I stumbled across another ebuild today that used the upstream-provided bootstrap script to rebuild autotools. Please refrain from using those if you can. Upstream doesn't always know better for our setup (it may try to second guess our settings by looking for particular automake/autoconf versions), it will show to the user information we don't care about, almost all the bootstrap scripts I've seen don't even try to catch when a step in the rebuild fails, they mask the need for autotools, and as you don't inherit autotools eclass for running them, you usually forget to add the autoconf/automake dependencies. And it makes very difficult to track down which ebuilds do actually use autotools to track down if there are changes to do. Let's not even start to talk about bootstrap scritps that run ./configure by themselves, those are just plainly evil. Please note that sometimes the bootstrap script is used to add extra m4 search directories and options like --foreign to automake. Well, here's the deal: - AT_M4DIR is the variable to use to pass extra m4 search directory to aclocal, no need for the bootstrap script; - eautomake takes care by itself to identify the cases where --foreign is needed (this usually means when some of the standard documentation files are missign); beside, if upstream is providing a bootstrap script for just these two reasons, then it's time they learn about ACLOCAL_AMFLAGS. Also make sure that autotools gets not rebuilt through maintainer mode, that will make the configure run twice, wasting users' time, and is usually evil if you are using unpack to check for the generated configure (yes it happened to me a couple of time). THANKS! -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp2TEcsoe1ye.pgp Description: PGP signature
[gentoo-dev] Re: packages up for grabs
Mike Frysinger <[EMAIL PROTECTED]> writes: > dev-util/elfsh I'll take a look, I might have some use for this. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
David Leverton <[EMAIL PROTECTED]> writes: > It's not just the order, it also breaks things that rely on the .init > section being called at all to register themselves with the core > application (with --as-needed, the .so doesn't get loaded in the first > place, so it doesn't get a chance to run anything). This really is backward, solution-wise: you expect the "core application" to know enough of the plugins to link them together, but not enough to call their init functions... And still, it breaks not only with --as-needed but also with the Sun linker, with the PE file format and other non-ELF file formats. So it's really not a problem _limited_ to --as-needed. Beside, you can _force_ a link by using --no-as-needed before a given library, that's what it's supposed to happen if you don't want to be helped by the linker. To a very minimum this can be said to be a _clash_ between two designs. Saying that --as-needed is _broken_ because it breaks this case is _quite_ an exaggeration... -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpDGGzHF7XVV.pgp Description: PGP signature
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Rémi Cardona <[EMAIL PROTECTED]> writes: > --as-needed breaks legitimate C++ code, I have yet to see it break > plain C code (but I could be wrong). This because C does not have constructors or static objects. I suppose I can write a couple of C files that can present the problem, but really, they would break as soon as I change the loading rules by moving to a non-ELF system or a different dynamic loader. It's interesting to note that Microsoft _did_ think of this problem when designing the .NET framework, and they answer is ensuring just that the static constructor will be called (right) before any static method or attribute is referenced and (right) before any object of the given class is istantiated. They don't get otherwise an absolute order in which static constructors are called. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp6Q7c1XvJEy.pgp Description: PGP signature
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
"Santiago M. Mola" <[EMAIL PROTECTED]> writes: > --as-needed breaking legitimate code is a problem, though. I wonder if > we have that kind of code in any application in the tree and if we > have some way to detect it. You could be looking for code not supposed to work under Solaris or Windows, as the --as-needed behaviour behaves a lot like the standard Sun linker and the forced behaviour of the PE executable format. The only thing that can be broken by using --as-needed is code that assumes the order in calling the .init sections of a set of shared objects. Such an order is not only changed by --as-needed usage but by any other change in the loading mechanism. It is strictly related to glibc at this point as far as I can tell. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpNOhQiIWOXd.pgp Description: PGP signature
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Marius Mauch <[EMAIL PROTECTED]> writes: > That's what `emerge @preserved-rebuild` does, or do you mean something > different? I meant something different, see the rst. > Well, with preserve-libs the situation is this (using your example): > - user upgrades expat, portage keeps libexpat.so.0 around > (some packages might now be linked against both versions if the session > included other packages as well) > - emerge tells the user to rebuild all affected packages (affected = > contains libexpat.so.0 in NEEDED, so includes both libfoo and bar) by > using `emerge @preserved-rebuild` (in the future this could also be done > automatically, but that won't be before 2.2 final) > - when all affected packages have been rebuilt (so their NEEDED entries > don't contain libexpat.so.0 anymore) libexpat.so.0 is automatically > removed Okay this works if the user follows the procedure and tries not to bend the rules... > So, if I understand you correctly (probably not), you want portage to > prevent the user from building any packages depending on any affected > package before the last step is completed? Yes this is exactly what I meant. Whenever a dependency is in the @preserved-rebuild set, it should not be linked against. It could still be used, but as now we don't have an easy way to distinguish between the two, I'd say it's better to check both DEPEND and RDEPEND and disallow its usage as a dependency until it's removed from the set. > Whoever that is is welcome to voice his opinion here, that's the point > of this thread after all. (It was mostly a disclaimer so that users don't feel like they get ignored without just cause if they want behaviour X and instead we go with behaviour Y... I'm sure a lot of people wouldn't like the option I proposed above, but trust me there's a reason why I voiced that concern :) ). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpblyTC9Kg3X.pgp Description: PGP signature
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Marius Mauch <[EMAIL PROTECTED]> writes: > Also it is not going to be a perfect solution against all runtime link > errors, but if enabled it should eliminate the need for revdep-rebuild > in most cases. I'm afraid that it will turn, for complex libraries like libexpat and users not using --as-needed, the message telling you the program cannot be started with subtle crashes for symbol collision. preserve-libs would be quite perfect if all libraries out there used versioned symbol, but this is far from true (and some systems Gentoo runs on don't even consider versioned symbol to begin with). Example at hand? When the libexpat transition started, the choice of keeling .so.0 around with .so.1 was discarded right away because: - library libfoo links to libexpat; - program bar links to libfoo; - user is not using --as-needed, so bar has a NEEDED against both libfoo and libexpat; - user rebuilds libfoo, but not bar; or bar and not libfoo, the result is the same; - KABOOM! symbol collision and bar crashes. As much as we want preserve-libs to be an all-curing magic, it's not. When you need to replace a library you need to do so _for all its users at once_, if you allow it to be gradually you're opening the hellgate of symbol collision. My solution would be to disallow _building_ anything that is or depends directly or indirectly on a package on the set until it is removed, or at the request of merging "mickeymouse", depending on "bar", re-emerging libfoo first, and bar if the user is not using --as-needed (checking the NEEDED lines). With all due respect to everybody, the right course of action here has to be selected by people who knows how the runtime linker works, symbol collision and all the rest, as that's what's at stake here. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpR6kEe6MGbq.pgp Description: PGP signature
[gentoo-dev] Re: About herds and their non-existant use
"Robin H. Johnson" <[EMAIL PROTECTED]> writes: > The sole reason that isn't possible is that some teams would have names > that conflict with system accounts. While it's possible to override > those in the Gentoo mail server setup, the system account versions DO > receive a _LOT_ of spam because they are so common (eg mysql@, ldap@). What about standardising on a suffix too? [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] and then all the aliases following that [EMAIL PROTECTED] [EMAIL PROTECTED] and so on -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: About herds and their non-existant use
Luis Francisco Araujo <[EMAIL PROTECTED]> writes: > Unless a team can maintain several herds, I find the term 'herd' > confusing and better understood as 'team' instead. +1 on this. I always thought that if almost every dev misuses the term herd, it was because the term had to be changed, rather than the devs corrected... -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpFE7rWRh6si.pgp Description: PGP signature
[gentoo-dev] Re: Moving some packages around
Ulrich Mueller <[EMAIL PROTECTED]> writes: > A Lexical Analyser and a Parser Generator are also required by > IEEE Std 1003.1 (aka POSIX) as part of the C-Language Development > Utilities. > > So it doesn't make much sense to remove flex and bison from system. IIRC POSIX mandates vi too, and we don't have that in system. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpUtWRYxFly8.pgp Description: PGP signature
[gentoo-dev] Re: FRC: debtools herd creation
Yuri Vasilevski <[EMAIL PROTECTED]> writes: > I will be adding some debian build tools to the tree, and would like to > create the debtools herd to associate with the packages. Just please don't add Debian-OpenSSL ;) -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpJFtnW9Ug70.pgp Description: PGP signature
[gentoo-dev] Re: Bug wrangling
Steve Long <[EMAIL PROTECTED]> writes: >> It makes moving a bug from one package to another quite a complex task >> though, as it requires two confirmation screens... and trust me that >> happens often enough. >> > Shouldn't that just be scripted via pybugz? A GUI for that would be nice; > perhaps as a pida[1] module. Frankly it appals me that y'all have so much > time to write bash scriptlets and none to develop tools for your own > use. I like Bugzilla for the very reason I can look, comment and in general manage bugs with decency without needing client software beside a webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand even while I was hospitalised (not in the ICU though, that was boring). Anything that requires me an extra software is something that I'm more likely _not_ going to use. >> Plus that would work fine if we had a bugzilla for ebuilds only, but >> would you really mix categories together with Infra, Portage, Gentoo >> Hosted Projects, ... ? >> > Who cares? Uh, I do, as I tend to report a lot of bugs and I don't want to have to use the find command of my browser to see where the heck should I report it. Don't even get me started on template bugs that I use to mass-report problems. And probably most users would find the huge and long product list to choose from most likely confusing. Users can't get it right already with the short list we have, reporting bugs on Bugzilla product which have nothing to do with Bugzilla... -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpLxXSM4xO5z.pgp Description: PGP signature
[gentoo-dev] Re: LaTeX documentation
Alexis Ballier <[EMAIL PROTECTED]> writes: > - In some pkg_ functions so that it doesnt get removed; is this safe > for binpkgs ? that'll leave stray files, but that's more or less the > point of doing it like that. Cache being cache, I'd say that it should be done in the ebuilds installing the fonts in pkg_* functions. I'd say not in src_* because packaging up the cache is not what one wants in almost all cases, you wouldn't want a buggy TeX version creating broken packages when you can avoid that. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgplYuHKwq2Eq.pgp Description: PGP signature
[gentoo-dev] Re: Bug wrangling
Donnie Berkholz <[EMAIL PROTECTED]> writes: > Would it be possible to add the tree categories as products and the > packages as components thereof? It makes moving a bug from one package to another quite a complex task though, as it requires two confirmation screens... and trust me that happens often enough. Plus that would work fine if we had a bugzilla for ebuilds only, but would you really mix categories together with Infra, Portage, Gentoo Hosted Projects, ... ? -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpvHLX3kZ64t.pgp Description: PGP signature
[gentoo-dev] Moving some packages around
I've been thinking today that we have a lot of things in sys-devel that shouldn't probably be there, like pmake and bmake. I'd propose the following move, if nobody has arguments aginst those: sys-devel/bmake -> dev-util/bmake sys-devel/pmake -> dev-util/pmake sys-devel/bison -> dev-util/bison sys-devel/flex -> dev-util/flex sys-devel/autoconf-archive -> dev-util/autoconf-archive sys-devel/ac-archive -> dev-util/ac-archive sys-devel/cons -> dev-util/cons sys-devel/gdb -> dev-util/gdb sys-devel/omni -> dev-lang/omni Reasoning for the moves: - bmake and pmake are additional make commands from the basic one, G/*BSD will have their own in -ubin or -bin, while the rest of the system uses GNU make as sys-devel/make; - bison and flex should get out of the system package set, what clearer than moving them out of sys-*? They are not so commonly used so there should no compelling reason to have them installed on every system; - autoconf-archive and ac-archive are not really something for your system; - cons is not commonly used as build system, so should probably be together with the other not-so-used build systems; - gdb is not part of the system, this might be a problem for crossdev...; - omni is ... well not something I'd look for in sys; plus it's a compiler so it would probably suite dev-lang better. There are a few I'm not sure of because I don't know the package at all, or because I have mixed feelings about them: sys-devel/remake -> dev-util/remake sys-devel/sparse -> dev-util/sparse sys-devel/distcc -> dev-util/distcc sys-devel/icecream -> dev-util/icecream sys-devel/m4 -> dev-lang/m4 sys-devel/patch -> app-text/patch sys-devel/prelink -> sys-apps/prelink (something else? It's not a devel package...) sys-devel/autogen -> dev-util/autogen sys-devel/dev86 -> dev-lang/dev86 sys-devel/bin86 -> dev-lang/bin86 sys-devel/gettext -> app-i18n/gettext (well, it's part of system for G/FBSD, but I'd rather have deps expressed properly...) Yes these are a lot of moves, sincerely I think sys-* categories are a bit bloated as they are, and I suppose we should start moving the things around rather than waiting forever ad ever.. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpmmXnU0kfAK.pgp Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh <[EMAIL PROTECTED]> writes: > You miss my point. GNU tar sometimes changes its on disk format (and > will be doing so again at some point for xattrs) It's not really important to the discussion, but... The TAR format is designed as such that on disk formats can be extended without breaking entirely backward compatibility. For what it's worth, extended attributes and ACLs are already supported by star (Schilling's) and bsdtar (libarchive). The fact that GNU tar doesn't support them at the moment is a different problem. On the other hand, even if the GNU tar does not support reading those attributes, it does handle them gracefully, warning the user of unknown extended headers, and then proceeding to unpack the data without preserving the extended attributes. So what Doug said stands perfectly and does not interest GNU tar at all. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpP94k0pAIHZ.pgp Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
Graham Murray <[EMAIL PROTECTED]> writes: > Should that be USE=-cxx? The help for USE=cxx says that this builds > support for C++. It was meant as setting a cxx USE on the ebuild, I wasn't certainly meaning to disable the C++ parts with USE=cxx enabled ;) -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpZoYJGuVAYM.pgp Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
Duncan <[EMAIL PROTECTED]> writes: >> So it would also be possible to compile "lzmadec" without any need for >> C++. Just call "make" in subdirs liblzmadec and lzmadec. > > What about USE=decode-only or something similar for lzma-utils, then? If > desired, it could even be masked on "normal" profiles, but would then be > there for the embedded and releng folks. USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. (BTW I considered using lzma for backup compression, but I didn't get much different results from bzip2 in term of size, but took quite longer in case of compression... I still have some doubts whether lzma is worth it). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpRSDaMmZtfS.pgp Description: PGP signature
[gentoo-dev] Re: Automagic dependencies in gegl
Hanno Böck <[EMAIL PROTECTED]> writes: > Beside, I'm asking myself how to handle this situation. Hard-enable them all > as long as there are no patches? Let the automagic go in the tree? Opinions > welcome. Automagic has _not_ to come to the tree, so hard-enable them all is the way. Have you looked at automagic.xml? It should help you for the task, and if it doesn't, I can see to extend it. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp2shTJ9UczV.pgp Description: PGP signature
[gentoo-dev] Reminder: re-run autotools if you change Makefile.am/configure.ac!
Please remember to re-run autotools if you change Makefile.am and/or configure.ac (or configure.in if the package uses the old name, or configure.in.in for KDE-based packages). Especially with autoconf 2.62 release this becomes important as some package might try to re-run autotools on its own and find different versions, dying of an horrible death. Also, remember that unless the package you're using is _not_ using automake (and thus aclocal), you should not run eautoconf, but eautoreconf instead. In general if you're unsure, just run eautoreconf. Exception can be made if you only touch Makefile.am, eautomake knows to run eautoreconf if the versions of the tools has changed, but again if you're unsure, just run eautoreconf. Yeah of course it makes waste time to the users to re-run autotools entirely, but it's better making every user waste those 30 seconds rather than having users complain that $foo doesn't build at the next autoconf bump. Or right now considering the amount of packages that fails with autoconf 2.62. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpCG22ilYd0X.pgp Description: PGP signature
[gentoo-dev] Re: New global USE flag: keyring
Peter Weller <[EMAIL PROTECTED]> writes: > 1) Nice and simple. Just force all packages to compile with > --gnome-keyring *cough* pambase *cough* So discard this idea already, removing the flag is not an option... unless you want pambase to stick with gnome USE flag as I did in origin. (I admit I didn't check if Remi renamed it or not, but he asked, so...). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp9gQ8NFvmG8.pgp Description: PGP signature
[gentoo-dev] Re: Removing .la files...
Petteri Räty <[EMAIL PROTECTED]> writes: > You would have to fix the vdb too. Which is the tricky part, and the reason why I didn't instruct anybody to do the sed on my ChangeLogs.p -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Removing .la files...
As those who _did_ ask me directly why I decided to do this did not think it was worth mailing - as they didn't - I suppose I should chime in now. Leaving alone what Petteri already said, this was intended to be a change on a series of single packages, the domino effect that happened I didn't foresee, on my system it was just a matter of five packages and a quick look at the revdeps didn't show _such_ an effect. Well maybe I expected a few problems with libogg, but yeah that doesn't seem to be the problem here, the problem seems to be with popt. For what popt is used (parsing of command-line options) I didn't expect it to creep in in so many libraries. And as the problem does not break any system - systems will still run perfectly - and can be solved with ease - just run a revdep-rebuild - I did consider this a pretty minor drawback on the whole. libogg and popt are now masked, and they'll wait a bit before return to ~arch that way. libmpcdec, libmad have very few library users so I don't expect major problems with those and I left them untouched. Same for libpam which should really _not_ be used by libraries beside a few very rare cases, if it was there is something _very_ broken. Probably the best thing would be to get a better tool than revdep-rebuild to handle broken .la files, as revdep-rebuild forces a timewasting rebuild, while a good fix could be just a sed -i -e 's:/usr/lib\(64\)\?/lib\(.*\).la:-l\2:' on all the .la files, installed and being-installed. By the way, asking a question is not poisonous. "Wulf C. Krueger" <[EMAIL PROTECTED]> writes: > Especially since even though removing .la files might make sense (with > exceptions, of course) we should think about either doing it > distribution-wide or not at all. Can't be done distribution-wide, as stuff would break way worse than this for sure (stuff is not going to link, or will fail at runtime). You _have_ to do it on a case-by-case basis. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpA75CPKwsyT.pgp Description: PGP signature
[gentoo-dev] Re: Help offered - Portage tree
[EMAIL PROTECTED] writes: > Then the chief architect of > Sabayon is scotched over bugzilla output? Can I declare myself Chief Architect of unieject? Does that give me right to take and fix others' software without passing through the usual ways? Counting titles seems more an HR thing to me than looking at behaviour. [and I didn't even want to write to this topic] -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpLV5Q12WHWy.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Renaming the caps USE flag to libcap
Tiziano Müller <[EMAIL PROTECTED]> writes: > Well, I'm not sure whether libcap is a good choice: What about > (not-yet-existing) apps which provide capability-support through another > package (like a foobar language libcap-wrapper)? Should they also use > libcap then? Uhm, good point. What about fscaps for the other case then? Or filecaps? -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [RFC] Renaming the caps USE flag to libcap
I'd like to propose the rename of caps USE flag to libcap. The reason for this is that I'd like to free the "caps" USE flag from the (runtime) dependency of libcap, so that, one we have the framework to do so, we could use the "caps' USE flag to set file capabilities directly (rather than setuid for instance). The step right afterward would be, for me, to find a way to mirror the capabilities from within Portage. I admit I have no clue how to achieve that for now. But at least the rename is a simple task, and I suppose the capabilities handling _could_ be a SoC project... -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Proposal for (next year's probably) SoC
I think it could be useful to learn from other projects' handling of SoC. The FFmpeg project has a list of "qualification tasks" for the students to complete before they can accepted into SoC, as you can see From [1]. The tasks are minor tasks that don't require a lot of time at hand, but gives a good way to judge if the person is in for the experience or the money, and might be able to cut the deal even for Gentoo devs if that is really wanted. How to implement it for Gentoo? Well I think we have the tool already: Bugzilla. We just need to add a keyword SOC_QUALIFICATION_TASK; when a developer think of a working qualification task, he can add the keyword and CC the soc team or something like that. Then the users can deal with the problems whenever they want, for the next SoC, even during the year. When they submit their application, we ask users to put the link to the bug that represented the qualification task they completed. To make the checking more easy, we could make sure that the person who completed the task is listed in the Whiteboard, and that only Gentoo devs can change that for the bugs for qualification task (letting only devs opening them, or cloning the feature requests from user that become a SoC qualification task, for instance). Then get a tracker that is blocked by all the SoC qualification task bugs, monitored by the SoC team, that can make sure how stuff is going with the qualification tasks, and finally add a default query for the tasks to the documentation about SoC. I'm sure we can easily get some qualification tasks on; with a bit more work we might also get qualification points (so that for instance minor tasks alone can't cut the deal). Maybe a bit complex, but I think it might be worth discussing. [1] http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2008 -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgplbNnqPp88m.pgp Description: PGP signature
[gentoo-dev] Re: One request for the next SoC: non already-devs students
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: > In the past two years we had quite a few applications from students that > were already full-fledged Gentoo developers. I sincerely would like that > this year we put as a rule that Gentoo developers cannot partecipate in > Summer of Code as students for Gentoo. Just to add material, Debian is also discussing a similar issue, see http://www.lucas-nussbaum.net/blog/?p=280 . -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp9DpQeBx80r.pgp Description: PGP signature
[gentoo-dev] Re: One request for the next SoC: non already-devs students
"Alec Warner" <[EMAIL PROTECTED]> writes: > Your entire argument is based on the assumption that the Summer of > Code program's primary goal is to recruit new developers for Open > Source projects. While this is one goal I am unsure if holding it > above the others is necessary. I know it's not the _sole_ goal of Summer of Code as intended by Google. But I do think it should be the main goal for Gentoo as a project. I also knew it was already discussed in the FAQ, and that there is no _Google_ rule stopping Gentoo developers from partecipating as Gentoo students. And that is why I'm bringing up the point on Gentoo ground. If this works, I'd take this time to add this as an official point for the next council meeting. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpa5jjojYtSp.pgp Description: PGP signature
[gentoo-dev] Re: One request for the next SoC: non already-devs students
Richard Freeman <[EMAIL PROTECTED]> writes: > Do we inspire them by telling them that anybody who has made this choice > in the past is not to be rewarded financially for doing so? This brings up a different point of view too. Why should just somebody be rewarded financially and not someone else? Why only people who are still in school, and not people who left school? I don't even want to think what might happen if there was something like Debian's DunkTank flame in here. > A bigger concern is this. Which is better for gentoo? Taking somebody > who has never worked on gentoo and paying them money to possibly > accomplish something on the project, or taking somebody who is already > doing quite a bit and pay them so that they can accomplish even more > without the distraction of a day job? Do you think that $4500 (which is, by now, less than €3000) during the summer will stop anybody already contributing from finding a day job? I sincerely don't think so. It does, though, help new people to _try_ working on Free Software. Students paid for SoC don't need to find a temporary job for that summer to build up experience (which is what I suppose most students would like to do, you can't expect a huge pay for three months of work _in the summer_), it's a good pay, for three months of work, but it's far from being a pay good enough for anybody to actively stop looking for a job. They will have to understand, though, that Gentoo is not a job and you won't end up always being paid to help that. Sincerely, I find the "without the distraction of a day job" argument to be pretty silly. How can an eventual, possible, not sure at all, and for sure not stable, check of €3000 once an year stop anybody from finding a dayjob? It's like counting on winning the lottery twice an year to sustain yourself. I live with my parents still, in the past years I had unstable jobs (paying more than €3000) during the start of the year and then had almost nothing between spring and winter, I have no monthly expenses, and I still struggle to find money to buy a new box. It might be an added incentive to get experience in Free Software rather than as a third-grade programmer helper in a small software company with most of the stable programmers taking weeks off for the summer, but for sure can't replace a stable job. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpVtsOBe18rv.pgp Description: PGP signature
[gentoo-dev] One request for the next SoC: non already-devs students
I know this is going to stir up quite some discussion, but I do think it's worth trying requesting it at least. In the past two years we had quite a few applications from students that were already full-fledged Gentoo developers. I sincerely would like that this year we put as a rule that Gentoo developers cannot partecipate in Summer of Code as students for Gentoo. I'm not asking to penalise Gentoo developers are students. But I sincerely think the main goal of Summer of Code is to allow new people to enter the scene of Free Software, to understand how Free Software projects work and so on. Gentoo Developers are already pretty well "inside" this world. I think it should be a self-made decision to abstain from applying as a student for what you already partecipate in, but as such concerns don't seem to be widespread (at least as the last two years shown), I'm asking for a formal decision to all the developers. If that is requested, I'm even willing to bring this in front of the council. Gentoo's ranks are quite reduced nowadays, and a few persons have shown conerns about our current recruiting methods being able to judge clearly technical and social skills, as well as the time one is ready to pour into the project. I think SoC could be used as a pretty good recruiting method: as you are going to work quite a bit with the student, you can easily judge availability and technical and social skills. Leaving SoC applications open to developers means wasting this opportunity. There are many other organisations partecipating, I think it would be quite feasible for Gentoo developers wanting to be a student SoC to choose another one, in which they are not involved already. Yes it's easier for them to do something for Gentoo as they are already contributing, but that is not the point of Summer of Code, the point is to introduce new people into projects, not giving money to people to do what they already do. And just to take a stance, even if this request is to be rejected, I'm not going to mentor a student that is already a Gentoo developer, for sure. So to be clear, I'm not trying to look down to anybody, I don't even want to stop people from being paid for their work. I just wish that we can focus this opportunity to improve the Gentoo project as a whole. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpRBzwP21UZC.pgp Description: PGP signature
[gentoo-dev] Re: [EMAIL PROTECTED]: Google Summer of Code 2008 is on!]
Grant Goodyear <[EMAIL PROTECTED]> writes: > I'm willing to help if help is wanted. I already offer myself as a mentor if we get accepted. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpEQEI74mHlp.pgp Description: PGP signature
[gentoo-dev] net-misc/zsync destiny?
I was just looking around in package.mask to see if I forgot to get rid of something, and I've noticed that zsync is currently masked because it contains an internal _vulnerable_ copy of zlib. It is currently maintainer-needed, so I don't see anybody actually fixing it to use system zlib anytime soon. Any reason why it isn't simply lastrited unless someone wants to maintain it? Treecleaners? -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/base/pam: upgrade-0.99.xml
On Sunday 24 February 2008, Robin H. Johnson wrote: > Why did you take the version on the document backwards? Because I mistyped it. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Keyword amd64 -> x86_64
Marius Mauch <[EMAIL PROTECTED]> writes: > - x64 is IMO the worst name for the architecture (originally a MS > marketing term later adopted by Sun, looks too similar to x86, name > doesn't make any sense really if you compare it to x86) Marius said all I wanted to say on that name. Beside, does it really changes stuff for anybody beside Intel fanboys? -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpJcqFsPOsVT.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] global useflags
Steve Long <[EMAIL PROTECTED]> writes: > Well if you're going for a widely-known acronym outside Gentoo-land it'd be > decss: http://en.wikipedia.org/wiki/DeCSS > > I've always wondered why that wasn't used in the first place (not that it > helps now; just found css odd for the same reason as others.) Because DeCSS and libdvdcss are not the same thing. It's like calling "acrobat" the pdf USE flag: yeah Acrobat produces and read PDF, but it's not Acrobat you're enabling. libdvdcss uses part of the code of DeCSS to do its work, but it is not DeCSS proper. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ pgp85UDAW9VS6.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] global useflags
"Wulf C. Krueger" <[EMAIL PROTECTED]> writes: > Where is the pressing need to do that? Again, which current package would > use a re-defined "css" USE flag? No package would use it, and there is no _pressing_ need. I still think it's nicer to let the user understand. What if we had qt referring to quicktime, and no qt package just yet? Would it be okay for you not to be able to understand without looking up the flag if qt referred to QuickTime or TrollTech's Qt? (being all downcase helps not here, capitalisation would have helped distinguish between the two). > I don't think any user will expect media-video/undvd, app-cdr/k3b or > media-video/cinelerra-cvs to support cascading style sheets but rather > the other CSS stuff. :-) This assumes that users know that there are _two_ CSS technologies. Which I sincerely doubt. Note that even Wikipedia defaults CSS to Cascading Style Sheet. While it can't say anything aboug Gentoo users, it says a lot on how that particular acronym is perceived among the general public. And I see no compelling reason to stick with a bad choice just for the sake of not renaming an USE flag, when the alternative is to actually give back sanity to the flag naming. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] global useflags
Peter Volkov <[EMAIL PROTECTED]> writes: > Seems that this arose from media-libs/libdvdcss... Can we rename this to > dvdcss to make it clear that this have something to do with dvds and not > with web technologies? I'd actually agree on this, while css is currently just used for Content Scramble System, I don't think we're going to have that mainstream anytime soon. This CSS is tied to the DVD technology that people are trying to replace (also because of the CSS debacle); the Cascading Style Sheet is, well, not going to disappear anytime soon, in my opinion. While changing an USE flag on the run is not a nice thing for users, I think that disambiguating this is a good idea. _While_ users are supposed to look up USE flags, it's no use to call, for instance, "tar" the support for Tape Audio Recording, just because there was no "tar" USE flag before ;) So +1 from me for css -> dvdcss renaming. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] global useflags
Markus Meier <[EMAIL PROTECTED]> writes: > hdf5: Adds support for the Hierarchical Data Format v5 And what the heck is the Hierarchical data Format v5? :P But I admit it's still better than "Adds support for HDF v5"... > djvu: Enable djvu support Not much more useful than just "djvu". beside the capitalization should be DjVu (iirc), it would be nice to say at least what DjVu is supposed to be... > cxx: Enable support for C++ I'd rather use "Builds support for C++ (bindings, extra libraries, code generation, ...)" > css: Enables ripping of encrypted DVDs Are we sure that nothing intends css as Cascading Style Sheet? > fontconfig: Support for managing custom fonts via > media-libs/fontconfig A bit better, but it's not to manage custom fonts, more like custom fonts options... > highlight: Enable source code highlighting Uh? I don't really want to look what does make that an option worth an USE flag... > cvs: Enable CVS (Concurrent Versions System) support Maybe "integration" rather than "support", if it's always integration that is enabled... -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ pgp5fohpgFJfm.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Reducing the size of the system package set
Brian Harring <[EMAIL PROTECTED]> writes: > Don't suppose you have a url for their reasoning? https://bugs.gentoo.org/show_bug.cgi?id=151758 -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] Reducing the size of the system package set
"Santiago M. Mola" <[EMAIL PROTECTED]> writes: > Having a complete > deptree and having a small system package set should be independent > goals, maybe your proposal should focus on making possible to have a > deptree as complete as possible independently of what packages are on > system set. QA team already rejected such a proposal. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] Reducing the size of the system package set
Donnie Berkholz <[EMAIL PROTECTED]> writes: > What is your goal? Is there something you're trying to accomplish that's > impossible? It's clear that changing this would be a fair amount of > work, and I don't understand the benefits. With the current size of system packages set, having a complete deptree is impossible. You're one of the main followers of the idea that if a package is in system you don't have to depend on it, and I already talked to you about the problems there are with emerge -e world when for instance zlib is broken. So my goals are: - have a deptree as complete as possible; - being able to have an emerge -e world that actually builds first the stuff that's going to be needed (zlib before packages using zlib); - avoid overriding the system package set in profiles like embedded where stuff like autoconf and perl might not be wanted on the resulting filesystem. The first goal is a prerequisite if we want to move to other stuff like a true multilib-handling package manager (we don't want to force down the users' throats multiple copies of autoconf, considering it's a script, do we?) or proper cross-building environments. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ pgpYLuxQrTHV9.pgp Description: PGP signature
[gentoo-dev] [RFC] Reducing the size of the system package set
Here comes the official proposal, copy and paste from my blog with an extra post scriptum at the end. I already ranted about the fact that the dependency tree of our ebuilds is vastly incomplete, as many lack dependency on zlib; trying to get this fixed was impossible, as Donnie and other insisted that as zlib was in system, we shouldn’t depend on it at all. I disagree, and I would like to know why we can’t depend on a system package, but whatever. Anyway, as having a complete dependency tree is almost impossible because of that, I have an alternative proposal: reducing the size of the system package set. Right now system contains stuff like ncurses, readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so on. Those are packages that certainly would be part of any base Gentoo system, but are those actual part of the system set of packages? I sincerely doubt it. The reason of the existence of the system package set is related first and foremost to breaking circular dependencies: for instance if any package that used the C compiler would depend on gcc, then the packages that gcc depends upon would create a circular dependency between gcc and itself. Also, specifying libc in almost any ebuild would be quite pointless, as well as coreutils (or freebsd-bin/ubin) for cp, mv, install, … But why autoconf and automake? Well the easy answer is that those are often used without making sure they are depended upon explicitly… or at least this was the case till me and Martin added autotools.eclass to the tree; nowadays all the ebuilds using autotools should have proper autoconf/automake dependency already, and if they don’t they are broken anyway. So why leaving them in system? And what about m4? m4 is not part of a common Unix system, it’s just an autoconf dependency, why isn’t it just an autoconf dependency? For what concern the three main libraries, there aren’t that many packages using zlib directly nowadays, this is especially easy to spot on a system built with --as-needed, as without that you actually do see zlib used in every other binary, for indirect dependencies. Nor there aren’t tons and tons of packages using readline, or ncurses. Actually in my own vserver’s chroot I only found four packages using readline, none of them part of system: ruby with the readline extension (uhm I wonder if I should ask for this to become an USE flag, I certainly don’t need it and I’d rather get rid of it), psql from postgresql (which maybe it’s still good to have with readline compiled in, but I could easily get rid of), bc (which is just an e2fsprogs build-dep, and I could build without readline just fine), and mysql. A little bit different the status of ncurses, which is used by screen, gettext (only a build-dep, not needed for runtime on Linux anyway), procps, psmisc and util-linux (and I wonder why we don’t have a switch to turn it off), texinfo (wonder why we can’t remove it entirely actually) and yet again ruby. Still, I wonder why ncurses is in system rather than being properly on the dependencies list of those packages. As for perl, that’s probably a bit more justified, there are tons of packages using perl directly or indirectly, especially in build systems. But I would like those to depend on perl properly rather than having perl in system, as there are cases where perl is not really needed at runtime at least. And the only users of gnuconfig are the packages making use of the old and deprecated gnuconfig.eclass, or portage’s econf. Why can’t it be a dependency of portage then? There are probably other packages that should, in my opinion, be removed From system, but these are certainly some of the most common. Unfortunately there’s a recursive problem here: to remove the packages from system without breaking stuff you’d need a proper deptree, and to get a proper deptree you need to remove the packages from system. This is what actually stops me from proposing this right away… P.S.: So there are more things that were brought to my attention, like ssh, flex, bison, e2fsprogs, and so on. We should probably look into what to keep, rather than what to remove. Also, rocket proposed me to try building a stage with a slimmed down system. I could try, but it would be a waste of time if we then decide not to go this route, and that's _a lot_ of time that would go to waste, so I'd rather first see what the other devs think, before going to do the actual tests. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ pgpj6JMlVTszU.pgp Description: PGP signature
[gentoo-dev] Re: Projects and subproject status
Luca Barbato <[EMAIL PROTECTED]> writes: > - video: Hopefully nothing much beside trying to give the best and > freshest snapshots from the repository you started to know (mplayer, > ffmpeg, xine, vlc...Hi Diego =)) I'm involved just in one and a half of those ;) As for me, I mostly handle PAM (solo as usual). Current status: PAM 0.99 is stable on all architectures beside one, which means that PAM maintenance should be quite easier. It has been a few months till last release so the water is also quite calm. The upgrade was smooth for most people up to now, hopefully the documentation on that will suffice. Future plans: I hope to be able to complete the developers' documentation, it's mostly a matter of finding time to work on it again, probably I won't be able to make it before February, but I count on writing something starting mid-february. And for what concerns PulseAudio: Current status: 0.9.8 is in tree for a while but contains a few new features that should be tested well before marking it stable, so 0.9.7 is the current candidate. The new init script using Baselayout 2/OpenRC functionalities is well tested at this point and mostly waiting for OpenRC to enter ~arch. Future plans: again not before mid-february I'll see to write some user documentation about PulseAudio, like a Gentoo-specific Perfect Setup, to integrate the generic documentation available on PulseAudio's wiki. As for other misc stuff I maintain, I don't know exactly what's left, but you can easily see what I'm doing on the blog :P -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ pgpYdZPjU9Epq.pgp Description: PGP signature
[gentoo-dev] Last rites for media-fonts/mikachan-font
As per summary, I've just masked mikachan-font for removal. Don't panic! I'm not removing the mikachan font from portage. This package installs, depending on version, either a TTF font (TrueType Fonts files) or a TTC font (TrueType Collection); the latter is not compatible with some software, like GD if I remember correctly, that expects only TTF fonts. To get around this problem, mikachan is now split in three packages, each of which installs the same fonts in a different format: media-fonts/mikachan-font-otf OpenType Fonts media-fonts/mikachan-font-ttf TrueType Fonts media-fonts/mikachan-font-ttc TrueType Collection this way you can have fine grained selection of fonts to install. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp4Rpyq2lIaZ.pgp Description: PGP signature
Re: [gentoo-dev] Google Summer of Code 2007
On Saturday 17 February 2007, Ciaran McCreesh wrote: > So perhaps next time around mentors should accept concrete proposals > that are really doable, rather than stuff that just seems shiny. Gentoo > *could* benefit greatly from SoC, if things are done properly. Apocalypse day may come soon this year, but for once I agree almost entirely with you. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpUWJ8gda9JI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Google Summer of Code 2007
On Saturday 17 February 2007, Markus Ullmann wrote: > Also about last year, are there known improvements other mentoring > organizations had out of SoC? (Like KDE, GNOME,...) You can see the projects for KDE at [1], as well for the other organisations, but I'm not sure if they published the final overviews that the other projects published. For what I can see by skimming through soc-admins right now, PHP project launched a new version of [2] last october, with SoC work embedded; KOffice 1.6 contains at least two SoC projects results (KFormula and Krita improvements), as Luca pointed out FFmpeg got a working VC-1 decoder (and WMV3 came with that), and now the AC3 and AMR decoders are getting in shape; Amarok got DAAP support half working during SoC and completed afterward (in this case the developer was a previous Amarok developer anyway), 1.4.5 have working both client and server DAAP support. For boost you can look at [3], quoting: | Seven projects were completed or nearly completed and the students are | expected to ask for a formal review within 2006 or early 2007. Four of | these projects necessitated a goal reorientation during development, | basically because the original plan was too ambitious for three months. | Most of the projects are still in active development during the months | following the Summer of Code program. Two projects did not reach the | planned goals, but nevertheless produced useful material that could be | expanded outside of the Summer of Code program. One project was abandoned | shortly after the midterm review. The reasons for the abandonment are | unknown. And so Adium [4], NetBSD [5], Gallery [6]. There are a few more info that were posted directly on the list and as I'm not sure if they were public, so I didn't quote or copy out of them, and I don't have a pointer for them as the list is private. I didn't find anything from us, note even as a post on the list, which is somewhat disappointing. [1] http://code.google.com/soc/kde/about.html [2] http://gcov.php.net/ [3] http://boost.org/more/boost_soc_06_overview.html [4] http://www.adiumx.com/blog/2006/10/google-summer-of-code-2006-roundup.php [5] http://www.netbsd.org/Foundation/press/soc2006-summary.html [6] http://gallery.menalto.com/summer_of_code/2006/wrapup -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp2IIL7RpCjf.pgp Description: PGP signature
Re: [gentoo-dev] Google Summer of Code 2007
On Saturday 17 February 2007, Danny van Dyk wrote: > a) It's _qualudis_ ;-) Whatever, can we get back on track? How much good did Google Summer of Code to the Gentoo _community_ ? How much the project were of use for the Gentoo (Linux) project? [1] http://code.google.com/soc/kde/about.html -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgphnNh7HHtkr.pgp Description: PGP signature
Re: [gentoo-dev] Google Summer of Code 2007
On Friday 16 February 2007, Grant Goodyear wrote: > So, is there support among devs for hosting another round of Summer > students? Are there good problems for those students to work on, and, > if so, what are they? Were people happy with how last year's program > went, or should we try to do something different? For what it's worth, > I think GSOC is worth putting our effort into, but I'd also like to see > projects that at least have the potential to benefit more of the > community than just Gentoo. *Shrug* Although last summer I wasn't too involved in the process (I was backup mentor for a couple of projects, but there was no need for a backup mentor for any of them, and I also passed the august offline), I did think with myself of a few issues with what SoC did for Gentoo (and the other way around too). Out of the 14 projects listed in [1], these are the (public) results: - I don't know of any GUI frontend to baselayout; - Antarus's work on CVS migration produced some interesting results, but as we know, the migration isn't possible just yet; - blubb's etc-update replacement is sort of complete, I wasn't able to get it to work yet, but at least blubb is still around; - Gentoo/FreeBSD/AMD64 port is deadish, Victor disappeared for what I can tell, there weren't many patches that were followed till merge, and there's no near hope to get amd64-fbsd working in short time; - I have no clue what's going on with gentoo-stats; - Pioto's dynusers (now creandus, I think) is still work in progress, since starting, pioto became a dev; - I have no clue what's going on with the web-based GuideXML frontend; - JACK support hasn't moved a bit, if possible it became worse because of bitrot, as the student dropped off; - I have no clue what's going on with NetworkManager, but it might actually have seen some work on it, considering it's now in portage, but metalgod/steev would probably know better; - I don't know what happened to qaludis, nor I care to be honest as it's an external project; - I don't know what happened to pkgcore, nor I care to be honest as it's an external project; - Alex completed Gentoo/FreeBSD port of Sandbox, although Martin disappeared and thus we're forced to unmask sandbox on our profiles for now, and in the mean time he also fixed some FreeBSD bugs; - I have no clue what's going on with SCIRE; - I have no clue what's going on with the Xorg configuration too. I admit I cannot of course judge all the progress, as you can see I have no clue on about half the projects, but that also means there wasn't a big new feature or fix that everybody knows about. So maybe, the targets we put were too much fuzzy, and difficult to achieve. Of course there's also the big unknown of the students, that we can't easily judge if we don't know them. This covers one point, but what most interest me to point out is that we have a real low conversion of developers. What I found interesting in the Summer of Code initiative was the ability to find new developers for a project, people that wouldn't have been involved in open sources projects otherwise. We enrolled as "students" four Gentoo developers, and only one of the remaining ten students was converted into a dev. Added to the little improvements done by the projects, maybe we could have spared a few more slots for the organizations that have achieved more. [1] http://www.gentoo.org/proj/en/devrel/user-relations/summerofcode/ -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp6MPqCE7guX.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Friday 09 February 2007, Ned Ludd wrote: > baselayout is only about a half of a meg these days and probably > getting smaller/faster with the addition of the multicall rc/runscript > work he has been doing. > > Adding bash also requires ncurses which in turn mostly requires having > a c++ aware compiler or using the nocxx,minimal flags. Even with those > flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure > see the benefits. > > Also for a moment lets stop and think. Some XYZ update breaks > ncurses/bash. Supporting this gives us a nice alternative way to still > boot our boxes for rescue using ash or another shell which might not > have such big deps. From where I stand I can see Ned's point just fine: I'm interested in both having a sane baselayout that doesn't break on bash upgrade (I've seen the breakage with 3.1, 3.2.. I also masked bash 3.1 while Roy fixed baselayout for that version), and in a baselayout that can run on medium embedded systems (and not just "for fun", trust me), so I wouldn't dismiss Roy's work as "unneeded" and/or not useful to anyone. He's not going to waste someone else's time, and as he said there will be compatibility with current configuration files, I don't think there's any downside to users. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpg13D9POXYc.pgp Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
On Thursday 08 February 2007, Jim Ramsay wrote: > How would you then reconcile the issues raised in this bug[1] > regarding /usr/lib and multilib support? /usr/lib/misc most likely, or /usr/libexec as you prefer, considering that the policy about that is still unwritten and probably will not appear in the next few months either. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpyccEJxAMJ3.pgp Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
On Thursday 08 February 2007, Thomas Rösner wrote: > AFAIR App Dirs provide internal arch distinction, so why not just put it > in /usr/share/rox? /usr/share is not a good place for any kind of executable. /usr/lib is more suitable for the purpose. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpsHVKNKs8IS.pgp Description: PGP signature
Re: [gentoo-dev] New network config for baselayout-ng
On Thursday 08 February 2007, Krzysiek Pawlik wrote: > Deep Space Nine, then Voyager, then Enterprise... sounds good to me ;) > baselayout-deep-space-nine ;) Portage would hate such versioning scheme ;) I would love it, it would be perfect with the naming convention I'm using for my boxes :) /me points to the @enterprise.flameeyes.is-a-geek.org message-id ;) -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp6jVcUcQ9oH.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tuesday 06 February 2007, Michael Hanselmann wrote: > XML! Actually, no. For me, libconfig[1] turned out to be very easy to > work with. Its config file format is easy to write by hand and the > parser resides in the library. On a simialr note there's libconfuse[1], which uses one of the most common formats available: ini-like :) [1] http://www.nongnu.org/confuse/ -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpYWPdBzIKuX.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for media-sound/poc
On Monday 05 February 2007, Mike Frysinger wrote: > can you name another package which provides the features this one does ? > no ? then leave it be ... punting a package because upstream is not > reachable is retarded You saying you're going to maintain it? :) Besides, if it's a streamer - can't really tell what else beside a streaming software it can be, as upstream is, well, unreachable - bossogg and/or icecast will probably cover it. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp7T9UtD5UmB.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for ruby-gnome (1) packages
On Saturday 03 February 2007, Diego 'Flameeyes' Pettenò wrote: > dev-ruby/ruby-gtk Following this, I'll be masking and removing www-client/gorua and www-client/ci because they depend on it. For who needs an alternative to these, ochusha is probably a good idea, although it does miss alpha keywording at all at the moment, I'll see to get at least some ~alpha keywording. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpbDES0xBmaa.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for February
On Monday 05 February 2007, Ryan Hill wrote: > Reply-to and SPF docs? Isn't this the third month now? I might be counting wrong, as last time I wasn't there, but it might be the fourth, counting the original one. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpmvWvwee2ZP.pgp Description: PGP signature
[gentoo-dev] Last rites for www-client/khttrack
Alright, I start to feel like an undertaker, another package to remove. This one is in the tree since 2003, no more releases, the source tarball 404's and it's currently using an obsolete admindir with broken arts handling. Masked for removal in 30 days. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpbcQf8e4Zal.pgp Description: PGP signature
[gentoo-dev] Last rites for app-portage/kentoo
As per summary: unfetchable, homepage 404ing, and pretty old, likely not working with current Portage system. Removal on March 4th. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpJOP4y78v3U.pgp Description: PGP signature
[gentoo-dev] Last rites for ruby-gnome (1) packages
For some reasons they escaped the big gnome 1.x removal, and now I'm going to remove them as they likely don't build anymore (with the exception of ruby-libart and ruby-gtk that anyway seems to be deprecated nowadays): dev-ruby/ruby-gtk dev-ruby/ruby-gconf dev-ruby/ruby-gdkimlib dev-ruby/ruby-gdkpixbuf dev-ruby/ruby-libart -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpR6PolRoPDH.pgp Description: PGP signature
[gentoo-dev] Last rites for app-admin/kcmgrunlevel
As per summary; unfetchable, it's probably incompatible with current baselayout, as it was developed in 2004, and the version number suggests an alpha/beta version. If nobody wants to take over maintainership, it will be removed in 30 days. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgp3nMjQ3ACgp.pgp Description: PGP signature
