Re: [gentoo-dev] GCC 4.6.* unmasked, 4.7.0 added to tree
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
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?
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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] Jeeves IRC replacement now alive - Willikins
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
Ł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
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
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@
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
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
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
# 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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++
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]
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
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 !
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
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
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)
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
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
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
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
Mike Frysinger [EMAIL PROTECTED] said: 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. I'd like GLEP 48 [1] to be voted on. Thanks, [1] http://www.gentoo.org/proj/en/glep/glep-0048.html -- 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 pgp7vJhlFQUYZ.pgp Description: PGP signature
