[gentoo-dev] Re: making the stable tree more up-to-date
* 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
# 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
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
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
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
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.