[gentoo-dev] festival use flag

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

The following packages have festival as a use flag:

media-plugins/mythphone:festival - Enable festival support
media-radio/xastir:festival - Enable festival support

I would like to add this use flag to
app-accessibility/speech-dispatcher also.

Is 3 packages enough to move this use flag to global status?  If so, I
will do this if I hear no objections by Monday.

Thanks,

William

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDiMTkblQW9DDEZTgRAv12AJ9sclzbN/mW3ppGyO3gYosac1pO3gCdHbDT
9JkVmLLTTswC0+HisWPqx3A=
=e0th
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] xinetd use flag and xinetd files being installed

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 28, 2006 at 08:33:26PM -0500, Doug Goldstein wrote:
> How about the packages that don't even ask and just install logrotate
> stuff? Like Apache, lighttpd, and mysql?

What about xinetd?  The same thing is happening there.  I have some
files in /etc/xinetd.d but I do not use xinetd.

I don't really like the install_mask idea for this because you can't set
that on a per-package basis that I am aware of, and we have several
packages that have an xinetd use flag.

What do you all think?

William

> -- 
> Doug Goldstein <[EMAIL PROTECTED]>
> http://dev.gentoo.org/~cardoe/
> 


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3EB6blQW9DDEZTgRAuoCAKCw4y2yMizmPZxQaz8gMZ5nu2lf/gCdHMHu
gZ3NTUG0r6dWA2teNextCyM=
=W+pj
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Make logrotate a global USE flag?

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Jan 29, 2006 at 07:46:30AM +, Ciaran McCreesh wrote:
> We already had this discussion. It's not that it's another file, it's
> that it's another file in /etc, which is backed up and requires
> administrator attention on every upgrade. Packages shouldn't stick
> stuff in /etc on a whim.

If you are saying that things should not be put in /etc by a package
automatically for optional features, I agree with you there, and that is
why I support the "logrotate" and "xinetd" use flags.

William

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD3SHrblQW9DDEZTgRAiGuAKCoHMY5glKY3Fdaev7cAbOLtSYuxACgtvNP
pMJHIUa6gnkYYuayh8tnEZ4=
=5d0V
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] where to install source files for c++ templates

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I am working on version bumping app-accessibility/festival and
app-accessibility/speech-tools.

I can get them to build outside an ebuild fine, but I have found that
festival #includes actual source files from speech-tools to instantiate
c++ templates.

If I keep speech-tools as a separate package, where should these source
files be installed in the file system?  /usr/share/speech-tools?

The other option would be to not keep speech-tools as a separate ebuild,
but have the festival ebuild build speech-tools then build and install
festival.

Any suggestions would be appreciated.

William

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD8JnvblQW9DDEZTgRAukLAJ0X7VbH84N/PeJ/4Em8imOrohUs4ACfSmKc
6NklAdfappcX6NyVZ5AtYsU=
=pcsG
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] call for maintainer

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I am looking for someone who would be interested in taking
maintainership of the following:

app-accessibility/festival
app-accessibility/speech-tools

There are several open bugs against festival and requests to add some
new voices as well which I will assign to you.  I don't recommend doing
the voices as parts of the festival package itself though since you
would need to do a rev bump every time one of the voices does another
release.

If you are interested in maintaining these, please let me know.

Thanks,

- -- 
William Hubbs
gentoo accessibility team lead
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiDd24ACgkQblQW9DDEZTjYIQCfem5odjxI4hOjmJna33PPEUkf
ZagAn2ZXaK7e444EKsQkLd8ikyVtjCOE
=vcf9
-END PGP SIGNATURE-

Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Aug 06, 2008 at 02:18:05PM -0700, Robin H. Johnson wrote:
> Hi folks,
> Getting the bot out there
> -
> If you would like to have the new bot in your #gentoo-* channel, would
> each channel founder/leader please respond to this thread, stating the
> channel name, and that they are the contact for any problems/troubles.

#gentoo-accessibility

Thanks,

- ---
William Hubbs
gentoo accessibility team lead
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkib7y4ACgkQblQW9DDEZTibGACgq+9ZezFKXgD8fXwOuJjMjUuY
RncAnjVfW80RIrkDDlasu5kXi5gA/siY
=HWBl
-END PGP SIGNATURE-

[gentoo-dev] packages up for grabs

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I have a couple of packages in the accessibility herd which I need a
maintainer for.

app-accessibility/festival
app-accessibility/speech-tools

If anyone is interested, please let me know.

Thanks,

- ---
William Hubbs
gentoo accessibility team lead
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkidtcQACgkQblQW9DDEZTj3HQCfVwvAociTGgX7M12GrWK1olqY
rd4AnRD8OAFIyRN4eBFI48HETOS+pIti
=96mv
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: World file handling changes in Portage-2.2

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Aug 16, 2008 at 10:39:41PM +0300, Petteri R??ty wrote:
> Title: World file handling changes in Portage-2.2
> Author: Petteri R??ty <[EMAIL PROTECTED]>
> Author: Zac Medico <[EMAIL PROTECTED]>
> Content-Type: text/plain
> Posted: 2008-XX-XX
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >sys-apps/portage-2.2_rc8
>
> As of Portage 2.2 the world set does not include the system
> set any more. If you want emerge --update --deep @world to
> update the system set too, you need to add @system to the new
> world_sets file in /var/lib/portage/. For more information on
> world_sets see man portage.

This brings up a question.  I have been doing updates this way:

emerge -NDu @installed

Does that do the same thing?

Thanks,

- -- 
William Hubbs
gentoo accessibility team lead
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkinguMACgkQblQW9DDEZTiwZgCff3r0XtUR2iGGswpfTkWxEQcp
xisAoKZDrcjbh9T1SikiaASpyqqEKq/A
=e9j2
-END PGP SIGNATURE-

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Mar 08, 2009 at 10:01:05AM -0700, Donnie Berkholz wrote:
> > How would that work? I can't see an obvious way of doing it that isn't
> > more or less as verbose as just using multiple calls.
> 
> It would just eliminate all but one call to use_with(). Depending on how 
> many you've got, this can shorten things up a fair bit. Here's an 
> example:
> 
>   econf \
>   $(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
>   econf \
>   $(use_with x X) \
>   $(use_with foo libfoo) \
>   $(use_with bar) \
>   $(use_with python pygtk)
> 

I like this idea also, but I would prefer using something other than
spaces in each argument, like so:

econf \
$(use_with x:X foo:libfoo bar python:pygtk)

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmz/zUACgkQblQW9DDEZTgnugCgkTMUOCQUbcAs9qcvxxmt2Wna
BY4AoKAjdpzXkiiizFsQ8MKUmAwHxZMC
=lFam
-END PGP SIGNATURE-

[gentoo-dev] pybugz

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

if you are following pybugz, we have moved development from google code
(which is subversion) to github.  The url for the page there is
http://www.github.com/ColdWind/pybugz

Thanks,


- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAknFTyQACgkQblQW9DDEZTjxDgCglzxXajjSGUG+6Z5ksJ8FBoKu
mOoAoJFUnjdtotMbL0svdC3mkvk3Qje9
=MxtT
-END PGP SIGNATURE-

Re: [gentoo-dev] On git and pushing official gentoo branches

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gilles,

On Sun, Apr 26, 2009 at 11:55:55PM +0200, Gilles Dartiguelongue wrote:
> As many of you might already know, gnome switched to git about 2 weeks
> ago so I'd like to take a pick at what people do concerning upstream
> using git. How do you present patches you maintain for gentoo to
> upstream ? Own maintained git server, gentoo hosted git, others ?

Take a look at git format-patch.  You can put your local changes on a
local branch and create patches that would be able to be merged very
easily upstream.  Or you can just use git diff to create patches to
email upstream.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkn0xQgACgkQblQW9DDEZTgDCQCgjruR5O+qZihvyRks77B8f6fo
VaIAn1uyNIRdwJaKVaTEG/yzWahBj/R2
=FdHj
-END PGP SIGNATURE-

[gentoo-dev] rfc: pybugz command syntax

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I'm considering changing the pybugz command syntax to be something
similar to the way portage's syntax works.  For example, "pybugz get"
would become "pybugz --get", "post" would become "--post", etc to
simplify the command line parsing code.

Does anyone have an objection to something like this?

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoG87EACgkQblQW9DDEZThCCwCfY237fQy5GqcaRKSjWo2vLlTq
RSUAoLTEj/Xh0tx/hqtrAU7pStbgQ46O
=x1oN
-END PGP SIGNATURE-

[gentoo-dev] rfc: pybugz option conflict

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I have found an option conflict in pybugz, and I would like suggestions
for naming one of the options.

Currently we have two meanings for the --version option.

optparse wants to use --version to display the version of the program,
and we are using --version in the post command to set the version that
will be part of the bug.  What do you think we could use for --version
in the post command instead so that we can use --version to display the
program version?

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoIS9QACgkQblQW9DDEZTh8eACfaqCZN3d+SA8JYE8vaCrSy1Y+
S2IAn29zAWDT41DIQtDdkZSngzpEXSmZ
=pwh5
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: rfc: pybugz command syntax

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, May 11, 2009 at 10:13:44PM +0200, Christian Faulhammer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> William Hubbs :
> > I'm considering changing the pybugz command syntax to be something
> > similar to the way portage's syntax works.  For example, "pybugz get"
> > would become "pybugz --get", "post" would become "--post", etc to
> > simplify the command line parsing code.
> > 
> > Does anyone have an objection to something like this?
> 
>  You will break app-portage/gatt.  But I can deal with that. :)
> 

Actually, it has turned out that I didn't have to make this change, so
gatt should be ok. :-)

William

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

iEYEARECAAYFAkoIjPQACgkQblQW9DDEZTg8rQCfY4qQ9dEUHFnKX9VjU0Z2u1CP
bxoAoK5wK14uPbIcBi7QXBH4t/hvK6dR
=AmLz
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I realize that I'm asking this very late in the discussion, so please
bear with me if it has been hashed before.

On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote:
> We need a mechanism to be able to use newer bash-features in ebuilds.
> Preferably one that doesn't go "Wait a couple of years, hope
> everyone did X then Just Do it." We want one that goes like "Get a new
> EAPI approved with new minimum bash-version attached, start using cool
> stuff like ( Bash-4.0 ):
 
 

> Personally, I like the first version better. It would be cool if we
> could start using it sooner. GLEP-55 provides the "clean" solution, by
> just making the file name indicate what's inside. No need to parse, no
> nothing. Portage is currently testing a "first line with EAPI=
> determines EAPI" method. That's slightly less clean, but has the added
> benefit of not breaking anything that relies on .ebuild extension for
> ebuilds and I think it's not an unreasonable limitation on ebuilds to
> require EAPI= to be parseable by !bash.
 
I don't know how strong this argument is, but here is my opinion about
the issue, followed up with a question.

The second solution seems to be the better one because it does not go
against standards.  For example, we see extentions like .c, .py and
.pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
languages to tell which version of the compiler is compiling them as
needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
Isn't there a way the PM could find out which version of bash is being
run, compare that to the EAPI, then take appropriate action?

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoMkdUACgkQblQW9DDEZTihowCdEynGXsB0Z1r9y43VeWEs9JLF
SrQAn2iNPikCR+tZHGyrv+ykr4y1D+81
=6F5i
-END PGP SIGNATURE-

