[gentoo-dev] Lastrites: app-misc/gramps-3.4.9

[Kevin Simmons]

# Kevin Simmons <ke...@kblob.com> (11 Nov 2016)
# Is holding up removal of old versions of
# sci-geosciences/osm-gps-map.
# Removal in 30 days.
app-misc/gramps-3.4.9

[gentoo-dev] Mentor request

[Kevin Simmons]

Hello gentoo-dev,

In general, I could use a mentor I can ask questions of and get answers
from. I have been a tinkerer/user only of Gentoo in the past and am now
wanting to be more involved.

I have been using the Developer Guide for assistance.

But specifically for now...
I requested to fill the maintainer role needed for the app-misc/gramps
package as I use the software for my own needs and am fairly familiar
with it. I am now the maintainer of that package. I find I can use some
guidance in getting started. For instance, there is a bug to have
gramps-4.2.4 stable (it is ~amd64 ~x86 now).

I have been running gramps-4.2.4 OK on amd64, testing various components
and reports OK

To stabilize this package for amd64 and x86 it would also need to be
verified on x86. I suppose I could do that myself by creating an x86
virtual guest and testing or I should ask for assistance via a bug to
x86@.

Also, when I run 'repoman full' from the proposed ebuild directory I get
QA issues for  RDEPEND for dev-python/pyicu, which is also ~amd64. This
dependent package (and its dependencies) would need to be stable as
well.

When it comes time to commit (repoman commit), do I need any user access
set up before I commit?

Regards,
Kevin

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Kevin Zhao]

Hi Guys， We have finish compiling stage3 for ppc64  (little-endian).Here is
the link:

https://drive.google.com/file/d/0B2k84p6709AyTFlwLUF1WjlxUk0/view?usp=sharing
 Now we are going to build LiveCD using stage3.  Could you help to give
some demo or a guide for building LiveCD? That will help we a lot to make
effort.
Thanks ~


2015-09-27 3:16 GMT+08:00 Anthony G. Basile :

> On 9/24/15 8:23 AM, Leno Hou wrote:
>
>>
>>
>>   Again, please apply POWER8 Systems and join our work  :-)
>>   [1]: https://www.runabove.com/instances/ibm-power8.xml
>>   [2]: https://ptopenlab.com/cloudlabconsole/#/
>>   [3]: http://osuosl.org/services/powerdev/request_hosting
>>
>>
>> -Leno Hou
>>>
>>>
> I have applied to osuosl for an ibm power8 ppc64le node.  I've put myself
> down as the point-of-contact.  I asked for openstack gui access and will
> try to build a system using Leno's stage3.  I'm not sure what the env looks
> like right now, but i assume i'll have to boot off a cd image.  I'll use
> debians.  I guess I could be macho and try to build everything from
> scratch, cross compile a kernel and all, but   time.
>
> Has anyone tried qemu simulating ppc64le on amd64?  Lu I thought you said
> you tried on x86 and it didn't work.
>
>
>
> --
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
>
>

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

 
  How about uncommenting a line that does so. All you are buying into is
  a default setup.
 
 App authors don't ship configs like that though. Does apt ship a sudo
 config? Does anything?

Perhaps you missed my opening message on this topic, except it was in
your first reply.

__

I remember reading a while back that distros had some blunders in
writing secure sudoers files and so it was emptied. Is that true?

I still ascert that apps adding groups with NOPASSWD sudoers lines
perhaps even commented out by default in all or some cases is far
better than polkit for many reasons. Any counter argument can apply
to sudo too and rather easily.


 The nice thing about (really dbus, not so much polkit per se) is that
 I can offer a nice API for applications that is not command line
 based. No parsing strings, no 'oh this tool writes to stderr, that one
 writes to stdout, I need to ignore these lines...)
 

What is wrong with sed and you can simply echo files in some sudoers.d
config. What kind of unix dev cannot handle text strings.

That is one of the problems with it too, especially if polkit becomes
over used and perhaps this is below the belt but it's certainly true
that IPC has caused Android more than enough security issues.

 
  I don't understand 'the APIs that coders will learn instead of C.' Can
  you elaborate? Polkit has a C api...
 
 
  It has an api that is simply not needed? Small tools are better.
 
 You prefer the commandline api? (one byte for return values, half of
 which are signals)
 

What's the problem there?. I have already stated some of the very
important benefits.

 
  I don't understand how the code will 'not be well designed to the
  application at hand.' I mean ideally the API and the CLI are
  essentially just wrappers around the same library of functions.
 
 
  If you search for sites that evaluate polkit you will see that it is
  considered to encourage granting more permissions than necessary rather
  than coding a specific tool.
 
 Hah, because no one uses sudo to grant extraordinarily broad permissions.
 

They do, but it encourages them not to and not vice versa and they can
easily customise the default rule to say emerge -moresecurethandefault

Win Win and a couple more Wins in fact

 
  Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
  you will have to read some manpages. However i don't think the
  concepts are difficult.
 
  Man pages won't help with polkit and it actually generally ships with no
  configs by default.
 
 In Ubuntu Precise..

You still have to do way more than commenting or editing a file to
restrict the default further, aka it's unlikely to happen.

 
 All of this is explained in man polkit.
 

And pkauthority and and  How will that help when as I have
mentioned a coders comments aren't even sure exactly what the code
permits. 

 
  I know about pkaction, the problem is that the actions tells you next to
  nothing about what is actually allowed. I haven't time to dig out one
  of the rediculous comments from the source now unfortunately. With
  small tools it's much better all round.
 
 Really? Please enumerate what giving someone access to 'emerge' can do.
 

Exactly, you see man emerge and grepping the source does work perfectly
well there. You could make myemerge pretty quick too.


 
 No one maintains the sudo wrappers though. Someone maintains the
 polkit actions. That someone also happens to be the upstream author.
 

That's what I am asking, is there any reason not to as it would be
better? No reason has come up yet?


 
  Is the polkit maintain any less 'trustworthy' than the gnome
  maintainers? the kde maintainers? the kernel maintainers? At the end
  of the day my machines are running software from thousands of
  contributors.
 
 
  I think that has been demonstrated and we are talking about root code
  and sudo is never running as such.
 
 I don't follow...
 

It is certainly far easier to exploit polkit than sudo with a decent
sudoers of course for multiple reasons.



-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

 
  I never meant it is rubbish as such but I saw it as rediculously
  inferior to sudo before I even read this.
 
  http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/
 
 Perhaps I'm misunderstanding, but that is talking about a specific set
 of problems that I don't think polkit was actually designed to
 address. Polkit is basically for authenticating applications via
 users, not the applications themselves. If I am running app foo, and
 app foo wants to inhibit hibernation; polkit is there to ask 'hey is
 antarus allowed to inhibit hibernation? Does antarus need to auth to
 do so? Is antarus already authenticated? Now one may say 'hey but I
 only want certain applications to hibernate' and while that may be an
 interesting problem...I don't think the existing polkit intends to
 solve it.
 

The point is that it is inferior in every way and so pointlessly causing
more work and other problems not to mention guaranteed increased
security risk having extra code constantly running as root. Why was it
started, rather than contributing to sudo.

 
 
  It is however, designed for graphical UI single-seat systems.
  Its command line support sucks (they only added a CLI auth agent in
  May) and it is not well adopted. Multi-user systems do not work well
  with polkit. Certainly with polkit and dbus you can allow users to
  take more specific action without complex wrappers, setuid scripts, or
  sudo.
 
  Except you can't, it only encourages more coarse grained approaches,
  less useful commands available and devs to learn an api rather than C
  and simply moves code into a far less secure mechanism and increases the
  chance that the code will not be well designed to the task at hand and
  running as root. It can be a real pain to work out exactly what polkit
  allows and you cannot just edit it to suit your application and it
  completely ignores the existing unix security technologies with
  brilliant track records.
 
 One could say that 'a discrete set of APIs will be no match for
 the..fined grain control that is the command line!' I would agree. I
 don't agree that this is a one-size fits all deal though. There can be
 a command line AND an API. I'd rather grant my users 'access to the
 install authenticated packages action' than have to own a complex sudo
 rule.
 

How about uncommenting a line that does so. All you are buying into is
a default setup.

 I don't understand 'the APIs that coders will learn instead of C.' Can
 you elaborate? Polkit has a C api...
 

It has an api that is simply not needed? Small tools are better.

 I don't understand how the code will 'not be well designed to the
 application at hand.' I mean ideally the API and the CLI are
 essentially just wrappers around the same library of functions.
 

If you search for sites that evaluate polkit you will see that it is
considered to encourage granting more permissions than necessary rather
than coding a specific tool.

 Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
 you will have to read some manpages. However i don't think the
 concepts are difficult.

Man pages won't help with polkit and it actually generally ships with no
configs by default.

 There are plenty of helpers (pkcheck springs
 to mind) that assist the user in figuring out what is 'allowed'. 

I know about pkaction, the problem is that the actions tells you next to
nothing about what is actually allowed. I haven't time to dig out one
of the rediculous comments from the source now unfortunately. With
small tools it's much better all round.

The
 configuration for polkit is all in /usr/share and /etc. The configs
 are configurable..again in /etc. This is not something I would term
 'challenging.'
 

Generally there aren't any rules files, the defaults are built in and
your expected to use a webbrowser, even on a server?!?! You shouldn't
run lynx never mind X on a server. 

If some configs are in /usr/share rather than /etc perhaps that explains
why one tutorial said so and it has no effect on some systems.

 
  You could try to argue that many eyes will look at a central piece of
  code but in fact less implementations will likely mean less eyes and
  just assumption that a guy who got JS through as a config language has
  everything covered. Granted, unmaintained code running as root may be
  higher with sudo but if it needs maintaining, should it be running as
  root at all or is it actually simply doing too much.
 
 Its not a matter of many-eyes. It is a matter of 'some other guy is in
 charge of maintaining that component.' It means I can focus on stuff
 that matters, and not focus on 'wrappers to make random things work.'

That can apply to sudo, would be more secure and cause less problems
and you see why I brought it up and asked why not, because that should
be the case.

 Is the polkit maintain any less 'trustworthy' than the gnome
 maintainers? the kde maintainers? the kernel maintainers? At the end

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

  Debian having to patch KDE to use /etc for configs is simply wrong too.  
 
 huh huh, do you know if they have a fix for 
 http://bugs.gentoo.org/438790 to stop KDE from destroying upstream 
 polkit files?

I don't, I just know that on Debian the configs are in /etc and the bug
you mention, comments was what caused me to comment.

Debian patches to make /etc/kde4 the config directory.

Of course it may just be that debians KDE hasn't got the polkit
rubbish as it is older.

I remember reading a while back that distros had some blunders in
writing secure sudoers files and so it was emptied. Is that true?

I still ascert that apps adding groups with NOPASSWD sudoers lines
perhaps even commented out by default in all or some cases is far
better than polkit for many reasons. Any counter argument can apply
to sudo too and rather easily.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

  Unless sudo has some config setting that allows access only when
  logged in via console it isn't really a solution.
 
  Rich
   

man sudoers - /requiretty

 
 I manage 'thousands' of desktops at Google and we generally like
 polkit.

I never meant it is rubbish as such but I saw it as rediculously
inferior to sudo before I even read this.

http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/


 It is however, designed for graphical UI single-seat systems.
 Its command line support sucks (they only added a CLI auth agent in
 May) and it is not well adopted. Multi-user systems do not work well
 with polkit. Certainly with polkit and dbus you can allow users to
 take more specific action without complex wrappers, setuid scripts, or
 sudo.

Except you can't, it only encourages more coarse grained approaches,
less useful commands available and devs to learn an api rather than C
and simply moves code into a far less secure mechanism and increases the
chance that the code will not be well designed to the task at hand and
running as root. It can be a real pain to work out exactly what polkit
allows and you cannot just edit it to suit your application and it
completely ignores the existing unix security technologies with
brilliant track records.

You could try to argue that many eyes will look at a central piece of
code but in fact less implementations will likely mean less eyes and
just assumption that a guy who got JS through as a config language has
everything covered. Granted, unmaintained code running as root may be
higher with sudo but if it needs maintaining, should it be running as
root at all or is it actually simply doing too much.

 My package manager can have a polkit action like 'install a
 signed package' and I can grant the user access to do that, but not
 access to install unsigned packages (root exploit there...) or run
 other dangerous apt commands. It comes built into apt, so I don't have
 to write extra wrappers.

That would be the default and wouldn't even need the command line
argument control of sudo. Just allowing updates is apt-get update.

In fact I have a debian system where experimental iceweasel is
installable but nothing else. I have an Arch system where the only
kernel updateable is a signed by me when offline kernel and polkit is
disabled as I don't have the time to keep track of what it is
permitting and code comments weren't helpful there.

Sudo even supports regex!

p.s. apt should be downloading as an _apt user, simply as best
practice before adding polkit support ;-)

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

On Tue, 15 Jan 2013 22:19:37 +0200
Maxim Kammerer m...@dee.su wrote:

 This is a major problem, there are other questionable choices that
 raise the question whether developers are familiar with how things are
 done on Unix:
 https://bugs.freedesktop.org/show_bug.cgi?id=58787
 

I have to confess that despite this being a serious matter that really
made me chuckle.

  Sudo even supports regex!  
 
 Only glob patterns, and it's not too good at that.
 http://www.sudo.ws/bugs/show_bug.cgi?id=500


/etc/sudoers:
anonliberte = NOPASSWD: /sbin/shutdown -[hr] now

sudo shutdown -h now - allowed
sudo shutdown -h now - allowed (probably shouldn't be)

It may not be perfect and is why I would love to see distros grow some
balls or perhaps more rightly packagers and embrace sudoers again but it
is far clearer what is allowed than polkit and I believe.

/sbin/shutdown -[h][r]

Would do what you want. You may need to test but I have never found a
command I couldn't add to sudoers.

After all it can only make the likes of Ubuntu and perhaps all in fact
more secure ;-)

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Kevin Chadwick]

 William is packaging upstream udev for Gentoo.
 
 You are shooting the messenger.

I expect there is 0 blame meant for William. 


P.s. 

Is it William that Lennart dished some blame in the direction of. I
completely disagree. It's not the job of every distro to look for all
build flags to fix some software's defaults because other software has
some small issues. That's simply ludicrous and my best guess is it
being a feeble attempt at reasoning an excuse. At the very least and
like in many release notes, it should have been made clear that distros
may wish to consider using that flag to keep the current behaviour
whether any reason to do was understood or not. The thought strikes me
now that in the reverse case their likely wouldn't be any justification
for having a build flag?

Debian having to patch KDE to use /etc for configs is simply wrong too.

You are right though, I don't suppose it helps much airing any of it
here.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: [gentoo-dev] Re: call for testers: udev predictable network interface names

[Kevin Chadwick]

  but
 again it appears that simple cases are being made complex, just to allow
 for someone else's complex cases. Which is faulty logic.

It's a welcome option but an important question seems to be; Why wasn't
this picked up in the dev cycle?.

This reminds me of udisks 8 months ago losing features for
multi-seat costing me time to replace it with udev and scripts which I
still prefer. Is it coincidence that Redhat wanted complex multiseat at
all costs for udisks and Redhat want fast boot at all cost for cloud
services?

p.s. I am very glad of RedHats contributions and respect their position
of giving coders freedom but I just think that if they are able to fund
coders to look after a corner full-time or completely then they need
to manage that corner or atleast have some ground rules to cover any
case of my way or the high way. The kernel wouldn't tolerate this
kind of breakage and I really hope I never see linux userland as
dependent on IPC as minix is or as broken without IPC as windows is
without RPC.

I take the unarguably more secure well setup sudoers and useful small
tools anyone can use or take code from over polkit anyday.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: [gentoo-dev] Re: USE flag suid in both use.desc and use.local.desc

[Kevin Chadwick]

On Mon, 31 Dec 2012 08:21:10 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 I was curious, however, as I'd been reading about running X as
 non-root, 

I use some hackery to run startx on some systems as a normal user on
linux and without suid. The only important things to me that break on
these systems is hotplugging mice etc. and which could be quite easily
fixed if it was worth the time. I've found a log out triggering a
relaunch good enough with 0 complaints for now.

You might be interested that the default on OpenBSD is for X to run as
the X11 user and xdm to run as root and involves no hackery or issues
but still some root priviledges.

