Re: [gentoo-dev] GCC 4.6.* unmasked, 4.7.0 added to tree

2012-05-22 Thread Mark Loeser
Ryan Hill dirtye...@gentoo.org said:
 I've added 4.7.0 to the tree tonight (unkeyworded and masked as usual).
 
 I've also keyworded the 4.6 series on all arches except amd64 (due to the
 grub bug).  This is a temporary measure until we figure out the best course of
 action (at least we have some people looking at the problem now).

Awesome, thanks.

 I personally apologize for the extremely long delay in getting these releases
 out in a timely manner.  As such, I'm stepping down as GCC maintainer.
 Someone with as limited free time and programming experience as myself has
 no business maintaining a such core piece of a source-based distro.
 
 Sorry to dump even more on your shoulders Mike, but really I haven't been
 helping out much this past year anyways.  I'll still be doing gcc-porting and
 hunting down patches like I used to.

I've been looking for things to start working on again, and I could step
back up and start to do some of the work I used to do for GCC releases.
I'll talk with Mike to figure out how we can best split up the work.

Thanks for all your work on the releases,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] dev-python/pygobject slotting

2011-10-20 Thread Mark Loeser
Alexandre Rostovtsev tetrom...@gentoo.org said:
 dev-python/pygobject:3 has been added to gx86 (package.masked for
 now). It provides only gobject-introspection based bindings (from
 gi.repository import GLib). Per upstream decision, pygobject:2,
 starting with 2.28.6-r50, will install only classic bindings
 (import glib), since its old gi module heavily collides with
 pygobject:3. To make the transition a bit easier for users who are
 doing their own python development, the introspection USE flag on
 pygobject-2.28.6-r50 pulls in pygobject-3 for the new gi module (in
 lieu of installing pygobject-2's internal gi).

I'd recommend you open a tracker bug for this porting effort.  No one is
going to be able to follow exactly what has been done via the mailing
list :)

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Removing herdno-herd/herd?

2011-09-11 Thread Mark Loeser
Michał Górny mgo...@gentoo.org said:
 On Sat, 10 Sep 2011 17:54:06 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  On Sat, 10 Sep 2011 11:22:16 +0300
  Markos Chandras hwoar...@gentoo.org wrote:
  
   On 10/09/2011 11:15 πμ, Mike Gilbert wrote:
For example, in IRC, willikins tries to look up the members of 
no-herd when you do !meta -v because the bot lacks a special 
exception for this odd-ball value.
   Just because willikins behaves like that does not justify the
   removal of this tag. God knows how many utilites and scripts are
   out there using the no-herd tag from metadata.
  
  There's, of course, metadata.dtd too but repoman re-fetches it on
  a regular basis so that's no problem.
 
 Ah, my bad. Our metadata DTD doesn't enforce existence of any herd/
 tag. Neither does repoman. So, it's just that one webpage which says
 there must be one.

You might want to check out the discussion on
https://bugs.gentoo.org/show_bug.cgi?id=279206

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-process/acct/files: acct.initd-r1 acct.logrotate-r1

2011-05-31 Thread Mark Loeser
Markos Chandras hwoar...@gentoo.org said:
 On 31/05/2011 02:28 μμ, Jeroen Roovers wrote:
  On Tue, 31 May 2011 11:00:27 +0100
  Markos Chandras hwoar...@gentoo.org wrote:
  
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA512
 
  On 30/05/2011 12:39 μμ, Jeroen Roovers (jer) wrote:
  jer 11/05/30 11:39:21
 
Removed:  acct.initd-r1 acct.logrotate-r1
Log:
Move to stable since there was no functional difference anyway.

(Portage version: 2.2.0_alpha37/cvs/Linux x86_64)
 
 
  Hi Jer,
 
  I've noticed you did not update the ChangeLog in this commit. The new
  policy[1] requires to update the ChangeLog on every commit no matter
  how important or trivial it is. Please keep that in mind on your
  future commits.
 
  Regards,
 
  [1]:http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
  
  You are joking right?
  
 No sorry, I was instructed to enforce the policy

Please actually check the full commit.  He did update the ChangeLog, but
due to how these emails are sent out, they don't always come as a full
changeset.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Removal of kdeprefix news item

2011-05-23 Thread Mark Loeser
Ulrich Mueller u...@gentoo.org said:
  On Thu, 19 May 2011, Alec Warner wrote:
 
  You should file a bug about that; I'm sure one of the portage guys
  can change the crap code I wrote 4 years ago to use the normal
  dependency checking code for installed atoms.
 
 But we wouldn't know if users have the updated portage version
 installed, so it doesn't help for the current news item.
 
 I think for a proper solution we would have to increase the number of
 the News-Item-Format. Maybe even add a new header field for the EAPI.

This seems like the absolute easiest solution to use going forward.

Having an 'eapi' file present seems workable as well, though I'm not
certain which is the easiest for Portage to implement today.

Are there any other suggestions, or does anyone disagree with Ulrich's
suggestion?

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] PyXML

2011-05-17 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 PyXML is dead:
   http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
   http://mail.python.org/pipermail/xml-sig/2006-June/011545.html
 
 PyXML provides _xmlplus module, which replaces xml module (from standard 
 library) at run time,
 which might result in various problems.
 
 I'm planning to implement the following solution:
 - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of 
 this function will be
   necessary to use replace xml module with _xmlplus module. Python 
 =2.7.1-r2:2.7 will be added
   to the tree in next week and will be temporarily package.masked. Later this 
 change will be
   backported to new versions in older slots.
 - All packages, which use PyXML, will have to be patched to call 
 xml.use_pyxml(). The following
   code should be added before first import of anything from xml module:
 
 import xml
 if hasattr(xml, use_pyxml):
 xml.use_pyxml()

Is this use_pyxml upstream?  From what you are saying, it is not. In
that case, we have just made patches for every package that will never
be allowed upstream.  Why not do something more worthwhile than waste the
time of having to support something that might just become a problem to
maintain in the future?

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] PyXML

2011-05-17 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
  I second that. Why do we need to make all the work fixing packages
  instead of letting upstream do their job? I am not so excited to 
  fix every package I maintain as it is quite possible to introduce
  regressions in the process. Furthermore, I don't understand your first
  message. You say that you will provide xml.use_pyxml() function on
  python-2.7. Is this code official or you are just patching the official
  python releases?
  Anyway, as I said, I'd rather wait for upstream to fix their packages
  instead of me.
 
 Some upstreams are dead and some packages using PyXML will never be ported by 
 upstreams to use
 something else than PyXML (e.g. lxml).

Then those packages should get removed from the tree.  Do not start
introducing Gentoo specific hacks to work around the problem.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

2011-05-16 Thread Mark Loeser
Mike Frysinger (vapier) vap...@gentoo.org said:
 vapier  11/05/16 03:30:02
 
   Removed:  bzip2-1.0.5-r1.ebuild
   Log:
   old

Please document removal of ebuilds in ChangeLogs.

http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/

It'd also be better to do this all as one commit and run repoman with
each commit.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

2011-05-16 Thread Mark Loeser
Alec Warner anta...@gentoo.org said:
 On Mon, May 16, 2011 at 11:24 AM, Markos Chandras hwoar...@gentoo.org wrote:
  On Mon, May 16, 2011 at 08:19:45PM +0200, Francisco Blas Izquierdo Riera 
  (klondike) wrote:
  El 16/05/11 19:54, Kacper Kowalik escribió:
   Neither of those points include sending mail to gentoo-dev, which tend
   to quickly convert into the witch hunt and seldom lead to anything
   conclusive.
  To some of us (i.e. me as a staffer and probably any wanna be developer
  following the list) it is a good way to learn from others' mistake
  before applying for full developership.
 
 
  This may be a bit of surprise to you but this is not an educational
  list. If you people disagree with these kind of commits feel free to
  open a bug to QA/Devrel like the policy suggests. But pretty please
  try to break this non-sense loop of this and similar threads.
 
 I actually value times when this stuff is CC'd to the list, is there
 some other list you think folks should CC problems on?

This is exactly where these sorts of emails should go so every other
developer can see what's going on and ensure they are also following
current policies.

Don't make yet another list...that's just pointless.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-29 Thread Mark Loeser
Samuli Suominen (ssuominen) ssuomi...@gentoo.org said:
 ssuominen11/04/29 18:13:31
 
   Removed:  transmission-2.12.ebuild
   Log:
   drop old, broken with stable libnotify
   
   (Portage version: 2.2.0_alpha30/cvs/Linux x86_64, RepoMan options: --force)

When removing an ebuild, please do document it in the ChangeLog.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: transmission-2.12.ebuild

2011-04-29 Thread Mark Loeser
Samuli Suominen ssuomi...@gentoo.org said:
 On 04/29/2011 09:26 PM, Mark Loeser wrote:
  Samuli Suominen (ssuominen) ssuomi...@gentoo.org said:
  ssuominen11/04/29 18:13:31
 
Removed:  transmission-2.12.ebuild
Log:
drop old, broken with stable libnotify

(Portage version: 2.2.0_alpha30/cvs/Linux x86_64, RepoMan options: 
  --force)
  
  When removing an ebuild, please do document it in the ChangeLog.
  
  Thanks,
  
 
 no thanks

Everytime you do this you make it that much more difficult for someone
to track down why a dependency just broke, or why a version they needed
went away.  You make a changelog entry when you add a version...removing
one is just as important.

This is a policy on the tree that you are needlessly breaking.  If you
want the policy changed, then go do that.  Otherwise, follow the
policies that are there for a reason.  Contrary to what you may think,
you are not special and the rules apply to you as well.


Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Camellia?

2011-04-28 Thread Mark Loeser
Eray Aslan e...@gentoo.org said:
 On Thu, Apr 28, 2011 at 06:59:05PM +0300, Panagiotis Christopoulos wrote:
  Please, can you continue this somewhere more privately? I wouldn't like it 
  if
  I were a sysadmin and someone was posting information about versions of
  software of production machines publicly. I hope you understand.
 
 Security through obscurity does not work.  It especially will not work for the
 infrastructure of a Linux distribution.

What does any of this have to do with development of Gentoo?  Go send an
email to infrastructure if you want to talk to those that administer
those services.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-12-05 23h59 UTC

2010-12-06 Thread Mark Loeser
Rémi Cardona r...@gentoo.org said:
 Le 06/12/2010 01:25, Robin H. Johnson a écrit :
  Removals:
  media-libs/libresample  2010-12-01 19:06:41 chainsaw
  
  Additions:
  media-libs/libresample  2010-12-01 16:59:41 chainsaw
 
 A glitch in the matrix?

Seems valid.  It was added and removed shortly after:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/libresample/?hideattic=0

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: metadata.xml ChangeLog quassel-9999.ebuild quassel-0.7.1.ebuild

2010-11-04 Thread Mark Loeser
Tomáš Chvátal scarab...@gentoo.org said:
 Dne 4.11.2010 15:37, Jeremy Olexa napsal(a):
  On Thu,  4 Nov 2010 14:33:59 + (UTC), Tomas Chvatal (scarabeus) wrote:
  scarabeus10/11/04 14:33:59
 
Modified: metadata.xml ChangeLog quassel-.ebuild
  quassel-0.7.1.ebuild
Log:
Introduce logrotate useflag.
  
  Please remove the logrotate useflag, it should NOT be introduced.
  
  https://bugs.gentoo.org/198901 - [TRACKER] Nuking logrotate use flag
  
  -Jeremy
 You've got 3 years to get rid of that local useflag entirely, yet still
 5 ebuilds use it.
 So do me a favor, remove it proactively if you really want to have it gone.

