Re: [gentoo-dev] Gentoo Hangouts

[Diego Elio Pettenò]

On Mon, Jun 24, 2013 at 5:52 AM, Norman Rieß  wrote:

> I do not see the benefit either, it seems like that kind of thing the PR
> department would come up with, which noone does actually like doing and
> everyone is glad when it's over and can go back to work.
>

I honestly wonder if Pavlos ever tried having regular meetings over VC.

I've worked on a VC system most of last year and I now go through regular
conferences... it's barely okay from a work point of view, it takes lots of
time to organize so you don't want to do that every single day for sure.

And unlike IRC meetings, you can cannot multitask, say making your dinner
while discussing this or that feature.

A VC is a full commitment, and its attractiveness is often much higher
_before_ you use it..

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

Re: [gentoo-dev] Introduce global dmalloc USE flag?

[Gilles Dartiguelongue]

Le samedi 22 juin 2013 à 15:48 +0800, Dennis Lan (dlan) a écrit :
> On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On 13/06/13 01:05 AM, Michał Górny wrote:
> >> Dnia 2013-06-13, o godz. 09:35:54 "Dennis Lan (dlan)"
> >>  napisał(a):
> >>
> >>> also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7)
> >>> net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd
> >>>
> >>> use dmalloc but controlled under USE=debug
> >>
> >> Do those use USE=debug solely for dmalloc or does it imply other
> >> stuff? Therefore: will it be possible to use USE=dmalloc in those
> >> packages?
> 
> HI mgorny, as I look into those ebuilds
> all of them use the USE=debug flag for dmalloc only, not for other
> debugging control
> so, as your second question, of course it's possible to switch to USE=dmalloc
> 
> >>
> >
> > and to follow up, if we assume that USE="debug" does more than just
> > build the package against the dmalloc lib (which is likely), is there
> 
> Yes, if this case exist.. then the separation would be good
> 
> 
> > any particular benefit to USE="debug -dmalloc" ?  Or USE="dmalloc
> > - -debug" ?
> >
> 
> I'm not sure, probably the befefits would be that we can have more
> accurate/explicit control,
> USE="dmalloc" is for debugging memory usage stuff (allocation, free,
> fence-post overwritten control)
> and USE=debug for other stuff?
> 
> This is a slightly improvement, but I'm also totally fine to keep
> current state as it is.. no big deal

Reading this thread, looks to me like these dmalloc USE should be moved
to debug, unless it has no runtime impact on usual speed, etc.

-- 
Gilles Dartiguelongue 
Gentoo

Re: [gentoo-dev] Introduce global dmalloc USE flag?

[Samuli Suominen]

On 24/06/13 11:54, Gilles Dartiguelongue wrote:

Le samedi 22 juin 2013 à 15:48 +0800, Dennis Lan (dlan) a écrit :

On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/13 01:05 AM, Michał Górny wrote:

Dnia 2013-06-13, o godz. 09:35:54 "Dennis Lan (dlan)"
 napisał(a):


also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7)
net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd

use dmalloc but controlled under USE=debug


Do those use USE=debug solely for dmalloc or does it imply other
stuff? Therefore: will it be possible to use USE=dmalloc in those
packages?


HI mgorny, as I look into those ebuilds
all of them use the USE=debug flag for dmalloc only, not for other
debugging control
so, as your second question, of course it's possible to switch to USE=dmalloc





and to follow up, if we assume that USE="debug" does more than just
build the package against the dmalloc lib (which is likely), is there


Yes, if this case exist.. then the separation would be good



any particular benefit to USE="debug -dmalloc" ?  Or USE="dmalloc
- -debug" ?



I'm not sure, probably the befefits would be that we can have more
accurate/explicit control,
USE="dmalloc" is for debugging memory usage stuff (allocation, free,
fence-post overwritten control)
and USE=debug for other stuff?

This is a slightly improvement, but I'm also totally fine to keep
current state as it is.. no big deal


Reading this thread, looks to me like these dmalloc USE should be moved
to debug, unless it has no runtime impact on usual speed, etc.



It does. In most often cases building against dmalloc makes the 
application/library completely unusable, and building it against dmalloc 
is intended for the developer of the application.

Separated USE=dmalloc is the only sane way to approach it.

Re: [gentoo-dev] Gentoo Hangouts

[Alex Legler]

On 24.06.2013 08:31, Alexander Berntsen wrote:
> I realise that by "Gentoo is and will remain Free Software"[0], what
> is meant is the distribution and the source code. However, I think it
> would be a bad example to use proprietary software for development or
> communication.

So we shouldn't be present on Google+ at all?

> 
> 
> [0]  
> 

-- 
Alex Legler 
Gentoo Security/Ruby/Infrastructure



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Hangouts