Re: [gentoo-dev] Gentoo and Root CAs

[Kevin Chadwick]

On Mon, 31 Dec 2012 15:42:39 +0100
Tobias Klausmann klaus...@gentoo.org wrote:

  I _do_ think that his concerns need
 to be addressed, particularly the second half of his statement.

Whilst I agree that if it does debians system shouldn't undermine
mozillas. I think the latest efforts are a pointless bandaid but I'm
sure better solutions should come if we can get around the CAs wanting
to make money issue.

Can you prove you know what certificates were issued, to whom, and who
authorized them? Accountability 101! It's not perfect, but it's a huge
step forward from Oh, this guy I know says its cool

Is it really. Introducing trust on people we don't know and can't
possibly verify (yes I know the procedures that you could argue badly
are better than none). 

What SSL protects is data between two servers and all that is required
is to ensure that you are talking securely to the server or domain name
you have chosen trust. Anything else is simply adding vectors of attack
and false senses of security. I thought DNSSEC maybe extremely useful
for ssl but it seems it may well just be the best available option
at the moment as DNSSEC could do with an overhaul too first.

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

[Kevin Chadwick]

 We're drifting here, but the concept is that machine-local stuff like
 configuration stays out of /usr, and generic distro stuff stays in
 /usr.
 
 A webserver for site1 vs site2 would be identical in /usr, but
 different elsewhere.

That has always been the case. In fact people have tried to
seperate /etc from / but it has proved too problematic. That's a
different issue entirely. If the proposal was / (etc) /root /usr. I
would be happy... if it worked.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

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

[Kevin Chadwick]

On Wed, 19 Dec 2012 09:13:28 -0800
Greg KH gre...@gentoo.org wrote:

 No, not at all, please see the web page that describes, in detail, the
 problems that has been going on for quite some time now, with the /usr
 and / partitions and packages.
   http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
 
 One good solution to this issue is to move everything into /usr, and
 that's something that has wonderful benifits in the long run, and is
 something that I expect all Linux distros to eventually implement.
 Those that don't, will suffer because of it.
 
 Again, see the web page for why moving stuff into /usr is a good idea
 for the reasons behind this.
   http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

If either of those links allowed comments, the story they told would be
very different.

From memory notice how the second link skimps over the main driving
force (point 4 again from memory).

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

[Kevin Chadwick]

 People simply don't seem to realize that you can go away and 
 do something else while all that's happening

Like servers I prefer build machines to be more secure dedicated build
machines without a browser or X, so I expect it's a bit of a barrier
for me.

Having said that I haven't found the time to see how much time and
resources are involved compared to Sabayon and how often yet whilst
using libreoffice binaries.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

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

[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] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Kevin Chadwick]

Firstly I use your longlasting 3.2 kernel currently though perhaps not
for long as I'm switching distro to avoid systemd and thank you for
the LTS work, however that won't stop me speaking my mind.
_

  Greg, can you write back to this message with specific examples of what
  would need to be customized so that separate /usr would work  right
  without an initramfs? I have tried to explain multiple times that this
  is a mis-conception that udev caused it, but I am getting nowhere.  
 
 It's not my job to do this, nor yours, or fix any of these issues.  It's
 up to the people who wish to keep a separate /usr partition without an
 initramfs to do this work.


So even though you keep stating things without being specific like
udev is not a blocker, you have just admitted that the udev package
does violate the Filesystem Hiearchical Standard as well as the latest
draft when installing. I can understand following the current trend
(some of which I agreed with) but what is the justification for that
which didn't already have an optional solution?

It's not your job?. I'd hope your unix spirit or atleast professionalism
would be greater than this and realise that helping may save good devs
time more than it costs you and realise that the generic goals may not
be everyone's or even the long lasting correct ones and competition is
good and not intended as a kick in the teeth or insult.



p.s. embedded does not equal mobile and android uses a leaner init
than /sbin/init and experiments posted to the buildroot list found
systemd to be slower, guessed to be due to increased cycles but perhaps
memory usage on even some mobile level processors which accounts for a
fraction of linux potential in embedded applications. POSIX compliance
is also a requirement by some major industries.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

[gentoo-dev] Survey about new contributor experience and other projects

[Kevin Carillo]

Hi everyone,

My name is Kevin Carillo. I am a PhD student currently living in Wellington 
(New Zealand) and I am doing some research on Free/Open Source Software 
communities.

If you have joined the Gentoo community after January 2010 (within 
approximately the last 3 years), I would like to kindly request your help. I am 
interested in hearing from people who are either technical or non-technical 
contributors, and who have had either positive or negative newcomer experiences.

The purpose of the research is to work out how newcomers to a FOSS community 
become valued sustainable contributors. I am basically studying how the 
experience of a FOSS community newcomer has an influence on this person's 
actions and project contributions in the community.

The survey has already gathered 250+ responses in less than 2 weeks and has 
been supported by the following projects: Debian, FreeBSD, GNOME, KDE, Mozilla, 
NetBSD, OpenSUSE, Python, Ubuntu or Wikimedia.

The survey can be found at:
https://limesurvey.sim.vuw.ac.nz/index.php?sid=65151lang=en

The survey is anonymous, and the dataset will be released under a share-alike 
ODbL license.

I will post news about my progress with this research, and the results on my 
blog: http://kevincarillo.org. Don't hesitate to contact me at 
kevin.cari...@vuw.ac.nz

You can also find some more information at:
https://www.linux.com/news/software/applications/666038-survey-how-important-is-newcomer-experience-in-free-open-source-software-projects
https://openhatch.org/blog/2012/a-research-project-to-understand-what-does-it-take-to-retain-newcomers/
and also on the planets of the listed projects...

Thanks!


Kevin Carillo
School of Information Management
Victoria University of Wellington
PO Box 600, Wellington NEW ZEALAND
(04) 463 5233 ext. 8679 | Room RH401
kevin.cari...@sim.vuw.ac.nz
http://kevincarillo.org/

[gentoo-dev] Quantity of open bugs

[Kevin F. Quinn]

Hi all,

I was nosing through bugzilla, and noticed:

* Number of open bugs is greater than 14,000
* Number of open bugs untouched for more than 2 years - well over 2000.
* Number of open bugs untouched between 1 and 2 years - well over 2000.
* Number of open bugs untouched between 6 months and 1 year - well over
  2000.
* Number of open bugs untouched between 3 months and 6 months - over
  2000

The winner is bug #78406, which hasn't been touched for over 2240 days
- over 6 years - at the time of writing.

I would guess these old untouched bugs aren't actually going to be
touched, ever - a lot simply won't be relevant any more for one reason
or another.  All they're doing is cluttering up bugzilla.


So I'd like to suggest a drastic, perhaps controversial action.  Mark
all bugs that haven't been touched for over (say) 3 months as
Resolved:Wontfix, with a polite comment saying that it is closed due
to lack of resource amongst the volunteer developer community.  I'm
sure a suitable bugzilla script wiz could do that relatively
easily.  Users who care about such bugs can still comment on them, or
talk directly to the assigned dev to highlight it's still a relevant
issue to them, or even to supply a solution against the current tree.

It could be an ongoing policy, in which case, users who care about
them can keep bugs alive simply by posting useful updates to the bug,
describing how the issue still applies to a new revision for example.

Just a thought from an old ex-dev...

Kev.

Re: [gentoo-dev] gtk 3 preparation work

[Kevin McCarthy]

On Wed, Mar 02, 2011 at 03:01:59PM +0100, justin wrote:
 On 01/03/11 08:32, Nirbheek Chauhan wrote:
 Things for
 
 
 Herd: sci
 Herd: sci-chemistry
 Maintainer: marku...@gentoo.org
 Maintainer: cr...@gentoo.org
 Maintainer: j...@gentoo.org
 
 
 are fixed.
 

Herd: desktop-misc
Herd: net-im

are fixed.

-- 
Kevin McCarthy sign...@gentoo.org


pgpVSeXNgCw9X.pgp
Description: PGP signature

[gentoo-dev] Last Rites: media-gfx/pornview

[Kevin McCarthy]

# Kevin McCarthy sign...@gentoo.org (25 Feb 2011)
# Crashes when opening images wrt #325879
# Upstream dead since 2004. No gentoo maintainer.
# Many alternatives in tree: eog, gqview, mirage, etc.
# Removal in 30 days
media-gfx/pornview

-- 
Kevin McCarthy sign...@gentoo.org


pgpuyFo1DPTnM.pgp
Description: PGP signature

[gentoo-dev] Retiring

[Kevin F. Quinn]

Hi all


I'm finally giving in to reality and retiring as a Gentoo Dev.  I've
been effectively inactive since March last year and lack of time
means that isn't going to change any time soon.  I'll still be using
Gentoo of course, so I'll still stick my nose in on bugzilla now and
again :)


There's not much out there that depends on me; packages that have my
name against them as maintainer are:

app-admin/eselect-oodict
app-text/hunspell
app-text/info2html
sys-apps/qtparted

and

app-dicts/myspell-*

There's useful work to be done on the myspell dictionaries (which are
used by hunspell). Currently various applications install their own
copies of dictionaries in various places - something that is just
wasteful and lazy.  I'd always intended to finish an eselect module for
managing myspell dictionaries; got some work done but never finished it
off. eselect-oodict was a quick version for dealing with OOo.org
dictionaries (which uses myspell dictionaries) and you can find my
attempts at a more generic eselect-myspell on bugzilla.  Doing that
needs co-operation from the relevant applications (particularly the
mozilla application set).

qtparted is controversial and may not be worth holding on to; see
bugzilla for details.


Lastly, just to say I've learned a lot from my involvement with Gentoo
over the time I was active and it has been very worthwhile for me;
hopefully I've managed to contribute at least something back to
compensate!


All the best,
Kev.


signature.asc
Description: PGP signature

Re: [gentoo-dev] ML changes

[Kevin Lacquement]

Kumba wrote:


- I envisioned three mailing lists, essentially:
* core
* dev
* project

- core:private, dev-only mailing list for internal discussion

* Possibility: becomes read-only to the public after
  a set time limit, possibly 1, 2, 4, or 6 months.
  Certain messages and threads could be marked (via
  some feature, for example) to remain permanently
  private, and thus would never be readable by the
  public.  This policy would NOT apply retroactively.


I'm not sure about stuff in -core becoming publicly accessible.  After 
all, isn't it in the private list for a reason?  Perhaps summaries of 
-core discussions being forwarded to -dev would be a better option. 
However, I'm new to -dev, so if this is what already happens I don't know.





- dev:open, dev and user mailing list for technical discussions 
about

the gentoo project.  Topics would include package
addition/removal/masking announcements, EAPI discussions,
package development questions/inquires (i.e., from users,
but NOT help -- gentoo-user exists for that).


Here's where we want the non-devs to get access.  After all, not all 
development and debugging is done by devs.  All the current devs were, 
at one point, users.  Where did they get their start?  My bet is they 
entered via the -dev mailing list, learned the ropes here, and 
eventually earned their dev status.  If the -dev list is closed, where 
do the new dev-wannabes learn the ropes and get their voices heard?




* Possibility: Package changes, such as moves,
  deletions, additions, and so forth could also be
  routed automatically to a -dev-announce ML, possibly
  by prefixing the subject field with [ANNOUNCEMENT]:
  (This prefix, would of course, be stripped by the
  automatic mailer before posting to -dev-announce).


Would it perhaps be better to send announcements to -dev-announce, and 
have that list forward to -dev?  That way we avoid issues if a subject 
starts with [ANNONUCEMENT], for example




* Possibility: topics could also include developer
  recruitment and developer departure emails.  However,
  these may need to be sparse and impersonal (almost
  machine-like) where-in it may be announced who joined
  (First/Last name, developer name, IRC handle, etc..),
  herd they'll be joining, and duties they'll perform,
  including packages they may be maintaining.  These can
  also be routed to a -dev-announce ML.


If these messages will be machine-like, why not have them 
machine-generated?  When you become a dev, someone (you?  the person 
that -dev-ifie's you?) fills out a form, and the information from the 
form is forwarded to the list.


[snip -project]



Basically, moderation is a tool to me, a tool that should be used 
sparingly. Not used as a blanket cover, with the occasional someone 
lifting up that blanket to peek outside (save that for the monster under 
the bed).  That said, however, I don't think we should totally dismiss 
the idea of blanket moderation.


Rather, I think we should first implement -project, put out enough 
information to get people to use it, and watch it for a few months.  By 
and large, we may discover that simply giving another list for the 
non-technical discussions may fix the problems on -dev, and moderation 
won't be needed on either list.  If, on the other hand, problems still 
arise on -dev that -project did not address (or may've been potentially 
created by -project's creation), then we can revisit the option of 
blanket moderation then.


I agree with this.  Also, it gives a transition time for people to get 
used to the new idea.  Don't create -project, then 3 months later say 
that didn't work, we need to moderate -dev.  Give it a little more 
time than that.  Ensure that people are reminded, especially at the 
beginning, that there may be a more appropriate forum.




Simply put: One Step At A Time.



Cheers,

--Kumba



My 2 non-dev cents,

Kevin
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] ML changes

[Kevin Lacquement]

Kumba wrote:



Here's where we want the non-devs to get access.  After all, not all 
development and debugging is done by devs.  All the current devs were, 
at one point, users.  Where did they get their start?  My bet is they 
entered via the -dev mailing list, learned the ropes here, and 
eventually earned their dev status.  If the -dev list is closed, where 
do the new dev-wannabes learn the ropes and get their voices heard?


You missed the small mention of open in my first sentence.  I probably 
should have clarified what my definition of what open is, but it 
pretty much means no moderation on the -dev list so that users and 
developers could post.




Sorry, I should have made it clear - I was agreeing with you there.  I'm 
not a -dev yet, but if I continue to have the time to work towards it, I 
don't want to be blocked because someone decided that users couldn't 
give insights to the developers list.


Kevin
--
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Watch out for license changes to GPL-3.

[Kevin Lacquement]

Greg KH wrote:
 On Tue, Jul 10, 2007 at 07:10:35PM +0200, Dominique Michel wrote:
 Can you explain more. If the kernel can be tivoized by someone
 I'm sorry, but tivoized is not a verb.  Please explain what you mean
 by this.
 I mean if someone distribute a kernel with a licence that forbid to remove 
 the
 functions he added even if we don't want them (as example drm at the kernel
 level as in Vista),
 
 But that's impossible with the current Linux kernel license, so how
 could that ever happen?  Why even try to discuss an impossiblity?
 

I understood it to mean that you're allowed to change the source, but
the hardware has locks on it to prevent you from using the changed
source.  So yes, you're allowed to modify the code and pass it on (as
permitted by the GPL), but you can't actually run it (eg due to code
signing requirements)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages needing new maintainers

[Kevin Lacquement]

Robin H. Johnson wrote:

 Software, I picked up maintenance of autofs when the previous maintainer went
 AWOL several years ago, and ran with it because I needed AutoFS-LDAP. I don't
 have access to any AutoFS-LDAP setups anymore, and upstream has moved on. 
 There
 is a 7Kb init.d script that badly needs complete rewriting due to upstream and
 kernel changes:
 net-fs/autofs


I'll see what I can do with this one.  I won't have access to my network
for a couple weeks, but when I get back home I'll poke into it.

Kevin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] automated extended information gathering

[Kevin Lacquement]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:

 5) considering 3), I'd rather see such information be specified by
 ebuilds somehow, not a global file (think about overlays). Maybe by
 installing a script in a specific location or so.

 Marius
How about adding another function to the ebuild format?  pkg_getinfo()?

Kevin


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGkCDCr4p8oOjnnKARAojFAJ0duN7Ur5wmf8e770AztJip7nxPngCgg5yH
Fqtd2iL+ourVZM+uMTP9SMY=
=ShqV
-END PGP SIGNATURE-

-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] 'stricter' FEATURE and poor programming practices notice

[Kevin F. Quinn]

On Thu, 17 May 2007 13:12:01 +0200
Hans de Graaff [EMAIL PROTECTED] wrote:

 I've had the 'stricter' FEATURE turned on for some time and found that
 many packages failed due to the QA notice regarding poor programming
 practices. I filed a few bugs for this but have not gotten a lot of
 response, or the suggestion to talk to upstream. Obviously the latter
 is always a good option, but I'm wondering what the intend behind
 this QA notice is.
 
 My view is that if this is a QA notice then, if a package doesn't
 emerge because of it, it is a Gentoo QA bug and package maintainers
 should be responsible for fixing it. 
 
 If the notice is only informational, then the emerge process should
 not be stopped because of it (and this would mean that it is nice to
 fix these issues but not mandatory).

