[gentoo-dev] Re: making the stable tree more up-to-date

2011-11-23 Thread Torsten Veller 
* Paweł Hajdan, Jr. phajdan...@gentoo.org:
 Please review the list, it's 800+ packages so I thought about asking for
 feedback before filing stabilization bugs (I plan to do that in stages
 of course).

What do you expect to happen with bugs assigned to maintainer-needed?

I don't know if any of the packages is really good to be stabilized.
Maybe they are better than the current stable version, maybe not.

-- 
Regards Torsten

[gentoo-dev] Lastrite: dev-util/monodevelop-boo and dev-util/monodevelop-debugger-mdb

2011-11-23 Thread Pacho Ramos 
# Pacho Ramos pa...@gentoo.org (23 Nov 2011)
# Upstream stopped their development and support for a long
# time, they are not compatible with recent monodevelop versions.
# See bug #389473. Removal in 30 days.
dev-util/monodevelop-boo
dev-util/monodevelop-debugger-mdb



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Infra survey results

2011-11-23 Thread Gilles Dartiguelongue 

Le 28 sept. 2011 à 03:28, Alec Warner a écrit :

 Ok so Google Docs sucks and I can't give you the 'summary link'
 because it wants people to sign in and that is crap! But I can discuss
 the results:
 […]
 I'm happy that there is some progress on each of these items. I don't
 want to provide delivery dates but I will try and stay on top of them
 and post updates as we make progress.
 
 -A

Digging through old mail.
Thanks for your feedback.

-- 
Gilles Dartiguelongue e...@gentoo.org
Gnome team

Re: [gentoo-dev] rewritten epatch

2011-11-23 Thread Maciej Mrozowski 
On Friday 18 of December 2009 20:07:47 Mike Frysinger wrote:

   if (patch -p${count} ${EPATCH_OPTS} --dry-run -f  
${PATCH_TARGET}) 
 ${STDERR_TARGET} 21 ; then

Just FYI.
There seems to be a little 'problem' with this, as patch is validated in --
dry-run mode before applying, no .rej files are generated, thus the only 
feedback is hunk # that failed from ${T}/${patchfile}.out.

-- 
regards
MM


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] rewritten epatch

2011-11-23 Thread Mike Frysinger 
On Wednesday 23 November 2011 18:19:40 Maciej Mrozowski wrote:
 On Friday 18 of December 2009 20:07:47 Mike Frysinger wrote:
  if (patch -p${count} ${EPATCH_OPTS} --dry-run -f 
 ${PATCH_TARGET}) 
  ${STDERR_TARGET} 21 ; then
 
 There seems to be a little 'problem' with this, as patch is validated in --
 dry-run mode before applying, no .rej files are generated, thus the only
 feedback is hunk # that failed from ${T}/${patchfile}.out.

this is always how epatch has worked.  my rewrite didn't change that.

personally, i've never found .rej useful.  and the .out file tells you exactly 
what hunk failed, so i don't see a problem here.
-mike


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] restricting phases where enew{user,group} is allowed

2011-11-23 Thread Mike Frysinger 
currently we blacklist certain phases (which is largely based on EAPI=0 and 
blocking src_*) for enew{user,group}.  moving forward, ferringb suggested we 
invert this into a whitelist of allowed phases.

afaict, the blacklisting + dev documentation has done a good job of 
restricting calls to three places: pkg_{setup,preinst,postinst}.  so inverting 
the logic should largely be safe.  on the off chance it isn't, i think letting 
the ebuild `die` and getting it fixed up via bug reports is acceptable (i 
grepped through the tree a bit and looked sane).

moving beyond that, i'd like to also ban pkg_postinst usage.  the trouble with 
using this phase is that `die` isn't fatal because the package has already 
been merged to $ROOT, so there's no going back.  and while logically i can see 
that people might prefer pkg_postinst vs pkg_preinst (no point in creating a 
user/group if the pkg isn't actually yet merged), for all real world usage, 
there's no need to delay it, and it makes the ebuilds a bit more robust as 
errors get caught before things get merged to $ROOT.  i believe the 
documentation has always recommended pkg_setup and pkg_preinst anyways.

moving even beyond that, i'd like to update the documentation to push people 
to prefer pkg_preinst.  if your package doesn't require the user/group to be 
available at compile/install time, then there's no need to use pkg_setup.  
this improves the use case of attempting to install a package from source, 
things failing for whatever reason, and then the pkg is never actually 
installed, but the user/group is left behind.

any feedback before i implement ?
-mike


signature.asc
Description: This is a digitally signed message part.