[Chí-Thanh Christopher Nguyễn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alex Legler schrieb:
> On 24.06.2013 08:31, Alexander Berntsen wrote:
>> I realise that by "Gentoo is and will remain Free Software"[0], what 
>> is meant is the distribution and the source code. However, I think it 
>> would be a bad example to use proprietary software for development or 
>> communication.
> 
> So we shouldn't be present on Google+ at all?

Last I checked, you can use Google+ with a web browser. For hangouts, you
need to install the proprietary google-talkplugin (I don't think a usable
free replacement exists yet).

Best regards,
Chí-Thanh Christopher Nguyễn

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

iEYEARECAAYFAlHIGREACgkQ+gvH2voEPRALlQCeN+dVNMQnvKjo/fU1OUXofMoj
dmwAnikYJMy2nULL9hRuLWA3CfOBpDk2
=PWOm
-END PGP SIGNATURE-

Re: [gentoo-dev] Gentoo Hangouts

[Alex Legler]

On 24.06.2013 12:01, Chí-Thanh Christopher Nguyễn wrote:
> Alex Legler schrieb:
>> On 24.06.2013 08:31, Alexander Berntsen wrote:
>>> I realise that by "Gentoo is and will remain Free Software"[0], what 
>>> is meant is the distribution and the source code. However, I think it 
>>> would be a bad example to use proprietary software for development or 
>>> communication.
> 
>> So we shouldn't be present on Google+ at all?
> 
> Last I checked,

…and I check every day!

> you can use Google+ with a web browser. For hangouts, you
> need to install the proprietary google-talkplugin (I don't think a usable
> free replacement exists yet).

Sure, but the (web-accessible) platform itself is proprietary as well.

I don't see it as much of an issue to use this channel—as long as it
isn't the only one we offer.

> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 

-- 
Alex Legler 
Gentoo Security/Ruby/Infrastructure



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo Hangouts

[Pavlos Ratis]

On Mon, Jun 24, 2013 at 11:14 AM, Diego Elio Pettenò
 wrote:
>
> On Mon, Jun 24, 2013 at 5:52 AM, Norman Rieß  wrote:
>>
>> I do not see the benefit either, it seems like that kind of thing the PR
>> department would come up with, which noone does actually like doing and
>> everyone is glad when it's over and can go back to work.
>
>
> I honestly wonder if Pavlos ever tried having regular meetings over VC.
>
> I've worked on a VC system most of last year and I now go through regular
> conferences... it's barely okay from a work point of view, it takes lots of
> time to organize so you don't want to do that every single day for sure.
>
> And unlike IRC meetings, you can cannot multitask, say making your dinner
> while discussing this or that feature.
>
> A VC is a full commitment, and its attractiveness is often much higher
> _before_ you use it..
>
>
> Diego Elio Pettenò — Flameeyes
> flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Maybe you misunderstood my proposal, I totally agree with you about
IRC meetings. I didn't propose video calls as a full replacement for
IRC meetings. Also, I've never said to use video calls every single
day.
These team video calls would be good to exist for different reasons.
These video calls are going to promote Gentoo, our team efforts and
could be useful to our users and those who want to contribute. As I
said before, it is optional, a team maybe choose not to do any video
call, a team could do *only one* video call and stop or a team could
do frequent video calls. It's up to the team to decide.

Re: [gentoo-dev] Introduce global dmalloc USE flag?

[Gilles Dartiguelongue]

Le lundi 24 juin 2013 à 12:05 +0300, Samuli Suominen a écrit :
> On 24/06/13 11:54, Gilles Dartiguelongue wrote:
> > Le samedi 22 juin 2013 à 15:48 +0800, Dennis Lan (dlan) a écrit :
> >> On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius  wrote:
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> On 13/06/13 01:05 AM, Michał Górny wrote:
>  Dnia 2013-06-13, o godz. 09:35:54 "Dennis Lan (dlan)"
>   napisał(a):
> 
> > also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7)
> > net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd
> >
> > use dmalloc but controlled under USE=debug
> 
>  Do those use USE=debug solely for dmalloc or does it imply other
>  stuff? Therefore: will it be possible to use USE=dmalloc in those
>  packages?
> >>
> >> HI mgorny, as I look into those ebuilds
> >> all of them use the USE=debug flag for dmalloc only, not for other
> >> debugging control
> >> so, as your second question, of course it's possible to switch to 
> >> USE=dmalloc
> >>
> 
> >>>
> >>> and to follow up, if we assume that USE="debug" does more than just
> >>> build the package against the dmalloc lib (which is likely), is there
> >>
> >> Yes, if this case exist.. then the separation would be good
> >>
> >>
> >>> any particular benefit to USE="debug -dmalloc" ?  Or USE="dmalloc
> >>> - -debug" ?
> >>>
> >>
> >> I'm not sure, probably the befefits would be that we can have more
> >> accurate/explicit control,
> >> USE="dmalloc" is for debugging memory usage stuff (allocation, free,
> >> fence-post overwritten control)
> >> and USE=debug for other stuff?
> >>
> >> This is a slightly improvement, but I'm also totally fine to keep
> >> current state as it is.. no big deal
> >
> > Reading this thread, looks to me like these dmalloc USE should be moved
> > to debug, unless it has no runtime impact on usual speed, etc.
> >
> 
> It does. In most often cases building against dmalloc makes the 
> application/library completely unusable, and building it against dmalloc 
> is intended for the developer of the application.
> Separated USE=dmalloc is the only sane way to approach it.