Yeah; it's a bit of a pain, especially if you have '-Wall' in CFLAGS
(a large proportion of packages fail if you do).

I've ended up removing stricter from FEATURES, which is far from ideal
as it means all the other checks are no longer fatal, some of which I
really want to know about at emerge time (well, to be honest, I've
ended up patching portage locally to make the bad code thing
non-fatal).

In a broader scope, we could do with a QA check control file or
something to provide finer-grained control of these QA checks.  However
the QA checks themselves seem to be a bit ad-hoc at the moment.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] distcc and precompiled headers

[Kevin F. Quinn]

On Fri, 18 May 2007 08:41:10 -0400 (EDT)
Caleb Tennis [EMAIL PROTECTED] wrote:

 Based on some recent findings, it looks like the two above mentioned
 features don't work together.  pch don't get distributed to distcc
 nodes, so they're basically mutually exclusive.  However, distcc is a
 FEATURE and pch are a USE flag.
 
 Should we just put a check in each ebuild that uses the pch use flag,
 make an eclass, or build something into the package manager(s) ?
 Thoughts?

I'd go with a 'pch' utility eclass, and have packages that IUSE pch add
a call in pkg_setup (which would either die, or disable distcc).

On a related note, we had a discussion on bug #128810 a while back about
whether the package manager should be doing distcc and ccache at all,
anyway.  Personally I think the package manager shouldn't be involved in
that at all.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

[Kevin F. Quinn]

On Sat, 12 May 2007 12:41:58 +0100
Marcus D. Hanwell [EMAIL PROTECTED] wrote:

 There is a template library called Eigen I would like to add to the
 tree. It is a dependency of an application I would like to add
 shortly. It will also end up being a dependency of KDE 4 (for
 kalzium). My question relates to the licence the code is released
 under.
 
 It is licenced under the GNU GPL, version 2 or later with the
 following exception,

This is a common situation with GPL compilers - some are licensed
so that they can be used to build non-GPL software, some can only be
used to build GPL software.

The situation with Eigen is similar to the libgcc exception for GCC.
We don't mention that in the LICENSE for gcc.  This is the exception
that allows you to build non-GPL software with gcc (note for the
interested - if you build profiled executables with gcc, the GPL applies
to the built executable since the profile support code linked into the
executable is licensed purely under the GPL - not a real problem as
no-one distributes profiled executables!).

However there's also a similar exception for gnat-gcc; that has a
separate license file GMGPL which explains the situation there.
However this is talking about extra libgcc stuff that is
Ada-specific - the standard libgcc exception is not mentioned.
For information, gnat-gpl (the AdaCore-sponsored version) doesn't have
the exception, so is straight GPL - this also means you can't use
gnat-gpl to build and distribute BSD-licensed software, for example.

So currently we're inconsistent.  We must be accurate in our license
declarations, I think, so my view is if Eigen has a license that is GPL
with some exception, that should be made clear.

All these exceptions are doing the same thing - relaxing the GPL as it
applies to the compiler (or template library in this case), so that it
does not apply to works created using it.  I like the
GPL-2-with-linking-exception license name that the gnu-classpath
package uses; perhaps we could include (concatenate) all the exception
clauses that lead to the same thing into that license file and have the
relevant packages use that license name.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] gentoo: static/dynamic linking libraries

[Kevin F. Quinn]

On Mon, 30 Apr 2007 05:07:00 +0200
Roman Zimmermann [EMAIL PROTECTED] wrote:

 Am Montag 30 April 2007 00:11 schrieb Ciaran McCreesh:
  On Sun, 29 Apr 2007 14:56:57 -0700
 
  Donnie Berkholz [EMAIL PROTECTED] wrote:
   Anyone who wants to build a static binary wants the static libs.
   Given the difficulty in universally enabling or disabling their
   builds because of build-system differences, building them and
   tossing them in the trash with INSTALL_MASK, as Marius suggested,
   seems like the best way to go.
 
  The best way to go or the only viable short term solution?

Best way to go, IMO.

 That's the point! Universally disabling static builds can't be a
 longterm solution. The only sane way to do this is on a per ebuild
 basis.

The thing about static libraries, is that the ebuild that creates them
doesn't know whether anything else will want to use them.  It may be
that in practice, most libraries are never used in their static form -
but the point is that the ebuild doesn't know enough information to
make the decision.

However, with INSTALL_MASK, the user makes the decision never to have
static binaries, and thus gets a system free of static libraries.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] $Header:$ and ebuilds

[Kevin F. Quinn]

On Sun, 22 Apr 2007 17:46:18 +0200
Danny van Dyk [EMAIL PROTECTED] wrote:

 Am Sonntag, 22. April 2007 schrieb Michael Cummings:
  On Sat, Apr 21, 2007 at 08:47:54AM +0100, Kevin F. Quinn wrote:
   I do the same.  The '$Header: $' tells me which version of a file
   in the CVS tree I last synced to in my overlay, then I can just do
   a cvs diff on the tree to get a patch of differences since then. 
   Very useful.
 
  FWIW, I've used the $Header $ to determine if a person is looking at
  the latest greatest or needs to synch up first (in particular when I
  was dealing with an eclass bug). Very useful when dealing with bugs
  and you need to confirm that the user is completely synch'd up and
  looking at a current tree or not (because just asking when the last
  time they synch'd doesn't help).
 
 This can be done using checksum like SHA1 much better, as people can 
 edit their ebuilds/eclasses/profiles and forget/lie about it, and
 still have the same $Headers$ line.

In practice I find it's rare that a user has been hacking around in the
eclasses.  All the SHA1 tells you is that it's not the most recent,
but it's not easy to determine from the SHA1 exactly which version they
do have (so it's not enough to determine what's different).

Having said that, the most accurate way to find out what they have is
to get them to attach the eclass and diff it yourself.  However
relying on the SHA1 also means you can't just say things like, Check
eclass blah is version 1.836 (look at the $Header line at the top
of the file).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] $Header:$ and ebuilds

[Kevin F. Quinn]

On Fri, 20 Apr 2007 14:30:54 +0200
Fabian Groffen [EMAIL PROTECTED] wrote:

 On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote:
  does anyone actually find this useful ?  i think ive used the value
  in there like once (when in reality a `md5sum` would have worked
  just as well) ... otherwise, from my perspective:
   - it causes annoying bogus hunks in diffs
   - not uncommon for people to contact me as the maintainer because
  i'm in that
   - wastes space (well, probably not a strong argument due to bytes
  vs blocks)
   - for mostly green users, it's confusing and they get it wrong
 
 I use it to make deltas of changes made in the tree, and apply those
 deltas on the overlay I'm using.  Without $Header: $ there I have no
 way to actually see which version I'm dealing with, so which
 revisions to retrieve for differences.
 For that reason, I prefer as much files as possible in the tree to
 have a $Header: $ somewhere, so I can easily sync, keeping my local
 changes.

I do the same.  The '$Header: $' tells me which version of a file in the
CVS tree I last synced to in my overlay, then I can just do a cvs diff
on the tree to get a patch of differences since then.  Very useful.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] $Header:$ and ebuilds

[Kevin F. Quinn]

On Sat, 21 Apr 2007 12:00:55 +0200
Thilo Bangert [EMAIL PROTECTED] wrote:

  I do the same.  The '$Header: $' tells me which version of a file in
  the CVS tree I last synced to in my overlay, then I can just do a
  cvs diff on the tree to get a patch of differences since then.  Very
  useful.
 
 right - but this functionality would not go away - it would just have
 to be implemented differently. a potential move to git would make
 this much more easy, if i am not mistaken.

By implemented differently you mean by adding extra steps and data
to the synchronisation process.  Currently, I compare the Header field
in my overlay (which SVN doesn't touch) with that in the Gentoo CVS,
and use the difference to drive the 'cvs diff' command to get a patch.

Removing the header would mean I'd have to record the origin version
somewhere, and keep that up-to-date whenever the file is
re-synchronised.

Having said that, it only works for me because my overlay is in SVN and
and is not configured to process CVS header keywords.

However I can honestly say that in my experience, the file revision
identification is _always_ recorded in the file - I've never yet seen
an SCM used in practice that didn't have that information.  The reason
people put that information in, is so that when the file is taken out
of the context of the SCM repository, it's still clear where it came
from.  This is precisely how I'm using it.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?

[Kevin F. Quinn]

On Mon, 26 Mar 2007 08:05:58 -0700 (PDT)
Alec Warner [EMAIL PROTECTED] wrote:

 do you as a developer find writing web pages to be confusing or
 difficult?

No.

 Is there not a good tutorial for learning our webpage XML syntax?

For my use, I've found the available docs sufficient.

 Do you find that you bump up against restrictions in the DTD or other
 problems that prevent you from expressing yourself properly?

No.  I do try to keep things simple, which may be why.

 Do you have any idea how to actually go about extending GuideXML
 (or the other XML's we provide)  Have you ever tried?

No and no - I've never had the need.

 Could we improve training with regards to any of this?

Do we really expect people to hack around with the DTDs?  I thought the
whole point is that you stick to the stuff provided by GuideXML.  We're
not writing fancy interactive websites - we're just writing some docs.

All that said, I've only ever written single-page docs.  I don't _like_
GuideXML, but have no inclination to do anything differently for
Gentoo website stuff, and it's sufficient for the stuff I've used it
for.

I wouldn't want to write anything sizable in XML, as the markup just
gets in the way, much like many other markup languages (LaTeX, GROFF
etc).  Docutils' RST (reStructuredText) is much better in this regard;
its markup is much less intrusive than anything else I've used.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID - NOCHANGE in bugzilla)

[Kevin F. Quinn]

On Sun, 25 Mar 2007 17:53:51 +0300
Rumen Yotov [EMAIL PROTECTED] wrote:

 May be a little OT, but just two of four ancient-sayings:
 1.Never accept things personaly (everyone is acting on his own
 motives); 2.Try not to make assumptions (just ask questions, till you
 get it). Clearly (from above, etc.) i'm not a native speaker, so
 forgive my wording. Hope you get the meaning ;)
 Better try to find common grounds, that assume something which (very
 often) isn't true at all.

Very true.  My favourite approach is the traditional TCP/IP adage, be
conservative in what you send, liberal in what you receive.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

[Kevin F. Quinn]

People reporting bugs often get annoyed when their bug is marked
INVALID; especially when they're relatively new to the Gentoo
Experience.  We've all seen it many times, I'm sure.

Arguably no bug is invalid in the normal sense - if someone raises an
issue, they have an issue, regardless what we think of it.  To that end
I'd like to propose bugzilla be reconfigured to use the phrase
NOCHANGE instead of INVALID.  NOCHANGE would indicate that whatever
the original issue, no change is needed on our part to resolve the
issue.

Any reasons why this would be a bad idea?

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

[Kevin F. Quinn]

On Sat, 24 Mar 2007 19:14:38 +0100
Marius Mauch [EMAIL PROTECTED] wrote:

 On Sat, 24 Mar 2007 18:34:21 +0100
 Kevin F. Quinn [EMAIL PROTECTED] wrote:
 
  People reporting bugs often get annoyed when their bug is marked
  INVALID; especially when they're relatively new to the Gentoo
  Experience.  We've all seen it many times, I'm sure.
  
  Arguably no bug is invalid in the normal sense - if someone raises
  an issue, they have an issue, regardless what we think of it.  To
  that end I'd like to propose bugzilla be reconfigured to use the
  phrase NOCHANGE instead of INVALID.  NOCHANGE would indicate
  that whatever the original issue, no change is needed on our part to
  resolve the issue.
 
 _If_ it's changed then please to something else, NOCHANGE would
 overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't
 that obvious to me at least. A fake resolution that's mentioned on
 IRC from time to time is NOTABUG which would fit better here.

Well, I meant for NOCHANGE to be no change needed, but figured
NOCHANGEREQUIRED is a bit longwinded.  It implies the issue is
understood, it has been explained to the bug reporter, but requires no
change to anything:

CANTFIX: the problem exists, but no sensible way to fix it exists
WONTFIX: the problem exists, but for some reason it won't be fixed
WORKSFORME: can't replicate

NOCHANGE: no change needed

The problem I have with NOTABUG is pretty much the same problem I have
with INVALID - it's not as severe, but it still does the same thing to
the user (i.e. slaps him with a wet fish rather than a frozen one).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

[Kevin F. Quinn]

On Sat, 24 Mar 2007 14:48:25 -0400
Michael Cummings [EMAIL PROTECTED] wrote:

 On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote:
  People reporting bugs often get annoyed when their bug is marked
  INVALID; especially when they're relatively new to the Gentoo
  Experience.  We've all seen it many times, I'm sure.
  
 But sometimes, just sometimes, the bugs are absolutely 100% invalid.
 Emerging nano broke my apache (random fake example with two
 unrelated packages)(or...are they...?)

Well, if someone raises a bug, they have an issue.  They may not
understand it properly, and may frequently mis-diagnose it, but there's
still an issue for them.  To take your example, emerge nano broke my
apache actually implies that apache isn't working properly for the
reporter - just because they incorrectly assign blame to an emerge of
nano doesn't mean everything is peachy.  As the details are eked out of
the reporter, the summary may become ssl support in apache broken with
openssl-1.2.3.4, IYSWIM.  We shouldn't be closing bugs as INVALID
just because the original reporter mis-diagnosed the problem.

There are cases where people raise a bug because they've mis-understood
something and they don't realise it's behaving correctly - i.e. the
behaviour they are complaining about is actually as-designed expected
behaviour.  But even then, the user had an issue - resolved by
the explanation, even if the outcome is no change to anything.
Closing it INVALID comes across too often as oh you're so stupid to
raise this as a bug and there's no need for that to happen, imo.
NOTABUG would do well enough in that sort of case I suppose, but
there's still an overtone of you shouldn't have raised this to it.

 More important is to explain
 to the user *why* it is invalid, and leave it open to them to argue
 and reopen the bug. Better communication,

Certainly good explanations as to why a bug is being closed are to be
encouraged.  My issue isn't with that - it's with the way that the
marking INVALID is perceived, when there's no need to be so harsh.

 not more convoluted closure
 flags, is the solution. IMHO. You know. Word.

The idea was to _replace_ INVALID with a less provocative name, not
add more closure flags.  I certainly agree that we don't need more
closure flags.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

[Kevin F. Quinn]

On Sat, 24 Mar 2007 22:02:48 +0100
Ioannis Aslanidis [EMAIL PROTECTED] wrote:

 I think that there is a problem of concept. If a bug is marked
 INVALID, it's because it is not a real bug. Marking a bug NOCHANGE or 
 NOCHANGEREQUIRED, not only overlaps with other resolutions, but fails
 to better explain the reason why the bug was closed, whereas INVALID
 indeed means that the reported bug is simply not a bug or that it was
 reported to the wrong place.

I don't think it overlaps, as I described before (whether it does or
not comes down to how you define it, of course).

As to knowing why the bug was closed, personally I would rather the
closure flag indicate the impact on the tree etc - i.e. whether
something was changed (FIXED), could have changed but didn't
(WONTFIX) or would have changed but couldn't be changed (CANTFIX) or
in no way indicated a change (NOCHANGE).

Bugs filed in the wrong place should just be re-assigned to the right
place, not closed INVALID (at least, not at the point where it's still
in the wrong place).

 Even though it might look harsh to the user to get such a resolution, 
 it's also harsh for the developers to have to handle bugs that are
 not related to them.
 
 Still, changing the name from INVALID to NOTABUG + NOTOURBUG does
 make sense, as the meaning doesn't get lost.

