Re: [gentoo-dev] Packages up for grabs: genstef gems special edition

2009-03-24 Thread Gordon Malm
On Monday, March 23, 2009 23:35:00 Tiziano Müller wrote:
 Am Montag, den 23.03.2009, 23:08 +0100 schrieb Peter Alfredsen:
  Since genstef has been .away for some time, I arranged with him that I'd
  send a list of his ebuilds that need maintenance to be put up for grabs.
  This list contains all ebuilds that have no herd, at least one open bug
  and where genstef is the maintainer.
 
  media-video/linux-uvc

 I'd have the hardware for that one if nobody else takes it.

Also note the UVC driver has been integrated into the mainline kernel as of 
2.6.26.



Re: [gentoo-dev] Developer Retirements

2009-03-09 Thread Gordon Malm
On Monday, March 9, 2009 11:44:55 Doug Goldstein wrote:
 I'm wondering what exactly is the harm in letting developers idle for a
 while? While they might not be actively committing they are still
 knowledgeable people that are just as capable as everyone else to push in a
 fix for small packages. There's lots of bugs in bugzilla with items that
 just need someone active to commit them. There's even a lot of these items
 are filed by retired Gentoo developers who could have easily pushed this
 fix for all users. The fact that someone only does one commit a year does
 not marginalize their contribution. While it may be small it is improving
 the overall quality of the distro. I'm constantly seeing developers getting
 upset over getting pushed out.

 What we really need is not a smaller, leaner development force. But a
 leadership team that's smaller and more effective and willing to take
 charge to get something done. I'm hoping that we can get away from the 6
 month GLEP process and towards something more streamlined.

 --
 Doug Goldstein


It is possible that maybe we've been too forceful in retiring people who still 
wish to contribute.  Sometimes it appears that way from the outside.  But as 
I am not on that team, I don't really know and therefore will not attempt to 
pass judgement on their processes.  From what I have seen and understand they 
do try to make contact multiple times to understand the situation before 
retiring anyone.

There is an important security aspect to retiring folks - commit abilities.  
Perhaps in the case a dev wants to contribute but cannot in the near future 
their commit privs can just be revoked until such time they ask for them to 
be turned back on?  I guess that would be an 'extended devaway' ?

Gordon Malm (gengor)



Re: [gentoo-dev] working on mysql-community 5.0.77 - mysql-extras