To be clear, the justification of USE=dmalloc being separated from
USE=debug is that it is so "intrusive" than anyone excepts a developer
would find it too cumbersome to attempt to debug a problem with the
application ?

If that is the case, maybe the USE flag description should mention that
so it is not enabled lightly.

-- 
Gilles Dartiguelongue 
Gentoo

Re: [gentoo-dev] Gentoo Hangouts

[Diego Elio Pettenò]

Pavlos, I understand what you mean, I'm just saying that organizing a real
video conference takes its toil. And just opening a webcam and talking is
just going to give an amateurish feeling that could be more detrimental
than not.

Can you please tell us if you have _any_ experience at all with VCing or
just thought that it looks cool?

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


On Mon, Jun 24, 2013 at 11:24 AM, Pavlos Ratis  wrote:

> On Mon, Jun 24, 2013 at 11:14 AM, Diego Elio Pettenò
>  wrote:
> >
> > On Mon, Jun 24, 2013 at 5:52 AM, Norman Rieß 
> wrote:
> >>
> >> I do not see the benefit either, it seems like that kind of thing the PR
> >> department would come up with, which noone does actually like doing and
> >> everyone is glad when it's over and can go back to work.
> >
> >
> > I honestly wonder if Pavlos ever tried having regular meetings over VC.
> >
> > I've worked on a VC system most of last year and I now go through regular
> > conferences... it's barely okay from a work point of view, it takes lots
> of
> > time to organize so you don't want to do that every single day for sure.
> >
> > And unlike IRC meetings, you can cannot multitask, say making your dinner
> > while discussing this or that feature.
> >
> > A VC is a full commitment, and its attractiveness is often much higher
> > _before_ you use it..
> >
> >
> > Diego Elio Pettenò — Flameeyes
> > flamee...@flameeyes.eu — http://blog.flameeyes.eu/
>
> Maybe you misunderstood my proposal, I totally agree with you about
> IRC meetings. I didn't propose video calls as a full replacement for
> IRC meetings. Also, I've never said to use video calls every single
> day.
> These team video calls would be good to exist for different reasons.
> These video calls are going to promote Gentoo, our team efforts and
> could be useful to our users and those who want to contribute. As I
> said before, it is optional, a team maybe choose not to do any video
> call, a team could do *only one* video call and stop or a team could
> do frequent video calls. It's up to the team to decide.
>
>

Re: [gentoo-dev] Introduce global dmalloc USE flag?

[Diego Elio Pettenò]

On Mon, Jun 24, 2013 at 11:37 AM, Gilles Dartiguelongue wrote:

> To be clear, the justification of USE=dmalloc being separated from
> USE=debug is that it is so "intrusive" than anyone excepts a developer
> would find it too cumbersome to attempt to debug a problem with the
> application ?
>

I think we already got a number of packages where that holds true. It was
one of the reasons why I did my best to make sure people understand that
debug symbols and nostrip should *not* be conflated with USE=debug.

If I'm not mistaken, app-editors/nano[debug] is hardly usable.

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

[gentoo-dev] Re: Gentoo Hangouts

[Michael Palimaka]

On 24/06/2013 07:30, Pavlos Ratis wrote:

That's why I'd like to propose Gentoo Hangouts. Gentoo Hangouts will
be Google+  video Hangouts(video calls) held by teams or developers
independent of a team. The main goal is to have the teams introduce
themselves and discuss about different issues in their Gentoo-related
projects.


Thanks for taking the time and initiative to work on something new, I am 
sure it will prove interesting.


It is the response that confuses me - I don't understand why everyone is 
rushing to shut it down before it even begins. For those that are not 
interested in the idea of a video hangout, just don't use it and move on 
- simple.

Re: [gentoo-dev] Re: Gentoo Hangouts

[Markos Chandras]

On 24 June 2013 11:54, Michael Palimaka  wrote:
> On 24/06/2013 07:30, Pavlos Ratis wrote:
>>
>> That's why I'd like to propose Gentoo Hangouts. Gentoo Hangouts will
>> be Google+  video Hangouts(video calls) held by teams or developers
>> independent of a team. The main goal is to have the teams introduce
>> themselves and discuss about different issues in their Gentoo-related
>> projects.
>
>
> Thanks for taking the time and initiative to work on something new, I am
> sure it will prove interesting.
>
> It is the response that confuses me - I don't understand why everyone is
> rushing to shut it down before it even begins. For those that are not
> interested in the idea of a video hangout, just don't use it and move on -
> simple.
>
>

I like the idea. It might help bring developers and users closer.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Gentoo Hangouts

[Rich Freeman]

On Mon, Jun 24, 2013 at 4:14 AM, Diego Elio Pettenò
 wrote:
> And unlike IRC meetings, you can cannot multitask, say making your dinner
> while discussing this or that feature.