Please do remove the flag.  The fact that there are some ebuilds in the
tree that use it does not make it alright to introduce more.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: gentoo-x86/net-misc/aggregate: aggregate-1.6.ebuild

2010-10-28 Thread Mark Loeser
Samuli Suominen ssuomi...@gentoo.org said:
 On 10/28/2010 09:11 PM, Mike Frysinger wrote:
  On Thu, Oct 28, 2010 at 10:20 AM, Samuli Suominen wrote:
  On 10/28/2010 12:30 PM, Fabian Groffen wrote:
  On 28-10-2010 09:25:23 +, Samuli Suominen wrote:
  ssuominen10/10/28 09:25:23
 
  Modified: aggregate-1.6.ebuild
  Log:
qa
 
  I think it would be good practice if you would give a summary of
  what type of QA you applied, even though for you it may be obvious.
  I just see lots of unnecessary changes that are apparently considered to
  be justified by QA.
 
  removal of quotes from ${A}, EAPI=2 to get src_configure to put
  econf and tc-getCC in, || die to make dobin, rest were unnecessary
  cosmetics not worth logging about
 
  so qa/cosmetics, are you really 'complaining' for not mentioning
  'cosmetics' in the commitlog?
  
  come on man, all you have to say is clean up and update to EAPI 2.
  that is infinitely better than a useless qa.  people can easily
  interpret QA stuff in a variety of significantly different ways.
  -mike
  
 
 agreed,
 
 I wasn't saying it was a perfect commit message. my point is more why
 are we having pointless discussion of commit messages in the first
 place? ;-)

Because it is not pointless.  Useful commit messages save lots of time.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


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

2010-10-25 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 2010-10-25 16:31:41 Petteri Räty napisał(a):
  On 10/25/2010 02:54 PM, Arfrever Frehtes Taifersar Arahesis (arfrever)
  wrote:
   arfrever10/10/25 11:54:19
   
 Modified: python.eclass
 Log:
 Set IUSE in EAPI =4.
 Rename _parse_PYTHON_DEPEND() to _python_parse_PYTHON_DEPEND() and 
   unset it after its using.
 Ban NEED_PYTHON variable.
 Add python_abi_depend().
 Fix exporting of python_pkg_setup() in EAPI =4.
   
  
  Please revert these until council has approved EAPI 4 for main tree
  usage or risk the consequences. There is no guarantee that IUSE will be
  in EAPI 4 although it's likely. If you want such pre-emptive actions in
  the main tree you should seek our approval first.
 
 python.eclass doesn't support EAPI=4 due to:
 
 if ! has ${EAPI:-0} 0 1 2 3; then
 die API of python.eclass in EAPI=\${EAPI}\ not established
 fi
 
 The attached patch could be applied if EAPI=4 doesn't contain support for 
 . in IUSE.
 Should I apply this patch now?

No, you should remove anything that relates to EAPI 4.  Please do so as
soon as possible.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/zsqlmethods: metadata.xml ChangeLog zsqlmethods-2.13.3.ebuild

2010-09-12 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis (arfrever) arfre...@gentoo.org said:
 arfrever10/09/11 21:47:18
 
   Added:metadata.xml ChangeLog zsqlmethods-2.13.3.ebuild
   Log:
   Initial addition.
   
   (Portage version: 2.2_rc80/cvs/Linux x86_64)
 


 Index: zsqlmethods-2.13.3.ebuild
 ===
 # Copyright 1999-2010 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: 
 /var/cvsroot/gentoo-x86/net-zope/zsqlmethods/zsqlmethods-2.13.3.ebuild,v 1.1 
 2010/09/11 21:47:18 arfrever Exp $
 
 EAPI=3
 PYTHON_DEPEND=2:2.6
 SUPPORT_PYTHON_ABIS=1
 RESTRICT_PYTHON_ABIS=2.4 2.5 3.*
 
 inherit distutils
 
 MY_PN=Products.ZSQLMethods
 MY_P=${MY_PN}-${PV}
 
 DESCRIPTION=SQL method support for Zope 2.
 HOMEPAGE=http://pypi.python.org/pypi/Products.ZSQLMethods;
 SRC_URI=mirror://pypi/${MY_PN:0:1}/${MY_PN}/${MY_P}.zip
 
 LICENSE=ZPL
 SLOT=0
 KEYWORDS=~alpha ~amd64 ~sparc ~x86
 IUSE=

Did you actually test this package on all of these archs?

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/pygtkhelpers: pygtkhelpers-0.4.1.ebuild

2010-09-12 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis (arfrever) arfre...@gentoo.org said:
 arfrever10/09/12 20:43:13
 
   Removed:  pygtkhelpers-0.4.1.ebuild
   Log:
   Delete older ebuild.

Please update the Changelog when you remove versions of the package.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass

2010-07-05 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 2010-07-05 18:26:40 Samuli Suominen napisał(a):
  On 07/05/2010 07:17 PM, Arfrever Frehtes Taifersar Arahesis wrote:
   2010-07-05 18:13:26 Samuli Suominen napisał(a):
   On 07/05/2010 06:23 PM, Arfrever Frehtes Taifersar Arahesis wrote:
   These minor changes in python.eclass and distutils.eclass have been 
   already
   reviewed on alias of Gentoo Python Project. It's recommended to be 
   familiar
   with internals of current code before trying to understand these minor 
   changes.
   Suggestions about indentation and quoting will be rejected.
  
  
   You have been already told to get rid of all the color customizations in
   the python eclasses here:
  
   http://bugs.gentoo.org/show_bug.cgi?id=309057#c2
   http://bugs.gentoo.org/show_bug.cgi?id=309057#c3
  
   [ .. ]
  
   http://bugs.gentoo.org/show_bug.cgi?id=309057#c5
  
   The bug was wrongly closed as fixed, as it's not really fixed before
   it's all punted
   
   Colors can be used with echo.
   
  
  Stop using echo for output and switch to standard output functions, like
  einfo/eerror/elog/... like told in
  http://bugs.gentoo.org/show_bug.cgi?id=309057#c5
 
 You should read relevant part of comment #7:
 The colors can of course be continued to be used in outputs that are purely 
 build
 time outputting and not for communicating things for users like what cmake 
 builds do.
 
 python.eclass uses colors for build time outputting, which doesn't 
 communicate anything for users.

Everyone else has already made valid points.  I'm just picking this one
to reply to now.  Please remove the colors you have added.  If you need
a new function, say eqawarn, we should have that added in the next
EAPI with a description of when and where to use it.  In the meantime,
Petteri proposed a nice solution awhile back that would centralize this
so it is not a one-off hack.  Here is a link to his original proposal:

http://archives.gentoo.org/gentoo-dev/msg_44d395a1b887468051a1e1c049e99ba3.xml

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] eqawarn for main tree

2010-07-05 Thread Mark Loeser
Petteri Räty betelge...@gentoo.org said:
 On 03/12/2010 11:27 PM, Zac Medico wrote:
  On 03/12/2010 11:39 AM, Petteri Räty wrote:
  In eclasses there's often use for outputting QA warnings for ebuild
  authors (at least in java and python could immediately make use of
  this). Currently Portage has eqawarn available but it's considered
  internal. Hopefully eqawarn finds it's way to the next EAPI but in the
  mean while do we want:
 
  1) Do a wrapper like attached to eutils.eclass
  2) Use whatever e* function that seems most appropriate (for example
  einfo when it's common so user LOGging setups don't get too much noise)
  3) Have a speedy next EAPI if we can find more stuff like this to bundle
  
  Here's another option:
  
  4) Retroactively add eqawarn to all EAPIs and use introspection to
  call eqawarn only if available (and drop the introspection after
  about 1 year):
  
 declare -F eqawarn /dev/null  \
 eqawarn this is ignored by older package managers
  
 
 As there was no further response and next EAPI isn't around the corner I
 propose getting the ball rolling with option 1. I will commit the patch
 next Sunday with needed documentation unless something comes up.

Could you please give a description as to when you believe this function
should be used.  Preferably as a patch for devmanual :)

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass

2010-07-05 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 2010-07-05 20:00:11 Mark Loeser napisał(a):
  Everyone else has already made valid points.  I'm just picking this one
  to reply to now.  Please remove the colors you have added.  If you need
  a new function, say eqawarn, we should have that added in the next
  EAPI with a description of when and where to use it.
 
 In case of the colored message added in this patch, if 
 einfo/elog/ewarn/eqawarn/eerror was used,
 then its output wouldn't be logged by Portage.

I don't understand what you are trying to say.  The QA team has decided
that the coloring should be removed from the python eclass and a
centralized generic solution should be proposed and agreed upon.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


[gentoo-dev] My council manifesto

2010-06-21 Thread Mark Loeser
Its quite simple.  I want to get innovation starting in Gentoo again.  I
am tired of seeing pointless arguments and threads that don't actually
make Gentoo any better.  Improving QA, improving our documentation,
making it easier for people to recognize how they can contribute, and
improving Gentoo as a whole, are all things that the Council should be
taking an active role in, and I want to be a part of making that happen.

I told you it was going to be short :)

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] My council manifesto

2010-06-21 Thread Mark Loeser
Arun Raghavan ford_pref...@gentoo.org said:
 On 22 June 2010 00:40, Mark Loeser halc...@gentoo.org wrote:
  Its quite simple.  I want to get innovation starting in Gentoo again.  I
  am tired of seeing pointless arguments and threads that don't actually
  make Gentoo any better.  Improving QA, improving our documentation,
  making it easier for people to recognize how they can contribute, and
  improving Gentoo as a whole, are all things that the Council should be
  taking an active role in, and I want to be a part of making that happen.
 
 Do you have any concrete ideas on how you will be doing these things?

We already have some people very active in QA working on tinderboxing.
I'd like to continue to have their work done, and try to expand on the
work they are doing to have it run on other architectures.  I've already
successfully got an ia64 donated for this.

We clearly have people that are interested in working on documentation,
but in wiki format.  I want to learn more why they are invested in that
format, and if there is some middle ground we can work on.

Its been a long standing problem that it seems people don't understand
how to become part of Gentoo.  I'd like to see the Staffing Needs page
better advertised, and update the How to Become a Developer guide to
help direct people to possible mentors.  Having a team of people outside
of the recruiters that are interested in mentoring new people, and how
these new people can get in touch with them would be cool.

I just think that the Council should take a somewhat active role in
trying to keep things moving.  There is a lot of good work going on, and
people seem to feel they are blocked for some reason in a lot of cases.
The Council should be there so we can keep progress moving forward in
whatever way we can.  Our devs do a lot of good work, and I want to do
my part to make sure they never feel they are hindered from doing that
work, and if they are, figure out how to address that issue.

Hope that helps,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open

2010-06-12 Thread Mark Loeser
Samuli Suominen ssuomi...@gentoo.org said:
 On Saturday 05 of June 2010 02:00:02 Torsten Veller wrote:
  Hello fellow developers and users.
 
  Nominations for the Gentoo Council 2010/2011 are now open for the next
  two weeks (until 23:59 UTC, 18/06/2010).
 
  All nominations must be sent to the gentoo-dev mailing list. If you
  were nominated and want to run, you have to accept your nomination on
  the same mailing list.
 
 I'll nominate flameeyes and halcy0n.

Thanks,

I accept.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] package.mask-ed ebuilds

2010-04-09 Thread Mark Loeser
Nirbheek Chauhan nirbh...@gentoo.org said:
 So, I can't find any documentation about this; nor can I find a
 best-practices list. Can we add broken ebuilds in-tree as long as they
 are package.masked? automagic deps, wrong deps, missing deps, file
 collisions, etc etc? Even if it makes the ebuild completely unusable
 by itself?

