date:20121217

On 17 December 2012 00:10, Michael Orlitzky mich...@orlitzky.com wrote:
On 12/16/12 14:04, Markos Chandras wrote:
On 16 December 2012 16:57, Michael Orlitzky mich...@orlitzky.com wrote:
Inspired by the number of packages being unmaintained -- why not use
some of that bug bounty money to fix up the recruitment documentation

Recruitment documentatiob? What does that mean?

People still think of Gentoo as a ricer distro that's broken all
the time, when in reality, it's one of the most stable.

Well that's not entirely true but that's a different issue

The first part is definitely true. The stable part is also true in my
experience, all things considered. For an example, take the last what's
your favorite distro post on Reddit (not exactly a representative
sample, I know):

http://www.reddit.com/r/linux/comments/14tpnt/of_all_the_distros_youve_ever_used_what_do_you/

Top rated comment:

Tie between Arch and Gentoo. These are my messing around distros.
Fun to install and tweak on older machines, but I don't know enough
about them to use them full time. Plus, Gentoo breaks. A lot. Arch
breaks much more often than Debian for me but much less than Gentoo.

Further down:

Gentoo is not stable. Stop saying that.

My experience mirrors Michael Mol's. Perception is bad. Reality not so much.

I don't care much about what a website may say or not. Truth is Gentoo
is a rolling release so you can't expect much when it comes to
stability. But we are trying our best though

Note quite. The activity of a distro is measure but the # of devs,
packages in tree, activity on bugzilla and mailing lists etc. The
design of a website does not
really say much. Many foss projects still have static html pages. This
does not mean they are dead.

The actual activity, yes. The perceived activity... eh. And that's what
gets you new users and developers.

The perceived activity is certainly not measured by the website. The
numbers of fixed bugs, version bumps etc is a good indication to
measure the activity of such projects. Honestly, I rarely visit the
website of the projects I use. I only read the RSS just to see if
something new is happening.

Parts of this docs are outdated but this does not matter. Get
involved, fix bugs, help people and someone will ask you to join. Or
look for a mentor.

If your recruitment process is fix bugs for years and maybe someone
will notice you, maybe not, then nobody is going to bother. There needs
to be a clear, step-by-step process. This guy posted a graph the other day:

http://hwoarang.silverarrow.org/wp-content/uploads/recruitment_stats.png

People aren't bothering. It's not because of any fundamental problem --
it's because the process is obscure and potentially a waste of time.

I posted that. The reason they don't bother is because the actual
*recruitment* process sucks and takes too much time. The contributors
are there, we have many of them, just getting them on board requires
time that many of them don't have. It is one of the reasons we formed
the proxy-maintainers project.

3. Get off CVS for Christ's sake. Nobody wants to work with that. I
don't know how this fits into my bullet list, but it's important.

I believe this is Irrelevant

It's the least important of the three probably. The (lack of)
recruitment process is the biggest problem.

Again, there is no lack of recruitment process. It just takes time.
Ask all these people who joined the project in the last year.

I don't like the attitude pay in order to happen. This is a foss
project, so people are supposed to
see this as a hobby or a learning experience. It is not a job ;)
Things are supposed to happen because they are fun

You would be perfect for training new developers. Feel free to decline
your salary =)

I already do that ;)

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2012-12-17 Thread Michał Górny

On Sun, 16 Dec 2012 19:10:06 -0500
Michael Orlitzky mich...@orlitzky.com wrote:

  Parts of this docs are outdated but this does not matter. Get
  involved, fix bugs, help people and someone will ask you to join. Or
  look for a mentor.
 
 If your recruitment process is fix bugs for years and maybe someone
 will notice you, maybe not, then nobody is going to bother. There needs
 to be a clear, step-by-step process. This guy posted a graph the other day:
 
 http://hwoarang.silverarrow.org/wp-content/uploads/recruitment_stats.png

I don't think a single graph is 'good enough' for the complexity
of the problem. I probably do count to the 'gave up' no in the earlier
years, yet I finally made it the other year. I wonder how many others
like me are there.

 People aren't bothering. It's not because of any fundamental problem --
 it's because the process is obscure and potentially a waste of time.

I agree with that. The process takes a lot of time for a minor benefit,
and most of it doesn't prove really helpful. I think the process should
mostly prove that someone is able to find and read docs, write ebuilds
and understand the major concepts.

Honestly, I see no reason to ask recruits for a lot of things we do
right now. There's no point in telling them to summarize a large piece
of the docs. From my personal experience, there is a lot of things which
you learn and then forget because you don't need them for a long time.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On 16 December 2012 19:14, Michael Mol mike...@gmail.com wrote:

  People still think of Gentoo as a ricer distro that's broken all
  the time, when in reality, it's one of the most stable.

 Well that's not entirely true but that's a different issue

 What's not really true? That it's the most stable? or that people
 think of it as a ricer distro?


It is definitely not the most stable. You can't even compare a rolling
release distro with other distros when it comes to stability. It is
just not possible. In order to have something stable, first you need
to test a well-defined set of packages, then declare them (tag them)
as stable, then have a dedicated team, tracking this tree, and fix
potential bugs that may pop up. People may complain that Debian stable
and Centos have ancient packages, but this is expected and it is a
compromise between cutting-edge distro vs stability.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

[gentoo-dev] Defaulting for debug information in profiles

Hi lads,
lately I am having bit of problems from getting relevant debug info from users.

Since we already have splitdebug for quite time (and I suppose quite
few of us are using it) how about making it to default profiles
default enabled and add -g to default cflags. Currently it is only
enabled in the developer profile.

This results in 2 gb data in /usr/lib/debug for my system which is not
that bad with current disk sizes and it saves users quite some time
when i have to request them to recompile half of their system with
debug info just to get idea how to fix their issue.

I would go even for compressdebug feature but that one needs more time
as some packages like glibc fails to merge with it and you need newer
gdb to work with it.

Cheers

Tom

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17/12/2012 11:11, Tomáš Chvátal wrote:
 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.

Why, somebody uses default cflags?

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Moving our/portage stuff to var

Currently we put portage into /usr/portage and all related stuff is to
be in the subfolders there (distfiles, binpkg).

I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough how to
make world and config files to be put elsewhere :P).

The only reason why we have this currently in usr is that bsd ports
put their stuff in there and I suppose Daniel just did the same.

With respect to reality how stuff is done in the linux land all the
variable data should be in /var so we should adjust and move it in
there too.

What would  you think?

Cheers

Tom

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 11:19, Tomáš Chvátal wrote:
 
 I've always myself override these defaults in make.conf to point for
 /var/portage/ (not /var/lib because I never bothered enough how to
 make world and config files to be put elsewhere :P).

I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Defaulting for debug information in profiles

2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu:
 On 17/12/2012 11:11, Tomáš Chvátal wrote:
 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.

 Why, somebody uses default cflags?

I silently hope they copy the default cflags to their make.conf and
then set march and add more stuff, rather than starting from scratch.
Also we can pop-up newsitem asking them to put it into cflags ;-)

Re: [gentoo-dev] Moving our/portage stuff to var

2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu:
 On 17/12/2012 11:19, Tomáš Chvátal wrote:

 I've always myself override these defaults in make.conf to point for
 /var/portage/ (not /var/lib because I never bothered enough how to
 make world and config files to be put elsewhere :P).

 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

Thats right, it should be even better location. :-)

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Michał Górny

On Mon, 17 Dec 2012 11:23:00 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:

 On 17/12/2012 11:19, Tomáš Chvátal wrote:
  
  I've always myself override these defaults in make.conf to point for
  /var/portage/ (not /var/lib because I never bothered enough how to
  make world and config files to be put elsewhere :P).
 
 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

+1 on /var/cache.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Sven Eden

Am Montag, 17. Dezember 2012, 11:11:38 schrieb Tomáš Chvátal:
 Hi lads,
 lately I am having bit of problems from getting relevant debug info from
 users.

 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.

 This results in 2 gb data in /usr/lib/debug for my system which is not
 (snip)

Hello Tomáš,

on my system I have set up everything with splitdebug enabled. My CFLAGS use -
march=native, -O2 and -ggdb.
And this is the result: (Yes, I have a dedictated partition for that.)

 ~ $ LC_ALL=C df -h /usr/lib/debug/.
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda10   25G   22G  1.7G  93% /usr/lib64/debug

This is a full KDE-4.9.4 system with a total
of 1,807 packages installed.

I guess the regular user would end up somewhere between your 2G and my 22G.
But I bet it will be slightly more likely my end, wouldn't it?


Sincerly

Sven

--
http://pwxlib.sourceforge.net

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Ben de Groot

On 17 December 2012 18:26, Tomáš Chvátal tomas.chva...@gmail.com wrote:

 2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu:
  On 17/12/2012 11:11, Tomáš Chvátal wrote:
  Since we already have splitdebug for quite time (and I suppose quite
  few of us are using it) how about making it to default profiles
  default enabled and add -g to default cflags. Currently it is only
  enabled in the developer profile.
 
  Why, somebody uses default cflags?
 
 I silently hope they copy the default cflags to their make.conf and
 then set march and add more stuff, rather than starting from scratch.
 Also we can pop-up newsitem asking them to put it into cflags ;-)


Please don't. For most users this is a waste of resources.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Ben de Groot

On 17 December 2012 18:27, Tomáš Chvátal tomas.chva...@gmail.com wrote:

 2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu:
  On 17/12/2012 11:19, Tomáš Chvátal wrote:
 
  I've always myself override these defaults in make.conf to point for
  /var/portage/ (not /var/lib because I never bothered enough how to
  make world and config files to be put elsewhere :P).
 
  I would say let's work on that so that portage can keep them there.
  Although I'm more for /var/cache/portage myself, as both distfiles and
  tree can be re-generated.
 
 Thats right, it should be even better location. :-)


I prefer some location in /var/ as well.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread Olav Vitters

On Sat, Dec 15, 2012 at 03:17:05PM -0500, Richard Yao wrote:
 On 12/15/2012 02:33 PM, Michał Górny wrote:
  On Sat, 15 Dec 2012 13:58:43 -0500
  Walter Dnes waltd...@waltdnes.org wrote:
  On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
  Waaait, what? Did something change lately or are you just repeating
  the same bullshit for months?
 
Older systemd boots OK with a separate /usr and eudev.  But somehow,
  somewhere along the line, as part of the merge, the udev portion of the
  systemd tarball requires initramfs.  See news item...
  http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
  It was actually finally released 2012-03-16.  If you disagree with that
  news item, complain directly to its author.  If you can boot a udev-181
  or higher system with a separate /usr, and no intrd/initramfs, I'm sure
  a lot of people would be very interested in knowing how.
  
  This was a Gentoo decision, not an upstream one.
 
 If I recall, WilliamH stated at the time that he believed that upstream
 would make avoiding it increasingly difficult. My impression was that he
 felt coerced into making that change.

So systemd still works with a separate /usr and you're continuing to
spread misinformation. Demonstrating such behaviour while complaining
about the behaviour of upstream is IMO very ironic.
-- 
Regards,
Olav

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17/12/2012 11:33, Sven Eden wrote:
 on my system I have set up everything with splitdebug enabled. My CFLAGS use -
 march=native, -O2 and -ggdb.

