[gentoo-dev] Re: openrc portage news item

2011-04-15 Thread Peter Hjalmarsson
tor 2011-04-14 klockan 08:09 + skrev Duncan:
 1) While baselayout-1 had a parallel boot option, it was quite broken and 
 (partly or entirely, not sure which) non-functional.  The same thing in 
 baselayout-2/openrc works WELL and I use it all the time.  (Given the 
 emphasis placed on this in the media, the various boot-timing contests, 
 etc, and the fact that this feature puts Gentoo in-play again in regard to 
 speed-boots, it's a pretty big positive in favor of upgrading.)

This feature is still not really perfect, at least not perfect enought.
Use squid on a system where it takes longer for its daemon to exist
(like my router, where the media is a intel SSD, 4GB memory and a AMD
Athlon 2x on the AM3 socket) and you will see lots of outputs from
openrc about all those scripts waiting for it to end...

So maybe when that feature is ready to be enabled by default?

Peter Hjalmarsson

[gentoo-dev] Why (i.e. USE=openssl instead of USE=ssl)

2010-08-14 Thread Peter Hjalmarsson
This is about my beloved USE=ssl. A bit long and ranty, but if you
want the consensus, just read the last part.

Today a new snapshot of gnash was uploaded where the old USE=ssl was
renamed to USE=openssl.

So yet another package where if you want ssl support you have to
_personally_ audit what function this useflag has (i.e. does it enable
ssl or tune the ssl implementation?).

So I wanted to figure it out, does gnash provide ssl itself and the
USE=openssl only tunes how it is implemented or does USE=openssl
enable ssl?

So what does the flag really do? Their local description does not say
very much:
local:openssl:www-plugins/gnash: Enable directly using OpenSSL

What is even enabled directly? Still not much smarter.
Unpacking the source and looking in ./configure --help and the strange
description for the use flag gets an explanation:
--enable-sslEnable using OpenSSL directly

Still not much smarter...

Looking inside configure.ac makes me smarter tho:

dnl Enable using OpenSSL with libnet.
  AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]),
[case ${enableval} in
  yes) build_ssl=yes ;;
  no)  build_ssl=no ;;
  *)   AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;;
esac], build_ssl=no)

So apparently it seems the flag enables ssl support using openssl.

No, I did not review the source to make sure that build_ssl does really
build ssl, but do I really have to to find out what a USE-flag does?

Personally I would still like the description for the useflag to really
describe the flag, like:
global:ssl: Adds support for Secure Socket Layer connections

(and thus in this case the use flag to still be USE=ssl)

And why I post here instead of making a bug is to try to start a
discussion that is still not finished[1]:
What function should useflags bring?

There are some packages (like networkmanager) that does not have a ssl
flag (it is always enabled), and the gnutls/nss useflags are used to
fine tune what implementation to use. If non selected the upstream
preferred (nss) is chosen.

Then there are some packages (like qemu) where there is only one flag
(USE=gnutls) that enables support for encrypten vnc.

Then there are packages like curl where the local description of
USE=ssl says it all:
local:ssl:net-misc/curl: Enable crypto engine support (via openssl if
USE='-gnutls -nss')

So as a user, if I want to have Secure Socket Layer or Transport Layer
Security, do I really need to learn the name of every implementation
known to man and enable their respective use flag to ensure that my
whole system has support for it, or should I just have to enable
And will I still be sure that those use flag did not disable a (maybe
superior or by maintainer preferred) internal ssl implementation?

[1] Last time I did a bugreport about this, here is the answer:

Peter Hjalmarsson

[gentoo-dev] Re: Why (i.e. USE=openssl instead of USE=ssl)

2010-08-14 Thread Peter Hjalmarsson
lör 2010-08-14 klockan 13:45 +0200 skrev Chí-Thanh Christopher Nguyễn:
 Peter Hjalmarsson schrieb:
  This is about my beloved USE=ssl. A bit long and ranty, but if you
  want the consensus, just read the last part.
  Today a new snapshot of gnash was uploaded where the old USE=ssl was
  renamed to USE=openssl.
  So yet another package where if you want ssl support you have to
  _personally_ audit what function this useflag has (i.e. does it enable
  ssl or tune the ssl implementation?).
  So I wanted to figure it out, does gnash provide ssl itself and the
  USE=openssl only tunes how it is implemented or does USE=openssl
  enable ssl?
 The USE flag was renamed after discussion with upstream. Gnash does not 
 provide any SSL implementation itself and (when invoked as NPAPI plugin) 
 uses the browser's facilities. Possibly I could make more explicit that 
 users only interested in the plugin don't need it.
 Best regards,
 Chí-Thanh Christopher Nguyễn