[gentoo-dev] EAPI Changes

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote:
> On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote:
> > Thanks Robin for finally pushing this in the tree, just didn't find the
> > time to.
> > 
> > Maybe it's a good time to emphasize this: Keep in mind that changing the
> > EAPI in an ebuild requires a revision bump (including reset to unstable
> > keywords, etc.).
> That's going to cause a large problem.
> 
> The entire point is that the STABLE ebuilds need to be changed,
> otherwise they will try to depend on the libusb-1 series (and fail
> dismally).
> 
> For switching from EAPI0 to EAPI1, if the ebuild still compiles fine,
> then I see no reason that a slot dep change cannot be just put in with
> the EAPI change. (The same cannot be said for EAPIx -> EAPI2, as further
> changes are needed for that case).
 
 As far as I know, the only time you need to do a rev bump and reset to
 unstable is if you change the files that are installed by the package.

 So, as far as I know, unless you are migrating to an EAPI that is not
 stable or changing the files that are installed by the package, it is
 not necessary to do a rev bump just for changing the EAPI as long as
 you make sure that the ebuild emerges fine under the new EAPI.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoNgNcACgkQblQW9DDEZTgorACdGfiXec4JUIC3UJDL/sGctbEi
FpwAn3UxUOjxuQUxl0w5S95M271+306Q
=jinO
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't reliably extract EAPI.
 
I just figured out a line in bash that will get an EAPI without
sourcing the ebuild:

eval `grep '^EAPI=' ebuildfile | head -n 1`

will set EAPI in the current scope to EAPI in the ebuild, without
sourcing it, unless the issue with something like this would be its use
of grep and head, but these are both in the system set, so unless you
don't want to depend on the system set, I don't know what the objection
would be.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoNxeEACgkQblQW9DDEZThaFACfYSQTpPTxfh3MzvErzbSNGZ8M
46AAoIyGTJxbWQ4Be7075uHXYN+hfnDl
=X3Wn
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 16, 2009 at 01:11:34PM +0200, Ben de Groot wrote:
> David Leverton wrote:
> > But the point isn't that we want to be able to do those things.  The point 
> > is 
> > that if the EAPI is in the filename, it's blatantly obvious that it has to 
> > be 
> > static, but adding strange and unintuitive restrictions on which shell 
> > constructs can be used is, well, strange and unintuitive.
> 
> Except that we aren't talking about strange and unintuitive. All we are
> saying is basically documenting current usage: put a line with EAPI=
> near the top. That's very straighforward and intuitive. Plus, it works.

Agreed.  The way I have always usedEAPI is, you set it once at the top
of the EBUILD and you are done with it.  As far as I know, there is no
reason to change EAPI once it is set, and eclasses shouldn't be changing
it.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPAX8ACgkQblQW9DDEZTizJACfarJ8hZh4WQ7GC0kuraqTba9u
FhkAn29jolc1O5D/jMWWA6TJaJcUZtbQ
=529O
-END PGP SIGNATURE-

Re: [gentoo-dev] The fallacies of GLEP55

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 16, 2009 at 07:14:00PM +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 13:10:07 -0500
> William Hubbs  wrote:
> > Agreed.  The way I have always usedEAPI is, you set it once at the top
> > of the EBUILD and you are done with it.  As far as I know, there is no
> > reason to change EAPI once it is set, and eclasses shouldn't be
> > changing it.
> 
> But eclasses have tried changing it. This is something people have
> done, not some hypothetical.
 
 I see that as an issue with those eclasses then; they need to be fixed
 so they don't change the EAPI.  They can test for it, but that is all
 they should do.  Maybe that needs to be documented somewhere if it
 isn't already.


- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPBGAACgkQblQW9DDEZThZ8ACdHK+5d2xjzAONo/IcuVPR3D5j
rTkAoLm4c3o7IVxh2kq3SD8aTUaB4ROb
=NjOq
-END PGP SIGNATURE-

[gentoo-dev] rfc: information on localstatedir

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I just submitted a patch today to fix an issue with brltty and it was
partially accepted.

The part of it that wasn't accepted is what brings me to this list.

I was told by the brltty developers that localstatedir should be /var.
I noticed, however, that econf passes --localstatedir=/var/lib to the
configure script.  The way around this was to pass the --localstatedir
option to econf.

My question for this list is, what is localstatedir supposed to be?

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoPYnIACgkQblQW9DDEZTj8LACfffvwtCe8e6zBk/aJKkatgPUR
nbcAoJH6vHTx7wtioxJuKsTBJbiV/qFA
=aDJ+
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: information on localstatedir

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, May 17, 2009 at 02:57:47PM -0400, Mark Loeser wrote:
> According to FHS we are doing it right:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
> 
> I guess what I would really like to know is...why does it matter?  If
> something is configurable like that, then it should work regardless of
> what is put in.
 
I guess it doesn't matter to me really; I was just looking for why we do
it the way we do since one of the brltty devs "strongly recommended"
that we change our build environment.


- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoQa8sACgkQblQW9DDEZThSygCeNBeribtJLB5MRx4QMeoElU9k
vzoAn2I3JG/bvcSMoWb4KRu7W9XDmOD4
=oHRJ
-END PGP SIGNATURE-

[gentoo-dev] rfc: Accessibility on our release media

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I need some opinions about accessibility on our release media.

I am requesting that we add the following to all of our release media
for amd64 and x86:

app-accessibility/espeak (with portaudio in use so it supports alsa)
app-accessibility/espeakup
app-accessibility/speakup
[alsa support]

This is needed so that a blind person can independently install gentoo
linux using either hardware or software speech.

Agaffney is stating that he doesn't want to add this support to the
minimal cd because it will increase the size of the cd and it is not
required to do an install.  He is willing to put it on the live cd.  I
think it should go there as well as go on the minimal.  I'm not
comfortable, however, with it just going on the live cd since the live
cds are not built near as often as the minimal cds.

I understand his point about keeping the minimal cd small, but I
disagree about the software not being required to do an install.  If a
blind person wants to install gentoo from a minimal cd, the software is
a requirement, not an extra feature that would be nice to have.

My question for the group is, how do you feel about speech software
being on our minimal cd as well as our live cd?

Thanks,

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoXDtYACgkQblQW9DDEZTgQcgCdG+nSnePDvIC/r9ahNDHQ84N5
56wAoJhjjorD5DbOdCs18W25iN71BjnG
=BgPY
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: Accessibility on our release media

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 22, 2009 at 11:58:32PM +0300, Petteri R??ty wrote:
> > I understand his point about keeping the minimal cd small, but I
> > disagree about the software not being required to do an install.  If a
> > blind person wants to install gentoo from a minimal cd, the software is
> > a requirement, not an extra feature that would be nice to have.
> 
> Could you/someone provide numbers on how much of an increase in size we
> are talking about?

Ok, the command I ran is:

equery size espeak speakup espeakup portaudio

This returns the following:

app-accessibility/espeak-1.40.02: total(304), inaccessible(0), size(2845230)
app-accessibility/espeakup-0.60: total(16), inaccessible(0), size(99234)
app-accessibility/speakup-3.0.3_p200904041142: total(34), inaccessible(0), 
size(257646)
media-libs/portaudio-19_pre20071207: total(43), inaccessible(0), size(554648)

So, somewhere between 3 and 4 mb, not including alsa support.

I realize that everyone wouldn't use this, but for those of us who do,
it does not fall into the category of a "nice feature to have", it is a
necessity.  So, I think it should go on both our live and minimal cds.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoXLJ4ACgkQblQW9DDEZTjwAgCgp2PMFeflAQ+FFjyNJetsqnef
TWgAoIOanI84dpjp0U3aicxQ77tLLKeG
=T/3e
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: Accessibility on our release media

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, May 22, 2009 at 07:40:43PM -0700, Josh Saddler wrote:
> Question: what kind of end-user configuration is required once the CD is
> booted to make use of it?
 
There is a patch with this bug, http://bugs.gentoo.org/267708 which
needs to be applied to livecd-tools.  Once that is done, we
need to put a bell character in the boot message for the cd so that it
will beep when the boot prompt comes up, and a very long timeout at
the prompt would help.  The reason behind this is so that there is no
doubt when the boot prompt is on the screen.

Once that is done, someone could do something like this at the boot
prompt:

gentoo speakup.synth=synthname

This will activate the speech and make sure X is not started.  If
speakup.synth=synthname is not on the command line, nothing will be
affected.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoXaX4ACgkQblQW9DDEZTjwmACff0reDQuOz/V4tD2jH94yoJF4
SrMAnRwVlVHNVxhE66sQj0Dr3WUbBuTr
=gNSh
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: Accessibility on our release media

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 23, 2009 at 07:32:18PM -0500, Dale wrote:
> Thomas Pani wrote:
> > On Sun, May 24, 2009 at 1:14 AM, Andrew Gaffney  wrote:
> >   
> >> The real issue here is the size. If these additional packages plus all of
> >> the alsa modules add 20MB to the minimal CD, it's just not worth it. It's
> >> not "minimal" anymore.
> >>
> >> 
> > Could you elaborate whom that change would affect (negatively)? 83MB
> > for current x86 isn't really "minimal" any more, anyway.
> > I don't see the difference between 83MB and 103MB:
> > - Makes no difference on blank CD (even those minis have ~200MB).
> > - Regarding download size, well, after the CD you'll have to get the
> > stage tarball and most probably source tarballs as well.
> >
> > --
> > Thomas Pani
> >
> >
> >   
> 
> For a person on dial-up, about 2 1/2 hours of additional download.  That
> said, I'd be OK with the increase in size if it would help a person who
> can't see the screen.
 
It is impossible for a person who can't see the screen to install gentoo
linux from our current release media unless they do what I did, which
was to have someone read the screen to me long enough to assist me with
starting an ssh server on the livecd and figure out the IP address of
the computer, so that I could ssh in from my second computer to do the
install.

In other words, putting this software on our media will not just
help, but make it possible for a blind person to install gentoo
independently.