I don't think we need NOTOURBUG.  Anything that's a real bug, but not a
bug in what we do, can be marked UPSTREAM.

 
 Kevin F. Quinn wrote:
  On Sat, 24 Mar 2007 19:14:38 +0100
  Marius Mauch [EMAIL PROTECTED] wrote:
  
  On Sat, 24 Mar 2007 18:34:21 +0100
  Kevin F. Quinn [EMAIL PROTECTED] wrote:
 
  People reporting bugs often get annoyed when their bug is marked
  INVALID; especially when they're relatively new to the Gentoo
  Experience.  We've all seen it many times, I'm sure.
 
  Arguably no bug is invalid in the normal sense - if someone raises
  an issue, they have an issue, regardless what we think of it.  To
  that end I'd like to propose bugzilla be reconfigured to use the
  phrase NOCHANGE instead of INVALID.  NOCHANGE would indicate
  that whatever the original issue, no change is needed on our part
  to resolve the issue.
  _If_ it's changed then please to something else, NOCHANGE would
  overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't
  that obvious to me at least. A fake resolution that's mentioned on
  IRC from time to time is NOTABUG which would fit better here.
  
  Well, I meant for NOCHANGE to be no change needed, but figured
  NOCHANGEREQUIRED is a bit longwinded.  It implies the issue is
  understood, it has been explained to the bug reporter, but requires
  no change to anything:
  
  CANTFIX: the problem exists, but no sensible way to fix it exists
  WONTFIX: the problem exists, but for some reason it won't be fixed
  WORKSFORME: can't replicate
  
  NOCHANGE: no change needed
  
  The problem I have with NOTABUG is pretty much the same problem I
  have with INVALID - it's not as severe, but it still does the same
  thing to the user (i.e. slaps him with a wet fish rather than a
  frozen one).
  


-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

[Kevin F. Quinn]

On Sat, 24 Mar 2007 23:17:52 +0200
Alin Năstac [EMAIL PROTECTED] wrote:

 Kevin F. Quinn wrote:
  The problem I have with NOTABUG is pretty much the same problem I
  have with INVALID - it's not as severe, but it still does the same
  thing to the user (i.e. slaps him with a wet fish rather than a
  frozen one).
 

 Maybe, just maybe, the problem is not with the resolution name, but
 with peeps who cannot accept they could be wrong.
 For the most of us, INVALID doesn't mean YOUAREAMORON.

My point is that if someone raises a bug, they clearly have an issue -
if they didn't, they wouldn't have raised a bug.  Closing INVALID is
like saying they never had an issue - when clearly they did have an
issue, even if it was just an issue of understanding.

 A NOTOURBUG resolution would be pointless. I cannot imagine a possible
 scenario in which I could choose such resolution over the existing
 ones. Probably you want it as a replacement for UPSTREAM?

Er, I never suggested NOTOURBUG - as you say we already have UPSTREAM.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla

[Kevin F. Quinn]

On Sat, 24 Mar 2007 22:46:07 +0100
Marius Mauch [EMAIL PROTECTED] wrote:

 On Sat, 24 Mar 2007 22:07:08 +0100
 Kevin F. Quinn [EMAIL PROTECTED] wrote:
 
  Certainly good explanations as to why a bug is being closed are to
  be encouraged.  My issue isn't with that - it's with the way that
  the marking INVALID is perceived, when there's no need to be so
  harsh.
 
 And NOCHANGE could be perceived as We're not going to change this
 anyway,

No, that would be WONTFIX (or CANTFIX).  NOCHANGE implies there is
nothing wrong with the existing code, so there's no question of whether
we should change anything or not.

 so you're not really solving any problem by just changing a
 label. Some people will only ever be happy if they get the FIXED
 label on their reports.

I'm not sure that's so.  There are certainly many who don't like
their reports marked INVALID, at least initially.  I know I've seen many
instances where the word INVALID has got peoples hackles up, yet after
it's explained that it doesn't imply they shouldn't have raised the
report in the first place, they're ok (I've explained to people before
that the INVALID marking just indicates that there's no change required
to the tree). This is the same issue I have with NOTABUG - it's like
saying, you're wrong, shouldn't have raised the report, just perhaps
not as in-your-face as INVALID.


Still, it looks like I'm being out-gunned on this one, and I'm
starting to repeat myself, so I'll be quiet for a bit...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC Package name additions

[Kevin F. Quinn]

On Sat, 17 Mar 2007 10:46:22 +0100
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:

 One thing we could do would be to separate hierarchy from version
 naming.

This is where upstream version numbers fail to have a decent order
(like your example where later versions have lower version numbers).
It could be done for example by extending metadata to include
definitions of unnatural ordering, but I don't think it's worth the
effort.  So far we deal with that on a case-by-case basis, and live
with the pain when it occurs.

 This would prevent cases like currently with rosegarden (~)1.2.4
 (~)1.4.0 4.1.0-r1 4.1.0-r2, where it really should be 4.1.0-r1
 4.1.0-r2 (~)1.2.4 (~)1.4.0.

For example, a simple solution is to just re-number the (presumably
older) 4.* as 0.4.* and be done.  That would also solve the potential
future problem when the latest release reaches 4.* again. The sequence
I would do is:

  1) copy 4.1.0* to 0.4.1.0*, commit to the tree (here you could either
 rig the SRC_URI to keep the old tarball names, or copy the old
 tarballs again with the new revision number)

  2) Alter any packages that depend on the 4.1 versions explicitly, to
 depend on the 0.4.1 versions (after you're sure the new 0.4.*
 versions are in the tree).

  3) Remove the 4.1* versions - after a delay (a few days, a
 week, whatever, depending on how often your users are likely to
 update); in the changelog note that users should expect a
 downgrade and it is ok to do so.  As a minimum, delay until
 you're sure (1) and (2) have reached the rsync mirrors.

  4) Get 1.2*, 1.4* stablilised some time later in the normal way.

Actually a quick scan of the tree shows there's nothing affected by (2)
so that step can be skipped. I'd recommend still having a delay between
the copy (1) and the removals (3) - at least long enough for the copies
to propogate to the rsync mirrors before the removals happen (I'd
probably do the copy one day, check that got through ok the next day
and do the removals then). Noting the expected downgrade in the
changelog when the higher-numbers are removed is important (this is
what users will see if they do emerge -l).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Gentoo's problems

[Kevin F. Quinn]

On Fri, 16 Mar 2007 08:41:50 +
Steve Long [EMAIL PROTECTED] wrote:

 IMO ciaran has definitely been trolling this list and it's doing my
 head in. Is there anyone else who feels the same, strongly enough to
 risk his ire?

If you think Ciaran is trolling, just ignore him.  Be part of the
solution, not the part of the problem.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Summary for 15 March 2007 special council meeting on CoC

[Kevin F. Quinn]

I'd just like to say good job and thanks, to all involved in the CoC.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Why I don't think the CoC is a good idea

[Kevin F. Quinn]

On Thu, 15 Mar 2007 00:06:28 +0100
Alexandre Buisse [EMAIL PROTECTED] wrote:

 [...] But then, why do we need a Code of Conduct at all? There
 is nothing in it that people don't already know and if they choose to
 still commit the offense, it's either that they don't think it's one
 or that they choose to ignore the consequences and commit it anyway.
 In both cases, having a written code won't change a thing.

This is a good point; effectiveness is key, and in designing a CoC one
should be crystal clear what the document is expected to achieve.
In the defense of having a CoC, it does provide a document we can point
to when asking people who don't realise their behaviour is disruptive,
to moderate that behaviour.

Before we commit ourselves to a CoC, we should agree what the CoC
precisely is _for_ - setting out the document scope should be the
first priority.  Here are some examples of what I mean by setting a
document scope first:

The aim of the CoC is to encourage developers to work together
productively in a positive atmosphere.

The aim of the CoC is to provide a point of reference for developers
and users alike to decide if their behaviour is acceptable.

The aim of the CoC is to ensure Gentoo presents a professional image.

The aim of the CoC is to define what behaviour is acceptable for
Gentoo developers and users.

The aim of the CoC is to force all developers to adhere to an
Anglo-Saxon work ethic.

Just some examples; I'm not suggesting any are right, and some are
deliberately tongue-in-cheek.  What I'm trying to do, is highlight the
point that having a well-defined scope makes it easy to critically
and objectively examine what should and should not be in the CoC.

The scope can be decided in broad discussion - after which the CoC can
be drafted off-line and then presented for review against the scope
before final sign-off.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Distrowatch

[Kevin F. Quinn]

On Wed, 14 Mar 2007 23:40:54 +0100
Paul de Vrieze [EMAIL PROTECTED] wrote:

 ps. If someone wanted to start a gentoo-politics, by all means, go
 ahead, just don't expect anyone to read it.

That's not such a bad idea, really. I don't mean creating -politics as
such, but the idea of separating out these long debates from -dev, so
that -dev can focus on technical issues (is this eclass ok, last rites,
how do I do X,Y,Z in ebuilds etc).

When these big debates arise, discussion could be shunted to the
separate list, requiring those who care enough to join the debate, to
join that list, which may help limit the number of people who get
involved.  Perhaps gentoo-discuss.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo's problems

[Kevin F. Quinn]

On Thu, 15 Mar 2007 18:40:05 +0100
Jakob Buchgraber [EMAIL PROTECTED] wrote:

 So why don't you start rewriting, refactoring and improving the
 portage source? It definitely doesn't make sense to create a
 competing package management system.

Patches welcome, I think is the appropriate response :)

Seriously, if you want portage to be re-factored, just go ahead and do
it; there's nothing to stop you.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo

[Kevin F. Quinn]

On Tue, 13 Mar 2007 19:25:23 -0500
Grant Goodyear [EMAIL PROTECTED] wrote:

 [...]  The previous doc had no moral weight, so to
 speak, because it was imposed on devs without any real discussion, and
 that's made it hard to enforce.  Moreover, there's long been notable
 distrust of devrel, which historically made it hard for them to
 enforce it. My belief is that developer buy-in would make all of
 the difference in how effective a code of conduct would be.

I think developer buy-in is absolutely _critical_ for this to work.
Without it, the exercise will create more unnecessary ante between
devrel and the rest of devs, and it'll be much less successful, even
largely a waste of time.

For the record, 3 calendar days for comment is a ridiculously small
amount of time to achieve this.  You could put something in place
rapidly, if you want to be seen to be responding to the negative press
in various quarters, but it must be on the explicit understanding that
the CoC will be developed properly over a longer period of time.

Short timescale notwithstanding, here are my comments on the document
as a whole.  I don't have time to be soft and fluffy over this, so
forgive me if it comes across too strong.

I agree firmly with Grant, that the doc should be positive in its
wording throughout.  I sent a critique of the old etiquette guide to
devrel last week making exactly this point, however the new CoC still
weighs in first with negatives and punishments.  This is what happens
when the document is drafted rapidly in response to, for want of a
better phrase, a crisis in communications.

The emphasis should on the positive and on empowerment, not on
restriction and subjugation. For example, I'd start the document with
something like (written previously as a suggestion for the etiquette
guide):

  Developers are representatives of Gentoo; your behaviour as a
  developer reflects on Gentoo as a whole.  These simple etiquette
  guidelines are here to help you to ensure your own behaviour is a
  positive asset to the Gentoo project.

and I'd have statements like:

  Keep all your communications polite and focused on the technical
  discussion at hand.  If a respondent is rude, obnoxious, offensive or
  annoys you in any way, choose to walk away rather than waste your
  time responding to it.

As far as punishments are concerned, I wouldn't focus on specifics, but
on the general aim:

  The elected proctors have overall responsibility for ensuring good
  standards of behaviour in all Gentoo fora (mailing lists, IRC,
  forums etc).  They are tasked with taking appropriate action should
  problems arise.

(could equally be 'proctors appointed by the elected council')

Well, that's about all I can manage for now - don't expect a full
critique in such a short timescale...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Distrowatch

[Kevin F. Quinn]

On Wed, 14 Mar 2007 12:29:38 -0500
Dale [EMAIL PROTECTED] wrote:

 And something good is coming from it too.  They are setting up rules
 so that this sort of thing doesn't happen again.

I believe the move towards creating the CoC was in the pipeline before
these outside events took place; it was a response to the surge on
gentoo-dev itself, and as such an internally instigated matter.

The pressure to get the draft approved in the ridiculously short period
of three days in the middle of a week does look like it was affected by
the bad PR in junk outlets like DW.  If that is the case, then it is
most definitely a bad thing.

  The mess in the last
 couple weeks was not the first either.  It will happen again if
 nothing is done.

That's the exact opposite of my reading.  The so-called mess in the
last couple of weeks is nothing so unusual - happens every few months
or so, and IMO it's more about steam venting than the specific
issues at hand at the time.  Responding to the sort of pathetic
blogging seen on Distrowatch is a bad thing, its sends the signal that
rantings on the blog-o-sphere are due some respect, which the article
of the 13th certainly does not.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Distrowatch

[Kevin F. Quinn]

On Wed, 14 Mar 2007 18:18:58 +0100
Christian Faulhammer [EMAIL PROTECTED] wrote:

 Kevin F. Quinn [EMAIL PROTECTED]:
 
  So please, friends, just ignore it, nothing positive will come of
  it.
 
  Unfortunately it made its way onto big news site and lowers the view
 on Gentoo even more.  From many comments I read we are a dying distro.

Yeah; isn't the blog-o-sphere great :/  For a dying distro, we're
showing up pretty active on http://cia.navi.cx/ - but then I guess DW
aren't interested in anything so mundane as facts.  Perhaps they're more
interested in generating ad revenue from whipped-up scandals...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] mod_perl in apache conf

[Kevin F. Quinn]

On Thu, 8 Mar 2007 17:34:39 -0500
Michael Cummings [EMAIL PROTECTED] wrote:

 [...] (new subject line, so
 hopefully unless your mail client threads but message-id's this should
 break the chain)

 X-Mailer: Claws Mail 2.8.0 (GTK+ 2.10.9; x86_64-pc-linux-gnu)

I guess you realise now, if you didn't before, your mail program threads
correctly by references ;)

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-portage-dev] LC_ALL and friends in make.conf

[Kevin F. Quinn]

This is an old issue, but I want to suggest a re-visit :)

As we all know, setting LC_ALL and friends can cause all sorts of
trouble in package builds.  However, many users really appreciate
being able to set it so that errors from the compiler etc are in their
own language.

It occurs to me that during emerge, only LC_MESSAGES is actually useful
for the user, to help interpret build errors.  LC_COLLATE and the
others don't give the user any benefit in the emerge process.

So how about if LANG or LC_* are set, portage would set LC_MESSAGES and
clear the rest?

Is there any real advantage to the user having LC_* set apart from
LC_MESSAGES?

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Some council topics for March meeting

[Kevin F. Quinn]

On Sat, 3 Mar 2007 13:17:56 -0700
Daniel Robbins [EMAIL PROTECTED] wrote:

 So, again, since you are participating as a key member in an official
 Gentoo project, which is a developer-only privilege, you should either
 have your dev access reinstated or be removed from the project.

This is incorrect.  The full implication here is that only devs can
contribute significantly to Gentoo - which would be a big backwards
step, and something we have gone through a fair amount of heart-ache to
avoid.  We have evolved various ways in which users can contribute
valuable work; not just by posting into bugzilla (which was the only
mechanism available when I joined, shortly after you left I think) but
also working alongside proxy devs, or working in with devs in
overlays, working as Arch Testers and so on.  Personally I work with
several people who are not Gentoo devs, but are _critically_ important
to the work that I do for Gentoo.  After all, although we call
ourselves developers, really we're integrators.

Today, being a dev (which essentially means having commit access
to Gentoo repositories) is mostly about taking responsibility for what
is finally committed.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: Copyright, non-US devs and Gentoo Foundation vs Gentoo (Was: [gentoo-dev] Some council topics for March meeting)

[Kevin F. Quinn]

I note that FSF-Europe uses what it calls a Fiduciary Licence
Agreement to gain the ability to prosecute license violations for
software whose copyright is distributed amongst many owners.

Discussion here:
http://www.fsf-europe.org/projects/fla/fla.html

and the boilerplate for FTF's agreement in PDF here:

http://www.fsf-europe.org/projects/fla/FLA.en.pdf

This may be more appropriate than a straight copyright assingment as
used by FSF (US).

I guess this is an issue for the trustees, rather than the council, but
(b)cc'ed both for comment.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))

[Kevin F. Quinn]

On Thu, 22 Feb 2007 17:10:38 +0100
Marien Zwart [EMAIL PROTECTED] wrote:

 The
 idea was to not get any messy portage quirks documented as required
 standard behaviour, the risk here is that we'll now get paludis quirks
 documented as required standard behaviour.

