Re: [gentoo-dev] IUSE and LINGUAS?
On Thursday 02 February 2006 20:55, Ciaran McCreesh wrote: > <[EMAIL PROTECTED]> wrote: > | Yeah that would help. But in the mean time what should we do? > > What you should always do. Do the right thing, even if repoman > disagrees. Seems like repoman is actually our boss in this case, so I was forced to put the linguas_* to use.local.desc. (If you can't tell, yeah I'm using a polemic tone this time) I'm wondering if to have a solution we're going to wait till the use.local.desc file is cluttered with all the linguas_* flags. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpn4lmEr2SUE.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Wednesday 01 February 2006 01:55, Jason Stubbs wrote: > However, if lang.desc already exists (and it does) and can be renamed to > linguas.desc, it is probably a better way to manage it than use.desc. Yeah that would help. But in the mean time what should we do? If I commit something with LINGUAS expanded (for example xdtv for which I need, that I want it or not, to know the LINGUAS) right now Mr_Bones_ is going to run at me with an adamantium club of vanquishing +9 ... I'm waiting for this for also alsa-driver (which I'm actually wondering whether it's the case... mainly because there the ebuild uses ALSA_CARDS directly, not sure what would happen if someone tries to set the things in package.use ...). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQWSAWgupTI.pgp Description: PGP signature
[gentoo-dev] QA guides
Hi everybody, I think this is worth to be told here (and maybe also in next week's GWN wouldn't be bad, if I'm able to finish what I'm going to promise later in this mail). As people could have read on my blog, today I've added a new guide under the qa project and added a link from the project page to the asneeded fixing guide. The qa project can be found at http://www.gentoo.org/proj/en/qa/ , and from there it's possible to read the two guides, the aforementioned --as-needed fixing guide and the automagic dependency guide. Why I've started writing those guides? Well mainly because I think we can't actually start enforcing some qa if we don't have documented practice; the DevManual was a good starting point, but AFAIK it's temporaly unmaintained and something more official would be needed to actually start enforcing it. I'm trying to stick with practical problems and solutions, not going on things that are more policy-related, as policies has the bad habit of fleeing out of control if not decided with lot of discussions. Following the two guides that I already put there, I want to write something about solving parallel make issues and autotools failures (how many times we had bugs stuck with a missing m4 file?). Of course, enhancement and extensions to those guides are really welcome; devs can commit there directly (adding themselves as authors if they add substantial doc), but please don't just change them entirely because you don't agree with what is written there, if there's something you strongly disagree, I'd see better a discussion on gentoo-dev so that all can be informed of what it's decided. Users that are wanting to precise something because they know the topic (wouldn't be so strange) can send me the corrections by mail; I don't think bugzilla is a good place for it because the docs product is for user documentation rather than project documentation, but if GDP wouldn't mind finding in that product bugs assigned to me about those guides, it can be arranged. I would also ask someone, wither from GDP or not, to please revise the grammar and spelling, possibly sending me the correction before committing if they seem to change substantial parts of the text. I really hope those guides can be helpful to people; IMHO the first step to have a QA is to provide enough documentation on how things has to be done, or people wouldn't know how to do them. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpE9LIo2bKjj.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 17:38, Mike Frysinger wrote: > it makes a the -pv output unreadable and thus useless ... although if you > do something like -pvv, then the user can expect to get a lot of output ... emerge -p is now less useless than before so it make sense for -pv to show lot of stuff.. > of course this still doesnt address the pita maintenance issue Adds an extra check to do before a bump. One would expect people to look at what they bump.. > no, we have lang.desc already, dont clutter use.desc with this crap Then portage should handle linguas.desc video_cards.desc and so on... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpctNK3vTqLK.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 06:17, Diego 'Flameeyes' Pettenò wrote: > Defining LINGUAS variable would be useful to allow people to know whether > they are going to have special support for their language in a package, but > it would also clutter the output quite a bit. Okay then.. I'm still looking locally how it appears, and I'm thinking it's really useful to have LINGUAS told in emerge -pv and -av. The reason is trivial: if someone sets LINGUAS for something, and then does not get that language supported, it might wonder why; by stating the accepted LINGUAS the problem is solved. Also, it would allow to know when a new language support is available. This makes version bumps a bit more complex, as just renaming the ebuild will ignore changes in supported LINGUAS, but for most cases, it's needed anyway (I think of xdtv for example). For KDE-based stuff, the LINGUAS handling is simple to recalculate: on the new tarball (that one should extract anyway), just do ls po | grep -v Makefile | xargs echo to get the language supported and the same with doc dir to get the documentation languages (then mix them while adding IUSE and there you are). I'm at 5 packages with local LINGUAS support and the output of their -pv is: [ebuild R ] app-editors/kile-1.9_beta2 USE="kde -arts -debug -xinerama" LINGUAS="it% -br% -ca% -cs% -cy% -da% -de% -el% -en_GB% -es% -et% -eu% -fi% -fr% -ga% -gl% -hi% -hu% -is% -ja% -lt% -mt% -nb% -nl% -nn% -pa% -pl% -pt% -pt_BR% -ro% -rw% -sk% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% -zh_CN%" 0 kB [ebuild R ] net-irc/konversation-0.19 USE="-arts -debug -xinerama" LINGUAS="it -bg -cs -da -de -el -en_GB -es -et -fi -fr -hi -ja -nl -pt -pt_BR -ru -sr [EMAIL PROTECTED] -sv -ta -tr" 0 kB [3] [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl -xinerama -zvbi" LINGUAS="it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% -zh_CN%" 0 kB [ebuild UD] media-sound/amarok-1.3.8 [1.4_pre20060116] USE="flac kde musicbrainz vorbis xine -arts -debug -gstreamer -mp3 -mysql -noamazon -opengl -postgres -visualization -xinerama -xmms" LINGUAS="it% -az% -be% -bg% -br% -ca% -cs% -cy% -da% -de% -el% -en_GB% -eo% -es% -et% -fi% -fr% -ga% -gl% -he% -hi% -hr% -hu% -id% -is% -ja% -ko% -ku% -lo% -lt% -nb% -nds% -nl% -nn% -pa% -pl% -pt% -pt_BR% -ro% -ru% -se% -sl% -sq% -sr% [EMAIL PROTECTED] -ss% -sv% -ta% -tg% -th% -tr% -uk% -uz% -zh_CN% -zh_TW%" 0 kB [ebuild R ] media-tv/xdtv-2.3.0 USE="X alsa ffmpeg jpeg ogg png xv xvid zvbi -Xaw3d -aqua_theme -carbone_theme -debug -dvb -encode -lirc -neXt -xinerama" LINGUAS="en% it% -ca% -de% -es% -fr% -gl% -ja% -pl% -ru%" 0 kB (amarok 1.4 is still to fix, I'll do that in my overlay). > Also, as repoman complain about linguas_blabla not being a valid useflags, > all the linguas_* useflags should be listed in use.desc Well I got at least 5 packages that uses a bunch of those LINGUAS flags, so I think it's not a problem about adding them to use.desc instead of use.local.desc. If somebody has a list of those variables, I would add them, it seems to me the most sensible way to do that, it would add documentation allowing people to know what they are going to do. Also, as use.desc is alphabetically sorted, all the linguas_* variables will stay together. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpaksaTfc76Q.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 12:54, Ciaran McCreesh wrote: > 2. Because USE_EXPAND is used for special USE things like arch and > userland, and because we undocumented the special arch USE flags > because they're not user settable. It was already discussed that those special arch USE flags, as soon as they are "safe" (there's a GLEP Grobian and I have to throw here to discuss wrt that) would be added to some sort of variable to disappear from users' sights. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpHvsB45AYor.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 12:43, Jason Stubbs wrote: > Not a huge difference but not exactly minor either. And of course > LINGUAS="" wouldn't be shown at all if nothing had changed with regard to > it and --verbose wasn't specified. That's a point to put them there, it's also quite interesting to see, and might help people who don't know they can set LINGUAS... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpt7fZTbd8Dh.pgp Description: PGP signature
Re: [gentoo-dev] IUSE and LINGUAS?
On Monday 30 January 2006 13:31, Jakub Moc wrote: > maintaining lists of honored LINGUAS in each ebuild it just huge > maintenance overhead with no gain... Well at least for the KDE ebuilds that does honour it in a non-automatic version, the list is anyway needed, as I said, I hadn't had to prepare the list for kdetv, I just changed a bit the way I declare it and added a for loop to add the IUSE. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp5F0exR3Kko.pgp Description: PGP signature
[gentoo-dev] IUSE and LINGUAS?
After reading Donnie's interesting post about how to set VIDEO_CARDS and INPUT_DEVICES in xorg 7, I wondered for a while if LINGUAS should have the same treatment. Defining LINGUAS variable would be useful to allow people to know whether they are going to have special support for their language in a package, but it would also clutter the output quite a bit. I experimented locally with kdetv, that uses LINGUAS variable to condition .po files and documentation generation in a predictable way (as in, the ebuild has to know which languages are available beforehand anyway): [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl -xinerama -zvbi" LINGUAS="it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% -zh_CN%" 0 kB What people think of this? Whatever decision is taken I think it should also be documented somewhere for people to use. Also, as repoman complain about linguas_blabla not being a valid useflags, all the linguas_* useflags should be listed in use.desc (consider that it would take a while, _if_ we decide to go this route, before all packages are updated to do this, but it's silly to pollute the use.local.desc file until 5 packages are using a given language); the descriptions need also to be accurate. (sorry missing signature, I've broken pinentry and waiting for it to be rebuilt by emerge -e world) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Saturday 28 January 2006 10:47, Robin H. Johnson wrote: > Rather than handling it manually, perhaps eselect can help handle it > consistently, and allow users to switch when they have both csh and > tcsh installed. I started working on something like that for gtar/bsdtar, but I found that I don't have knowledge of eselect to do that, but this might be interesting in a generic way for alternatives, and I'd like to help if someone would start something. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwgxJy7wNB0.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
On Saturday 28 January 2006 12:37, [EMAIL PROTECTED] wrote: > Please welcome Markus to the team. Hi Markus! :) use repoman || die [This time it was the case to use this lame joke, right? :)] -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpBNzo5jmd8l.pgp Description: PGP signature
Re: [gentoo-dev] New Polish translator shadoww (Damian Kuras)
On Friday 27 January 2006 16:37, Henrik Brix Andersen wrote: > Somebody please translate this to Polish? I think he meant that we shouldn't welcome him with "use repoman || die" as that's something useful only for ebuild developers :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpaumJyD1XzZ.pgp Description: PGP signature
Re: [gentoo-dev] New Polish translator shadoww (Damian Kuras)
On Friday 27 January 2006 15:32, Jochen Maes wrote: > yups polish conspiracy is growing... And most of it is under my control :P Okay okay, RESTRICT=lamejokes ... Welcome Damian! :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpT0LC5NKdAb.pgp Description: PGP signature
Re: [gentoo-dev] Re: coreutils: deprecated behavior not so deprecated
On Wednesday 25 January 2006 07:54, MIkey wrote: > media-video/xine-ui-0.99.3-r1 (/usr/bin/xine-bugreport) One would suppose that newer coreutils goes in ~arch so the ~arch version should be tested, mainly. xine-ui 0.99.4-r3 has that fixed at least. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp8vfPMTXwPa.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 09:54, Grobian wrote: > It appears that some people > don't agree with you on changing the assumptions made in the current > portage tree. I'm not going to ask for dropping the assumption, I'm just asking for making sure that the assumption is actually backed up with actual presence. The sed/gsed naming shouldn't be too hard to achieve and it's already common in non-GNU userlands. As we seen for gmake/gawk, it's also a common way to make sure for some scripts to use a GNU tool. > Solution to this is making the GNU tool the default for portage known > under its non-g-prefixed name, such that the assumptions made in the > tree hold. This requires (ab)using /usr/lib/portage/bin .. last time you were against that, weren't you? > Maybe it's just the path of least resistance... The profit of having a > tree that works with any implementation of awk, sed, find, xargs, etc. > is perhaps too small for the actual work and sacrifices needed for it. About find, the problem is really minimum: with last release GNU find make simpler to deal with it as it has a stricter syntax. The rest, I never asked for people to rewrite all the awk and sed scripts to work with BSDish awk and sed, I'm just asking to make sure that the GNU versions are called, no matter what, by using gawk and gsed naming. I'm not even asking for them to be fixed for all ebuilds, but only for the ones that uses subshell not respecting aliases Not that difficult, is it? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp7O2am6v67p.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 02:23, Ciaran McCreesh wrote: > If there are any hardcoded calls to /usr/bin/sed, it is reasonable for > you to ask for them to be fixed. For any others, use a wrapper script. I think the wrapper script idea was turned down by someone from portage IIRC. Anyway it's not exactly the cleanest solution: while it would have an immediate effect with no work required, it will increas, and not decrease) the number of "assumption" portage does. I think this is one of the worse things that can be done at this point. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsGv3LKHCPs.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 06:47, Mike Frysinger wrote: > Diego was mistaken here ... probably my fault because i lied to him at some > point on irc, who knows for sure ... at any rate, the sed ebuild does not > install 'gsed' on GNU systems I was pretty sure we decided to go with g-prefixed for tar, sed and make for GNU systems, too (and it's what it's being done by gawk, gmake and so on). I actually have gsed locally, but it might be some trace from the old g/fbsd overlay at this point... So this makes the things more complex again. Time to rethink all of that, what you think? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyJNPtrEN4B.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 00:48, Stephen Bennett wrote: > We've discussed this several times in the past, and every time the > answer has been that in the ebuild environment `sed` is gnu sed-4. It's > the only sane way to do things, since certain other platforms ship > retarded versions of sed. And as there's no current way to fix the invokation of sed from within xargs or find, I'm not going to ask to change _all_ the calls of sed, but just the ones done through those two or other scripts and things that won't honour aliases in bashrc. I have to remember you that the discussions in the past often asked us to redo things after a while. Being more strict and safe on the environment (wrt to find and xargs) is IMHO helping; there are already things that are more or less encapsulated and would be simple to get around (think of patch/gpatch that's encapsulated to epatch) if we really need to. But find, xargs and in general subshells not honouring bashrc are the main big problem. Other suggestions are of course welcome, if you have something constructive to say about that. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQ93B5zYAwv.pgp Description: PGP signature
Re: [gentoo-dev] sed vs gsed
On Wednesday 25 January 2006 00:32, Mike Frysinger wrote: > if you're implying we change all calls from 'sed' to 'gsed' in ebuilds then > the answer is no from my pov Can you at least read all my mails till the end before replying next time? I was referring mainly to the ones that calls sed from find and xargs and similar, the rest are a problem that's already worked around and for now is fine as they are. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYzpSjMgMeO.pgp Description: PGP signature
[gentoo-dev] sed vs gsed
I think the time is mature to ask for another step of Gentoo/ALT improvement ;) Currently ebuilds uses a sed syntax that's mostly GNU sed 4 compatible, but incompatible with BSD sed for instance. This is usually fine as we aliases sed to gsed in our bashrc so that the problem in sed calls is removed. The main problem happen with sed when called by xargs or by find, as that ignores the aliases set in bashrc. What I'd like to ask is, if possible, to start using gsed instead, that's present on both GNU and other userlands with current stable version of sed (4.1.4; ppc-macos has no problem as the 4.0.9 version uses gsed anyway). It might require to change the dependency over >=sys-apps/sed-4.1.4, but that would help making portage a bit cleaner IMHO (instead of relying on sed being the executable you need, it make sure you're using a GNU sed version) and solves quite a few headaches for us. Comments about this? (Please don't tell me to do a GLEP about this) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpOMEesMD2cG.pgp Description: PGP signature
Re: [gentoo-dev] package.mask cleanups
On Tuesday 24 January 2006 16:23, Marcus D. Hanwell wrote:
> All of the KDE stuff is the upcoming 3.5.1 release which we are working on
> in p.mask until the official release. There *are* ebuilds for all this
> stuff in the tree right now. So that has chopped the number of entries by a
> fair margin, but for the script to be useful it should be able to detect
> they have valid ebuilds.
As KDE is way bigger than that is probably listing the packages that are still
at 3.5.0 and didn't get a verbump.
Dan probably did a for pkg in ${PORTDIR}/kde-base/*; do echo
"=kde-base/$pkg-3.5.1*"; done >> ${PORTDIR}/profiles/package.mask or a
variation on the theme, that's also why metadata.xml got listed, too.
I have a partial ruby script that might work to get the real kde packages to a
given version but it's still raw...
--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgp9yCfrxksIo.pgp
Description: PGP signature
Re: [gentoo-dev] coreutils: deprecated behavior not so deprecated
On Tuesday 24 January 2006 05:19, Ciaran McCreesh wrote: > Pretty much the same issue for findutils-4.3. You'll have to get the > argument order correct and remember to include the path. I'm very glad of this :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpynstghiG5J.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Patrick Mclean
On Monday 23 January 2006 18:56, Simon Stelling wrote: > (Not going to make a lame joke here, as I was the one who asked for a new > RESTRICT feature ;)) Well you did broke that RESTRICT already a few times :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpcMsJoRb3XN.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Patrick Mclean
On Monday 23 January 2006 18:21, Mike Doty wrote: > Please take a moment to welcome our newest developer, chutzpah. Patrick > joins us to help the sound and AMD64 herds. Welcome Patrick... and now get to work! ;) Finally someone new in the sound team to give some bugs' share :P And he's also my doomed victim for ifp stuff, so that's really make this good news :D -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpGtMAsW7AJg.pgp Description: PGP signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion
On Tuesday 17 January 2006 17:51, Olivier Crete wrote: > The argument in favor of splitdebug is that it allows users to give > useful bugreports when using tools such as gnome's bug-buddy. Erm actually it does not. Unless gnome herd fixed it recently. The same goes for KCrashHandler/Dr Konqui. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgptxObRn0QT9.pgp Description: PGP signature
Re: [gentoo-dev] Some LaTeX news
On Sunday 15 January 2006 00:33, Kalin KOZHUHAROV wrote: > Not sure how does the new tetex handle i18n, but less than a year ago I had > to use ptex to write Japanese (in euc-jp, AFAIR). There was some rumble > about UTF-8 support, but did it get in? Yes, UTF-8 in tetex3 works fine, at least for me (not like I use extensively unicode-level characters, but in tetex2 also renderning the 'ò' of my name without using the compound sequences was a nightmare). One of the problems I found was that latex2html does not work with UTF-8 encoded files. But that's a side problem I think :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp5XudgMdgIq.pgp Description: PGP signature
Re: [gentoo-dev] learn to use RESTRICT=test people
On Saturday 14 January 2006 00:45, Simon Stelling wrote: > Right after RESTRICT=lamejokes is implemented :P You can't restrict me ;) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpbxYEUijJiC.pgp Description: PGP signature
Re: [gentoo-dev] Is the autotools mess solvable?
On Wednesday 11 January 2006 23:03, Stefan Schweizer wrote: > And I do not see a problem with omitting autotools deps, because > autotools is in system. Autotools shouldn't actually be in system as they are only DEPEND, so it's anyway an improvement if we can get it out of it. And anyway by making sure that the deps are stated by autotools eclass we're actually fixing deps ;) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpl8etcEF2Nq.pgp Description: PGP signature
[gentoo-dev] Is the autotools mess solvable?
I'm actually wondering this. Most of the tree requires autotools being installed, there's no way round this, as they change configure.ac and Makefile.am to fix bugs and similar. Currently we're supposed to check which versions of tools are being ran and then add the approriate deps to the package. Sometimes this is difficult, sometimes it's just misrepresentation as they can work with newer versions, too, and so on. While it would be interesting to get rid of some versions of autotools from portage, I wouldn't think this is possible in a near future... or even in a not-so-near future, unless all upstreams applies our patches, and people start moving to something else. I'm wondering if we shouldn't just drop the idea of having precise deps on that part, and make simpler maintenance, that's already enough of an hell when dealing with autotools, by adding the DEPEND on the wrapper directly on the eclass. That would also solve the problem of dependency on sys-devel/libtool that's already missed by many many packages. It's a compromise, we trade perfectly stated deps for a lot of easyness for devs.. It's not a perfect world, you all know. Comments? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpPNsybMgQ6S.pgp Description: PGP signature
[gentoo-dev] virtual/os-headers and non-Linux
I don't really know what was behind virtual/os-headers versus virtual/linux-headers or something like that. I'm currently considering that, as sometimes you need to depend on some version of linux headers, it might make sense to use a versioned virtual, but that would make no sense for Gentoo/FreeBSD and other Gentoo/Alt systems. So I'm asking if someone can summarize me why the os-headers virtual is named this way and if we can get rid of that or at least implement another virtual/linux-headers to use versioned that can also be used to make sure for instance that packages requiring v4l2 are getting 2.6 headers (see the problems with v4l/v4l2 on sparc). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp4IOPKJpfgs.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Monday 09 January 2006 21:04, Tom Martin wrote: > The devmanual has an an enormous number of links, citations and cross > references. I'd imagine that's what really takes time to generate. For > things like this, it would be very fast. Might be good to test moinmoin's RST support then. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpVQ19lNU7hY.pgp Description: PGP signature
Re: [gentoo-dev] Re: ca-certificates PDEPEND
On Monday 09 January 2006 18:11, Andrea Barisani wrote: > Yeah it could be treated as a bug, I'd rather fix that by patching wget > (--dont-be-a-pain-with-self-signed-certs yes) or anyway at *that* layer and > not by adding ca-certificates as a DEPEND since it has other implications > that we already discussed. wgetrc can be changed to not bitch about it, or a switch can be added to the FETCHCOMMAND command (but it requires a newer version of wget as older don't understand it and bails out, the first is the ideal, IMHO, as people can still change that in their ~/.wgetrc). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQWUvvcmtdr.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Sunday 08 January 2006 18:59, Diego 'Flameeyes' Pettenò wrote: > Okay let's forget the flames and talk about something related to > practical development today :) Sigh ok no practical development at this come out as a discussion/flame again. What I was thinking of is _not_: - a wiki writable by users; - a CVS writable by non-devs; - a replacement for GuideXML (I like it); - a way to replace GDP (I was thinking of dev-level documentation); What I was thinking was instead: - a place where things can be drafted up before GDP submission if they want to handle dev docs, too; - a place where devs can put their own dev guides, without changing the style of the site from the one in main Gentoo site; - a place that does not require the strict belonging to a project to put guides into. I like GuideXML, so I have no problem with writing small-to-medium guides with it, RST would be fine, too, but I don't want it to be plain text or ViewCVS only, GuideXML is in style with the rest of the site and it has printable version available, and it's Googlable. ViewCVS is too "raw" for user viewing, and there might be users interested in those guides. And IIRC ciaranm said it took quite a while to render the devmanual from RST to HTML, would be difficult to sync hourly then. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpW6yk0OucLA.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Monday 09 January 2006 03:14, Marius Mauch wrote: > Find a nice place in www.gentoo.org/proj/ Okay that's what I try to do most of the time, in this specific case, I'm probably going to ask for space to qa project (as fixing --as-needed problems or parallel make issues and such is imho QA-related). This still does not resolve issues for other things like the quilt guide I tried to start writing (but then I'm not so good at explain the user/dev part of it). But at least I'll probably have time to spend on the other stuff for a while if Sven allows me :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpxkXHgVjPB5.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Sunday 08 January 2006 19:07, Renat Lumpau wrote: > Devwiki i thought of devwiki when I started writing Gentoo/Alt documentation. I then discarded the idea for a series of reason, the first of which is the one already stated by Brian, that the docs results unreadable by non-devs, and also not all devs have currently access to the wiki, sa they need to register and then ask infra for access. The method is for sure unintuitive for devs, and unacceptable to leave the documentation up (if some non-dev want to know how to fix something because it's currently unmaintained in tree and submits a patch, I think it's worth to leave the doc public). I also don't find GuideXML so bad for documentation, also if developers' eyes only. The GDP style is simple enough as XML to allow using of CVS. The idea of using devwiki for drafts is a bit better, but I tried that, too, when I moved the above noted Gentoo/Alt documentation in GuideXML out of the devwiki. Chris White helped me with the GuideXMLification, as the syntax is different enough to be unpractical to use devwiki for drafting. Also, drafts are usually better when they are visibile to as much eyes as possible, so I'd rather let them visibile to user too. There are some ways that might be practical. The first one is the simplest I can think of: let general documentation like the "how to fix common problems" document to be handled by GDP as developers' documentation when they are finished, and work on them in a special "draft" directory inside /proj/en/ (with no access restrictions) so that they can be handled by many devs at a time. When the document is ready, it's submitted to GDP which will handle the future maintenance. Another way is to provide GuideXML xslt on dev.gentoo.org so that we can put guidexml-formatted pages directly on our public_html before submitting to GDP. The third way is somewhat more complex: provide a standanlone branch, aside of proj and doc, called "devs", where we can commit guidexml documents that aren't strictly referring to a single topic, but rather organized by who's working on them, still under CVS so we have history. There the drafts can be worked on, and then again passed to GDP when they're final. I tried ordering the three ideas by order of flexibility and easyness for infra to enact them, and they are only what I came up after an afternoon spent thinking on it. There might be practical issues with all of them. I don't like the idea of a wiki not for the public thing (I think it would still be limited in write access to devs), because not only it would be yet another tool to learn usage of, but it would be "off style" with the rest of the site. Also, limiting it to devs to write it would lose the main feature of a wiki, so it would be like wasting the load that it would add... I still like the idea of continuing using GuideXML, after have learned to use it it's really practical to me at least. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp1kss5nhzpm.pgp Description: PGP signature
[gentoo-dev] Projects and simple guides
Okay let's forget the flames and talk about something related to practical development today :) As people reading my blog might already know, I've been experimenting with --as-needed LDFLAG in the past days. It seems pretty stable when you don't have GNOME installed (as many libraries from GNOME project don't like it), but it's usually also fixable when they fail. Now, I wanted to try writing something up about that with a quick guide to fix the most common cases when --as-needed fails. While --as-needed should remain unsupported (now and robably in the future), it might be helpful to have this sort of informations lying around for who wants to know how to fix the problems. I originally thought of putting it on my devspace, but using GuideXML there is a bit tricky, at least for me (as xsltproc seems to refuse working on the pure xml directly). So I was thinking if we had a way to put some "how to fix" guides somewhere, on the lines of the ones written by soalr and vapier for hardened. A part the --as-needed thing, it might also be useful to put something about "how to solve parallel make issues" and similar things that are tricky but usually just requires little knowledge of tricks. GDP might be the place where to put them, but as they are mainly developer-oriented, they might be better accessed directly by devs (at least for the first steps until they are drafts). What people think about this? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpa0iC3APXTS.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for January
On Friday 06 January 2006 16:15, Duncan wrote: > And I definitely wish you well in your G/FBSD efforts, but when I > mentioned them on my local ISP's unix (*ix) group, the FBSD groupies > reaction was "Yuck!" Same for FreeBSD devs that tries to hinder us. But why? They think to be the keeper of The Only Truth? Well the "bsd is dying" joke born for that reason. Check on my blog if you want to know why I continue working on this and I continue thinking it's a good way to _improve_ software. Might not have, right now, any appeal to sysadmins, but it has some advantages (and some drawbacks, as everything), and I like the improvements. But this is not the place to discute this. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQBx4J8HqEg.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Friday 06 January 2006 09:37, Duncan wrote: > Well, for that matter, "distribution" is considered at least by my *BSD > friends, to be a peculiarly Linux term. From their perspective, Linux has > 1001 "distributions", but they only have the one *BSD they choose to use. That's what we started changing. Gentoo/FreeBSD is by all means a FreeBSD distribution (actually, PC-BSD started this a bit before of us). We didn't fork it to change the base system, we use FreeBSD basesystem and portage, so it's not like others BSD. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp49E4a6O4La.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 15:59, Stuart Herbert wrote: > Page title: "Gentoo Linux - Gentoo Linux News" Yeah ok, let me end up these holidays, and I'll prepare a written request to change the Linux part in something else (Land if you want to keep the L, or I'll try to find a name we can use)... we deserve it as Gentoo/FreeBSD is at a level not so far from Gentoo Linux, and Gentoo for Mac OSX is still going on. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQhT5tU53jB.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 13:24, Ciaran McCreesh wrote: > No, that's censored to only display what certain people want it to say > rather than the truth of what's going on. planet.gentoo.org/universe ? I have yet to see anything, from rants to personal notes, that didn't got there (for what I've wrote). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpcnx7l89XtO.pgp Description: PGP signature
[gentoo-dev] package.mask and unmasking packages
I know I'm one of the new ones, and I shouldn't be complaining for this, but people please, pretty please, check what you remove out of p.mask.. if it was masked, there was probably a reason, check carefully before unmasking. Remember that when you get something out of p.mask, all users in ~arch are going to get it at the same time, it means that if something breaks, we have a broken ~arch tree at least, and while that's not the "stable tree", it's not good to have it broken this way. Rather, stick with something in p.mask for long times, and points people to unmask it to test it if bugs are fixed there, but _don't_ unmask it "and see what it happens". Better wait a week or two more, but get everything working, than having to deal with broken trees and people who complains. You might not care what users think and say, but many people (and I'm one of them) actually has to deal with users and gets annoyed by people asking "gee why this was done? it does not work!" and similar. And the upgrade/downgrade, especially for things that are linked in lots of programs, it's pretty annoying for devs, too. Just a friendly reminder, hoping that we won't see bigger problems. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgptpApVDbZk7.pgp Description: PGP signature
Re: [gentoo-dev] Re: shoving utils from xpdf to poppler...
On Tuesday 03 January 2006 20:25, Luis F. Araujo wrote: > So i suppose we should avoid using this kind of notation whenever possible. Or you can try to fix portage. > Which dep? xpdf. poppler does _not_ require xpdf. !< allows to avoid installing older xpdf and newer poppler at the same time if you change that to >=, you get a forced fake dep on xpdf, requiring everyone using poppler to have xpdf installed, too. That's what we're trying to avoid. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpe5J2Txod8U.pgp Description: PGP signature
Re: [gentoo-dev] Re: shoving utils from xpdf to poppler...
On Tuesday 03 January 2006 04:30, Luis F. Araujo wrote: > Now if i change to >=app-text/xpdf-3.01-r4 , it works just fine. But you significantly change its meaning. > I am not sure what it is happening here though... is the !< notation > broken? Portage does not resolve block correctly, look at bugzilla there are tons of bugs open. > I also think we should stick to the >= notation instead, which it is > cleaner imho. It does not mean the same, it would require adding a dep that is not actually there. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzrypydfbL6.pgp Description: PGP signature
Re: [gentoo-dev] Re: shoving utils from xpdf to poppler...
On Monday 02 January 2006 10:35, Alexandre Buisse wrote: > Isn't there any way to make xpdf and poppler live together on the same > system? emerge unmerge xpdf emerge -u poppler emerge xpdf -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpFZEAunw1wH.pgp Description: PGP signature
Re: [gentoo-dev] What to do with GCC 4 related bugs?
On Monday 02 January 2006 09:01, Dirk Heinrichs wrote: > I recently switched to GCC 4.0.2. A handful of packages didn't (re-)compile > during emerge -e system and emerge -e world. Is there a big GCC 4 related > bug in bugzilla where I can report those problems or should I write one > report for each package? Usually, one report for each package is the preferred way, as this allows to close the bugs already committed, and to dupe against existing if it's the case (always search for existing bugs of course). I'm wondering if a gcc4 tracker bug might help as Mark was planning to move it in ~arch. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpytug2kgVGi.pgp Description: PGP signature
Re: [gentoo-dev] SuperH (sh) KEYWORD spam
On Saturday 31 December 2005 11:27, Jason Stubbs wrote: > So that's one package every two weeks then? ;) Average of every three when they fail :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpSasQOULmB6.pgp Description: PGP signature
Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing
On Tuesday 27 December 2005 18:55, Peter wrote: > Thanks all for the feedback. It's important to realize that "userland" in > this case is under 1 minute compile time. One of the modules, glx, doesn't > even get compiled. A poster on this thread noted that glx took 14 > seconds -- it just copies closed source libraries. Here it takes a time variable between 30 seconds and 2 minutes depending on the load of the machine. It's always things that gets copied, overwriting the extended attributes for pax (well I think pax counts only the executables, I'm wondering if paxctl would work on .so files, but I don't think so). For sure, -xconfig and -settings are not going to be as simple to merge into the single ebuild for the paxctl thing above at least, not counting that many people (included me) don't really need -settings or -xconfig, and just use the default. Current situation seems to me one of the most clean possible, way simpler than using nvidia's manual installation, and for what I've seen with users, it's not _so_ difficult to understand. > Here, the intent is to simplify things, remove steps and ebuilds, and make > it more user friendly and require less interaction. I already said that FreeBSD and Linux modules have _nothing_ in common and merging all in one ebuild is going to give me an headache to fix it. I'm not going to drop the FreeBSD support tho. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6fvwC5ORpd.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 20:24, Jakub Moc wrote: > exactly the same thing with motif - would > someone explain why the heck do do we need this thing in make.defaults? Because people emerges xpdf waiting for xpdf binary and they won't find it with -motif, as it requires motif integration, but I think more people would just have xpdf installed because of cups or older kpdf/gpdf versions. Now that poppler is there, the problem might be mitigated, in the future, tho, as cups still uses xpdf and not poppler yet. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZOJe0D9UT8.pgp Description: PGP signature
Re: [gentoo-dev] Stupid USE defaults that need cleaning
On Monday 26 December 2005 17:32, Jan Kundrát wrote: > If it should be on by default, let's add it to the profile, don't ask > users to turn it on themselves. That s what it s done now. But -* would disable it... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpbt2L1P6CIf.pgp Description: PGP signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 13:59, Simon Stelling wrote: > > Actually "stricter", and there are way too many people to put that in > > without knowing what that do... or is it a default nowadays, I'm not even > > sure. > You're mixing up 'strict' with 'stricter'. Well if I'm mixing up, someone moved the QA checks from stricter to strict lately ;) I don't run strict as I usually have modified ebuilds if I'm working on them; I don't run stricter as lot of packages that fails are not mine, I usually use it only when I'm testing my packages or my changes. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsZyuWhdqN2.pgp Description: PGP signature
Re: [gentoo-dev] Installing COPYING or LICENSE files
On Monday 26 December 2005 15:02, Petteri Räty wrote: > It's just that usually the > INSTALL file is not really useful unless you are manually installing the > package from sources and then you will have the INSTALL file in there > with the sources. Yeah, and in that case I usually judge it useless and avoid installing it. For the (rare) exceptions, I'd rather newdoc it with another name such as SETUP or something like that, would probably also help users to find useful informations. I'd add ABOUT-NLS files to the list of useless, as that usually just reflect the status of GNU project translations on a given gettext release... I'd rather just see it installed by gettext package itself. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZNe63wlzLQ.pgp Description: PGP signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 03:28, Chris White wrote: > I'm not sure if we're on the same page as far as the target audience of > this change. The target audience is developers/those with strict in their > features. Actually "stricter", and there are way too many people to put that in without knowing what that do... or is it a default nowadays, I'm not even sure. > I've always found dodoc should > be checked anyways, and if we're assuming the documentation consists of the > formentioned items, then we're also having the situation of missing other > important documentation as well. Take KDE-related packages.. a good 90% of those have just the files I named or a subset of them as documentation, for those, the eclass already take care of them definitely. When there's something _more_, it can be dodoc-ed by hand. But it would fail if someone didn't put a NEWS file or a ChangeLog ... that seems stupid to me. Also, I think jakub is totally right with this. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLC1euV5lJJ.pgp Description: PGP signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
On Monday 26 December 2005 00:32, Petteri Räty wrote: > > Currently there are quite a few ebuilds in the tree that execute dodoc > > or dohtml for files that do not exist. I think it would be nice to have > > ebuilds die if this is the case. I wouldn't like this. The reason is, they are also used in eclasses that might be generic; while for example kde eclass checks for the presence of files before dodoc-ing them, I would rather see it ignore the actually presence or less of the files, and just dodoc the one that exists, without failing if some does not exists. One can be reasonably safe that it will find AUTHORS ChangeLog README NEWS and TODO files in generic packages, if they follow GNUs style for example, but sometimes they can be missing. I'd rather not see the change. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpms11GjfT7b.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Unified nVidia Driver Ebuild ready for testing
On Saturday 24 December 2005 16:31, Peter wrote: > Not really. glx does not compile at all and the entire pkg file has to be > extracted. Same amount of files being processed... No, because the glx part files needs to be processed by portage, too, and that's something that takes time, especially now that portage uses paxutils to find texrels and company. > FBSD is a problem already. It's not even a valid arch at the moment I'm working on it, the problem is that we had to get rid of x86-fbsd keyword in arch.list to avoid devs wasting time from running repoman for x86-fbsd profiles. An alternative is to check CHOST. >Anything current with fbsd is at the best a > complete hack. In GLX? I don't really think so, a part a couple of special cases, the most of the ebuild works in the same manner for both of them, there are name changes due to the different versions. And for the kernel module, it's _completely_ different, that's why I don't want the Linux module and the FreeBSD module to be in the same ebuild. I have an nvidia-freebsd package on gentoo/alt overlay. > Then, there is one last issue you did not consider. If nvidia releases a > new driver, there is no dependency from kernel -> glx. This would make it a circular dep, I would say to poke portage devs about that. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpADVTsfLg2m.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing
On Saturday 24 December 2005 13:50, Peter wrote: > Also, I find it absolutely fascinating that the only people against this > concept are devs, and the only people for it are users. Remember that > users are your customers. Every effort should be made to keep them happy. Considering that we aren't paid, I think that every _affordable_ effort should be made, but making more complex maintainership for devs just to satisfy a couple of users, when the advantages are really minimal, it's not exactly a good choice, IMHO. > Here, with the unified nvidia, the intent was to REDUCE ebuilds and > simplify installation process. I thought the recommendation of a meta > nvidia ebuild is a worthy one worth consideration. nvidia-glx depends on nvidia-kernel already, no? That would be enough, for me. > nVidia upstream combines all the products together > in their .run files. There is minimal time difference between having the > entire suite installed versus each one individually. Well depends how you see it. If you just build it when you update the drivers, yeah there's a minimal difference. But if you have more than one kernel (for whatever reason), and you want to have the latest kernel on all of them, it's way faster to just use nvidia-kernel. Then there's the point I've already said, about mixing the kernel-level with generic userland stuff: for Gentoo/FreeBSD I need it to be split, or I'd have to recreate a copy ebuild especially for FBSD... and that not only sucks from an user POV but also from a maintenance POV. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgptjX1EPKlJN.pgp Description: PGP signature
Re: [gentoo-dev] Optimizing performance
On Saturday 24 December 2005 12:37, Kevin F. Quinn wrote: > I'm still convinced this is untrue (apart from disk space). IIRC was solar who said some time ago that executables are mmapped before the sections to load are loaded. And when I was using non-stripped binaries, I had less free memory than I have now with splitdebug binaries... might be a coincidence, but I wouldn't bet on that. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp4E1NyQVuyO.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] iconv and libintl virtuals
On Sunday 11 December 2005 18:02, Diego 'Flameeyes' Pettenò wrote: > Okay now that virtual/x11 introduced the new generation's virtuals, the > decision of waiting to have virtuals for iconv and libintl can be > considered concluded, and we might start adding them, right? :D I'm still waiting for other answers to this, a part Spider's consideration about libiconv (that shown no problems yet, I'll anyway see to mask it on default-linux profile and other glibc-based profiles). If people has no complaints with this, next week I would start adding the packages and fixing the ebuilds to use the right deps. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpAHf4hYIuJ5.pgp Description: PGP signature
Re: [gentoo-dev] Optimizing performance
On Friday 23 December 2005 18:35, Paul de Vrieze wrote: > Just to add. This is not so much related to debugging information in the > library files (what gdb can use). That information never makes it from disk > so is not that much of a speed issue (esp. if it is split out). Actually, if the binaries are not stripped, they consume more memory. With splitdebug the issue is unseen (I'm happily using it with -g3 for everything now..) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp9kmRUvN7r7.pgp Description: PGP signature
Re: [gentoo-dev] X.Org 7.0 Release
On Friday 23 December 2005 23:50, Greg KH wrote: > For those of us who want to try modular now, where's the pointer to how > to do this (I can't seem to find it in the archives, sorry...) google for <> :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpH9bqK3ieCW.pgp Description: PGP signature
Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing
On Friday 23 December 2005 18:41, Peter wrote: > We would like your help in evaluating, testing, and > commenting on this approach. Please locate the latest > nvidia ebuild at: I thought that we (gentoo devs) were trying to split the modules from ebuilds, so that people don't need to waste time with userland when rebuilding modules after kernel update. Also, I'd really like to have nvidia-glx split from nvidia-kernel because of fbsd support, adding all on one ebuild would make it difficult to handle the fbsd case... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpdX142l70xE.pgp Description: PGP signature
Re: [gentoo-dev] Commiting of ~arch virtual/* ebuilds causes deptree issues
On Wednesday 21 December 2005 19:28, Donnie Berkholz wrote: > IOW, it doesn't matter if an ~arch virtual depends on stable packages. > It matters if stable packages depend on an ~arch virtual. So that's like any other package in the tree.. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQN3kxkxvdl.pgp Description: PGP signature
[gentoo-dev] Last rites for kde-base/kmobile
I've masked kde-base/kmobile pending removal, for a series of reasons: - it's not built by default - it's not useful, because it's incomplete - it's even broken on 3.5 and required patching to build, so the 3.5.0 never appeared - it's still unstable creating up&down problems to people having it installed You can see at https://bugs.gentoo.org/show_bug.cgi?id=115980 a summary report. The dependency from kdepim-meta was already dropped time ago, so it's not even a problem from that side. If nobody has reasons to let it still leave, I'll drop it entirely in a week. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpdLwFrv4ldI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Optimizing performance
On Thursday 15 December 2005 16:43, Patrick Lauer wrote: > [talking about -Os if I'm right] > I've seen some reproducable breakage, e.g. KDE doesn't like it at all Actually, I'm running KDE with -Os right now... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpxYRkW4Ai7s.pgp Description: PGP signature
Re: [gentoo-dev] Optimizing performance
On Thursday 15 December 2005 14:43, Francesco Riosa wrote: > Some upstreams, mostly media related but also unsuspectable like MySQL, > use and test their apps with high optimizations. Not exactly true.. many media related upstreams forces "ricing" flags (-fomg-so-fast) on packages, but that does not really mean it's more stable that way... actually, xine-lib proved to be way more stable while *not* using ricing CFLAGS. The actual problem there is that many packages have code that breaks if you remove those flags, so for example xine-lib has to foce a few flags on to work fine (on x86). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKksvz07bOr.pgp Description: PGP signature
Re: [gentoo-dev] mod_rewrite .htaccess support on dev.g.o ? (was: jforman touches himself)
On Wednesday 14 December 2005 21:37, Mike Frysinger wrote: > speaking of which, am i retarded, or does mod rewrite not work in > .htaccess files on dev.g.o ? I asked for that too, the feature is disabled by infra. klieber should be the one to ask for the reasons iirc. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp7sWuYCoieJ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] iconv and libintl virtuals
On Monday 12 December 2005 00:47, Spider (D.m.D. Lj.) wrote: > Yeah, I certainly -HOPE- that it will retain its blocker vs. glibc, or > things may slip downhill on a certain rollercoasterride of party and > fun. Not to mention that they claim the same files ;) AS long as nobody does stupid things like touching my ebuild without telling me, it should be safe, I'm quite territorial, so I monitor my own packages.. > Aye, I just raised the point that such packages -do- exist and will(I'm > still not an optimist) be an issue in the future (tm) for you : ) Some packages depends on || condition on libiconv already, I haven't seen a single bug about it since I maintain it. Maybe I'm lucky, maybe the current situation is better handled. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyO2aCLMXWM.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 23:53, John Myers wrote: > Well, if you take the entire spec with all its variations, then ciaranm's > points there are indeed correct (week number formats, day of the year > formats, punctuationless formats, etc.) Well as long as you always use the same format, the sort is quite natural... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpIl0Y1xkiDN.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
On Sunday 11 December 2005 22:57, Ciaran McCreesh wrote: > You forgot d) a pain in the ass to parse, e) inconsistent with > everything else, f) a pain in the ass to sort, g) massive overkill. I find ISO 8601 simple to sort -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYInhF7jnyM.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] iconv and libintl virtuals
On Sunday 11 December 2005 19:29, Spider (D.m.D. Lj.) wrote: > How will you deal with the packages that build against glibc iconv but > not against the separated? I'll patch them, if they are common packages, ports from FreeBSD, NetBSD, OpenBSD, DragonFly BSD or DarwinPorts will have patches for them, as they use libiconv. > There used to be a lot of issues here, which caused me to hard-mask > iconv ( still should be hard masked for most/all glibc-based systems ) > due to the split and mainline packages running out of sync. That's why the virtual consider glibc first, for systems where glibc is not present it will go with libiconv. Everyone using glibc *must not* use libiconv, and it *has* to remain hardmasked for them. But libiconv is unmasked for Gentoo/FreeBSD, Gentoo/NetBSD and Gentoo/OpenBSD systems, where it's needed to have iconv() function. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwMlvSYDe44.pgp Description: PGP signature
[gentoo-dev] [RFC] iconv and libintl virtuals
Okay now that virtual/x11 introduced the new generation's virtuals, the decision of waiting to have virtuals for iconv and libintl can be considered concluded, and we might start adding them, right? :D Proposed virtuals for now would be: virtual/iconv: || ( sys-libs/glibc dev-libs/iconv ) virtual/libintl: || ( sys-libs/glibc sys-devel/gettext ) The deps of programs using libintl would then be RDEPEND="nls? ( virtual/libintl )" DEPEND="nls? ( sys-devel/gettext )" for iconv instead simply add virtual/iconv to RDEPEND; note that most of the packages do depend on libintl but don't on libintl, as that is pulled in mostly as a dep of gettext... there are though some packages that actually uses libiconv directly, such as glib and mpd iirc. If this is ok, I won't ask any maintainer to add that stuff by himself (well if somebody wants, I'll thank him for sure), I'll take care of updating the deps as they are needed. Embedded team: this would probably be a good test for NLS support on uclibc, if you want, please add me (or alt) as CC if you'll ever have to file bugs of NLS not being correctly disabled with --disable-nls, as I found quite a few programs taking that bad. Thanks to everybody who cared to read this mail. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpaXi9wKeOQT.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Sanchan
On Saturday 10 December 2005 23:09, Luca Barbato wrote: > the Italian conspiracy taking place? Would also be time :P Welcome Sandro :) What scares me is the proportion of engineers... :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpxYIjKFnZ4b.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for media-video/dvdrip
On Thursday 08 December 2005 21:10, Mike Frysinger wrote: > so the video herd policy is to remove packages until you're left with > a small enough subset of packages you can handle ? No, it's to remove the packages that have problems, that requires dependencies that are badly broken (transcode 0.6 is a pain to manage, does not work with GCC4 and it's not easily fixable, and upstream moved to transcode 1), that requires maintenance and nobody can give it, and that might be replaced by other programs with way less troubles... If you want to maintain that, no need for it to be removed... atm it's going to be unmaintained in the tree, full of problems, and requires us to not plan of dropping transcode 0.6. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpIOAXbLYRuA.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for media-video/dvdrip
On Thursday 08 December 2005 19:12, Chris Bainbridge wrote: > Er, isn't dvdrip the most popular ripping software on Linux? Popular, maybe, but there're enough bug to make it a difficult task to maintain. Current versions are tested only on transcode 0.6 (I'm sure that at least the versions that upstream consider stable does not run with transcode 1.0) and it has to inherit also all the bugs of transcode 0.6 then. Currently there's no one in Video team that seems to be taking care of dvdrip so the bugs will continue stratification on bugzilla. If a new maintainer is found, fine, it can remain, but currently the resources of Video team are limited and we have enough problems to take care of without dvdrip. The new maintainer would anyway have to take care of transcode, too, or at least make sure that dvdrip in portage can work with transcode 1.x as that has lots less problems than the old 0.6 one. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpkw94AT2mag.pgp Description: PGP signature
[gentoo-dev] Last rites for media-video/dvdrip
Another package is taking a long long way that goes out of portage. I'm running out of openings for these mails, you know? Oh well, media-video/dvdrip has many issues reported in bugzilla (some have patches, most haven't), and depends on a version of transcode with many issues, too (and force us to leave transcode 1 masked). Nobody in video herd is looking at it right now, last bump was done by morfic, and more would be needed. Alternative dvd-ripping software is present in portage, starting from mencoder and its frontends, and they usually works better (look at winki for example). For this reason, I'm package.masking dvdrip and pending removal 2 weeks from now. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpRHBBYB6dla.pgp Description: PGP signature
Re: [gentoo-dev] Looking for DirectFB maintainers
On Thursday 08 December 2005 15:10, Chris Gianelloni wrote: > What are you talking about? DFBsee and at least another package is assigned to media-video, and seeing the recent assignments, I've supposed the wrong metadata , sorry ^^; -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpCAHS4Su2G9.pgp Description: PGP signature
[gentoo-dev] Looking for DirectFB maintainers
Another series of packages that lies around, this time for media-video team. DirectFB requires some new maintainers to take care of it and its applications. I'm not using it and seems like nobody else on the team is taking care of it, so if someone uses it, it would be good if it stepped up... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpovs6e9t9wz.pgp Description: PGP signature
[gentoo-dev] Looking for jack maintainers
Seems like the jack support in sound team started to be unavailable lately, kito is full of other tasks and he's the only one, as far as I can see, who's taking are of Jack. As I have no idea where to start looking for it, nor I have time to spend on it, unfortunately, so I can't take care of them. Is some other dev (possibly) wanting to take care of that as a main task? :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpefc1s1XREc.pgp Description: PGP signature
[gentoo-dev] Last rites for media-video/kavi2svcd
Another package leaving the tree, again because of transcode1 CLI changes. It does not work as intended with transcode 1.0 and has other problems, too. Hoping in newer versions to come out better, I'm going to mask and it's pending removal one week from now. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp65wGDibyzj.pgp Description: PGP signature
[gentoo-dev] Last rites for media-video/gtranscode
gtranscode should have been a transcode frontend in GTK2, but it does not work the way it is in portage, it's unmaintained both upstream and in Gentoo (kzimmerm seems to be MIA), and the new versions of transcode changed the CLI so it wouldn't work on transcode 1. I'm going to mask it today and remove it the 12 if nobody wants to step up, and fix it completely (take over upstream?). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpO6Y16j48wg.pgp Description: PGP signature
Re: [gentoo-dev] eclass mozconfig-2 restrictions
On Sunday 04 December 2005 20:47, Ned Ludd wrote: > that sounds like it would solve the problems ferringb has > pointed out in the past. That works fine, a part an "Eclass blabla inherited illegally" errors on unmerge of older ebuilds. The main problem is that what was proposed for shadow deps requires adding a dep to an eclass, so it would add _again_ the dep on shadow on eutils (it was removed because the shadow dep was creating a circular dep with pam-login and pam). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpqgnSVzTFdH.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Monday 28 November 2005 21:01, Curtis Napier wrote: > A seperate tag like , as > someone mentioned earlier, would also be a huge help but would still > give you the homepage info as well. Seems like we are all ok for the tag in metadata then... should this require a GLEP or it's a simple change? Who can take care of that? Paul? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKKndDbxD2o.pgp Description: PGP signature
[gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
Hi all, little question (that could start up a flame): what's the official status of /usr/libexec directory? I was told on IRC time ago to prefer /usr/$(get_libdir)/misc to libexec because that's already ABI-specified... but I'm not really sure. /usr/libexec is already used by many upstream packages, starting from FreeBSD itself, and while it's true that /usr/$(get_libdir)/misc is ABI safe, I don't really like thinking of moving executables in a subdirectory of lib for ABI's sake.. or we'll end up having /usr/$(get_libdir)/binaries instead of /usr/bin ... So, as the documentation about that seems not to be clear, what's its status? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpdsyCVsmXbj.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Monday 28 November 2005 16:47, Jan Kundrát wrote: > What about setting the HOMEPAGE of alsa-something to point to our > ALSA-guide? Because that's not the homepage? I go often on pgo to see the homepage of something, and it's usually to get *upstream* homepage, not Gentoo's guides. It's misleading changing that, imho. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpgWZOKjIFM3.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Monday 28 November 2005 12:20, Paul de Vrieze wrote: > Perhaps we should do both, as "title" attributes are not easy for machines > to understand, as they are freeform. The kind attribute would not be and > only allow certain values such as: "maintainer", "user", > "administration", "troubleshooting", "misc" Sort of the way a dev in a project has role and description, then. Good for me :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzmkf9GAzQS.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Monday 28 November 2005 11:39, Paul de Vrieze wrote: > In any way I like the idea to add a tag to the metadata.xml files. I would > however want to do it differently. I'd like to propose a general > tag with the usual attributes (version/deprange, language) and as new > attributes a "src" and a "kind" attribute. I like this idea, as it would also allow to specify user documentation that can be found on GDP, allowing users to find out the link to alsa guide directly from an alsa-* package's metadata. Maybe instead of a kind attribute we can have a "title" attribute, it would be anyway simple to recognize maintainers' guides, as they would be all title="Maintainer's Guide". -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLWt874MJVA.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Sunday 27 November 2005 20:27, Donnie Berkholz wrote: > This should be the goal already, and all herds should be looking to > either join or create a project, in conjunction with other herds. Okay that probably goes fine for most of the cases, there are still non-herded ebuilds but that's a side problem. Anyway if the organization is non-trivial, the metadata thing is really needed. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpgq6BBJB6tA.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Thursday 24 November 2005 12:31, Diego 'Flameeyes' Pettenò wrote: > What I'm waiting for now are comments if someone has ideas where to put > guides that does not belong directly to an existant project. And if someone > wants to join the effort of documenting maintenance process for his > packages, it would be helpful, too. Trying not to let this idea die, as I still think it might be good in the long run, especially if there's a way to get them collected in a single place. Right now the main problem is that they are spread across projects (at least video/sound projects). Possible solutions I thought of: 1) have every herd controlled by a project, so that the maintainers' guides can be committed there; it would be difficult to find the maintainer's guide for a package this way; 2) have a single repository for maintainers' guides that does not belong to other projects; 3) have a single repository for *every* maintainers' guide. The problem with 1 and 2 is that the maintainers' guides would be difficult to locate in the mess of projects. The problem of 3 is that we have already complex maintainers' guides such as xine's and the one spyderous wrote for X11 herd, that might be difficult to fit in a single organization.. To solve 1's and 2's problem, the solution could be adding a tag to metadata.xml, that carries the URL to the maintainer's guide for the package. It would also make simpler, for example, the case where a single guide is used for more than one package (see always xine's). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp9xae7VUadb.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 17:49, Ciaran McCreesh wrote: > A proper solution requires Portage changes. Unfortunately, for some > packages waiting a year or more to fix something isn't an option. Maybe not, if we just make man and info two useflags enabled by default in all profiles and change one-by-one the ebuilds that installs man pages or info manuals. The info index regen can go in an eclass, as it's only needed for packages that does install info pages, and they are not so many. Not a simple way, but it would be clean on the long run. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpkL2IJTbgqE.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 17:12, Ned Ludd wrote: > USE=(man|info|doc) wont quite work. > While they could have an advantage that you can use them to control > depend strings the doc use flag has already been heavily used for other > things which everybody surely wont want. As vapier said, doc useflag does not mean much in this discussion. FEATURES="nodoc" is less than an install mask, as it just (iirc) make dodoc commands no-ops. An INSTALL_MASK makes simpler to handle that. We already use the doc useflag to avoid adding dependencies only for doc building, so the similar meaning for info and man is already in use. Basic doc does not require any dep (as it's already built), while man and info requires the man command and texinfo, so there's a big difference. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpjo00wZVz3A.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Sunday 27 November 2005 15:39, Jason Stubbs wrote: > Core packages or not, they are all broken. When the requirement came up, > the respective maintainers should have spoken up so that a proper solution > could be found. When are the quick hacks going to stop? :| Is my mail enough as a speak-up for finding a proper solution? :P -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpPbCoKei1nq.pgp Description: PGP signature
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sunday 27 November 2005 15:39, Dan Meltzer wrote: > Err, maybe I am incorrect, but isn't it more "work" to ungenerate them > (using strip) then to just not install them? Their creation in-line of a binary is probably a simpler work (for the disk) than having to split them out, but I might be wrong. For sure they'll take a bit more disk space while building, and that might be significant for things like OpenOffice. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYe2EgSjSfr.pgp Description: PGP signature
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sunday 27 November 2005 00:10, Luca Barbato wrote: > It's great! > Make it a FEATURE default on for common profiles. +1, and it would be better if the FEATURES, instead of removing the generated files, would disable the building of them completely, mainly because "work" systems with limited CPU, RAM and HDD space would probably prefer not having to create and store them :) /me thinks of laptops -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpgPcOc1xxQW.pgp Description: PGP signature
Re: [gentoo-dev] manpages that requires dependencies
On Friday 25 November 2005 00:58, Ciaran McCreesh wrote: > man pages can't be considered optional (despite what RMS says). They're > not fancy extra HTML API documentation, they're core, so they don't get > a USE flag. I know (and I *really* don't like info for one) but I think I'd rather disable it and ship pre-built manpages, instead of adding docbook-sgml-utils to the deps. > Of course, if FEATURES were in the USE expand list, you could use > ! features_noman ? ( ) ... Right... that *would* be useful... -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwOZwdfx9rI.pgp Description: PGP signature
[gentoo-dev] manpages that requires dependencies
Hi everybody, a little question that I'd like to be answered (so that we can make it a sort of rule). How should manpages that are generated be managed? The common sense and looking to other ebuilds would say to always build man pages, but when it asks me to install something like docbook-sgml-utils, I'm tempted not to do that ;) The 'doc' useflag, as I see it, is not a good way to achieve that, as it's already used for API documentation (unless we start create a "apidoc" useflag instead, that would help, too). A 'man' useflag? So people, flame on! [let's use the mailing list for some constructive development things ;)] -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpc9sJx3GYHL.pgp Description: PGP signature
Re: [gentoo-dev] my apologies for the mess with this release of MySQL 5.0.16
On Friday 25 November 2005 00:13, Francesco R. wrote: > did'nt know that, I will try in the ebuild too Pretty please *don't* use ldconfig in ebuilds. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp3ONHJ6JHnV.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Thursday 24 November 2005 21:25, Ciaran McCreesh wrote: > *shrug* I'm not sure that the existing docs team is the best way of > handling developer documentation. If it's just matter of fixing the English in it, I don't think there's much technical matter they would be required to think about. I'm not saying they should write *more* of it, it's just a way to clean up the form of something written by the techies. > | Not everybody is a native English speaker, and it's stupid blaming > | people for that. > There doesn't seem to be any strong correlation between being a native > English speaker and being able to write correct English... You might not be able to see it because you're one, so don't even try to find lame reasons. It's not _easy_ at all. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgplP3JJ0cdrz.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Thursday 24 November 2005 20:50, Ciaran McCreesh wrote: > Of course, the problem > with that is that some our package maintainers couldn't stick together > a coherent English sentence even if they were paid to do so... That's why I was thinking of a complete project with some doc guys assigned to grammar revision. Not everybody is a native English speaker, and it's stupid blaming people for that. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpcalDDlCFKk.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Thursday 24 November 2005 14:51, Grant Goodyear wrote: > Assuming that they're reasonably well written, why not add them to The > Doc? For the same reason the doc born outside GDP: quick changes, for once. for example the xine mantainer's guide yesterday was changed "on the spot" when the TEXTRELs problem was found, both its and vlc's guides were changed as soon as I moved the patchsets in gentoo CVS. The point is to have maintainers update their notes as they do them. If a new release come up, I can quickly update the notes about it. > Alternatively (and perhaps more usefully), what about permitting a > MaintainerNotes file in any cat/pkg directory where it would be useful? That would be quite every package, because there's no package "without notes". Also the simplest packages might have something that needs to be checked. And adding one more file to the tree, of considerable size for some cases (look at xine's guide, it's quite long) would be really bad. And I still think that something more elaborated than txt can help in writing notes about that.. I know that many people does not like GuideXML, but it's flexible enough for most of the needs of a packager's notes. Referring again to the xine's guide, you can find that all the useflags stated are in bold.. if someone wants to find out why a given useflag is threated in certain way, it's simple to spot it, it's not so simple when you have to do it with a plain text file. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKOVnNJcie4.pgp Description: PGP signature
Re: [gentoo-dev] Maintainer's guides?
On Thursday 24 November 2005 01:01, Diego 'Flameeyes' Pettenò wrote: > I'm going in the next days to add more and more documentation about this as > I want to leave enough notes for someone else to step over if I have to go > away for a medium/long period. Okay, brix suggested me to explain better what I meant as the phrasing sucked (as often from me). What I'm waiting for now are comments if someone has ideas where to put guides that does not belong directly to an existant project. And if someone wants to join the effort of documenting maintenance process for his packages, it would be helpful, too. If there's enough volunteers to document the packages, it might be worth having a "maintainers' guides" project to save all the guides to.. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpVy1xnrDFC5.pgp Description: PGP signature
[gentoo-dev] Maintainer's guides?
As someone probably already know (thru my blog or by looking to my commits), I'm being lately working on documenting the process I use to maintain some of my packages, in particular xine[1], vlc[2] and alsa[3]. I'm going in the next days to add more and more documentation about this as I want to leave enough notes for someone else to step over if I have to go away for a medium/long period. Now the problem is that while xine vlc and alsa belongs to sound and video projects, and I'm writing the maintainers' guides there, other packages such as rtorrent, bsdtar and netatalk does not belong to a project, so I don't know where to stick those maintainers' guides in. Does anybody have options? [1] http://www.gentoo.org/proj/en/desktop/video/xine.xml [2] http://www.gentoo.org/proj/en/desktop/video/vlc.xml [3] http://www.gentoo.org/proj/en/desktop/sound/alsa.xml -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzZYV5uiFXS.pgp Description: PGP signature