Only adding the software to the live cd is not an option for me, because
I feel that all of our release media should be accessible.  Yes, there
will be a size increase for the release media, but, unless the alsa
modules and alsa-utils are over 15 mb, it will not be a 20 mb increase.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoYpmQACgkQblQW9DDEZThbRwCdGswP4rJIEkREb54LG9Z3PjjH
eF0AmQHXE6keEZDxA2r0bLe1rfakmR9C
=ThQY
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: Accessibility on our release media

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 23, 2009 at 08:12:17PM -0500, Dale wrote:
> Ferris McCormick wrote:
> >
> > If the 20MB is a real problem, I think the alternative is to have two
> > versions of the "minimal CD".  Otherwise it seems to me that Gentoo is
> > discriminating against people who cannot see the screen, and I would
> > consider that to be very tacky at best.
> >
> > Someone (rdalek1967) said the problem was an extra 2.5 hours time for
> > download over dialup.  If that is correct, we are looking at 12.5 hours
> > instead of 10 hours (about 25% increase, but 10 hours is a long time,
> > and I don't know that 12.5 hours is subjectively that much longer).
> >
> > So, to answer William's original question, one way or another we should
> > provide a minimal CD with the speech software on it in my opinion.

Keep in mind that if we produce a separate cd with the speech software,
that means yet another cd for each architecture that we know the speech
software runs on, so I think the better route would be to just put it on
all of our media that we produce for the affected architectures instead
of asking releng to produce a separate cd for each release or autobuild.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoYr30ACgkQblQW9DDEZTglhgCgtLVGTtFjMCn3CsLxcAddj9iQ
c7YAoLOnpvcO9aB+qeu+Ba19vPaPuxdN
=heml
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: Accessibility on our release media

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 23, 2009 at 09:47:24PM -0500, Dale wrote:
> Maybe I am being misunderstood.  I'm all for it even if it does make it
> bigger.  It's a good idea in my opinion.
 
 Hi Dale,

 no, I didn't misunderstand you, and I am sorry if I came across that
 way.  I just wanted to make sure that everyone here knows that this
 isn't just something that would "help" blind users to be able to
 install our distro.  It would do more than help, it would make it
 possible. :-)

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoYuyAACgkQblQW9DDEZTiyhwCdFnwZGghO0JfhT0PmTfU0elBY
fM8AnjXxOtQFWeDMTGYrsFXA3LrgMPf/
=9Dnm
-END PGP SIGNATURE-

Re: [gentoo-dev] Speech on the Gentoo Linux LiveCD

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, May 24, 2009 at 02:13:43PM -0700, Keith Hinton wrote:
> Hello,
> I would strongly recommend adding Speakup access into the Gentoo
> installation media, probably with software speech, as hardware speech
> is becoming quite outdated.
> Feel free to email me if you folks want offf-list to discuss some of this.
 
 Keith,

 we are going to add both.  Yes, there are some situations where
 hardware speech doesn't work, but because of speakup/espeakup's design,
 it is easy to add both.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoZuucACgkQblQW9DDEZThjyACfb1qKYPy0dv3SlEIA4CBBxfZb
B7UAoLd4AshG76+0AwFhvK1bZt3zjMTP
=ypal
-END PGP SIGNATURE-

[gentoo-dev] maintainer needed for app-accessibility/festival and app-accessibility/speech-tools

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

we have multiple open bugs for app-accessibility/festival and
app-accessibility/speech-tools.

These packages are very difficult to maintain and upstream appears to be
dead.

I am not interested in them, and I haven't heard from the accessibility
team member who joined to maintain them in many months.  So, after
several attempts to contact him, I am bringing these back to the list.

If someone wants to maintain them, please contact me.  Otherwise, I will
send them to the last rights graveyard this coming weekend.

Thanks,

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpSRgQACgkQblQW9DDEZThQFACgk30RfyB/1dQTgY3CdKwwPxLR
7z0AmwQOd4WAy1vnNsFw/yRNR6aHpQDq
=Zikj
-END PGP SIGNATURE-

Re: [gentoo-dev] maintainer needed for app-accessibility/festival and app-accessibility/speech-tools

[William Hubbs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jul 06, 2009 at 01:44:20PM -0500, William Hubbs wrote:
> we have multiple open bugs for app-accessibility/festival and
> app-accessibility/speech-tools.
> 
> These packages are very difficult to maintain and upstream appears to be
> dead.
 
The latest on this is that the package maintainer contacted me, so I
will be working with him on these for the next couple of weeks, then we
will see what happens from there.

- -- 
William Hubbs
gentoo accessibility team lead
willi...@gentoo.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpTc/kACgkQblQW9DDEZTikCACguK5iN34qsV9q3Q/CuSUB1pJ2
TSsAnRIfG/8on2cns5saXHgCm2Nuz6Hf
=+l5h
-END PGP SIGNATURE-

[gentoo-dev] rfc: virtual/modutils and module-init-tools

[William Hubbs]

All,

in preparation to unmask udev-181, it was brought to my attention that a
number of packages in the tree have direct dependencies on
module-init-tools. Udev-181 requires kmod, which is a replacement for
module-init-tools.

I have added virtual/modutils to the tree which as of now prefers
module-init-tools over kmod.

The dependencies on module-init-tools in the tree should be changed to
virtual/modutils. I am willing to do this myself if no one objects. If I
do, should I open individual bugs for the packages?

Also, this brings up another question. I replaced module-init-tools in
the system set with virtual/modutils.  But, since it is possible to have
a linux system with a monolithic kernel, should this even be in the
system set? If not, once the dependencies are correct, I propose
dropping virtual/modutils from the system set.

On the other hand, if we want virtual/modutils in the system set, there
should be no dependencies in the tree  on virtual/modutils.

Thoughts?

William


pgp4lnvXWSch3.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[William Hubbs]

On Sat, Feb 25, 2012 at 08:44:39AM +, Duncan wrote:
> You are however correct that it'll be on most systems, at least with 
> udev-181, since udev won't build without kmod, now.  (I found that out 
> when the build broke on me due to missing kmod, as I've had udev unmasked 
> for awhile and got 181 before kmod was added as a dep.)

But, one thing about kmod is that you can turn off the command line
portions of it completely on a monolythic system since udev just uses
the library. That is actually the main reason we are transitioning over
to kmod.

You do that by putting the following in /etc/portage/package.use:

sys-apps/kmod -compat -tools

William



pgpDh3MVxHmOp.pgp
Description: PGP signature

[gentoo-dev] newsitem: unmasking udev-181

[William Hubbs]

All,

here is the udev 181 unmasking news item.

If all goes well, this will be committed to the tree  on 3/14 UTC.

William
Title: udev-181 unmasking
Author: William Hubbs 
Content-Type: text/plain
Posted: 2012-03-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following url:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken


pgpQjiK64cSRR.pgp
Description: PGP signature

Re: [gentoo-dev] newsitem: unmasking udev-181

[William Hubbs]

Here is the latest version of the news item; this gives a few days
notification before the unmasking.

William

Title: udev-181 unmasking
Author: William Hubbs 
Content-Type: text/plain
Posted: 2012-03-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following URL:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken


pgpamWqYQoxOY.pgp
Description: PGP signature

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[William Hubbs]

On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
> On 3/10/12 6:53 PM, Rich Freeman wrote:
> > neither the genkernel nor dracut docs have specific instructions about
> 
> I guess we could pour more effort in getting dracut more easy to use 
> and/or try to figure out which are the items that should be moved to / 
> and fix the remaining ones...