Honestly, that bit is a two-edged sword.  I was just musing with the
Trustees yesterday how it seems the meetings take forever to really
just hit a few items.  I think much is due to distraction (and I'm
probably as guilty as anyone).  That said, it is also helpful that I
can still attend family functions or whatever and connect via mobile
to a meeting - I'd definitely need to excuse myself if we were using
audio/video.

In my experience well-done videoconf works well for meetings, though I
haven't tried Google Hangouts for anything serious so I can't vouch
for that - low latency would be the most important attribute so that
people aren't stepping all over each other.  It does require focus to
come across professionally.  Since not coming across professionally in
my workplace is just an invitation to get fired that isn't really a
problem.  Now, language CAN be a problem in audio or videoconf -
generally in my workplace people speak English reasonably well, but
I've seen that become a challenge in anything other than written or
non-1:1 conversation.

I think our main meeting challenge boils down to timezones and being
international.  I can't say I'd want to have an international
videoconf at work because inevitably it would mean having to dress up
and be in a room that looked nice at 6AM or 10PM.  For gentoo that
matters slightly less, but only to a degree.  The bigger issue is that
meetings end up being inconvenient for many just due to their timing -
maybe one person lucks out and has it at the start/end of the day, but
for me they end up being middle-of-the-afternoon which has a tendency
to kill the day if on a weekend, and if on a weekday could conflict
with work.

However, I think it is still a good idea.  Perhaps they shouldn't be
used as a regular way to meet, but on occasion to try to re-capture
the personal element.  I for one have never met another Gentoo
developer in the flesh - and only a few users.  It would be nice to
actually talk with one...  :)

Rich

Re: [gentoo-dev] Re: Gentoo Hangouts

[Mike Pagano]

On Mon, Jun 24, 2013 at 12:04:04PM +0100, Markos Chandras wrote:
> On 24 June 2013 11:54, Michael Palimaka  wrote:
> > On 24/06/2013 07:30, Pavlos Ratis wrote:
> >>
> >> That's why I'd like to propose Gentoo Hangouts. Gentoo Hangouts will
> >> be Google+  video Hangouts(video calls) held by teams or developers
> >> independent of a team. The main goal is to have the teams introduce
> >> themselves and discuss about different issues in their Gentoo-related
> >> projects.
> >
> >
> > Thanks for taking the time and initiative to work on something new, I am
> > sure it will prove interesting.
> >
> > It is the response that confuses me - I don't understand why everyone is
> > rushing to shut it down before it even begins. For those that are not
> > interested in the idea of a video hangout, just don't use it and move on -
> > simple.
> >
> >
> 
> I like the idea. It might help bring developers and users closer.
> 
> --

I can't see the harm, and people who don't have the time, interest or
social skills can certainly not join.  

I worked from a home office for 7 years and used this all the time.
Sometimes it helps to realize that the people on the other end of the
wire are just that: people.

I've seen behaviors change among team members for the better. Plus,
maybe I can learn how to pronouce more than half of your names. :)

Re: [gentoo-dev] Gentoo Hangouts

[William Hubbs]

On Mon, Jun 24, 2013 at 09:14:44AM +0100, Diego Elio Pettenò wrote:
> A VC is a full commitment, and its attractiveness is often much higher
> _before_ you use it..

Agreed.

I have found that if I am on a voice chat with someone, say on skype, it
requires my full attention, especially since I use assistive technology
to access my computer.

I use synthetic speech to tell me what is happening on screen and it is
difficult at times to keep up with that and the voice conversation. This
is even more true in a group voice conference.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Last time touched bugs by year

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/06/13 03:53 PM, Alex Xu wrote:
> On 21/06/13 03:27 PM, Sergey Popov wrote:
>> 21.06.2013 23:22, Sergey Popov пишет:
>>> 2) package has dead upstream, does not build with current 
>>> gcc/glibc/binutils/whatever and can not be fixed - bug is
>>> closed as OBSOLETE.
>>> 
>> 
>> Of course i am talking about long-standing bugs, that assigned
>> to maintainer-wanted@. That's why OBSOLETE seems to be a better
>> decision, but WONTFIX is reasonable too :-)
>> 
> nobody needs it: OBSOLETE it doesn't work: CANTFIX
> 

For many m-w bugs, its existence in overlays like sunrise still apply
here to whether or not the bug should be left active and valid, tho.
I think it might still be beneficial to filter out the m-w bugs that
are tagged with InOverlay -- or at least, not expect them to be
resolved or closed unless the sunrise dev's take care of this when
they drop the package.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlHIYa4ACgkQ2ugaI38ACPADuQD/RSPQY3rmzp9tjVURHZFNgsut
04MIae+7g/S9AcG64e8BAKmqmIBHeJv0+qDDfs5gZA9xoEJBiRmxDaFrdLnmBDZS
=Yyyi
-END PGP SIGNATURE-

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Tom Wijsman posted on Sun, 16 Jun 2013 23:24:27 +0200 as excerpted:

> On Sun, 16 Jun 2013 19:33:53 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> 
>> TL;DR: SSDs help. =:^)
> 
> TL;DR: SSDs help, but they don't solve the underlying problem. =:-(