Well, that'll come out in review later, I would expect.  I'll be
surprised if the EAPI=0 spec Ciaran et. al. are working on just gets
rubber-stamped without anyone looking!  This thread shows there are a
number of people who know what they're talking about and will review it
heavily when it is published as a draft, and the council are unlikely
to approve something that doesn't have broad support.

With respect to having a small relatively closed group for initial
drafting - it's a sensible way to do things in the early stages (it's
not the only sensible way of course). If anyone doesn't like it,
there's nothing stopping them from drafting their own in a different
way. Indeed, having two strong drafts would be good, for finding
idiosyncrasies from different perspectives.

I have to say, the few queries I've seen from Ciaran have been exactly
what I would (happily) expect.  Queries about whether some current
portage behaviours should be classed as quirks or EAPI=0 behaviour,
presumably because the answer has a large impact on the design of a
package manager.  A good example is the recent one about whether EAPI=0
should require that the ebuild be sourced in every phase or only once.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

[Kevin F. Quinn]

On Thu, 22 Feb 2007 19:08:48 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 The example given in ebuild(5) is:
 
 || (
 sdl? ( media-libs/libsdl )
 svga? ( media-libs/svgalib )
 opengl? ( virtual/opengl )
 ggi? ( media-libs/libggi )
 virtual/x
 )

Took me a while to figure out why anyone would want to write that; the
key is that ebuild(5) says only one of the conditions is satisfied;
i.e. even if all the dependencies are present on the system, the
package will build only against the first matching dependency.

The way I see it, the ebuild has to cater for the dynamic situation
anyway, for example doing something like:

src_configure() {
use sdl 
has_version media-libs/libsdl 
vid_conf=--enable sdl ||
use svga 
has_version media-libs/svgalib 
vid_conf=--enable svga ||
use opengl 
has_version virtual/opengl 
vid_conf=--enable opengl ||
use ggi 
has_version media-libs/libggi 
vid_conf=--enable ggi ||
vid_conf=--enable x11
...
econf ${vid_conf} ...
}

So the dependency could be re-written as:

 sdl? ( media-libs/libsdl )   
 !sdl? ( svga? ( media-libs/svgalib )
 !svga? ( opengl? ( virtual/opengl )
  !opengl? ( ggi? ( media-libs/libggi )
 !ggi? ( virtual/x ) ) ) )

and you have the same result, which means the originally quoted syntax
is redundant.  The only advantage it has is that it looks a little bit
prettier - but I'd argue the logic is clearer in the re-written version.

I guess the question remains, though - should that syntax be in EAPI=0
or not...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] A Gentle Reminder

[Kevin F. Quinn]

On Thu, 8 Feb 2007 22:34:32 +
Stephen Bennett [EMAIL PROTECTED] wrote:

 If any of you were thinking of removing the latest stable version of a
 package, don't. Even if you're the package maintainer, even if there
 are open security bugs against it, even if someone has filed you a bug
 requesting that it be removed. If it's the latest stable version on
 any architecture, you don't remove it. If you do, we'll know, and we
 won't be happy.
 
 There. It's not that hard to understand, is it?

Do you object to such packages (specifically with security issues) being
p.masked?

I'm not sure we should be encouraging people to continue using packages
when we know there are known security issues.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] A Gentle Reminder

[Kevin F. Quinn]

On Sun, 11 Feb 2007 12:33:52 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Sun, 11 Feb 2007 13:22:48 +0100 Kevin F. Quinn
 [EMAIL PROTECTED] wrote:
 | Do you object to such packages (specifically with security issues)
 | being p.masked?
 
 If it's forcing a downgrade, yes.

 | I'm not sure we should be encouraging people to continue using
 | packages when we know there are known security issues.
 
 You assume that being affected by a local denial of service on a
 system where all users have the root password is more important than
 using a package that has been verified to work by an arch team member.

I said nothing about local denial of service; perhaps you're thinking
of a particular instance - I'm not.  To rhetorically follow your line of
discussion, you're happy to have remote exploits remain in the tree
(i.e. promoted by Gentoo) if a package is marked stable and a patch
isn't available?

The point about p.masking (rather than removal) is that we have then
made reasonable efforts to inform the user and give them the
opportunity to decide what they want to do, based on their own security
policy - which could be to unmask locally and continue regardless, or
could be to remove the package and try something else.  That way they'd
be making informed decisions.

I think if we're to promote packages that have security issues on an
arch, we need to be very clear that we're not making reasonable efforts
to ensure that arch is free of known exploits.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] afflib licence (BSD4 like)

[Kevin F. Quinn]

On Wed, 7 Feb 2007 19:50:10 +1100
Daniel Black [EMAIL PROTECTED] wrote:

 Was looking at http://www.afflib.org/LICENSE.txt and was wondering if
 it really had any Gentoo implications with adding it as a package.
 
 I asked a few questions. Does the following seem reasonable?

Just one comment - we should maintain a list of packages that have this
sort of clause, so that it would be easy for releng (for example) to
either avoid mentioning them in the advertising for release media, or
to credit as required.  I'm thinking of the 2007.0 LiveCD is now out;
upgraded packages include: ... afflib n.m ... sort of announcement.

Personally, I would say that if we include credits for one package, we
should include credits for all - it hardly seems fair to
prominently highlight credits for a minor package like afflib, without
listing everyone else.  It'd be a massive list, of course, but it would
be fair :)

 [1] https://bugs.gentoo.org/show_bug.cgi?id=123175
 
 --  Forwarded Message  --
 
 Subject: Re: afflib licence
 Date: Wednesday 07 February 2007 09:56
 From: Simson Garfinkel [EMAIL PROTECTED]
 To: Daniel Black [EMAIL PROTECTED]
 Cc: Brian Carrier [EMAIL PROTECTED], Carl Hoffman
 [EMAIL PROTECTED]
 
 Hi, Daniel. Thanks for your email. We'd be happy to have you add
 AFFLIB to the Gentoo distribution.
 
 I'll answer your questions:
  Is inclusion in an online database like http://packages.gentoo.org?
  advertising and therefore subject to the clause 3?
 
 No, we do not consider that advertising.
 
  What happens if a security
  vulnerability is found and a GLSA (Gentoo Linux Security Advisory)
  is issued.
 
 We wouldn't consider that to be an advertisement either.
 
  What about a magazine article on Gentoo?
 
 We don't consider that to be an advertisement.
 
  The University of California, Berkeley revoked their clause 3 in
  1999 I
  believe because of similar legal vagueness over advertising.
  (ref: http://www.freebsd.org/copyright/license.html)
 
 Yes, I'm aware that they did this.
 
 We've decided to keep the advertising clause because Basis
 Technology, the company that funded a substantial amount of the
 AFFLIB development, wishes to be acknowledged in computer forensic
 products that use AFF.  We do not consider the bundling of AFFLIB on
 a CDROM or online distribution of Linux utilities to meet the
 requirements in section 3.
 
 Section 3 states:
 
 * 3. All advertising materials mentioning features or use of this
 software
 *must display the following acknowledgement:
 
 If your advertising of Gentoo mentions features or use of AFFLIB,
 then we would expect you to say that AFFLIB is a product of Simson
 Garfinkel and Basis Technology. But if you are merely including the
 code and not mentioning the fact that you include AFFLIB in your
 advertisements, then you have no need to mention Simson Garfinkel or
 Basis Technology in your advertisements either.
 
 I hope that this email clears up any questions that you might have.
 But if you have others, please feel free to drop me an email.
 
 -Simson
 
 On Feb 6, 2007, at 6:58 AM, Daniel Black wrote:
  Simson,
 
  Was looking at the afflib product and was considering adding it to
  the Gentoo
  distribution when I looked at the license and found the BSD-4
  license variant.
 
  The problem with the particular license is the condition 3
  advertising clause
  and its vagueity.
 
  Is inclusion in an online database like http://packages.gentoo.org?
  advertising and therefore subject to the clause 3? What happens if
  a security
  vulnerability is found and a GLSA (Gentoo Linux Security Advisory)
  is issued.
  Is this an advertisement? If Gentoo does a booth at an Expo is this
  included?
  What about a magazine article on Gentoo?
 
  The University of California, Berkeley revoked their clause 3 in
  1999 I
  believe because of similar legal vagueness over advertising.
  (ref: http://www.freebsd.org/copyright/license.html)
 
  Can you consider doing the same?
 
  Other references:
  http://farragut.flameeyes.is-a-geek.org/articles/2007/01/08/a-
  shadow-lies-upon-all-bsd-distributions
  --
  Daniel Black [EMAIL PROTECTED]
  Gentoo Foundation
 
 ---
 


-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] New network config for baselayout-ng

[Kevin F. Quinn]

On Wed, 7 Feb 2007 15:11:39 +
Roy Marples [EMAIL PROTECTED] wrote:

 THE CONFIG FILE HAS TO BE PARSEABLE BY ANY SHELL

Well, to be precise, it has to be parse-able by whatever runscript (-
runscript.sh) uses to source it.  Currently that's hard-wired
to /bin/bash; you're suggesting it be hard-wired to /bin/sh instead -
but it could be configurable as an option to runscript:

#!/bin/runscript --shell=/bin/sh

 EVERY SHELL HAS TO BE PATCHED TO UNDERSTAND BASH ARRAYS
 
 Simply put, this has to work where /bin/sh is any valid POSIX shell.
 
 #!/bin/sh
 . /etc/conf.d/net

Another idea; have baselayout install different versions of
init.d/conf.d and default shell for runscript depending on USE flags

USE=posix - install posix 'sh' versions of conf.d/init.d scripts, have
runscript default to /bin/sh

otherwise install the bash versions with runscript defaulting
to /bin/bash.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] New network config for baselayout-ng

[Kevin F. Quinn]

On Wed, 07 Feb 2007 23:14:14 -0500
Doug Goldstein [EMAIL PROTECTED] wrote:

 Mike Frysinger wrote:
  On Wednesday 07 February 2007, Roy Marples wrote:
  Welcome to baselayout-ng
  
  please god do not use this name ... just call it baselayout-2
  -mike
 
 Mike how about... yabl.. or ya-baselayout..

How about baselayout-nb (No Bash) :)

More seriously baselayout-posix, if posix-compliance of all scripts is
a primary motivation.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Hardened USE flag

[Kevin F. Quinn]

On Tue, 06 Feb 2007 00:15:25 -0400
Luis Francisco Araujo [EMAIL PROTECTED] wrote:

 Hello World!
 
 I want to ask for suggestions and opinions for the best way to handle 
 this bug:
 
 http://bugs.gentoo.org/show_bug.cgi?id=158434

 [textrels in smalltalk shared librart libgst.so]

 I am usually very hesitant to add new use flags to the tree (unless
 they are *really* necessary or imply a great advantage.) ; though i
 am not sure here if anybody else would consider this a good
 recommendation for handling textrels.

In general, we would urge maintainers to default to no-textrels for
shared libraries; normally the performance impact is negligible
(often the performance is better, overall).  It would be worth
obtaining some real statistics before deciding.

Note that textrels in shared libraries are pretty much an x86-only
thing.  amd64 in particular does not tolerate textrels in shared
libraries (PIC is cheaper on amd64).

 I was thinking more of a simple 'use hardened  myconf= .. '
 specific line for this ebuild; but it's probably a good idea offering
 to more developers the easy choice of this feature through a USE flag?

I think 'use pic' would be more appropriate, because we're talking
about whether we want position-independent code or not (but I defer to
solar in these things).

 If it looks enough useful for many people; then i think we can
 proceed to implement it; if it will only be used by this ebuild; then
 i am already against it ;-)


-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Network configuration and bash

[Kevin F. Quinn]

On Tue, 6 Feb 2007 19:09:26 +
Roy Marples [EMAIL PROTECTED] wrote:

 The stuff that handles our networking maybe written in A.N.
 Other-Language (Mrs.), but keeping /etc/conf.d/net readable by a shell
 script does have advantages.

You need to define what shell (or subset) you want to parse it.  'sh'
itself varies from platform to platform.  The one we have is a softlink
to bash so doesn't make any difference for Gentoo Linux except for
limiting what can be written.  I just tried variable redirection for
example (which can be used to implement pseudo-arrays without using
eval) - I was surprised it works in sh here - dunno if it works in BSD
sh (doesn't on busybox).  What you have on FreeBSD may be different from
what's on Solaris.

Perhaps busybox sh might be a practical set to choose, for basic posix
compliance.


You could simply do something like:

ifconfig_eth0=\
  10.1.1.1 netmask 255.255.255.0;\
  10.1.1.2 netmask 255.255.255.0

which means standard shell interpretation doesn't lose information, even
if it's actually normally parsed by something else (chose ';' as a
separator since ':' is used in ipv6 strings).


It seems to me that the problem you're trying to solve, is the
implementation of baselayout on restricted systems.  Reducing all
init.d/conf.d and so on to a common denominator for everyone isn't
necessarily the best way forward.  A different approach could be to
provide more than one baselayout; one for large systems, where
expecting to have bash available isn't such a big deal, and one for
limited systems, restricted to busybox-standard sh.  Actually I kinda
assumed that's what baselayout-lite was all about...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Network configuration and bash

[Kevin F. Quinn]

On Tue, 6 Feb 2007 23:26:32 +
Roy Marples [EMAIL PROTECTED] wrote:

 On Tue, 6 Feb 2007 21:28:04 +
 Ciaran McCreesh [EMAIL PROTECTED] wrote:
 
  I think it's more that you're expected to justify *why* the bash
  requirement is so bad, given the cost of changing.
 
 1) Lack of choice.
 Gentoo is all about giving the user choice. baselayout even supports
 other init systems when requested.

Surely you would provide choice by providing different baselayout
packages; one tailored for embedded systems that only have busybox, one
for general purpose use, etc.  That's what the virtual is for, isn't it?

 2) Speed.
 Bash is one of the slowest shells around for looping.
 However, it also requires less forking due to it's nice built-ins.
 This does of course only work with bash and not other shells.

Restricting everything to 'sh' I think is more likely to slow things
down than anything else.  Apart from the forking issue that you
mention, builtins are different - '[' for example is about 30% slower
than '[[' in bash (which is what's implementing sh on Gentoo Linux).  I
wonder how much time would be saved on Gentoo Linux by replacing [ with
[[ throughout the init scripts; maybe a percentage point?

If there really is a big speed penalty from using bash on BSD compared
to the native shell, wouldn't it be better to supply a Gentoo/FreeBSD
baselayout?  They don't have to be completely independent; smart use of
the vcs would allow you to share scripts between baselayout branches,
with specific variants where it makes a difference.

 3) What's the cost of *not* changing away from bash?
 I would say that bash is the best shell around in terms of features
 and ease of use, however that is not without cost. That cost is new
 bash versions consistently breaking baselayout, ebuilds and configure
 files.

w.r.t new bash versions, we should certainly be conservative in marking
new versions stable.  It's worth noting the breakage isn't always
100% the fault of bash. The recent problem with '=~' and quoting for
example is down to glibc behaving differently to everyone else's libc
when it comes to accepting quoted characters for the regex interfaces
(a point where the POSIX standard is open to interpretation).

 4) Size.
 Because bash has all these nice features it's large, hence unsuitable
 for low memory or low disk space environments.

But you only get one bash text image in memory at any one time (~825k).
So space isn't a real issue, except on small-memory systems.

 5) I'm *just* talking about config files here.
 If users want to run bash, that's fine and I won't stop them. They can
 also use bash in their init script if they so wish as I plan to
 support something like so
 
 depend() {
shell bash
 }

Making that sort of requirement explicit is a good idea.  I wouldn't use
'depend()', as in init scripts it's quite cleanly only to do with the
order of services.  You could make it an option to runscript:

#!/bin/runscript --shell=/bin/bash

or something along those lines - the shebang is clearly all about how
the script is executed, and the shell used falls nicely into that.

 And voila, problem solved. Of course, that's just an idea I just had.
 However, I also think that baselayout provided services should not
 require bash for the above reasons, hence the need for a new config.

I think the argument for conf.d files is better than that for init.d
scripts; you could have multiple baselayout setups that share conf.d
file formats.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for February

[Kevin F. Quinn]

On Sat, 03 Feb 2007 14:04:49 -0600
Ryan Hill [EMAIL PROTECTED] wrote:

 Kevin F. Quinn wrote:
  It would but having some kind of deadline after which you are for
  example free to take over the package if you want to would be nice.
  
  That's going too far; there's certainly no need to take over a
  package just to get a fix in.  If you want to take over a package,
  asking the current maintainer has to be the first step, not to
  quietly wait for a timeout then just grab it.  Similarly asking the
  current maintainer if they mind you putting a fix in.
 
 That's of course a given.  I think the question here relates to
 non-responsive maintainers or herds.

Well, this thread didn't start with MIA devs (which is what you're
talking about), it started with devs being too slow to take action.