I highly discourage moving more things to /.  If you google for things
like, "case for usr merge", "understanding bin split", etc, you will
find much information that is very enlightening about the /usr merge and
the reasons for the /bin, /lib, /sbin -> /usr/* split.

I'll start another thread about this farely soon, but for now I'll say
that even though Fedora is a strong advocate of the /usr merge, it
didn't start there. Solaris started this 15 years ago, and I think it
would be a good thing for gentoo to implement the /usr merge at some
point to make us more compatible with other unixes. Another thing to add
is that it appears that at least Fedora and Debian are doing this.

William



pgp1fJWnaHQT9.pgp
Description: PGP signature

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[William Hubbs]

On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
> On 11.3.2012 17.33, Zac Medico wrote:
> > On 03/11/2012 04:03 AM, Petteri Räty wrote:
> >> The Display-If-Installed atom shows the news item to stable users once
> >> it's committed. I am not sure at what point does Portage show it when
> >> the atom is >= so we might want to evaluate the options. 
> > 
> > It's displayed after the package is installed, before emerge exits, just
> > after the message about config file updates.
> 
> Based on this I think >= is better than < so people will get when they
> actually update.

That means that people won't be notified that they have the news item to
read until after they install >= sys-fs/udev-181.

Is that how we would want this to work?

William


pgpV3ferdlWbI.pgp
Description: PGP signature

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[William Hubbs]

On Sun, Mar 11, 2012 at 11:48:19PM +0200, Petteri Räty wrote:
> On 11.3.2012 23.43, William Hubbs wrote:
> > On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
> >> On 11.3.2012 17.33, Zac Medico wrote:
> >>> On 03/11/2012 04:03 AM, Petteri Räty wrote:
> >>>> The Display-If-Installed atom shows the news item to stable users once
> >>>> it's committed. I am not sure at what point does Portage show it when
> >>>> the atom is >= so we might want to evaluate the options. 
> >>>
> >>> It's displayed after the package is installed, before emerge exits, just
> >>> after the message about config file updates.
> >>
> >> Based on this I think >= is better than < so people will get when they
> >> actually update.
> > 
> > That means that people won't be notified that they have the news item to
> > read until after they install >= sys-fs/udev-181.
> > 
> > Is that how we would want this to work?
> > 
> > William
> 
> How do you plan to handle notifying stable users if you go with 

pgpnoemfZFO6r.pgp
Description: PGP signature

[gentoo-dev] rfc: location of portage tree

[William Hubbs]

All,

I know this has come up before, but I don't really recall what the
specific objections were.

IMO the portage directory doesn't belong under /usr at all.
I was chatting with another developer who uses
/var/cache/portage/{tree,distfiles}, and I'm thinking about switching my
default setup to do this.

I realize that historically the portage tree has been installed under
/usr, but Can we consider changing this default for new installations
and providing instructions for users for how to get the portage tree out
of /usr?
William



pgph8ZXXVDA91.pgp
Description: PGP signature

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[William Hubbs]

On Wed, Mar 28, 2012 at 08:20:45AM +1300, Kent Fredric wrote:
> On 28 March 2012 08:15, Sven Vermeulen  wrote:
> >> Then again, Gentoo is about choice.  It just seems like we're
> >> presenting users with more choices than makes sense for a newbie.  If
> >> there is a choice between something that 99.99% of users will want,
> >> and some ancient piece of cruft that still works and is better for
> >> 0.01% of the userbase, does that really have to be in the handbook?
> >
> > Welcome to documentation development. The Gentoo Handbook has always been a
> > difficult source for such discussions. If we truely want to provide
> > information towards our users on all possible choices, you'll need a totally
> > different approach.
> >
> > I once started (before I left Gentoo, rejoined, left again) on a "complete
> > gentoo handbook" that covered much more in greater detail (you'll find the
> > last version at
> > http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml) but I've
> > since moved away from that. Perhaps I should work again on it...
> >
> > Wkr,
> >        Sven Vermeulen
> >
> 
> 
> An idea is a javascripty-dynamic-slidey thing that makes more details
> and advanced stuff visible to people who want it, so you can adjust
> the documentation to suit your skill level.

Why not just the separate "quick install" guide like we have that lists
steps and the handbook if yu want more details?

William


pgpqE8WTjvLWn.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: location of portage tree

[William Hubbs]

On Wed, Mar 28, 2012 at 08:25:58AM +1300, Kent Fredric wrote:
> On 28 March 2012 08:05, William Hubbs  wrote:
> /var/cache/repositories/gentoo/*
> /var/cache/repositories/perl-experimental/*
> /var/cache/distfiles/*
> /var/cache/packages/*
 
These sub directories are all portage related, so it is best to put them
 under /var/cache/portage.
 Look in /var/cache on your system; most of the directories in there (at
 least on my system) are named for the program that uses them.

William



pgpGzm6h6TRvH.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: location of portage tree

[William Hubbs]

On Wed, Mar 28, 2012 at 08:29:50AM +1300, Kent Fredric wrote:
> >
> > /var/cache/repositories/gentoo/*
> > /var/cache/repositories/perl-experimental/*
> > /var/cache/distfiles/*
> > /var/cache/packages/*
> >
> 
> 
> Actually, now I think of it, repositories /might/ be suitable for
> being under /db/
> the repository does sort of function like a database, the tools we use
> to access it treats it like one. .
> 
> And we already have /var/db/pkg   , why not /var/db/repositories  beside it?

I disagree with this, because the repositories can be recovered by doing
an emerge --sync, but if you rm -rf /var/db/pkg you hose your system.

William



pgpxmTUvtaTHZ.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: location of portage tree

[William Hubbs]

On Tue, Mar 27, 2012 at 12:47:10PM -0700, Alec Warner wrote:
> On Tue, Mar 27, 2012 at 12:40 PM, William Hubbs  wrote:
> > On Wed, Mar 28, 2012 at 08:25:58AM +1300, Kent Fredric wrote:
> >> On 28 March 2012 08:05, William Hubbs  wrote:
> >> /var/cache/repositories/gentoo/*
> >> /var/cache/repositories/perl-experimental/*
> >> /var/cache/distfiles/*
> >> /var/cache/packages/*
> >
> > These sub directories are all portage related, so it is best to put them
> >  under /var/cache/portage.
> >  Look in /var/cache on your system; most of the directories in there (at
> >  least on my system) are named for the program that uses them.
> 
> The gentoo-x86 ebuild tree is not necessarily portage related.
> However I think we should paint the bike shed '/srv/tree'
heh ;-)

What I was wanting to discuss mainly was that /usr/portage isn't right;
I think we need to move that out of the /usr directory.

I'm not sure what the new default should be, nor how the default should
be decided. Maybe we just let Zac pick one?

William



pgpVLBibsPCC9.pgp
Description: PGP signature

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[William Hubbs]

On Tue, Mar 27, 2012 at 05:19:10PM +0200, "Paweł Hajdan, Jr." wrote:
> On 3/26/12 7:20 PM, Mike Gilbert wrote:
> > On Mon, Mar 26, 2012 at 1:08 PM, "Paweł Hajdan, Jr."
> >  wrote:
> >> I posted this issue here because it's not obvious what to do with it.
> >> That version of pybugz worked for me before (20 February 2012).
> >>
> >> Any ideas?
> >>
> > I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 4.2.
> > 
> > I think you should file a bug for pybugz. :)
> 
> Right, and indeed I've found existing
>  (there is patch inside).

That is now merged into pybugz-, but it had nothing to do with the
bugzilla 4.2 issues.

I will see what else I can come up with, but patches/suggestions are
welcome.

William



pgpOv3Sosp5DC.pgp
Description: PGP signature

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[William Hubbs]

On Thu, Mar 29, 2012 at 07:37:15PM -0700, Alec Warner wrote:
> On Tue, Mar 27, 2012 at 1:03 PM, William Hubbs  wrote:
> > On Tue, Mar 27, 2012 at 05:19:10PM +0200, "Paweł Hajdan, Jr." wrote:
> >> On 3/26/12 7:20 PM, Mike Gilbert wrote:
> >> > On Mon, Mar 26, 2012 at 1:08 PM, "Paweł Hajdan, Jr."
> >> >  wrote:
> >> >> I posted this issue here because it's not obvious what to do with it.
> >> >> That version of pybugz worked for me before (20 February 2012).
> >> >>
> >> >> Any ideas?
> >> >>
> >> > I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 
> >> > 4.2.
> >> >
> >> > I think you should file a bug for pybugz. :)
> >>
> >> Right, and indeed I've found existing
> >> <https://github.com/williamh/pybugz/pull/19> (there is patch inside).
> >
> > That is now merged into pybugz-, but it had nothing to do with the
> > bugzilla 4.2 issues.
> >
> > I will see what else I can come up with, but patches/suggestions are
> > welcome.
> >
> > William
> >
> 
> My plan is to add support for the jsonrpc api, which I was going to do
> this weekend.

Go for it; actually I wouldn't have a problem with us converting over to
that and dropping the old method of communicating with bugzilla.

William


pgpSxQAi5Achc.pgp
Description: PGP signature

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[William Hubbs]

Hi all,

here is a quick update on this:

On Mon, Mar 26, 2012 at 01:20:38PM -0400, Mike Gilbert wrote:
> On Mon, Mar 26, 2012 at 1:08 PM, "Paweł Hajdan, Jr."
>  wrote:
> > I posted this issue here because it's not obvious what to do with it.
> > That version of pybugz worked for me before (20 February 2012).
> >
> > Any ideas?
> >
> 
> I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 4.2.
> 
> I think you should file a bug for pybugz. :)
> 
> Long term, we may want to consider porting pybugz to use Bugzilla's
> XML-RPC api to avoid such breakage.

Agreed, and I think that is going to happen sooner than longterm.

I now have a project on my github account called PyZilla, which is a
library for communicating with BugZilla via xmlrpc.  [1] However, it
does not work with python 2.7, which is what I would like.

I emailed the original author since he hadn't worked on this library in
a year, and I was given permission to take over maintainership because
he said he doesn't have time to work on it.

So, any patches to make this work with python-2.7 are welcome. :-)

William

[1] https://github.com/williamh/PyZilla



pgpGCDPnJrI2f.pgp
Description: PGP signature

[gentoo-dev] pybugz call for testers

[William Hubbs]

All,

I have updated pybugz- to work with the xmlrpc interface of
bugzilla.

I can name a couple of issues that are api limitations that we can't do
anything about:

- you can't add keywords to a bug with the post command, but you can
  with the modify command.

- you can't search on cc: or keywords fields.

I haven't done a release yet, since there may be other issues.But, if
you are up to it, feel free to emerge pybugz- and test and report
any issues you find.

Thanks,

William


pgpnbol9JFg83.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[William Hubbs]

On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > New udev and separate /usr partition
> > 
> > Decide on whether a separate /usr is still a supported configuration.
> > If it is, newer udev can not be stabled and alternatives should be
> > investigated. If it isn't, a lot of documentation will have to be
> > updated. (And an alternative should likely still be provided.)

There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.

Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an initramfs
if you have a separate /usr partition [1]?

Also, I am going to reiterate what Greg said. This is not an issue with
udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.

Also, with the appropriate documentation changes, which are being worked
on (see [1]), I feel that the statement above that newer udev can't be
stabled should be re-evaluated.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=407959


pgpUAdzbT64Xc.pgp
Description: PGP signature

Re: [gentoo-dev] pybugz call for testers

[William Hubbs]

On Tue, Apr 10, 2012 at 10:45:14PM +0200, "Paweł Hajdan, Jr." wrote:
> On 4/10/12 7:54 PM, William Hubbs wrote:
> > I have updated pybugz- to work with the xmlrpc interface of
> > bugzilla.
> 
> Cool, thank you for working on that.
> 
> > I can name a couple of issues that are api limitations that we can't do
> > anything about:
> > 
> > - you can't search on cc: or keywords fields.
> 
> That's going to be a problem for arch testing needs (e.g. STABLEREQ
> keyword and x86@ cc-ed). How about doing the searches "the old way" that
> allowed the above.

That is not so easy to do since we have completely gotten rid of the old
method of communicating with bugzilla. That method was not reliable and
had broken several times with bugzilla upgrades, but using the web
services will be more stable.

Here is the documentation for their search command [1]. It would
probably be better for us to open a bug against bugzilla itself and
request those changes be put in the api.

What are your thoughts?

William

[1] 
http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService/Bug.html#search


pgpT2yL2vhpuE.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[William Hubbs]

On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote:
> On 04/10/2012 07:28 PM, Steven J Long wrote:
> > I suppose you could script that, but again, it just seems like a lot of
> > bother to implement an "alternative" that doesn't actually gain anything
> > over the traditional setup (plus making sure that partitions are mounted
> > before udev starts.)
> 
> At least in the case of udev, we gain from not having to maintain a fork.
> 
> > As for the burden of ensuring that binaries installed to /{s,}bin don't link
> > to libs in /usr, why not just automate a QA check for that, and let
> > developers decide whether a fix is necessary? After all, core packages that
> > do that even when configured with prefix and execprefix = /, aren't so
> > portable, and Gentoo has always championed "doing the right thing" wrt
> > helping upstream fix portability issues.
> 
> If the relevant ebuild developers really want to support that, it's fine 
> I guess. Hopefully that won't involve using static links as workarounds 
> for cross-/usr dependencies.

Another issue to consider is binaries that want to access things in
/usr/share/*. If a binary in /{bin,sbin} needs to access something in
/usr/share/*, you have two choices. move the binary to /usr or move the
thing it wants to access to / somewhere which would involve creating
/share. Actually there is another choice, but I don't want to go there.
That would be writing patches.

The best way to solve all cross / - /usr dependencies imo is the /usr
merge (moving everything from /{bin,sbin,lib*} to the counterparts in
/usr), which has been discussed pretty extensively on this list, and
there hasn't been a lot of opposition to it.

William



pgppMLDuqUmiW.pgp
Description: PGP signature

[gentoo-dev] >= udev-182 tracker

[William Hubbs]

All,

here is what I see on the current udev situation:

The council has made a decision that we will continue supporting
split out /usr. 

This, however, was never in question. No one is planning to drop support
for separate /usr. Also, no one is planning on trying to force
stabilize udev-182 within 30 days.

To allay any fears of that happening, I have opened a tracker [1] for
issues which need to be resolved before newer udevs can go stable.

Does this answer any fears about trying to force an untimely
stabilization?

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=411627


pgp75jkreO7tE.pgp
Description: PGP signature

Re: [gentoo-dev] >= udev-182 tracker

[William Hubbs]

On Wed, Apr 11, 2012 at 09:58:47PM +0200, Michał Górny wrote:
> Maybe we should create a new mailing list, say,
> gentoo-usr-discuss...@lists.gentoo.org.

No. I'm on enough mailing lists as is. :-)

William


pgpG9pgrCd8Qa.pgp
Description: PGP signature

Re: [gentoo-dev] Making user patches globally available

[William Hubbs]

On Sun, Apr 15, 2012 at 03:55:58PM +0200, Michał Górny wrote:
> 
> What if some patches are applied conditionally?

imo patches that are applied conditionally should be rewritten so they
can always be applied.

patches that are applied conditionally probably won't get into upsream
most of the time.

Best regards,

William



pgpBJ291Ka9dr.pgp
Description: PGP signature

Re: [gentoo-dev] Re: New license: yEd Software License Agreement

[William Hubbs]

On Fri, Apr 27, 2012 at 02:26:07PM +, Duncan wrote:
> Amadeusz Żołnowski posted on Fri, 27 Apr 2012 15:45:36 +0200 as excerpted:
> 
> > Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200:
> >> No distribution allowed.  You're going to be doing restrict=mirror,
> >> correct?
> > 
> > Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually.
> 
> That works.  RESTRICT=fetch is stricter so works, but I'm not sure 
> whether it's necessary as I've not paid attention to the legal 
> distinctions since both are out of the question here, but certainly, 
> gentoo can't distribute, so restrict=mirror for sure.  Whether it merits 
> restrict=fetch or not I'll let someone else worry about.

Definitely you should use restrict=mirror.

Restrict=fetch is used when a user has to go to a web site and register
or accept a license on the web site before they download the file the
way I understand it.

William



pgpFqGmuYcBtm.pgp
Description: PGP signature

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

On Sun, Apr 29, 2012 at 10:00:26PM -0400, Mike Frysinger wrote:
> finally, since the recent udev-mount init.d script is completely brain dead 
> and 
> refuses to execute unless devtmpfs is enabled, this code will also 
> automatically mount+seed /dev (via mdev) if need be.

The recent udev-mount script goes with >=udev-182 which *requires*
devtmpfs, so I don't see why you think the the udev-mount script is
braindead.

> this should address the council's requirement (sep-/usr w/out initramfs) 
> while 
> allowing the general craziness to proceed w/out forking projects ourselves.

Correction here; as far as I know the council did not mandate separate
/usr without initramfs. They just said that separate /usr is a
supported configuration.

William



pgpjRETQQMOfD.pgp
Description: PGP signature

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

On Mon, Apr 30, 2012 at 12:48:55AM -0400, Mike Frysinger wrote:
> it leaves your system in a hard to recover state because you happened to 
> forget to check a filesystem option (which ironically isn't under Filesystems 
> in the kernel).  it's piss-poor user facing behavior.

Here's the situation.

Udev-182 mandates that a devtmpfs be mounted on /dev.
Udev-mount attempts to do this, and if it can't, it fails.
Since udev-mount fails, udev has to fail.

I would rather have had >=udev-182 refuse to merge if you don't have
config_devtmpfs in your kernel, but I was informed that is not allowed
because of build hosts.

If there is another way to handle this I'm all ears.

Thanks,

William



pgpQVMEZ4GASd.pgp
Description: PGP signature

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

On Mon, Apr 30, 2012 at 12:00:59PM -0400, Rich Freeman wrote:
> On Mon, Apr 30, 2012 at 4:05 AM, Tony "Chainsaw" Vroon
>  wrote:
> > Binaries that are essential for system boot, and must be available in
> > single user mode go in /bin and /sbin, with their libraries in /lib.
> > This allows for /usr to be:
> > 1) marked read-only for NFS mounts, which some of us rely on
> > 2) inside of an LVM2 container, allowing for / to be (very) small
> > 3) on a squashfs filesystem, in order to save space
> 
> These are all things easily supported with an initramfs.  In fact,
> initramfs-based solutions allow the same sorts of things to be done
> with all the other filesystems and not just /usr.

This is correct.

> > Trying to second-guess my motivation, and trying to undo unanimous
> > council votes simply because your opinion is different, really has to
> > stop.
> 
> I don't think anybody is trying to undo council votes - people are
> just speculating as to what they voted on.  The easiest solution is
> for somebody to say "I'm John Smith, and I am speaking officially for
> the council, and we agree that what was decided upon is X."

Yes, this is correct. I read the log over several times and it isn't
clear what the council actually voted on. Tony, it seems clear that you want to
mandate that gentoo in its default configuration will support separate
/usr without an initramfs. The thing that isn't clear is whether the
rest of the council wants to do that. In reading the log, there was
definite uncertainty about whether the vote was just to continue
supporting /usr as a separate configuration or to mandate how
separate /usr was going to be supported in the default configuration.

> It seems pretty clear that everybody wants to support a separate /usr.
>  We even have multiple supported solutions, including an initramfs, a
> use flag on busybox, and I believe somebody posted a script that can
> be run during early boot to mount /usr.  It sounds like the only thing
> that isn't supported is "doing nothing" - but with Gentoo if you "do
> nothing" you don't get an installed system that works on any
> configuration.
 
Rich, you are absolutely right. There is not an argument anywhere about
whether separate /usr is supported.

> > I feel a lot better about vapier's pragmatic approach then I do about
> > udev/systemd upstream's ability and motivation to support current
> > systems. If you had any doubts about whether udev was part of the
> > problem, consider what tarball you will have to extract it from in future.
> 
> Well, if others feel differently about the direction udev is taking,
> they can of course just fork it.
> 
> I can't say I'm terribly excited about the amount of vertical
> integration going on.  I don't run Gnome, and I don't run Unity.  I
> really do prefer the unix way.
 
 I'm not excited about parts of the vertical integration either. Newer
 versions of gnome are going to start requiring systemd from what I've
 heard, and I disagree with that level of integration.

> However, I don't contribute much to those upstream projects, and I
> don't see much value in telling a bunch of people who do that they are
> doing it wrong.  I don't like how Google develops Android in the dark,
> or that they bundle 1GB of third-party stuff in their Chromium source
> and distribute a favored binary-only derivative.  However, I do like
> that they're giving me all of that stuff essentially for free, and so
> beyond the odd blog post I try not to give them too hard a time.
> 
> In the same way I think we need to give the maintainers of these
> projects in Gentoo some slack, or join those projects and help them to
> address your needs.  It is a lot easier to tell others what to do than
> to help make it happen, but a volunteer-based project like Gentoo
> needs the latter more than the former.

Agreed.

William



pgp80r3HSe75a.pgp
Description: PGP signature

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote:
> the fact that the script leaves your system in a hard to recover state is 
> what 
> i'm whining about, not that udev requires devtmpfs.

So why did you decide to whine instead of opening a bug? :p

> /dev/pts isn't created, thus devpts doesn't get mounted, thus you cannot log 
> in to your system to fix it.  would also be trivial to run the all of three 
> commands so people could recover:
>   mount -t tmpfs dev /dev
>   busybox mdev -s
>   mkdir /dev/pts

Yes, I could do this.

> we already have examples of the init scripts modifying /etc/issue to notify 
> login entry points that their system needs manual attention to recover.

This part can't happen in the udev init script since / is ro when it is
run. Doing something in udev-postmount is also eroneous because that
assumes that the user is booting to the default runlevel which they may
not be.

The best thing I can think of to do is to just log a message about it in
udev-mount and fail which will cause udev to fail.

William



pgpyzoloSPqGp.pgp
Description: PGP signature

Re: [gentoo-dev] busybox[sep-usr] support for mounting /usr w/out hassle

[William Hubbs]

On Tue, May 01, 2012 at 11:45:01AM -0400, Mike Frysinger wrote:
> On Tuesday 01 May 2012 11:06:42 William Hubbs wrote:
> > On Mon, Apr 30, 2012 at 11:59:02AM -0400, Mike Frysinger wrote:
> > > the fact that the script leaves your system in a hard to recover state is
> > > what i'm whining about, not that udev requires devtmpfs.
> > 
> > So why did you decide to whine instead of opening a bug? :p
> 
> based on past behavior, i assumed it was operating as indented
> 
> > > we already have examples of the init scripts modifying /etc/issue to
> > > notify login entry points that their system needs manual attention to
> > > recover.
> > 
> > This part can't happen in the udev init script since / is ro when it is
> > run. Doing something in udev-postmount is also eroneous because that
> > assumes that the user is booting to the default runlevel which they may
> > not be.
> 
> in the past, we would `mount -o remount,rw /`, but that was because we needed 
> to add missing dirs in /.

Hmm, if I do that I would also have to put it back ro after I modify
issue because fsck hasn't run yet...

Do we want to mess around with the fs before fsck is run?

William



pgpywRiUs1cB0.pgp
Description: PGP signature

Re: [gentoo-dev] Stability of /sys api

[William Hubbs]

On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote:
> Actually with all the hype about mdev these days, why not just use a 3
> year old version of udev (or maybe 4), that is probably what mdev is at
> as far as functionality goes.  Why not just fork udev from then and go
> forward from that?  What exactly are you not liking in udev that makes
> you want to get rid of it so badly?  What is it doing that bothers
> people so much?

I'm wondering the same thing since once busybox 1.20.0 hits stable you
will be able to have a separate /usr without an initramfs quite easily
if that's what you want to do.

When you emerge this version of busybox with the "sep-usr" use flag, you
get a binary in / called ginit. Now just follow the instructions you got
when you emerged it.

William




pgpsDOJ63MLdp.pgp
Description: PGP signature

[gentoo-dev] latest commits to dev-lang/go

[William Hubbs]

All,

I know my latest commits to dev-lang/go haven't updated the ChangeLog.

I got into the habbit of using repoman commit -[Mm] to do that, but for
some reason that stopped working.

I will use echangelog from this ponit until I hear that repoman commit
has been fixed.

Thanks,

William



pgppTTapnoBvd.pgp
Description: PGP signature

Re: [gentoo-dev] latest commits to dev-lang/go

[William Hubbs]

On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote:
> All,
> 
> I know my latest commits to dev-lang/go haven't updated the ChangeLog.
> 
> I got into the habbit of using repoman commit -[Mm] to do that, but for
> some reason that stopped working.
> 
> I will use echangelog from this ponit until I hear that repoman commit
> has been fixed.

Thanks to Zac's quick assistance on irc, I found that this was an issue
with my repository, not repoman.

William



pgpMNBwFatqWE.pgp
Description: PGP signature

Re: [gentoo-dev] Stability of /sys api

[William Hubbs]

On Tue, May 15, 2012 at 07:51:03PM -0400, Walter Dnes wrote:
> On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote
> > On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote:
> > > On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote
> > > > What specifically is your objection to udev today?  Is it doing things
> > > > you don't like?  Too big?  Something else?
> > > 
> > >   Today, it requires an initramfs if /usr is not physically on /.  That
> > > is due in large part to the fact that it has been rolled into the
> > > systemd tarball, and inherited some of systemd's code and limitations,
> > > despite the fact that udev is still a separate binary.
> > 
> > This is absolutely and definitely false. Where did you hear such
> > nonsense ?
> 
>   1) Did you sleep through the /usr and initramfs flamewars?
> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
>   2) The udev sources have merged into the systemd tarball.  See...
> http://article.gmane.org/gmane.linux.hotplug.devel/17392  And note
> the date is April 3rd, not April 1st.  If they were really as worried
> about compatability as they claim, you wouldn't need to use initramfs

If you saw my last message on this subject, there is no need to use
initramfs if you don't want to use it.

See the sep-usr use flag on the ~arch version of busybox and the
instructions you get when you turn that on.

William


pgpHlUscQM0LF.pgp
Description: PGP signature

Re: [gentoo-dev] latest commits to dev-lang/go

[William Hubbs]

On Tue, May 15, 2012 at 10:15:28PM -0400, Matt Turner wrote:
> On Tue, May 15, 2012 at 9:07 PM, William Hubbs  wrote:
> > On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote:
> >> All,
> >>
> >> I know my latest commits to dev-lang/go haven't updated the ChangeLog.
> >>
> >> I got into the habbit of using repoman commit -[Mm] to do that, but for
> >> some reason that stopped working.
> >>
> >> I will use echangelog from this ponit until I hear that repoman commit
> >> has been fixed.
> >
> > Thanks to Zac's quick assistance on irc, I found that this was an issue
> > with my repository, not repoman.
> >
> > William
> >
> 
> So that others don't have the same problem -- what was the issue?

it had to do with the timestamp of the ChangeLog file being wrong. I just
fixed it by doing 

cvs up ChangeLog

while I was in the dev-lang/go directory in my cvs checkout of the
portage repo.

William


pgplwFqGWTVA1.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Stability of /sys api

[William Hubbs]

Hi Steven,

On Thu, May 17, 2012 at 06:48:33AM +0100, Steven J Long wrote:
> Thing is it runs before the real init[1] so if we are using a separate /usr 
> partition on LVM, will it still work? I'd have thought not, since we need 
> the device-mapper service and there's /etc/lvm.conf to consider, but I'll 
> gladly be told different.
 
No, you are correct about this. This does not work if you have /usr on
lvm, mdadm, or encrypted. The same applies to /. That is the situation
where you would need an initramfs.

I'm curious, have you seen our initramfs guide yet [1]? Making and using
an initramfs seems to be pretty well documented these days.

William

[1] http://www.gentoo.org/doc/en/initramfs-guide.xml


pgpqXzx9WI3CB.pgp
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> I, for one, think we should stay with CVS and leave all this git
> Linusware to the new-fangled Fedora kids with their fancy init systems
> and tight coupling. CVS was good enough for my grandfather, and it's
> good enough for you.

I hope this is sarcasm or a joke?

William



pgp8HVeq1dZv3.pgp
Description: PGP signature

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Wed, May 23, 2012 at 10:37:55PM +0200, Michał Górny wrote:
> On Wed, 23 May 2012 15:25:54 -0500
> William Hubbs  wrote:
> 
> > On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote:
> > > I, for one, think we should stay with CVS and leave all this git
> > > Linusware to the new-fangled Fedora kids with their fancy init
> > > systems and tight coupling. CVS was good enough for my grandfather,
> > > and it's good enough for you.
> > 
> > I hope this is sarcasm or a joke?
> 
> Obviously. His grandfather used SCCS.

Heh, that's possible, or maybe he even used prodos [1], which was pretty
cool for its time.

William

[1] http://en.wikipedia.org/wiki/PRODOS


pgp4O14kFI8pz.pgp
Description: PGP signature

[gentoo-dev] rfc: OpenRC Networking Scripts

[William Hubbs]

All,

I realize this has been discussed and there are definite opinions about
which method works well. So, I want to take a different approach.

Is there any interest in documenting and supporting newnet along side
oldnet as opposed to killing newnet?

Newnet would consist of the "network" init script to set up your
loopback interface along with something like dhcpcd, networkmanager,
or wicd (and wpa_supplicant for wireless interfaces) running in
standalone mode to manage your other interfaces.

My understanding of the way newnet works is that the big advantage would
come for workstations that have a simple network setup and where users
would want hotplugged interfaces to just work.

Any thoughts?

William



pgpSDl0LQvtpY.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: OpenRC Networking Scripts

[William Hubbs]

On Sun, May 27, 2012 at 10:49:07AM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 26/05/12 03:40 PM, William Hubbs wrote:
> > All,
> > 
> > I realize this has been discussed and there are definite opinions
> > about which method works well. So, I want to take a different
> > approach.
> > 
> > Is there any interest in documenting and supporting newnet along
> > side oldnet as opposed to killing newnet?
> > 
> > Newnet would consist of the "network" init script to set up your 
> > loopback interface along with something like dhcpcd,
> > networkmanager, or wicd (and wpa_supplicant for wireless
> > interfaces) running in standalone mode to manage your other
> > interfaces.
> > 
> > My understanding of the way newnet works is that the big advantage
> > would come for workstations that have a simple network setup and
> > where users would want hotplugged interfaces to just work.
> > 
> > Any thoughts?
> > 
> > William
> > 
> 
> 
> Just want to point out that my hotplugged interfaces work great with
> oldnet.

Actually they don't, because we don't make or remove the net.* symlinks
in /etc/init.d for the hotplugged interfaces when the interfaces are
added or removed.

William



pgpRaImBi44rW.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?

[William Hubbs]

On Tue, May 29, 2012 at 03:46:39PM -0400, Michael Orlitzky wrote:
> How about introducing e.g. FEATURES="nouserpriv", and make the current
> userpriv behavior the default?

No. Please stay away from things like this.
It is reverse logic and can be very confusing. Just adding "-userpriv"
to your features would do exactly the same thing.

William



pgpDBWymIk6cT.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
> On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson  wrote:
> > 1.
> > Discussion on merge policy. Originally I thought we would disallow merge
> > commits, so that we would get a cleaner history. However, it turns out that 
> > if
> > the repo ends up being pushed to different places with slightly different
> > histories, merges are absolutely going to be required to prevent somebody 
> > from
> > having to rebase at least one of their sets of commits that are already 
> > pushed.
> 
> Not sure I'm following, but I will be the first to admit that I'm a
> git novice.  Would this be aided by a convention, like only committing
> to master on the gentoo official repository, and any on-the-side work
> on places like github/etc stays in branches?  Those repositories would
> just keep getting fed commits on master from the official repository.

 Iagree with this; I think we should ban merge commits on master. That
 would force everyone to rebase their work on current master before they
 commit to master which would make the history clean.

William


pgpA0ksxOrWmJ.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Thu, May 31, 2012 at 07:13:42PM +, Robin H. Johnson wrote:
> - You have a commit, that you want to put into the Gentoo tree.
> - You have already pushed it to your github, signed

If I have a github tree, that would probably be because I didn't have
push access to the official tree, so signing the commit probably
isn'tgoing to matter; I would expect that a gentoo dev who has push
access to the tree would sign the commit when it is put into the gentoo
tree.

> - It needs to be merged/rebased so that it applies on the Gentoo tree.
> - If you force it to be a rebase so it applies on the tip, then you may
>   have changed the history of your github tree, and broken any further
>   forks.
> - If you permit a merge instead, nobody gets broken.

If you do this:

git rebase master mybranch
git checkout master
git merge mybranch <-- this is a fast-forward merge
git pull --rebase
git push

I think that covers this concern doesn't it?

> > > 2.
> > > Git-SVN breakage. Why does this matter you're wondering?
> > > We need the newer Git for the commit signing, but it comes with a
> > > price, the git-svn binary has some major failures with SVN 1.7.
> > > Git since 1.7.8 has been broken this way.
> > To clarify - these won't be issues for gentoo per se, but there is a
> > sense that we can't stabilize the latest git because it will break it
> > for people using git-svn on non-gentoo work?
> As the Git maintainer, I will not keyword it for anybody until I know
> it's not going to lose/corrupt data, regardless of what they are using
> it for.

Why not keyword it and use package.use.mask for the git-svn flag?

William


pgpwkzFYxv1GM.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Thu, May 31, 2012 at 08:26:58PM +, Duncan wrote:
> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
> 
> I don't know what's going to happen to all the overlays with the main 
> tree switch to git, but won't that break various "overlay first" 
> policies, say for the kde overlay?
> 
> Of course, if all the official overlays are converted to git branches of 
> the main tree... but won't they still require rebasing as they've already 
> been pushed?  (This assumes your workaround idea doesn't work.  If it 
> does, great!)

Overlays aren't really part of this discussion; those are independent
trees which we have no control over, so commiting changes from overlays
to the main tree is the responsibility of the overlay maintainers.

William



pgpnUoF15VbKy.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Thu, May 31, 2012 at 03:58:43PM -0400, Rich Freeman wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny  wrote:
> > What would git signing work with rebased commits? Would all of them
> > have to be signed once again?
> >
> 
> The whole point of rebasing is to throw away history (which is either
> good or bad based on your perspective).
> 
> So, if 14 devs spend 3 years and 2000 commits working on something in
> a branch, and I commit it to master using a rebase, then all you'll
> see in the master history is that rich0 committed 20k lines of code to
> master on May 31st, and that would be signed by me.

You don't commit to master with a rebase,; it is always a merge. The
type of merge is what controls what you see in the logs.

If you rebase your branch on master, merge to master then run "git pull
--rebase" then push, you will get a fast forward merge, which shows the
individual commits.

If you don't include the rebasing, you get another type of merge which
just shows up in the logs as one commit afaik.

William



pgpGov9QxG7kv.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Thu, May 31, 2012 at 08:23:31PM +0100, Ciaran McCreesh wrote:
> On Thu, 31 May 2012 14:18:04 -0500
> William Hubbs  wrote:
> > > Not sure I'm following, but I will be the first to admit that I'm a
> > > git novice.  Would this be aided by a convention, like only
> > > committing to master on the gentoo official repository, and any
> > > on-the-side work on places like github/etc stays in branches?
> > > Those repositories would just keep getting fed commits on master
> > > from the official repository.
> > 
> >  Iagree with this; I think we should ban merge commits on master. That
> >  would force everyone to rebase their work on current master before
> > they commit to master which would make the history clean.
> 
> So what's the point of switching to git if you want to ban the main
> reason git exists?

To clarify: we should only allow fast-forward merges on master.

My big complaint about merge commits is if you do a git show  on
a merge commit, you get nothing, so there is no way to see what actually
changed in that commit.

William



pgpLhNVh63xgN.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Fri, Jun 01, 2012 at 12:57:10PM +, Duncan wrote:
> William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:
> > Overlays aren't really part of this discussion; those are independent
> > trees which we have no control over, so commiting changes from overlays
> > to the main tree is the responsibility of the overlay maintainers.
> 
> But it seems to me that overlays are the primary use case for commits to 
> public trees other than gentoo first.  Otherwise, the whole rebase-vs-
> merge problem goes away, because the first public commit is to the gentoo 
> tree.  But especially with overlays (like kde) that have an overlay-
> first, test, then gentoo-tree, policy, that public overlay tree (which is 
> already in git) is part of the process.  Commits MUST go thru the overlay 
> to get to the tree, and that overlay is public, so constant rebasing is a 
> definite no-no.
> 
> Which unless your workaround idea works, pretty much leaves us with merge-
> commits as a necessity.  (Which of course, as Ciaran pointed out, are 
> part of the point of git, such that running git without merge-commits 
> defeats part of the purpose of the whole exercise.)

Overlays are completely separate repositories. There is nothing stopping
an overlay from using git right now even if the main tree isn't using
git. They just work in their git repositories until they are ready to
commit something to the main tree, then they move the changes to the
main tree.

What the main tree on git would give them is the ability to create a
branch from the main tree for their changes, but that would not be pushed
to the main repository.

All they would have to do when they are ready for their code to be
merged back into the main repository is make sure that they are creating
a fast-forward merge so that there is no merge commit on the master
branch.

William



pgpmzpgQTqKJR.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[William Hubbs]

On Fri, Jun 01, 2012 at 04:33:35PM +, Robin H. Johnson wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
> > Overlays are completely separate repositories. There is nothing stopping
> > an overlay from using git right now even if the main tree isn't using
> > git. They just work in their git repositories until they are ready to
> > commit something to the main tree, then they move the changes to the
> > main tree.
> What about overlay repositories that elect to be a branch of the main
> tree via git?
> 
> Do we call that forbidden usage?

No, it just would mean that they have to know how to rebase their
changes on master before they commit.

They would clone the main tree to their overlay location, then make a
kde branch in their location. That branch would be where they did their
work and they would keep master in sync with the main tree (upstream) by
running git pull.

To merge the overlay changes into the master, a developer would use a
git remote to add the kde overlay to his tree, add a kde branch that
tracked the remote kde branch, rebase that on current master, merge it
into master to create a fast-forward merge then push.

I think that probably sounds more complicated than it is, so let me know
if you need clarification.

William



pgpglcTCfr3Mr.pgp
Description: PGP signature

Re: [gentoo-dev] Kernel compiles and you

[William Hubbs]

On Wed, Jul 04, 2012 at 02:20:36PM -0400, Rick "Zero_Chaos" Farina wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 07/04/2012 01:58 PM, Michał Górny wrote:
> > On Wed, 4 Jul 2012 19:46:47 +0200
> > Tobias Klausmann  wrote:
> > 
> >> Recently, I have again bumped into the question whether one
> >> should compile the kernel as root. One of the things that puzzles
> >> me is why almost every HowTo, blog post and book recommends
> >> building as non-root -- yet basically no distribution /helps/ the
> >> user with doing that.
> >>
> >> I've discussed this with a few people on #gentoo-dev and they've
> >> provided valuable insight (thanks AxS, Chainsaw and WilliamH), so
> >> I have gathered the results so far here:
> >>
> >> http://blog.i-no.de/archives/2012/07/index.html#e2012-07-04T19_28_32.txt
> >>
> >> Feel free to comment (ideally here). Note that I'm aiming for a
> >> solution that is not (overly) Gentoo-specific.
> > 
> > There's a very simple yet custom solution I'm using. Shortly saying:
> > checkout the kernel git to /usr/src/linux and chown to your user. As
> > far as it goes, it's superior to having kernel sources installed by
> > ebuilds.
> > 
> > I just have to remember to do 'git fetch' from time to time and 'git
> > merge' whenever a new version is tagged.
> > 
> 
> Honestly I'm not certain if there is an easy way to do this
> 
> Obvious easy way, make the ebuilds install the kernel sources and chown
> root.users then chmod g+w.  Of course, after this any user could trojan
> the kernel...

There is no need to chown or chmod anything. /usr/src/linux* is always
world readable.

> We could allow writes in the directories but not to the kernel source
> files themselves... that seems moderately sane even as the source files
> don't need to be written to be compiled, only the dir's need write
> permissions...

Actually the directories do not need write permissions either. Take a
look at the O= option documented in /usr/src/linux/README.

William


pgpd90SjW3nS8.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

On Tue, Jul 10, 2012 at 07:57:50PM +0200, Michał Górny wrote:
> On Tue, 10 Jul 2012 12:54:31 -0400
> Alexis Ballier  wrote:
> 
> > On Tue, 10 Jul 2012 17:18:00 +0200
> > Michał Górny  wrote:
> > 
> > > The former two were previously provided by 'extras' USE flag,
> > > and the third was unconditional.
> > 
> > since udev-171 seems to be going stable, why not simply drop the
> > 'extras' compatibility ?
> > then you could just use 'gudev?' usedeps it seems
> 
> I heard that people are still bound to old udev versions because of
> kernel requirements introduced by newer ones.

The eventual plan is to kill off the extras use flag in favor of the
others. It is only there to allow packages that depended on udev[extras]
to be moved to depend on the correct use flag, so I think we should be
able to kill it at some point. I just haven't looked into doing that.

William



pgpmzWHl1WZae.pgp
Description: PGP signature

[gentoo-dev] rfc: old udev versions

[William Hubbs]

All,

the last thread started by mgorny has prompted me to ask here on the
list which versions of udev we really need in the tree.

I know that all versions before 133 must go because openrc has a
requirement for at least that version.

I've looked at the kernel packages we have in /usr/portage, but have no
guide there either. If I go by gentoo-sources, I could get rid of all
but very recent versions of udev, but I have heard some things also
about people using older kernels. Also, vanilla-sources goes all the way
back to 2.6.16 (I have no idea why)?

Any thoughts would be helpful.

Thanks,

William



pgpCF1apq2yMO.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

On Tue, Jul 10, 2012 at 05:18:00PM +0200, Michał Górny wrote:
> Hello, all.
> 
> Since nowadays udev is bundled within systemd, we start having two
> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making
> the long story short, I would like to introduce a virtual for libudev
> which would pull in either of those two.
> 
> There are three USE flags used in conditionals when depending on udev:
> - gudev - for glib wrapper on udev,
> - hwdb - to pull in hwids,
> - static-libs.
> 
> The former two were previously provided by 'extras' USE flag,
> and the third was unconditional.
> 
> I'm attaching an example virtual/libudev which does the job. Sadly,
> because of the 'extras' compatibility it's a big ugly conditional.

I'm going to ask here, because of the discussion on IRC, that you not
commit this yet. There are issues still we need to work out wrt
packaging systemd and udev.

William



pgpCws1oiVjUh.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: old udev versions

[William Hubbs]

On Wed, Jul 11, 2012 at 12:42:04PM +0800, Ben de Groot wrote:
> On 11 July 2012 02:30, William Hubbs  wrote:
> > All,
> >
> > the last thread started by mgorny has prompted me to ask here on the
> > list which versions of udev we really need in the tree.
> 
> Personally, I'm holding on to 171. I have masked >=181 because of
> bad decisions upstream and I want to see how the situation will
> stabilize.
> 
> Since 171 is the latest stable, I would think most of our users are
> on this version anyway.
> 
> Since upstream seems to be unwilling to work with us, I think
> we should seriously consider doing a fork. I know there are
> other distros like Debian and Slackware who would be happy
> to join us in that effort.

I'm not interested in a fork at this time. I think we can continue
making udev work for us as is, and the way upstream is doing things
isn't affecting binary package based distros, so we would basically be
on our own.

The deal is that upstream supports *running* udev separately, but not
*building* it separately [1]. Their approach works wonderfully if you
are a binary package based distro, so I'm not sure Debian,
Slackware, etc would really have any incentive to join a fork at this
point.

William

[1] http://freedesktop.org/wiki/Software/systemd/MinimalBuilds


pgpWkIspVxAgb.pgp
Description: PGP signature

[gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

All,
I am about to release udev-186-r1, which will move everything currently
in /lib/udev to /usr/lib/udev.

For packages that install udev rules in ${FILESDIR}, we need an eclass
that tests the version of udev installed on the user's system and
installs the udev rules in the proper place. I'm not sure how many
packages do this, so if it is a very small number of packages, it may
not be worth the eclass. It would be good to discuss that as well as
reviewing the proposed eclass.

Thanks,

William

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v 1.11 2012/01/07 
17:53:47 mgorny Exp $

# @ECLASS: udev-rules.eclass
# @MAINTAINER:
# udev-b...@gentoo.org
# @BLURB: helper functions to install udev rules
# @DESCRIPTION:
# This eclass provides a set of functions to install udev rules.
# With versions of udev prior to 186, udev rules for extra packages were
# installed in /lib/udev/rules.d, but with newer versions they are installed in
# /usr/lib/udev/rules.d.
# @EXAMPLE:
#
# @CODE
# inherit udev-rules
#
# src_install() {
# udev_dorules "${FILESDIR}"/foo.rules "${FILESDIR}"/bar.rules
# udev_newrules "${FILESDIR}"/old.rules.name baz.rules
# }
# @CODE

case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac

# @FUNCTION: _udev_get_rulesdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udev rules directory.
_udev_get_rulesdir() {
local dir
if has_version '

pgpQTVhkDkOnL.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

On Wed, Jul 11, 2012 at 03:27:41PM -0400, Mike Gilbert wrote:
> Just to put a number to this, there are currently 126 packages in the
> tree with a dependency on sys-fs/udev.
> 
> Personally, I think a consolidated systemd/udev package is the best
> way to go here. Short of that, the virtual + blockers seems like an
> acceptable solution.

Thinking on this, I agree with Mike here, and to make it easier for
maintainers so they don't have to change their dependencies, it should
be a udev ebuild with a systemd use flag.

William



pgp40hv8AYgm1.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: virtual/libudev

[William Hubbs]

On Wed, Jul 11, 2012 at 04:33:44PM -0400, Mike Gilbert wrote:
> On Wed, Jul 11, 2012 at 3:54 PM, William Hubbs  wrote:
> > Thinking on this, I agree with Mike here, and to make it easier for
> > maintainers so they don't have to change their dependencies, it should
> > be a udev ebuild with a systemd use flag.
> 
> An alternative to the funky udev[systemd] solution would be to replace
> the entire udev ebuild with RDEPEND="sys-apps/systemd", and implement
> the requisite logic in the systemd ebuild. This would effectively make
> udev a virtual package without the need to modify any other packages.

You would still have funkey logic in the systemd ebuild then, because
you would have to have a use flag, maybe "udev-standalone"
which would make it only install udev, and you would still have to deal
with use flags that don't make sense without systemd being installed.

William



pgpHuy9q3psQz.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

On Wed, Jul 11, 2012 at 02:11:42PM -0500, William Hubbs wrote:
> All,
> I am about to release udev-186-r1, which will move everything currently
> in /lib/udev to /usr/lib/udev.
> 
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass. It would be good to discuss that as well as
> reviewing the proposed eclass.

If there are no objections, I will commit this to the tree, no earlier
than 15 July UTC.

Thanks,

William



pgp5vdlZ0mMsZ.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò wrote:
> Il 11/07/2012 21:11, William Hubbs ha scritto:
> > I am about to release udev-186-r1, which will move everything currently
> > in /lib/udev to /usr/lib/udev.
> 
> Unless you're going to establish a symlink, please keep it under p.mask
> until everything is using some common code — otherwise things _will_ break.

Since multiple packages put things in /lib/udev, I'm not sure it is
possible to establish a symlink from /lib/udev to /usr/lib/udev if
that's what you mean; I'll look into it though.

My concern about p.mask is things tend to die there. How will we know
for sure when there will not be any breakages without putting it in
~arch to see what breaks?

William



pgp3qWyas6PuJ.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

On Wed, Jul 11, 2012 at 04:59:11PM -0400, Alexis Ballier wrote:
> How do you plan to handle the following: 
> - foo installs an udev rule
> - install foo with old udev
> - upgrade udev
> 
> are rules installed by foo used by new udev ?

No, they wouldn't be; that is a good reason to question the value of the
eclass itself. Maybe the correct way to do this is to forget the eclass
and just file bugs against packages that break having them move their
rules to the new location and set a dependency on the newer udev.

This would have to be a rev bump for the broken packages.

William

> 
> A.
> 


pgptwsPXj4sgH.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

On Thu, Jul 12, 2012 at 04:22:20PM +0200, Michał Górny wrote:
> On Wed, 11 Jul 2012 14:11:42 -0500
> William Hubbs  wrote:
> 
> > # @FUNCTION: _udev_get_rulesdir
> > # @INTERNAL
> > # @DESCRIPTION:
> > # Get unprefixed udev rules directory.
> > _udev_get_rulesdir() {
> > local dir
> > if has_version ' > dir=/lib/udev/rules.d
> > else
> > dir=/usr/lib/udev/rules.d
> > fi
> > echo -n $dir
> > }
> 
> For now, I think it would be better to just use /lib/udev/rules.d. We
> can decide on moving the rules later.

We can hold off on this for udev-186. Sometime soon though we will need
to move the rools.

The more I think about it it will do best to be a hard dependency on
>=sys-fs/udev-187 and not worry about the whole eclass issue.

William



pgpJDVvbVa59x.pgp
Description: PGP signature

Re: [gentoo-dev] udev <-> mdev

[William Hubbs]

Hi all,

On Thu, Jul 12, 2012 at 04:07:41PM -0400, Walter Dnes wrote:
> On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote
> 
>   First a disclaimer... I am not a C programmer, let alone a developer.
> I feel like I've been dragged into this kicking and screaming in order
> to save the Gentoo that I remember from a few years ago.
> 
> > Out of curiosity, since mdev is (i assume) more than complete enough
> > to handle mounting, would it be possible to initially start with mdev
> > and then hand over control to udev (if there was a need for udev, that
> > is) , to avoid initramfs with separate /usr ?
> 
>   I think that's exactly how initramfs itself works.  You might be able
> to use an initrd instead of initramfs.  See Zac Medico's posting at...
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
> That was the clue that got me started on replacing udev with mdev.

initrd is deprecated and has been for a long time; you should use
initramfs.

>   Once you have psuedo-filesystems and partitions mounted, you need to
> shut down mdev and start up udev.  And make sure that
> /proc/sys/kernel/hotplug points to udev.

If you are using udev, /proc/sys/kernel/hotplug should be empty; do not
point this to udev.

Thanks,

William



pgpbZG40oxrBE.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: udev-rules.eclass

[William Hubbs]

All,

mgorny has written a patch for udev, which if it gets accepted, will
make it read rules from /lib/udev/rules.d, so there will be nothing that
we need to do on our side at all.

William



pgpBzeeg8CYM1.pgp
Description: PGP signature

Re: [gentoo-dev] Re: udev <-> mdev

[William Hubbs]

On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
> > On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao  wrote:
> > > mdev would need to switch to the netlink hotplug interface.
> > 
> > I think that's quite unlikely, since mdev is not a daemon. Perhaps by
> > the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
> > settled on some early udev fork. [1]
> 
>   Do you realize this would effectively kill linux in the embedded
> device area?  Udev, even without the systemd code, is simply to large
> for embedded devices.

What about using devtmpfs alone?

William


pgpsZziQMIEqm.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao wrote:
> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.
 
 This is not quite correct. The initramfs is required because of [1].

> Interestingly, the /usr merge changes made to genkernel permit us to
> mount /etc from a genkernel-built initramfs by putting /etc on a
> separate mount point in fstab and then doing `echo /etc >>
> /etc/initramfs.mounts`.
 
That doesn't negate putting /usr on nfs and making it possible for
different hosts to share it.

> Some people claim that the current approach is somehow broken by citing
> Bluetooth keyboards. However, what makes that work is adopting an
> initramfs and that does *not* require moving files into /usr. If people
> do not want an initramfs, they can simply not have a separate /usr. The
> /usr merge gives nothing to people using bluetooth while the /usr merge
> will break systems of non-bluetooth users.

I don't see what bluetooth has to do with anything other than with the
'separate usr is broken' document which is a separate issue.

> I have been told that moving everything into /usr would be easy for us
> because Arch Linux did it and they are a rolling distribution too. Arch
> Linux does all-or-nothing upgrades. They do not offer the ability for
> their users to choose to use older versions of software and we will not
> be able to move everything into /usr without breaking existing systems
> that boot without issues now.
 
 This issue is not completely flushed out with the upstream folks for
 udev yet, and  either way, it will be addressed in our version of udev.

> I have also been told that the /usr merge is necessary because upstream
> will force it on us. Interestingly, most of @system on Gentoo Linux is
> GNU software, which would need to stop supporting things in / in order
> for that to happen. As far ass I know, systemd does not work on GNU HURD
> and it would be incapable of functioning if the GNU project made this
> change. Hell will freeze long before that happens.
 
This is basically not relevant since we do not support HURD.

> The only thing that might require a merge is systemd and it is not in
> @system. If we offered users the ability to choose rc systems, we would
> still be supporting baselayout-1's rc system. If we start now, we should
> bring that back.
 
 We offer several rc systems in the tree, but I don't know how up to
 date they are. Either way, bringing back bl1 is not a relevant
 argument, because it is not compatible with OpenRC.

> With that said, there is a great deal of FUD being spread by the systemd
> developers and I see no reason for us to accept it. We would be breaking
> users' systems for no gain other than to make the systemd developers
> happy. Their refusal to permit udev to be built separately from systemd
> demonstrated complete disdain for Gentoo Linux. Why should we let them
> dictate how we design our distribution at our users' expense?

I think we can do the /usr merge in a way that won't break systems; I am
looking into that possibility. I am not interested in breaking systems.

> Lastly, don't tell me to read systemd's case for why we should break
> people's systems. I have read it and I find it flawed. There is
> absolutely no need for us to make this change.
 
Without elaboration on why you find their case flawed, this sounds
like the typical, "if it isn't broke, don't fix it" argument.
While that has merrit, if there are advantages to doing
 something, like I think there would be to doing the /usr merge, it may
 be worth the transition, especially if we can make it as smooth as
 possible.

William



pgp7n4NWLAhxJ.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Tue, Jul 17, 2012 at 06:41:26PM -0400, Rich Freeman wrote:
> In any case, it sounds like for now some devs are continuing to adjust
> ebuilds to keep a separate /usr working as well as possible, though it
> apparently breaks in some edge cases right now without an initramfs,
> as you've already noted in your email.
> 
> I don't think anybody in Gentoo is really pushing for a /usr merge -
> there are just lots of devs saying that they aren't going to spend a
> lot of time stopping it either.  If upstream sticks files needed to
> boot in /usr then it is basically up to somebody who cares to do
> something to move them.  Right now that isn't a lot of work, but the
> reason people are concerned is that this is likely to change.
 
Right, I'm definitely not advocating a full out /usr merge tomorrow or
anything, I am just not interested in doing a whole lot of patching to
keep something from moving to /usr if upstream moves it there.

 Also, I am interested in looking at what is installed in /, and if
 upstream defaults put it in /usr, allowing it to happen on gentoo that
 way as well.
 
 My thought is that eventually we will have  more and more things that are
 being installed in /usr.

> If somebody really is pushing for an all-out /usr move by all means
> speak up, but I think that basically what everybody is advocating is
> trying to follow upstream for individual packages.
 
Right, that's the issue. Some upstreams (mainly udev) have dropped
backward compatibility. But, I will be able to get around those for a
while.

William


pgpR2Wy1yPTyS.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Tue, Jul 17, 2012 at 06:13:06PM -0500, Dale wrote:
> 
> William Hubbs wrote:
> >  
> >  This is not quite correct. The initramfs is required because of [1].
> >
> >
> > William
> >
> 
> Where is [1]?

[1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

We have a way around this in some limited circumstances with
busybox[sep-usr], but that definitely does not support anything fancy
like rade, lvm, etc.

William



pgpwvudC8KtOA.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote:
> On 07/17/2012 07:02 PM, William Hubbs wrote:
> > This is basically not relevant since we do not support HURD.
> 
> It is relevant because it guarantees that the GNU stuff in @system will
> continue working. That allows us to narrow our focus to the non-GNU
> things required to use Gentoo Linux.
> 
> Looking at @system and what it typically pulls into @world, the only
> thing that might cause a problem is udev, although virtual/dev-manager
> is in @system, rather than udev. If that happens, we have a few ways of
> dealing with that:
> 
> 1. Patch udev.

I think I can come up with a patch locally that will read rules from
/lib/udev/rules.d if that's what we want to do for now.

> 2. Fork udev.

I don't think this is necessary, and it would create more work for us
than is needed.

> >> Lastly, don't tell me to read systemd's case for why we should break
> >> people's systems. I have read it and I find it flawed. There is
> >> absolutely no need for us to make this change.
> >  
> > Without elaboration on why you find their case flawed, this sounds
> > like the typical, "if it isn't broke, don't fix it" argument.
> > While that has merrit, if there are advantages to doing
> >  something, like I think there would be to doing the /usr merge, it may
> >  be worth the transition, especially if we can make it as smooth as
> >  possible.
> 
> The cost to benefit ratio is simply too low for "lets change it because
> it could be better this way" to merit making the change. The things that
> I have heard are going to break existing systems that I have gone
> through some trouble to support. I really don't want to see that.

You are still not saying what things you have heard. Your concerns can't
be addressed if you don't tell us what they are.

William



pgpM4wdMCDc6P.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Tue, Jul 17, 2012 at 08:37:03PM -0400, Ian Stakenvicius wrote:
> 
> On 2012-07-17, at 7:07 PM, Olivier Crête  wrote:
> 
> > I'm sure most people can't
> > even explain the difference between them.
> > 
> 
> /sbin is for bins that only root should be able to run.  easy. :)

Not quite, check out this link [1].

William

[1] http://www.osnews.com/story/25556


pgp6iqD4s1pKe.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Wed, Jul 18, 2012 at 08:13:51PM +0400, Hobbit wrote:
> > Why should we care about ancient filesystems that didn't supported
> > long paths, and therefore we got stuck with /usr since we didn't
> > wanted to waste another *single* character to make it /user?
> 
> Because of it's original name: "UNIX System Resources" (usr).

Actually this is not correct (see my earlier post with the link to
osnews.com).
Originally it contained user directories like /home does now.

William



pgpc1JoopQ1kk.pgp
Description: PGP signature

[gentoo-dev] rfc: openrc init scripts taking command line arguments

[William Hubbs]

All,

I have received a request to allow OpenRC's init scripts to take command
line arguments [1]. As noted on the bug, there are some advantages to
this, but implementing it would have to break backward compatibility,
for example:

/etc/init.d/foo stop start

would no longer work the way you might expect because there would be no
way to tell whether start is a command or an argument to stop.

What are your thoughts about this change?

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=427144


pgp4N15VIiNj5.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[William Hubbs]

On Wed, Jul 18, 2012 at 03:58:18PM -0400, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge  wrote:
> > William Hubbs wrote:
> >> /etc/init.d/foo stop start
> >>
> >> would no longer work the way you might expect because there would be no
> >> way to tell whether start is a command or an argument to stop.
> >>
> >> What are your thoughts about this change?
> >
> > /etc/init.d/foo stop start
> >
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
> 
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.
> 
> I.e.
> 
> touch -- -an-ugly-filename
> ls -l -- -an-ugly-filename
> rm -- -an-ugly-filename

Theis still breaks backward compatibility though, e.g.

/etc/init.d/foo command1 -- arg1 arg2 command2

has issues.

The other approach, which is on the bug, still has this issue, e.g.

/etc/init.d/foo command1 arg1 arg2 command2 arg3 arg4 command3 arg5

gets pretty ugly pretty quick. which arguments go with which commands is
subject to interpretation.

William



pgpOp3VKyhnRD.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[William Hubbs]

Folks,

let's move all of the discussion of this to the bug if possible so that
it is all in one place.

Thanks,

William



pgpw1garAIRzQ.pgp
Description: PGP signature