Just use some common sense.  If its completely broken, it obviously
doesn't belong in the tree.  If its something that somewhat works and is
actively being worked on, then its probably safe to add it and
package.mask it, with the intent that you are working towards getting it
to a state that it will be unmasked.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] How about a monthly bumpday?

2010-03-10 Thread Mark Loeser
Mike Frysinger vap...@gentoo.org said:
 On Tuesday 09 March 2010 23:08:24 Sebastian Pipping wrote:
  We have about 500 bump request open at the moment:
  https://bugs.gentoo.org/buglist.cgi?quicksearch=bump
  
  I assume that quite a few of them would be no big deal to their
  maintainers in Gentoo.
  
  
  Bugday is occupying the first Saturday of the month: how about bumpday
  on the third Saturday of the month?  First bumpday could be March 20th,
  10 days from now.
  
  What do you think?
 
 for the maintainer-needed ones, np.  for the ones with maintainers, i think 
 you need an ack from someone first.

I don't even think the maintainer-needed ones should be bumped.  Who
knows what bugs you are introducing into the tree.  This is why things
eventually get treecleaned.

As Mike said, for ones with maintainers, don't touch them unless you
have explicit permission.  We have maintainers for a reason, and if you
don't know the intricacies of the package, you shouldn't be touching it.
You should know how it works, how to test it, and what the normal
problems of a bump are.

With that being said, I don't really see the point of a bumpday.  These
day ideas are ignoring the fact that we don't have enough active developers,
which is the real problem.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events

2010-03-10 Thread Mark Loeser
Duncan 1i5t5.dun...@cox.net said:
 So a gmail account is now considered mandatory for Gentoo devs, at least 
 if they want calendar access?
 
 What about those who might think that Google knows enough about them with 
 search and the web crawling and database correlation Google does, and 
 whatever ad serving might leak thru, and object to having a gmail account 
 on principle?

Then they don't get to see the calendar

Seriously though, who cares.  If it becomes a problem, we can deal with
it then.  Until that point, use what we have or implement something
that's better.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Low hanging bug fruit patterns

2010-03-08 Thread Mark Loeser
Sebastian Pipping sp...@gentoo.org said:
 Hello!
 
 
 There are a few patterns for potentially low hanging fruits among Gentoo
 bugs:
 
   SRC_URI errors
   Missing depencies
   ...
 
 What else?
 
 Anything you look after repeatedly that doesn't take days to get it fixed?

What is this even in reference to?  Its not at all clear what you are
trying to do.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Python 3.1: Stabilization and news item

2010-03-07 Thread Mark Loeser
Sebastian Pipping sp...@gentoo.org said:
 On 03/04/10 19:22, Arfrever Frehtes Taifersar Arahesis wrote:
  All problems, which were blocking stabilization of Python 3, have been 
  fixed.
  Stabilization of Python 3.1.2 is currently scheduled on 2010-04-19.
 
 #python on Freenode still reads It's too early to use Python 3.x.
 Are they wrong?

I'd believe them.

 Are we at a point already where we can feed 90% of the Python 2.x code
 out there to Python 3 without problems?

Doesn't seem that way.

 Has QA given their blessing to this?

Absolutely not.  Its actually the opposite.  Until 90+% of the tree just
works with the new version of python, it should not be stabilized.  The
stable tree should all Just Work together.  Stabilizing python-3 at this
point would be the equivalent of me stabilizing gcc-4.5 after its been
in the tree for a few months and nothing else works with it.  Sure, gcc
works just fine, but it can't compile half of the tree.

I hope everyone can see that this is a terrible idea and of no use to
our stable users.  If a stable user really needs Python-3, they will
have the technical ability to unmask it and use it properly.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: Lastrite: games-fps/openarena

2010-03-03 Thread Mark Loeser
Michael Sterrett mr_bon...@gentoo.org said:
 I've remove the mask for games-fps/openarena.
 
 The mask was done without consulting the games team.

This is no reason to remove the mask.  The games team had more than
enough time to fix the package.  I'll be adding the mask back as the
package is vulnerable via multiple bundled libs and therefore shouldn't
be in the tree.  You can apply the patches if you want to keep it and
remove the mask at that time.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


signature.asc
Description: Digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/rhythmbox: metadata.xml ChangeLog rhythmbox-0.12.7.ebuild

2010-03-02 Thread Mark Loeser
Gilles Dartiguelongue (eva) e...@gentoo.org said:
 eva 10/03/01 23:31:32
 
   Modified: metadata.xml ChangeLog
   Added:rhythmbox-0.12.7.ebuild
   Log:
   Version bump. Lots of fixes, add rdepend for context panel plugin. Kill 
 *.la files for plugins.

   (Portage version: 2.2_rc63/cvs/Linux x86_64, RepoMan options: --force)
 
This seems to be a growing trend, so let me address it here...Do not use
--force to get an ebuild into the tree that has unsatisfiable
dependencies.  --force should only be used in circumstances where it is
the only option.  Breaking deps for an arch is not what it is intended
for.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Marking bugs for bugday?

2010-03-01 Thread Mark Loeser
Ioannis Aslanidis aslani...@gmail.com said:
 Hello,

  [... whole bunch of ideas ...]

 Let me hear of what you have to say to all this.

Has anyone looked at how others projects do bugdays?  We shouldn't need
to reinvent the wheel here and can probably get some great ideas from
other distributions out there.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Marking bugs for bugday?

2010-02-27 Thread Mark Loeser
Sebastian Pipping sp...@gentoo.org said:
 Hello!
 
 
 I'm surprised that there is no keyword in Gentoo's bugzilla [1] to mark
 bugs for bugday.  Is there a good reason why such a keyword does not
 exist?  Would it be hard to set up?

I think the goal was to have http://bugday.gentoo.org/ fill this role
instead of polluting bugzie with more keywords.  I'm not really attached
to one approach over the other, but atleast this little site gives the
users one place to have to check for things and we can categorize them
easily.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Marking bugs for bugday?

2010-02-27 Thread Mark Loeser
Roy Bamford neddyseag...@gentoo.org said:
 The last few times I've dropped into bugday, its been very quiet, which 
 suggests its in need of some tlc but maybe its just my timezone.

Its been pretty much dead.  We need more developer involvement so users
can actually talk to them and help resolve issues.  If we can't get
enough developers to participate then we should just stop trying to do
it instead of putting on such a poor showing.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Marking bugs for bugday?

2010-02-27 Thread Mark Loeser
Ben de Groot yng...@gentoo.org said:
  Its been pretty much dead.  We need more developer involvement so users
  can actually talk to them and help resolve issues.  If we can't get
  enough developers to participate then we should just stop trying to do
  it instead of putting on such a poor showing.
 
 I would like to be involved but not in the current disorganized form. Our
 #gentoo-bugs channel topic still refers to the thoroughly outdated
 bugsday.g.o page, and I can't edit either of them.

I can modify the channel topic for you.  I should have a login for the
bugsday.g.o page somewhere, if not...I'm sure we can get one.

 We need an easier interface to mark bugs to be tackled on bugday,
 and I like Sebastian's proposal for that. The idea for the bugsday.g.o
 page is good, but it needs to be brought up-to-date and accessible
 to all devs. Low barriers to participation and all that. And even devs
 who cannot take part on the day itself could participate by requesting
 certain bugs or issues to be tackled.

If you want to take the lead on this, come and talk to me on IRC and let
me know what ideas you have.  I'd love to see it take off, but I don't
have the time to put towards it myself.

 Also, participating devs should get permission to commit easy fixes
 for packages they don't maintain (the other thread about commit
 policies is relevant here). Obviously issues that are more involved
 need to be passed on to the proper maintainers.

This is something we'll have to be careful of and discuss what types of
changes can be done.  Not everything needs to be necessarily fixed in
the tree though, helping users get proper patches onto bugs can be just
as good and help get more useful contributions from those users in the
future.  Consider it an opportunity to train possible new developers.

 I think if we can get a few devs and possibly some users together
 to organize this in a better way, this could be useful. But if things
 are to stay the way they are, then we better stop pretending.

I couldn't agree more.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Re: Remove dev-status of mips profiles

2010-02-25 Thread Mark Loeser
Torsten Veller ml...@veller.net said:
 * Torsten Veller t...@gentoo.org:
  Can we please move the mips profiles from dev to exp in
  profiles/profiles.desc?
 
 Based on the current feedback I'll change it not earlier than friday
 next week if nobody objects.

That would be nice.  I'd also love to know why we need about 150
different profiles for MIPS...

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Python-3.2-related changes

2010-02-06 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
  I consider filing bugs for not adjusted packages after some months (e.g in 
  summer).
 
 1123 packages (440 in dev-python category) from 108 categories specify 
 dev-lang/python
 or virtual/python in DEPEND or RDEPEND, so actually it might be better to 
 start filing
 bugs in this month. If there are no objections, then I would like to file 1 
 bug per
 category (except dev-python category).

Make trackers and make one bug per package.  Its way too hard to follow
a huge metabug with a bunch of packages listed in it.  Also, I think the
concerns and suggestions that were brought up about the syntax of this
new variable should be addressed first and not ignored.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

2009-11-08 Thread Mark Loeser
Patrick Lauer patr...@gentoo.org said:
 If you feel you have too much time you could search on bugzilla for patch 
 and start fixing those bugs. Bump is also a funny search. 

If you are just bumping random packages and applying patches when you
have no idea how the package works, we have a problem on our hands.
Please don't do that, you are only making more work for others.  Perhaps
some of the things that are not maintained should go away.

 Once you've done that for 3 months we can renegotiate cosmetic bugs and QA.

Renegotiate QA?  Do not commit anything to the tree that doesn't comply
to QA standards.  Its really that simple.  Don't be lazy and do things
the right way, or don't do them at all.


 Kthxbai,

Also, please learn how to communicate in a manner that is constructive
instead of acting like a dick at every opportunity.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpgRzcnPXpT9.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

2009-11-08 Thread Mark Loeser
Ben de Groot yng...@gentoo.org said:
 2009/11/8 Mark Loeser halc...@gentoo.org:
  Also, please learn how to communicate in a manner that is constructive
  instead of acting like a dick at every opportunity.
 
 Looks to me this should be applied to some others in this thread first.
 Really, aren't there more constructive ways to communicate your (meaning
 all of you in this thread) concerns, without demotivating the person who
 does so much work for Gentoo?

If the person doing said work does not care about abiding by QA
standards, then that person shouldn't be touching the tree to begin
with.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpv1uG57G78X.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-benchmarks/bonnie++: bonnie++-1.96.ebuild ChangeLog bonnie++-1.93c.ebuild

2009-11-08 Thread Mark Loeser
This removed the only stable version of bonnie++ from the tree.  I have
just added it back to the tree.

Everyone, please be careful when you are pruning old ebuilds.

Thanks,

Mark