Well if that is the use of the use flag the description is to be honest
really bad.

And still, why openssl instead of ssl? Even if most people are out to
only get the plugin the meaning of use flag for the rest of the package
is still the same. So is there a special reson why upstream do want ssl
disabled for people only out to get the plugin (and why not EAPI=1 and

[gentoo-dev] Re: Why (i.e. USE=openssl instead of USE=ssl)

2010-08-14 Thread Peter Hjalmarsson
lör 2010-08-14 klockan 15:14 +0300 skrev Samuli Suominen:
  [1] Last time I did a bugreport about this, here is the answer:
 Long story short:
 If package has SSL support, and use ssl is ignored or not present in a
 ebuild. it's plain broken.
 Every ebuild in tree with USE=openssl is a QA violation, and should be
 fixed asap.

Is there a policy I can point Doug to in the bug referenced as he asks
for it?

[gentoo-dev] Re: New global use flag: vpx or vp8

2010-08-13 Thread Peter Hjalmarsson
lör 2010-07-31 klockan 13:37 +0200 skrev Hanno Böck:
 vpx for supporting googles vp8 codec used in webm.
 At the moment this is only mplayer and ffmpeg, but it's pretty obvious that 
 apps supporting vp8 will start popping up everywhere (currently working on 
 arista ebuild which will support it).
 Though we might discuss if vpx is really a good name or it shouldn't be vp8.

This feels like the standard discussion about a use flag for function
versus a use flag for dependencies.

Myself I think this should follow the most commonly for ssl found
nameing convention which is that:

USE=ssl provides ssl support in all packages. If a package has
optional ssl-support they should have this flag.

USE=gnutls openssl nss ... finetunes which implementation of ssl to
use. They should never exist without USE=ssl unless they package has
unconditional ssl support.

Of course there are people who think otherwise even for ssl/tls, and so
you cannot be sure that you have ssl/tls support even if you have
For example if you cannot connect with vnc using tls to your qemu
virtual machine then you have to look up that ebuild to see that tls is
only enabled if you have USE=gnutls. I think that is suboptimal and
confusing for the user.

So I think a USE=vp8 or USE=webm (probably the first) to enable
decoding, and USE=vpx should be used to fine tune what implementation
to use. Having USE=vp8 (no USE=vpx specified) in make.conf should
give you support for vp8 in all packages and the implementation should
be the maintainers preference for that package.

[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults

2010-07-05 Thread Peter Hjalmarsson
mån 2010-06-28 klockan 15:05 +0100 skrev Ciaran McCreesh:
 On Mon, 28 Jun 2010 14:59:21 +0100
 Roy Bamford neddyseag...@gentoo.org wrote:
  All of engineering involves compromise.
 It's not a question of compromise. It's a question of being right vs
 being wrong. If one person says that 2 + 2 = 4 and a loud mob screams
 that their prophet revealed to them in a blog post that 2 + 2 = 6, you
 don't compromise and say that 2 + 2 = 5.

Sorry for being late to the party, but:
http://www.thinkgeek.com/tshirts-apparel/unisex/generic/60f5/ [1]

Nothing is EVER black or white. Not even the physical ones and zeros in
your computer are. That is why we have politics. To make compromises
which tells us what we should parse as a one or a zero.

1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know
how to round numbers, and that 2 can be rounded from everything between
1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.)

[gentoo-dev] Re: New global USE flag: introspection

2010-06-22 Thread Peter Hjalmarsson
tis 2010-06-22 klockan 15:17 +0530 skrev Arun Raghavan:
 On 21 June 2010 21:23, Arun Raghavan ford_pref...@gentoo.org wrote:
  I'm still trying to think of a good name. I understand the concerns
  about introspection being too generic and non GNOME-y, but gir is
  likely to cause confusion.
 gir is not good because it gives near-zero information.
 I can still not think of short enough USE flag. I propose we stick to
 introspection. There isn't anything on the horizon that might
 overlap with this flag, and I don't see why we should drop using a
 simpler flag for the *possibility* that it might overlap with
 something else in the future. We can deal with this if it happens.

Why not just gintrospection?

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild

2010-06-20 Thread Peter Hjalmarsson
sön 2010-06-20 klockan 15:55 +0200 skrev Arfrever Frehtes Taifersar
 This problem is probably caused by bugs in Python 2, which have been fixed in 
 Python 3.
 $ echo 'a = True'  test.pyx
 $ cython test.pyx
 $ gcc -O2 -Wall -I/usr/include/python3.1 -c test.c
 $ gcc -O2 -Wall -I/usr/include/python2.6 -c test.c
 test.c: In function ‘inittest’:
 test.c:479: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 test.c:479: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 test.c:479: warning: dereferencing pointer ‘_Py_TrueStruct.42’ does break 
 strict-aliasing rules
 test.c:479: warning: dereferencing pointer ‘_Py_TrueStruct.42’ does break 
 strict-aliasing rules
 test.c:479: note: initialized from here
 test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break 
 strict-aliasing rules
 test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break 
 strict-aliasing rules
 test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break 
 strict-aliasing rules
 test.c:482: warning: dereferencing pointer ‘__pyx_t_1’ does break 
 strict-aliasing rules
 test.c:479: note: initialized from here

Actually this makes me question the append-flag even more.
Why mess with what gcc does with the code for all versions of python if
it works for x version of python?
And only for som warnings? I could have understand a bit more if it
was Errors.

Also why not even a comment saying?

Currently as one of the users of hardened and helping Zorry out with the
hardened toolchain I have seen many packages filter flags like -fPIE and
-fstack-protector without a comment on why, where and how it broke, and
noone remeber why.
New versions comes of software and if you do not know why it broke with
a cflag you cannot test if the breakage is still there.

This line of code is fine and all that until you forget why you added
that flag or you retire and a later maintainer of the package does not
dare to touch the flag since they do not know why it was added and what
will break if the remove that line of ebuild code.

[gentoo-dev] Re: About libpng-1.4 handling

2010-05-11 Thread Peter Hjalmarsson
mån 2010-05-10 klockan 23:52 -0400 skrev Mike Frysinger:
 On Monday 10 May 2010 23:10:48 Markos Chandras wrote:
  provide a user friendly way to migrate to the new libpng without the need
  to spend so many hours digging around on which packages to rebuild.
 if you're digging around then clearly you havent done the obvious and run 
 revdep-rebuild ?  that is pretty user-friendly.

I did, but revdep-rebuild did not take *.la into account (I did run it
as revdep-rebuild --ignore -- --jobs 10 --keep-going if that has any
impact) and many of the things it wanted to rebuild plainly failed
because a library that did not link against libpng12 had it in its *.la
(libgnomeui is on example of this). This led to that the library
(example: libgnomeui) was not set to be rebuilt, but the packages
pulling libgnomeui in broke because while linking they could not find

[gentoo-dev] Re: ccache causing problems

2010-05-03 Thread Peter Hjalmarsson
fre 2010-04-30 klockan 16:34 + skrev Robin H. Johnson:
 Note however, that while I have a high level of trust in ccache, I do
 think there are more latent bugs in distcc.

Heh, yeah. I have had problems with ccache having broken cache (i.e.
stuff breaks, removing the cache and it unbreaks) on different
computers, but since I stopped use distcc together with it I have had no
such problems anymore.
Still since those experiences I always start with trying without ccache
when I hit strange bugs.

[gentoo-dev] Re: [RFC][NEW] Utility to find orphaned files

2010-05-03 Thread Peter Hjalmarsson
fre 2010-04-30 klockan 18:24 +0200 skrev Enrico Weigelt:
 * Daniel Pielmeier bil...@gentoo.org schrieb:
  What about searching the complete file system but using an exclude file 
  you can put directories and files which should not be searched. It is 
  tedious to
  tell every path on the command-line. Also for instance if you specify /lib 
  will also search under /lib/modules and I am sure you do not consider all
  contents there as unneeded.
 hmm, perhaps there's some way to assign these files to some package ?

Eh, no and it should not be since files in that directory is kernel
modules, and most of the files there is created by cd /usr/src/linux 
make or genkernel or something alike and it is supposed to be that way.
Looking at the contents of that directory is pretty easy to see if a
directory there should be left alone or removed (as there is just one
directory per kernel. not any longer running a kernel anymore? remove
the corresponding dir).
It is better to have the script not tuch that directory at all or at
most point out the directory contains directories for more kernels then
the currently running (i.e. there is more then one dir) and it is
totally THIS big. You may want to take a look if you have files from
older kernels that you do not longer need.
That would leave up to the user to figure out what kernel modules to
keep and what kernel to pount. Or you suggest autocleaning of /boot
and /usr/src/linux-* as well? Dangerous!

[gentoo-dev] Re: Should we disable RESOLVED LATER from bugzilla?

2010-04-05 Thread Peter Hjalmarsson
mån 2010-04-05 klockan 03:54 +0300 skrev Mart Raudsepp:
 The problem is really the RESOLVED connotation and the hiding that goes
 along with that on searches, etc.
 The LATER status itself can be useful when used properly (more as
 ASSIGNED LATER). In the lack of that some bigger teams might need to
 think of other methods to get things meant for LATER out of main views
 of huge bug lists.

Actually I think this is the best yet.

I have always found the sounding of RESOLVED LATER so harsh. ASSIGNED
LATER would more sound like we know there is a problem, and we know it
should be fixed, but we cannot do it now for different reasons.

[gentoo-dev] when to use a function and an implementation use flag.

2010-03-24 Thread Peter Hjalmarsson
I took a look at qemu-kvm and found something I percieve as funny:
It had a gnutls use-flag, but no ssl useflag.

As I see it is I want ssl/tls support it should be sufficient to enable
USE=ssl and let the maintainer of said ebuild decide which
implementation (if more then one) I am better off with and only care
about the USE=gnutls openssl nss if i really think the maintainer is

For qemu-kvm the problem is that there is only one implementation (i.e.
gnutls), and if I want to have ssl support I have to enable gnutls for
this package.

When I wrote a bug about this I got a rather short reply from maintainer
about pointing me to the policy about this.
Now I know there was a disscussion a while back about this on the
mailinglist, but google fails me to find it, looking into the Gentoo
Development Guide [1] it fails me too.

There is not a _single_ word about how to handle if there is only one
implementation, but two use flags for this (one for the function
provided - ssl - and one for the actual implementation - gnutls).

So I have a question:
Is there no policy about this?
If there is could someone please point me towards it and also it in that
case may be time to update the gentoo development guide.


[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it

2010-03-20 Thread Peter Hjalmarsson
fre 2010-03-19 klockan 05:13 -0500 skrev Dale:
 Because, when I installed gcc 4.3, I could then unmerge the old gcc.  
 That's why I didn't complain about that.  With python, we still have to 
 have the current version plus the new version which is not being used at 

That was if you did not use qemu that did *not* compile or run with a
gcc never then gcc-3 for a couple of years...

Also search for gcc-porting in b.g.o and guess what: there are many
packages that fits this description for gcc, qemu was just a special
case since for it it actually took YEARS before upstream released a
version that worked with gcc-4, most other packages is often easier to
patch (since it is mostly compile-time brokenness related to headers or
other small fixes) and our awesome toolchain guys helps fixing it up
before it hits ~arch.

[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it

2010-03-20 Thread Peter Hjalmarsson
I have a question related to this:

If I have package X which supports python2 and python 3, and I install
it without python3 installed it will only install python2-files
(i.e. /usr/lib/python2.x/*), right?
What happens if I later install packages Y that is only python3, and
relies on the python3 parts of package X? Can this happen and how will
the PM handle that (reemerge package X installing the python3 parts or
fail to compile package Y due to missing python module)?

[gentoo-dev] Re: Re: Python 3.1: Stabilization and news item

2010-03-08 Thread Peter Hjalmarsson
mån 2010-03-08 klockan 10:53 +0100 skrev Antoni Grzymala:

 Sorry guys if I missed something crucial in this lengthy thread, but
 from what I'm understanding:
 if python-3 goes stable (and unmasked):
 - it is a separate, slotted version
 - it generally shouldn't get pulled in (current portage non-greedy
   behaviour on slots)
 - if it does get pulled in by, say, and old portage version, or a
   package with badly defined deps, it shouldn't do any harm because it
   will just sit quietly in its slot and old packages will still
   compile/run against (already installed) python-2.x
 or not?
 PS. one thing I realize I may be missing is the /usr/bin/python symlink
 and the /usr/bin/python-wrapper to which it points. Will the default
 change to python31 upon python-3 installation?

AFAICS you are right (and that is also why I have a hard time
understanding the flames here, are people so against fixing the deps in
their packages and/or filing bugs and/or contacting devrel about those
maintainers who refuse to fix their packages?).

about your ps: pyhon-3 is absolutely harmless in its current form, and
that is partly because it does not take over the role as the system
python unless you do something stupid/uninformed.

[gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches news item for review)

2010-03-08 Thread Peter Hjalmarsson
mån 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp:

 Instead I think we should be improving eselect profile to support
 multiple inheriting /etc/make.profile files in a user friendly fashion,
 and in the end removing 249 subprofiles, instead of adding 28+.

I vote for this one. A profile being a only contains what is interesting
for that profile, and you can stash together some profiles into your
own cocktail.
Yeah, I know it sounds horrible, but it would still be better then to
only be able to focus on one small set.

For example if I am using the GNOME DE, and have someone other also
using my computer, but who really wants to use KDE. Should I have to
find out what from the KDE profile to enable in my env to make my
GNOME-profile also tingle for KDE?

I think having a set of base profiles for toolchains and alike (i.e.
default, hardened) would be good. Then be able to add for example
desktop/gnome or server and/or selinux profiles on top would be
interesting. This also for maintainers, as for example PeBenito can
focus on the selinux part of the profiles, and do not have to keep up to
date with which hardened-compilers are currently masked/unmasked.

[gentoo-dev] Re: Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2

2010-03-05 Thread Peter Hjalmarsson
ons 2010-03-03 klockan 17:46 +0200 skrev Petteri Räty:
 On 03/03/2010 02:47 PM, Ciaran McCreesh wrote:
  On Wed, 03 Mar 2010 09:47:37 +0100
  Tomáa Chvátal scarab...@gentoo.org wrote:
  Removing eclass functions like this is not allowed by current
  policy. If you want to do it, you should discuss about changing
  since when?
  Since ever.
  If you change eclass abi you need to rename it.
  No, that's not been the case 'since ever' at all. It used to be that if
  you changed or removed a function, you just had to make sure you didn't
  break anything. This was made more complicated by the way that eclasses
  in the tree were used for removing installed packages too, which is no
  longer an issue.
 You can't fix all possible overlays so you can only start removing
 functions that are used for installations if we decide we don't care
 about overlays.

I have start to question why should we care about overlays more then the
actual portage tree?

Take for example the kernel or Xorg.
They give themselves a period of time to clean up their own code (i.e.
kernel-modules, xorg-drivers) and then they release it as stable and
tell users/distributors to upgrade.
They do not wait for nVidia/AMD/other out-of-tree drivers/modules to
catch up.

Now if we say we have someone managing an overlay, and this person do
miss this warning/die for half an year, then I would say they have nott
done their homework and they are on their own. I do not see why we
should wait unreasonable long periods of time because there may be
someone broken somewhere.

How long does Ubuntu wait for PPAs to catch up or do they expect the
managers of the PPAs to actually follow development? How about Fedora?

[gentoo-dev] Re: [rfc] layman storage location (again)

2010-01-18 Thread Peter Hjalmarsson
mån 2010-01-18 klockan 06:27 +0100 skrev Ulrich Mueller:
  On Mon, 18 Jan 2010, Sebastian Pipping wrote:
  isn't a package tree somehow having system-wide implications?
  i'm not really sure about /var/db - doesn't seem to be in FHS.
  is a package tree a database?
 This depends on your definition of database. At least some parts of
 the tree (like the files/ dirs) at not very database-like.
  current ranking through my eyes:
  1) /var/layman   con: adds folder to /var, maybe should not
  2) /var/db/laymancon: you tell me
  3) /var/lib/layman   con: not really /var/lib-style data
 I still think that it should be close to the portage tree, therefore
 in /usr. But if you go for /var then take /var/layman.

I sometimes think the main problem is the tree itself. Portage really
should had a directory of its own, but maybe with anoher structure,
like /var/portage, /var/portage/tree (the current
PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
itself), /var/portage/overlays/layman or /var/portage/layman.
I of course realize that change the structure of the whole portdir would
had inresting complications, so take this comment just as serious as you

But overlays really was an afterthought?

[gentoo-dev] Re: Re: [rfc] layman storage location (again)

2010-01-18 Thread Peter Hjalmarsson
mån 2010-01-18 klockan 12:40 +0100 skrev Michael Haubenwallner:
 Alex Alexander wrote:
  On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
  I sometimes think the main problem is the tree itself. Portage really
  should had a directory of its own, but maybe with anoher structure,
  like /var/portage, /var/portage/tree (the current
  PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
  itself), /var/portage/overlays/layman or /var/portage/layman.
  I of course realize that change the structure of the whole portdir would
  had inresting complications, so take this comment just as serious as you
  /var/portage/overlays (non-layman managed, layman could also be in here)
 Not that I really care, but are these portage-only and we might need
 /var/{paludis,pkgcore,...}/*? So what about /var/gentoo/*?

I think gentoo is too non-specific. portage is more or less a good
name for everything with regards to the package management in gentoo.

That there is a name collision between that and the default
implementation of a package manager I see just as an coincidence.
Just like Gentoo both can refer to a distribution and a file-browser.
Or RPM is both a file-format and a tool to handle said file format.

[gentoo-dev] Re: [rfc] layman storage location (again)

2010-01-16 Thread Peter Hjalmarsson
lör 2010-01-16 klockan 19:16 +0100 skrev Sebastian Pipping:
 On 01/16/10 05:39, Mike Frysinger wrote:
  On Friday 15 January 2010 20:55:18 Sebastian Pipping wrote:
  On 01/16/10 02:45, Mike Frysinger wrote:
  the better idea
  though would be to split your stuff along the proper lines.
  cache files = /var/cache/layman/
  as i said: it's not a normal cache.
  you said but didnt explain why it's special.  these are merely caches of 
  external overlays and xml caches of overlay lists.
 to me cache is something that speeds up operation but does not hold
 content of real value.  with layman overlay checkouts that's a bit
 different.  let's say a host overlay is taken offline: now the layman
 copy is my only source.  Page [1] describes /var/cache as
 Long term data which can be regenerated. so to me it's not a cache
 because there might be data in there that we cannot regenerate.
That is for the overlays, yeah?
But hov about the cache_*.xml files?

I think what he meant was that should layman really only has one
directory? One for cache (downloaded/downloadable lists of overlays?
in /var/cache/layman/?), one for the make.conf and overlay.xml
(/etc/layman/?) and maybe one more directory for the overlays

That make.conf/overlay.xml may not go as cache, nor do the overlays
themselves, but as I said, should really it all be in the same

[gentoo-dev] Re: [rfc] layman storage location (again)

2010-01-16 Thread Peter Hjalmarsson
lör 2010-01-16 klockan 19:31 +0100 skrev Jörg Schaible:
 dev-ran...@mail.ru wrote:
  On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
  2010/1/16 Peter Volkov p...@gentoo.org:
   layman cache is nfs distributable. Also it's good idea to have it close
   to PORTDIR. Thus I'd like to keep it somewhere at /usr.
  I'd like both to be under /var/
  I _use_ both under /var/. In my config PORTDIR_OVERLAY=/var/repos/{many
  directories} and PORTDIR=/var/repos/gentoo. /usr/ is too crazy place
  for ebuilds. IMHO.
 Same for me. I have PORTDIR also beneath /var ...
 - Jörg

Me too. I consider /usr/portage as one of those design flaws/thinkos
that are left behind since noone are ready to take the blame and flames
of all those who do not want to read elog-messages/announces and alike
and want to raise hell if somethings changes they are note prepared for.

[gentoo-dev] Re: Re: QA last rites for x11-wm/ion

2009-12-15 Thread Peter Hjalmarsson
mån 2009-12-14 klockan 19:03 -0500 skrev Mike Frysinger:
 On Monday 14 December 2009 18:38:36 Ryan Hill wrote:
  On Sun, 13 Dec 2009 20:46:18 +0100 Diego E. Pettenò wrote:
   # Diego E. Pettenò flamee...@gentoo.org (13 Dec 2009)
   #  on behalf of QA team
   # Pre-strip files (bug #241534), ignore flags (bug #241556),
   # misplaces documentation (bug #241560), bump request open
   # since August 2008 (bug #235888).
   # Removal on 2010-02-11
  Really?  Does it not build or something?  That's pretty weak.
 yeah, not clean enough doesnt really imply pmask+punt.  if it build fails, 
 that's a different story.

On the other hand this may be something for treecleaners? A package that
has not been bumped for 7 years? With at least three releases since, and
a bumprequest open for at least one year? A link to a webside that does
not exist?
Sound like a Gentoo maintainer gone MIA or alike.
Also the project is currently more or less dead upstream since the
upstream dev switched to windows.

So I see diegos point in giving it two months to be picked up by someone
that may want to use it/maintain it.

[gentoo-dev] Re: [RFC] Enable userpriv by default? Support RESTRICT=userpriv? Interaction with prefix in EAPI 3?

2009-12-11 Thread Peter Hjalmarsson
fre 2009-12-11 klockan 12:11 -0800 skrev Zac Medico:
 Should we enable FEATURES=userpriv by default? If we do that then do
 we also need to support RESTRICT=userpriv? Maybe RESTRICT=userpriv
 should not be supported on the grounds that it is never justified?
 What about prefix support (in EAPI 3), which often doesn't have root

That would be problematic for hardened, as they set the permission
for /usr/src/* to root only.

[gentoo-dev] Re: A parting gift

2009-12-03 Thread Peter Hjalmarsson
ons 2009-12-02 klockan 17:55 + skrev Jacob Todd:
 On Wed, Dec 02, 2009 at 09:15:10AM +0100, Gunnar Wrobel wrote:
  ... I did buy the rights to my book back.
 Wait, you don't keep the 'rights' to *your* book when it's published?

No this is a common thing with books. Remember some time ago in sweden
some writers wanted to republish their book, but their current publisher
did not want to. Created some spectacle when they did go to another
publisher only to find out about this clause in the contract with their
first publisher.

[gentoo-dev] Re: FEATURES use or misuse?

2009-11-04 Thread Peter Hjalmarsson
tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer:
 Hi there,
 All of these bugs were for the use of the FEATURES variable in ebuilds, which 
 is a very convenient thing to work around issues. 
 For example known failures with FEATURE=distcc or funky things like test 
 failures with FEATURES=userpriv and so on. All other methods of expressing 
 that are much more verbose and inherently sucky.

I ask myself if what we really want is many different and strange
approaches to handle FEATURES?
Would it not be better to actually expand some eclasses to be able to
say something about your build environment?
I mean where the checks for userpriv is needed also prefix will fail,
because AFAIK it can be used to build and install programs in an
non-root environment? Or if you just test an ebuild and runs it as your
user? So would it not just be better to have a check for which privs the
user has so it covers more fields?
For ccache and for distcc would it not be better to expand
toolchain-funcs so you can have a function like tc-getCC from which
you can get that sort of information?

Also if the ebuilds does not already have a comment about it, do not
forget to comment on why these checks are there, and why they are a must
(i.e. a broken buildsystem should be fixed, not worked around - while
tests that are designed to run as root should not be run as a user even
if in the best of worlds all testsuits should test and skip those tests
I would not like to see a new kind of hell where when something is
broken it is not fixed properly, but in a strange ways worked around in
ways that does not always work.
qemu and kvm is good examples on how NOT to do this these with regards
to hardened.

qemu (which kvm apparently has used as a template) has a broken build
system (it does not link with CFLAGS, only LDFLAGS, which is something
that also the gcc devs say you should not if you want a predictable
result), and it also invokes filter-flags at the wrong place in the
ebuild (hint: int should be invoked before the command that sets the
CFLAGS, in this case ./configure and not after like in these ebuilds).
Instead it has some strange logic to unset/change the GCC_SPECS which if
it ever worked certainly does not anymore (bugs filed for both, qemu bug
is really old, but very noisy, bug for kvm has been open for about an
week which the qemu maintainer may want to check out, with a clean patch
of one added sed a move of filter-flags and the removal of the whole
src_compile block to make the ebuild install something which (in case of
qemu) actually build, and does not segfault as soon as it uses a bit

[gentoo-dev] Re: RFC: USE=qa-test

2009-10-11 Thread Peter Hjalmarsson
Sorry for reviving an old thread, but was there any progress on this

With packages as dbus that breaks with FEATURES/USE=test hand in hand
with packages like dev-libs/gmp[1] there would really be nice to know if
you are supposed to be screwed or helped by FEATURES/USE=test...

[1](from http://gmplib.org/)

GMP is very often miscompiled! Please never use your newly compiled
libgmp.a or libgmp.so without first running make check. If it doesn't
complete without errors, don't trust the library. Please try another
compiler release, or change optimisation flags until it works. If you
don't have the skill to isolate the problem, please report it to us as
if it was a GMP bug; else to the compiler vendor. (The compilers that
cause most problems are HP's unbundled compilers and gcc, in particular
Apple's gcc releases.)

N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines.

[gentoo-dev] Re: RFC: USE=qa-test

2009-10-07 Thread Peter Hjalmarsson
ons 2009-10-07 klockan 16:46 +0200 skrev Gilles Dartiguelongue:
 Le mardi 06 octobre 2009 à 20:38 -0600, Ryan Hill a écrit :
  Some packages, like dbus[1], have testing features that, while useful for
  developers and arch-testers, aren't something that should be foisted on
  users.  Dbus' case is extreme, as it builds-in functions that are useful for
  unit testing, but result in an insecure and unstable package (I just 
  fixed a
  bunch of testsuite failures i've been seeing in dbus-using packages by
  disabling USE=test). Other packages have testsuites that take an 
  amount of time to build/run (db, ppl, boost, that faad/faac one that takes
  six hours), are pretty much guaranteed to fail (gcc, binutils), have strange
  dependency quirks (can't run the tests unless the package is already
  installed, create circular dependencies), or a dozen other situations I 
  think of right now.
  I'd like to propose a new USE flag, qa-test or a better name, to handle 
  cases in a consistent way.  This would give us a way to differentiate 
  tests that everyone should run and tests that only devs and arch-testers
  would be interested in, making enabling FEATURES=test by default in a future
  EAPI a little more palatable.Use of this flag would be up to the
  maintainer, of course.
 while it might sound sane, I think this proposal covers too much cases,
 most of which should actually be filled as bugs to the maintainers of
 the packages for not fixing the testsuite (or not filling an upstream
 bug) before commiting to the tree.
 For gnome ebuilds as someone commented out, the test failure rate is
 quite stable, and we are slowly trying to get around them, or at least
 not commiting ebuilds with new regressions in the testsuite.
 Use of RESTRICT=test shouldn't be encouraged as it disables tests
 completely while part of them might still work and be relevant.

The problem comes with packages like dbus where the testsuit is pretty
useful for ATs, but if dbus is merged with FEATURES=test then other
testsuits for other packages depending on dbus breaks, which AFAICS
tells us that a dbus built with tests is pretty broken for general


FEATURES=test emerge -1q dbus  FEATURES=test emerge -1q
and dbus-python will FAIL its testsuit.

FEATURES=-test USE=-test emerge -1q dbus  FEATURES=test emerge
-1q dbus-python
and dbus-python will compile, test and install without problems.

Now how do we ensure that the ATs still can test a package even under
these conditions?
Because as I see it RESTRICT is only for packages whose testsuits are
broken by design and never meant to be run on a working system (yeah
*drm*, I am looking at you).

I think we first hand should decide over these packages, after a
decision is made about these problems with MORE then a compile-time
impact, we can start talking about less important problems (i.e.
problems that do not break stuff) like how long time a testsuit is
supposed to run.

And FEATURES=test IS sometimes a good thing, I learned this the hard
way once when something broke grub for me, and one of the things that
made my system unbootable was one of those things the grub testsuit
checks for.

[gentoo-dev] Re: RFC: LD_AS_NEEDED=1 in profiles/targets/developer/make.defaults?

2009-10-04 Thread Peter Hjalmarsson
lör 2009-10-03 klockan 14:21 -0600 skrev Ryan Hill:
 On Sat, 03 Oct 2009 22:13:59 +0300
 Samuli Suominen ssuomi...@gentoo.org wrote:
  Since new binutils will support LD_AS_NEEDED=1 to force ld behave
  asneeded we could use this for the developer -target in profiles?
  Speak up if you think it's a terrible idea.
  Thanks, Samuli
 I think it's a not terrible idea.
 Only barely related: can we enable FEATURES=test too?

For FEATURES=test a policy for how to handle stuff like:

if use test; then
ewarn You have unit tests enabled, this results in an insecure 
ewarn It is recommended that you reinstall *without* 

needs to be formed before enabling it anywhere by default. Should this test 
really be run by default, or should it be shielded by USE=unsafetests or 
something of just restricted?

My 2 cents.

 and scroll to the bottom. 

//Peter Hjalmarsson

[gentoo-dev] Re: Re: Developer Retirements

2009-03-12 Thread Peter Hjalmarsson
tis 2009-03-10 klockan 08:29 -0700 skrev Alec Warner:
  With some devs reviewing gentoo-commits@, I highly doubt that this commit
  could go unnoticed more than a few hours.
 really? cause I bet I could slip something in; now I'm motivated to try ;p

Looking inside of package.mask this morning I think someone got there
before you:

# Tomas Chvatal scarab...@gentoo.org (6 Mar 2009)

You have that in between of two diffrent masks. Nothing more, nothing
So even thou some devs review gentoo-commits@ it seems like they are not
über-super-humans and sometimes even they miss things.