That's  -ggdb that increases the size.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On 16 December 2012 18:53, Andreas K. Huettel dilfri...@gentoo.org wrote:
   1. Even MediaWiki (wiki.gentoo.org) looks better than www.gentoo.org.
  That's impressive-bad.

  People still think of Gentoo as a ricer distro that's broken all
  the time, when in reality, it's one of the most stable. No one
  would suspect that anything has changed, though, since the
  homepage hasn't since before I could drink beer.

  It makes the entire distro look unmaintained.

 Yeah. Stable. Hehe...

 The problem with the entire webpage is that is coded in an extremely obscure
 way. It is probably easier to 100% replace it from scratch than to modify and
 improve it. Yes, I've tried to analyze once how e.g. the table of blog posts
 or the GLSA announcements on the main page come together.

 My personal suggestion would be to code an internal replacement and
 transparently port more and more pages to it (as a change mostly invisible
 from outside, with two content management systems running concurrently for a
 transition period). Once the transition is complete, improvements can be made
 in a more sweeping way.

 How to do this, however, and what software to target should probably be
 decided by people who know more than me... and in the end it all boils down to
 who has the time and motivation.

Outsource it to someone who has the knowledge and interest in doing
this. The foundation has the funds to support it, and none of us
actually have the time to invest in a complete webpage redesign.



   2. Nowhere is it actually spelled out how to become a developer.
  Let's google how to become a gentoo developer. This takes me
  to...

  http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2

  which as far as I know, is complete bullshit. I should look for an
  opening in the monthly newsletter? Really? Or in #gentoo-bugs?

 That page BADLY needs an update. It should however probably also reflect
 reality in the sense that you cannot really apply to become a developer.
 What you can do is help out, be useful, get noticed, and be offered the job.
 (That at least is my personal impression on how it works.)

Different devs got involved it totally different ways. But yes, you
need to get involved in a team to get noticed and understand how
things work. That a fairly good start. The fact that there are
hundreds of different ways to reach a point where a recruiter picks
you for interview makes it hard to document it.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17/12/2012 11:26, Tomáš Chvátal wrote:
 I silently hope they copy the default cflags to their make.conf and
 then set march and add more stuff, rather than starting from scratch.
 Also we can pop-up newsitem asking them to put it into cflags ;-)
 

They don't, they use those coming from cataylist.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Alexandre Rostovtsev

On Mon, 2012-12-17 at 11:11 +0100, Tomáš Chvátal wrote:
 Hi lads,
 lately I am having bit of problems from getting relevant debug info from 
 users.
 
 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.
 
 This results in 2 gb data in /usr/lib/debug for my system which is not
 that bad with current disk sizes and it saves users quite some time
 when i have to request them to recompile half of their system with
 debug info just to get idea how to fix their issue.
 
 I would go even for compressdebug feature but that one needs more time
 as some packages like glibc fails to merge with it and you need newer
 gdb to work with it.
 
 Cheers
 
 Tom

The bigger problem is not disk space but memory usage at link time. Try
building something like *-webkit-* or firefox with debugging CFLAGS on a
machine with limited memory.

Re: [gentoo-dev] Defaulting for debug information in profiles

2012/12/17 Sven Eden sven.e...@gmx.de:
 Hello Tomáš,

 on my system I have set up everything with splitdebug enabled. My CFLAGS use -
 march=native, -O2 and -ggdb.
 And this is the result: (Yes, I have a dedictated partition for that.)

  ~ $ LC_ALL=C df -h /usr/lib/debug/.
 Filesystem  Size  Used Avail Use% Mounted on
 /dev/sda10   25G   22G  1.7G  93% /usr/lib64/debug

 This is a full KDE-4.9.4 system with a total
 of 1,807 packages installed.

 I guess the regular user would end up somewhere between your 2G and my 22G.
 But I bet it will be slightly more likely my end, wouldn't it?


Well your problem is using -ggdb, that adds ton of stuff that makes
things large exponencialy in most cases, i bet you would be around 5-6
on -g usage.

Cheers

Tom

Re: [gentoo-dev] Defaulting for debug information in profiles

2012/12/17 Alexandre Rostovtsev tetrom...@gentoo.org:

 The bigger problem is not disk space but memory usage at link time. Try
 building something like *-webkit-* or firefox with debugging CFLAGS on a
 machine with limited memory.


That ain't problem, we acutally can patch in those packages to strip
the debug by default and add there useflag to not strip those for
those really needing it.

Also the culprit is again -ggdb rather than -g.

Re: [gentoo-dev] Defaulting for debug information in profiles

2012/12/17 Ben de Groot yng...@gentoo.org:
 Please don't. For most users this is a waste of resources.

On first look it seems like waste of resources.
On second hand it makes stuff easy wrt bugreports provided by users.
And believe me when I say most upstreams are pissed by gentoo reports
because they lack any good debuginfo features, nor they know how to
tell users how to make their systems contain debug informations. I
have seen quite few upstreams rejecting all  by Gentoo reported issues
because of this, plus they were quite suprised that I actually can
generate any sane debug informations with it.

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17/12/2012 11:54, Tomáš Chvátal wrote:
 That ain't problem, we acutally can patch in those packages to strip
 the debug by default and add there useflag to not strip those for
 those really needing it.

No. USE=debug is for _something else_ entirely. And I'm going to kick
hard whoever tries to make USE=debug provide debug information rather
than debug codepaths.

 Also the culprit is again -ggdb rather than -g.

Which makes now interesting for somebody to test what webkit-gtk
requires, memory-wise, with just -g rather than -ggdb.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread justin

On 17/12/12 11:23, Diego Elio Pettenò wrote:
 On 17/12/2012 11:19, Tomáš Chvátal wrote:

 I've always myself override these defaults in make.conf to point for
 /var/portage/ (not /var/lib because I never bothered enough how to
 make world and config files to be put elsewhere :P).
 
 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.
 

fetch-restricted files are to be considered critical here. Do we want to
force the user to keep them twice? So an additional location which is
not a cache?
Of course PORTAGE_RO_DISTDIRS and friends are nice here, but they are
not part of a default setup.

justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Moving our/portage stuff to var


On 12/17/12 11:30 AM, Michał Górny wrote:

On Mon, 17 Dec 2012 11:23:00 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:


On 17/12/2012 11:19, Tomáš Chvátal wrote:


I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough how to
make world and config files to be put elsewhere :P).


I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.


+1 on /var/cache.


Agreed.

Bonus points if we consider suggesting to move it on a dedicated file 
system ^^;


lu

Re: [gentoo-dev] Re: eudev project announcement


On 12/17/12 11:40 AM, Olav Vitters wrote:

So systemd still works with a separate /usr and you're continuing to
spread misinformation. Demonstrating such behaviour while complaining
about the behaviour of upstream is IMO very ironic.


No it does not, try by yourself please ^^

(or just issue and ldd over the main binaries)

lu

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 12:06, justin wrote:
 fetch-restricted files are to be considered critical here. Do we want to
 force the user to keep them twice? So an additional location which is
 not a cache?
 Of course PORTAGE_RO_DISTDIRS and friends are nice here, but they are
 not part of a default setup.

I would still think they are cache. I can re-download Oracle's JRE
binaries; Portage's copy is a cache because I don't need to back it up.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread viv...@gmail.com


Il 17/12/2012 11:42, Diego Elio Pettenò ha scritto:

On 17/12/2012 11:33, Sven Eden wrote:

on my system I have set up everything with splitdebug enabled. My CFLAGS use -
march=native, -O2 and -ggdb.

That's  -ggdb that increases the size.



In short FEATURES=compressdebug should be stable and default before you 
(gentoo) decide for something like this.
As mentioned somewhere else in this thread some packages are on the 
unbeareable side when compiled with debug information, those should 
default to filter out debug flags if not actually wanted by the user 
USE=gdb maybe?
When going with debug information the best available should be used so 
-ggdb not -g if possible.
Please try to understand the differences between the  various options 
(nodebug, -g, -ggdb) versus (time to build, memory needed, disk space) 
before attempting this.

Diego maybe it's worth some runs in the tinderbox.

Some numbers:

Packages installed:   1756
Packages in world:626
Packages in system:   42
Required packages:1756
Number to remove: 0


ECFLAGSbase='-O2 -march=corei7-avx -pipe -frecord-gcc-switches'
ECFLAGSnative='-mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop 
-mno-bmi -mno-tbm --param=l1-cache-size=32 --param=l1-cache-line-size=64 
--param=l2-cache-size=6144 -mtune=corei7-avx'
ECFLAGSnative=${ECFLAGSnative} -mno-bmi2 -mno-avx2 -mno-lzcnt -mrdrnd 
--param=l1-cache-size=32
ECFLAGSo3='-fgcse-after-reload -fpredictive-commoning -ftree-vectorize 
-funswitch-loops' # O3 - -finline-functions -fipa-cp-clone
ECFLAGSgraphite='-fgraphite-identity -floop-block -floop-interchange 
-floop-strip-mine' # graphite  co (-fira-loop-pressure no good amd64)


ECFLAGSdbug='-ggdb -gdwarf-4 -fvar-tracking-assignments'

ECFLAGSlto=''
CFLAGS=${ECFLAGSbase} ${ECFLAGSnative} ${ECFLAGSo3} ${ECFLAGSgraphite} 
${ECFLAGSlto} ${ECFLAGSdbug}

CXXFLAGS=${CFLAGS} -fvisibility-inlines-hidden
ELDFLAGSoptimize='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-Wl,--sort-common -Wl,--no-copy-dt-needed-entries'


ELDFLAGSdebug='-Wl,--build-id'

ELDFLAGSlto=''
LDFLAGS=${LDFLAGS} ${ELDFLAGSoptimize} ${ELDFLAGSdebug}


FEATURES=${FEATURES} splitdebug installsources compressdebug

du -csh /usr/lib/debug/ /usr/src/debug/
5,5G/usr/lib/debug/
3,9G/usr/src/debug/
9,4Gtotale

find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec 
echo  {} +
/usr/armv7a-hardfloat-linux-gnueabi /usr/bin /usr/brlcad /usr/data 
/usr/etc /usr/fakelib /usr/gnu-classpath-0.98 /usr/include /usr/lib32 
/usr/lib64 /usr/libexec /usr/local /usr/man /usr/Mod /usr/sbin 
/usr/share /usr/x86_64-pc-linux-gnueabi


find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec 
du -csh {} +

38M /usr/armv7a-hardfloat-linux-gnueabi
825M/usr/bin
86M /usr/brlcad
1,3M/usr/data
16K /usr/etc
8,0K/usr/fakelib
12M /usr/gnu-classpath-0.98
425M/usr/include
392M/usr/lib32
11G /usr/lib64  == 5,5G/usr/lib/debug/
415M/usr/libexec
28K /usr/local
304K/usr/man
18M /usr/Mod
81M /usr/sbin
3,3G/usr/share
27M /usr/x86_64-pc-linux-gnu
17G totale

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17/12/2012 12:37, viv...@gmail.com wrote:
 
 In short FEATURES=compressdebug should be stable and default before you
 (gentoo) decide for something like this.
 As mentioned somewhere else in this thread some packages are on the
 unbeareable side when compiled with debug information, those should
 default to filter out debug flags if not actually wanted by the user
 USE=gdb maybe?
 When going with debug information the best available should be used so
 -ggdb not -g if possible.
 Please try to understand the differences between the  various options
 (nodebug, -g, -ggdb) versus (time to build, memory needed, disk space)
 before attempting this.
 Diego maybe it's worth some runs in the tinderbox.

Again, I'm against using USE flags to handle debug information, it's
already hard enough as it is without adding extra complexity.

I'd be more for _suggesting_ the use of -g but leaving it to the user.
And yes I also agree that -ggdb makes more sense.

I'll write something about it later on I guess.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Moving our/portage stuff to var

On Mon, Dec 17, 2012 at 11:23 AM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

+1.

Cheers,