Patrick Lauer (patrick) patr...@gentoo.org said:
 patrick 09/11/08 12:26:16
 
   Modified: ChangeLog
   Added:bonnie++-1.96.ebuild
   Removed:  bonnie++-1.93c.ebuild
   Log:
   Bump, remove old
   (Portage version: 2.2_rc49/cvs/Linux x86_64)
 
 Revision  ChangesPath
 1.28 app-benchmarks/bonnie++/ChangeLog
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-benchmarks/bonnie++/ChangeLog?rev=1.28view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-benchmarks/bonnie++/ChangeLog?rev=1.28content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-benchmarks/bonnie++/ChangeLog?r1=1.27r2=1.28
 
 Index: ChangeLog
 ===
 RCS file: /var/cvsroot/gentoo-x86/app-benchmarks/bonnie++/ChangeLog,v
 retrieving revision 1.27
 retrieving revision 1.28
 diff -u -r1.27 -r1.28
 --- ChangeLog 16 Jun 2009 14:38:12 -  1.27
 +++ ChangeLog 8 Nov 2009 12:26:15 -   1.28
 @@ -1,6 +1,12 @@
  # ChangeLog for app-benchmarks/bonnie++
  # Copyright 1999-2009 Gentoo Foundation; Distributed under the GPL v2
 -# $Header: /var/cvsroot/gentoo-x86/app-benchmarks/bonnie++/ChangeLog,v 1.27 
 2009/06/16 14:38:12 jer Exp $
 +# $Header: /var/cvsroot/gentoo-x86/app-benchmarks/bonnie++/ChangeLog,v 1.28 
 2009/11/08 12:26:15 patrick Exp $
 +
 +*bonnie++-1.96 (08 Nov 2009)
 +
 +  08 Nov 2009; Patrick Lauer patr...@gentoo.org -bonnie++-1.93c.ebuild,
 +  +bonnie++-1.96.ebuild:
 +  Bump, remove old
  
16 Jun 2009; Jeroen Roovers j...@gentoo.org bonnie++-1.95.ebuild:
Marked ~hppa too.
 
 
 
 1.1  app-benchmarks/bonnie++/bonnie++-1.96.ebuild
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-benchmarks/bonnie++/bonnie++-1.96.ebuild?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-benchmarks/bonnie++/bonnie++-1.96.ebuild?rev=1.1content-type=text/plain
 
 Index: bonnie++-1.96.ebuild
 ===
 # Copyright 1999-2009 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: 
 /var/cvsroot/gentoo-x86/app-benchmarks/bonnie++/bonnie++-1.96.ebuild,v 1.1 
 2009/11/08 12:26:15 patrick Exp $
 
 inherit eutils
 
 DESCRIPTION=Hard drive bottleneck testing benchmark suite.
 HOMEPAGE=http://www.coker.com.au/bonnie++/;
 SRC_URI=http://www.coker.com.au/bonnie++/experimental/${P}.tgz;
 
 LICENSE=GPL-2
 SLOT=0
 KEYWORDS=~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86
 IUSE=debug
 
 DEPEND=
 RDEPEND=
 
 src_compile() {
   econf \
   $(use_with debug) \
   --disable-stripping \
   || die
   emake || die emake failed
   emake zcav || die emake zcav failed # see #9073
 }
 
 src_install() {
   dosbin bonnie++ zcav || die
   dobin bon_csv2html bon_csv2txt || die
   doman bon_csv2html.1 bon_csv2txt.1 bonnie++.8 zcav.8
   dohtml readme.html
   dodoc changelog.txt credits.txt
 }
 
 
 
 

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpoFIU5ZXEXR.pgp
Description: PGP signature


Re: [gentoo-dev] openrc-0.5.1 arrived in the tree

2009-10-13 Thread Mark Loeser
Mike Frysinger vap...@gentoo.org said:
 On Tuesday 13 October 2009 19:30:52 Joshua Saddler wrote:
  All that to say, Tommy (et al), is that the idea of expecting users to
   magically know everything and not to offer any documentation *in advance*
   . . . is a silly idea. Good lord, can you imagine the shitstorm the X11
   team would have gone through if they'd tried *that* without first writing
   up xserver 1.5 and 1.6 migration guides?!
 
 we arent talking migrations that are forced onto everyone.  we're talking 
 about new code that users have to *opt in* for (new net) that is only 
 available in unstable.  expecting everything in testing to be documented up 
 front is unreasonable.  no one is saying the stuff shouldnt be documented, 
 just that complete user friendly coverage is not a requirement for unstable.  
 your comments here dont really apply to bleeding edge -- they certainly apply 
 to stable though.

I'd say this isn't correct.  Unstable isn't a pure testing playground.
its meant for packages that should be considered for stable.  As such,
we should make sure that we get the documentation needed ready, so we
can make sure that it is correct for people that are testing the upgrade
path for us.  It then gives us a chance to correct our documentation
before it goes stable.

All this comes down to is laziness in documenting changes, and forcing
stuff upon our users.  Neither of those things is good, and if everyone
thinks that's the status quo...that really should change.


-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpX2U6V4nQow.pgp
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Mark Loeser
Dawid Węgliński c...@gentoo.org said:
 You mix it up. Portage works with python 3.1. If an user switches to python 
 3.1 as the main interpreter, it's possible that his own scripts won't work. 
 Marking it stable sometine in november give's some time to ebuilds 
 maintainers to fix their python based apps just like it's done with gcc 
 stabilization.

And you are mixing that up.  We never mark GCC stable before we fix
everything we have identified as a problem, or pretty close to
everything.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpW6pMGhwBsH.pgp
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 I agree. But Python 3.1 doesn't have more issues than Python 2.6, so
 the stabilization is reasonable.

And how about all of the packages in the tree that use python?  You are
missing that huge part.  That's like saying libfoo works absolutely
great, but every single application that links to libfoo now breaks with
the new release of libfoo-2.0.  The things that use your package are
just as important when looking to stablize something or to move it out
of package.mask.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpuYjSfPlpRR.pgp
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 Stabilization of Python 3.1.* will be requested at the beginning of november.
 There was a suggestion to create a news item which would inform users that
 temporarily they shouldn't switch to Python 3 as their main interpreter.
 Python ebuilds don't automatically activate Python 3, so I'm not sure if
 the news item is required. What is your opinion about it?

Please don't do this.  The stable system is meant to Just Work.  We
don't need people switching between python versions and making half of
their system unusuable.  There is absolutely no benefit to moving it to
stable.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpBOqjpyzWlZ.pgp
Description: PGP signature


Re: [gentoo-dev] Multimedia overlay

2009-08-10 Thread Mark Loeser
Ben de Groot yng...@gentoo.org said:
 So hereby we announce the Gentoo Multimedia overlay. It is located at
 http://gitorious.org/gentoo-multimedia and any developers who want to
 join can let us know their gitorious account name, so they can be added.
 Administration of the overlay will be shared among the participating
 Gentoo devs, so new committers can quickly be added. Any users that want
 commit status can get access after their work is found to be of
 sufficient quality. We encourage this, as the overlay is also a training
 ground for new contributors to Gentoo.

Why can't this be on our official overlays?  Is there a technical
reason, because we seem to just be spreading things out even more than
necessary.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpcnAKKm9Mwb.pgp
Description: PGP signature


Re: [gentoo-dev] QA last rites for dev-libs/libowfat; net-misc/slidentd www-servers/gatling

2009-08-09 Thread Mark Loeser
Chip Parker infowo...@gmail.com said:
 dev-libs/libowfat _does_ build. I currently have the version
 complained about in the bug installed on amd64, try instead compiling
 with gcc-4.4 and/or sending your bug report upstream.

If it doesn't build with gcc-4.4, it better go sooner rather than later,
because its going to break in a week.  He doesn't maintain the package,
do you?  If so, then please send the bug report upstream and become the
maintainer of this package if you want to keep it around.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpZQbQ157vZB.pgp
Description: PGP signature


Re: [gentoo-dev] Re: gcc-4.4 unmasking soon

2009-08-08 Thread Mark Loeser
Nikos Chantziaras rea...@arcor.de said:
 I see that the graphite USE flag is disabled by default.  Are there any 
 known issues with this new optimizer?

None that I know of, but then again, I have not really played with it a
whole lot to say one way or the other.  If you want to test it, please
file any bugs you find to toolchain.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpJWhiHk4CzC.pgp
Description: PGP signature


[gentoo-dev] gcc-4.4 unmasking soon

2009-08-04 Thread Mark Loeser
I'd really like to unmask gcc-4.4.1 soon, as in the next week or so.
If you could please install it and test it out, I would appreciate it.
Also, if you have any gcc 4.4 porting bugs assigned to a herd that you
are a part of, resolving those bugs would help a lot.

Thanks to all that have contributed and helped already,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpTWFS2O2djB.pgp
Description: PGP signature


Re: [gentoo-dev] Global use flags eabled by default

2009-07-01 Thread Mark Loeser
Maciej Mrozowski reave...@poczta.fm said:
 Hello
 
 Somewhat continuing my battle to reasonably minimise USE flags enabled by 
 default for users, I'd like to ask about one particular commit. Note that 
 there's no commit message and it looks a bit fishy:
 
 http://sources.gentoo.org/viewcvs.py/gentoo-
 x86/profiles/base/use.defaults?r1=1.1r2=1.1.1.1

That is on a different branch and is incredibly old.  To make a long
story short...someone screwed up and created their own branch of the
whole tree.  It isn't actually being used.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpFmrO1l9HDA.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

2009-06-01 Thread Mark Loeser
Tiziano Müller dev-z...@gentoo.org said:
 The people I'd like to nominate:

 - halcy0n ... even though he had to resign early I hope he finds time
 again to run for council, I really enjoy working together with him and I
 appreciate his common sense

Thanks Tiziano, but I like the extra time I'm having to work on other
things right now, so I have to decline.  Maybe the next time around.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpZqzOCwvr1q.pgp
Description: PGP signature


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

2009-05-17 Thread Mark Loeser
William Hubbs willi...@gentoo.org said:
 I was told by the brltty developers that localstatedir should be /var.
 I noticed, however, that econf passes --localstatedir=/var/lib to the
 configure script.  The way around this was to pass the --localstatedir
 option to econf.

According to FHS we are doing it right:
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION

I guess what I would really like to know is...why does it matter?  If
something is configurable like that, then it should work regardless of
what is put in.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpDmYeIX5LuK.pgp
Description: PGP signature


Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

2009-05-10 Thread Mark Loeser
Sérgio Almeida meph...@gmail.com said:
 Abstract:
 
 Universal Select Tool is an utility to manage system configuration.
 This tool is similar to the unmaintained eselect utility of Gentoo or
 Exherbo's eclectic. The idea is to create a tool that  manages both
 system settings and user settings with profile creation possibilities.
 The utility will use mostly concepts from modules, softenv, and
 both eselect and eclectic.

I guess this is a very high level question...but do we need yet another
eselect?  Why can't we enhance or fix what we already have rather than
creating everything from scratch?

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpUGXMzGTQ7a.pgp
Description: PGP signature


Re: list purpose. was: Re: [gentoo-dev] Re: gentoo-x86 commit in app-forensics/memdump: memdump-1.0.1.ebuild ChangeLog

2009-01-05 Thread Mark Loeser
Daniel Black dragonhe...@gentoo.org said:
 I'm not sure I want to see this list being a QA list for commits.
 
 If there is a commit that raises an interesting question for everyone sure 
 put 
 it here.
 
 Otherwise please take up QA faults with the author or devrel if you think 
 they 
 are consistantly under-standard.

I'm pretty sure this has come up before...  The developer list is the
best place for us to do peer review, since it not only helps the person
that is being reviewed, but also helps other developers at the same
time since they can see issues and how to correct them.

My 2c would be that if you don't want to see them to set up a filter.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpgZsS26DXRH.pgp
Description: PGP signature


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

2008-12-11 Thread Mark Loeser
Ciaran McCreesh ciaran.mccre...@googlemail.com said:
 On 01 Dec 2008 05:30:01
 Mike Frysinger vap...@gentoo.org wrote:
  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.
 
 Please give the OK on the following, assuming no objections crop up
 before then:
 
 * [RFC] Label profiles with EAPI for compatibility checks (revised)
   
 http://archives.gentoo.org/gentoo-dev/msg_930f58fcebcbbcbe523c001f2c825179.xml

