Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-09 Thread Doug Goldstein
On 5/7/16 4:25 PM, Michał Górny wrote:
> On Sat,  7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel" <hd_bru...@gentoo.org> wrote:
> 
>> commit: 66afcab271f65b97330e610040ad3acc1b812a03
>> Author: Joerg Bornkessel  gentoo  org>
>> AuthorDate: Sat May  7 21:18:48 2016 +
>> Commit: Joerg Bornkessel  gentoo  org>
>> CommitDate: Sat May  7 21:18:48 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
>>
>> fixed einstall vs. emake install for eapi=6
>>
>>  eclass/vdr-plugin-2.eclass | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
>> index ae09a34..65f1409 100644
>> --- a/eclass/vdr-plugin-2.eclass
>> +++ b/eclass/vdr-plugin-2.eclass
>> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>>  local SOFILE_STRING=$(grep SOFILE Makefile)
>>  if [[ -n ${SOFILE_STRING} ]]; then
>>  BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
>> }}
>> -einstall ${BUILD_PARAMS} \
>> +if [[ ${EAPI} == 6 ]]; then
>> +emake install ${BUILD_PARAMS} \
>> +else
>> +einstall ${BUILD_PARAMS} \
>> +fi
>>  ${BUILD_TARGETS} \
>>  TMPDIR="${T}" \
>>  DESTDIR="${D}" \
>>
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
> 

Michal,

How about trying a different tone?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: dev-libs/matrixssl

2016-03-20 Thread Doug Goldstein
On 3/19/16 1:39 AM, Aaron Bauman wrote:
> # Aaron Bauman <b...@gentoo.org> (19 Mar 2016)
> # Multiple unpatched security vulnerabilities
> # per bug #523040. Masked for removal in 30 days.
> dev-libs/matrixssl
> 

bug #532040

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/5] app-emulation/xen-tools: Make use of new python_gen_impl_dep function

