Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Mon, Apr 4, 2011 at 9:26 PM, Jeroen Roovers j...@gentoo.org wrote: On Sun, 27 Mar 2011 23:28:05 +0200 René 'Necoro' Neumann li...@necoro.eu wrote: Am 27.03.2011 22:44, schrieb Rich Freeman: Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). I remember distinctly that I once publicly proposed to change http://packages.gentoo.org/ to actually interpret packages' metadata.xml and displaying its formatted contents on every http://packages.gentoo.org/package/CAT/PKG page (notably because the site mentioned and still mentions the last committer at the top of the page, with his or her Gentoo e-mail alias/handle plainly visible, so at the time I envisioned it to prevent people from addressing the wrong developers). metadata.xml is a mere link on every page and doesn't invite anyone to dig deeper, when it could be put to better use. Our bugzilla database already has proper descriptions for every alias we use, so we could reuse that information to improve packages.g.o. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml ? (Only, I cannot now find any trace of such a discussion at all, or even the bug report I am quite certain I would have filed about this.) jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Tue, 5 Apr 2011 03:58:05 -0700 Alec Warner anta...@gentoo.org wrote: http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml People tend to visit http://packages.gentoo.org/ when they find a problem with a package, to find out more about the package, like who maintains it. You wouldn't visit the URL above unless you already knew about the maintenance status of a package. jer
Re: [gentoo-dev] git-2.eclass final review
* Mike Frysinger schrieb am 23.03.11 um 00:08 Uhr:
2011/3/22 Tomáš Chvátal:
Dne 22.3.2011 22:26, Mike Frysinger napsal(a):
# @BLURB: This eclass provides functions for fetch and unpack git
repositories
fetching/unpacking
Yarp fixed.
well, the fix broke the blurb. it has to be on one line.
# @BLURB: foo
EGIT_BRANCH=${x:-${EGIT_BRANCH:=${EGIT_MASTER}}}
EGIT_COMMIT=${x:-${EGIT_COMMIT:=${EGIT_BRANCH}}}
doesnt make much sense to use := ... it should be :-
[[ $# -ne 1 ]] die ${FUNCNAME}: requires 1 argument (path)
quoting doesnt make much sense ... -ne compares an int, not a string
If using [[ you never need to quote anyway.
-Marc
--
8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134
Re: [gentoo-dev] KDE4 eclasses review
* Tomáš Chvátal schrieb am 04.04.11 um 19:00 Uhr:
Hi guys,
since we didn't do this for quite long time I would like kde4 eclasses
reviewed as whole rather than on patch basis (altho i attach the patches
for convenience too).
It is 2 years since we reviewed them last time fully on -dev so lets see
how much weird/useless logic we can find (more heads know more).
Remember: nitpick on everything cause this thing is used in quite a lot
ebuilds so we need it in top-notch shape :)
This update brings support for git since upstream is slowly moving to
git repos from SVN. Dropped support for eapi2. Usage of fdo/gnome
classes to update mime stuff. Most of the koffice code removed as being
obsoleted and various loads of whitespace stuff.
Cheers
Tom
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: kde4-base.eclass
# @MAINTAINER:
# k...@gentoo.org
# @BLURB: This eclass provides functions for kde 4.X ebuilds
# @DESCRIPTION:
# The kde4-base.eclass provides support for building KDE4 based ebuilds
# and KDE4 applications.
#
# NOTE: KDE 4 ebuilds currently support EAPI 3. This will be reviewed
# over time as new EAPI versions are approved.
# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
# @DESCRIPTION:
# For proper description see virtualx.eclass manpage.
# Here we redefine default value to be manual, if your package needs virtualx
# for tests you should proceed with setting VIRTUALX_REQUIRED=test.
: ${VIRTUALX_REQUIRED:=manual}
[...]
KDE_MINIMAL=${KDE_MINIMAL:-4.4}
I'd suggest setting default for all variables the same way. I
personally like the : {X:=default} approach best.
: ${KDE_MINIMAL:=4.4}
-Marc
--
8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134
[gentoo-dev] www-client/chromium and asian fonts, help needed
There is a bug about www-client/chromium and asian fonts: http://bugs.gentoo.org/show_bug.cgi?id=359153 First, I'm just wondering whether making the browser RDEPEND on some fonts would be a correct solution. Maybe, similarly to the icon themes, we should just suggest some fonts in pkg_postinst. I have no idea which of the fonts listed in the bug above handle Chinese, Japanese, or Korean. It seems that it is important to differentiate between them. Short example: for a Chinese page we need the Chinese font, not just any CJK font. A Korean font might seem to render most of the Japanese characters correctly, but it's not 100% correct. Do you have some ideas how to handle that? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] www-client/chromium and asian fonts, help needed
On Tue, Apr 5, 2011 at 11:45 AM, Paweł Hajdan, Jr. wrote: First, I'm just wondering whether making the browser RDEPEND on some fonts would be a correct solution. Maybe, similarly to the icon themes, we should just suggest some fonts in pkg_postinst. i dont think you should be depending on fonts. a pkg_postinst elog sounds fine though. -mike
Re: [gentoo-dev] www-client/chromium and asian fonts, help needed
Paweł Hajdan, Jr. schrieb: First, I'm just wondering whether making the browser RDEPEND on some fonts would be a correct solution. Maybe, similarly to the icon themes, we should just suggest some fonts in pkg_postinst. You could extend the existing virtual/ttf-fonts with a new cjk USE-flag, which would make it depend on one of the suggested fonts from bug 359153. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] www-client/chromium and asian fonts, help needed
On Tue, 05 Apr 2011, Paweł Hajdan, wrote: There is a bug about www-client/chromium and asian fonts: http://bugs.gentoo.org/show_bug.cgi?id=359153 First, I'm just wondering whether making the browser RDEPEND on some fonts would be a correct solution. Maybe, similarly to the icon themes, we should just suggest some fonts in pkg_postinst. I think this would be conceptionally wrong. Fonts are a property of the X server and shouldn't be a dependency of an X client (which may even run on a different machine). Already chromium's dependency on virtual/ttf-fonts is wrong, IMHO. We had the same discussion for Emacs some time ago (see bug 137598), and we output a message in pkg_postinst() that Emacs requires fonts. Ulrich
[gentoo-dev] Re: www-client/chromium and asian fonts, help needed
Il giorno mar, 05/04/2011 alle 17.45 +0200, Paweł Hajdan, Jr. ha scritto: First, I'm just wondering whether making the browser RDEPEND on some fonts would be a correct solution. Maybe, similarly to the icon themes, we should just suggest some fonts in pkg_postinst. As Ulrich said, Chromium should not depend on the fonts at all. They use different methods of rendering fonts, but both do their work with finding the right font to use if one is installed. In general, one should be expected to have the right fonts installed for the right language to display. Also, I think singling out CJK here might be a bit inappropriate; while they are probably the most commonly known languages using non-latin scripts, they are definitely not the sole ones. Just take a look at the Wikipedia homepage[1] to see how many non-latin languages are there (and keep in mind that it's a subset of the world's languages). For what it's worth, in my screenshot there are four languages missing glyphs entirely, and a few having glitches, all of this with this selection of fonts: media-fonts/aquafont-2.7-r4 media-fonts/aquapfont-2.6-r2 media-fonts/arphicfonts-0.2.20080216.1 media-fonts/corefonts-1-r5 media-fonts/dejavu-2.33 media-fonts/droid-113-r1 media-fonts/encodings-1.0.4 media-fonts/font-util-1.2.0 media-fonts/freefont-ttf-20100919 media-fonts/fs-fonts-0.1_alpha3 media-fonts/ipamonafont-1.0.8 media-fonts/ja-ipafonts-003.02-r1 media-fonts/lohit-fonts-2.4.2 media-fonts/mikachan-font-otf-9.1-r1 media-fonts/monafont-2.90-r2 media-fonts/mplus-outline-fonts-0_pre037 media-fonts/sazanami-20040629 media-fonts/thaifonts-scalable-0.4.13 media-fonts/urw-fonts-2.4.9 [Yes I have a personal preference to CJ fonts myself..] [1] http://www.flameeyes.eu/tmp/wikipedia.png -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: GCC 4.6.0
Il giorno sab, 02/04/2011 alle 22.11 -0600, Ryan Hill ha scritto: Common errors: I've been running my tinderbox with GCC 4.6 now, so I hope to help out discovering the issue asap, but in the mean time I'd like to point out that GCC 4.6 (a little more than others, afaict) could cause ./configure scripts to fail (or misdetect availability of functions). If something does not seem to build right, but doesn't appear directly related to GCC 4.6, make sure to attach the config.log of the configure execution. In particular, since with GCC 4.5 (and modern glibc) doing things such as write(fd, buf, bufsize); would have caused return value ignored warnings, which would have thrown off detections using -Werror, they were rewritten as int n = write(fd, buf, bufsize); ... too bad that this *now* causes the unused but set warning. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