Well, there's the long-term fix to the underlying problem, and there's 
coping strategies to help with where things are at now.  I was simply 
saying that an SSD helps a LOT in dealing with the inefficiencies of the 
current code.  See the "quite apart... practical question of ... dealing 
with the problem /now/" bit quoted below.

> I have one; it's great to help make my boot short, but it isn't really a
> great improvement for the Portage tree. Better I/O isn't a solution to
> computational complexity; it doesn't deal with the CPU bottleneck.

But here, agreed with ciaranm, the cpu's not the bottleneck, at least not 
from cold-cache.  It doesn't even up the cpu clocking from minimum as 
it's mostly filesystem access.  Once the cache is warm, then yes, it ups 
the CPU speed and I see the single-core behavior you mention, but cold-
cache, no way; it's I/O bound.

And with an ssd, the portage tree update (the syncs both of gentoo and 
the overlays) went from a /crawling/ console scroll, to scrolling so fast 
I can't read it.

>> Quite apart from the theory and question of making the existing code
>> faster vs. a new from-scratch implementation, there's the practical
>> question of what options one can actually use to deal with the problem
>> /now/.
> 
> Don't rush it: Do you know the problem well? Does the solution properly
> deal with it? Is it still usable some months / years from now?

Not necessarily.  But first we must /get/ to some months / years from 
now, and that's a lot easier if the best is made of the current 
situation, while a long term fix is being developed.

>> FWIW, one solution (particularly for folks who don't claim to have
>> reasonable coding skills and thus have limited options in that regard)
>> is to throw hardware at the problem.
> 
> Improvements in algorithmic complexity (exponential) are much bigger
> than improvements you can achieve by buying new hardware (linear).

Same song different verse.  Fixing the algorithmic complexity is fine and 
certainly a good idea longer term, but it's not something I can use at my 
next update.  Throwing hardware at the problem is usable now.

>> ---
>> [1] I'm running ntp and the initial ntp-client connection and time sync
>> takes ~12 seconds a lot of the time, just over the initial 10 seconds
>> down, 50 to go, trigger on openrc's 1-minute timeout.
> 
> Why do you make your boot wait for NTP to sync its time?

Well, ntpd is waiting for the initial step so it doesn't have to slew so 
hard for so long if the clock's multiple seconds off.

And ntpd is in my default runlevel, with a few local service tasks that 
are after * and need a good clock time anyway, so...

> How could hardware make this time sync go any faster?

Which is what I said, that as a practical matter, my boot didn't speed up 
much /because/ I'm running (and waiting for) the ntp-client time-
stepper.  Thus, I'd not /expect/ a hardware update (unless it's to a more 
direct net connection) to help much.

>> [2] ... SNIP ... runs ~1 hour ... SNIP ...
> 
> Sounds great, but the same thing could run in much less time. I have
> worse hardware, and it doesn't take much longer than yours do; so, I
> don't really see the benefits new hardware bring to the table. And that
> HDD to SSD change, that's really a once in a lifetime flood.

I expect I'm more particular than most about checking changelogs.  I 
certainly don't read them all, but if there's a revision-bump for 
instance, I like to see what the gentoo devs considered important enough 
to do a revision bump.  And I religiously check portage logs, selecting 
mentioned bug numbers probably about half the time, which pops up a menu 
with a gentoo bug search on the number, from which I check the bug 
details and sometimes the actual git commit code.  For all my overlays I 
check the git whatchanged logs, and I have a helper script that lets me 
fetch and then check git whatchanged for a number of my live packages, 
including openrc (where I switched to live-git precisely /because/ I was 
following it closely enough to find the git whatchanged logs useful, both 
for general information and for troubleshooting when something went wrong 
-- release versions simply didn't have enough resolution, too many things 
changing in each openrc release to easily track down problems and file 
bugs as appropriate), as well.

And you're probably not rebuilding well over a hundred live-packages 
(thank $DEITY and the devs in question for ccache!) at every update, in 
addition to the usual (deep) @world version-bump and newuse updates, are 
you?

Of course maybe you are, but I did specify that, and I didn't see 
anything in your comments indicating anything like an apples to apples 
comparision.

>> [3] A

Re: [gentoo-dev] Gentoo Hangouts

[Tobias Klausmann]

Hi! 

On Mon, 24 Jun 2013, Diego Elio Pettenò wrote:
> I've worked on a VC system most of last year and I now go
> through regular conferences... it's barely okay from a work
> point of view, it takes lots of time to organize so you don't
> want to do that every single day for sure.

It depends how you run it. We have teams having a video thing
open during the day with there geographically-diverse other team
members and it works well for them. For those teams, it also
improves cohesion. Geographically-diverse teams always have to
actively fight the us-vs-them vibe that seems to be fundamental
human nature. Aforementioned video link is part of that.

> And unlike IRC meetings, you can cannot multitask, say making
> your dinner while discussing this or that feature.