I wouldn't have a standard timeout (far too regulatory) - just apply
common sense and do what needs to be done.

 I have been in the situation
 many many times with gcc-porting where I file a bug with a simple
 patch (say removing extra qualification) to get a package to build
 with GCC 4.1, and get no response for months from the maintainer
 despite multiple pings.  In that case, i'll apply the fix myself. I
 always try to wait a month or more before going ahead and always ping
 at least once.  So far i've not received any major complaints, but
 i'm just waiting for the day someone will get territorial about their
 packages and decide rip me a new one.  It'd be nice to have some kind
 of asshole insurance.

Well, my experience so far has been that provided you fix stuff
decently (both technically and politically ;) ), people don't mind
Maintainers can always tweak later if they prefer a different
solution.  If things get antsy, there's always devrel to mediate.

One obvious point, is to check a dev's away status if they're not
responding, before diving in.

 This also affects things like treecleaners.  How long does a herd team
 or maintainer have to be unresponsive to warrant the package falling
 into maintainer-needed?  Right now the most common way we find these
 packages is when Jakub gets annoyed enough with the accumulating bugs
 and lack of response to CC us. ;P
 
 I personally think that for bug fixes a month is a long enough wait to
 allow someone to respond.  Keep in mind that's to respond, not to fix
 the bug.  A simple yep, i'll get to this later is enough.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Maintainer Timeout

[Kevin F. Quinn]

On Fri, 2 Feb 2007 10:19:21 -0600
Grant Goodyear [EMAIL PROTECTED] wrote:

 [lots of good stuff]

I was going to respond to Timothy's proposal in much the same way - but
Grant has said everything much better than I would have done!

+lots Grant :)

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Monthly Gentoo Council Reminder for February

[Kevin F. Quinn]

On Thu, 01 Feb 2007 22:19:57 +0200
Petteri Räty [EMAIL PROTECTED] wrote:

 Ciaran McCreesh wrote:
  On Thu, 01 Feb 2007 20:36:29 +0200 Petteri Räty
  [EMAIL PROTECTED] wrote:
  | I would like the council to discuss if we should have a policy on
  how | long to wait for a developer to respond to a non critical bug
  before | you can fix it yourself.
  
  Wouldn't that depend highly upon the bug?
  
 
 It would but having some kind of deadline after which you are for
 example free to take over the package if you want to would be nice.

That's going too far; there's certainly no need to take over a package
just to get a fix in.  If you want to take over a package, asking the
current maintainer has to be the first step, not to quietly wait for a
timeout then just grab it.  Similarly asking the current maintainer if
they mind you putting a fix in.

If that approach doesn't succeed, it should then be put in the hands of
devrel to arbitrate.  I don't see that anything more is needed.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [RFC] Depending on active version

[Kevin F. Quinn]

On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner [EMAIL PROTECTED] wrote:

  Hmm; one could get the same benefit by introducing a new interface
  (e.g. pkg_env_check()) which is defined to return true if the
  environment is ok, false otherwise (with some text to stdout,
  perhaps). The package manager would then run this function, after
  building the depgraph and finding the candidate packages to merge,
  for each candidate package - if any package fails is env_check,
  none of the packages get emerged.  Note this is then completely
  independent of depgraph creation.
  
  In the 'tr1' example, I'd imagine something like this:
  
  use.local.desc: boost: Use boost library for tr1 rather than gcc's.
  
  ebuild:
  
  ...
  inherit ... toolchain-funcs versionator ...
  ...
  DEPEND=... boost? ( dev-libs/boost ) ...
  ...
  pkg_env_check() {
  use boost  return 0
  version_is_at_least 4.1 $(gcc-version)  return 0
  echo Either USE boost, or switch to gcc later than 4.1
  }
  
  
  (with a default definition, pkg_env_check() { return 0; } )
 
 In an ideal system you'd want this stuff in the metadata cache so that
 the resolver can deal with it up front.

You're talking about the metadata on the host, rather than the stuff on
the rsync servers?  I'm not sure you could cache the results even on
the host - you would need to know what could affect the results so as
to know when the cached information is out of date and has to be
recalculated.  That would either have to checked on every emerge, or
made a separate switch (i.e. rely on the user to tell emerge when the
environment has changed).

  All resolution is a brute
 force metadata search; and assuming we had all the necessary data up
 front, we can optimize the search there (see pkgcore and restriction
 subsystem) versus IMHO doing a 'dumb' search and then running through
 a list of criteria for inclusion.
 
 This is the same reason why built_with_use in pkg_setup is really just
 use_deps; these metadata should be included during resolution, not
 after.

My concern about dynamic dependencies runs to use deps, as well :)
One could consider use-deps to be a special case of Marius' active
checks.  how pkg P was built isn't so different from slot S of P is
active in terms of dep-graph creation; both are asking about the
state of host  target systems, rather than the tree.

In the case of USE deps, things are saner because the data doesn't
change without the package manager knowing about it.  Effectively the
depgraph becomes static w.r.t. the tree + installation record (rather
than just static w.r.t. the tree).  With active checks implemented in
the depgraph, however, that is no longer the case - the depgraph can
change independently of the tree and the installation record.

 With that said, I'm not sure how easy it would be to rewrite that
 code; and this is simpler in that it's just a few bash functions as
 opposed to more resolver foo.

There's a lot to be said for keeping things simple, of course :)  It's
easy enough to mess up things like dep-graphs in any case - introducing
these sorts of dynamic dependencies can render it substantially more
complex.

Another way to look at it, is to consider how often this sort of thing
comes up.  My understanding is that it is relatively rare; across the
10,000+ packages in the tree only a handful use 'built_with_use' fex.
That makes a strong case for having a simple solution in the near term,
and re-visit if it becomes commonplace.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Changing licenses/BSD

[Kevin F. Quinn]

On Sat, 13 Jan 2007 20:44:24 +0200
Petteri Räty [EMAIL PROTECTED] wrote:

 Anyone oppose the attached patch for making the BSD license more
 readable? I just came across this way for writing it in one package
 and think it would be easier to understand this way.

Surely the best thing would be to make it identical to the template at
opensource.org: http://www.opensource.org/licenses/bsd-license.php

This means just removing the redundant '*'s from the continuation lines.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] deprecating /etc/make.profile

[Kevin F. Quinn]

On Wed, 10 Jan 2007 22:30:32 -0800
Ned Ludd [EMAIL PROTECTED] wrote:

 On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote:
  On 1/11/07, Marius Mauch [EMAIL PROTECTED] wrote:
  
   And I assume there is a non-trivial number of custom scripts out
   there using make.profile, but that's nothing we can do about.
  
  
  You could give them all a grace period for which have to comply with
  the new standard by then end of it, and have ( during that grace
  period ) an automatic symlink generation based on that make.conf
  flag.
  
  And just to make sure, I doubt it would be too difficult to have an
  application that analyises packages as they install to check whether
  they reference make.profile or not, and flag a QA warning if they
  do.
  
 
 
 
  And packages that don't switch to the standard by the end of the
  grace period I guess we'll see on a last rites bulletin ;)
 
 Or we/gentoo could just support it and stop breaking the end user. 

A simple expedient would be to have the package manager re-create the
symlink according to the variable, whenever it is run.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

[Kevin F. Quinn]

On Tue, 9 Jan 2007 23:23:55 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Tue, 09 Jan 2007 14:41:50 -0800 Zac Medico [EMAIL PROTECTED]
 wrote:
 | Bug #161045 [1] requests that portage support RESTRICT=sandbox.
 | This is certainly a valid request but a user may wish to reject a
 | package based on certain questionable values of RESTRICT. 
 
 If a RESTRICT value is questionable, it shouldn't be supported or
 used.
 
 Honestly, this strikes me as rather silly and rather dangerous.
 RESTRICT is not something about which the end user should have to
 know or care; it should be something entirely between ebuilds and the
 package manager. And sandbox is not something that should be turned
 off lightly; making it so easy will only encourage developers to take
 the nasty way out rather than fixing simple bugs.

I agree; it'd be useful to know exactly what is failing the sandbox and
why, with the aim of fixing sandbox if it isn't quite up to the job.

The only shortcoming I'm aware of in sandbox is bug #135745 (have
fopen/open() fail normally if the file does not exist, rather than
report a violation).  Waiting on azarah to roll a new sandbox version,
I think.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*

[Kevin F. Quinn]

On Sat, 6 Jan 2007 05:21:48 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:

 On Saturday 06 January 2007 05:10, Alon Bar-Lev wrote:
  Is there any reason why not setting latest as default for
  WANT_AUTO* variables?
 
  I believe that an ebuild should set these variables only if there is
  some exception.
 
 that seems like a not-too-shabby idea actually

Not sure.  Would we run the risk that working ebuilds would start to
fail when newer autotools versions arrive?

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] GPL-2 vs GPL-2+

[Kevin F. Quinn]

On Wed, 3 Jan 2007 10:18:51 +0100
Paul de Vrieze [EMAIL PROTECTED] wrote:

 I know that I'm a bit late on this, but to me the version 2 or
 later is a license by itself. Let's call it GPL-RENEW and let the
 file have contents like:
 This package is licensed with the version x or later clause for the
 GPL.

This is effectively what Diego was proposing with the 'GPL-2+' name.

 The LICENSE would then be:
 LICENSE=GPL-2 GPL-RENEW

 The advantage being that the renew clause is version independent, we
 don't lose information, don't have to mutilate licenses (by adding
 text). If desired it could even be used as LICENSE=|| (GPL-2 GPL-3)
 GPL-RENEW

This isn't necessary - by creating the 'GPL-2+' license name, the only
thing that's not fully correct as things stand is that packages that
can be accepted with GPL-2 or later won't be accepted if the user has
just GPL-3 in ACCEPT_LICENSES.  Over time this can be fixed, by
replacing GPL-2 with GPL-2+ in the LICENSE variable for the
relevant packages.

The the meaning of each license name would be strictly:

GPL-2 : Only licensed under GPL v2
GPL-3 : Only licensed under GPL v3
GPL-2+ : Licensed under GPL v2 or later

Which gives everyone what they need; those wanting GPL-2 or later would
have ACCEPT_LICENSES=GPL-2 GPL-3 GPL-2+.


For me, the only other sane alternative would be to use license groups
(assuming license groups can be specified in the LICENSE variable).  I
don't recall the status of license groups in portage.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] GPL-2 vs GPL-2+

[Kevin F. Quinn]

On Sun, 24 Dec 2006 18:05:48 +
Stephen Bennett [EMAIL PROTECTED] wrote:

 On Fri, 22 Dec 2006 21:56:54 +0100
 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:
 
  GPL-2:
  Note: this license states that the software is licensed under GNU
  General Public License version 2, and you might not be able to
  consider it licensed under any later version.
  
  GPL-2+:
  Note: this license explicitly allows licensing under GNU General
  Public License version 2 or, at your option, any later version.
  
  Comments, ideas, proposals?
 
 From a purist point of view, I'd be inclined to go with this route.
 Pragmatically though, given the number of packages that do have the
 or later clause compared to the number that don't, it might be
 simpler to split them into GPL-2 (implying or later) and
 GPL-2-only. That's just a possible naming quibble though -- the idea
 I like.
 
 The suggestion to convert all GPL-2-or-later packages to || ( GPL-2
 GPL-3 ) won't scale -- what happens when GPL-2.1 or GPL-3.1 appear?
 It's also an awful lot of work for something that is, when you get
 down to it, wrong.

I agree.  Diego's proposal works fine in practice; the 'might not' in
the description for GPL-2 makes it clear that we don't guarantee to
have updated all existing ebuilds to use the GPL-2+ name where
appropriate.

Doing it on an opportunity basis should be fine, so I don't think we
need to worry about doing GPL-2-only.  Saying GPL-2 when GPL-3 is also
acceptable isn't critical in the near term; it won't cause people to
install stuff with a license they don't accept. It won't really be
needed until someone wants to have GPL-3 stuff but no GPL-2-only stuff
- I think it's reasonable to avoid supporting that for a while, at
least.  If we start now, with all new commits having GPL-2 changed to
GPL-2+ if appropriate, after a while we can change the GPL-2
description to be GPL-2 only and let GPL-3-only people (there's
always one) bug about packages that are still unchanged when they hit
them.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Big change ideea

[Kevin F. Quinn]

On Wed, 06 Dec 2006 23:44:26 +0200
Alexandru Mincu [EMAIL PROTECTED] wrote:

 http://www.gobolinux.org/
 They have an idea that Mac OS X implemented it when it first came out
 to be more user friendly.
 They are trying to remove the old UNIX file system scheme with the/bin
 /etc /usr /var, etc directories and are trying to implement a little
 more intuitive version of the file system hierarchy.

This is an idea that comes up quite often, especially with people who
come from the Microsoft or Mac world.  As far as Gentoo is concerned,
it is quite a lot of work (although not particularly difficult) for very
little gain.  The primary motivation for GoboLinux seems to be to make
it easy to find which files go with which applications.  You already
have that information of course, in /var/db/pkg/.../CONTENTS. 

Indeed, it would be trivial to do the GoboLinux thing but inverted -
leave everything where it currently is, and build a big tree of
symlinks from the places you want.  That's a lot of symlinks, however...

One last thing - their 'readdir' kernel hack (GoboHide) - that's
really nasty!  Hacking the kernel interfaces to deliberately break
compatibility is lunacy.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Versioning the tree

[Kevin F. Quinn]

On Mon, 27 Nov 2006 13:02:17 +
Stuart Herbert [EMAIL PROTECTED] wrote:

 On 11/27/06, paul [EMAIL PROTECTED] wrote:
  You can't take workload out of the picture since it's the main issue
  here. Stable tree means backport fixes and I don't see this
  happening as it can't be automated:
 
 Stable tree means backport fixes is an assumption, not a
 requirement.
 
 It's one reason why the word stable is a poor choice for any such
 tree, just as it is a poor choice for the current Portage tree.
 
 I think the original poster hit the nail on the head.  The real
 barrier preventing a slower-moving tree is cultural.

One method could be to snapshot all package versions at the time that
Release Engineering make a release, building a package.mask file out of
it masking out all packages of higher revisions (i.e. having 'CPVR'
entry for every package in the tree in stable, and 'CPVR' if no
versions are stable).

Then, rather than back-port security fixes, this list would be updated
with security-fixed version numbers, along with minimum required updates
to dependent packages. The lists could be stored in the tree; for
example as profiles/default-linux/x86/stable.mask.

Obviously maintaining that list is some work; predominantly watching
the announcements from the security team and fixing up dependencies,
and masking out new packages (for what that's worth).  It could be
regenerated on some or all releases, or perhaps on a yearly basis.  It
would also mean that versions listed there cannot be removed from the
tree (until they're bumped in the list).

Some of that maintenance could be tool-assisted; in particular masking
new packages and finding the minimum required bumps to support a
package that was bumped for a security fix.

People who want to use it could then just soft-link
from /etc/portage/package.mask to that list.

It's just a suggestion - I'm not prepared to do the work ;)  However it
might be a simple but effective method to help people maintain secure
but relatively stable systems, without having to upgrade umpteen
packages a week.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Kevin F. Quinn]

On Mon, 27 Nov 2006 10:53:43 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:

 On Monday 27 November 2006 10:48, Marius Mauch wrote:
  Mike Frysinger [EMAIL PROTECTED] wrote:
   On Sunday 26 November 2006 18:38, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
 is there a way in the new GLEP to say never bother me with
 any license bullcrap ?  i made sure the current
 check_license() function respected the idea of * so that i
 can put this in my make.conf: ACCEPT_LICENSES=*

looks to me like check_license() will effectively ignore '*' in
ACCEPT_LICENSE:

...
local shopts=$-
local alic
set -o noglob #so that bash doesn't expand *
for alic in ${ACCEPT_LICENSE} ; do
if [[ ${alic} == ${l} ]]; then
set +o noglob; set -${shopts} #reset old shell opts
return 0
fi
done
...