2015-12-24 Thread Doug Goldstein
On 12/23/15 10:44 AM, Michał Górny wrote:
> ---
>  app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild | 2 +-
>  app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild | 2 +-
>  app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild  | 4 ++--
>  app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild  | 4 ++--
>  app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild  | 2 +-
>  app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild  | 2 +-
>  6 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild 
> b/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> index 67e3d1c..d29aab3 100644
> --- a/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.2.5-r10.ebuild
> @@ -68,7 +68,7 @@ DEPEND="dev-libs/lzo:2
>   api? ( dev-libs/libxml2
>   net-misc/curl )
>   ${PYTHON_DEPS}
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
>   sys-devel/bin86
>   sys-devel/dev86
>   dev-lang/perl
> diff --git a/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild 
> b/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> index ae93f4d..392be10 100644
> --- a/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.2.5-r11.ebuild
> @@ -68,7 +68,7 @@ DEPEND="dev-libs/lzo:2
>   api? ( dev-libs/libxml2
>   net-misc/curl )
>   ${PYTHON_DEPS}
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
>   sys-devel/bin86
>   sys-devel/dev86
>   dev-lang/perl
> diff --git a/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild 
> b/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> index 8af652c..ba2f756 100644
> --- a/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.5.2-r2.ebuild
> @@ -87,8 +87,8 @@ DEPEND="${COMMON_DEPEND}
>   ${PYTHON_DEPS}
>   api? ( dev-libs/libxml2
>   net-misc/curl )
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
>   !amd64? ( >=sys-apps/dtc-1.4.0 )
>   amd64? ( sys-devel/bin86
>   system-seabios? ( sys-firmware/seabios )
> diff --git a/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild 
> b/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> index 59e9056..a147169 100644
> --- a/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.5.2-r3.ebuild
> @@ -90,8 +90,8 @@ DEPEND="${COMMON_DEPEND}
>   ${PYTHON_DEPS}
>   api? ( dev-libs/libxml2
>   net-misc/curl )
> - pygrub? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/ncurses} )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + pygrub? ( $(python_gen_impl_dep ncurses) )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
>   !amd64? ( >=sys-apps/dtc-1.4.0 )
>   amd64? ( sys-devel/bin86
>   system-seabios? ( sys-firmware/seabios )
> diff --git a/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild 
> b/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> index 57d618e..e9f84c0 100644
> --- a/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.6.0-r4.ebuild
> @@ -87,7 +87,7 @@ DEPEND="${COMMON_DEPEND}
>   ${PYTHON_DEPS}
>   api? ( dev-libs/libxml2
>   net-misc/curl )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
>   !amd64? ( >=sys-apps/dtc-1.4.0 )
>   amd64? ( sys-devel/bin86
>   system-seabios? ( sys-firmware/seabios )
> diff --git a/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild 
> b/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> index 104fac9..ceb1402 100644
> --- a/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> +++ b/app-emulation/xen-tools/xen-tools-4.6.0-r5.ebuild
> @@ -90,7 +90,7 @@ DEPEND="${COMMON_DEPEND}
>   ${PYTHON_DEPS}
>   api? ( dev-libs/libxml2
>   net-misc/curl )
> - ovmf? ( ${PYTHON_DEPS//${PYTHON_REQ_USE}/sqlite} )
> + ovmf? ( $(python_gen_impl_dep sqlite) )
>   !amd64? ( >=sys-apps/dtc-1.4.0 )
>   amd64? ( sys-devel/bin86
>   system-seabios? ( sys-firmware/seabios )
> 

Acked-by: Doug Goldstein <car...@cardoe.com>

I actually made ncurses always required in recent versions to try and
avoid this hack. I'm glad there's a nicer way to officially do this.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Use GLEP27!

2015-12-14 Thread Doug Goldstein
On 12/14/15 12:06 AM, Robin H. Johnson wrote:
> On Mon, Dec 14, 2015 at 07:49:42AM +0300, Alexey Shvetsov wrote:
>> Hi!
>>
>> Ok. Since there is GLEP27 we should make it reality. To do so i think we 
>> should
>> 1. Have some list of system uid/gid (on wiki for example). Also we need 
>> to agree on uid/gid numbers for services
> This database was already started, prior to GLEP27.
> In CVS, you want gentoo-src/eid_database/
> 
>> 2. Add uid/gid from list to existing ebuilds
> 
>> 3. Make a repoman (or may be eclass) check, that will no allow to commit 
>> ebuilds with enewuser enewgroup calls with undefined uids
> I think in the original discussion, there were concerns that there were
> cases where this was going to be valid. I think this check needs to come
> later, after we rule those out. It should however start to warn about
> them ASAP.
> 
>> 4. Make some script or howto to migrate to determenistic uids/gids from 
> Much of the work was implemented for GSOC2006, "Creandus" by
> developer pioto.
> 
> Cardoe did more work on it later on.
> 

I'll try to find what I did but at one point I had the database of
uid/gid updated to include everything in the tree. I had some patches
for enewuser/enewgroup to not allow them to do anything unless the ids
were in the database.

Sadly, its been a long long time. But I still would love to see this
happen. There just wasn't much interest from everyone in making this happen.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Use GLEP27!

2015-12-14 Thread Doug Goldstein
On 12/14/15 3:22 AM, Michał Górny wrote:
> 
> 
> Dnia 13 grudnia 2015 21:41:02 CET, "Robin H. Johnson"
> <robb...@gentoo.org> napisał(a):
>>On Sun, Dec 13, 2015 at 09:03:51PM +0300, Alexey Shvetsov wrote:
>>> Hi all!
>>>
>>> We trying to use ldap for users @work, many of our workstations
>>running
>>> binary gentoo based distro called Calculate linux. However if we
>>wanna
>>> have wide use of ldap there is a need for determenistic system group
>>> gids names and user uids.
>>>
>>> Many ebuilds in tree uses enewgroup and enewuser with -1 (aka next
>>> available parameter)[1]. However it will be much better to set distro
>>
>>> wide deterministic uid and gid for system service name. So for
>>example
>>> ldap users may have determenistic groups like video, audio, plugdev,
>>> etc..
>>GLEP27 was approved for this, however it is barely used.
>>
>>Convert the rest of the tree to use it, and then you'll be done, aside
>>from the existing mess on user systems.
> 
> As far as I can see, this GLEP predates EAPI and does not meet modern
> standards. It needs to be updated or killed with fire.
> 
> For a start, relation to EAPI needs to be defined. This will likely
> require both profiles and ebuilds to use the new EAPI.
> 
> Also, the contents of 'backwards compatibility' section are
> unacceptable. But that's probably going to be covered by EAPI.
> 
> The spec itself is hard to follow, though the idea seems simple. It
> makes me wonder if we aren't missing something important there.
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.


Don't kill it. The best way forward would be to update it.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCHES] multilib-build & multilib-minimal EAPI 6 patchset

2015-12-10 Thread Doug Goldstein
On 12/6/15 12:57 PM, Michał Górny wrote:
> Hi, everyone.
> 
> Here's a patchset for review. Changes:
> 
> 1. eclass-generated variables are read-only,
> 2. missing error checks (||die) added,
> 3. 'unset -f' used to wipe local and temporary functions from the env,
> 4. deprecated function QA warnings turned into bans for EAPI 6,
> 5. eutils inherit fixes/updates.
> 
> Please review. I've tested it on a set of randomly selected packages.
> 
> 

Its worth noting that you should probably be utilizing --cover-letter to
git format-patch to generate this.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] news item: libvirt-1.2.19 init script upgrades

2015-09-09 Thread Doug Goldstein
The following is the proposed news item to inform OpenRC users of a
change to the init script setup for libvirt 1.2.19 and newer.

-- 
Doug Goldstein
Title: libvirt-1.2.19 init script changes
Author: Doug Goldstein <car...@gentoo.org>
Content-Type: text/plain
Posted: 2015-09-09
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: 

signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: app-emulation/kvm-kmod

2015-08-25 Thread Doug Goldstein
# Doug Goldstein car...@gentoo.org (25 Aug 2015)
# Masked for removal in 30 days. Users should use the modules available
# via the kernel as upstream has deprecated these packages.
app-emulation/kvm-kmod


--
Doug Goldstein



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] git commit / push signing error

2015-08-10 Thread Doug Goldstein
On Sun, Aug 9, 2015 at 9:00 PM, Kent Fredric kentfred...@gmail.com wrote:
 On 10 August 2015 at 13:40, Doug Goldstein car...@gentoo.org wrote:
 $ git push --signed origin master

 You need a passphrase to unlock the secret key for
 user: Doug Goldstein car...@cardoe.com
 4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24
  (subkey on main key ID 0x6C4E620431C9980D)

 gpg: cancelled by user
 gpg: skipped 0xA2BC03DC87ED1BD4: Operation cancelled
 gpg: signing failed: Operation cancelled
 error: gpg failed to sign the data
 fatal: failed to sign the push certificate
 fatal: The remote end hung up unexpectedly


 Your GPG is not working correctly.

 eg:  echo hello | gpg -a --sign # also fails

 export GPG_TTY=$(tty)

 try again. ( The GPG-Agent associates with the tty it was spawned in
 by default, and that tty might have evaporated )


 --
 Kent

 KENTNL - https://metacpan.org/author/KENTNL


This was it. Thanks. I use keychain and ssh into the box so I would
expect keychain would handle things for me correctly.

-- 
Doug Goldstein



[gentoo-dev] git commit / push signing error

2015-08-09 Thread Doug Goldstein
Hoping someone has the answer for me because I'm at a loss. I'm not
canceling the operating or hitting any key after enter.

$ git push --signed origin master

You need a passphrase to unlock the secret key for
user: Doug Goldstein car...@cardoe.com
4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24
 (subkey on main key ID 0x6C4E620431C9980D)

gpg: cancelled by user
gpg: skipped 0xA2BC03DC87ED1BD4: Operation cancelled
gpg: signing failed: Operation cancelled
error: gpg failed to sign the data
fatal: failed to sign the push certificate
fatal: The remote end hung up unexpectedly

-- 
Doug Goldstein



Re: [gentoo-dev] rfc: renaming rc binary in OpenRC

2013-12-11 Thread Doug Goldstein
On Wed, Dec 11, 2013 at 6:37 PM, Patrick Lauer patr...@gentoo.org wrote:
 On 12/12/2013 04:41 AM, William Hubbs wrote:
 All,

 We got a request from Debian to rename the rc binary of OpenRC due to
 a naming conflict they have. They have a port of the att plan 9 shell,
 which has a binary named rc as well[1].

 My thought is to rename our rc to openrc, since that would be
 unique.

 Make it build-time configurable. Keep default at rc. Let Debian and
 others rename it as they want/need.

 I know at least one thing that will break is everyone's inittab, so
 should I sed their inittab in our live ebuild or expect them to fix it
 and give a warning?

 It's change to change things, it doesn't fix any bugs we have.

 So don't break things for fun, please ...

Honestly, with Linux systems a symlink won't matter. Just rename the
binary to openrc so that we are closer with Debian. It would be nice
if in the future docs and blogs and other things could share the same
info.

For Gentoo just symlink rc - openrc and call it a day. There's also
no reason to remove the symlink in the next release like others have
said. Keep the thing around for as long as is possible. Cause if you
drop it, you're liable to break someone upgrading an old system and
they have a higher chance to miss an important ewarn and you know how
much I hate breaking upgrades.

-- 
Doug Goldstein



Re: [gentoo-dev] some multilib-minimal enhancements [0/6]: de-headerization

2013-12-11 Thread Doug Goldstein
On Wed, Dec 11, 2013 at 3:18 PM, Greg Turner g...@malth.us wrote:
 sorry for attaching these rather than in-lining but google insists on
 78-wrapping plain-text e-mail.  If HTML mail would be a better
 solution for people I'd be happy to re-send (unless maybe a single
 person requests it and a chorus of objections are raised :P).

 This series is available also in bug #493214.

Use git send-email, works perfectly fine with gmail. Attachments are
worthless and mostly considered spam.

-- 
Doug Goldstein



Re: [gentoo-dev] rfc: status of OpenRC's public API

2013-09-14 Thread Doug Goldstein
On Sat, Sep 14, 2013 at 11:35 AM, William Hubbs willi...@gentoo.org wrote:
 On Sat, Sep 14, 2013 at 12:47:04AM -0400, Alexandre Rostovtsev wrote:
 On Fri, 2013-09-13 at 22:48 -0500, William Hubbs wrote:
  On Fri, Sep 13, 2013 at 09:04:06PM -0400, Alexandre Rostovtsev wrote:
   app-admin/openrc-settingsd uses various functions (rc_sys(),
   rc_runlevel_get(), rc_service_exists(), rc_service_in_runlevel(),
   rc_service_resolve(), rc_service_mark() etc.) from rc.h
 
  Will this still be needed once gnome 3.8 is stable everywhere?

 It will not be needed for gnome. Possibly another desktop environment
 might have a use for it.

 Running  grep -r 'app-admin/openrc-settingsd' .  in a current
 gentoo-x86 tree shows the following output:

 ./app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild:# $Header: 
 /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/openrc-settingsd-1.0.1.ebuild,v
  1.8 2013/02/02 22:20:11 ago Exp $
 ./app-admin/openrc-settingsd/ChangeLog:# ChangeLog for 
 app-admin/openrc-settingsd
 ./app-admin/openrc-settingsd/ChangeLog:# $Header: 
 /var/cvsroot/gentoo-x86/app-admin/openrc-settingsd/ChangeLog,v 1.10 
 2013/02/02 22:20:11 ago Exp $
 ./app-admin/openrc-settingsd/CVS/Repository:gentoo-x86/app-admin/openrc-settingsd
 ./gnome-base/gnome-control-center/gnome-control-center-3.8.3.ebuild:|| ( 
 ( app-admin/openrc-settingsd sys-auth/consolekit ) =sys-apps/systemd-31 )
 ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1-r1.ebuild: 
   || ( ( app-admin/openrc-settingsd sys-auth/consolekit ) 
 =sys-apps/systemd-31 )
 ./gnome-base/gnome-control-center/gnome-control-center-3.8.4.1.ebuild:  || ( 
 ( app-admin/openrc-settingsd sys-auth/consolekit ) =sys-apps/systemd-31 )
 ./gnome-base/gnome-control-center/gnome-control-center-3.6.3-r1.ebuild:   
   app-admin/openrc-settingsd
 ./gnome-extra/cinnamon/cinnamon-1.8.8.1.ebuild: 
 app-admin/openrc-settingsd
 ./gnome-extra/cinnamon/cinnamon-1.6.7-r2.ebuild:
 app-admin/openrc-settingsd

 It looks like this is gnome specific to me.

 I would be concerned about another desktop environment linking to these
 libraries because that seems to be the same type of vertical integration
 gnome is doing with systemd.
 linking to these libraries because that seems to be the same type of
 vertical integration gnome is doing with systemd.

 William


Cinnamon is not requiring systemd, so removing openrc-settingd will
break that environment.

-- 
Doug Goldstein



Re: [gentoo-dev] rfc: stabilization policies

2013-08-20 Thread Doug Goldstein
On Tue, Aug 20, 2013 at 7:42 PM, Rich Freeman ri...@gentoo.org wrote:

 On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel
 dilfri...@gentoo.org wrote:
 
  Stable implies not so often changing. If you really need newer
 packages on a
  system that has to be rock-solid, then keyword what you need and nothing
 else.

 ++

 30 days is too long?  How can something new be stable?  Stable doesn't
 mean I don't think this is broken.  Stable means lots of others
 have already been using this and so far there aren't many reports of
 breakage.


Stable also means this is less broken than current stable. In the past I've
gotten push back from arch teams on all sorts of items I consider to be
unrelated to the stabilization request. Yes it'd be great if the world was
black and white and 30 days was a magical cut off but many times its not.
If current stable is causing a crash or some bad user case, I'll ask for a
quick stabilization of a revbump that contains a small scope patch that a
user can confirm it fixes the issue.



 According to distrowatch RHEL is at 2.6.32.  I'm sure it has a
 bazillion backports, but that is what I'd call stable.  Running stable
 means starting to use the stuff everybody else is about ready to stop
 using.  When an upstream releases a new stable release, that means
 that it is just now ready for testing, and chances are they'll have
 another stable release before their previous release really is stable.


Apples and oranges. Its 2.6.32 for the kabi, which they maintain and
support. They have plenty of things that landed in 3.7 in RHEL 6.4. They
have a solid QA procedure to vet their kernels and they're not afraid to
turn the crank on small targeted fixes and pushing those out to resolve
issues as the release matures.



 If you need the release two days after it comes out, you're not really
 looking for a stable release.

 At work we typically buy stuff about a year after it comes out, and by
 the time we're done doing integration and testing it is probably two
 years old and we've gotten 27 patches in the meantime.  That's stable.


Correlation is not causation. Just because software or hardware sat of the
shelf for a year doesn't mean its any more or less stable when it was
originally shipped. If a vendor has a high level of QA with multi-layed
test processes that product will probably more stable out the door than a
vendor with no QA that kicked the product out the door and let their early
adopters find the bugs over the past year. I say probably because again the
world isn't black and white. Your use case with both products could be
exposing a corner case that no user before you and no QA engineer before
you had tried and both products will go boom.



 Gentoo is one of the few distros that really lets you mix and match,
 so run stable on the stuff you don't care about, and if the purpose of
 the box is to serve apps on Rails then by all means use ~arch on Ruby.
  You can do that and not worry about whether it is going to be broken
 by the latest glibc or coreutils or whatever.

 Rich


Its also precisely that mix and match that might cause instability due to
people not testing things. Case in point QEMU 1.6.0 just came out and it
went through a number of release candidates but no one ever saw that it
depends only on Python 2.4 but actually needs Python 2.6. That's kind of
like Gentoo, a package says it depends on libfoo 1.0 or higher and the dev
that tested stable baz 0.8 confirmed it worked with libfoo 1.0, but baz 0.9
in ~arch still depends on libfoo 1.0 but really needs libfoo 1.1 and libfoo
1.1 is ~arch as well. So the developer running ~arch believed that baz 0.9
works fine since he has ~arch libfoo.

My point is what Gentoo calls stable is just something that usually 2 or
more people have compiled and installed vs ~arch which 1 or more people
have compiled and installed.

-- 
Doug Goldstein


Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon

2013-08-17 Thread Doug Goldstein
On Fri, Aug 16, 2013 at 10:30 PM, Dale rdalek1...@gmail.com wrote:

 Doug Goldstein wrote:
 
  sys-apps/etckeeper is what you want. Works great. It even has portage
  integration. Though I'd recommend going with the ~arch version instead
  of stable for that portion.
 
  --
  Doug Goldstein

 I think this is something dispatch-conf does too.  I use that but still
 make a backup myself, just in case.  Generally, a successful reboot is a
 good sign that the configs are working.

 Going to look into this but the home page doesn't really show me much, yet.



You'll want USE=cron enabled so that you get the benefits of etckeeper
taking a note of someone or something changing a config and not committing
it. Additionally without USE=cron, when you emerge the next package
etckeeper will think that the most recent package you emerged changed a
file that it didn't if you manually changed a file.

Once that's done just do:
# etckeeper init -d /etc
# bzcat /usr/share/doc/etckeeper-1.7/examples/bashrc.bz2 
/etc/portage/bashrc

And you're set.

-- 
Doug Goldstein


Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon

2013-08-16 Thread Doug Goldstein
On Fri, Aug 16, 2013 at 11:46 AM, Rich Freeman ri...@gentoo.org wrote:

 On Fri, Aug 16, 2013 at 12:14 PM, Ian Stakenvicius a...@gentoo.org wrote:
  For everyone's information -- The conf.d/net removal on upgrade is a
  packaging issue, which could not have been tested prior to
  openrc-0.12.ebuild hitting the tree.  There are details in
  https://bugs.gentoo.org/show_bug.cgi?id=481336 if anyone's interested
  in why it's happening.
 
  I've fixed the 0.12.ebuild in the tree now.  It's a hack but it seems
  to be the best possible solution.

 Thanks for the update.  From the other report it seems unlikely that
 calling for volunteers would have turned up much.

 That's just the nature of ~arch - if you get an openrc update you're
 among the first.  Gentoo users should know what they're doing
 regardless, and ~arch users doubly-so.

 Also, it really isn't Gentoo-specific, but putting /etc in a git repo
 is a really good practice, and I'm wondering if it should go in the
 handbook as a result.

 Rich


sys-apps/etckeeper is what you want. Works great. It even has portage
integration. Though I'd recommend going with the ~arch version instead of
stable for that portion.

-- 
Doug Goldstein


Re: [gentoo-dev] renaming gentoo-oldnet

2013-08-03 Thread Doug Goldstein
On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs willi...@gentoo.org wrote:
 On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote:
 On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs willi...@gentoo.org wrote:
  Actually the plan is to generalize it so that it works with other init
  systems. Right now it is very tightly integrated with OpenRc, but there
  is interest in changing that, so adding openrc to the name would be
  misleading eventually.

 OK... so gentoo-networking? or just come up with own name? best-networking?

 I don't know about best-networking. ;-) One reason we are splitting it
 out also is so it can have its own development/release cycle; the
 oldnet stuff is responsible for about 1/3 of the bugs against OpenRc
 right now, and it is very difficult to test because of all of the
 possibilities.

You and I have had this talk more times than I can remember at this
point. Using the name oldnet sucks and was one of the worst choices
possible. Looking through our IRC chats, I had also suggested
gentoo-networking. Its really a shame because this dependency based
networking is really one of the real strengths of Gentoo and its
really just being given the cold shoulder. Our dependency based init
system was one of the reasons many people used Gentoo back in the day
(besides the zomg its source its faster use -O6 crowd).

In our discussions I've suggested trimming back the support in the
networking scripts from all the various options (they support 4 DHCP
clients for example) and slowly push these scripts to be installed by
the package and maintained by the package maintainer (e.g. the pump
script can be managed by the net-misc/pump maintainer and so on and so
forth). Give them a name (systemd did by calling these snippets unit
files) like OpenRC net snippets (Don't let me come up with names, I'm
not good at that part, just ask my co-workers) and maintain an API
for them.


 However, I do not understand how you can port it without changing the
 notations... or lowering features... example: rc_net_*_provide,
 rc_net_*_need, or the rc_config, rc_use, rc_net_*_provide=!net
 etc...

 Do you think systemd users can understand that /etc/conf.d/net is
 actually a shell script? I hope this is not going to be eliminated, as
 I use it a lot.

 Robin is going to do most of it I think; I'm not exactly sure what he
 has in mind.

 William


If we lose that flexibility and configurability then just give up on
OpenRC right now cause its dead because all interesting features are
gone and it'll just become an inferior init system that needs to be
replaced.

-- 
Doug Goldstein



Re: [gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE

2013-05-23 Thread Doug Goldstein
On Thu, May 23, 2013 at 2:31 PM, Mike Frysinger vap...@gentoo.org wrote:

 On Thursday 09 May 2013 12:59:11 Pacho Ramos wrote:
  El mié, 08-05-2013 a las 20:59 -0400, Mike Frysinger escribió:
   On Wednesday 05 December 2012 18:02:51 Doug Goldstein wrote:
- if grep -q disable-scrollkeeper configure; then
+ if grep -q disable-scrollkeeper ${ECONF_SOURCE:-.}/configure;
 then
  
   ECONF_SOURCE should be quoted
   -mike
 
  If it doesn't cause any problem (it shouldn't, I think), feel free to
  commit adding the quotes. Thanks for noticing! (will CC gnome team to
  keep them aware)

 Index: gnome2.eclass
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/gnome2.eclass,v
 retrieving revision 1.120
 diff -u -p -r1.120 gnome2.eclass
 --- gnome2.eclass   16 Jan 2013 23:01:02 -  1.120
 +++ gnome2.eclass   23 May 2013 19:31:00 -
 @@ -122,7 +122,7 @@ gnome2_src_configure() {
 # Remember to drop 'doc' USE flag from your package if it was only
 used to
 # rebuild docs.
 # Preserve old behavior for older EAPI.
 -   if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
 +   if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
 if has ${EAPI:-0} 0 1 2 3 4  in_iuse doc ; then
 G2CONF=$(use_enable doc gtk-doc) ${G2CONF}
 else
 @@ -132,29 +132,29 @@ gnome2_src_configure() {

 # Pass --disable-maintainer-mode when needed
 if grep -q ^[[:space:]]*AM_MAINTAINER_MODE(\[enable\]) \
 -   ${ECONF_SOURCE:-.}/configure.*; then
 +   ${ECONF_SOURCE:-.}/configure.*; then
 G2CONF=--disable-maintainer-mode ${G2CONF}
 fi

 # Pass --disable-scrollkeeper when possible
 -   if grep -q disable-scrollkeeper ${ECONF_SOURCE:-.}/configure;
 then
 +   if grep -q disable-scrollkeeper ${ECONF_SOURCE:-.}/configure;
 then
 G2CONF=--disable-scrollkeeper ${G2CONF}
 fi

 # Pass --disable-silent-rules when possible (not needed for
 eapi5), bug
 #429308
 if has ${EAPI:-0} 0 1 2 3 4; then
 -   if grep -q disable-silent-rules
 ${ECONF_SOURCE:-.}/configure; then
 +   if grep -q disable-silent-rules
 ${ECONF_SOURCE:-.}/configure; then
 G2CONF=--disable-silent-rules ${G2CONF}
 fi
 fi

 # Pass --disable-schemas-install when possible
 -   if grep -q disable-schemas-install ${ECONF_SOURCE:-.}/configure;
 then
 +   if grep -q disable-schemas-install
 ${ECONF_SOURCE:-.}/configure; then
 G2CONF=--disable-schemas-install ${G2CONF}
 fi

 # Pass --disable-schemas-compile when possible
 -   if grep -q disable-schemas-compile ${ECONF_SOURCE:-.}/configure;
 then
 +   if grep -q disable-schemas-compile
 ${ECONF_SOURCE:-.}/configure; then
 G2CONF=--disable-schemas-compile ${G2CONF}
 fi

 -mike


I guess I forgot to commit that to the tree when I posted it a few days
ago/week, w/e. Yeah commit that. My original commit was wrong.

-- 
Doug Goldstein


Re: [gentoo-dev] sys-apps/texinfo vs @system

2013-03-31 Thread Doug Goldstein
On Sun, Mar 31, 2013 at 12:59 AM, Mike Frysinger vap...@gentoo.org wrote:
 the new texinfo-5.x series has rewritten makeinfo in perl.  the main `info`
 program is still in pure C.

 when it comes to packages installing .info pages, it's largely limited to the
 GNU projects as the format has never really caught on.  many of those projects
 also install man pages.

 personally, i've never found info pages usable.  for most utils, the man pages
 or the --help output is sufficient, and for people doing heavy development, 
 the
 online html manuals are significantly more useful.

agreed.


 when it was pure C, i could live with it as it's only 1MiB and no real deps
 to speak of.  now it's more like 3MiB, and pulls in 3 semi-uncommon additional
 perl packages (not to mention perl itself).

 it's in @system for two reasons: it provides `info` and `makeinfo`.  the
 former is for reading info pages (i.e. RDEPEND) while the latter is used for
 generating info pages (i.e. DEPEND) when the tarball didn't ship with them
 pregenerated (they usually do).

 one option would be to make the makeinfo stuff into a USE flag so all the perl
 junk isn't pulled in by default.  only the packages that actually generate
 info pages can DEPEND on that.

 it'd be simpler if we just dropped it altogether from @system.  if people want
 `info`, they can `emerge` it themselves.  if packages want `makeinfo`, they
 can DEPEND on it -- few fall into this category (100 by a rough survey of
 random Gentoo installs).

 obviously my preference is for the latter.
 -mike

I agree with the later as well.

-- 
Doug Goldstein



[gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers

2013-03-03 Thread Doug Goldstein
One of the reasons people volunteer in open source projects is to
scratch their personal itch. When that itch develops into a festering,
gangrenous limb it becomes time to amputate it. That is what I am
doing with my involvement in x11-drivers/nvidia-drivers. As a result
someone will need to work with spock and rej to figure out what
aspects they are able to maintain and then maintain the components
they aren't able to. For example, different hardware has different
series of drivers to support it.

-- 
Doug Goldstein



Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass

2013-02-21 Thread Doug Goldstein
On Thu, Feb 21, 2013 at 12:42 PM, Anthony G. Basile
bas...@opensource.dyc.edu wrote:
 Hi everyone,

 This issue has come up in a few bugs so I want to bounce it off the
 community.  When building packages that need a configured kernel source
 tree, many ebuilds inherit linux-info to find configuration info about the
 kernel.  However, there is the running kernel with its configuration
 (/proc/config.gz if it exists), there is the kernel source tree
 (/usr/src/linux if it exists and is configured) and both of these can be of
 a different version than linux-headers.  Since building modules consumes
 headers from /usr/include/linux, but uses code from /usr/src/linux and then
 these modules are expected to insmod against the running kernel, all of
 which can be mismatched, we have a lot of room for breakage.  Eg. bug
 #458014.

 Any ideas about how to deal cleanly with situations like that?

 --
 Anthony G. Basile, Ph. D.
 Chair of Information Technology
 D'Youville College
 Buffalo, NY 14201
 (716) 829-8197


Kernel modules never use /usr/include/linux. That's the uapi headers,
which are now broken out in 3.7 and newer. Kernel modules always use
/usr/src/linux.

There have been a number of issues with the differences between the
user space bits and the kernel space bits wrt to netfilter post 3.0,
so its not surprising that a userspace component is trying to use
/usr/include/linux to frame up a structure to pass into kernel space
via netlink and running into an issue.

This is one of the reasons behind kapi/uapi to make it clear you
shouldn't play with or touch this field/structure/value from user
space.

-- 
Doug Goldstein



Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory

2013-02-10 Thread Doug Goldstein
On Fri, Feb 8, 2013 at 11:53 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 Any objections if I slap a generic package.mask on every firmware package
 installing to wrong directory?
 Half of them install to /$(get_libdir)/firmware as opposed to correct
 /lib/firmware.
 Most of them are maintainer-needed@ and very old.

 Then intrested parties get to fix what they want and unmask?

 - Samuli


Whatever is correct and sticks should have a pkgmove added so that
users don't have long lasting issues.

-- 
Doug Goldstein



Re: [gentoo-dev] fcaps.eclass: bringing filesystem capabilities to the tree

2013-01-26 Thread Doug Goldstein
On Fri, Jan 25, 2013 at 5:51 PM, Mike Frysinger vap...@gentoo.org wrote:
 i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
 most settings are now defaults
 -mike


Good deal. Good idea on using USE=filecaps instead of USE=caps due to
the requirements. Once this hits the tree I'll likely start using it
for app-emulation/qemu.

-- 
Doug Goldstein



Re: [gentoo-dev] Separately buildable binary blobs

2013-01-20 Thread Doug Goldstein
On Sun, Jan 20, 2013 at 10:45 PM, Peter Stuge pe...@stuge.se wrote:
 Doug Goldstein wrote:
 sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios,
 sys-firmware/vgabios
 ..
 So basically, how important is it to keep supporting these separately
 buildable blobs knowing that it might slow the release of QEMU within
 our own tree.

 Each of those sys-firmware/ packages have quite significant use cases
 well outside of QEMU.

Aware of that, but no one added them to the tree prior to me adding
them to the tree for QEMU. Since then I haven't had a single user
report a bug or contact me in any way about using it outside of QEMU.
The one exception is myself with ipxe as I use that at work to provide
something similar to boot.fedoraproject.org but on a much grander
scale.


 Note also that in particular SeaBIOS but possibly the others too are
 really recommended to build with a separate, known-good, toolchain -
 even if you're building for the same platform that you run on.

Aware of that as well, you'll notice we have always defaulted to using
pre-built binaries of the releases by Kevin O'Connor the upstream
maintainer and for any bugs reported with QEMU if someone built their
own BIOS I always tell them they need to try with the upstream blob.


The point of my original post was we go through the effort to ALLOW
users to build their own binary blobs but is it really necessary as
part of our culture? If this was Debian the answer would obviously be
yes.

-- 
Doug Goldstein



[gentoo-dev] Separately buildable binary blobs

2013-01-18 Thread Doug Goldstein
How important are separately buildable binary blobs? Rather than speak
in terms of app/foo and app/bar, I'll just come out and say its
app-emulation/qemu. Due to the nature of the package it relies on
firmware blobs to emulate certain aspects of the system (e.g. BIOS).
I've been working on making each of the binary blobs buildable and
adding them to the tree e.g.
sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios,
sys-firmware/vgabios. Unfortunately QEMU upstream keeps their own
repos of the various components and for each release builds their own
and commits it within their repo. They ship with these pre-built blobs
and that is what they install by default. The result is from the true
package upstreams there often is not a release that works with QEMU.
For example, QEMU 1.3.0 requires a git revision of SeaBIOS.

So basically, how important is it to keep supporting these separately
buildable blobs knowing that it might slow the release of QEMU within
our own tree.

-- 
Doug Goldstein



Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c

2013-01-18 Thread Doug Goldstein
On Thu, Jan 17, 2013 at 1:21 PM, Pacho Ramos pa...@gentoo.org wrote:
 # Pacho Ramos pa...@gentoo.org
 # Dead since 2003, doesn't work with journaling filesystems.
 # Also collides with dev-util/smem (#288721). Removal in a month.
 app-misc/secure-delete


FWIW, we also have app-misc/scrub in the tree which likely does similar things.

http://code.google.com/p/diskscrub/

-- 
Doug Goldstein



Re: [gentoo-dev] app-emulation/qemu-user mask

2013-01-16 Thread Doug Goldstein
On Mon, Jan 14, 2013 at 11:01 AM, Doug Goldstein car...@gentoo.org wrote:
 On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov ale...@gentoo.org wrote:
 В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал:
 On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote:
  Hi!
 
  For cross-chroots its needed to have static qemu-$arch user translators.
  May be you can introduce user-static use flag for them? Also it will be
  cool to have init script for kvm

 USE=static is available for app-emulation/qemu. I'll get a chroot for
 arm setup soon and test everything to make sure its working well.

 It doesnt allow to build dynamik qemu-system* and static user targets

 That can be fixed. File a bug.


To follow this up. I've successfully installed and am using an arm
chroot on my amd64 box using app-emulation/qemu-1.2.2 not using
USE=static. But it required a little bit of effort (using ldd or
readelf to bring in the necessary libraries) so I'll introduce
USE=static-user and USE=static-softmmu, both of which will be enabled
by USE=static.


-- 
Doug Goldstein



Re: [gentoo-dev] removing the server profiles...

2013-01-16 Thread Doug Goldstein
On Wed, Jan 16, 2013 at 8:16 AM, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 16/01/13 08:32 AM, Panagiotis Christopoulos wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0
 transition would be a good moment to finally remove the (also in
 my opinion rather useless) server profiles.


 The server profiles are not useless, if we can maintain them, and
 if they actually are, nowadays, they shouldn't be.

 -1, unless other profile options being offered are minimal enough
 for the job and enabling certain things that someone may need in a
 server.


 Just to summarize the last massive thread on this:

 1 - they aren't maintained; they haven't changed for years

I think you're confusing updates with maintenance. They work fine as
is therefore no need for updates.


 2 - the only difference between server profiles and the base profile
 is USE=+snmp and maybe one other flag

USE=-perl -python snmp truetype xml


 3 - there isn't any general consensus on what makes a server, as such
 there isn't any consensus on how to make server profiles more useful.

Just make the base profile as minimal as possible and people will be happy.



 ... i think that's about it?

 PS: +1 from me.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)

 iF4EAREIAAYFAlD2tjQACgkQ2ugaI38ACPDGbwEAr4WGmtio2d+uWTkroEGCbu4U
 53GdR5R3A4Fti8UXzj8A/iM805vMnkojNTNGw8b5XYVXPbYrZ9TJ4GPp0onE8AK8
 =6Lja
 -END PGP SIGNATURE-




-- 
Doug Goldstein



Re: [gentoo-dev] app-emulation/qemu-user mask

2013-01-14 Thread Doug Goldstein
On Mon, Jan 14, 2013 at 1:47 AM, Alexey Shvetsov ale...@gentoo.org wrote:
 В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал:
 On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote:
  Hi!
 
  For cross-chroots its needed to have static qemu-$arch user translators.
  May be you can introduce user-static use flag for them? Also it will be
  cool to have init script for kvm

 USE=static is available for app-emulation/qemu. I'll get a chroot for
 arm setup soon and test everything to make sure its working well.

 It doesnt allow to build dynamik qemu-system* and static user targets

That can be fixed. File a bug.



 With regards to the KVM init script, I'm uninterested in maintaining
 it and it doesn't belong in the package as it is. There's a number of
 submitted init scripts that are attempting to create init scripts
 but really they're re-inventing libvirt and ganeti, but instead
 poorly. Ones I know about are:

 https://bugs.gentoo.org/show_bug.cgi?id=321517
 https://bugs.gentoo.org/show_bug.cgi?id=406043

 Ghm.. Its some kind of overkill to install libvirt or gannety just for 1-2 vms




-- 
Doug Goldstein



Re: [gentoo-dev] app-emulation/qemu-user mask

2013-01-13 Thread Doug Goldstein
On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote:
 Hi!

 For cross-chroots its needed to have static qemu-$arch user translators. May
 be you can introduce user-static use flag for them? Also it will be cool to
 have init script for kvm


USE=static is available for app-emulation/qemu. I'll get a chroot for
arm setup soon and test everything to make sure its working well.


With regards to the KVM init script, I'm uninterested in maintaining
it and it doesn't belong in the package as it is. There's a number of
submitted init scripts that are attempting to create init scripts
but really they're re-inventing libvirt and ganeti, but instead
poorly. Ones I know about are:

https://bugs.gentoo.org/show_bug.cgi?id=321517
https://bugs.gentoo.org/show_bug.cgi?id=406043

-- 
Doug Goldstein



[gentoo-dev] app-emulation/qemu-user mask

2013-01-11 Thread Doug Goldstein
Just wanted to give everyone a heads up. app-emulation/qemu provides
all the functionality of app-emulation/qemu-user without all the
outstanding security bugs and issues the package has. For users using
a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I
presently use an arm chroot with app-emulation/qemu. Should there
truly be a missing feature, open a bug and I'll fix it. The only item
I'm aware of that app-emulation/qemu does not have is the binfmt
initscript. But I plan on adding that to the unstable version shortly.

If there are no objections for 30 days, I'll send a treecleaner notice
in 30 days and remove it 30 days after that (60 days from now).

-- 
Doug Goldstein



[gentoo-dev] Handy pybugz wrappers

2013-01-11 Thread Doug Goldstein
Anyone have handy pybugz wrappers for bumping ebuilds and fixing bugs?
I'm so used to the environment at work where a post-commit hook parses
specifically formatted commit messages to take several actions on
commits. I figure before I hack on any I'd ask if someone has some
that could be shared with the community. Really just looking to
combine steps like echangelog and repoman commit with pybugz.

-- 
Doug Goldstein



Re: [gentoo-dev] glibc-2.17: nscd is optional

2013-01-01 Thread Doug Goldstein
On Mon, Dec 31, 2012 at 11:13 PM, Maxim Kammerer m...@dee.su wrote:
 On Tue, Jan 1, 2013 at 2:10 AM, Alec Warner anta...@gentoo.org wrote:
 flatfile lookups are 2-4ms with hot cache. How much faster is the db
 option?

 I guess it depends on the implementation and how close is the system's
 operational situation to an ideal one (whether swap started thrashing,
 etc.). A DB is the proper solution that can be improved if necessary
 (e.g., keeping often-used parts in RAM). Filesystem where it resides
 can be offered hardware with lower seek time or better cache. But I
 agree that it is easy to rationalize bad solutions. I don't like
 waiting on an ls -l in addition to the system not being responsive
 due to some other reason, though. But maybe I am expecting too much,
 with even PolKit delegating each query to a full-blown Javascript
 library nowadays.


You realize that files are cached in RAM right? There's a page cache
and pages are ejected when the system needs that RAM for something
else and they're ejected in an LRU fashion. More than likely those
pages are always in cache. I say pages very liberally here because
most of the files we're dealing with are less than 4096 bytes (yep,
I'm making that assumption) so its really 1 page per file. The result
is that the request for the data (assuming mmap here) is handled by
just doing a bounds/range check and converting the virtual address to
the physical address the data is wired in. The time required to parse
the average GNOME single user desktop machine (I've got 44 users and
69 groups on that box) is likely smaller than the overhead of a DB.

-- 
Doug Goldstein



[gentoo-dev] Lastrites: app-emulation/qemulator

2012-12-07 Thread Doug Goldstein
# Doug Goldstein car...@gentoo.org (07 Dec 2012)
# Masked for removal in 30 days. (07 Jan 2012)
# Upstream says the project is dead and is being replaced
app-emulation/qemulator

-- 
Doug Goldstein



[gentoo-dev] [PATCH] gnome2.eclass does not respect ECONF_SOURCE

2012-12-05 Thread Doug Goldstein
The gnome2.eclass checks the configure script for certain items and
adjusts the arguments to econf based on those checks. Unfortunately
when checking the configure script it did not respect ECONF_SOURCE.
---
 gnome2.eclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/gnome2.eclass b/gnome2.eclass
index 3f7b2da..1f3e005 100644
--- a/gnome2.eclass
+++ b/gnome2.eclass
@@ -129,7 +129,7 @@ gnome2_src_configure() {
# Remember to drop 'doc' USE flag from your package if it was only used 
to
# rebuild docs.
# Preserve old behavior for older EAPI.
-   if grep -q enable-gtk-doc configure ; then
+   if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
if has ${EAPI-0} 0 1 2 3 4  has doc ${IUSE} ; then
G2CONF=${G2CONF} $(use_enable doc gtk-doc)
else
@@ -138,24 +138,25 @@ gnome2_src_configure() {
fi
 
# Pass --disable-maintainer-mode when needed
-   if grep -q ^[[:space:]]*AM_MAINTAINER_MODE(\[enable\]) configure.*; 
then
+   if grep -q ^[[:space:]]*AM_MAINTAINER_MODE(\[enable\]) \
+   ${ECONF_SOURCE:-.}/configure.*; then
G2CONF=${G2CONF} --disable-maintainer-mode
fi
 
# Pass --disable-scrollkeeper when possible
-   if grep -q disable-scrollkeeper configure; then
+   if grep -q disable-scrollkeeper ${ECONF_SOURCE:-.}/configure; then
G2CONF=${G2CONF} --disable-scrollkeeper
fi
 
# Pass --disable-silent-rules when possible (not needed for eapi5), bug 
#429308
if has ${EAPI:-0} 0 1 2 3 4; then
-   if grep -q disable-silent-rules configure; then
+   if grep -q disable-silent-rules ${ECONF_SOURCE:-.}/configure; 
then
G2CONF=${G2CONF} --disable-silent-rules
fi
fi
 
# Pass --disable-schemas-install when possible
-   if grep -q disable-schemas-install configure; then
+   if grep -q disable-schemas-install ${ECONF_SOURCE:-.}/configure; then
G2CONF=${G2CONF} --disable-schemas-install
fi
 
-- 
1.8.0




[gentoo-dev] Lastrite: app-emulation/kqemu

2012-11-21 Thread Doug Goldstein
# Doug Goldstein car...@gentoo.org (21 Nov 2012)
# Masked for removal. Lots of bugs opened. Upstream
# says don't use it. No Gentoo maintainer
# activity for some time. qemu no longer supports it.
# Removal date: 21 Dec 2012
app-emulation/kqemu

-- 
Doug Goldstein



[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: nvidia-driver.eclass

2012-11-17 Thread Doug Goldstein
On Sun, Nov 18, 2012 at 12:18 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 18/11/12 07:47, Doug Goldstein (cardoe) wrote:

 cardoe  12/11/18 05:47:02

Modified: nvidia-driver.eclass
Log:
Update to support a new legacy series

 Revision  ChangesPath
 1.16 eclass/nvidia-driver.eclass

 file :
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16view=markup
 plain:
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16content-type=text/plain
 diff :
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?r1=1.15r2=1.16

 Index: nvidia-driver.eclass
 ===
 RCS file: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v
 retrieving revision 1.15
 retrieving revision 1.16
 diff -u -r1.15 -r1.16
 --- nvidia-driver.eclass22 Aug 2011 04:46:32 -  1.15
 +++ nvidia-driver.eclass18 Nov 2012 05:47:02 -  1.16
 @@ -1,6 +1,6 @@
   # Copyright 1999-2011 Gentoo Foundation
   # Distributed under the terms of the GNU General Public License v2
 -# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.15
 2011/08/22 04:46:32 vapier Exp $
 +# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.16
 2012/11/18 05:47:02 cardoe Exp $

   # @ECLASS: nvidia-driver.eclass
   # @MAINTAINER:
 @@ -30,9 +30,21 @@
   031b 031c 0320 0321 0322 0323 0324 0325 0326 0327 0328 032a 032b 032c
 032d \
   0330 0331 0332 0333 0334 0338 033f 0341 0342 0343 0344 0347 0348 034c
 034e

 +drv_304x=0040 0041 0042 0043 0044 0045 0046 0047 0048 004e 0090 0091
 0092 \
 +0093 0095 0098 0099 009d 00c0 00c1 00c2 00c3 00c8 00c9 00cc 00cd 00ce
 00f1 \
 +00f2 00f3 00f4 00f5 00f6 00f8 00f9 0140 0141 0142 0143 0144 0145 0146
 0147 \
 +0148 0149 014a 014c 014d 014e 014f 0160 0161 0162 0163 0164 0165 0166
 0167 \
 +0168 0169 016a 01d0 01d1 01d2 01d3 01d6 01d7 01d8 01da 01db 01dc 01dd
 01de \
 +01de 01df 0211 0212 0215 0218 0221 0222 0240 0241 0242 0244 0245 0247
 0290 \
 +0291 0292 0293 0294 0295 0297 0298 0299 029a 029b 029c 029d 029e 029f
 02e0 \
 +02e1 02e2 02e3 02e4 038b 0390 0391 0392 0393 0394 0395 0397 0398 0399
 039c \
 +039e 03d0 03d1 03d2 03d5 03d6 0531 0533 053a 053b 053e 07e0 07e1 07e2
 07e3 \
 +07e5
 +
   mask_96xx==x11-drivers/nvidia-drivers-97.0.0
   mask_71xx==x11-drivers/nvidia-drivers-72.0.0
   mask_173x==x11-drivers/nvidia-drivers-177.0.0
 +mask_173x==x11-drivers/nvidia-drivers-305.0.0


 I don't know the eclass, but shouldn't this say mask_304x here ?


   # @FUNCTION: nvidia-driver-get-card
   # @DESCRIPTION:
 @@ -71,6 +83,13 @@
 return 0;
 fi
 done
 +
 +   for drv in $drv_304x; do
 +   if [ x$card = x$drv ]; then
 +   echo $mask_304x;
 +   return 0;
 +   fi
 +   done
 done

 echo ;






Thank you for finding the flaw in my mail filter rule to delete these
e-mails when they hit gentoo-dev, where I'm directly addressed. In the
future if you want these e-mails to go through you'll have to e-mail
me directly without CCing the list or sending it to the list. Just
doing my part to help clean up pointless e-mails to -dev one mail
filter at a time.

That said, you are actually correct.

-- 
Doug Goldstein



Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-17 Thread Doug Goldstein
, to succeed.  Without knowing the problems you
  are having, there's no way anyone will ever change.

 We already have OpenRC, which has been found to work well on both Gentoo
 Linux and Gentoo FreeBSD. The integration of udev into systemd has
 caused problems for existing OpenRC systems with people being told that
 it is okay to break configurations that users had been told to use over
 well over a decade. Many of us consider that to be unacceptable.

 Part of the goal of systemd is to unify all Linux distros startup logic,
 and configuration logic, to make things unified to help a whole lot of
 things happen better and faster in the end.  It is a move to save
 effort, and, is succeeding quite well.  If Gentoo does not wish to
 participate in this effort, then those of us who are participating in
 it, and are Gentoo developers, should be told this so that we can decide
 what we wish to do.

 OpenRC is great, and has worked well for 10+ years.  But seriously, it
 is creaky in places, and doesn't do much at all compared to what systemd
 offers.  If Gentoo wants to ignore systemd, it does so at its own peril.

 Oh, and systemd has nothing to do with the /usr issue, don't ever get
 that confused.  A separate /usr broke a long time ago, systemd just now
 shows you how broken your system really was, and you didn't notice it :)

 Anyway, results are what are important. If you are interested in what we
 are doing, then I suggest coming back in a month to see what we have
 produced.

 Why a month?  Where did that deadline come from?

 And again, the main question that has never been answered yet, What are
 you trying to do here?

 thanks,

 greg k-h


Greg,

While I agree you have some valid points here, I do think you're being
a bit discouraging towards this. Honestly if they want to go off and
work on this project because it gets them excited about open source
then that's a good thing and they should be allowed to do that (the
whole Gentoo Foundation thing and copyright business aside) as a stand
alone project. What stake do you have in this to really hurl a bunch
of questions at them about their problems with existing solutions and
goals? I'd honestly just drop it and let them do what developers are
suppose to do and produce some code. Maybe the project goes no where,
maybe it comes up with some interesting ideas that can be merged in
with other projects, or maybe it becomes something that stands on its
own.

My feeling is if people want to code, let them code. Let them do what
they want to do and enjoy themselves, even if you think their idea
sucks.

-- 
Doug Goldstein



Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

2012-11-17 Thread Doug Goldstein
On Sat, Nov 17, 2012 at 11:59 PM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 On 17/11/2012 21:52, Joshua Kinard wrote:
 It's human nature to wake up one day and exclaim, I will develop X!, and
 then go off and do so without any formal planning or even a rough idea of
 how to start.  Sometimes it works, and sometimes it doesn't.  Sometimes, you
 just roll dice.  That's what keeps life interesting.

 Agreed. Heck I've worked for how long on Gentoo/FreeBSD? And did I have
 a plan for most of that? Not really.

 But I didn't go around saying that I was not following the waterfall
 or developing AGILE. I was just doing shit that sounded cool and
 looked nice. Did I expect much out of it? Not really.

 At the end we did get something, in particular we got OpenRC out of it,
 which has served us very well for quite a while, and we never planned
 for it before that. But it was just luck, and I wouldn't brag about it.

Diego I'm going to have to call you out here. You've so far in this
thread claimed you were the reason behind the eudev project and now
claim you're behind OpenRC. Sounds like bragging to me.


 That's why I'm not saying please shut down the project, just please
 keep ryao away from the keyboard.

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




-- 
Doug Goldstein



Re: [gentoo-dev] Re: gentoo-x86/eclass: udev.eclass

2012-10-30 Thread Doug Goldstein
On Tue, Oct 30, 2012 at 2:17 PM, Fabian Groffen grob...@gentoo.org wrote:
 On 30-10-2012 19:08:39 +, Samuli Suominen wrote:
 Added: udev.eclass
 Log:
   New eclass to determine udevdir from udev.pc pkg-config file as requested 
 by many people, without ML review due to unproductive feedback

 Uhm...
 Please, stop doing this!


 --

Stop the bike shedding. Provide real constructive improvements. I'm
not copying and pasting the same hunk of code in a bunch of ebuilds.

-- 
Doug Goldstein



Re: [gentoo-dev] About DESCRIPTION in ebuilds needing to end with a dot .

2012-10-19 Thread Doug Goldstein
On Fri, Oct 19, 2012 at 2:01 PM, Pacho Ramos pa...@gentoo.org wrote:
 Hello

 At least in spanish, it's mandatory to end phrases with a dot ., would
 you agree with trying to enforce this trivial change with a repoman
 warning?

 Thanks for your opinions


I don't really see the advantage or upside. English requires sentences
end in a dot as well.


-- 
Doug Goldstein



Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)

2012-09-09 Thread Doug Goldstein
On Sun, Sep 9, 2012 at 3:13 PM, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 This news item was committed.


So the news item was a bit ambiguous on if I wanted to make the change
myself to the new locations when I could actually make the change.
Current portage supports it? Or is their a new version coming which I
would need?

-- 
Doug Goldstein



[gentoo-dev] app-emulation/qemu app-emulation/qemu-kvm folding into one package

2012-09-09 Thread Doug Goldstein
Hey all,

Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to
app-emulation/qemu at some point this week. The app-emulation/qemu
ebuilds will effectively die and be replaced by the
app-emulation/qemu-kvm ebuilds. I've brought this up before and there
was a bunch of rabble about keep our pristine qemu ebuilds!!!. The
fact of the matter is that the app-emulation/qemu just isn't getting
the same maintenance care that app-emulation/qemu-kvm is. I've really
only got the bandwidth to handle one at a time. Additionally this will
bring us inline with a few other distros use of qemu as they're really
building their binaries from qemu-kvm.

For those that want pure qemu builds, I recommend creating an overlay
and replacing the URL. The ebuilds will otherwise aim to be 100%
compatible.

-- 
Doug Goldstein



Re: [gentoo-dev] remove system set?

2012-08-16 Thread Doug Goldstein
On Thu, Aug 16, 2012 at 7:05 AM, Rich Freeman ri...@gentoo.org wrote:
 On Wed, Aug 15, 2012 at 10:04 AM, Fabian Groffen grob...@gentoo.org wrote:

 From that angle, if you wouldd remove the system set, would you add its
 contents to the Portage ebuild?  Portage itself doesn't need a compiler
 or might not need gawk, but whatever it runs (ebuilds) often need so.

 Nope - I'd add them to every ebuild, and only where needed.  That's
 the whole point.


 Adding libc, a compiler, linker, shell, etc. to almost any every ebuild
 looks pretty much useless to me.  Adding deps for all regular tools an
 ebuild uses (bash, sed, awk, cut, wc, ...) seems like error-prone and
 pretty much useless to me as well.  So, there is the system set which
 just is the central place where those packages are recorded.

 It is only useful for situations where people want to do something
 unusual.  Some would argue that this is the only situation where
 Gentoo is useful.  If I wanted a system just like everybody else's I
 guess I'd run Ubuntu, if not Windows or OSX.

 In any case, I do agree that getting there is associated with pain.  I
 just like to think that getting there someday would be nice.  I know
 that a systematic effort exists in mathematics to try to reduce all of
 math to a minimum set of axioms and have everything else be formally
 derived.  I consider that a thing of beauty, even if I don't care to
 read the two volumes necessary to get to 1+1=2.

 Rich


The other point of the system set is to get rid of the chicken and egg
problem. For example, virtually every package in the system set ships
as a tar, including tar itself. All the compression utilities ship as
tars, which need to be installed to build tar (think -z, -j, -J). You
need a standard C library to run virtually everything including tar,
which you need to extract your standard C sources. The list goes on.


-- 
Doug Goldstein



Re: [gentoo-dev] Kernel calls gcc directly: fine?

2012-08-12 Thread Doug Goldstein
On Sun, Aug 12, 2012 at 9:19 AM, Agostino Sarubbo a...@gentoo.org wrote:
 If you try to launch make V=1 from the kernel source directory you will see:

  gcc -Wp,-MD,scripts/mod/.empty.o.d  -nostdinc -isystem /usr/lib/gcc/x86_64-
 pc-linux-gnu/4.5.3/include -I/usr/src/linux-3.3.8-gentoo/arch/x86/include -
 Iarch/x86/include/generated -Iinclude  -include /usr/src/linux-3.3.8-
 gentoo/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
 -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-
 declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -
 march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-
 outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -
 DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno-
 asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-
 larger-than=2048 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-
 after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -
 DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s -
 DKBUILD_BASENAME=KBUILD_STR(empty)  -DKBUILD_MODNAME=KBUILD_STR(empty) -c
 -o scripts/mod/empty.o scripts/mod/empty.c


 So it calls gcc directly.

 I see we don't like gcc called directly from the tracker[1], but this is for
 packages/ebuild. Should this bug block that tracker or it is invalid?


 [1]: https://bugs.gentoo.org/show_bug.cgi?id=cc-directly


Its invalid. Kbuild has its own documented way to do cross compiles
and replace out the compiler (granted only gcc works for building the
official Linux tree, there has been efforts to use clang and icc but
those are not mainlined).

-- 
Doug Goldstein



Re: [gentoo-dev] force verbose build log as per PMS policy?

2012-08-04 Thread Doug Goldstein
On Fri, Aug 3, 2012 at 6:18 PM, hasufell hasuf...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 08/01/2012 06:07 PM, Michał Górny wrote:
 On Wed, 01 Aug 2012 13:13:43 +0200 hasufell hasuf...@gentoo.org
 wrote:

 We already had a discussion about cmake-utils.eclass and forcing
 verbose build log for that which was approved:
 http://archives.gentoo.org/gentoo-dev/msg_ce7d33748936663e84a5463fbf7f4d39.xml



 Also we have bug https://bugs.gentoo.org/show_bug.cgi?id=384193 and
 https://bugs.gentoo.org/show_bug.cgi?id=379497

 I opened a tracker
 https://bugs.gentoo.org/show_bug.cgi?id=429308

 Some devs seem unsure about that or want to have a council vote
 on that https://bugs.gentoo.org/show_bug.cgi?id=429332

 PMS doesn't have such a thing as a 'policy'. Gentoo can have one,
 and I believe that should be discussed per Gentoo policy.


 So that would simply mean we add that information to the devmanual?

 Should I open a bug with a devmanual patch then?

FFS, do not spam base-system yet again with stuff that's in the
process of being discussed still. Additionally, this is something that
should be fixed on the EAPI/eclass level and NOT per package. Putting
EXTRA_ECONF=--disable-silent-rules in EVERY package is epically
moronic. Make econf automatically use --disable-silent-rules.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/udev: udev-187-r1.ebuild udev-9999.ebuild ChangeLog

2012-08-04 Thread Doug Goldstein
On Sat, Aug 4, 2012 at 2:31 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 If you don't use double [[ then ${ROOT} will need  quoting


Don't do top post code reviews. Snip out the context and do code
reviews inline so that your feedback is meaningful. Top posting and
leaving the entire commit with CVS metadata and all is just wasteful
and silly.

-- 
Doug Goldstein



Re: [gentoo-dev] Problem with texlive-basic-2012 in portage

2012-07-30 Thread Doug Goldstein
On Mon, Jul 30, 2012 at 9:00 PM, easior eas...@tom.com wrote:
 Hi, all!

 I am a TeX user with TeX Live installed by Gentoo portage. Recently, I found
 that the TeX Live version have been updated to 2012 and I want to refresh my
 Gentoo system. Unfortunately, the package, texlive-basic-2012, couldn't be
 properly compiled. Viewed from the build.log, it maybe caused by the package
 zlib. The version of zlib did not match to texlive-basic since texlive-basic
 needs the zlib library with version 1.2.5.1, but the zlib in my gentoo is
 updated to version 1.2.7. On the other hand, the ebuild of zlib-1.2.5 have
 been removed by the Gentoo protage and the downgrading of zlib is not a good
 solution for zlib-1.2.7 is pulled by many packages.


$ revdep-rebuild
$ emerge -1 lua

Should do the trick.

--
Doug Goldstein



Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)

2012-07-23 Thread Doug Goldstein
On Mon, Jul 23, 2012 at 7:07 PM, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:

snip

 Starting with catalyst 2.0.10, make.conf and make.profile will be
 moved from /etc to /etc/postfix. Releng build boxes will be updated to

s/postfix/portage/

snip

-- 
Doug Goldstein



[gentoo-dev] ROMs category suggestion

2012-07-21 Thread Doug Goldstein
I've got a few ROMs to add to the tree and some which are already in
the tree if people have a suggestion where they should live. Short
list:

ipxe
openbios
seabios
sgabios
vgabios

-- 
Doug Goldstein



Re: [gentoo-dev] multiple package moves into one

2012-07-16 Thread Doug Goldstein
On Mon, Jul 16, 2012 at 8:49 AM, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 15/07/12 06:16 PM, Zac Medico wrote:
 On 07/15/2012 03:08 PM, Doug Goldstein wrote:
 Is it valid to do something like:

 move media-plugins/mytharchive media-plugins/mythplugins move
 media-plugins/mythbrowser media-plugins/mythplugins move
 media-plugins/mythgallery media-plugins/mythplugins move
 media-plugins/mythgame media-plugins/mythplugins move
 media-plugins/mythmovies media-plugins/mythplugins move
 media-plugins/mythnews media-plugins/mythplugins move
 media-plugins/mythweather media-plugins/mythplugins

 No, that's not really how it's intended to be used. You'll probably
 have to put blockers in media-plugins/mythplugins to block all the
 old packages that install the same files.

 Theoretically (i've done a quick test on this and it seems true) a
 single-! blocker is enough that one package will on upgrade replace
 all these others without user intervention being required (assuming
 these packages aren't in @world, of course), and it won't cause file
 collisions.

 Unrelatedly curious, why the package merge?

Trying to make MythTV maintenance easier on myself since I couldn't
find a maintainer. Upstream changed to SVN a long while back and with
that changed moved all the plugins into one bundle called mythplugins.
They've now switched to git and with that change I decided to
modernize a little bit.

mythtv.git a few top level directories, each of which is packaged as
its own tarball which makes backporting patches extra fun. The
mythplugins tarball (mythtv.git/mythplugins) contains additional
plugins that are found in different git repos.

They're still unique snowflakes with their git usage.

-- 
Doug Goldstein



[gentoo-dev] multiple package moves into one

2012-07-15 Thread Doug Goldstein
Is it valid to do something like:

move media-plugins/mytharchive media-plugins/mythplugins
move media-plugins/mythbrowser media-plugins/mythplugins
move media-plugins/mythgallery media-plugins/mythplugins
move media-plugins/mythgame media-plugins/mythplugins
move media-plugins/mythmovies media-plugins/mythplugins
move media-plugins/mythnews media-plugins/mythplugins
move media-plugins/mythweather media-plugins/mythplugins

Thanks.
-- 
Doug Goldstein



Re: [gentoo-dev] multiple package moves into one

2012-07-15 Thread Doug Goldstein
On Sun, Jul 15, 2012 at 5:14 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Sun, 15 Jul 2012 17:08:45 -0500
 Doug Goldstein car...@gentoo.org wrote:
 Is it valid to do something like:

 move media-plugins/mytharchive media-plugins/mythplugins
 move media-plugins/mythbrowser media-plugins/mythplugins
 move media-plugins/mythgallery media-plugins/mythplugins
 move media-plugins/mythgame media-plugins/mythplugins
 move media-plugins/mythmovies media-plugins/mythplugins
 move media-plugins/mythnews media-plugins/mythplugins
 move media-plugins/mythweather media-plugins/mythplugins

 Nope.


Dang. Didn't think so but I figured I'd ask. Thanks for the quick reply.

-- 
Doug Goldstein



[gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer

2012-07-14 Thread Doug Goldstein
sys-auth/nss-ldapd is looking for a maintainer. This is the
preferred NSS LDAP by RHEL6. I just haven't been using it and
haven't been keeping up with releases. I'm only aware of two bugs:

https://bugs.gentoo.org/show_bug.cgi?id=287727
https://bugs.gentoo.org/show_bug.cgi?id=234555

One is asking for a bump and one is asking for some USE flag fixes.

-- 
Doug Goldstein



Re: [gentoo-dev] sys-auth/nss-ldapd is looking for a maintainer

2012-07-14 Thread Doug Goldstein
On Sat, Jul 14, 2012 at 6:25 PM, Matthew Thode
prometheanf...@gentoo.org wrote:
 On 07/14/2012 02:49 PM, Doug Goldstein wrote:
 sys-auth/nss-ldapd is looking for a maintainer. This is the
 preferred NSS LDAP by RHEL6. I just haven't been using it and
 haven't been keeping up with releases. I'm only aware of two bugs:

 https://bugs.gentoo.org/show_bug.cgi?id=287727
 https://bugs.gentoo.org/show_bug.cgi?id=234555

 One is asking for a bump and one is asking for some USE flag fixes.

 I'll take it, starting with the bump and hopefully getting upstream to
 accept a --enabled/disable for kerberos.


Thanks a bunch Matt.

-- 
Doug Goldstein



Re: [gentoo-dev] grub:2 keywords

2012-07-04 Thread Doug Goldstein
On Tue, Jul 3, 2012 at 9:20 AM, Jeroen Roovers j...@gentoo.org wrote:
 On Mon, 2 Jul 2012 15:02:28 -0400
 Mike Gilbert flop...@gentoo.org wrote:

 That is exactly what Doug (cardoe) proposed, and he is working on the
 docs for that.


 Ah yes, it's been a long-winded thread. :)


  jer


I got a little busier this past weekend than I had intended (loving
that leap second bug) but here's the first draft:

http://dev.gentoo.org/~cardoe/docs/grub2-migration.xml

It will be integrated into the official Gentoo doc set once I get a
nod from the docs guys.

-- 
Doug Goldstein



Re: [gentoo-dev] grub:2 keywords

2012-06-25 Thread Doug Goldstein
On Sun, Jun 24, 2012 at 11:15 PM, Mike Gilbert flop...@gentoo.org wrote:
 An official release of grub-2.00 should be coming pretty soon. I would
 like to keyword this for ~amd64 and ~x86 shortly after it hits the tree.
 I don't do much work on base system packages, so I would like some
 advice on how to make this as smooth as possible.

 My main concern is that many people probably have sys-boot/grub in
 @world. If grub:2 is made visible, portage will install it, and will
 remove grub-0.97 on the next depclean. This could be a little confusing,
 but should not cause any immediate damage since the copy of grub-0.97
 installed in the MBR and /boot would remain intact.

 Is this worthy of a news item? Or I just blog about it?

 Anything else I need to think about here?

 Note: The Gentoo Documentation Project has indicated that they do not
 want to add anything to the handbook until we are somewhat close to
 stabilizing grub:2. That's at least a couple months away.


Mike,

Since Grub Legacy and Grub 2 are slotted, Portage won't remove the
older version. Even if it removes the older one, everything necessary
is installed into /boot and the MBR already.

The best route forward would be to instruct people to use
grub2-install (but whatever the flag is to prevent MBR installation).
Have people generate their grub.cfg with grub2-mkconfig and then put a
chain loader into the Grub Legacy configs so that they can test Grub 2
and then once they test it tell them to install Grub 2 into the MBR
and remove Grub Legacy.

I'll gladly work with you on this. IMHO, it might be a good plan to
unmask and ~arch one of the release candidates with an aim to get Grub
2.0.0 fully released with docs.

-- 
Doug Goldstein



Re: [gentoo-dev] gtk3 useflag and support of older toolkits

2012-06-23 Thread Doug Goldstein
On Sat, Jun 23, 2012 at 1:31 PM, hasufell hasuf...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/11/2012 07:08 PM, Ciaran McCreesh wrote:
 No, your goal is to provide a distribution. Gentoo has repeatedly
 shot itself in the foot, leg, groin etc by favouring short-term
 hacks over a well thought out, validated, self-enforcing design.
 Right now nearly all of the package manager work is on paying off
 previously incurred technical debt, and in the mean time you're
 busy adding to it.


 Please take your exherbo trolling somewhere else.

 Our goal is not to provide a distribution, because gentoo sees itself
 as a metadistribution.

 Please familiarize yourself with:
 http://www.gentoo.org/main/en/about.xml

Let's keep the discussions on this mailing list technical and not personal.

Thanks.
-- 
Doug Goldstein



Re: [gentoo-dev] gtk3 useflag and support of older toolkits

2012-06-23 Thread Doug Goldstein
On Sat, Jun 23, 2012 at 1:26 PM, Michał Górny mgo...@gentoo.org wrote:
 On Sat, 23 Jun 2012 14:40:50 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Sat, 23 Jun 2012 15:33:47 +0200
 Gilles Dartiguelongue e...@gentoo.org wrote:
  Well the problem is simple, we need to ship webkit with gtk2 and
  gtk3 support. This is needed because gentoo has gtk2 based
  desktop/apps and because we want to ship gnome3 for example.
 
  Cool thing is that webkit supports being built with each toolkit
  without conflicting with the build from the other toolkit hence we
  ended up using SLOTS.

 You could just have gtk2 and gtk3 use flags in the ebuild, use
 REQUIRED_USE to ensure that at least one is enabled, and build things
 twice in the ebuild if necessary.

 Ah, so because a few paludis users may be building an additional
 variant of webkit-gtk unnecessarily, we should force all Gentoo users
 to randomly rebuild 1-2 variants depending on how soon they're going to
 get the USE correctly.


Let's all agree that the current solution is less than ideal and could
use improvement. I have several Gentoo  Portage only desktops and I
find myself annoyed with webkit-gtk and its revisions and rebuilds.

-- 
Doug Goldstein



Re: [gentoo-dev] gtk3 useflag and support of older toolkits

2012-06-23 Thread Doug Goldstein
On Sat, Jun 23, 2012 at 9:45 AM, Gilles Dartiguelongue e...@gentoo.org wrote:
 Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit :

 I'd like to know why using USE flags until a nicer solution is
 available
 is sufficiently terrible that it warrants a hackaround.

 remember qt3/qt4, gtk/gtk2. We want to avoid repeating these mistakes
 hence the guidelines already exposed back when we introduced gtk3 to the
 tree.

 As you may have noticed, this is still the solution applied for things
 hard to split or slot like gtk-vnc or avahi but we didn't see the need
 to have such USE flags when the library was so easily slottable.


It's funny you bring up qt3/qt4 and gtk/gtk2 since I'm only of the few
developers that worked on resolving both of those as they came and
went. Right now the resources we've got available to us from a Package
Manager stand point. Being a Gentoo dev for so long has allowed me to
see how our distro has evolved so let me give you a short walk down
memory lane, when gtk/gtk2  qt3/qt4 occurred we had the following:
- Portage 1.x (gtk/gtk2) / Portage 2.0.x (qt3/qt4)
- No EAPI
- No way to add features quickly to the Package Manager and the spec for it.

During gtk/gtk2, the rule was you had to wait until a feature was
available in the STABLE version of Portage, 4 releases back before you
could use a new feature. For everyone's knowledge, we did 4 releases a
year then. We knew our solution to gtk/gtk2 sucked and we hated it but
there was absolutely nothing we could do about it. It was a bitter
battle of band aids and hacks that we couldn't wait to get rid of. We
even attempted to throw gtk1 out of the tree entirely (ah the XMMS
flamewar) to get rid of the hacks. You couldn't even modify eclasses
since they weren't stored with the install, which lead to the -rX
revisioning of eclasses. On top of all this, Portage 1.x SUCKED to
modify or hack at. The only solution with that codebase was to nuke it
from orbit, which we finally did with Portage 2.0.x.

During qt3/qt4, the rule was you had to wait until the feature you
were trying to use was in a STABLE Portage for 6 months. We didn't
have a lot of options available but we worked with the current Portage
maintainer at the time to get some of the resolver improved and fixed
and get those updates pushed out to the tree as quickly as possible.
Once the updates were available the hacks went away and life was
better.

Now fast forward to 2011/2012, we were obviously aware that the
gtk2/gtk3 change would cause some problems. Heck people encountered it
when they tried to add ebuilds to the tree. The right path forward was
to speak to Zac, Brian and the rest of the PMS guys and see what the
best solution was. If it was implementing some new features then we
could have done that and gotten and EAPI approved quickly and had it
available before we even saw the first gtk3 ebuild unmasked. But alas,
that wasn't the case and here we are today. So here's what I suggest,
let's stop bickering and revisit the hacks you did to make things
work. Speak to Zac, Brian and the rest of the PMS guys and get what
you need implemented as a feature and get that feature into the very
next EAPI bump. Fix the tree to use that EAPI and get rid of the
hacks. You'll thank yourselves in the long run since things will be
easier to maintain and you can focus on what you enjoy doing.

-- 
Doug Goldstein



Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev

2012-06-21 Thread Doug Goldstein
On Thu, Jun 21, 2012 at 9:12 PM, Sylvain Alain d2racing...@gmail.com wrote:
 Amen to that too, but can you post the actual comments that he said ?



 2012/6/21 Homer Parker hpar...@gentoo.org

 On Thu, 2012-06-21 at 23:01 +0200, Michał Górny wrote:
  Just a short note as it seems some confusion arises lately:
 
  Ciaran McCreesh is not a Gentoo dev and his words don't represent
  the position of Gentoo development team.
 


        Amen.

 --
 Homer Parker hpar...@gentoo.org




 --
 Salut
 alp
 Sylvain


Guys,

Let's act like adults here. Just because someone disagrees with you
doesn't mean they have something personally against you so there's no
reason to take it to that level. This thread should end right now in
the interest of civil discussion.

-- 
Doug Goldstein



Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

2012-06-21 Thread Doug Goldstein
On Thu, Jun 21, 2012 at 2:42 AM, Michał Górny mgo...@gentoo.org wrote:
 On Thu, 21 Jun 2012 08:30:24 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Thu, 21 Jun 2012 09:29:49 +0200
 Michał Górny mgo...@gentoo.org wrote:
  On Wed, 20 Jun 2012 18:24:33 +0100
  Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
   On Wed, 20 Jun 2012 19:11:33 +0200
   hasufell hasuf...@gentoo.org wrote:
On 06/20/2012 07:07 PM, Michał Górny wrote:
 Please read the rationale. Again. The whole thing. Three
 times.
   
Please read my suggestions. Again. The whole thing. Three times.
  
   Can we all agree to just stop this and just restrict the arguing
   to being between SDEPEND and DEPENDENCIES? Cheers.
 
  You just volunteered to write portage patches. Cheers.

 Both were already implemented in Paludis, if you're looking for a
 reference implementation to try it out. There are also examples of
 use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
 can give you a small patch to turn SDEPEND on for an EAPI if you like
 (it's just a one line addition to the EAPI definition file).

 Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
 in Paludis' doesn't work here. We're discussing Gentoo features,
 and official package manager in Gentoo is portage. If you don't believe
 me, check out the docs.

 --
 Best regards,
 Michał Górny

I would recommend the two of you step away from this thread and
discussion for a day or two and come back to it with a fresh look at
the suggestions and the code that's available and then we can move on
getting this into an EAPI from there.

-- 
Doug Goldstein



Re: [gentoo-dev] ebuild laziness and binpkg overhead

2012-06-19 Thread Doug Goldstein
On Tue, Jun 19, 2012 at 10:27 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 06/20/2012 06:19 AM, Mike Frysinger wrote:

 On Tuesday 19 June 2012 22:46:26 Samuli Suominen wrote:

 On 06/15/2012 06:10 PM, Mike Frysinger wrote:

 On Friday 15 June 2012 03:44:14 Samuli Suominen wrote:

 On 06/13/2012 06:02 AM, Mike Frysinger wrote:

 i've noticed a growing trend where people put setup of variables into
 pkg_setup that only matter to src_* funcs presumably so they don't
 have
 to call the respective src_* func from an inherited eclass.
 unfortunately this adds pointless overhead to binpkgs.  can we please
 move away from this practice ?


 Every Xfce ebuild in gentoo-x86 is using pkg_setup() for 3 variables,
 DOCS for src_install, PATCHES for src_prepare


 these are static variables, so defining them in a func is pointless


 sort of not necessarily, 'has $useflag  PATCHES+=( )' has been used
 before, not sure if it's used in tree right now or not


 as we've always said, USE conditional patches are to be highly discouraged


 I agree BUT there are cases where it's OK to use conditional patching:

 For example, libfoo-0.1.1 is broken and is fixed in git for master which
 will be in next release. The fix doesn't apply to 0.1.1 cleanly without
 heavy modifications.
 Then you would take the easiest possible route to get 0.1.1 working again,
 with the comfort of knowing it's properly fixed for the next version.

 -Samuli


I assume you mean libfoo-0.1.1 is broken when USE=bar is enabled and
you get a patch for that conditional case when USE=bar is enabled.

Either way, the better solution is to mask it and have people use libfoo-0.1.0

-- 
Doug Goldstein



[gentoo-dev] epatch_user usage

2012-04-23 Thread Doug Goldstein
So I've just had one reservation when using epatch_user for allowing
users to apply patches. And that's figuring out when to run
eautoreconf. I don't necessarily want to run it unconditionally but
sometimes users have patches which touch autoconf files but my
existing patch set doesn't so I'm not calling eautoreconf. Does anyone
have a suggested way to handle this?

Thanks.
-- 
Doug Goldstein



Re: [gentoo-dev] epatch_user usage

2012-04-23 Thread Doug Goldstein
On Mon, Apr 23, 2012 at 11:10 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Monday 23 April 2012 23:45:36 Doug Goldstein wrote:
 So I've just had one reservation when using epatch_user for allowing
 users to apply patches. And that's figuring out when to run
 eautoreconf. I don't necessarily want to run it unconditionally but
 sometimes users have patches which touch autoconf files but my
 existing patch set doesn't so I'm not calling eautoreconf. Does anyone
 have a suggested way to handle this?

 just always call it when the user applies patches.  i don't see a big deal.
        epatch_user  eautoreconf
 -mike

That works. I was wondering if you guys did anything more crafty but
this is fine.

Thanks all for the input.

-- 
Doug Goldstein



[gentoo-dev] Unstabling a package

2012-02-19 Thread Doug Goldstein
Any specific procedure to unstable a package? Specifically MythTV.
While there's a lot of user interest in the package, there's just not
enough dev help with the package to really keep it up to snuff to what
could be considered stable. Its woefully behind and I'd just be
happier to drop the current stable and bump everything as unstable.

-- 
Doug Goldstein



[gentoo-dev] How to handle x86/amd64 only packages on other arches

2012-01-25 Thread Doug Goldstein
I need to be able to have ppc/arm/etc users install a package that can
only be built on x86/amd64. The packages in question are
sys-apps/seabios and sys-apps/vgabios. The point is that a PPC machine
that's using qemu-system-x86_64 still needs to use seabios and
vgabios. I was planning on building the package on my own hardware and
posting up sys-apps/seabios-bin and sys-apps/vgabios-bin unless of
course someone has a better suggestion.

I know the list tends to devolve into the theory of foo/bar and
foo/baz but I'd like to keep this concrete to those two packages.

-- 
Doug Goldstein



Re: [gentoo-dev] enew{user,group}: killing off [extra] argument

2011-11-09 Thread Doug Goldstein
On Sun, Nov 6, 2011 at 4:54 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Sunday 06 November 2011 13:33:48 Petteri Räty wrote:
 On 03.11.2011 17:30, Mike Frysinger wrote:
  http://sources.gentoo.org/eclass/user.eclass?r1=1.8r2=1.9

 Less than a day is quite a short time for people to comment. Also it
 would be better to include the diff in the original email.

 4 days later and still no one cares
 -mike


I care Mike... I care... that the code is now cleaner and more
maintainable. Thank you for doing this improvement.

-- 
Doug Goldstein



Re: [gentoo-dev] nvidia-settings needs a maintainer (or something)

2011-05-09 Thread Doug Goldstein
On Mon, May 9, 2011 at 12:47 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 should have announced this before, but nvidia-settings needs an active
 maintainer or it should be merged back to the nvidia-drivers

 the bugs idle on maintainer-needed@ now, you can find them easily by
 search keyword of nvidia-settings

 Jer has been doing some work on the matter, so might want to discuss
 with him before just taking over

 - Samuli



I'll take it over as I've wanted to do to keep the two packages in sync.

-- 
Doug Goldstein



[gentoo-dev] Re: Last rites: x11-drivers/nvidia-drivers-71.86.x

2010-08-29 Thread Doug Goldstein
On Tue, Jul 13, 2010 at 12:16 AM, Doug Goldstein car...@gentoo.org wrote:
 Last rites: x11-drivers/nvidia-drivers-71.86.x

 The Video ABI in these drivers is no longer supported by any version
 of x11-base/xorg-server that Gentoo has in the tree. Gentoo has not
 had a version that supported this video ABI in the tree for some time
 now. As a result, this version will leave the tree in approximately 30
 days.

 --
 Doug Goldstein


Its the end of August folks, these versions have been removed.


-- 
Doug Goldstein



Re: [gentoo-dev] Re: Last rites: eclass/php5_1.eclass

2010-07-18 Thread Doug Goldstein
On Sat, Jul 17, 2010 at 6:28 PM, Ryan Hill dirtye...@gentoo.org wrote:
 On Sat, 17 Jul 2010 22:23:03 +0200
 Matti Bickel m...@gentoo.org wrote:

 On 07/17/2010 09:58 PM, Matti Bickel wrote:
  since there's no dev-lang/php-5.1* version in the tree anymore, this
  eclass is useless. It will be removed on 17th August 2010.

 I've just been told by scarabeus that eclass removal is a two years
 minimum process. So it'll be removed 17th August 2012 and marked #...@dead
 (deprived of functionality) in the next days.

 /me shakes his fist once again at the inanity of this policy.



Just remove it! If the council can not be bothered to help developers
develop but instead hinder developers from developing, then they are
no longer relevant and should be treated as such. Other course of
action could always be that they should all be kicked out and replaced
with a suitable organization to ensure Gentoo's technical and
developmental success.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

2010-07-12 Thread Doug Goldstein
On Mon, Jul 12, 2010 at 3:54 AM, Petteri Räty betelge...@gentoo.org wrote:
 On 07/12/2010 12:56 AM, Doug Goldstein wrote:

 I remember very clearly as you and I were both council members at the
 time. My point is that this discussion does not need to even happen
 and the council shouldn't even remotely be involved here.


 I assumed the best way to change policy would be to ask council to rule
 on it. Of course we could just see if we can get a consensus fast
 without council.

There is no change of policy and there is no reason for the council to
be involved. He can change the eclass how he needs and that's the end
of the story. The council does not need to be involved at every
potential crossroad. The council only needs to be involved when a
potential technical issue arises. No technical issue, proceed ahead.
No need for the council to road block.

e.g. if its not in the rule book you can do it.

This is vastly different then your interpretation of the council's
mandiate, Petteri, which is if its not in the rule book go ask
permission.

Hence my point of saying let developers develop instead of telling
them they need to ask permission and wait 4 weeks while it gets on an
agenda list everytime they want to commit to the tree or blow their
nose or boot up their computer.

-- 
Doug Goldstein



[gentoo-dev] Last rites: x11-drivers/nvidia-drivers-71.86.x

2010-07-12 Thread Doug Goldstein
Last rites: x11-drivers/nvidia-drivers-71.86.x

The Video ABI in these drivers is no longer supported by any version
of x11-base/xorg-server that Gentoo has in the tree. Gentoo has not
had a version that supported this video ABI in the tree for some time
now. As a result, this version will leave the tree in approximately 30
days.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

2010-07-11 Thread Doug Goldstein
On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty betelge...@gentoo.org wrote:
 On 07/11/2010 08:02 AM, Doug Goldstein wrote:

 If I really need to go to the council with every change, considering
 it must be debated on the ML for at least X number of days prior to
 going to the council, I'd more likely just remove MythTV from the tree
 and maintain it in an overlay. I don't invest a lot of time in the
 MythTV ebuilds, but they work for a large majority of people. And when
 a new version comes out it requires some retooling and it just works
 for everyone.


 When someone proposes this I'll let you know. What's under discussion is
 allowing removals to the public API of eclasses by following a
 documented process (that doesn't involve council approval).

 So basically, you guys decide.. am I pulling them out of the tree or
 am I leaving them in?


 If you decided to drop maintenance of MythTV in main tree, wouldn't it
 be a better service to users to try and find a new maintainer (who would
 possibly merge stuff from your overlay)?

 Regards,
 Petteri



Simply put, the council's purpose is not to say oh we have to stop
development and have a 4 week debate about everything minor. The
council's purpose is to help decide between different technical
solutions and encourage people to move forward on one unified path.
The council's purpose is not to HINDER development as your responses
clearly suggest you would like to hinder eclass development but
instead to promote positive development.

Someone along the years the council lost its way and has felt that it
needs to stick its fingers into places that it really doesn't belong.
Its really become like the upper management at a large company that
slows its developers down, instead of helping make them more
efficient.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

2010-07-11 Thread Doug Goldstein
On Sun, Jul 11, 2010 at 11:37 AM, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Doug.

 On 11-07-2010 16:03, Doug Goldstein wrote:
 On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty betelge...@gentoo.org wrote:
 On 07/11/2010 08:02 AM, Doug Goldstein wrote:

 If I really need to go to the council with every change, considering
 it must be debated on the ML for at least X number of days prior to
 going to the council, I'd more likely just remove MythTV from the tree
 and maintain it in an overlay. I don't invest a lot of time in the
 MythTV ebuilds, but they work for a large majority of people. And when
 a new version comes out it requires some retooling and it just works
 for everyone.


 When someone proposes this I'll let you know. What's under discussion is
 allowing removals to the public API of eclasses by following a
 documented process (that doesn't involve council approval).

 So basically, you guys decide.. am I pulling them out of the tree or
 am I leaving them in?


 If you decided to drop maintenance of MythTV in main tree, wouldn't it
 be a better service to users to try and find a new maintainer (who would
 possibly merge stuff from your overlay)?

 Regards,
 Petteri



 Simply put, the council's purpose is not to say oh we have to stop
 development and have a 4 week debate about everything minor. The
 council's purpose is to help decide between different technical
 solutions and encourage people to move forward on one unified path.
 The council's purpose is not to HINDER development as your responses
 clearly suggest you would like to hinder eclass development but
 instead to promote positive development.

 There seems to be some misunderstanding going on as we (Gentoo) haven't
 approved (in prior councils terms or in the current one which hopes to
 have its first meeting in the coming week or the following) any rules
 about eclass changes having to be discussed or approved by the council.

 Someone along the years the council lost its way and has felt that it
 needs to stick its fingers into places that it really doesn't belong.
 Its really become like the upper management at a large company that
 slows its developers down, instead of helping make them more
 efficient.

 About the issue in discussion, Petteri was recalling that contrary to
 what anyone new to Gentoo might conclude from the current discussion,
 the issue of eclass deprecation has been subject to at least 2 separate
 discussions in the past 2 or 3 years and that in the last round there
 was a proposal for setting minimal deprecation time frames.

 - --
 Regards,

 Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
 Gentoo- forums / Userrel / Devrel / KDE / Elections

Jorge,

I remember very clearly as you and I were both council members at the
time. My point is that this discussion does not need to even happen
and the council shouldn't even remotely be involved here.

Let developers develop.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

2010-07-10 Thread Doug Goldstein
On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill dirtye...@gentoo.org wrote:
 On Sat, 10 Jul 2010 01:34:37 -0700
 Brian Harring ferri...@gmail.com wrote:

 On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
  The standing policy is still not to remove any public functionality from
  eclasses. If we decide to start removing functionality the council
  should set common rules for it.

 Just adding a note on this one- the original technical reason for
 this policy (portage inability to run from just the saved env dump)
 is no longer an issue.

 If people want to allow eclasses to have fluid APIs (specifically
 removal of functionality), that's a discussion that needs to start on
 the dev level.

 Anyone got strong opinions on this one?

 I don't believe there ever was such a policy, except for pkg_{pre,post}rm
 because of the mentioned technical limitations (which were fixed in portage
 2-3 years ago now).  If there is such a policy then I've violated it on
 several occasions :).  In fact, isn't the generally accepted method of
 deprecating an eclass to remove all functionality and replace it with a
 message in global scope and a # @DEAD tag?

 I don't see the advantage of keeping unmaintained broken code no one should
 use around in eclasses.  You can argue that removing eclass functionality can
 potentially break ebuilds in overlays, but if you follow that line of
 reasoning then really we should never remove any package from the tree
 because it may be a dependency of something, somewhere.

 So I'd like to see a policy that treats public functions in eclasses the same
 as the last rites policies for package removal:  minimum 30 day deprecation
 period, mail to dev-announce, etc.


 --
 fonts, gcc-porting,                                   and it's all by design
 toolchain, wxwidgets                        to keep us from losing our minds
 @ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


To be honest, the MythTV eclasses have been an ever evolving set of
eclasses for ages now. Ever since it was declared that its now safe to
remove eclasses from the tree since Portage saves eclasses and its
env, therefore it wouldn't cause a problem.

If I really need to go to the council with every change, considering
it must be debated on the ML for at least X number of days prior to
going to the council, I'd more likely just remove MythTV from the tree
and maintain it in an overlay. I don't invest a lot of time in the
MythTV ebuilds, but they work for a large majority of people. And when
a new version comes out it requires some retooling and it just works
for everyone.

So basically, you guys decide.. am I pulling them out of the tree or
am I leaving them in?

-- 
Doug Goldstein



Re: [gentoo-dev] RFC: removal of virtual/php from depend.php

2010-07-09 Thread Doug Goldstein
On Fri, Jul 9, 2010 at 5:09 PM, Matti Bickel m...@gentoo.org wrote:
 So we're replacing virtual/php with dev-lang/php in depend.php.
 Question is: do we need depend.php-r1 for this? Did I miss some
 important point about the change?


Matt,

No you don't. You should be free to make the change.

-- 
Doug Goldstein



Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo

2010-07-06 Thread Doug Goldstein
On Mon, Jul 5, 2010 at 11:13 AM, Enrico Weigelt weig...@metux.de wrote:
 * Nirbheek Chauhan nirbh...@gentoo.org schrieb:

 What you are saying makes sense for desktop users since they will
 likely already have consolekit/policykit/nm-applet installed, and
 hence using NetworkManager for all network management makes sense.

 Actually, I've got several Gentoo-based desktop systems, none of
 them uses any these packages.

 From what I can see, we have three options:
 (a) Make our existing openrc network code + openrc configuration files
 work with systemd, and move to systemd by default
 (b) Make systemd work with openrc+NM configuration files[1], make NM
 work w/o PK/CK[2], add command line tools to NM, and move to systemd
 by default.
 (c) Support systemd as an alternative init system for use by desktop users.

  (d) Fix systemd to get rid of dependencies to dbus, etc.



(e) Get our network scripts compatible with netcf [1], which is the
way of the future for letting applications modify the network
configuration of the system.

[1] https://fedorahosted.org/netcf/


-- 
Doug Goldstein



Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior

2010-03-28 Thread Doug Goldstein
On Sat, Mar 27, 2010 at 9:54 AM, Petteri Räty betelge...@gentoo.org wrote:
 See this thread for background:
 http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ced.xml

 I think we should go through all the ssl use flag using packages and
 unify the use flag descriptions and behavior to the following standing
 policy (handed down probably):

 1) packages always have the general ssl use flag to control whether to
   enable ssl at all
 2) If the package supports multiple backends then there's use flags for
   gnutls, openssl or nss. EAPI 2 use defaults will be used to
   communicate upstream defaults if any. If they are all turned of
   select the default (ssl being on).

 No objections and I will open a tracker a week from now and let's see
 who joins up to go through packages and open bugs.

 Regards,
 Petteri



I seriously hate changing USE flags for the sake of changing use
flags. This provides a moderate amount of annoyance for anyone that
maintains more then one Gentoo box because they need to then tinker
with their /etc/make.conf and /etc/portage/package.use to get
everything right again. And oh no what if the one box is on ~arch and
one isn't and what if one is x86 and one isn't. Its just such a
configuration nightmare.

So unless there's any real benefit, I'm against this.

Also two little side points... USE defaults happened in EAPI 1. And
the method by which you're asking people to select would be nice if we
had some method for saying USE X and Y are subset of USE A.

-- 
Doug Goldstein



Re: [gentoo-dev] when to use a function and an implementation use flag.

2010-03-28 Thread Doug Goldstein
On Sat, Mar 27, 2010 at 9:44 AM, Petteri Räty betelge...@gentoo.org wrote:
 On 03/24/2010 08:30 PM, Peter Hjalmarsson wrote:

 For qemu-kvm the problem is that there is only one implementation (i.e.
 gnutls), and if I want to have ssl support I have to enable gnutls for
 this package.

 In this case the ebuild should have only ssl use flag.

 When I wrote a bug about this I got a rather short reply from maintainer
 about pointing me to the policy about this.

 Where did he point you to?

I didn't point him anywhere. I merely asked him for a policy on this.
Because senseless changes in USE flags will require my 9 VM servers
will need to be tweaked around for a pointless USE flag change and I
don't need administrative burden for the sake of administrative
burden.


 So I have a question:
 Is there no policy about this?

 The policy is that USE=ssl controls whether to enable ssl support in
 general. Then the specific use flags like gnutls and openssl control
 what implementation to use if the package supports multiple.

Again, this policy is stated but no one can point me to anything. The
closest thing to a policy is you sending a follow up e-mail to the
dev list to make this a policy.

-- 
Doug Goldstein



[gentoo-dev] Re: Pending mask of Qt3 and MythTV

2010-02-23 Thread Doug Goldstein
On Sun, Feb 21, 2010 at 11:25 PM, Ben de Groot yng...@gentoo.org wrote:
 Hi,

 As the Gentoo Qt team has announced six months ago, Qt3 is about to be
 masked now (see bug 283429). We sent another mail with a timeline at
 the end of December. Most of the issues surrounding the mask and
 removal of Qt3 have been solved. But we see ourselves confronted with
 one remaining issue: MythTV. Its current stable version uses Qt3, but
 there is a Qt4 version in testing. In all this time the MythTV
 maintainers have not taken any action.

Incorrect. You came to me a few months ago and I told you I would not
and will not have time to mess with the package at all. I think I've
made that clear in past mailing list posts, discussions we've had, and
on bugzilla. Many people have spoken up about the situation and time
and time again I've said please, take over the package. It needs to
be stabilized and a new unstable bump needs to happen. You took one
of those times to create a ticket saying you'd stabilize it, then
deferred to me and the arch teams. My response was the arch teams
haven't stabilized MythTV in years because none of them have a setup
to test it, so please stabilize it. I'm running it on a stable
machine.

I do not have my Gentoo commit machine up and running right now. I've
only got my MythTV machines running x86 and amd64 with MythTV running
~arch for a while now. So I ask you once again, PLEASE just mark it
stable. SOMEONE. And quit accusing anyone of inaction.

As far as the news item goes, as I've said before. Its completely
unnecessary since MythTV will handle notifying you properly if you
need to do anything to your database. I can count more than a dozen
people on Gentoo that have successfully done the conversion without
issue. The problem stems from people either not reading the
instructions when MythTV tells them they need to take action and read
the update guide. Or people stupidly reading the upgrade guide,
thinking oh I'll upgrade my DB early and upgrading their DB and then
running their old version. A news item will probably do more harm than
good and will result in a lot of partial corruptions, which we already
have one person on the bug you guys made for the news item already
doing.

-- 
Doug Goldstein



Re: [gentoo-dev] Last rites: media-tv/linuxtv-dvb-firmware

2010-02-08 Thread Doug Goldstein
On Mon, Feb 8, 2010 at 1:15 PM, Daniel Pielmeier bil...@gentoo.org wrote:
 # Daniel Pielmeier bil...@gentoo.org (08 Feb 2010)
 # Masked for removal on 10 Mar 2010.
 # Manifest failures due to upstream source changes without version bump.
 # SRC_URI changes all the time. Firmware extraction fails. Overly complex
 # ebuild for just installing one or two files.
 # Will be replaced by updating the vdr-guide with information on how to obtain
 # and install the firmware.
 media-tv/linuxtv-dvb-firmware

 --
 Daniel Pielmeier




Ignore this. Its not being removed.

-- 
Doug Goldstein



Re: [gentoo-dev] Upstream tags in metadata.xml (GLEP 46)

2010-02-05 Thread Doug Goldstein
On Thu, Feb 4, 2010 at 7:05 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Thursday 04 February 2010 16:37:01 Tiziano Müller wrote:
 While some people already discovered the upstream metadata tags, there
 are only 8 ebuilds using them so far. Mostly I am to blame for that,
 since I forgot to send out a proper announcement. While all the required
 information can be found in the Developer Handbook [1], here is a short
 summary:

 anyone who feels like doing this kind of work should feel free to add any
 upstream tags to base-system/toolchain/games packages ... no need for
 bugzilla and such.
 -mike


Ditto on base-system/mythtv/app-emulation

-- 
Doug Goldstein



[gentoo-dev] x11-libs/cairo USE defaults change

2010-02-05 Thread Doug Goldstein
I figured I'd let everyone know that this weekend sometime I plan on
changing the cairo ebuilds to have IUSE=+svg. It seems like a lot of
default installs of various things out of the box actually rely on
cairo to have SVG support and users are presented with an ugly error
message out of the box all the time.

Any objections, speak up now.

-- 
Doug Goldstein



Re: [gentoo-dev] GLEP59 - Manifest2 hashes

2010-02-01 Thread Doug Goldstein
On Sun, Jan 31, 2010 at 3:57 AM, Robin H. Johnson robb...@gentoo.org wrote:
snip

 The SHA512 algorithm is available in Python 2.5, which has been a
 dependency of Portage since approximately Python 2.1.6.13.
snip

I hate to nitpick, but I believe you meant Portage in that line.

However, great work on this GLEP, you've put forth some good solid
research into it.

I do hope that we don't intend on settling on SHA512 as the end all
solution as well. We should retain a method for bumping the hashing
algorithm used when the SHA-3 family becomes available.

-- 
Doug Goldstein



Re: [gentoo-dev] g15 and freevo up for grabs

2010-01-18 Thread Doug Goldstein
On Mon, Jan 18, 2010 at 10:56 AM, Robert Buchholz r...@gentoo.org wrote:
 Hello,

 I want to drop maintenance for some of the packages that I have acquired
 over the years. Some of them are still co-maintained, some are now
 unmaintained.

 === Freevo ===

 Freevo is split up in different Python components. They are all
 maintained by a herd, but a dedicated maintainer is needed.

 media-tv/freevo            # media-tv herd


Should be worth noting that no one from media-tv herd actually uses
freevo or has an interest in it. You've got 2 MythTV guys and 2 vdr
guys in the herd and that's it. Unless someone steps up this package
should be marked maintainer-needed.

-- 
Doug Goldstein



Re: [gentoo-dev] net-fs/netatalk is facing removal

2010-01-12 Thread Doug Goldstein
On Fri, Jan 8, 2010 at 2:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 since noone seems to care about this package, and it's blocking glibc
 stabilization it will be removed from tree wrt bug 300218

 last chance

 thanks, Samuli



Its been saved.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: use.local.desc

2010-01-02 Thread Doug Goldstein
On Thu, Dec 31, 2009 at 4:13 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 01/01/2010 12:07 AM, Robin H. Johnson (robbat2) wrote:
 +app-accessibility/flite:alsa - use alsa for audio output.
 +app-accessibility/flite:oss - Use Open Sound System for audio output.

 Why? USE alsa and oss are global flags.



Real question is why not? local USE flags provide more details than
the very generic global description and as such are considered a good
thing. That is one of the purposes I had in mind originally when I
wrote GLEP 56 [1].

[1] http://www.gentoo.org/proj/en/glep/glep-0056.html
-- 
Doug Goldstein



Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread Doug Goldstein
On Mon, Dec 28, 2009 at 3:10 AM,  lx...@gentoo.org wrote:
 In the aim of improving binpkgs status, I filed a bunch of bugs against all
 the libX* available in tree that contain wrong RDEPEND bits pointing to
 x11-proto/* stuff.
 To x11, just don't get angry (eheh), let's discuss concerns here (actually I
 don't see any and I am willing to fix all the ebuilds and close all my bugs
 if you ack).

Why not provide some actual meat and potatoes here instead of a
useless e-mail with bug numbers and some stupid attempt at humor at
the expense of the x11 herd?



Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread Doug Goldstein
On Mon, Dec 28, 2009 at 1:15 PM, Jeroen Roovers j...@gentoo.org wrote:
 On Mon, 28 Dec 2009 10:10:48 +0100 (CET)
 lx...@gentoo.org wrote:

 let's discuss concerns here (actually I don't see any and I am
 willing to fix all the ebuilds and close all my bugs if you ack).

 If they are genuine bugs, then there isn't anything to discuss.

 List of Gentoo bugs:

 Tracker bug is #298759[1]


 Regards,
     jer


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




Then there was no need to waste everyone's time with a backhanded
comment about the X11 herd. And we can all get on with our lives.

-- 
Doug Goldstein



Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

2009-12-25 Thread Doug Goldstein
 the more
 technically competent ones than me, will get back to you on this and
 offer help and advice. As soon as I have a better internet connection
 I will contact you about this.

 Feel free to do so.

 P.S.: I dont want to affront you or anyone else personally, but the way, how 
 it currently goes. I
 know from IRC, forums and mails, that there are people around, who would like 
 to see
 multilib-features in portage. But with such frustrating none-actions like 
 this, noone should wonder
 why such things are not implemented, also there are people, who would like to 
 see it and even
 people, who would help doing it and creating code for it. That does not 
 actually speak for Gentoo,
 more against it (and it is not the only point, where Gentoo could improve, 
 but does not, but that
 could be part of another big mail).


 --
 Thomas Sachau

 Gentoo Linux Developer



People are honestly just waiting for this to hit the tree at this
point. Inaction by the council is a serious failure of the council.
The Portage team doesn't want to start integrating code that the
council will force them to remove in the future. Being a former
council member myself I can easily say, get off your ass and do
something.

-- 
Doug Goldstein



[gentoo-dev] app-emulation/kvm moves to app-emulation/qemu-kvm

2009-11-22 Thread Doug Goldstein
Hey all,

app-emulation/kvm has moved to app-emulation/qemu-kvm to align
ourselves better with the development goals of upstream.

If anyone wants to maintain this package (and app-emulation/kvm-kmod)
please feel free to step up and join because I honestly will not have
much time to maintain it.

-- 
Doug Goldstein



Re: [gentoo-dev] GLEP 27 Bump

2009-11-15 Thread Doug Goldstein
On Sun, Nov 15, 2009 at 7:35 PM, Robin H. Johnson robb...@gentoo.org wrote:
 On Sun, Nov 15, 2009 at 09:25:45AM +0200, Petteri Räty wrote:
 Doug Goldstein wrote:
  GLEP 27 [1] seems pretty stagnant and I'm planning on giving it a bit
  of a refresh and actually implementing it. Now before I do this I'm
  not in love with the format in tree but I haven't decided on a format
  exactly in my head. So that being said, I'm sending this out looking
  for some opinions or ideas for my new GLEP. One of the obvious things
  I'll cover is all the ambiguity of the GLEP with regard to the data
  inside each of the files.
 
  [1] http://www.gentoo.org/proj/en/glep/glep-0027.html
 One idea worth considering is making users just ebuilds with a
 supporting eclass.
 While I'm hugely in favour of having consistent UID/GIDs with no
 conflicts over all Gentoo machines, I feel one of the reasons that the
 GLEP failed was that users required by ebuilds changed over ebuild
 versions, and the GLEP didn't seem to handle that well.

 Cases I've seen in the tree:
 - username change (slocate - locate)
 - homedir change
 - shell change


Which would seem to mean that Petteri's suggestion would work better
since that would allow us to version/upgrade user/group data.



-- 
Doug Goldstein



[gentoo-dev] global USE flag description change: css

2009-11-14 Thread Doug Goldstein
The css USE flag currently says:

Enables ripping of encrypted DVDs

But that really doesn't describe the usage correctly. It enables the
ability to READ encrypted DVDs. I'm going to make the change if no one
objects.

-- 
Doug Goldstein



[gentoo-dev] GLEP 27 Bump

2009-11-14 Thread Doug Goldstein
GLEP 27 [1] seems pretty stagnant and I'm planning on giving it a bit
of a refresh and actually implementing it. Now before I do this I'm
not in love with the format in tree but I haven't decided on a format
exactly in my head. So that being said, I'm sending this out looking
for some opinions or ideas for my new GLEP. One of the obvious things
I'll cover is all the ambiguity of the GLEP with regard to the data
inside each of the files.

[1] http://www.gentoo.org/proj/en/glep/glep-0027.html

-- 
Doug Goldstein



[gentoo-dev] [maintainer-needed] app-emulation/kvm

2009-11-11 Thread Doug Goldstein
KVM needs a maintainer. Plain and simple. If you're interested please
step and and start wrangling some bugs.

-- 
Doug Goldstein



Re: [gentoo-dev] Unused ebuild built_with_use cleanup

2009-10-29 Thread Doug Goldstein
On Wed, Oct 28, 2009 at 4:51 AM, Petteri Räty betelge...@gentoo.org wrote:
 Mike Frysinger wrote:
 On Tuesday 27 October 2009 14:46:31 Petteri Räty wrote:
 Normally old versions are not kept around as already said if you read
 the thread.

 normal is not the same thing as always.  unless you're the maintainer, 
 you
 have no idea whether old versions are kept there on purpose.  ive had people
 delete older versions of packages on me simply because they made this invalid
 assumption without talking to the maintainer.  the rest of the thread is
 irrelevant as this point was not made.


 Yes I have no idea. That's why I asked on gentoo-dev-announce for
 maintainers to tell me if they are kept on purpose so the point was made
 already at the very start.

 Regards,
 Petteri



I see several of my packages on there as well and there's absolutely
no way you're culling them since they have a definite use since you're
script clearly failed to take into consideration various profiles and
SLOTs. Biggest reason that my packages still use built_with_use is the
lack of the --missing option for EAPI=2.

-- 
Doug Goldstein



Re: [gentoo-dev] Qt3 deprecation

2009-07-27 Thread Doug Goldstein
On Sun, Jul 26, 2009 at 3:25 PM, Ben de Grootyng...@gentoo.org wrote:
 Dear fellow devs,

 We would like to draw your attention to the fact that the Gentoo Qt team
 now officially discourages further usage of Qt3. Version 3 is no longer
 being developed or supported upstream. All users are strongly encouraged
 to use Qt version 4 where applicable.

 This means that we request that no new Qt3-based packages will be
 introduced to the portage tree. Also, where there is a choice, Qt4
 should be preferred over Qt3 by default.

 We will still do some minimal maintenance and support on the existing
 Qt3 libs and applications for about another 6 months. This will give
 application maintainers the time to upgrade or look for alternatives.
 After this period we will move the Qt3 libs and apps along with KDE3
 into an overlay where users of those legacy packages can maintain them.

 If you have a package for which both Qt3 and Qt4 versions exist, please
 have the Qt4-based version marked stable (if it isn't already) within
 the next few months and remove the legacy Qt3-based version, if possible.

 Thanks,

 Ben de Groot
 Gentoo Qt team lead



MythTV still uses Qt3 and there is NO way that the Qt4 based MythTV
could even remotely be considered stable. It is still undergoing
constantly changing and there are many codepaths that are incomplete.

-- 
Doug Goldstein



Re: [gentoo-dev] Gentoo Council Reminder for June 25

2009-06-24 Thread Doug Goldstein
On Mon, Jun 22, 2009 at 2:18 PM, Thomas Anderson gentoofa...@gentoo.orgwrote:

 (This is late because I was traveling and dev-zero is/was on devaway.)

 This is your friendly reminder! Same bat time (typically the 2nd  4th
 Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
 irc.freenode.net) !

 If you have something you'd wish for us to chat about, maybe even vote
 on, let us know! Simply reply to this e-mail for the whole Gentoo dev
 list to see.

 For more info on the Gentoo Council, feel free to browse our homepage:
 http://www.gentoo.org/proj/en/council/



ACK on the agenda items. Though I'm really curious to see what these
questions are going to be for the past year of council members. Since I
believe there's only 3 council members remaining from the original election
and 2 of those council members were members of the previous council as well.
The only take away we have is that being a council member burns you out.


-- 
Doug Goldstein


[gentoo-dev] 2009 Council Elections

2009-06-24 Thread Doug Goldstein
Hello everyone,

I wanted to take this time to encourage everyone who can vote in this
year's council elections. This is your chance to affect the technical
development for Gentoo for the coming year and I encourage you to take
it. Voting is easy, just login to your account on dev.gentoo.org and
perform the following steps:

Quick voting helper:
$ votify --new council200906 [1]
$ $(editor) .ballot-council200906 [2]
$ votify --verify council200906 [3]
$ votify --submit council200906 [4]

While I'm not running this year. I encourage people to consider
gentoofan23 (tanderson on IRC). He's done an outstanding job helping
the current council members and without him much of the council's
progress would have stalled.

-- 
Doug Goldstein



  1   2   3   4   >