As others have pointed out, this is a double edged sword:
Sometimes, having less distraction (or getting away with less
distraction) is a Good Thing.

> A VC is a full commitment, and its attractiveness is often much
> higher _before_ you use it..

This does not hold true for me. I'd never used VC before joining
my current company, and I love it -- iff the alternative is not
meeting at all or text-only. As I pointed out above, it is
crucial for team cohesion.

The basic question is: why do you do it? what do you want to get
out of it? If you just want to have a get-together, like going to
the pub together for a few beers, all prep it needs is finding a
time. And beer, maybe.

If you want to have a distincly productive meeting, you need an
agenda/goals and someone to _run_ the meeeting. But that is true
of IRC meetings, too. 

About the only thing that IRC meetings are invariably better at,
is logging. Note, however, that logging is no replacment for
agendas or summarizing the outcome of the meeting.

Regards,
Tobias

Re: [gentoo-dev] Gentoo Hangouts

[Diego Elio Pettenò]

On Mon, Jun 24, 2013 at 4:43 PM, Tobias Klausmann wrote:
>
> It depends how you run it. We have teams having a video thing
> open during the day with there geographically-diverse other team
> members and it works well for them. For those teams, it also
> improves cohesion. Geographically-diverse teams always have to
> actively fight the us-vs-them vibe that seems to be fundamental
> human nature. Aforementioned video link is part of that.
>

Sure, but first of all these are private meetings, and not public ones.
Even more, they are meetings private to the company, and not even with
customers. You can tell that the response to a public vs private meeting is
definitely different. I've witnessed before people trying go show off even
more just because a camera is involved, which can be obnoxious, in my
opinion.


> > And unlike IRC meetings, you can cannot multitask, say making
> > your dinner while discussing this or that feature.
>
> As others have pointed out, this is a double edged sword:
> Sometimes, having less distraction (or getting away with less
> distraction) is a Good Thing.
>

Yeah sure if you can afford it. One thing that people seem to miss is that
Gentoo is _not_ an employment. And while we'd like to keep professional
behaviour, the system of incentives and disincentives that work for an
employment position do not apply to organizations like Gentoo.


>
> > A VC is a full commitment, and its attractiveness is often much
> > higher _before_ you use it..
>
> This does not hold true for me. I'd never used VC before joining
> my current company, and I love it -- iff the alternative is not
> meeting at all or text-only. As I pointed out above, it is
> crucial for team cohesion.
>

Sure and in some ways it's a least worst option. On the other hand you and
I both know that it's not as easy as saying "okay let's all meet at 7" —
timezones, hardware issues, connection issues, you name it. We sidestep
most of these issues as the various problems have been ironed out before..
but to start doing "regular" hangouts between Gentoo teams? It's going to
involve lots of work.


> If you want to have a distincly productive meeting, you need an
> agenda/goals and someone to _run_ the meeeting. But that is true
> of IRC meetings, too.
>
> About the only thing that IRC meetings are invariably better at,
> is logging. Note, however, that logging is no replacment for
> agendas or summarizing the outcome of the meeting.
>

On the other hand, I would be _very_ much against using Hangouts for
anything that involves decision-making or explanation of future planning,
for the very reasons I originally pointed out:

 * they require too much time set aside (I can't even lurk a Hangout if I'm
cooking, or working, or my phone only knows what);
 * they are not for everyone (English is not universal as we'd wish it is —
if it wasn't for last year's experience, I wouldn't want speaking English
in public; William also pointed out another reason);
 * I don't expect a great signal to noise, not only at the beginning but
throughout: try to imagine an unmoderated IRC channel being spoken aloud,
then add a bunch of "can you hear/see me?" from every other participant,
the "what did you say? I can't understand you" and so on so forth.

Honestly, I see as much potential to cause further issues in a team as
there is to solve them.

Re: [gentoo-dev] Re: Gentoo Hangouts

[Sven Vermeulen]

On Mon, Jun 24, 2013 at 12:04:04PM +0100, Markos Chandras wrote:
> I like the idea. It might help bring developers and users closer.

Me too, if I can ever contribute to it, or help users with their Gentoo
(Hardened/SELinux/IMA/EVM/...) through it, I'll be happy to work with it.

Wkr,
  Sven Vermeulen

Re: [gentoo-dev] Re: Packages up for grabs

[Tom Wijsman]

On Mon, 24 Jun 2013 15:27:19 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> > I have one; it's great to help make my boot short, but it isn't
> > really a great improvement for the Portage tree. Better I/O isn't a
> > solution to computational complexity; it doesn't deal with the CPU
> > bottleneck.
> 
> But here, agreed with ciaranm, the cpu's not the bottleneck, at least
> not from cold-cache.  It doesn't even up the cpu clocking from
> minimum as it's mostly filesystem access.  Once the cache is warm,
> then yes, it ups the CPU speed and I see the single-core behavior you
> mention, but cold- cache, no way; it's I/O bound.
> 
> And with an ssd, the portage tree update (the syncs both of gentoo
> and the overlays) went from a /crawling/ console scroll, to scrolling
> so fast I can't read it.