2009-02-27 Thread Gordon Malm
On Friday, February 27, 2009 15:12:04 Caleb Cushing wrote:
 I went ahead and use the order you used previously all the patches
 apply, but it still doesn't build.

 86_64-pc-linux-gnu-g++ -DEMBEDDED_LIBRARY -DMYSQL_SERVER
 -DDEFAULT_MYSQL_HOME=\/usr\ -DDATADIR=\/var/lib/mysql\
 -DSHAREDIR=\/usr/share/mysql\ -I. -I../include
 -I../innobase/include -I../innobase/include -I../include -I../include
 -I../sql -I../sql -I../sql/examples -I../regex  -DDBUG_OFF -O2
 -pipe -DHAVE_ERRNO_AS_DEFINE=1 -fno-exceptions -fno-strict-aliasing
 -felide-constructors -fno-rtti -fno-implicit-templates
 -fno-implicit-templates -fno-exceptions -fno-rtti -MT field_conv.o -MD
 -MP -MF .deps/field_conv.Tpo -c -o field_conv.o field_conv.cc
 In file included from lib_sql.cc:34:
 ../sql/mysqld.cc: In function ‘int init_server_components()’:
 ../sql/mysqld.cc:3436: error: ‘make_master_open_index’ was not
 declared in this scope
 ../sql/mysqld.cc:3488: error: ‘make_master’ was not declared in this
 scope
 make[3]: *** [lib_sql.o] Error 1
 make[3]: *** Waiting for unfinished jobs
 mv -f .deps/derror.Tpo .deps/derror.Po
 mv -f .deps/field_conv.Tpo .deps/field_conv.Po
 mv -f .deps/field.Tpo .deps/field.Po
 make[3]: Leaving directory
 `/mnt/sda8/tmp/portage/dev-db/mysql-community-5.0.77/work/mysql/libmysqld'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory
 `/mnt/sda8/tmp/portage/dev-db/mysql-community-5.0.77/work/mysql/libmysqld'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory
 `/mnt/sda8/tmp/portage/dev-db/mysql-community-5.0.77/work/mysql'
 make: *** [all] Error 2


 I'm going to try attaching the git patch to the version bump bug
 (send-email won't handle it )

I've had success building dev-db/mysql-community-5.0.77 some days ago.  I 
commented on your version bump bug[1].  Can we please take this discussion 
there?  Thanks.

[1] http://bugs.gentoo.org/show_bug.cgi?id=260574

Gordon Malm (gengor)



[gentoo-dev] RSBAC-related packages removal notice

2008-12-29 Thread Gordon Malm
RSBAC has been without a maintainer for some time and Hardened is 
discontinuing support for RSBAC.  As such, the following packages are going 
into package.mask for eventual removal after January 31st, 2009.

sys-apps/rsbac-admin
sys-kernel/rsbac-sources

Gordon Malm (gengor)



Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db

2008-12-09 Thread Gordon Malm
Should be able to find which gcc was used by checking LDPATH in the 
environment.bz2.  I believe it is about the only gcc version information 
recorded in /var/db/pkg/category/package/ though.

Gordon Malm (gengor)

On Monday, December 8, 2008 16:44:16 Federico Ferri wrote:
 Hello,
 today I hit this annoyance, because my laptop hung in the middle of an
 'emerge -e @world' (checking that my world set compiles with
 gcc-4.3... stopped at ~ 300 of 700  :S )

 I was looking for an entry in /var/db/pkg/cat/pkg/ that could have
 told me the compiler used to build the package, but couldn't find any.
 indeed it would be a fairly useful feature to have, both for testing
 purposes, and for user's everyday maintenance.

 please criticize this with anything constructive you can think of.

 thanks





Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-03 Thread Gordon Malm
On Monday, November 3, 2008 02:22:12 Peter Volkov wrote:
 В Вск, 02/11/2008 в 12:11 -0700, Gordon Malm пишет:
  You can cry abuse all you want.  You FAIL to offer any alternatives or
  solutions.  I'll ask again, how do you detect that you are compiling code
  destined to be run in-kernel from within gcc without checking for the
  __KERNEL__ macro?  I think we both know the answer.

 Gordon, as far as I see our linux-mod.eclass builds each kernel module
 separately and it is possible to modify it to pass CFLAGS you wish for
 kernel modules only and as such avoid using __KERNEL__ macro for this...

Peter, with much respect, this doesn't really address the question.  Here is 
the relevant snippet of hardened's gcc specs:

%(cc1_cpu) %{profile:-p} %{!D__KERNEL__: %{!static: %{!fno-PIC: %{!fno-pic: 
%{!shared: %{!nostdlib: %{!nostartfiles: %{!fno-PIE: %{!fno-pie: %{!nopie: 
%{!fPIC:
%{!fpic:-fPIE}}} } } } } } } } }  %{!nostdlib: %{!fno-stack-protector: 
-fstack-protector %{!D_LIBC: %{!D_LIBC_REENTRANT: %{!fno-stack-protector-all: 
-fstack-protector-all} } } } } }

As you can see the __KERNEL__ macro is checked to decide which gcc specs to 
apply any time hardened's gcc compiles anything.  Patching linux-mod.eclass 
isn't going to do anything to break our reliance on the __KERNEL__ macro.

What patching linux-mod.eclass *would* allow us to do is not patch distcc to 
pass -D__KERNEL__ (which I have already done in the case of USE=hardened, 
so really this is solved).  The limitations of the linux-mod.eclass patching 
approach is that it wouldn't work for any modules that use a standalone build 
system (dumb as it that might be) instead of kbuild or any module being 
compiled outside of portage (kbuild or not).

The linux-mod.eclass hacking could get pretty ugly.  I haven't looked deeply 
into it but KBUILD_CFLAGS is not yet defined at the time emake is called that 
I can tell, so I don't think it will be as simple as adding something like 
KBUILD_CFLAGS=${KBUILD_CFLAGS} -fmy -fflags -fhere.  If I'm wrong please 
let me know, I'd be grateful. :)

There's potentially a lot of conditionals involved as well as far as what 
flags to add for a diversity of ARCHes, what the available out-of-tree 
modules want for themselves, etc.  Overall, linux-mod.eclass could start to 
look really nasty and I think it would take quite awhile (for me alone at 
least) to figure out a workable solution, if even possible.  When accounting 
that this would only address the problem for modules using Kbuild and built 
within portage - I don't think its worth it for a partial solution.

Patching KBUILD_CFLAGS in the kernel sources themselves works, but if we don't 
do that for every kernel portage we restrict users to using hardened-sources 
when running a hardened toolchain w/o the hardened kernel is a perfectly 
valid configuration.  They wouldn't be able to use a non-gentoo provided 
kernel without patching it as well.  Plus, we're just *not* going to have 
every kernel in the tree have a patch conditional on USE=hardened (ick :).

Best regards,
Gordon Malm (gengor)



[gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-01 Thread Gordon Malm
I'd like to get distcc added as one of the FEATURES we are able to RESTRICT.

It is true that RESTRICT=distcc is usually not the proper solution to 
problems.  But in the case of out-of-tree kernel modules the idea of 
distributing compile jobs to other machines is fundamentally flawed IMO.  
Additionally, there are a few packages in the tree already that will never 
get fixed (or be fixable) and just have some check for FEATURES=distcc  
die disable distcc type stuff.

Thanks,
Gordon Malm (gengor)



Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-01 Thread Gordon Malm
If you're compiling an out-of-tree module that requires the kernel be compiled 
with support for a particular item and the distccd host's kernel does not 
have that support compiles fail.  Reference bug #120001 (though I know that 
it was properly diagnosed there).

Then there's also this doozie. - #167844.

Thanks,
Gordon Malm (gengor)

On Saturday, November 1, 2008 14:00:17 Ciaran McCreesh wrote:
 On Sat, 1 Nov 2008 13:57:17 -0700

 Gordon Malm [EMAIL PROTECTED] wrote:
  But in the case of out-of-tree kernel modules the idea
  of distributing compile jobs to other machines is fundamentally
  flawed IMO.

 Why? And how are out of tree kernel modules in any way special when it
 comes to distcc?



Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-01 Thread Gordon Malm
On Saturday, November 1, 2008 14:28:06 Ciaran McCreesh wrote:
 On Sat, 1 Nov 2008 14:21:43 -0700

 Gordon Malm [EMAIL PROTECTED] wrote:
  If you're compiling an out-of-tree module that requires the kernel be
  compiled with support for a particular item and the distccd host's
  kernel does not have that support compiles fail.  Reference bug
  #120001 (though I know that it was properly diagnosed there).
 
  Then there's also this doozie. - #167844.

 So far as I can see, when the correct options are passed to a build
 system, the only issue is hardened being broken. There doesn't seem to
 be any fundamental reason why distcc with a sane compiler can't be used
 with kernel modules. If this is the case, wouldn't it be better to get
 the hardened compiler fixed?

I use madwifi-ng extensively and have experienced the same issue with 
madwifi-ng as stated in that bug.  For bug #167844, please read comment #13 
and http://code.google.com/p/distcc/issues/detail?id=25.  There's nothing to 
fix, hardened is doing the right thing as is distcc.  The proper approach is 
to not distribute compiles of kernel modules.

To not get too stuck on a single scenario, I think this would be a useful 
feature and desireable vs. the alternative of FEATURES=${FEATURES/distcc/}.

This is not the first time its been requested, a simple search reveals bugs 
#28300, #80894.

A quick grep shows these packages at minimum have to do some FEATURES checking 
and either pass a config option (if provided) or die disable distcc and try 
again.
dev-python/pyqwt
media-gfx/sam2p
media-tv/mythtv
media-video/avidemux

Gordon Malm (gengor)



Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-01 Thread Gordon Malm
On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote:
 On Sat, 1 Nov 2008 14:58:39 -0700

 Gordon Malm [EMAIL PROTECTED] wrote:
  I use madwifi-ng extensively and have experienced the same issue with
  madwifi-ng as stated in that bug.  For bug #167844, please read
  comment #13 and http://code.google.com/p/distcc/issues/detail?id=25.
  There's nothing to fix, hardened is doing the right thing as is
  distcc.  The proper approach is to not distribute compiles of kernel
  modules.

 It looks to me like hardened is doing entirely the wrong thing. Thus,
 the proper fix is to make hardened behave itself.

It looks to me like you've already made up your mind.  How is hardened doing 
the entirely wrong thing?  What do you propose can be done to fix the 
hardened compiler?  What about madwifi-ng?  You are getting increasingly 
narrow in your points of objection.


  To not get too stuck on a single scenario, I think this would be a
  useful feature and desireable vs. the alternative of
  FEATURES=${FEATURES/distcc/}.
 
  This is not the first time its been requested, a simple search
  reveals bugs #28300, #80894.

 It looks a lot like people are blaming distcc for parallelisation bugs
 that aren't distcc related but that happen to be easier to reproduce
 when distcc is enabled. Do you have any examples of problems that are
 definitely caused by distcc, rather than general parallelisation bugs
 or user misconfigurations? RESTRICTing distcc doesn't seem to be an
 actual fix for anything...

As I said in my first post:

'It is true that RESTRICT=distcc is usually not the proper solution to 
problems.'

Parallel building problems can often and should be addressed properly.  I 
don't want the answer to every one that comes along to be to add 
RESTRICT=distcc.  This is something to be addressed through developer 
documentation that using RESTRICT=distcc should be a last resort.

However, in practice making a package parallel-make safe isn't always trivial.  
So what happens in these cases is FEATURES=distcc  die check is put in 
place killing the emerge chain and requiring user intervention.  Either that 
or the bug just lingers and the compile fails somewhere in the middle...

I don't know about palaudis but this is like a one line patch to portage.  But 
silly me, I thought the package manager was there to support the 
distribution.

Gordon Malm (gengor)



Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-01 Thread Gordon Malm
On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote:
  Parallel building problems can often and should be addressed
  properly.  I don't want the answer to every one that comes along to
  be to add RESTRICT=distcc.  This is something to be addressed
  through developer documentation that using RESTRICT=distcc should
  be a last resort.

 Uh, RESTRICT=distcc won't even fix parallel make problems. It'll just
 make them harder to reproduce on some systems.

Why don't you post the whole context?  Here, I'll do it for you:

On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote:
  It looks a lot like people are blaming distcc for parallelisation bugs
  that aren't distcc related but that happen to be easier to reproduce
  when distcc is enabled. Do you have any examples of problems that are
  definitely caused by distcc, rather than general parallelisation bugs
  or user misconfigurations? RESTRICTing distcc doesn't seem to be an
  actual fix for anything...

And my full response...
 As I said in my first post:
 
 'It is true that RESTRICT=distcc is usually not the proper solution to 
 problems.'
 
 Parallel building problems can often and should be addressed properly.  I 
 don't want the answer to every one that comes along to be to add 
 RESTRICT=distcc.  This is something to be addressed through developer 
 documentation that using RESTRICT=distcc should be a last resort.

You're the one assuming the only purpose would be to mask parallel make 
problems.  Apparently it does have a purpose though since avidemux builds 
fine in parallel but NOT via distcc.


Back to your most recent post
  *If* there's a legitimate use for RESTRICT=distcc then I am entirely in
 favour of it. But it looks like there isn't, with every issue being
 either a parallelism issue (which RESTRICT=distcc won't fix), a user
 configuration issue (which RESTRICT=distcc won't fix) or a hardened
 toolchain bug (for which RESTRICT=distcc is massive overkill, and thus
 the wrong solution). You've decided upon a solution before you've
 worked out what the problem is.

You assumed it is a parallelism issue that people are trying to solve.  I 
haven't pointed to any user configuration issues.  Using RESTRICT=distcc on 
kernel modules is hardly overkill.  This isn't openoffice.  I know exactly 
what the problem is, but since you have such a better grasp on it

On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote:
 On Sat, 1 Nov 2008 15:47:09 -0700

 Gordon Malm [EMAIL PROTECTED] wrote:
   It looks to me like hardened is doing entirely the wrong thing.
   Thus, the proper fix is to make hardened behave itself.
 
  It looks to me like you've already made up your mind.  How is
  hardened doing the entirely wrong thing?  What do you propose can be
  done to fix the hardened compiler?  What about madwifi-ng?  You are
  getting increasingly narrow in your points of objection.

 I suggest you get the hardened upstream people to stop abusing the -D
 switch to gcc. The distcc people suggest the same.

On Saturday, November 1, 2008 16:28:17 Jan Kundrát wrote:
 Gordon Malm wrote:
  It looks to me like you've already made up your mind.  How is hardened
  doing the entirely wrong thing?

  From the page [1] you mentioned:

 If so, that seems to me like an abuse of the -D option.

 The abuse is in changing the compiler behavior based on -D options.

  What do you propose can be done to fix the
  hardened compiler?

  From the same page:

 It would be better for you to remove the patch from gcc where it makes
 -D__KERNEL__ imply -nossp -nopie, and to instead patch the Linux kernel
 build system (Makefiles, etc.) so that it passes -D__KERNEL__ -nossp
 -nopie rather than -D__KERNEL__.


We have to build using different specs sets for kernel code than userland.  If 
we can't depend on the __KERNEL__ macro for detection, how else do you 
propose one detect if gcc is building kernel code or not?

Patching an out-of-tree module's build system to pass -fno-PIE works on x86, I 
don't know how this will affect other ARCHes, do either of you?  This could 
potentially get really tricky.  If it can't be done nicely in the eclass for 
every possible kernel release and out-of-tree module, then we get into 
patching *everything* and having to maintain it forward.  So this is just a 
different workaround, a rather heavy-handed and high-maintenance one at that.  
What makes it any better than a simple option to RESTRICT distcc?

I guess the larger question in all this is why does a third party who has 
demonstrated his anti-Hardened (and anti-Gentoo) slant on multiple occasions 
define what goes in our PMS?

Gordon Malm (gengor)