Looks good to me.

 * EAPI change: Call ebuild functions from trusted working directory
   
 http://archives.gentoo.org/gentoo-dev/msg_5ba467bbd5a0820e040210683702a67f.xml

Ditto.

 * RFC: DEFINED_PHASES magic metadata variable
   
 http://archives.gentoo.org/gentoo-dev/msg_8c34d8efbc0d31ab28c517403dc83f62.xml

Same.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp0avzg69XWr.pgp
Description: PGP signature


[gentoo-dev] An official Gentoo wiki

2008-11-11 Thread Mark Loeser
So, gentoo-wiki.com went down for a awhile and took something away from
our users something that is useful.  Its back now, but I think we should
consider having our own official wiki that our users can contribute to.
We already have something very similar to this on the forums, and this
would just give the correct tool to put their documentation on.

I already know some people are going to hate this idea and say that the
documentation could be wrong, etc, so lets look at how others have
handled this situation.  It seems that Ubuntu has their own official
documentation section and a community section where users can contribute
to.  We can put a nice big warning saying that the user documentation
may have some errors, and that any such errors should not be directed at
the maintainers of the package or the GDP.

What are others feelings on this?  What issues do you see with having a
wiki?  Do you see anyway to resolve the issue you see with us having a
wiki?

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpR4907laveX.pgp
Description: PGP signature


[gentoo-dev] Proposal for how to handle stable ebuilds

2008-11-10 Thread Mark Loeser
Instead of addressing archs as being slackers or not, this addresses it
as a more granular layer of looking at ebuilds.  Thanks to Richard
Freeman for the initial proposal that I based this off of.  Please give me
feedback on this proposal, if you think it sucks (preferably with an
explanation why), or if you think it might work.

Ebuild Stabilization Time

Arch teams will normally have 30 days from the day a bug was filed, keyworded
STABLEREQ, the arch was CCed, and the maintainer either filed the bug or
commented that it was OK to stabilize (clock starts when all of these
conditions are met).

Security bugs are to be handled by the policies the Security Team has
established.

Technical Problems with Ebuild Revisions

If an arch team finds a technical problem with an ebuild preventing
stabilization, a bug will be logged as a blocker for the keyword request.  The
bug being resolved resets the time for the 30 days the arch team has to mark
the ebuild stable.

Removing Stable Ebuilds

If an ebuild meets the time criteria above, and there are no technical issues
preventing stabilization, then the maintainer MAY choose to delete an older
version even if it is the most recent stable version for a particular arch.

If an ebuild meets the time criteria above, but there is a technical issue
preventing stabilization, and there are no outstanding security issues, then
the maintainer MUST not remove the highest-versioned stable ebuild for any
given arch without the approval of the arch team.

Security issues are to be handled by the recommendations of the Security Team.

Spirit of Cooperation

Ebuild maintainer and arch teams are encouraged to work together for the sake
of each other and end users in facilitating the testing and maintenance of
ebuilds on obscure hardware, or where obscure expertise is needed.  Package
maintainers are encouraged to use discretion when removing ebuilds in
accordance with this policy.


--
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpdydl9hHo6Z.pgp
Description: PGP signature


Re: [gentoo-dev] Proposal for how to handle stable ebuilds

2008-11-10 Thread Mark Loeser
Jose Luis Rivero [EMAIL PROTECTED] said:
 Mark Loeser wrote:
 Removing Stable Ebuilds
 If an ebuild meets the time criteria above, and there are no technical 
 issues
 preventing stabilization, then the maintainer MAY choose to delete an 
 older
 version even if it is the most recent stable version for a particular 
 arch.

 Mark, I think you are looking at the problem only with the ebuild 
 maintainer hat put on. We have other players in our business, being one of 
 them the users. This policy would bring too many problems to them so .. 
 nono by my side.

I purposely did this.  I like the proposal, but I also know that it has
a lot of problems.  It was better than sending something out asking what
people think though.

 I would prefer to analyze the causes of the slacker arch (manpower, 
 hardware, etc) and if we are not able to solve the problem by any way 
 (asking for new devs, buying hardware, etc) go for mark it as experimental 
 and drop all stable keywords.

This is one way to resolve it.  We need to establish how an arch gets
pushed to experimental and how maintainers need to deal with that
though.  An example is removing the only version of a package that works
on that specific arch, is this a problem if the arch is declared to be
experimental?

If this is the path we want to go down, lets set up some rules for how
to handle experimental archs and what it means to go from
stable-experimental and experimental-stable.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpS6lqfqSAGz.pgp
Description: PGP signature


Re: [gentoo-dev] Bug wrangling

2008-09-08 Thread Mark Loeser
Christian Faulhammer [EMAIL PROTECTED] said:
 Hi,
 
 everyone working on bugs, please add all people from metadata.xml to
 the assignee or cc field, I regularly have to search for bugs where a
 team and I maintain a package because only the team has been added.
  Second, please use full atoms (cat-egory/package) in the Summary
 field, so searching is easier.

jer added some good stuff up on the bug-wranglers page:

http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml#doc_chap4

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgplj1sJibdvl.pgp
Description: PGP signature


[gentoo-dev] EAPI usage in the tree

2008-09-03 Thread Mark Loeser
Just a friendly reminder from your QA team...please do not commit
ebuilds to the tree that are not using an EAPI that is not approved by
the council (in masked or unmasked ebuilds).  This means that the only
EAPIs you can use in the tree are EAPI 0 and 1.  If you want to use any
of the EAPI-2 prereleases, please do so in an overlay.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpCNR0gs9t8D.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council Reminder for August 7

2008-08-18 Thread Mark Loeser
Lukasz Damentko [EMAIL PROTECTED] said:
 Fair enough. Let me wrap up the IRC part.
 
 1. I'd like to ask Council to discuss possible reactions to our
 developer being banned from Freenode without providing us with a
 reason. The situation looks like one of Freenode staffers overreacted
 over something Chris said during previous Council meeting and banned
 him to prevent him from attending next meetings when he was supposed
 to provide more information on the CoC topic. The ban was removed
 after an hour, but they still refuse to provide us with reasons for it
 which looks like (mostly because we weren't shown any sane
 justification for the ban) a cover up operation. It would be good if
 Council officially protested against that ban and demanded a detailed
 explanation from Freenode staff.

Due to their privacy policy I don't think we'll ever be able to get
adequate explanations from Freenode staff when our devs are banned.

 2. I want Council to consider moving their meetings somewhere where
 third parties can't control who in Gentoo can attend and who can't.
 Like our own small and created just for this purpose IRC server. A
 situation when a third party may disallow our developer from attending
 a meeting without even telling us why isn't the healthiest one. We
 should be independent from such decisions of third parties so they
 can't politically influence Council decisions by removing people who
 are inconvenient for them. Now when it (most probably) happened once,
 we have no other choice but to believe it's possible it will happen
 again.

If for some reason a developer was unable to attend a meeting due to
being klined or the internet being FUBAR'd, I know that I have my IM
details available in LDAP for that dev to be able to contact me, or they
could send the entire council an email. I don't think setting up our own
IRC server is worth the trouble for this small purpose.

 3. I want Council to consider creating and using irc.gentoo.org alias
 instead of irc.freenode.net in our docs, news items and so on. The
 alias would allow us to move out of the network more easily should we
 ever decide to do so. Debian did exactly the same a couple of months
 ago prior to them moving out to OFTC
 (http://www.debian.org/News/2006/20060604)  so maybe it would be a
 good idea to have this for Gentoo too. Infra (Shyam Mani) say it isn't
 a problem at all to create and maintain it, we in fact already have
 something like this pointing at Freenode, it would be just a question
 of updating that alias and updating our docs with it. It would
 increase our independence from Freenode and make future network
 switching much easier should we ever decide it's time to part our ways
 with our current IRC service provider.

I like this idea.  spb rose some concerns in the meeting with regards to
some users thinking that if they came onto irc.gentoo.org and joined #java
that it would be a Gentoo java channel, but it doesn't seem like
Freenode considers this to be much of a problem.  For evidence of this:
http://freenode.net/acknowledgements.shtml

They thank projects for pointing their domains to them, so I believe
that the network as a whole shouldn't have a problem with this.  If
someone thinks I'm misunderstanding what they mean on that page, please
let me know.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpuLxRnl25xF.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council Reminder for August 7

2008-08-18 Thread Mark Loeser
Ben de Groot [EMAIL PROTECTED] said:
 2) Continued presence of forcefully retired devs
 It really baffles me that some developers are forcefully retired for
 anti-social behavior, but are not consequently banned from the places
 where they display this behavior, such as our MLs and IRC channels. What
 good is it to retire developers, but allow them to continue to be
 disruptive? I would like the Council to decide for a change in our
 policy on this point.

I personally don't see why they should be allowed to stay part of our
communication channels where they have caused problems bad enough to get
them retired.  With that being said, I think the same technical issues
come into play here as with banning someone from Gentoo entirely.

I am not sure how we would be able to enforce this across the board for
forcefully retired developers.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpvsdKcZDfkV.pgp
Description: PGP signature


Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]

2008-08-13 Thread Mark Loeser
Josh Saddler [EMAIL PROTECTED] said:
 If you're going for proper XML, then it should look like this:

 flag name=png/

 XML doesn't put a space between the attribute and the closing slash -- 
 XHTML does. Common mistake. Also, use  for attributes, rather than '.

Well, if we want to nitpick, adding a space, tab, or newline is
perfectly valid, as is using ' to quote the attribute. :)

http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EmptyElemTag
http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-AttValue

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpSeDKKUaTpX.pgp
Description: PGP signature


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

2008-08-06 Thread Mark Loeser
Robin H. Johnson [EMAIL PROTECTED] said:
 Getting the bot out there
 -
 If you would like to have the new bot in your #gentoo-* channel, would
 each channel founder/leader please respond to this thread, stating the
 channel name, and that they are the contact for any problems/troubles.

#gentoo-cpp
#gentoo-qa
#gentoo-toolchain

Thanks Robin,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpQFFdAQDCRS.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council 2008/2009 - RESULTS

2008-07-05 Thread Mark Loeser
Łukasz Damentko [EMAIL PROTECTED] said:
 Dear Gentoo Community,
 
 Here are your verified and long-awaited results.
 
 Gentoo Council for term 2008/2009 will be:
 
 Donnie Berkholz (dberkholz)
 Mark Loeser (Halcy0n)
 Diego Petteno (Flameeyes)
 Petteri Raty (Betelgeuse)
 Luca Barbato (lu_zero)
 Markus Ullmann (Jokey)
 Tobias Scherbaum (dertobi123)

Thanks everyone.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpO3nhS7vvTS.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [v3] Planning for automatic assignment of bugs