We're not talking about the Portage tree update, but about the
dependency tree generation, which relies much more on the CPU than I/O.
A lot of loops inside loops inside loops, comparisons and more data
structure magic is going on; if this were optimized to be of a lower
complexity or be processed by multiple cores, this would speed up a lot.

Take a look at the profiler image and try to get a quick understanding
of the code; after following a few function calls, it will become clear.

Granted, I/O is still a part of the problem which is why I think caches
would help too; but from what I see the time / space complexity is just
too high, so you don't even have to deem this as CPU or I/O bound...

> >> Quite apart from the theory and question of making the existing
> >> code faster vs. a new from-scratch implementation, there's the
> >> practical question of what options one can actually use to deal
> >> with the problem /now/.
> > 
> > Don't rush it: Do you know the problem well? Does the solution
> > properly deal with it? Is it still usable some months / years from
> > now?
> 
> Not necessarily.  But first we must /get/ to some months / years from 
> now, and that's a lot easier if the best is made of the current 
> situation, while a long term fix is being developed.

True, we have make and use the most out of Portage as long as possible.

> >> FWIW, one solution (particularly for folks who don't claim to have
> >> reasonable coding skills and thus have limited options in that
> >> regard) is to throw hardware at the problem.
> > 
> > Improvements in algorithmic complexity (exponential) are much bigger
> > than improvements you can achieve by buying new hardware (linear).
> 
> Same song different verse.  Fixing the algorithmic complexity is fine
> and certainly a good idea longer term, but it's not something I can
> use at my next update.  Throwing hardware at the problem is usable
> now.

If you have the money; yes, that's an option.

Though I think a lot of people see Linux as something you don't need to
throw a lot of money at; it should run on low end systems, and that's
kind of the type of users we shouldn't just neglect going forward.

> >> [2] ... SNIP ... runs ~1 hour ... SNIP ...
> > 
> > Sounds great, but the same thing could run in much less time. I have
> > worse hardware, and it doesn't take much longer than yours do; so, I
> > don't really see the benefits new hardware bring to the table. And
> > that HDD to SSD change, that's really a once in a lifetime flood.
> 
> I expect I'm more particular than most about checking changelogs.  I 
> certainly don't read them all, but if there's a revision-bump for 
> instance, I like to see what the gentoo devs considered important
> enough to do a revision bump.  And I religiously check portage logs,
> selecting mentioned bug numbers probably about half the time, which
> pops up a menu with a gentoo bug search on the number, from which I
> check the bug details and sometimes the actual git commit code.  For
> all my overlays I check the git whatchanged logs, and I have a helper
> script that lets me fetch and then check git whatchanged for a number
> of my live packages, including openrc (where I switched to live-git
> precisely /because/ I was following it closely enough to find the git
> whatchanged logs useful, both for general information and for
> troubleshooting when something went wrong -- release versions simply
> didn't have enough resolution, too many things changing in each
> openrc release to easily track down problems and file bugs as
> appropriate), as well.

I stick more to releases and checking the changes for things where I
want to know the changes for; for the others, they either don't matter
or they shouldn't really hurt as a surprise. If there's something that
would really surprise me then I'd expect some news on that.

> And you're probably not rebuilding well over a hundred live-packages 
> (thank $DEITY and the devs in question for ccache!) at every update,
> in addition to the usual (deep) @world version-bump and newuse
> updates, are you?

Developers rebuild those to see upcoming breakage.

Apart from that, I don't use many - as

[gentoo-dev] Re: Re: eselect init

[Steven J. Long]

On Thu, Jun 20, 2013 at 03:48:29PM -0500, William Hubbs wrote:
> On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote:
> > Fabio Erculiani wrote:
> > > - only init is currently handled by eselect-init, which is now using a
> > > very small wrapper POSIX shell script to redirect the calls to the
> > > currently running init
> > 
> > How does say, switching inittab format, work under this setup?
> 
> I think this is a separate issue -- if busybox init's inittab is a
> different format than sysvinbb's inittab, it should also use a different
> file name, e.g. bb-inittab or something similar.
> 
> bb could fall back to inittab, but I think it should look for something
> liike bb-inittab first. That way eselect init wouldn't have to worry
> about it at all.

You're missing the point, because of your usual monomania for specific rather
than general use-cases. 'Say' meant it was an example.

I asked the question, because AFAICT from reading the code, the proposed 
approach
keeps an indication of the running init, from startup, and then traps every call
to that init, to check whether eselect has in the interim changed the symlink to
point elsewhere.

If einit instead simply checked whether there was a 'switchto' file at startup,
it would be able to handle the more general problem, as well as running more
efficiently and robustly, with no need to mess around with symlinks.

The complexity would then be in eselect confirming, eg that the 'to' init is
installed and configured, before setting the file for the next reboot. And
optionally in the switcher when starting the new init at boot, if it should
need anything tricky carried out, which might interact badly with a currently
running init.

That's a re-iteration of Duncan's idea, ofc.