Dirkjan

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On 17 December 2012 09:40, Michał Górny mgo...@gentoo.org wrote:
 On Sun, 16 Dec 2012 19:10:06 -0500
 Michael Orlitzky mich...@orlitzky.com wrote:

  Parts of this docs are outdated but this does not matter. Get
  involved, fix bugs, help people and someone will ask you to join. Or
  look for a mentor.

 If your recruitment process is fix bugs for years and maybe someone
 will notice you, maybe not, then nobody is going to bother. There needs
 to be a clear, step-by-step process. This guy posted a graph the other day:

 http://hwoarang.silverarrow.org/wp-content/uploads/recruitment_stats.png

 I don't think a single graph is 'good enough' for the complexity
 of the problem. I probably do count to the 'gave up' no in the earlier
 years, yet I finally made it the other year. I wonder how many others
 like me are there.

 People aren't bothering. It's not because of any fundamental problem --
 it's because the process is obscure and potentially a waste of time.

 I agree with that. The process takes a lot of time for a minor benefit,
 and most of it doesn't prove really helpful. I think the process should
 mostly prove that someone is able to find and read docs, write ebuilds
 and understand the major concepts.

 Honestly, I see no reason to ask recruits for a lot of things we do
 right now. There's no point in telling them to summarize a large piece
 of the docs. From my personal experience, there is a lot of things which
 you learn and then forget because you don't need them for a long time.

 --
 Best regards,
 Michał Górny

Somehow you need to make sure they actually read part of the docs and
they will not commit random bits just because they though this was
the correct way to do it. We are all people, and sometimes it's
easier to assume something is right than actually investigating
whether your assumption was right or not. And frankly, many mentors
nowadays don't pay much attention in training their recruits. They
just do a very limited quiz review and hand them to recruiters. I have
interviewed a few people where they did not know basic stuff, like
local use flags go to metadata.xml and not local.use.desc anymore etc
and that's because their mentors did a very very bad job in preparing
them. Be a responsible mentor, train them well, and the recruitment
will be much faster than you might expect.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Defaulting for debug information in profiles

On Mon, Dec 17, 2012 at 11:26 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote:
 I silently hope they copy the default cflags to their make.conf and
 then set march and add more stuff, rather than starting from scratch.
 Also we can pop-up newsitem asking them to put it into cflags ;-)

You might want to get the handbook to recommend that for new installs?

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1chap=5#doc_chap3

Cheers,

Dirkjan

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17 December 2012 10:11, Tomáš Chvátal tomas.chva...@gmail.com wrote:
 Hi lads,
 lately I am having bit of problems from getting relevant debug info from 
 users.

 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.

 This results in 2 gb data in /usr/lib/debug for my system which is not
 that bad with current disk sizes and it saves users quite some time
 when i have to request them to recompile half of their system with
 debug info just to get idea how to fix their issue.

 I would go even for compressdebug feature but that one needs more time
 as some packages like glibc fails to merge with it and you need newer
 gdb to work with it.

 Cheers

 Tom


Sounds like a reasonable request to me although most people will have
their own cflags in make.conf.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Derek Dai

+1 /var/cache

Derek Dai



On Mon, Dec 17, 2012 at 6:30 PM, Michał Górny mgo...@gentoo.org wrote:

 On Mon, 17 Dec 2012 11:23:00 +0100
 Diego Elio Pettenò flamee...@flameeyes.eu wrote:

  On 17/12/2012 11:19, Tomáš Chvátal wrote:
  
   I've always myself override these defaults in make.conf to point for
   /var/portage/ (not /var/lib because I never bothered enough how to
   make world and config files to be put elsewhere :P).
 
  I would say let's work on that so that portage can keep them there.
  Although I'm more for /var/cache/portage myself, as both distfiles and
  tree can be re-generated.

 +1 on /var/cache.

 --
 Best regards,
 Michał Górny

Re: [gentoo-dev] Moving our/portage stuff to var

On 17 December 2012 10:30, Michał Górny mgo...@gentoo.org wrote:
 On Mon, 17 Dec 2012 11:23:00 +0100
 Diego Elio Pettenò flamee...@flameeyes.eu wrote:

 On 17/12/2012 11:19, Tomáš Chvátal wrote:
 
  I've always myself override these defaults in make.conf to point for
  /var/portage/ (not /var/lib because I never bothered enough how to
  make world and config files to be put elsewhere :P).

 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

 +1 on /var/cache.

 --
 Best regards,
 Michał Górny

+1 sounds good to me.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On Mon, Dec 17, 2012 at 11:43 AM, Markos Chandras hwoar...@gentoo.org wrote:
 Outsource it to someone who has the knowledge and interest in doing
 this. The foundation has the funds to support it, and none of us
 actually have the time to invest in a complete webpage redesign.

If we have funds for this kind of thing, the PSF process is a good example:

http://pythonorg-redesign.readthedocs.org/en/latest/

(And I think that would be a great idea.)

Cheers,

Dirkjan

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread George Shapovalov

On Monday 17 December 2012 11:19:20 Tomáš Chvátal wrote:
 I've always myself override these defaults in make.conf to point for
 /var/portage/ (not /var/lib because I never bothered enough how to
 make world and config files to be put elsewhere :P).
Finally!
And, while we are at it, lets more distfiles out of portage. That is the only 
(prominent) dir inside that has drastically different storage requirements. 
Having portage on a separate partition requires now changing defaults, bind 
mounts or symlinks. It is better to have it done right from the onset then to 
workaround every time.

Oh, and +1 on /var/cache/portage for the location.

George

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Sven Eden

Am Montag, 17. Dezember 2012, 11:47:24 schrieb Tomáš Chvátal:
 2012/12/17 Sven Eden sven.e...@gmx.de:
  Hello Tomáš,
 
  on my system I have set up everything with splitdebug enabled. My CFLAGS
  use - march=native, -O2 and -ggdb.
  And this is the result: (Yes, I have a dedictated partition for that.)
 
   ~ $ LC_ALL=C df -h /usr/lib/debug/.
 
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda10   25G   22G  1.7G  93% /usr/lib64/debug
 
  This is a full KDE-4.9.4 system with a total
  of 1,807 packages installed.
 
  I guess the regular user would end up somewhere between your 2G and my
  22G.
  But I bet it will be slightly more likely my end, wouldn't it?

 Well your problem is using -ggdb, that adds ton of stuff that makes
 things large exponencialy in most cases, i bet you would be around 5-6
 on -g usage.

First, I do not want to argue. I just want to state, and prove for at least
_my_ machine, that this is not true.

Second, my whole system is compiled using gcc-4.7.2. This means, that the
results below might differ greatly from a setting where stable gcc-4.5.4 is
used for the whole. But this doesn't matter, because gcc-4.7.* will,
eventually, become the stable and current gcc. (Unless it is skipped, of
course.)

Third, _My_ Machine means: My setting, hardware, USE-Flags and CFLAGS.

For this the assumption -ggdb would add about 300% in size is a bit
exsessive.

Background:
The option -g produces debugging information in the operating systems native
format, already fit for GDB. -ggdb simply uses the most expressive format.
Both, as I believe, result in DWARF-2 format on my system. At least I get no
difference whether I specify -g -gdwarf-2 or -ggdb. GDB extensions are
added if possible.

It seems to me, judging the results of the tests below, that those gdb-
extensions are already enabled by default (gcc-4.7.2).
I have not found any information on that regarding DWARF-2, but at least
 http://gcc.gnu.org/onlinedocs/gccint/DBX-Options.html
states that DEFAULT_GDB_EXTENSIONS (for DBX output) is always turned on by
default.

Maybe that's true for DWARF-2 as well?


Below are the resulting sizes of all .debug files having been generated first
using -ggdb, then using -g in make.conf CFLAGS.

The tested packages are:

1) kde-base/kate (C++ Code, heavy library usage) and
2) dev-libs/lzo (ANSI C)

I believe both are, regarding their code base, far enough apart for building
up a test case. It is _not_ representative, of course.


1) --- kde-base/kate
-

Compiled with -ggdb in CFLAGS:

 # sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140

Compiled with -g in CFLAGS:

 # sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140

Result: No size change at all.


2) --- dev-libs/lzo
-

Compiled with -ggdb in CFLAGS:

 # sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558664

Compiled with -g in CFLAGS:

 # sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558304


Result: A difference of 260 bytes or 0.06%. Far away from the assumed 300%.


Conclusion:
I do not doubt that -ggdb adds size. It does. And maybe, if I did an emerge -e
@world would reduce the size used on my system between 30% and 40%. But not
about 66% like assumed.


However, even if it where around 5-6 G, it would be thrice the initial
assumption of 2G. And that's the whole point.



Sincerly

Sven

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Philipp Riegger


On 17.12.2012 11:23, Diego Elio Pettenò wrote:

On 17/12/2012 11:19, Tomáš Chvátal wrote:


I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough how to
make world and config files to be put elsewhere :P).


I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.



With this change distfiles and packages could be moved to a directory 
which is not a subdir of portage. Something like


/var/cache/{portage,distfiles,packages}

or

/var/cache/portage/{tree,distfiles,packages}

since the file types and storage requirements are so different. At least 
I prefer not to have too many filesystems mounted inside each other.


Philipp

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread justin

On 17/12/12 12:17, Diego Elio Pettenò wrote:
 On 17/12/2012 12:06, justin wrote:
 fetch-restricted files are to be considered critical here. Do we want to
 force the user to keep them twice? So an additional location which is
 not a cache?
 Of course PORTAGE_RO_DISTDIRS and friends are nice here, but they are
 not part of a default setup.
 
 I would still think they are cache. I can re-download Oracle's JRE
 binaries; Portage's copy is a cache because I don't need to back it up.
 

I am more thinking about packages which are not as easy accessible as
JRE. There are a couple sci packages which are distributed on request by
mail other inconvenient methods. Sometimes even not by your own, but by
your PI or other seniors. And even sometimes upstreams doesn't
distribute them anymore at all.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Ulrich Mueller

 On Mon, 17 Dec 2012, Michał Górny wrote:

 On Mon, 17 Dec 2012 11:23:00 +0100
 Diego Elio Pettenò flamee...@flameeyes.eu wrote:

 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

 +1 on /var/cache.

If we change the location, can we then move distfiles to some place
outside of the tree? Something like:

   /var/cache/portage
   /var/cache/distfiles

Rationale for this is that the tree with many small files and
distfiles (which tend to be large) have very different parameters for
filesystem optimisation, when one of them (or both) are kept on a
separate partition.

Ulrich

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 13:42, Ulrich Mueller wrote:
 If we change the location, can we then move distfiles to some place
 outside of the tree? Something like:
 
/var/cache/portage
/var/cache/distfiles

What I do on my systems is

/var/cache/portage/tree
/var/cache/portage/distfiles

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 13:39, justin wrote:
 I am more thinking about packages which are not as easy accessible as
 JRE. There are a couple sci packages which are distributed on request by
 mail other inconvenient methods. Sometimes even not by your own, but by
 your PI or other seniors. And even sometimes upstreams doesn't
 distribute them anymore at all.

In which case you should keep them somewhere safer anyway, which is what
I do for that kind of files.

Remember that eclean acts on distfiles as well.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread Richard Yao

On 12/17/2012 05:40 AM, Olav Vitters wrote:
On Sat, Dec 15, 2012 at 03:17:05PM -0500, Richard Yao wrote:
On 12/15/2012 02:33 PM, Michał Górny wrote:
On Sat, 15 Dec 2012 13:58:43 -0500
Walter Dnes waltd...@waltdnes.org wrote:
On Sat, Dec 15, 2012 at 07:07:09PM +0100, Micha?? G??rny wrote
Waaait, what? Did something change lately or are you just repeating
the same bullshit for months?