It then falls through to interactively requesting confirmation.

Not directly, you'd need to define a local license group
including all licenses (could automate that with a postsync
hook I guess) and use that in ACCEPT_LICENSE.
  
   in other words, your only proposed solution is a hack ?
 
  If you want to word it that way: yes.
 
 so why arent we providing a real solution ?

As I understand it, they're providing a solution that goes as far as it
can without violating the licenses themselves.  So you'll be able to
specify all the licenses that don't require explicit acceptance at
installation (@NOT_MUST_HAVE_READ, in the glep proposal), you just won't
be able to say '*' to include the licenses that require explicit
acceptance as well.  Since some licenses always have to be excluded,
allowing * would be misleading because it wouldn't be allowed to
match all licenses.  Some of the licenses that can't be wildcarded or
grouped are the games licenses from ID Software, for example.

From Chris Gianelloni, earlier in the thread:
 We don't want to support ACCEPT_LICENSE=* including the interactive
 licenses, since that *would* be skipping the requirements on the
 license.  This has been discussed on the bug report, already
(re. bug #152593)

I think the sort of license text this is trying to address is:

 YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AGREEMENT, YOU UNDERSTAND 
 THIS AGREEMENT, AND UNDERSTAND THAT BY CONTINUING THE DOWNLOAD OR 
 INSTALLATION OF THE SOFTWARE, BY LOADING OR RUNNING THE SOFTWARE,
 OR BY PLACING OR COPYING THE SOFTWARE ONTO YOUR COMPUTER HARD DRIVE
 OR RAM, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS 
 AGREEMENT.

in particular the download  installation bits (loading, running being
user concerns, not sys-admin/portage concerns).  IANAL so of course I
can't say whether the proposed rules are necessary and sufficient.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-dev] Announcement: New(ish) eclass pax-utils.eclass

[Kevin F. Quinn]

Hi peeps.

I added an eclass (a utility class, rather than a real eclass) to
abstract PaX flag management from ebuilds into a central place where we
(hardened project) can maintain the use of the tools which manipulate
the PaX flags.  These tools are still evolving, and we need to continue
to support them as they do so. Abstracting their use into a simple
interface allows us to do so without having to hack around in ebuilds
all around the place.

Although I committed it originally almost a year ago, it hasn't been
used yet, so if there's anything fundamentally wrong with whole thing,
now is the time say as it can be removed with impunity.

I did consider adding the functions to eutils.eclass, but I prefer to
have it separate.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Kevin F. Quinn]

On Tue, 21 Nov 2006 14:03:08 -0500
Chris Gianelloni [EMAIL PROTECTED] wrote:

 On Tue, 2006-11-21 at 17:59 +0100, Kevin F. Quinn wrote:
  Am I correct in thinking that the ACCEPT_LICENSE behaviour will just
  affect how portage calculates whether something can be installed or
  not (much like the behaviour w.r.t. KEYWORDS)?  In this is the case,
  interactivity doesn't have much to do with it.  As Brian suggests, a
  RESTRICT=interactive seems to be the most appropriate way to allow
  the admin to prevent portage from trying to install packages that
  need interaction during the install (whether it's for inserting CDs,
  accepting licenses, or any other reason).  It depends on what
  ACCEPT_LICENSE means to the package manager.  I take it to mean
  that the package may be considered for inclusion during emerge -
  i.e. the sysadmin is happy for portage to attempt to install
  packages under those licenses onto the system - rather than that
  licenses are actually accepted by the admin or user.  If that's
  correct, perhaps naming it ACCEPTABLE_LICENSES would be clearer.
 
 It is used to mask the package, correct.  When a package is masked, it
 gives the output of the license, or, if the license it too large (I
 think Marius set it at 20K) informs the user to read the license file.
 It also explains to the user that they will need to read and accept
 the license.
 
 RESTRICT=interactive should be restricted to only the contents of
 the ebuild.  ACCEPT_LICENSE=RTCW-ETEULA emerge enemy-territory is
 *not* interactive,

That's what I've missed then.  I didn't realise that setting
ACCEPT_LICENSE would inhibit the interactive confirmation that the
license has been read.  It means that ACCEPT_LICENSE is a list of
licenses that have been accepted (which is not what I thought it was).

 whereas emerge ut2004-data always is.  This is
 exactly why we are trying to keep licensing separate from ebuild
 interactivity. They are not the same thing, at all.
 
 ACCEPT_LICENSE needs to be used for backwards compatibility.  It is
 being used currently by many Gentoo users, myself included, for
 licenses which I have accepted.  ACCEPT_LICENSE is very much like
 ACCEPT_KEYWORDS.  We don't use ACCEPTABLE_KEYWORDS, do we?

The suggestion to use ACCEPTABLE_LICENSE was to highlight the
difference; i.e. that ACCEPT_LICENSE means matching licenses have
actually been accepted, rather than ACCEPTABLE_LICENSE meaning licenses
that the system owner allows users to accept.  Since ACCEPT_LICENSE does
affirm the license has been accepted, ACCEPTABLE_LICENSE would be wrong
and that suggestion goes down the pan.  In retrospect it's complete
garbage.

  Some packages require each user to accept the license explicitly
  when it is run (e.g. Acrobat Reader), some require it to be accepted
  explicitly during install (Enemy Territory) - in neither case should
  portage be taking automatic responsibility for actually accepting
  the license.
 
 It isn't.  The package manager will not be accepting anything.  The
 *system administrator* does the accepting... just like if I were to
 emerge enemy-territory now.
 
  On naming - please can we avoid calling any group NOT-something.
  Since the ACCEPT_LICENSE syntax allows -license, it's much better
  to use affirmative names always; in this case for example
  INTERACTIVE-INSTALL-ACCEPTANCE instead of NON-MUST-HAVE-READ.  One
  can define
  
ACCEPTABLE_LICENSES=* [EMAIL PROTECTED]
  
  easily enough.
 
 Except we don't want that.
 
 We don't want to support ACCEPT_LICENSE=* including the interactive
 licenses, since that *would* be skipping the requirements on the
 license.  This has been discussed on the bug report, already, but
 unless we made * not really equal *, then it won't work, as it
 won't fill the requirement that the license is accepted.

OK that's fine.  I'd still like to see a positive rather than a
negative name, but I admit I can't think of a good one to cover what
NOT-MUST-HAVE-READ would cover.  Following the discussion about *
from the bug (#152593 for those who don't know), I can see why
you'd rather not have a positive list of restricted licenses.  The best
name I can think of to replace NOT-MUST-HAVE-READ, is UNRESTRICTED.
That clearly doesn't say anything about interactivity - it's just a
list of all the licenses that have no restrictions on the operation of
portage.

 Now, I ask everyone to go read the bug before posting any more
 comments, since most of this has been discussed quite a bit there,
 and doesn't need to be rehashed.

I didn't realise there was a bug (#152593) - I was responding to the
posting of the GLEP and discussion I've seen here recently.  I've read
it now...

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] amd64 and ia64 keywords

[Kevin F. Quinn]

On Sat, 21 Oct 2006 13:36:04 -0400
Jonathan Smith [EMAIL PROTECTED] wrote:

 ia64 is for itanium, which was 
 intel's horrid first attempt at a 64-bit successor to x86.

I wouldn't call Itanium a successor to x86, any more than SPARC was
(recall that early Sun boxes were x86).  As you mentioned, it's a
completely new architecture.

All those years people have been bashing Intel for the limitations of
x86 that have been retained for decades for compatibility
reasons (limited register set, nasty CISC, ever-increasing instruction
set) - they try to do the design-from-scratch thing and it just gets
ignored.  AMD jump in and do what Intel had always previously done -
extend the existing architecture by bolting on extra stuff - and clean
up in the marketplace (or at least, hit Intel hard).

If you want to call any architecture horrid, I'd suggest x86, which
from a programmer's perspective has evolved into a real mess. x86_64
alleviates some nastiness (register set is now workable, pc-relative
addressing is possible), but adds some more of its own.  Of all the
processor architectures I've worked with, modern x86 is far and away
the muckiest from the point of view of an embedded software engineer.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: per-package default USE flags

[Kevin F. Quinn]

On Fri, 13 Oct 2006 13:53:27 +0200
Simon Stelling [EMAIL PROTECTED] wrote:

 Paul de Vrieze wrote:
  I would go for the EAPI bump. Even then I think it would be smart
  to wait a short while for packages to use this as we ensure that
  the supporting portage version is stable.
 
 Err, EAPI was designed to assure that a supporting version is
 actually used, no need to wait then.

Although obviously nothing using such an EAPI version could go stable
until a supporting version of portage goes stable on all relevant
arches (I think of EAPI as an implicit BDEPEND on the package manager
version).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 04 Oct 2006 15:09:06 +0200
Natanael Copa [EMAIL PROTECTED] wrote:

 What you didn't need to be a gentoo dev to be a package maintainer?
 Lets say anyone could be marked as maintainer in an ebuild. When
 there is a bug, the package maintainer fixes the bug and submits an
 updated ebuild/patch whatever. This person has no commit access.
 
 Then a committer, a gentoo-dev (someone with little more
 experience), just take a quick look at it and commit it.

This already happens on some packages (in particular where the upstream
author is happy to maintain the Gentoo ebuild).  One very important
thing is for the Gentoo proxy dev to be listed in metadata.xml (as
well as the non-Gentoo maintainer).

The Gentoo dev takes formal responsibility for any commits.  The trick
is to find a Gentoo dev who is prepared to proxy for you; that involves
a trust relationship between the dev and the maintainer.  The amount of
work the dev has to do depends on how well the maintainer follows the
Gentoo ebuild rules.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 4 Oct 2006 11:44:07 -0400
Thomas Cort [EMAIL PROTECTED] wrote:

 On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
  On Wed, 04 Oct 2006 09:41:45 -0400
  Alec Warner [EMAIL PROTECTED] wrote:
 
  My view is that while they're being actively supported, there's no
  reason to remove them.  Granted their mostly SpanKY's babies, but so
  what?
 
 My view is that currently we cannot offer the same level of support
 for the minority arches as the majority arches because we don't have
 enough people involved.

We don't need to.  Gentoo isn't just one single thing, and I see no
reason to require that all projects and arches offer the same level of
support.  Each project and arch can make their own determination about
what level of support they can and will offer.  Embedded users, for
example, are generally more technically-oriented to start with so need
far less support than, say, non-technical x86 users.

 I think that spreading the developers too thin
 leads to conflict and burnout. Look at NetBSD and debian. They are
 trying to be everything for everyone. How is that working for them,
 how is it working for us? I think we should be more focused, but
 that's just my opinion.

Minority arches don't affect devs who aren't interested in them, so
they have no impact on how spread out the developers are.  Effectively
you're saying that those involved in the minority arches should stop
messing about with that and commit all their Gentoo time to mainline
activities, which is obviously not sensible.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 4 Oct 2006 11:44:07 -0400
Thomas Cort [EMAIL PROTECTED] wrote:

 On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
  On Wed, 04 Oct 2006 09:41:45 -0400
  Alec Warner [EMAIL PROTECTED] wrote:
 
  My view is that while they're being actively supported, there's no
  reason to remove them.  Granted their mostly SpanKY's babies, but so
  what?
 
 My view is that currently we cannot offer the same level of support
 for the minority arches as the majority arches because we don't have
 enough people involved.

We don't need to.  Gentoo isn't just one single thing, and I see no
reason to require that all projects and arches offer the same level of
support.  Each project and arch can make their own determination about
what level of support they can and will offer.  Embedded users, for
example, are generally more technically-oriented to start with so need
far less support than, say, non-technical x86 users.

 I think that spreading the developers too thin
 leads to conflict and burnout. Look at NetBSD and debian. They are
 trying to be everything for everyone. How is that working for them,
 how is it working for us? I think we should be more focused, but
 that's just my opinion.

Minority arches don't affect devs who aren't interested in them, so
they have no impact on how spread out the developers are.  Effectively
you're saying that those involved in the minority arches should stop
messing about with that and commit all their Gentoo time to mainline
activities, which is obviously not sensible.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 4 Oct 2006 11:39:07 -0400
Thomas Cort [EMAIL PROTECTED] wrote:

 On 10/4/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
  On Wed, 4 Oct 2006 09:21:08 -0400
  Thomas Cort [EMAIL PROTECTED] wrote:
 
 The minority arches like mips, sparc etc seem to get along
quite happily.
  
   Not the minority arches like m68k, s390, alpha, ...
 
  I haven't seen any significant numbers of complaints. What exactly
  about those arches do you think is a problem?
 
 The speed at which bugs are resolved is the problem. Keywording/stable
 bugs can sit for months and sometimes over a year without being
 touched.

So?  Who is complaining?  Open stabilisation bugs are a concern for the
relevant arches, not for everyone. Once an arch has actioned a
stabilisation bug, they remove themselves from CC, after which they
don't care.

 Some people think the amount of time some arches lag behind
 is acceptable, I don't. The primary reason why arches lag is that we
 don't have enough people doing the testing and keywording.
 
  You should only raise expectations when you know you can follow
  through, not the other way around.  Raising expectations before
  being able to follow through leads to disappointment, which is bad.
 
 I think that if we implement my suggestions (drastically reducing the
 workload), we will be able to meet those expectations.

All that will happen if you ditch the minority arches, is that the devs
involved will take their work into overlay or possibly leave Gentoo
altogether.  It won't improve anything for other arches.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 4 Oct 2006 14:18:54 +0100
Ciaran McCreesh [EMAIL PROTECTED] wrote:

 On Wed, 4 Oct 2006 15:02:17 +0200 Kevin F. Quinn
 [EMAIL PROTECTED] wrote:
 | Yuck.  Devs should be free to add whatever packages they like,
 | provided they're willing to maintain them.
 
 There're already some restrictions:
 
 http://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree?
 
 Perhaps they should be enforced...

Yes, I have no objections to there being rules about what can and
cannot be added to the tree, and the ones in your devmanual are
clearly sensible and should be applied.  I do however object to the
suggestion that adding a package to the tree be subject to formal
approval (by whom, for a start...).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 4 Oct 2006 09:21:08 -0400
Thomas Cort [EMAIL PROTECTED] wrote:

   The minority arches like mips, sparc etc seem to get along quite
  happily.
 
 Not the minority arches like m68k, s390, alpha, ...

I haven't seen any significant numbers of complaints. What exactly
about those arches do you think is a problem?

   - Reduce the number of projects by eliminating the dead, weak,
   understaffed, and unnecessary projects
 
  Weak: Be more specific.  What are the weak projects, and why?
 
 Projects that don't achieve anything, have no goals, and don't show
 any promise of doing anything productive.

By specific I meant which projects exactly - i.e name some, and
explain how the weakness you perceive is a problem.

  Understaffed: this issue manifests itself as a project being slow to
  update.  However the only place this is an issue is for security
  issue management.  Another solution to under-staffing is to reduce
  expectations.
 
 The more we reduce expectations, the more it will hurt users. We
 should be raising expectations and following through.

You should only raise expectations when you know you can follow through,
not the other way around.  Raising expectations before being able to
follow through leads to disappointment, which is bad.

  Unnecessary: again, be more specific. What are the unnecessary
  projects, and why?
 
 Projects that aren't needed to further Gentoo and are not helpful to
 users or developers.

Again, by specific I meant which projects, by name, do you think meet
those criteria.  Explain why you consider those projects to be a
hindrance to users or developers.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

[Kevin F. Quinn]

On Wed, 04 Oct 2006 09:41:45 -0400
Alec Warner [EMAIL PROTECTED] wrote:

 Thomas Cort wrote:
  - Drop all arches and Gentoo/Alt projects except Linux on amd64,
  ppc32/64, sparc, and x86
 
 I can perhaps see some of this stuff dying.  Like all of SPanKY's
 weird ass arches; I have no idea why they are in the tree.  Cool
 yes...Useful? debatable.

My view is that while they're being actively supported, there's no
reason to remove them.  Granted their mostly SpanKY's babies, but so
what?  If you're not using those arches, you don't need to get
involved.  Incidentally you only have to lurk in #gentoo-embedded to
see there are users trying Gentoo on all sorts of bizarre boxes; it's
something that is much less painful and much more flexible with Gentoo
than with any other distribution.

I don't like the idea that only stuff used by large groups should be in
the tree.  I think the criteria should hinge primarily on whether stuff
has an active Gentoo maintainer.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