I'm also curious as to how an initramfs fits into the schema, given that there
may be things that need to be done before pid 1 is started (or if not, I have 
nfc
what all the discussion about replacing the kernel mechanism was in aid of.)

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] repoman default

[Michael Sterrett]

repoman should default to the -I behavior: discuss.

Re: [gentoo-dev] repoman default

[Zac Medico]

On 06/24/2013 10:40 PM, Michael Sterrett wrote:
> repoman should default to the -I behavior: discuss.

Does it make sense to have with ebuilds in the tree with unsatisfiable
dependencies? If so, should we distinguish between conditional and
unconditional dependencies? Note that if the dependencies are
conditional, you can already use package.use.mask to suppress the
repoman warnings.
-- 
Thanks,
Zac

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Tom Wijsman posted on Tue, 25 Jun 2013 01:18:07 +0200 as excerpted:

> On Mon, 24 Jun 2013 15:27:19 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> 
>> Throwing hardware at the problem is usable now.
> 
> If you have the money; yes, that's an option.
> 
> Though I think a lot of people see Linux as something you don't need to
> throw a lot of money at; it should run on low end systems, and that's
> kind of the type of users we shouldn't just neglect going forward.

Well, let's be honest.  Anyone building packages on gentoo isn't likely 
to be doing it on a truly low-end system.  For general linux, yes, 
agreed, but that's what puppy linux and etc are for.  True there's the 
masochistic types that build natively on embedded or a decade plus old 
(and mid-level or lower then!) systems, but most folks with that sort of 
system either have a reasonable build server to build it on, or use a pre-
built binary distro.  And the masochistic types... well, if it takes an 
hour to get the prompt in an emerge --ask and another day or two to 
actually complete, that's simply more masochism for them to revel in. =:^P

Tho you /do/ have a point.

OTOH, some of us used to do MS or Apple or whatever and split our money 
between hardware and software.  Now we pay less for the software, but 
that doesn't mean we /spend/ significantly less on the machines; now it's 
mostly/all hardware.

I've often wondered why the hardware folks aren't all over Linux, given 
the more money available for hardware it can mean, and certainly /does/ 
mean here.

>> Truth is, I used to run a plain make -j (no number and no -l at all) on
>> my kernel builds, just to watch the system stress and then so elegantly
>> recover.  It's an amazing thing to watch, this Linux kernel thing and
>> how it deals with cpu oversaturation.  =:^)
> 
> If you have the memory to pull it off, which involves money again.

What was interesting was doing it without the (real) memory -- letting it 
go into swap and just queue up hundreds and hundreds of jobs as the make 
continued to generate more and more of them, faster than they could even 
fully initialize, particularly since they were packing into swap before 
they even had that chance.

And then with 500-600 jobs or more (custom kernel build, not all-yes/all-
mod config, or it'd likely have been 1200...) stacked up and gigs into 
swap, watch the system finally start to slowly unwind the tangle.  
Obviously the system wasn't usable for anything else during the worst of 
it, but it still rather fascinates me that the kernel scheduling and code 
quality in general is such that it can successfully do that and unwind it 
all, without crashing or whatever.  And the kernel build is one of the 
few projects that's /that/ incredibly parallel, without requiring /too/ 
much memory per individual job, to do it in the first place.

Actually, that's probably the flip side of my getting more conservative.  
The reason I /can/ get more conservative now is that I've enough cores 
and memory that it's actually reasonably practical to do so.  When you're 
always dumping cache and/or swapping anyway, no big deal to do so a bit 
more.  When you have a system big enough to avoid that while still 
getting reasonably large chunks of real work done, and you're no longer 
used to the compromise of /having/ to dump cache, suddenly you're a lot 
more sensitive to doing so at all!

>> Needlessly oversaturating the CPU (and RAM) only slows things down and
>> forces cache dump and swappage.
> 
> The trick is to set it a bit before the point of oversaturating; low
> enough so most packages don't oversaturize, it could be put more
> precisely for every package but that time is better spent elsewhere

Indeed. =:^)

> Not everyone is a sysadmin with a server; I'm just a student running a
> laptop bought some years ago, and I'm kind of the type that doesn't
> replace it while it still works fine otherwise. Maybe when I graduate...

Actually, I use "sysadmin" in the literal sense, the person taking the 
practical responsibility for deciding what goes on a system, when/if/what 
to upgrade (or not), with particular emphasis on RESPONSIBILITY, both for 
security and both keeping the system running and getting it back running 
again when it breaks.  Nothing in that says it has to be commercial, or 
part of some huge farm of systems.  For me, the person taking 
responsibility (or failing to take it) for updating that third-generation 
hand-me-down castoff system is as much of a sysadmin for that system, as 
the guy/gal with 100 or 1000 systems (s)he's responsible for.

My perspective has always been that if all those folks running virus 
infested junk out there actually took the sysadmin responsibility for the 
systems they're running seriously, the virus/malware issue would cease to 
be an issue at all.

Meanwhile, I'll admit my last system was rather better than average when 
I first set it up (dual socket original 3-digit Opteron, that whole 
spendi