Older systemd boots OK with a separate /usr and eudev. But somehow,
somewhere along the line, as part of the merge, the udev portion of the
systemd tarball requires initramfs. See news item...
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=36326;list=gentoo
It was actually finally released 2012-03-16. If you disagree with that
news item, complain directly to its author. If you can boot a udev-181
or higher system with a separate /usr, and no intrd/initramfs, I'm sure
a lot of people would be very interested in knowing how.

This was a Gentoo decision, not an upstream one.

If I recall, WilliamH stated at the time that he believed that upstream
would make avoiding it increasingly difficult. My impression was that he
felt coerced into making that change.

So systemd still works with a separate /usr and you're continuing to
spread misinformation. Demonstrating such behaviour while complaining
about the behaviour of upstream is IMO very ironic.

I believe that the systemd upstream developers would disagree. They
claim is that this is completely broken and any attempt to make it work
(such as what we are discussing) is strongly discouraged.

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Tiziano Müller

Am Montag, den 17.12.2012, 11:19 +0100 schrieb Tomáš Chvátal:
 Currently we put portage into /usr/portage and all related stuff is to
 be in the subfolders there (distfiles, binpkg).
 
 I've always myself override these defaults in make.conf to point for
 /var/portage/ (not /var/lib because I never bothered enough how to
 make world and config files to be put elsewhere :P).

I always move the stuff as well:

* /var/cache/distfiles
* /var/cache/packages ... may not be the best choice since they can't
always be regenerated
* /var/db/repositories/portage
* /var/db/repositories/... (other portage repositories)
* /var/db/paludis/repositories/... (for paludis-specific repositories,
like layman)

Tiziano

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread Olav Vitters

On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote:
 On 12/17/12 11:40 AM, Olav Vitters wrote:
 So systemd still works with a separate /usr and you're continuing to
 spread misinformation. Demonstrating such behaviour while complaining
 about the behaviour of upstream is IMO very ironic.
 
 No it does not, try by yourself please ^^
 
 (or just issue and ldd over the main binaries)

I quoted the relevant bits. There has been communication here about it
as well as elsewhere.

What was said here is that systemd did not support this. It does. Now we
can twist words that sometimes Gentoo does not mean Gentoo. That
systemd sometimes means as packaged by Gentoo and sometimes upstream.

Poor behaviour!

And yeah, the separate /usr has been mentioned as not to be a problem
(meaning: it works) by the Debian developers when that claim was made on
their list. Furthermore this has found not to be a problem by the Mageia
contributor + QA team. Anyway, this is all happened before this
announcement and the emails in this thread where it was again repeated.
This is a little bit too much IMO to not speak up.

-- 
Regards,
Olav

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Kevin Chadwick

On Mon, 17 Dec 2012 11:19:20 +0100
Tomáš Chvátal tomas.chva...@gmail.com wrote:

 The only reason why we have this currently in usr is that bsd ports
 put their stuff in there and I suppose Daniel just did the same.

 +1 on /var/cache.
  
 Agreed.

Bonus points if we consider suggesting to move it on a dedicated
file system ^^;

/var sounds right but if /usr is still huge it may annoy some (like
apt can) with smaller drives who now need lots of free space for new
programs in both /usr and /var. Of course there is LVM.

On OpenBSD the Auto partition map suggests /usr/ports /usr/src as
seperate partitions as long as you have a fair amount of space. It
possibly even suggests a seperate obj partition. The benefit being you
can mkfs/newfs much quicker than deleting many many files. Security (DAC
permission avoidance) and nuking more than what you wanted obviously
needs consideration for that kind of function. 

So it's probably a user exercise?

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Kacper Kowalik

On 12/17/2012 11:11 AM, Tomáš Chvátal wrote:
 Hi lads,
 lately I am having bit of problems from getting relevant debug info from 
 users.

All trouble can be saved by asking user to recompile package with
relevant flags on bug report, resolving the bug as NEEDINFO. Instead of
forcing everybody out there using Gentoo to have additional XGb for
debug, patching troublesome packages like webkit-gtk etc. Bug without
valid data is by definition... invalid?

I'm pretty amused by this thread, cause *you* taught me that ^^. I had
once the very same idea :)
Cheers,
Kacper

 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.
 
 This results in 2 gb data in /usr/lib/debug for my system which is not
 that bad with current disk sizes and it saves users quite some time
 when i have to request them to recompile half of their system with
 debug info just to get idea how to fix their issue.
 
 I would go even for compressdebug feature but that one needs more time
 as some packages like glibc fails to merge with it and you need newer
 gdb to work with it.
 
 Cheers
 
 Tom
 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 14:40, Kevin Chadwick wrote:
 /var sounds right but if /usr is still huge it may annoy some (like
 apt can) with smaller drives who now need lots of free space for new
 programs in both /usr and /var. Of course there is LVM.

Changing our defaults is unlikely to force users to change their settings.

 On OpenBSD the Auto partition map suggests /usr/ports /usr/src as
 seperate partitions as long as you have a fair amount of space. It
 possibly even suggests a seperate obj partition. The benefit being you
 can mkfs/newfs much quicker than deleting many many files. Security (DAC
 permission avoidance) and nuking more than what you wanted obviously
 needs consideration for that kind of function. 

Honestly I would never take what OpenBSD does to face value.

But in general this is a call for users — myself I have been keeping
them split on the tinderbox host but merged into the rootfs for the laptops.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Moving our/portage stuff to var

On Mon, Dec 17, 2012 at 8:40 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 So it's probably a user exercise?

It already is a user exercise.  A stage3 doesn't even contain the
/usr/portage directory - you manually create it per the handbook (or
more likely let tar/etc do it for you.

I also would like to see distfiles moved.  Ideally the package tree
should be a perfect copy of what is on the rsync mirrors.  It seems a
bit odd to stick other stuff in there, which needs special treatment
as a result.

To the extent that this isn't already supported, portage should simply
let you set the location in make.conf.

I'd also suggest at least considering how paludis handles this.  They
just have a directory containing config file per repository, with a
priority setting.  The portage tree is just another overlay, which is
a good way to handle it.  The sync mechanism handles the main tree
identically to overlays as a result, though you can specify what to
sync.

Rich

Re: [gentoo-dev] Defaulting for debug information in profiles

On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik xarthis...@gentoo.org wrote:
 All trouble can be saved by asking user to recompile package with
 relevant flags on bug report, resolving the bug as NEEDINFO. Instead of
 forcing everybody out there using Gentoo to have additional XGb for
 debug, patching troublesome packages like webkit-gtk etc. Bug without
 valid data is by definition... invalid?

Tend to agree.  Plus, you can always compile -O0 in such a case and
get more useful debug info besides (yes, I know this can be misleading
under some circumstances, but not all packages are glibc).  Plus, if
the user doesn't enable core dumps the debug info is useless unless
the problem is reproducible, and if it is reproducible then you can
just build it with debug info.

But, by all means make it easy for the user to make their own choice.

I usually keep a debug file in /etc/portage/env.d and symlink it to
anything I'm working on.

Rich

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 14:49, Rich Freeman wrote:
 I'd also suggest at least considering how paludis handles this.  They
 just have a directory containing config file per repository, with a
 priority setting.  The portage tree is just another overlay, which is
 a good way to handle it.  The sync mechanism handles the main tree
 identically to overlays as a result, though you can specify what to
 sync.

Let's not conflate two completely different changes with two completely
different work required to deal with them.

Changing our default locations, and the documentation is quick. Changing
the way the syncing/handling is done is a nightmare.

If we conflate the issue, we can stop discussing as we're never ever
going to go anywhere.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On Mon, Dec 17, 2012 at 5:43 AM, Markos Chandras hwoar...@gentoo.org wrote:

 Outsource it to someone who has the knowledge and interest in doing
 this. The foundation has the funds to support it, and none of us
 actually have the time to invest in a complete webpage redesign.

Before we considered undertaking this, we need somebody with a
long-term Gentoo commitment (preferably a dev or docs team member, or
even forum moderators or similar role) who would be in a leadership
position.  You don't just hire somebody and point them at your website
and say, make it better.  I'd like to see somebody with
passion/vision leading this rather than the collective groans of the
mailing lists (valid as they may be).

To be useful it needs to be maintained as well.

If bringing in a professional is what it takes to get us over the hump
into sustainability then I'm all for it.  However, I don't think we
have all our bases covered yet.  We might find that once we address
the long-term care of our site the need to bring in a professional
goes away. However, if we get a vibrant team together to care for the
site I'm sure the Trustees will weigh their recommendations heavily.
We generally don't bikeshed - if infra says they need to replace a
hard drive we pay for it.  If the web site had a similar team caring
for it I'm sure we'd work with them, and likely let them lead the
interviews as well.

As a volunteer distro the first preference is of course that we fix
things ourselves.  However, I fully recognize that good web
development is a skillset.

Rich

Re: [gentoo-dev] Defaulting for debug information in profiles

On Mon, Dec 17, 2012 at 9:05 AM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 So please stop giving this stupid suggestion, which causes enough grief
 as it is without being repeated once again.

Uh, sure, insofar as it is possible to stop doing something that
you've done exactly once...  :)

However, I've found it a useful tool, assuming the error is still
reproducible.  If it prevents the error from being reproduced it is
obviously less useful.  I for one like having all parameters on my
stack frame, but perhaps there is another switch that will only toggle
this.

Rich

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread Richard Yao

On 12/17/2012 08:25 AM, Olav Vitters wrote:
 On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote:
 On 12/17/12 11:40 AM, Olav Vitters wrote:
 So systemd still works with a separate /usr and you're continuing to
 spread misinformation. Demonstrating such behaviour while complaining
 about the behaviour of upstream is IMO very ironic.

 No it does not, try by yourself please ^^

 (or just issue and ldd over the main binaries)
 
 I quoted the relevant bits. There has been communication here about it
 as well as elsewhere.
 
 What was said here is that systemd did not support this. It does. Now we
 can twist words that sometimes Gentoo does not mean Gentoo. That
 systemd sometimes means as packaged by Gentoo and sometimes upstream.
 
 Poor behaviour!
 
 And yeah, the separate /usr has been mentioned as not to be a problem
 (meaning: it works) by the Debian developers when that claim was made on
 their list. Furthermore this has found not to be a problem by the Mageia
 contributor + QA team. Anyway, this is all happened before this
 announcement and the emails in this thread where it was again repeated.
 This is a little bit too much IMO to not speak up.
 

As I said in an earlier email, Lennart Poettering claims that it does
not work. We are discussing some of the things necessary to make it work.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Defaulting for debug information in profiles

On 17/12/2012 15:20, Rich Freeman wrote:
 Uh, sure, insofar as it is possible to stop doing something that
 you've done exactly once...  :)

In general, I've heard the same suggestion touted too many times
already. It's this kind of misinformation and cargo culting that often
causes `strip-flags` to be used (even when gcc codegen is perfectly
fine), or that make upstream complain that Gentoo users are ricers for
not sticking with -O0.

 However, I've found it a useful tool, assuming the error is still
 reproducible.  If it prevents the error from being reproduced it is
 obviously less useful. 

By experience with the kind of crashes we get reported on bugzilla,
roughly eight times out of ten it's perfectly pointless to use -O0.

_FORTIFY_SOURCES overflows can't happen at -O0.
Uninitialized variables are zeroed out at -O0.

At -O0 you're debugging a completely different program. Sure it's
possible that the crash is so blatantly broken than it will crash
anyway, but that kind of crashes tend to be extremely rare and easy to
catch to begin with.

In most cases, you just want to know the ballpark of where the crash is
happening, as you want to know which assumption is not holding up.

 I for one like having all parameters on my
 stack frame, but perhaps there is another switch that will only toggle
 this.

There is, but it can stop constant propagation from working properly. If
we're discussing about crashes, which is what debug information in
general is useful for, -O0 is useless in most cases.

It's a different story altogether if you go into what a developer would
do to debug a particularly nasty crash, or to see why something's
misbehaving, and you want to use gdb rather than fill your code of
printf() statements. But that's a completely different story, so let's
leave it at that.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Marc Schiffbauer

Am Montag, 17. Dezember 2012, 11:23:00 schrieb Diego Elio Pettenò:
 On 17/12/2012 11:19, Tomáš Chvátal wrote:
  I've always myself override these defaults in make.conf to point for
  /var/portage/ (not /var/lib because I never bothered enough how to
  make world and config files to be put elsewhere :P).

 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.

What about setups where portage tree is mounted via NFS to reduce traffic and
disk space?

FHS states[1] that /var/cache is *locally* generated. Which aould not be the
case for such setups...

I prefer /var as well, but I am not such if /var/cache would be the right
place...


[1]
From FHS 2.3:
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or calculation.

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 15:49, Marc Schiffbauer wrote:
 What about setups where portage tree is mounted via NFS to reduce traffic and 
 disk space?

Since nothing in Gentoo and/or other distributions _enforces_ FHS,
you're allowed to do as you prefer

 FHS states[1] that /var/cache is *locally* generated. Which aould not be the 
 case for such setups...

Again, you can do as you prefer. Do you wish to violate FHS to just keep
in the usual place? You can. You want to move it somewhere else to
adhere to FHS? You can.

 I prefer /var as well, but I am not such if /var/cache would be the right 
 place...

Any other suggestions on where to place it? And please don't say
/var/lib because that would usually be backed up.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On 17 December 2012 12:31, Dirkjan Ochtman d...@gentoo.org wrote:
 On Mon, Dec 17, 2012 at 11:43 AM, Markos Chandras hwoar...@gentoo.org wrote:
 Outsource it to someone who has the knowledge and interest in doing
 this. The foundation has the funds to support it, and none of us
 actually have the time to invest in a complete webpage redesign.

 If we have funds for this kind of thing, the PSF process is a good example:

 http://pythonorg-redesign.readthedocs.org/en/latest/

 (And I think that would be a great idea.)

 Cheers,

 Dirkjan


I believe this is something that this[1] project needs to decide and
set it in motion.

[1]http://www.gentoo.org/proj/en/pr/website.xml

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Marc Schiffbauer

Am Montag, 17. Dezember 2012, 15:56:11 schrieb Diego Elio Pettenò:
 On 17/12/2012 15:49, Marc Schiffbauer wrote:
  What about setups where portage tree is mounted via NFS to reduce traffic
  and disk space?

 Since nothing in Gentoo and/or other distributions _enforces_ FHS,
 you're allowed to do as you prefer

  FHS states[1] that /var/cache is *locally* generated. Which aould not be
  the case for such setups...

 Again, you can do as you prefer. Do you wish to violate FHS to just keep
 in the usual place? You can. You want to move it somewhere else to
 adhere to FHS? You can.

  I prefer /var as well, but I am not such if /var/cache would be the right
  place...

 Any other suggestions on where to place it? And please don't say
 /var/lib because that would usually be backed up.

FHS also states:

[...] Other portions may be shared [between systems], notably /var/mail,
/var/cache/man, /var/cache/fonts, and /var/spool/news.

So I think this might indeed be interpreted like that /var/cache/portage would
be perfectly ok.

Another place I could imagine is /var/portage because of its fundamental
importance in gentoo.

FHS about that: Applications must generally not add directories to the top
level of /var. Such directories should only be added if they have some system-
wide implication, and in consultation with the FHS mailing list.

I think this would also be ok because portage can be counted as system-wide
implication ...

-Marc
--
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] College Course in Gentoo Development


Hi everyone,

Give the talk on the list about attracting devs, I've should probably 
mention that I'm teaching a College Course on Gentoo Development next 
semester.  I know two students will most likely go through the 
recruitment process, others may at least contribute.  So its like GSoC 
but the focus is not one project but an overview of general gentoo 
development, and I will have to touch on lots of stuff outside of gentoo 
per se, like how autotools and other build systems work.


So what should I teach?  Here's what I've got off the top of my head:

1. Open source communities and Gentoo's internal political structure.

2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.

3. Delivering the goods: code - build system - portage - compiled 
goodies - working system


4. How to work with gnu autotools.  Writing a build system.

5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.

6. Arches, arch testing.  Profiles.

7. Building stages.  Catalyst.

Somewhere in there I'll squeeze in Gentoo's alt factor: alternative c 
libs, alternative compilers and hardening, alternative kernels, prefixes.


Please comment.  If it gets systematized enough, it can be a guide to 
future devs too.  Everything will be creative commons.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Moving our/portage stuff to var


On 12/17/2012 05:30 AM, Michał Górny wrote:

On Mon, 17 Dec 2012 11:23:00 +0100
Diego Elio Pettenòflamee...@flameeyes.eu  wrote:


On 17/12/2012 11:19, Tomáš Chvátal wrote:

I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough how to
make world and config files to be put elsewhere :P).

I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.

+1 on /var/cache.


+1 on the idea of moving portage and +1 on the idea of /var/cache

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On 17 December 2012 14:08, Rich Freeman ri...@gentoo.org wrote:
 On Mon, Dec 17, 2012 at 5:43 AM, Markos Chandras hwoar...@gentoo.org wrote:

 Outsource it to someone who has the knowledge and interest in doing
 this. The foundation has the funds to support it, and none of us
 actually have the time to invest in a complete webpage redesign.

 Before we considered undertaking this, we need somebody with a
 long-term Gentoo commitment (preferably a dev or docs team member, or
 even forum moderators or similar role) who would be in a leadership
 position.  You don't just hire somebody and point them at your website
 and say, make it better.  I'd like to see somebody with
 passion/vision leading this rather than the collective groans of the
 mailing lists (valid as they may be).

Ehm I never said to blindly assign this task to someone. This is why I
said that the website project[1] should take initiative here :)

[1]http://www.gentoo.org/proj/en/pr/website.xml

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] Moving our/portage stuff to var

On Mon, 2012-12-17 at 11:23 +0100, Diego Elio Pettenò wrote:
 On 17/12/2012 11:19, Tomáš Chvátal wrote:
  
  I've always myself override these defaults in make.conf to point for
  /var/portage/ (not /var/lib because I never bothered enough how to
  make world and config files to be put elsewhere :P).
 
 I would say let's work on that so that portage can keep them there.
 Although I'm more for /var/cache/portage myself, as both distfiles and
 tree can be re-generated.
 

I've been pushing for the portage tree to move somewhere in /var for
awhile.

Also I think the tree and layman overlays should be under the same
master directory, then portage, pkgcore,... could just quickly scan the
master directory  sub directories to auto-add the valid overlays there.
No need to add them to PORTDIR_OVERLAY

something like

/var/cache/repositories/
/var/cache/repositories/gentoo
/var/cache/repositories/x11== overlay
/var/cache/repositories/local== overlay
/var/cache/repositories/distfiles== move it out of the tree dir.
/var/cache/repositories/packages== move it out of the tree dir.

-- 
Brian Dolbec dol...@gentoo.org


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Moving our/portage stuff to var

On Mon, 2012-12-17 at 13:47 +0100, Diego Elio Pettenò wrote:
 On 17/12/2012 13:39, justin wrote:
  I am more thinking about packages which are not as easy accessible as
  JRE. There are a couple sci packages which are distributed on request by
  mail other inconvenient methods. Sometimes even not by your own, but by
  your PI or other seniors. And even sometimes upstreams doesn't
  distribute them anymore at all.
 
 In which case you should keep them somewhere safer anyway, which is what
 I do for that kind of files.
 
 Remember that eclean acts on distfiles as well.
 

which is why eclean has a config file where you can add files/pkgs,
patterns to exclude from being cleaned.
-- 
Brian Dolbec dol...@gentoo.org


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Moving our/portage stuff to var

On Mon, 2012-12-17 at 15:56 +0100, Diego Elio Pettenò wrote:
 On 17/12/2012 15:49, Marc Schiffbauer wrote:
  What about setups where portage tree is mounted via NFS to reduce traffic 
  and 
  disk space?
 
 Since nothing in Gentoo and/or other distributions _enforces_ FHS,
 you're allowed to do as you prefer
 
  FHS states[1] that /var/cache is *locally* generated. Which aould not be 
  the 
  case for such setups...
 
 Again, you can do as you prefer. Do you wish to violate FHS to just keep
 in the usual place? You can. You want to move it somewhere else to
 adhere to FHS? You can.
 
  I prefer /var as well, but I am not such if /var/cache would be the right 
  place...
 
 Any other suggestions on where to place it? And please don't say
 /var/lib because that would usually be backed up.
 

then /var/repositories/  similar to my previous reply.  It is very clear
by the name what it's purpose is.  Also name the portage tree dir gentoo
like it's repo_name and all but one of the layman overlays available to
install.
-- 
Brian Dolbec dol...@gentoo.org


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Moving our/portage stuff to var

On 17/12/2012 16:51, Brian Dolbec wrote:
  
 then /var/repositories/  similar to my previous reply.  It is very clear
 by the name what it's purpose is.  Also name the portage tree dir gentoo
 like it's repo_name and all but one of the layman overlays available to
 install.

Erm, why should we invent something new on top of var which is something
that about everywhere it's suggested NOT to do?

Using /var/lib clearly spells back this up yourself.
Using /var/cache clearly spells can be lost without consequences.
Using /var/tmp clearly spells things will be deleted.

/var/repositories sounds just like NIH, seriously.

Somebody already proposed /var/db — that probably makes more sense if
you want to go that route, although I wouldn't put distfiles or packages
there.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Rick Zero_Chaos Farina

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
 Hi everyone,
 
 Give the talk on the list about attracting devs, I've should probably
 mention that I'm teaching a College Course on Gentoo Development next
 semester.  I know two students will most likely go through the
 recruitment process, others may at least contribute.  So its like GSoC
 but the focus is not one project but an overview of general gentoo
 development, and I will have to touch on lots of stuff outside of gentoo
 per se, like how autotools and other build systems work.
 
 So what should I teach?  Here's what I've got off the top of my head:
 
 1. Open source communities and Gentoo's internal political structure.
 
 2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.
 
 3. Delivering the goods: code - build system - portage - compiled
 goodies - working system
 
 4. How to work with gnu autotools.  Writing a build system.
 
 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.
 
 6. Arches, arch testing.  Profiles.
 
 7. Building stages.  Catalyst.
 
 Somewhere in there I'll squeeze in Gentoo's alt factor: alternative c
 libs, alternative compilers and hardening, alternative kernels, prefixes.
 
 Please comment.  If it gets systematized enough, it can be a guide to
 future devs too.  Everything will be creative commons.
 
Can I take this course online? Will the lectures be recorded?

- -ZC
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQz0IQAAoJEKXdFCfdEflKikMP/iXGzyM1Bda1hfWa8L9Iby8e
kpRee1N/7+QpjZB/caDVzNm5CWEJn3Vs2LP71Ig/Ybve41EvqGJXGfBDAbF7cfIb
d6kXZqgPfKj480TT2toUAY/fIji3jbmrPxrTYBXigDsIcUxrpiMykgQMifW4esK/
1ZddA5UCI8LQxIjrDDItVQL88PMz7vSBQqgJvobXAPEdHG/xDXLUews4UsgN6z7c
F95220G2DmaPzxnITIuJfFQ1sui1ahkHJRLr4uz1e8BMFcnCbWJOFsQAqNvX8YZV
iAcb4HHTC6EXD5MUKF+OGv+sy1PJy8f4G7/cnERJxdADdyZkOUj8HQGEnuY3znt+
nbvSoCQVGAEkdm0mQY6x7kbZDzQhvztvrP2ovMCLz9FPzai+wcWQ07d00nbQd17v
mUPntVXSYKsXKg+hTPj1rGzh3Nu9zGcw7mwtJwH/z0J3sqPJRSlp88KCWIOP7bro
J+7trObO8c9GYQK6JVAFL7sxBQct9vBO4DETOJ6XxMG7lJ89GLA/zdSIBWbvWPZf
GZ+Z3+ohV//Bf9I28S5AeRVczBdAE13EFUj7VcvsRYTMkTgawHo3jQtU+gzRHfhk
H/16vCDoZ511F4wu4PF9zKWuffiVy25y0PLPewbwlPbvPwAIWiK4hsGt87t2mckr
cerDzNSNBYf9NfbHiMe7
=7Vnh
-END PGP SIGNATURE-

Re: [gentoo-dev] Moving our/portage stuff to var

On Mon, 2012-12-17 at 15:02 +0100, Diego Elio Pettenò wrote:
 On 17/12/2012 14:49, Rich Freeman wrote:
  I'd also suggest at least considering how paludis handles this.  They
  just have a directory containing config file per repository, with a
  priority setting.  The portage tree is just another overlay, which is
  a good way to handle it.  The sync mechanism handles the main tree
  identically to overlays as a result, though you can specify what to
  sync.
 
 Let's not conflate two completely different changes with two completely
 different work required to deal with them.
 
 Changing our default locations, and the documentation is quick. Changing
 the way the syncing/handling is done is a nightmare.
 
 If we conflate the issue, we can stop discussing as we're never ever
 going to go anywhere.
 

I agree.  

But for the purpose of answering Rich, layman is also capable of syncing
the portage tree, although, not using the round robin and other user
sync variations portage is capable of.  Once I finish the python 3
compatibility code changes.  I will re-visit getting layman's api use
into portage, pkgcore for them to use to sync the overlays from within
the package manager.  I have already demonstrated how easy it is for
portage to run layman's api.  An in tree example is app-portage/esearch
which adding the -l parameter will use the layman api if available or
fall back to running layman in a subprocess to sync the overlays as well
as the portage tree.
-- 
Brian Dolbec dol...@gentoo.org


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Ciaran McCreesh

On Mon, 17 Dec 2012 15:56:11 +0100
Diego Elio Pettenò flamee...@flameeyes.eu wrote:
 Any other suggestions on where to place it? And please don't say
 /var/lib because that would usually be backed up.

/var/db

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Paweł Hajdan, Jr.

On 12/17/12 2:11 AM, Tomáš Chvátal wrote:
 Since we already have splitdebug for quite time (and I suppose quite
 few of us are using it) how about making it to default profiles
 default enabled and add -g to default cflags. Currently it is only
 enabled in the developer profile.

Fully seconded.

For people raising concerns in this thread: it can be easily disabled.

I think good defaults are really important. What do you think is more
reasonable to assume: (1) that the user hits crashes and wants to submit
a good bug report but doesn't want to recompile half of the system, or
(2) that the user has very limited disk space or some other kind of
special configurations.

Note that (2) is totally fine, I just think it's less likely to happen
(hopefully we can avoid a bias here with people thinking if _they_ have
a setup that can't use splitdebug or something, the same would apply to
everybody else).

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Moving our/portage stuff to var

2012-12-17 Thread Paweł Hajdan, Jr.

On 12/17/12 2:19 AM, Tomáš Chvátal wrote:
 With respect to reality how stuff is done in the linux land all the
 variable data should be in /var so we should adjust and move it in
 there too.
 
 What would  you think?

Fully seconded.

+1 to /var/cache/portage and having distfiles outside of the portage
tree directory.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Paweł Hajdan, Jr.

On 12/17/12 7:32 AM, Anthony G. Basile wrote:
 So what should I teach?  Here's what I've got off the top of my head:
 Please comment.  If it gets systematized enough, it can be a guide to
 future devs too.  Everything will be creative commons.

I think it's worth to mention somewhere that although packages take
longer to compile than downloading binaries, people don't have to
_watch_ the compilation, and many things can be done e.g. overnight.

Also, remember that Google's ChromeOS takes a lot of things from Gentoo,
including the package manager and many ebuilds. The idea here is that it
has applications in the industry.

Oh, unbundling libraries _might_ be valuable too. Or automagic
dependencies and other such packaging issues.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Defaulting for debug information in profiles

2012-12-17 Thread Walter Dnes

On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
 1) --- kde-base/kate
 -
 
 Compiled with -ggdb in CFLAGS:
 
  # sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do 
 xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
 32652140
 
 Compiled with -g in CFLAGS:
 
  # sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do 
 xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
 32652140
 
 Result: No size change at all.
 
 
 2) --- dev-libs/lzo
 -
 
 Compiled with -ggdb in CFLAGS:
 
  # sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do 
 xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
 558664
 
 Compiled with -g in CFLAGS:
 
  # sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do 
 xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
 558304
 
 
 Result: A difference of 260 bytes or 0.06%. Far away from the assumed 300%.
 
 
 Conclusion:
 I do not doubt that -ggdb adds size. It does. And maybe, if I did an emerge 
 -e 
 @world would reduce the size used on my system between 30% and 40%. But not 
 about 66% like assumed.
 
 
 However, even if it where around 5-6 G, it would be thrice the initial 
 assumption of 2G. And that's the whole point.

  On my 32-bit machines I have...

FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe 
-fno-unwind-tables -fno-asynchronous-unwind-tables
CXXFLAGS=${CFLAGS}

  See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables.  Would I
have to rebuild system and world without...

-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables

...to have debug data available?

-- 
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications

Re: [gentoo-dev] Defaulting for debug information in profiles

On 12/17/2012 02:55 PM, Rich Freeman wrote:
 On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik xarthis...@gentoo.org wrote:
 All trouble can be saved by asking user to recompile package with
 relevant flags on bug report, resolving the bug as NEEDINFO. Instead of
 forcing everybody out there using Gentoo to have additional XGb for
 debug, patching troublesome packages like webkit-gtk etc. Bug without
 valid data is by definition... invalid?
 
 Tend to agree.  Plus, you can always compile -O0 in such a case and

Ages ago I wrote something about how wrong is using -O0 and expect to
reproduce issues. IIRC Diego blogged about it as well.

Please do not use -O0, it changes a _lot_ the codepats of programs and
glibc (and other libc) might or might not switch to compiler specific
implementation that might uncover problems.

I'd rather suggest the user to install valgrind and run the application
under it.

lu

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Ian Stakenvicius

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/12/12 10:32 AM, Anthony G. Basile wrote:
 Hi everyone,
 
 Give the talk on the list about attracting devs, I've should
 probably mention that I'm teaching a College Course on Gentoo
 Development next semester.  I know two students will most likely go
 through the recruitment process, others may at least contribute.
 So its like GSoC but the focus is not one project but an overview
 of general gentoo development, and I will have to touch on lots of
 stuff outside of gentoo per se, like how autotools and other build
 systems work.
 
 So what should I teach?  Here's what I've got off the top of my
 head:
 
 1. Open source communities and Gentoo's internal political
 structure.
 
 2. Building a gentoo system, ie the handbook.  Gentoo as
 metadistribution.
 
 3. Delivering the goods: code - build system - portage -
 compiled goodies - working system
 
 4. How to work with gnu autotools.  Writing a build system.
 
 5.  How to write ebuilds, ie the dev manual.  How to work with cvs
 and git.
 

5.5:  BUGS

Very appropriate here to include somewhere (perhaps as a precursor to
#4 or as part of #5) how to (A) generate useful patches, (B) apply
patches for testing (overlay ebuild, epatch_user, etc), (C) use
bugzilla (useful submissions, bug-wrangling, herds).  QA related
issues would be good to deal with, also (maybe under arch testing in
#6?).  IE: missing dependencies, automagic dependencies, --as-needed
failures, etc. etc.


 6. Arches, arch testing.  Profiles.
 
 7. Building stages.  Catalyst.
 
 Somewhere in there I'll squeeze in Gentoo's alt factor:
 alternative c libs, alternative compilers and hardening,
 alternative kernels, prefixes.
 
 Please comment.  If it gets systematized enough, it can be a guide
 to future devs too.  Everything will be creative commons.
 

The exam isn't going to be the ebuild quiz, is it? :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDPVP0ACgkQ2ugaI38ACPBxNQD/RvBkMHaJiwds7HpLUXnocWUi
cKXoBLfTMzeWPuVaV7QA/A3tWYw7FSTK6TCMEI68c3INcrFEF5jqjKlXha7rzq0s
=igjU
-END PGP SIGNATURE-

Re: [gentoo-dev] College Course in Gentoo Development


On 12/17/2012 12:23 PM, Ian Stakenvicius wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/12/12 10:32 AM, Anthony G. Basile wrote:

Hi everyone,


5.  How to write ebuilds, ie the dev manual.  How to work with cvs
and git.


5.5:  BUGS

Very appropriate here to include somewhere (perhaps as a precursor to
#4 or as part of #5) how to (A) generate useful patches, (B) apply
patches for testing (overlay ebuild, epatch_user, etc), (C) use
bugzilla (useful submissions, bug-wrangling, herds).  QA related
issues would be good to deal with, also (maybe under arch testing in
#6?).  IE: missing dependencies, automagic dependencies, --as-needed
failures, etc. etc.


Yes!  Definitely.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Roy Bamford

On 2012.12.17 16:02, Rick Zero_Chaos Farina wrote:
 On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
  Hi everyone,
 
  Give the talk on the list about attracting devs, I've should
  probably mention that I'm teaching a College Course on Gentoo 
  Development
[snip]

 Can I take this course online? Will the lectures be recorded?
 
 -ZC
 

I would be interested in an online version too.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpNo4gexStsn.pgp
Description: PGP signature

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Maxim Kammerer

On Mon, Dec 17, 2012 at 5:32 PM, Anthony G. Basile bluen...@gentoo.org wrote:
 Please comment.  If it gets systematized enough, it can be a guide to future
 devs too.

Hi, what is the level of the students, what are the prerequisites
(i.e., have they already seen some systems programming using C?), and
how many weekly hours? Have you already designed some assignments? I
can think of the following:

1. Create a small makefile-based project with a separate shared
library, an executable, and a man page. Determine run-time and
build-time dependencies. Then convert to autotools, update
dependencies. Do it all on GitHub, with a separate branch for
converting to autotools.

2. Write an ebuild for the project above, maintained in an overlay
(also on GitHub), with sources fetched from GitHub. Add some small
patch to configure.ac in the ebuild. Add USE flags. Add make check
support to the build system, test with FEATURES=test. Many
ebuild-related tasks can be easily added (e.g. installing init.d
scripts).

3. Take an old-version ebuild for a project with a known bug, fetch
the relevant git tag, and bisect to find the bug. Prepare a patch,
describe patch submission process.

Wrt. subjects covered, will you cover sandboxing, installing to image
vs. merging to live system, etc.? I would expect students to like such
stuff.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Michael Mol

On Mon, Dec 17, 2012 at 1:09 PM, Roy Bamford neddyseag...@gentoo.org wrote:
 On 2012.12.17 16:02, Rick Zero_Chaos Farina wrote:
 On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
  Hi everyone,
 
  Give the talk on the list about attracting devs, I've should
  probably mention that I'm teaching a College Course on Gentoo
  Development
 [snip]

 Can I take this course online? Will the lectures be recorded?

 -ZC


 I would be interested in an online version too.

As would I.

(I'd also be very interested in seeing the structure duplicated to
produce similar material for other common distributions...but I'm a
chrestomathy addict.)

--
:wq

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread hasufell

 
 4. How to work with gnu autotools.  Writing a build system.

Writing a build system from scratch is actually not a requirement.
However one should understand basics of the most popular build systems
and probably have some advanced understaning of Makefiles and how flags
work, where they should be placed and so on which leads me to what you'v
been missing a bit:

QA

Why we do it and what the most common QA issues are (things like
disrespected CFLAGS/CC/LDFLAGS, bundled libs, broken parallel make,
portage QA notices (i.e. broken strict-aliasing), automagic dependencies
and so on).

That's what seperates us from many other distros.

 
 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.

a few more specific thoughts on this...

IMO one of the more important points of writing ebuilds is to figure out
the dependencies correctly and how to implement use flags properly.
So figuring out dependencies usually involves reading the build system
and might even involve grepping/reading source files for includes/dlopen
or language specific things (note the differences in ruby, perl and
python...), cause assuming that the information from upstreams
INSTALL/README file suffices is almost always wrong.
Regarding useflags it's important to a) decide whether it makes sense to
offer that useflag/choice at all, b) what name to choose, so we don't
confuse the user, c) give descriptions in metadata.xml if the usecase
differs from the global description and d) test them all (which leads us
to point 6)

And that's exactly how I usually begin writing an ebuild:
- figure out all dependencies
- figure out what useflags to provide and how to implement them
- fix QA issues/patch the build system

Then the next thing is just understanding phase functions and the
regular helpers like econf/cmake-utils.eclass/eutils.eclass which you
can read up quite easily.

I would probably leave a few things behind like java ebuilds, ruby
ebuilds or even python ebuilds (due to the current eclass
conversion/confusion) and focus on autotools, cmake and plain Makefile
related things.

Give a few good and bad examples for each of them, so people understand
that every build system can be messed up.

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread hasufell

On 12/17/2012 07:11 PM, Maxim Kammerer wrote:
 Then convert to autotools, update
 dependencies. Do it all on GitHub, with a separate branch for
 converting to autotools.
 

That's not really a common thing to do for ebuild development (neither
converting nor writing from scratch).

Actually you only do that if you have direct access to the upstream repo
or know that they will accept your patch.

That happened only once to me.

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Ciaran McCreesh

On Mon, 17 Dec 2012 10:32:03 -0500
Anthony G. Basile bluen...@gentoo.org wrote:
 5.  How to write ebuilds, ie the dev manual.  How to work with cvs
 and git.

An important thing to teach here is how to code to a spec vs how to
code to an implementation. It's also something people should know in
general...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2012-12-17 Thread Roy Bamford

On 2012.12.17 15:15, Markos Chandras wrote:
 On 17 December 2012 12:31, Dirkjan Ochtman d...@gentoo.org wrote:
  On Mon, Dec 17, 2012 at 11:43 AM, Markos Chandras
 hwoar...@gentoo.org wrote:
  Outsource it to someone who has the knowledge and interest in 
 doing
  this. The foundation has the funds to support it, and none of us
  actually have the time to invest in a complete webpage redesign.
 
  If we have funds for this kind of thing, the PSF process is a good
 example:
 
  http://pythonorg-redesign.readthedocs.org/en/latest/
 
  (And I think that would be a great idea.)
 
  Cheers,
 
  Dirkjan
 
 
 I believe this is something that this[1] project needs to decide and
 set it in motion.
 
 [1]http://www.gentoo.org/proj/en/pr/website.xml
 
 -- 
 Regards,
 Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
 
 
 

To make this project a suitable project for Foundation funding, it 
needs a clearly defined specification that can be circulated for 
interested parties to provide fixed price quotations against.

The specification provides several things:-
1. the scope of work (out of scope work is extra cost)
2. the basis to judge completion (so we pay the fee)
3. some guidance as to implementation details

I know that 3. is unusual in a requirement specification but in this 
case it is unlikely that the Foundation would fund ongoing 
mainatainace, so we would need to dictate a few implementation details.
e.g. no Flash, Gentoo colours,

Its worth contrasting this sort of thing with a bug bounty.  The 
requirement is easy - fix the bug. Judging completion is fairly 
straight forward too. The patch is accepted by $UPSTREAM. 
The requirement specification for a website is a lot of work by 
comparison.

Suppose the team in [1] above wrote the specification, who needs to 
agree it?

The council, the trustees, the body of devs ... some combination of 
that list.  All in all, producing an agreed specification for a website 
it probably as much work as actually building the site. It could easily 
be as much work as the PMS. 

Anyway, I'm rambling a little.
In summary, if we decide to outsource the website project, it needs to 
be carefully controlled.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees


pgpTJWDmoCdNZ.pgp
Description: PGP signature

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread Olav Vitters

On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
 As I said in an earlier email, Lennart Poettering claims that it does
 not work. We are discussing some of the things necessary to make it work.

Just to repeat:
In this thread it was claimed that a separate /usr is not supported by
systemd/udev.

A case which works with latest systemd on various distributions. I
checked with upstream (not Lennart), and they confirmed it works. I can
wait for Lennart to say the same, but really not needed.

I assume this will again turn into a but I meant something else.

-- 
Regards,
Olav

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Hinnerk van Bruinehsen

On Mon, Dec 17, 2012 at 11:02:24AM -0500, Rick Zero_Chaos Farina wrote:
SNIP
 Can I take this course online? Will the lectures be recorded?
 
I would second the idea of an online course if that is possible: I
would even gladly do the beta testing of such an online course... ;)

WKR

Hinnerk

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread J. Roeleveld

Olav Vitters o...@vitters.nl wrote:

On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
 As I said in an earlier email, Lennart Poettering claims that it does
 not work. We are discussing some of the things necessary to make it
work.

Just to repeat:
In this thread it was claimed that a separate /usr is not supported by
systemd/udev.

A case which works with latest systemd on various distributions. I
checked with upstream (not Lennart), and they confirmed it works. I can
wait for Lennart to say the same, but really not needed.

I assume this will again turn into a but I meant something else.

Olav.

Lennart has stated that he considers a seperate /usr without init* broken.
This has worked correctly in the past.

The direction udev development is going, according to Lennart, is to make that 
impossible and he refuses to fix this regression.

I am really happy with this project and intend on testing it once requests for 
this appear in the eudev mailing list.

--
Joost Roeleveld
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

2012-12-17 Thread Jeroen Roovers

On Sun, 16 Dec 2012 14:14:49 -0500
Michael Mol mike...@gmail.com wrote:

 I face funroll-loops references and worse almost every time I bring up
 Gentoo among a different group of Linux-familiar technical people.
 There are still *very* strong prejudices against Gentoo in most places

Comparing Gentoo to binary Linux distros is simply using the wrong
analogy. I use Gentoo/Linux the way other people use some BSD with
ports - this is where Gentoo stands out, and compiler flags have little
to do with it. Build time configuration does. You pick a development
base, build and install packages you want on top of that, and you end
up running a stable system for years that is relatively easy to patch
up as and when needed.

The difference between many other ports-like distros and Gentoo is that
it is usually very well possible to do rolling upgrades and we make
that difference by ensuring a neverending progression from unstable to
stable, instead of calling a freeze every so often and picking up new
developments for future stable releases.

 I've brought it up. But when I bring it up, and I argue against those
 funroll-loops references, one or two people come out of lurking and
 admit that they use it...and it's a surprise to people around them.

There you go! Just explain that compiler optimisation is not the reason
you use it. Then you should have their attention and you can start to
explain the actual reasons you use it. It may make them feel rather
stupid about the plonk in the CD and roll with it attitude that they
must have picked up from some antiquated locked-down distro[1]. :)

 I've started describing it as a coming out of the closet experience
 for a reason... There's a _serious_ reputation issue that Gentoo still
 hasn't completely sloughed off...which is incredibly sad.

The same reputation issue that FreeBSD and OpenBSD have, no doubt.

 :wq

There is an app for that:
alias :wq='echo OK, I quit!'


 jer


[1] Heck, nowadays even Windows and Mac OS X support several ports-like
source-based software distros, despite sandboxed, walled-gardened
app stores for people who find it easier to pay for stuff than to
wonder how to get the software they need for free. And that's
entirely fair: it's a design/implementation decision everyone has
to make according to their own needs, expectations, limitations and
experience.

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Maxim Kammerer

On Mon, Dec 17, 2012 at 8:18 PM, hasufell hasuf...@gentoo.org wrote:
 On 12/17/2012 07:11 PM, Maxim Kammerer wrote:
 Then convert to autotools, update
 dependencies. Do it all on GitHub, with a separate branch for
 converting to autotools.

 That's not really a common thing to do for ebuild development (neither
 converting nor writing from scratch).

These are proposed course assignments (supposed to cover understanding
of certain subjects), not a training for writing ebuilds. :)

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

[gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing

2012-12-17 Thread Greg KH

On Mon, Dec 17, 2012 at 10:07:59AM -0500, Rich Freeman wrote:
 Announcing once to -dev-announce due to the general importance of this
 topic to the community, but ALL replies should go to -nfp, or to
 trustees@ if you must, or to /dev/null if you shouldn't.
 
 Before I start, yes, the trustees realize that there are legal issues
 around copyright assignment in general, and that various workaround
 exist and may or may not work, such as various contributor licensing
 agreements that are used by various organizations, especially in
 Europe.  The purpose of this thread isn't really to debate this topic,
 as it might be moot in any case.

I understand your wish to somehow think that the legal issues involved
have no pertinence to this discussion, but that just isn't the case.  In
fact, they will be one of the major factors that control any decision
that is picked, so you can't just ignore them, sorry.

 The question we would like to get feedback from the Gentoo community
 on is this: is copyright assignment (or something like it) something
 Gentoo should even be pursuing, and if so, to what degree?

My personal opinion is, No, the Gentoo Foundation should not be
pursuing any copyright assignment for any code that it creates or
manages.  And my main justification for this goes to the above point,
to do anything other than this is almost a legal impossibility for a
project like Gentoo (i.e. one that spans the world and accepts
contributions from people working for a wide range of companies) that
wishes to continue to accept contributions from as many people as
possible.

This was the main reason that Gentoo gave up on the copyright assignment
clause in the developer agreement all those years ago.

Those who forget history, are doomed to repeat it, let's not go through
all of this again, please.

On a personal note, if any copyright assignment was in place, I would
never have been able to become a Gentoo developer, and if it were to be
put into place, I do not think that I would be allowed to continue to be
one.  I'm sure lots of other current developers are in this same
situation, so please keep that in mind when reviewing this process.

thanks,

greg k-h

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread Greg KH

On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
 Olav Vitters o...@vitters.nl wrote:
 
 On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
  As I said in an earlier email, Lennart Poettering claims that it does
  not work. We are discussing some of the things necessary to make it
 work.
 
 Just to repeat:
 In this thread it was claimed that a separate /usr is not supported by
 systemd/udev.
 
 A case which works with latest systemd on various distributions. I
 checked with upstream (not Lennart), and they confirmed it works. I can
 wait for Lennart to say the same, but really not needed.
 
 I assume this will again turn into a but I meant something else.
 
 Olav.
 
 Lennart has stated that he considers a seperate /usr without init* broken.

Yes, as do I, and so do a lot of other developers.

But that is a system configuration issue, not a systemd issue, please
don't confuse the two.

 This has worked correctly in the past.

Define past please.

Note, it's still broken, I have yet to see any upstream fixes to resolve
all of the issues that are involved here with fixing this up.

Yes, as always, for some subset of users, you can be lucky and it will
work for them, but those systems are getting rarer and rarer these days,
as the rest of upstream (not systemd here) are moving on and not doing
anything to change their behavior for this topic.

 The direction udev development is going, according to Lennart, is to
 make that impossible and he refuses to fix this regression.

Again, this has NOTHING to do with udev or systemd, as has been pointed
out numerous times.  I understand your _wish_ that it would have
something to do with it, but that will not change the facts, sorry.

 I am really happy with this project and intend on testing it once
 requests for this appear in the eudev mailing list.

Good luck, the root problems still remain, and nothing that eudev ever
does can resolve that, sorry.

Can this topic finally be put to rest please?  There is a whole web page
devoted to this topic, why do people blindly ignore it?

Again, a separate /usr without an initrd has NOTHING to do with systemd
or udev, with the minor exception that Gentoo's packaging of those
programs _might_ have an issue, but that is Gentoo's issue, NOT
upstream's issue.

If anyone involved with eudev, or is involved with the Gentoo Council
thinks that the previous paragraph is incorrect, they are flat out
wrong.

greg k-h

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Michael Orlitzky

On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
 Hi everyone,
 
 Give the talk on the list about attracting devs, I've should probably 
 mention that I'm teaching a College Course on Gentoo Development next 
 semester.  I know two students will most likely go through the 
 recruitment process, others may at least contribute.  So its like GSoC 
 but the focus is not one project but an overview of general gentoo 
 development, and I will have to touch on lots of stuff outside of gentoo 
 per se, like how autotools and other build systems work.
 

This is a great idea, and is essentially the pay someone to recruit
approach taken to an extreme. I would be willing to pay for a class like
this (online or otherwise) if it meant that there were a clear set of
goals, which if met, meant that I'd become a developer.

Why can't something like this *be* the recruiting process? Put up a
syllabus. The wait to be noticed process is so vague as to be useless.

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On Mon, Dec 17, 2012 at 7:32 PM, Roy Bamford neddyseag...@gentoo.org wrote:
 Suppose the team in [1] above wrote the specification, who needs to
 agree it?

 The council, the trustees, the body of devs ... some combination of
 that list.  All in all, producing an agreed specification for a website
 it probably as much work as actually building the site. It could easily
 be as much work as the PMS.

I don't think the whole body of devs has to agree to it. The trustees
definitely have to, since they have to fork over the cash. The council
probably also makes sense.

I think producing a specification for the website would be much work,
but work to which most of us would probably more suited than the work
of actually building the site. Building a good site is a lot of hard
work, too.

Is the website team actually active these days?

Cheers,

Dirkjan

Re: [gentoo-dev] College Course in Gentoo Development

2012-12-17 Thread Michael Hampicke

Am 17.12.2012 17:02, schrieb Rick Zero_Chaos Farina:
 On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
 Hi everyone,
 
 Give the talk on the list about attracting devs, I've should probably
 mention that I'm teaching a College Course on Gentoo Development next
 semester.  I know two students will most likely go through the
 recruitment process, others may at least contribute.  So its like GSoC
 but the focus is not one project but an overview of general gentoo
 development, and I will have to touch on lots of stuff outside of gentoo
 per se, like how autotools and other build systems work.
 
 So what should I teach?  Here's what I've got off the top of my head:
 
 1. Open source communities and Gentoo's internal political structure.
 
 2. Building a gentoo system, ie the handbook.  Gentoo as metadistribution.
 
 3. Delivering the goods: code - build system - portage - compiled
 goodies - working system
 
 4. How to work with gnu autotools.  Writing a build system.
 
 5.  How to write ebuilds, ie the dev manual.  How to work with cvs and git.
 
 6. Arches, arch testing.  Profiles.
 
 7. Building stages.  Catalyst.
 
 Somewhere in there I'll squeeze in Gentoo's alt factor: alternative c
 libs, alternative compilers and hardening, alternative kernels, prefixes.
 
 Please comment.  If it gets systematized enough, it can be a guide to
 future devs too.  Everything will be creative commons.
 
 Can I take this course online? Will the lectures be recorded?
 
 -ZC
 

I would be interested in this course as well :)

Re: [gentoo-dev] Re: Attracting developers (Re: Packages up for grabs...)

2012-12-17 Thread Peter Stuge

Duncan wrote:
 Apparently, IRC is a hard requirement.  At least the one final 
 evaluation must be done on IRC.

I understand why online communication is not everyone's prefered format.

I guess that the IRC part of the recruitment is not very formal, I
don't know as I haven't seen one, but in general I would expect that
it is simply a lightweight substitute for going to the pub and having
a chat in person, or talking on the phone to a friend.

I further guess that if you would prefer a chat with someone over the
phone then that could work just as well.

That said, I find that IRC is a useful tool for developers sometimes.
It's not mandatory by any means, and sometimes it's just a huge time
sink, and a little bit like filing bugs it isn't mandatory, but it
*can* be useful.


//Peter

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

On Mon, Dec 17, 2012 at 4:35 PM, Dirkjan Ochtman d...@gentoo.org wrote:
 On Mon, Dec 17, 2012 at 7:32 PM, Roy Bamford neddyseag...@gentoo.org wrote:
 Suppose the team in [1] above wrote the specification, who needs to
 agree it?


 I don't think the whole body of devs has to agree to it. The trustees
 definitely have to, since they have to fork over the cash. The council
 probably also makes sense.

Most logical thing is for the website team to get together and suggest
something, and then can work with the rest of the devs to gather input
as they see fit.  They can then put together a proposal for the
trustees.  Generally speaking as long as the website team has done
reasonable due diligence we aren't going to shoot holes in it.  That
would be about as productive as getting into a debate with the infra
team about how many data centers we want to have hardware in, etc.

Those who care should step up and join the appropriate project.  Those
who don't care that much should try not to get in the way in the name
of offering advice.

The biggest thing the trustees are likely to help with are ensuring
we've done due diligence around bids/etc.  Generally funding requests
involve all of a few emails and a vote - this should be no different
as we shouldn't be contemplating some $20k development project.


 Is the website team actually active these days?

I think that should be our focus.  Rather than just going back and
forth about all the wonderful things that could happen if somebody
actually cared about our website, we need people to actually step up
and be willing to do something about it.

Our website is at least functional for the moment.  It certainly could
be better, but it takes more than dollars to make that happen.  We
can't pay people to care.

Rich

Re: [gentoo-dev] Re: eudev project announcement

2012-12-17 Thread William Hubbs

On Mon, Dec 17, 2012 at 01:31:59PM -0800, Greg KH wrote:
 On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
  Olav Vitters o...@vitters.nl wrote:
  
  On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
   As I said in an earlier email, Lennart Poettering claims that it does
   not work. We are discussing some of the things necessary to make it
  work.
  
  Just to repeat:
  In this thread it was claimed that a separate /usr is not supported by
  systemd/udev.
  
  A case which works with latest systemd on various distributions. I
  checked with upstream (not Lennart), and they confirmed it works. I can
  wait for Lennart to say the same, but really not needed.
  
  I assume this will again turn into a but I meant something else.
  
  Olav.
  
  Lennart has stated that he considers a seperate /usr without init* broken.
 
 Yes, as do I, and so do a lot of other developers.
 
 But that is a system configuration issue, not a systemd issue, please
 don't confuse the two.
 
  This has worked correctly in the past.
 
 Define past please.
 
 Note, it's still broken, I have yet to see any upstream fixes to resolve
 all of the issues that are involved here with fixing this up.
 
 Yes, as always, for some subset of users, you can be lucky and it will
 work for them, but those systems are getting rarer and rarer these days,
 as the rest of upstream (not systemd here) are moving on and not doing
 anything to change their behavior for this topic.
 
  The direction udev development is going, according to Lennart, is to
  make that impossible and he refuses to fix this regression.
 
 Again, this has NOTHING to do with udev or systemd, as has been pointed
 out numerous times.  I understand your _wish_ that it would have
 something to do with it, but that will not change the facts, sorry.
 
  I am really happy with this project and intend on testing it once
  requests for this appear in the eudev mailing list.
 
 Good luck, the root problems still remain, and nothing that eudev ever
 does can resolve that, sorry.
 
 Can this topic finally be put to rest please?  There is a whole web page
 devoted to this topic, why do people blindly ignore it?
 
 This is a very good question.

 Again, a separate /usr without an initrd has NOTHING to do with systemd
 or udev, with the minor exception that Gentoo's packaging of those
 programs _might_ have an issue, but that is Gentoo's issue, NOT
 upstream's issue.
 
 If anyone involved with eudev, or is involved with the Gentoo Council
 thinks that the previous paragraph is incorrect, they are flat out
 wrong.
 
This all started with the April 2012 council meeting when it was pushed
through that separate /usr without an initramfs is a supported
configuration, so yes, the previous council started this issue.

Also, yes, eudev believes they will be able to fix it.

I am another one who has been pointing out how this is wrong multiple
times but my statements about it are falling on deaf ears.

William



pgp2bisqyiN7y.pgp
Description: PGP signature

Re: [gentoo-dev] College Course in Gentoo Development


On 12/17/2012 01:11 PM, Maxim Kammerer wrote:

On Mon, Dec 17, 2012 at 5:32 PM, Anthony G. Basilebluen...@gentoo.org  wrote:

Please comment.  If it gets systematized enough, it can be a guide to future
devs too.

Hi, what is the level of the students, what are the prerequisites
(i.e., have they already seen some systems programming using C?), and
how many weekly hours? Have you already designed some assignments? I
can think of the following:

1. Create a small makefile-based project with a separate shared
library, an executable, and a man page. Determine run-time and
build-time dependencies. Then convert to autotools, update
dependencies. Do it all on GitHub, with a separate branch for
converting to autotools.


Its a second year course so they've had some programming in Java but no 
serious C.  It meets 3 hours a week but I expect about 6 hours more per 
week in assignments.


There is some overlap with other stuff I've taught: Makefiles, 
autotools, git and shared objects.  I did my lecture materials in git 
and then ran a git rebase -i in class and redid the commits showing them 
what happened on each point.  You can see some of that stuff here -


practice with git - 
http://tweedledum.dyc.edu/gitweb/?p=model-git.git;a=summary


how autotools works - 
http://tweedledum.dyc.edu/gitweb/?p=autotools.git;a=summary


how Makefiles work - 
http://tweedledum.dyc.edu/gitweb/?p=makefile.git;a=summary


how shared objects work - 
http://tweedledum.dyc.edu/gitweb/?p=shared-objects.git;a=summary




2. Write an ebuild for the project above, maintained in an overlay
(also on GitHub), with sources fetched from GitHub. Add some small
patch to configure.ac in the ebuild. Add USE flags. Add make check
support to the build system, test with FEATURES=test. Many
ebuild-related tasks can be easily added (e.g. installing init.d
scripts).


This would be totally new to them but I agree that's a good idea.  I 
don't know about GitHub.  Can you delete projects from it when you're 
done because I don't want to polute GitHub with lots of unpolished stuff.




3. Take an old-version ebuild for a project with a known bug, fetch
the relevant git tag, and bisect to find the bug. Prepare a patch,
describe patch submission process.
Hmm ... I didn't think of this but I could do that with the kernel on 
virtual machines.




Wrt. subjects covered, will you cover sandboxing, installing to image
vs. merging to live system, etc.? I would expect students to like such
stuff.

At some point I would have to cover that.  Like when I got over the 
phases of emerging, stepping through them with ebuild.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Re: eudev project announcement