[Kevin F. Quinn]

On Wed, 20 Sep 2006 10:05:00 -0400
Michael Cummings [EMAIL PROTECTED] wrote:

 On Wed, 2006-09-20 at 13:36 +0200, Simon Stelling wrote:
 
  Every license which a package in the portage tree depends on gets a
  package in the ``txt-licenses/`` category. Its ebuild must install
  the license text to ``/usr/shared/licenses/``. The initial version
  shall be 1 if there is no version specified.
 
 This doesn't make sense to me. I have a copy of every license used in
 the portage tree already in /usr/portage/licenses - why dup that
 again?

Plus the copies in /usr/share/doc.

 We already have an existing LICENSE keywording in the ebuilds,
 why not just focus on patching portage to allow a make.conf variable
 for allowed licenses and block based on that? 

Sounds good enough to me.  Perhaps two variables; ALLOW_LICENSES and
DENY_LICENSES (with wildcard support).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

On Thu, 07 Sep 2006 16:42:11 +0200
Simon Stelling [EMAIL PROTECTED] wrote:

 Carsten Lohrke wrote:
  One question remains: Is it needed/correct that Portage doesn't
  take blockers for architecture breakages into account? Such a
  line/prefix is easily changed and when someone - whatever the bad
  reason is - uses cvs commit, a real tree breakage is the cause.
 
 The behaviour is correct. The depstring in question was
 !app-text/hunspell-1.0, which means that you can't have
 hunspell-1.0 and kdelibs installed on a system at the same time.
 Reason for this could e.g. be file collisions that got fixed in
 hunspell-1.0.
 
 If the depstring was !app-text/hunspell-1.0 app-text/hunspell,
 (same as =app-text/hunspell-1.0, just retarded)  repoman would
 complain loudly.

1,$ s/hunspell/hspell/g

:)

To follow up in the use of a blocker - obviously blocking something
like kdelibs, a core part of a major package suite, against a utility
like hspell is less than ideal (to put it politely).  This was not the
case before - kdelibs and hspell could happily be installed on the same
system, just kdelibs wouldn't make use of hspell.  Adding the blocker
unnecessarily restricts the system, and was the wrong thing to do.

One point that illustrates this clearly, is that if kdelibs is blocked
by hspell, a corollary is that hspell should block kdelibs.  However
since hspell wasn't blocking kdelibs, you would fail to install kdelibs
until hspell was unmerged.  Unmerging hspell would allow kdelibs to
merge, then you could happily install hspell again and end up with a
confused dep tree.

Also, to my understanding, having configure automagically build support
for hspell if it's available on the system is not the way we're
supposed to handle such dependencies.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

On Sun, 03 Sep 2006 17:54:33 -0600
Ryan Hill [EMAIL PROTECTED] wrote:

 Kevin F. Quinn wrote:
  If you don't care whether a package is stable or not, just let the
  arch team go ahead and do what they need to do to stabilise when
  they wish to.  The role of package maintainer has nothing to do with
  stabilisation, which is the preserve of the arch teams.
 
 Um, sure it does.  We're not going to stabilize something without 
 attempting to contact the maintainer first.  If it's
 maintainer-needed we'll just go ahead though.

Yeah; I meant that ebuild maintainers don't do stabilisation, the arch
teams do, and that if the ebuild maintainer isn't interested in whether
the package is stable or not, they can leave it for the arch team (and
ATs) to do.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] [GLEP] Bugzilla access for contributors

[Kevin F. Quinn]

On Mon, 04 Sep 2006 00:59:44 +0200
Stefan Schweizer [EMAIL PROTECTED] wrote:

 An example for this has been obvious since the overlays project was
 established. Bugs for overlays should be filed on bugs.gentoo.org and
 will most likely get assigned to the developer/herd. This does allow
 a contributor to fix the bug but only to mark it as fixed in bugzilla
 when he is also an arch tester.

Is it not enough just to re-assign such bugs to the contributor?  The
reason devs can resolve bugs is that they have write access to the tree
and thus can incorporate a fix.  If something is in an overlay,
presumably the contributor has write access to that overlay, and should
be the assignee of the bug.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

[gentoo-dev] packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

triggered by bug #77751: hspell lists a non-gentoo.org address for
the maintainer email, the herd as maintainer-needed, and no other
addresses.

Is this sort of thing now ok?

I don't think it's a good idea for devs to be putting stuff into the
tree without taking responsibility for it.  I would expect that either
the herd is set appropriately (which means either the committer be a
member of the herd, or the herd explicitly agree to be proxy), or the
committer be listed as a maintainer email address along with whoever is
being proxied.  Further I believe bugs against such packages should be
assigned to the @gentoo.org address (proxy maintainer if there is one,
herd otherwise), and CC'ed to the proxied maintainer address.


Packages affected:

app-arch/rzip
app-portage/getdelta
app-text/hspell
net-misc/vnc
sys-fs/dmraidcvs

All of the above list a non-gentoo.org address as mainainer, but do not
have either a proper herd, or a specific gentoo.org dev listed as
maintainer.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

On Sun, 03 Sep 2006 13:57:10 +0200
Stefan Schweizer [EMAIL PROTECTED] wrote:

 Kevin F. Quinn wrote:
  I don't think it's a good idea for devs to be putting stuff into the
  tree without taking responsibility for it.  
 sure I can put myself in there but it will help no one because I
 cannot test the thing.

Then you should not have committed it - as a dev it is your
responsibility to test any ebuilds your commit.  There's nothing
stopping you doing the normal checks on the ebuild, even if you can't
read Hebrew.  For example you should verify whether the '-j1' is really
necessary on emake.

 Furthermore I am actually part of
 maintainer-needed and commit fixes there. I am also on the
 maintainer-needed email alias.

For a start, maintainer-needed is just a mail alias, it is not a
herd and never can be, by definition. See
http://www.gentoo.org/proj/en/metastructure/herds/herds.xml.

The point of a herd is to provide a contact for maintenance of the
member packages - and maintainer-needed by definition does not do
maintenance.

 Also maintainer-needed makes obvious to everyone that they do not
 have to ask me to fix sth. or take over the package - less
 communication overhead.

You can put notes into metadata.xml - see other instances for
examples; the easiest way is to have two maintainer entries, and in
the description field describe the maintenance arrangement.  Putting
maintainer-needed as the herd just means the package is essentially
unmaintained, and is a candidate for removal. We should not be putting
stuff into the official tree if no dev has taken responsibility for it.

  I would expect that either 
  the herd is set appropriately (which means either the committer be a
  member of the herd, or the herd explicitly agree to be proxy), 
 which is the case here.

See above - maintainer-needed does not satisfy the requirements of the
herd entry.

  or the 
  committer be listed as a maintainer email address along with
  whoever is being proxied.  
 the committer in this case has no interest in maintaining the thing.

Even more reason the package should acquire a dev to maintain it, or be
removed from the tree.

 And for proxying it does not matter who is proxying.

Proxying is more than just doing whatever the non-dev says.  By
committing to the tree, you take full responsibility for those
commits.

  Further I believe bugs against such packages should be 
  assigned to the @gentoo.org address (proxy maintainer if there is
  one, herd otherwise), and CC'ed to the proxied maintainer address.
 
 this does not allow the actual maintainer to close the bug and causes
 a lot of bugspam for a person who does not care about it and should
 be only contacted in the end to commit fixes/patches/bumps.

Whoever does the commit takes formal responsibility for those commits.
Therefore they should take note of bug activity relating to those
commits.  If they don't care about that then they should not be acting
as proxy in that case.


Surely this is what the Sunrise overlay was for; user-supplied ebuilds
that don't have a a Gentoo dev to take responsibility for maintenance.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

On Sun, 03 Sep 2006 16:22:37 +0200
Stefan Schweizer [EMAIL PROTECTED] wrote:

 Paul de Vrieze wrote:
  For this stuff, add a comment to the metadata.xml file. Don't do it
  in this less than obvious way. 
 
 arch teams for example will still contact me then for stabilizing, I
 do not want that. jeeves and herdstat do not support comments and the
 metadata is not often read directly.

If you don't care whether a package is stable or not, just let the arch
team go ahead and do what they need to do to stabilise when they wish
to.  The role of package maintainer has nothing to do with
stabilisation, which is the preserve of the arch teams.

  The maintainer must still be someone with a
  gentoo email.
 
 is that written down somewhere? I was under the impression that it is
 allowed and have seen it used for example
 in /usr/portage/www-client/links/metadata.xml

You'll notice that there are two maintainer blocks in there, one for
the non-gentoo third-party maintainer, and one for the Gentoo dev who
proxies - the official Gentoo maintainer.  There are several packages
like this.

What I'm conerned about is packages that have no Gentoo maintainer,
something that should obviously never happen for packages in the
official tree.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo 2006.1

[Kevin F. Quinn]

On Sun, 3 Sep 2006 17:44:32 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:

 On 9/3/06, Alec Warner [EMAIL PROTECTED] wrote:
  Because the thought that stable is always stable or that because
  we released things are stable is incorrect ;)
 
 You're not supposed to break the stable tree; that surely must include
 stabilising a compiler (which is the _default_ for new installs) that
 can't compile all the packages marked stable for your arch.

That's just not feasible, as we've identified before.  You can't expect
sys-devel/gcc to take responsibility for every package in the tree in
all configurations.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Gentoo 2006.1

[Kevin F. Quinn]

On Sat, 02 Sep 2006 12:34:38 +0200
Edgar Hucek [EMAIL PROTECTED] wrote:

 Apeal on extended testing :
 
 Developer, please test things more carefull before you 
 release it.

There are over 10,000 packages in the tree (11247 to be exact); each
of which can be built many ways with USE flags.  It is simply not
feasible to test all of the packages in all possible combinations in
all possible USE configurations for all architectures.  The number of
combinations is literally astronomical.

So, we test what we can, but rely on users to raise a bug in bugzilla
when a combination they try, that we haven't, fails.

 I already found things which does not compile out of
 the box.

So raise bugs on bugs.gentoo.org.  Make sure you include data about the
configuration of your system (i.e. the output of 'emerge --info').

 1.) Use wacom does not compile out of the box. You
 have to unmask linuxwacom.

Raise a bug, if one hasn't already been raised.

 2.) Enable the use flage accessibility gnome cant be
 merged. It fails on compile the speech-tools.

Raise a bug, if one hasn't already been raised.

 It seams that USE flags are not realy tested or how
 can it happen that there are already know bugs in the
 stable distro ?
 
 http://bugs.gentoo.org/show_bug.cgi?id=116030

 Festival and the speech-tools are well know not to
 compile with gcc =4.

Er, because the bug is not yet fixed.  If we were to hold up the
release of everything until all bugs are fixed, we'd never release
anything.

You have the power to sort out this problem on your own system.  Just
build the relevant packages with gcc-3.4.6 instead of gcc-4.1.1 (see
gcc-config for switching your selected compiler).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Portage Sets

[Kevin F. Quinn]

On Tue, 29 Aug 2006 07:57:43 -0400
Alec Warner [EMAIL PROTECTED] wrote:

 So I have implemented merging of sets (more or less) in a local
 portage branch.

Could you elaborate how the implementation of sets would differ from:

# emerge $(cat /var/lib/portage/myset)

where /var/lib/portage/myset is a file containing a list of atoms?
That would help in thinking what the behaviour could be.

I'm thinking that perhaps you do everything up to but not including
qmerge for all packages then do the qmerge phase for the set in one go,
provided they all got to install ok.  It might be useful to try to move
all actions that might fail during qmerge to the end of the install
phase (I'm thinking things like collision-detection, qa checks), so
that the only reason qmerge on the set would fail is lack of disk space.

Obviously that's simplifying somewhat - if there are build-time DEPEND
relationships between elements of the set, the set has to be broken
down into sub-sets that don't have such internal dependencies.  However
I can't think of much else you would do with sets that the $(cat
file) approach doesn't already supply.  Alternatively you could
require that sets must not have such internal dependencies.

  However there are some use cases for which the
 appopriate action is ambiguous.
 
 Use Case #1:
 Set1 = { postfix, gentoolkit, lsof, bind-utils, vixie-cron }
 
 A set of standard tools to be on a machine.  Assume a new install (ie
 none of the packages in Set1 are installed).  Is it an error if one of
 the packages in the set is masked or unavailable?  In this case I
 would say yes; if you instead just skip the masked package (say
 postfix in this case because it's convenient ) vixie-cron will pull
 ssmtp instead of postfix.
 
 Of course this will also occur if postfix is after vixie-cron in the
 set; but for our purposes we will assume the administrator put them in
 this order such that postfix will get pulled in.
 
 One could also say that the user should have used emerge -pv set1 and
 noticed that ssmtp is being pulled in instead of postfix.
 
 Use Case #2:
 
 Set1 = cat /var/lib/portage/world (the world set)
 
 Assume the world file has 100 packages in it, two which are masked,
 and three of which there are no ebuilds in the tree for.  If missing
 packages cause an error (which in use case 1 they should imho) then
 the user cannot update world without unmasking things properly.  The
 packages for which ebuilds are missing in the tree is in fact a
 portage bug(I think), and will probably need to be fixed.

For the initial merge case then an error before anything is merged is
good.  For an upgrade merge, a warning would be more appropriate
(perhaps becoming an error with FEATURES=stricter or similar).

 Other use cases for sets would be appreciated, as far as behavior.  It
 would probably be best to provide some sort of switch.

The most obvious use is to have a related group of packages that may
otherwise include a virtual, making the choice of that virtual explicit
(like your cron example above).

Other sets would be simply groups of packages that make functional
sense together, where perhaps one package might make little sense
without others in the set.  For example:

sylpheed-kev = ( sylpheed-claws sylpheed-claws-mailmbox \
sylpheed-claws-smime sylpheed-claws-rssyl sylpheed-claws-smime \
sylpheed-claws-vcalendar)

toolchain4 = ( \
~sys-devel/gcc-4.1.1 \
~sys-devel/binutils-2.16.1 \
~sys-libs/glibc-2.4 )

Are you considering allowing sets to contain other sets?  Then world
would contain the names of sets, not just CPs.

 Unmerging sets is also a fun one, I'm not sure if it's entirely
 appropriate yet.

Would it do anything more than:

# emerge -C $(cat /var/lib/portage/myset)

Perhaps it would unmerge any packages merged as dependencies of the
set that are no longer dependencies of anything else currently
installed - but I think that's better handled separately.

Ah; it occurs to me that unmerging a set should only unmerge elements
of the set that are not part of any other installed set (including
world).  So behaviour is less like 'emerge $(cat set)' and more like
emerge sets/set where sets/set/set-V.ebuild is like a meta-ebuild.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] Democracy: No silver bullet

[Kevin F. Quinn]

On Thu, 24 Aug 2006 09:50:04 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:

 We've had a global vision for where Gentoo is going from before I
 joined - Gentoo is here to create a source-based distribution where
 each package is as close to what $UPSTREAM intended it to be as
 possible.  We're not trying to take $UPSTREAM packages and innovate
 with them - we're here to do a first class job of packaging them up.

While that's generally the case, it's not always true; in particular
the hardened project deliberately causes stuff to be built differently
to the way upstream expect.

This illustrates that there is more than one vision, and what's good
about Gentoo is that we can support different visions without having to
fork the whole of Gentoo.  The increased use of overlays helps to scale
this up.

...
 We don't have a democracy.  Gentoo is largely a workocracy (there must
 be a better word for it ;), where the vast majority decisions are made
 by the folks who actually do the work.

Meritocracy, perhaps.

...
 *  Every staff member has to belong to a team.  You join a team by
 being voted onto the team by the other members of the team.  They
 don't vote you in, you can't join.
 *  If you're not part of any team, your rights and privileges as a
 staff member are automatically terminated.  There's no place to go to
 appeal.
 *  You can be voted off the team at any time.  The teams are
 self-managing.

I figured this is pretty much how it works at the moment, just without
the formality.  You don't just attach yourself to a team and start
stomping over the work of that team - acceptability of what you do is
by consent of the team.  The lack of formality means that if the
team doesn't explicitly object to something you propose (e.g. what you
propose doesn't affect what the rest of the team do, or if it does
they don't care), you can just go ahead.  Your summary implies explicit
consent from the team would be needed, which I don't think would be a
good idea.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature