[gentoo-dev] Re: GCC 4.6.0

[Diego Elio Pettenò]

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/

[gentoo-dev] Re: www-client/chromium and asian fonts, help needed

[Diego Elio Pettenò]

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

Re: [gentoo-dev] www-client/chromium and asian fonts, help needed

[Ulrich Mueller]

> 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

Re: [gentoo-dev] www-client/chromium and asian fonts, help needed

[Chí-Thanh Christopher Nguyễn]

"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

[Mike Frysinger]

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

[gentoo-dev] www-client/chromium and asian fonts, help needed

[Paweł Hajdan, Jr.]

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] KDE4 eclasses review

[Marc Schiffbauer]

* 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

Re: [gentoo-dev] git-2.eclass final review

[Marc Schiffbauer]

* 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] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeroen Roovers]

On Tue, 5 Apr 2011 03:58:05 -0700
Alec Warner  wrote:

> http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

People tend to visit  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] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Alec Warner]

On Mon, Apr 4, 2011 at 9:26 PM, Jeroen Roovers  wrote:
> On Sun, 27 Mar 2011 23:28:05 +0200
> René 'Necoro' Neumann  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
>  to actually interpret packages'
>  and displaying its formatted contents on every
>  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).  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
>
>