2008-07-03 Thread Mark Loeser
Duncan [EMAIL PROTECTED] said:
 Jim Ramsay [EMAIL PROTECTED] posted [EMAIL PROTECTED],
 excerpted below, on  Tue, 01 Jul 2008 11:29:56 -0400:
 
  Mark Loeser [EMAIL PROTECTED] wrote:
  Its a good idea, but since our users don't always provide useful
  reports, it seems like we are just shifting work around.
  
  I'd suggest that this would /spread/ work around - Instead of a few
  folks wrangling bugs, everyone would be doing it.
  
  That said, I have no idea how many duplicate / incomplete bugs I have
  never seen due to the wonderful work of the wranglers.  In some ways it
  would be a shame to lose that quality pre-reading of the bugs.
 
 Perhaps the best solution is to get the implementation in place, but not 
 completely automate it.  Put the tools there so if it looks right, all 
 the wrangler needs to do is a single click, and it's auto-assigned, but 
 that single click is still necessary so that a human actually gets to 
 review things before doing the assignment.
 
 That would make it /much/ easier for the wranglers.
 
 If desired, a cron script or some such could then be setup to go thru and 
 automatically assign anything that wasn't assigned yet and that hadn't 
 been touched (no comments asking for more info, etc) for some period, say 
 a week, just to catch anything that fell thru the cracks or if the 
 wranglers all disappeared or went on strike/vacation/whatever.  Then if 
 folks ever suddenly find themselves inundated with raw bugs, it'd be a 
 serious indication that the wranglers needed some help.

I like this idea.  It would address my concerns.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp0bZKY3L5NP.pgp
Description: PGP signature


Re: [gentoo-dev] [v3] Planning for automatic assignment of bugs

2008-07-01 Thread Mark Loeser
Robin H. Johnson [EMAIL PROTECTED] said:
 So this is now the third revision of this proposal. 
 
 The first two editions are available here.
 http://thread.gmane.org/gmane.linux.gentoo.devel/48485
 http://thread.gmane.org/gmane.linux.gentoo.devel/49601
 
 Comments are welcome, as are offers to implement it.
 
 Implementations should be a small python or perl script that take a
 single CP atom an resolve it to an assignee, along with one or more CC
 entries. They may assume that an rsync tree exists at $PORTDIR (not
 /usr/portage, but $PORTDIR). Additional data files are welcome as well
 for special assignment rules.

My main question to this entire proposal is do we actually want to give
bugs that possibly have no useful information to maintainers?  No script
will be able to replace people looking at a bug and trying to get the
user to supply information that will be useful for the maintainer of a
package.  The whole goal of the bug-wranglers project should be to
provide bugs to maintainers that they can actually do something with
when they receive them.  (Yes yes, you can say that this doesn't happen
all the time today, and you would probably be right, but that doesn't
mean we can't fix that problem.  A dedicated group of people that follow
guidelines that we set up for bug-wrangling should improve the quality
of bugs going to maintainers.)  Also, does anyone know of any other open
source project that does automatic assignment like this?  I'd be
interested to see how they implemented it and how it works for them.

Maybe no one else agrees with me, but I think auto-assignment might make
more work for people that don't want to deal with bugs that say:
sys-devel/gcc is br0ken!!! and provide nothing useful to help us
figure out the problem.  Its a good idea, but since our users don't
always provide useful reports, it seems like we are just shifting work
around.

Just my 2 cents,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpIGtI7janth.pgp
Description: PGP signature


Re: [gentoo-dev] Assigning bugs back to bug-wranglers@

2008-06-30 Thread Mark Loeser
Jeremy Olexa [EMAIL PROTECTED] said:
 On a side note: How is the b-w SOP doc coming? It is obvious to me
 the b-w is tedious a time consuming so I would like to help every now
 and then but I really am not sure about the rules wrt assignment just
 by looking at metadata.xml. IMO, b-w'ing is something that anyone can
 do.

I'm hoping to work on it later this week.  I have been getting
absolutely buried with projects at work recently, which has eaten up a
lot of my spare time.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpUmivu1sXLU.pgp
Description: PGP signature


Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009

2008-06-07 Thread Mark Loeser
Alex Howells [EMAIL PROTECTED] said:
 I wish to nominate a couple more people:
 
Halcy0n
tsunam
solar
robbat2
KingTaco
 
 All of whom should do a fine job, IMO.

Thanks.  I accept my nomination.  My platform is pretty simple, I want
Gentoo to get back to doing fun and innovative things.  If you are also
sick of all of the politics and want to take the no bullshit approach,
that's what I want to try to achieve.  We are all volunteers and there
is no reason to needlessly troll or bash other people's work.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp9jR4fBDVm7.pgp
Description: PGP signature


Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009

2008-06-07 Thread Mark Loeser
I nominate:

dev-zero
dirtyepic
zmedico

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpjvCUmiFCFy.pgp
Description: PGP signature


[gentoo-dev] Last rites: dev-cpp/libwrapiter

2008-05-21 Thread Mark Loeser
# Mark Loeser [EMAIL PROTECTED] (21 May 2008)
# Dead upstream and not used by anything
# Masked for removal in 30 days
dev-cpp/libwrapiter


-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpNKrGQ9RCE9.pgp
Description: PGP signature


Re: [gentoo-dev] Bug wrangling

2008-05-12 Thread Mark Loeser
Denis Dupeyron [EMAIL PROTECTED] said:
 That he comes back or not is of no importance to bug wrangling. Or at
 least it should be. It is a mistake to solely rely on a developer for
 such a task. Developers come and go without warning, he just proved
 it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also,
 one single developer handling this puts him/her in such a prominent
 position that it is bad for him/her, our users, other developers and
 the entire project. We had too many examples of this.

Making an actual bug wrangling team (subproject of QA) is something
I've been toying around with in my head.  I'd love to get an actual team
set up so we can encourage users to help us get the information we need
in bugs so it is less work for us.  Several other distributions have
such projects, so we have something we can use as a template.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpgsmBHX4PIH.pgp
Description: PGP signature


[gentoo-dev] Last rites: dev-libs/swl

2008-04-02 Thread Mark Loeser
It will be removed at the end of the month.

03 Apr 2008; Mark Loeser [EMAIL PROTECTED] package.mask:
  mask dev-libs/swl due to dead upstream and not working properly; bug
  #206163

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpNDyIfwz99Z.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild

2008-03-30 Thread Mark Loeser
Donnie Berkholz [EMAIL PROTECTED] said:
 On 17:26 Sat 29 Mar , Mike Frysinger (vapier) wrote:
  1.1  sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild
  
  file : 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1view=markup
  plain: 
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1content-type=text/plain
 
  local check base=${PORTAGE_CONFIGROOT}/etc/portage/patches
  for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
  EPATCH_SOURCE=${base}/${CTARGET}/${check}
  [[ -r ${EPATCH_SOURCE} ]] || 
  EPATCH_SOURCE=${base}/${CHOST}/${check}
  [[ -r ${EPATCH_SOURCE} ]] || EPATCH_SOURCE=${base}/${check}
  if [[ -d ${EPATCH_SOURCE} ]] ; then
  EPATCH_SUFFIX=patch
  EPATCH_FORCE=yes \
  EPATCH_MULTI_MSG=Applying user patches from 
  ${EPATCH_SOURCE} ... \
  epatch
  break
  fi
  done
 
 This looks like it should be generic code somewhere else.

Actually, I'd say this should just be removed.  If a user wants to apply
a patch, they can put their own ebuild into an overlay and do it
themselves (presumably if they want to patch something, they'll know how
to make the simple modifications to an ebuild).  By allowing the user to
arbitrarily patch something means we have no idea what the user has
built and is filing a bug about.  If they installed an ebuild from an
overlay it is a lot easier to identify what they built.  Sure, they
could patch the ebuild in their tree, but by supporting user supplied
patches easily in this way, we are encouraging them to patch things
without our knowledge.  If we start supporting this across the board, I
can see bugs being filed when their patches break and they don't
understand what is happening.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp00OFv13uhm.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

2008-02-19 Thread Mark Loeser
Doug Klima [EMAIL PROTECTED] said:
 As it's been explained to me by one of your fellow PMS developers, since 
 EAPI=0 is not complete yet, there will be no work on further EAPIs until 
 EAPI=0 is complete. Since this is the case and we still need to make 
 changes, we must revert back to the previous policy with regard to changes.

Just to clarify slightly:

I won't be working on anything other than EAPI=0.  Other people may be,
but the council said in the latest meeting that they feel we should get
EAPI=0 done before adding any new EAPIs to the tree.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp3y2lGk2cbz.pgp
Description: PGP signature


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

2008-02-13 Thread Mark Loeser
Mike Frysinger [EMAIL PROTECTED] said:
 This is your one-day friendly reminder !  The monthly Gentoo Council
 meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
 channel topic for the exact time (but it's probably 2000 UTC).

This is probably a bit late to be bringing up, but could the council
please discuss the state of PMS and EAPI?  What we mean by that is that
it seems we are using EAPI=1 in the tree, and some of us are concerned
because we can't find any council approved proposal of what EAPI=1
actually means.  It seems to be somewhat documented by bugs, but that
does not seem like nearly enough for a global change like that to be
introduced to the tree.  If you could also discuss how EAPI changes
should be introduced to the tree, like having a GLEP or something
similar, that would be nice as well.

Thanks (and sorry for the late notice),

Halcy0n, solar, and wolf31o2

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpQD4IA7V1hk.pgp
Description: PGP signature


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

2008-02-13 Thread Mark Loeser
Wulf C. Krueger [EMAIL PROTECTED] said:
 EAPI=1 approved for use in the main tree
 
 
 Stable portage version 2.1.3.12 supports EAPI=1. It's now officially OK 
 to start using it in the main tree. From the ebuild ChangeLog for 
 portage:
 
   This release is the first to have support for EAPI-1 (#194876), which 
   includes SLOT dependencies (#174405), IUSE defaults (#174410), and 
   ECONF_SOURCE support for the default src_compile function (#179380). 
   Package maintainers should carefully consider the backward compatibility 
   consequences before defining EAPI=1 in any ebuilds, especially if
   other packages depend on those ebuilds. See the ebuild(5) and emerge(1) 
   manual pages for EAPI related documentation.
 
 EAPI=1 features are documented in PMS as well as the man pages, but they 
 are not yet documented in the devmanual or the dev handbook.

Okay, so I stand corrected about them approving it.  Where is the
approved specification though?  PMS is still a draft the last time I
heard, and if it isn't, we should have a non-moving version that is
authoritive about EAPI=1.  (And no, the man pages are not a
specification, nor is a list of bugs...give us one document that we can
point to)

I can get it put into devmanual as soon as I can find the approved
authoritative source to base information off of.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpsrvHQTUf4T.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: Adding available as a mentor bit to LDAP

2008-02-11 Thread Mark Loeser
Donnie Berkholz [EMAIL PROTECTED] said:
 Given that, what I think is that people's willingness to mentor may 
 depend on the recruit. So you'd need more than a simple on/off bit, 
 you'd also need a maybe option.

And probably area's of interest should be part of it.  Even though I
have nothing to do with (just taking something random here) openmotif,
if someone wanted to come on board and maintain that, I'd certainly be
interested in mentoring them (same with anything that is lacking a
maintainer right now).

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpOz4gvUiae9.pgp
Description: PGP signature


Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

2008-01-19 Thread Mark Loeser
Tiziano Müller [EMAIL PROTECTED] said:
 
 Current state: Deferred
 Wanted state: Accepted/Implemented (at least by me)

Yea, this sounds like a good thing from reading over the GLEP, unless
I'm missing some glaring problems with it.

 Open questions from last discussion (March 2006):
 - Is it possible/should it be possible to have more than one maintainer
   entry?

Yea, agree.

 - Is recording an upstream-status (active/inactive) a good idea?
   Possibilities:
 An element: status{active/inactive}/status
 An attribute: maintainer status={active/inactive}...

Definately.  We have several packages in the tree that once they become
broken, we'd have to start developing ourselves.  This will help the
treecleaner project as well so they can tell if a package has several
open bugs and upstream is inactive, its a very good candidate for
getting booted from the tree.

 - Is an additional doc element needed to link to upstream docs

Sounds reasonable.

 - Must the type of remote-id be controlled/listed/checked?

I'd say we should come up with a good list to start with.  We can come
up with updates to the allowed values at a later date, but I do think we
should keep this under control.


-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpPXq07yrA1j.pgp
Description: PGP signature


Re: [gentoo-dev] Concerns about WIPE_TMP change

2008-01-18 Thread Mark Loeser
Stefan de Konink [EMAIL PROTECTED] said:
 How stupid anyone could be that stores anything in /tmp. I think it is a
 problem to change the default behavior of a system that in essence will
 result in data loss.

I think this might just be a communication problem.  You seem to be
contradicting yourself here by saying how someone could be stupid for
storing something, and then defending people that are doing something
you are admitting to be stupid and not logical.

 As pointed out by others you should not use /tmp to store data, my
 return question is then, why are the other ./tmp directories not wiped?
 If any ./tmp on a partition was 'kernel' governed I could agree that a
 semi-ramdisk would be gone upon reboot, or after an application was done
 running. But it is not.

Because according to the FHS (and common sense), files or directories in
/tmp should not be considered to be preserved.  /var/tmp on the other
hand is specifically for temporary files that should be preserved
between reboots.


 In any case my request would be to put a message with bells and beeps in
 the ebuild that cause the /etc/conf.d/bootmisc change announcing that by
 then the default option for /tmp is deletion on boot. To be consistent,
 also delete /var/tmp. If anyone thinks wiping /var/tmp is evil, please
 reconsider /tmp too. In my opinion WIPE_TMP should be in the same state
 as RC_PARALLEL_STARTUP. Unless anyone can make sure a user knows what he
 is doing, disable it.

Please refer to my explanation above as to why /var/tmp is different
from /tmp.

Should an elog statement been put into the ebuild...maybe.
I leave that up to the maintainer to decide what is important enough to
be logged, and they clearly thought this wasn't in this case.  But
bringing it up on this mailing list is atleast the correct place to get
a discussion going on what should be mentioned when we change default
configurations if that is your intention.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpDa8ODazvOL.pgp
Description: PGP signature


Re: [gentoo-dev] Re: USE flag documentation

2008-01-15 Thread Mark Loeser
Ryan Hill [EMAIL PROTECTED] said:
 Mark Loeser wrote:
 Ryan Hill [EMAIL PROTECTED] said:
 c) Allow flags from use.desc to also exist in use.local.desc.  In the 
 case that a flag for a package exists in both, the use.local.desc 
 description overrides the use.desc one.  This allows a more specific 
 per-package description of global flags.
 Still doing alright :)
 d) Allow long descriptions in a package's metadata.xml, as some have 
 begun to do already, for cases where more info is needed.  For example 
 I'd like to explain exactly what the bindist flag on freetype does and 
 what legal implications disabling it can have.
 Why can't this be done in use.local.desc?

 My expectation is that `grep flag use.local.desc` will give me a list of 
 packages using that flag (or having it in the description), one per line. 
 Putting paragraphs in there doesn't seem right.

One could argue that you can't do that currently for DEPEND strings and
such, so that seems like a possibly weak argument to me.  Just because
you can do something right now doesn't mean it was meant to be that way,
or shouldn't be changed to make things better :)

Either way, I would prefer (and I'm sure others will as well since it
will cut down on confusion) if we pick either use.local.desc or to move
them into metadata.xml.  Having it possibly be in both places just seems
silly.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpKNKGoZLuMg.pgp
Description: PGP signature


Re: [gentoo-dev] USE flag documentation

2008-01-14 Thread Mark Loeser
Piotr Jaroszyński [EMAIL PROTECTED] said:
 Tbh, I don't have any issues with the current solution, but I may be missing 
 something. Rationale doesn't seem to help though, afaics it is just saying 
 that the current behaviour  needs to be documented and fwiw PMS draft covers 
 this already:
 http://dev.gentoo.org/~spb/pms.pdf - section 3.4.3

Which is fine, but PMS is just a draft.  I'm trying to see if everyone
can accept one solution, instead of throwing things into metadata.xml
and into use.local.desc without the process being documented in one place.
This is more of a proposal to see if we should even change how we do things
today.  Maybe we shouldn't, and that's what I'm trying to figure out...

  http://dev.gentoo.org/~halcy0n/gleps/glep-0054.html
 
 Please, don't use an already assigned GLEP number, it's a bit confusing. Note 
 that 55 is taken as well.

It wasn't taken when I first sent it (as far as I know).  I forgot to
change before resending.  Thanks for reminding me.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpnYkNt4leuz.pgp
Description: PGP signature


Re: [gentoo-dev] Re: USE flag documentation

2008-01-14 Thread Mark Loeser
Ryan Hill [EMAIL PROTECTED] said:
 a) Keep use.desc as it is:  a list of common flags and a short general 
 description of their meaning.

Sounds good.

 b) Keep use.local.desc as it is: a list of per-package flags that are 
 specific to one to a few ebuilds (i think 5 is the number though i think 10 
 is more appropriate, but that's not relevant to this discussion).  Again, 
 each has a short description.

Also fine.

 c) Allow flags from use.desc to also exist in use.local.desc.  In the case 
 that a flag for a package exists in both, the use.local.desc description 
 overrides the use.desc one.  This allows a more specific per-package 
 description of global flags.

Still doing alright :)

 d) Allow long descriptions in a package's metadata.xml, as some have begun 
 to do already, for cases where more info is needed.  For example I'd like 
 to explain exactly what the bindist flag on freetype does and what legal 
 implications disabling it can have.

Why can't this be done in use.local.desc?

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpty7jvR7m5f.pgp
Description: PGP signature


[gentoo-dev] USE flag documentation

2008-01-13 Thread Mark Loeser
Here is a newer revision of the GLEP.  I still have multiple methods of
solving this problem (mostly because I want and *need* input from people
as to what they would prefer).  Please tell me what you would want to
use so I can come up with a more precise specification.  What exactly do
we need this system to do that we can't do now?  Is overriding the USE
flag with use.local.desc sufficient and we just need to document the
current solution properly?

Please...let me know how you feel about this.

http://dev.gentoo.org/~halcy0n/gleps/glep-0054.html

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp1cWKoQgE6v.pgp
Description: PGP signature


Re: [gentoo-dev] USE flag documentation

2007-12-31 Thread Mark Loeser
Alec Warner [EMAIL PROTECTED] said:
 One of the GLEP's primary goals is to provide a global use flag
 definition and over-ride
 it with a local definition.  How does putting all flags in use.desc
 and over-riding local flags in
 use.local.desc not accomplish this?

It does, and maybe that's what we should use instead?  The reason for
the email is to figure out if what we have now is good enough, or if we
should switch to something else.

 How does the glep intend to handle USE_EXPAND?

It doesn't say anything about them right now, but since you brought it
up...any ideas? :)

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpUIrolgzHPs.pgp
Description: PGP signature


Re: [gentoo-dev] USE flag documentation

2007-12-31 Thread Mark Loeser
Doug Klima [EMAIL PROTECTED] said:
 Marius Mauch wrote:
 What benefit does use.xml have over use.desc?
 My opinion is that we should use use.desc for a complete list of use
 flags, including a generic description, allow a more verbose
 description in metadata.xml and get rid of the stupid separation of
 local and global flags. No need to change the format of use.desc
 though.

 I completely agree with this. This allows each individual package to 
 provide more insight to what a USE flag does.

This sounds sane to me as well.  As I said, I'm just throwing ideas out
there to see what sticks :)

 The only benefit use.local.desc gives us is a fast way to list packages
 using some flags, but that's unreliable at best. If needed such a list
 could be autogenerated.

Completely agree.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpY4lku9pvmP.pgp
Description: PGP signature


[gentoo-dev] USE flag documentation

2007-12-30 Thread Mark Loeser
This is a very very rough draft/question about how we should move
forward with USE flag documentation and specification.  The entire idea
of a single USE flag having different meanings will need to be revisted
later.  I just want to get an idea of how we can document these
different meanings.  Please read my ideas here:

http://dev.gentoo.org/~halcy0n/gleps/glep-0054.html

Let me know if you like any of those ideas, or if they all suck (and if
they do, you better tell me why).  I'm not sure which is the best way
forward, which is why I want everyone to contribute towards the best
solution moving forward.  I really don't want to be stuck with something
that is going to end up being a pain a year down the road.

Thanks,

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgp5KMFB9dR0l.pgp
Description: PGP signature


[gentoo-dev] New-style virtuals LICENSE variable

2007-12-16 Thread Mark Loeser
Just to bring to a wider audience the discussion that we had on bug
#140180 [1].

While documenting new-style virtuals for devmanual we began to discuss
what the LICENSE variable for the virtual ebuilds should contain.  For
the reasons listed on the bug, we came to a conclusion that the LICENSE
variable should be empty for these ebuilds.

A brief list of the reasons:

* the ebuild doesn't really install anything
* the ebuild itself is already licensed under GPLv2 as is every
  other ebuild in the tree
* ACCEPT_LICENSE accepts an empty LICENSE, so the virtual is
  automatically accepted
* if the above were not true, we would have the fun maintainence
  nightmare of having to list every license that could satisfy the
  virtual in the LICENSE variable

So long as everyone understands this, I'll go ahead and commit the new
documentation to devmanual and ask zmedico to commit the repoman change
to make sure LICENSE= in the virtual category.

Thanks,


[1] https://bugs.gentoo.org/show_bug.cgi?id=140180
-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
web   -   http://www.halcy0n.com


pgpEHiB1YmrR7.pgp
Description: PGP signature


[gentoo-dev] New-style virtuals LICENSE variable

2007-12-16 Thread Mark Loeser
(Sorry for the spam g-dev, I forgot to send this to dev-announce as
well).

- Forwarded message from Mark Loeser [EMAIL PROTECTED] -

 Date: Sun, 16 Dec 2007 20:03:39 -0500
 From: Mark Loeser [EMAIL PROTECTED]
 To: gentoo-dev@lists.gentoo.org
 Subject: [gentoo-dev] New-style virtuals LICENSE variable
 User-Agent: Mutt/1.5.16 (2007-06-09)
 
 Just to bring to a wider audience the discussion that we had on bug
 #140180 [1].
 
 While documenting new-style virtuals for devmanual we began to discuss
 what the LICENSE variable for the virtual ebuilds should contain.  For
 the reasons listed on the bug, we came to a conclusion that the LICENSE
 variable should be empty for these ebuilds.
 
 A brief list of the reasons:
 
 * the ebuild doesn't really install anything
 * the ebuild itself is already licensed under GPLv2 as is every
   other ebuild in the tree
 * ACCEPT_LICENSE accepts an empty LICENSE, so the virtual is
   automatically accepted
 * if the above were not true, we would have the fun maintainence
   nightmare of having to list every license that could satisfy the
   virtual in the LICENSE variable
 
 So long as everyone understands this, I'll go ahead and commit the new
 documentation to devmanual and ask zmedico to commit the repoman change
 to make sure LICENSE= in the virtual category.
 
 Thanks,
 
 
 [1] https://bugs.gentoo.org/show_bug.cgi?id=140180
 -- 
 Mark Loeser
 email -   halcy0n AT gentoo DOT org
 web   -   http://www.halcy0n.com



- End forwarded message -


pgpWnxw422NtR.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007

2007-11-06 Thread Mark Loeser
Hanno Boeck (hanno) [EMAIL PROTECTED] said:
 hanno   07/11/06 01:01:35
 
   Modified: 4Q-2007
   Log:
   move beryl packages to their corresponding compiz fusion packages
 
 Revision  ChangesPath
 1.10 profiles/updates/4Q-2007
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?rev=1.10content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9r2=1.10
 
 Index: 4Q-2007
 ===
 RCS file: /var/cvsroot/gentoo-x86/profiles/updates/4Q-2007,v
 retrieving revision 1.9
 retrieving revision 1.10
 diff -u -r1.9 -r1.10
 --- 4Q-2007   3 Nov 2007 15:35:36 -   1.9
 +++ 4Q-2007   6 Nov 2007 01:01:35 -   1.10
 @@ -8,3 +8,10 @@
  move x11-apps/compiz-settings x11-apps/ccsm
  move x11-plugins/compiz-extra x11-plugins/compiz-fusion-plugins-main
  slotmove =app-emulation/emul-linux-x86-java-1.4* 1.4.2 1.4
 +move x11-wm/beryl x11-wm/compiz-fusion
 +move x11-wm/beryl-core x11-wm/compiz
 +move x11-plugins/beryl-plugins x11-plugins/compiz-fusion-plugins-main
 +move x11-plugins/beryl-dbus x11-plugins/compiz-fusion-plugins-extra
 +move x11-misc/beryl-settings-bindings x11-libs/compizconfig-python
 +move x11-misc/beryl-settings x11-libs/libcompizconfig
 +move x11-misc/beryl-manager x11-apps/ccsm

Just to get a wider audience involved in this...this just seems wrong to
do.  There is a QA bug open about it as well:
https://bugs.gentoo.org/show_bug.cgi?id=198248

What are other people's feelings on using package moves to forcibly
migrate people like this?  It also sounds like this wasn't announced at
all and the packages just left the tree.

-- 
Mark Loeser
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpXm4ASAsbex.pgp
Description: PGP signature


Re: [gentoo-dev] evolution of x86 stabling procedures

2006-06-05 Thread Mark Loeser
Grant Goodyear [EMAIL PROTECTED] said:
 I maintain very few packages these days, so it was quite a surprise to
 me today when I discovered that peer review is now effectively a part of
 the x86 stabilization process.  When I wrote GLEP 40, the problem that I
 was trying to solve was that of devs stabling packages without ever
 testing the package on an actual stable system (because most devs run
 ~arch).  As such, the language in GLEP 40 essentially suggests that devs
 could still stable their own packages, but only if they were properly
 testing the package on a stable system.  That policy has evolved over
 time to one where devs are actively discouraged from stabling their own
 packages, thereby ensuring that at least one other person examines and
 tests the ebuild before it becomes stable.  (I'm still not quite sure of
 the actual procedure, so I'm not sure how many people are generally
 involved in this peer review process.)  From a QA perspective, more eyes
 can only be a good thing, and this idea has been tossed around
 on-and-off for years.  On the other hand, peer review could potentially
 really slow things down, which is why we'd always rejected that approach
 in the past.  Are other arch's also requiring peer review?  Do we have
 any statistics or anecdotal evidence for what's improving, and whether
 or not anything is getting worse as a result?

Well, since you decided to bring this up on here, I guess we'll just try
to address everything.

I believe almost everyone has been happy with how the x86 team has
turned out.  I have only gotten positive feedback from people and users.
Despite that, we still have some devs, and *teams*, that don't follow
proper keywording procedures.

Peer review should be part of any stablization process.  The glep that
*you* wrote even provides for it:

For a package to move to stable, the following guidelines must be met:
...
* The relevant arch team must agree to it.

Maybe it was not what you intended, but we have not been slowing down
any process as far as I'm aware, since we get to our bugs as quickly as
we possibly can.  And every arch team has their own keywording policy.
I don't see why x86 can not have the poilcy that we decided on.  If you
have MIPS hardware and you mark something ~mips, I'm pretty sure they
will be pissed if they didn't give you prior permission.  Probably the
same for a few archs.

The x86 team has been asking for months now that everyone files a bug to
have their package stablized, and we allow maintainers to stablize their
package when it is impossible for us to do so.  I'm trying to figure out
why this is a problem all of a sudden, because things seemed to be going
just fine.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpOD1VY3Mhq5.pgp
Description: PGP signature


Re: [gentoo-dev] QA subproject, TreeCleaners

2006-06-03 Thread Mark Loeser
Alec Warner [EMAIL PROTECTED] said:
 I propose a new QA subproject, the TreeCleaners.

 Questions and Comments are welcome, as always.

This has my support.  Hopefully it will help us get rid of a lot of
cruft that hasn't been touched in ages and doesn't even work.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgp6Szf3Zvd7h.pgp
Description: PGP signature


[gentoo-dev] Last rites for media-libs/nurbs++

2006-05-29 Thread Mark Loeser
Upstream's last release for this package was in 2002, it doesn't compile
with gcc-3.4 (bug #120303), and hasn't had a maintainer for a long time.
Unless someone steps up to fix up this package, it will be punted in 30
days.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgp1dYzBd0FHP.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]

2006-05-29 Thread Mark Loeser
Alec Warner [EMAIL PROTECTED] said:
 So we created this awesome alias to put ebuilds that need a maintainer.
  Good idea at the time, decent idea still.  The problem?  We have nearly
 2000 open bugs assigned to maintainer-wanted[1].  I would like to
 discuss policy on these.  Do we keep them, do we get a group of people
 to slowly review and discard them?  Do we mind having a ton of things
 open like this (a quasi-ebuild db of sorts).  Is bugs the right place
 for this sort of thing, or can we improve somewhere/how?

Yea, the current situation has quickly turned into a mess.  I definately
think that QA should definately be watching
maintainer-wanted/maintainer-needed and helping clean up new ebuilds, or
removing old unmaintained packages that no one cares about anymore.  The
problem with maintainer-wanted is the pure number of possible packages
we *could* have in the tree, but no one wants to add.  After discussing
this briefly with antarus, I agree that it might be cool to write up our
own homebrewed app to handle this.

Basically, it would be something that allowed you to browse the current
tree of submitted ebuilds. This way users that submit something can
categorize it for devs to easily look for ebuilds they may be interested
in, and we can make it so we could easily grab the ebuilds from this hacked
up idea of a tree.  It would make it a lot easier to do automated checks
against submitted ebuilds for QA issues, and we would offload all of those
submissions from bugs.g.o to this app.  I guess you could think of it as
the overlays.g.o idea, but I tend to think overlays are experimental
things that aren't necessarily going to be added to the tree.  This
would be for ebuilds/packages that are ready to be added to the tree,
but just lack someone that wants to maintain them.

Comments on this idea are appreciated.  I wouldn't mind helping write it
and maintain it, but having interest and support in doing something like
this is definately going to be needed :)

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgp5aKA0jGhzU.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Devmanual

2006-05-25 Thread Mark Loeser
Jan Kundrát [EMAIL PROTECTED] said:
 Nice job. Are the XML and XSLT sources available from our CVS? I wasn't
 able to find them.

Not yet.  The Contributing page shows where it is currently hosted,
and I'm going to have it moved over to Gentoo infra soon.  I just
haven't gotten around to it yet :)

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpI9MDgupHFZ.pgp
Description: PGP signature


Re: [gentoo-dev] Don't filter --as-needed !

2006-05-23 Thread Mark Loeser
Mike Frysinger [EMAIL PROTECTED] said:
 mark should update his QA script to flag this as a maintainer is doing 
 something stupid

/me makes a TODO item to remember to try and get something work for this
soon

Basically, any sort of flag filtering is doing something stupid.  It
should just be a temporary measure to make it work until we can fix the
actual bug.  Sure, some are more complicated than others, but filtering
GCC flags, or whatever, only masks bugs that we should be fixing.
That's my belief on the flag filtering issue atleast.  I think we should
be trying to get bugs upstream to fix all of these issues.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpit1oZsBFqk.pgp
Description: PGP signature


[gentoo-dev] Last rites for dev-util/cvsutils

2006-05-18 Thread Mark Loeser
This package is currently without a maintainer and has open QA issues;
bug #123708.  It was marked as testing on every arch without being
tested and could really use someone to clean it up.  It will be booted
in 30 days if no one wants to keep it around.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgp4PXcAamgWx.pgp
Description: PGP signature


Re: [gentoo-dev] Paludis and Profiles

2006-05-17 Thread Mark Loeser
Matthijs van der Vleuten [EMAIL PROTECTED] said:
 I'd say that's exactly the intention of INVALID. If I were to file,
 say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be
 marked INVALID. (Unless, of course, the bug is caused by Gentoo's
 patches.)

No, I would get a testcase for the bug and file it upstream.  The only
bugs I've marked invalid are for the testing versions of GCC.

But, this is entirely off topic.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpyozy4RbMJI.pgp
Description: PGP signature


[gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

2006-05-17 Thread Mark Loeser
As the latest long thread has shown, there seems to be a split (it is hard to
tell exactly) on whether or not alternative package managers, that support
Gentoo ebuilds to some degree, should be added to the tree and supported.
Supported in this case means having their own profiles which may or may not
work with Portage.  There are currently a few different Portage rewrites, or
alternatives, whatever you want to call them, and all of them have their own
unique features being added to them which make them incompatible with Portage.
Some don't even emulate Portage's broken behaviour which could also cause
QA problems for us if we add the package to the tree.  If a package is in the
tree, it is implicitly stating that we are going to offer some level of
support for that application, and it increases workload for everyone that
may have an ebuild that works with one package manager and not another.

Therefore, I am requesting at the next Council meeting that they discuss
and decide on how we want to handle problems like this in general.  This
is not going to be the last time that someone wants to add their rewrite/
alternative of Portage to the tree.  It should be decided if it is really
in the best interests of Gentoo, its users, and developers to be adding
these new managers to our own tree, instead of having them host their
altered work on their own infrastructure.

As the QA lead, I am requesting that until the Council convenes and decides
on how we should proceed, that we not add anything else to the tree
for the sole reason of supporting another package manager's features.
This includes profiles or any other packages.  This will reduce
headaches for all of us, and hopefully cut down on needless arguments
that get us no where.

Thanks,

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpxCau7Apugg.pgp
Description: PGP signature


Re: [gentoo-dev] Paludis and Profiles

2006-05-17 Thread Mark Loeser
Stephen Bennett [EMAIL PROTECTED] said:
 Given the sheer volume of impassioned response, regardless of any
 technical arguments, I'm dropping the top-level profile idea for now.
 Several architecture teams have expressed an interest in creating
 sub-profiles under their own, however, and I'll be working with them to
 get those implemented. Perhaps I'll revisit the top-level idea at a
 later date when all the fuss has died down.

Sub-profiles are included in my statement in the other thread.  Please
hold off on adding or modifying *anything* until the Council has decided
on how we wish to proceed in handling situations like this.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpwU1pKAc0eY.pgp
Description: PGP signature


Re: [gentoo-dev] RFC - Gentoo Knowledge Base

2006-05-16 Thread Mark Loeser
Sven Vermeulen [EMAIL PROTECTED] said:
 A Knowledge Base provides answers to specific questions and problems that
 users (or developers) might encounter. It is easily searchable and
 maintained by developers who are knowledgeable in the topic. The knowledge
 base entries (topics as I like to call them) are not documentation guides,
 but very specific to a particular environment and question. They should
 leave absolutely *no* room for different interpretations.

I like it.  It would be nice to be able to point someone to a doc or
something when they file a bug about something they did wrong, and this sounds
like it would fill that void.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email -   halcy0n AT gentoo DOT org
  mark AT halcy0n DOT com
web   -   http://dev.gentoo.org/~halcy0n/
  http://www.halcy0n.com


pgpxbBF0qj8v3.pgp
Description: PGP signature


  1   2   >