Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tuesday 24 February 2009, Petteri Räty wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. Thanks for opening a spot to voice our opinions within reasonable limits and without deadlocked discussions. To make it brief, I'd very much prefer 3c[0] for the reasons provided by others before: - From what I can see, it provides for all requirements set out by g55. - There is a backwards-compatible way to implement it. - It does not expose any more internal metadata than current ebuilds do. - I see no rush to implement new EAPI features that require drastic changes enabled by 1*. - It provides a constant face for Gentoo, aka we're the guys and gals using the .ebuild format. Robert [0] Although not with a fixed line limit, but with a strict way to find it, i.e. the first occurence of #?\s*EAPI=[']?([a-zA-Z0-9._]+)[']? or similar. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Sunday 08 March 2009, Tiziano Müller wrote: Hi everyone With eapis 1 and 2 we introduced nice features but also a couple of new problems. One of them are the use dependencies when the package you depend on doesn't have the use flag anymore (see [1] for an example). So I think it's time for a short eapi bump with some distinct improvements: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I'm not sure if you would like to discuss items to be added to the spreadsheet on this list first, but I accidently added default_src_install (bug 33544) to the list. I did not know it would store and share changes immediately. However, the proposed implementation on the bug does not follow the ideas of adding arguments to the default_src_* implementations (230725). Still, I think adding the default src_install function to EAPI=3 would be both trivial and an improvement for many simple ebuilds. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
On Saturday 21 March 2009, Markos Chandras wrote: Doing some research I found out that perforce-cli was in the portage back in 2006 but not anymore. Can somebody recall the reason why it is not there anymore? If it wasn't a license issue , I want to bring it back ( at least the client for now ). I am waiting your suggestions. Thank you Revisiting old bugs, it seems it was removed due to distfile collisions (same name, different content in several perforce packages): https://bugs.gentoo.org/123923 Since we have src_uri arrows now, this is no show-stopper. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
On Sunday 22 March 2009, Nirbheek Chauhan wrote: On Sun, Mar 22, 2009 at 2:58 AM, Alec Warner anta...@gentoo.org wrote: I think you will encounter namespace collisions, thats why I CC'd zac as he maintains mirror-dist ;p Why the hell didn't we think of this before!? :o The mirror-dist script *cannot* rename the upstream files for storage, since emerge will be looking for the *original* filename on the gentoo mirror. And if we keep them the same, we'll have collisions on the mirror, which is more probable (and severe) than a collision on a user's local DISTDIR. The easiest solution I can think of is for emerge to give special consideration to the mirrors in GENTOO_MIRRORS, and look for the renamed file there instead of the original ones. No reason to panic. :-) This is what Portage already does and what is specified in EAPI=2. Refer to the paragraph quoted by Ciaran earlier in this thread. Do we have a reason to believe our mirror scripts do not already handle this correctly? Because to me it seems they do. $ ebuild bashburn-3.0.ebuild unpack Downloading 'http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/distfiles/BashBurn-3.0.tar.gz' --2009-03-22 15:48:57-- http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/distfiles/BashBurn-3.0.tar.gz Resolving ftp.spline.inf.fu-berlin.de... 130.133.110.66 Connecting to ftp.spline.inf.fu-berlin.de|130.133.110.66|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 84435 (82K) [application/octet-stream] Saving to: `/usr/portage/distfiles/BashBurn-3.0.tar.gz' ... $ G ENTOO_MIRRORS= ebuild bashburn-3.0.ebuild unpack Downloading 'http://bashburn.dose.se/index.php?s=file_downloadid=3' --2009-03-22 15:49:12-- http://bashburn.dose.se/index.php?s=file_downloadid=3 Resolving bashburn.dose.se... 90.227.105.216 Connecting to bashburn.dose.se|90.227.105.216|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/octet-stream] Saving to: `/usr/portage/distfiles/BashBurn-3.0.tar.gz' Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Monday 23 March 2009, Tiziano Müller wrote: Spec needed. DOCS or no DOCS? DOCS, and non-empty default value, please [1]. Some eclasses already do this (not base, but others), and if that default doesn't cover it for you, the function can be overridden. Concerning the argument of declarative ebuilds vs. bash-oriented ebuilds brought up by Donnie: Our ebuilds always had declarative parts with an impact on the PM (e.g. RESTRICT), or on eclasses (WANT_AUTOCONF, or look at the games eclass). I think if we stay within sane limits[2], following this paradigm is going to help developers because more simple cases will be caught by the default implementation without adding the complexities of having to know tons of (aka more than one) variables and how they interact. Robert [1] As seen here: https://bugs.gentoo.org/show_bug.cgi?id=33544#c17 [2] That is very fuzzy, but we're talking about introducing one variable in one function. Any lower limit would be to disallow. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding
On Monday 30 March 2009, Thomas Sachau wrote:
Ciaran McCreesh schrieb:
So far, we've got this, by agreement of the Council:
* There will be a default src_install in EAPI 3
* It will have a DOCS variable, or something along those lines.
I'd like to suggest the following too:
* If DOCS is explicitly specified, it is an error if anything in it
doesn't exist.
* If DOCS isn't explicitly specified, it isn't an error if anything
in its default, if it has one, doesn't exist.
We don't have an implementation yet. So I'll start off with this:
default_src_install() {
emake -j1 DESTDIR=${D} install
Why do you want to force -j1 here?
And i had this proposal some months ago, which noone argued against
any more (the default list may of course be extended):
...
What Ciaran added was a way to disable installation of default DOCS. The
implmenetation we discussed on the thread a while ago does not check
whether DOCS is declared but empty.
I believe the way the DOCS variable is handled in the first example of
the thread starter is good for a default_src_install although I don't
know if we really need arrays. But why not? :-)
So what about this funcion for the next EAPI and also implementation
in base.eclass?
Why would you want to implement it in base.eclass when it's in EAPI=3? I
can't think of a case where inherit base would make things easier
than bumping to EAPI=3. In both cases, you might need to change logic
within your ebuild and test it.
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Project summaries - Alpha Arch Team
On Wednesday 06 May 2009, Tobias Klausmann wrote: I've been toying with the idea of offering something akin to Debians popularity contest tool. Some people are rather uncomfortable with data gathering tools that send stuff to some strangers, so I don't know how well it would work. I list this idea here, since I have just about no idea what actual alpha hardware is used with Gentoo out there. Knowing which packages are actually *used* (instead of just being stabilized for the heck of it) would be nice. Added benefit of that would be that users helping with testing would reduce workload. Hi Tobias, a late Happy Birthday from my side first. Note that we have a Summer of Code student this year who is working on a project to gather both hardware and software statistics from Gentoo users. If you have any special requirements for your platform, I am sure he has open ears. No need to invent two wheels at the same time. I'm putting Sebastian in CC directly, if you are looking for the project mentor, that is me. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The fallacies of GLEP55
On Saturday 16 May 2009, Ciaran McCreesh wrote: Have a look at every package using a MY_PV style thing. Group those into upstream's doing something dumb and upstream's being sensible but our arbitrary restrictions on rules means we can't follow what they do. I like the fact that our versioning rules are a fixed subset of the sum of all our upstream's versioning rules. It provides a more consistent user experience. As a user, I know it's always _rc and never -rc. Gentoo developers take care of mapping all upstream versions onto an easy-to-remember set of ebuild versions. The file extension change makes changing versioning rules possible. From a developer PoV, this might relieve me from fiddling with MY_PV. However, I have to take care of additional fuzz with file extensions (As pointed out by klausman). Bottom line: I see no gain for me as a developer, and a loss of consistency for users. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild From what I understand, the difference between 3 and 4 is that (4) would break pre-glep55 Portage versions that see an ebuild with no metadata cache present if the ebuild uses a future EAPI that introduces changes as described in the Current behaviour section. (4) would otherwise keep the current workflow the same except restricting the way the EAPI variable is defined in the ebuild. I would argue that most people who are be exposed to repositories that do not carry a metadata cache (overlays) which use new EAPIs also keep their portage version current. I'd say go with option (4) now and by the time EAPI 4 is collected, written up, agreed upon and implemented, enough time went by so we would not have to introduce an artificial delay. And after that, there won't be any delay to avoid breakage anymore. Robert signature.asc Description: This is a digitally signed message part.
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Monday 18 May 2009, Jeroen Roovers wrote: On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. I'm not following. Why should it be discouraged? I was happy with it until now. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Gentoo Support Everywhere
On Tuesday 19 May 2009, Jesús Guerrero wrote: On Tue, May 19, 2009 21:52, Dale wrote: Also, the link to your thread does not exist. I get The topic or post you requested does not exist. The project should be viewable. The forum post will only be visible for mods, admins and devs I guess, and only when loged in· There's nothing I can do about that. I get the same error (logged in). I don't know why it is restricted, but since you announced the thread as containing the rationale for the project, it was rather hard to follow the reasons. Thanks for stating them in the mail I am replying to. Do we need this to be a top-level project? I imagine this might live as a sub-project of the Forums TLP. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Baselayout 2 stabilisation todo
On Saturday 23 May 2009, Roy Marples wrote: Basically as Doug said, each OpenRC version comes with a few big chances. Well not massive as in your box will break now, but just a different spin on how things should work. OpenRC-0.5 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. If future changes of this magnitude are still expected, I wonder if we want to go stable with OpenRC anytime soon. I do not intend to hinder fast progress and design changes in OpenRC in any way, but if its design is not considered final, I suggest we do not make it the default recommandation for our users. Marking it stable might also be contraproductive for upstream since revised configurations need to stay supported a lot longer than they would had they been used only by ~arch users. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Monday 25 May 2009, lx...@sabayonlinux.org wrote: On Mon, May 25, 2009 at 3:43 PM, Alex Legler a...@gentoo.org wrote: On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. Yeah but emerge @overlay would be obviously illegal. So your argument is a bit pointless ;) # emerge --update lsof @system versus # emerge --update l...@system would have completely different meanings. This is what I would dislike about the '@' character. I'm ok with :: though. If we use repo_name as the overlay identifier, we must rethink how layman-global.txt is currently handled. Many overlays in there have that file missing, and some have different identifiers than what layman displays as their name. Is this specifier stored and considered on future dependency calculations (e.g. updates, dependencies of other ebuilds on the package that was installed via @overlay)? Where is it stored, how is it displayed to the user in emerge/eix output? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Monday 25 May 2009, Ben de Groot wrote: Robert Buchholz wrote: If we use repo_name as the overlay identifier, we must rethink how layman-global.txt is currently handled. Many overlays in there have that file missing, and some have different identifiers than what layman displays as their name. I think layman should simply start to use the repo_name as identifier. That should result in less confusion, I'd think. Overlays that miss the repo_name file are broken and should be fixed, and should be ignored until they are. Unfortunately, that value is not known until the repository is checked out. Doing that on every list operation would be too much overhead. We do need a script to verify the layman list, nevertheless. (Don't look at me for this! :-) Robert signature.asc Description: This is a digitally signed message part.
Gentoo Security Project Summary -- was Re: [gentoo-dev] Project summaries
Gentoo Security Project Summary Short Summary: The Security Team is up and running, but we are dealing with numerous tasks and a high load in daily maintenance. Fresh blood is not only appreciated, but needed to continue the luxury of Security Support we currently have. We have too many open bugs, too many undrafted GLSAs that are eventually sent too slow, and a lot of channels to monitor. There are some bugs that need extensive amount of work to be resolved. The Security Team is also developing applications to support our workflow and user's systems, such as improvements to glsa-check and our DTD, a new Ruby on Rails application to draft GLSAs and an application to coordinate Kernel security support and check local systems. == Personal changes == === Lead Election === Since the last election had been longer than a year ago, we held a new election during the first two weeks of May. It was determined unanimously that Pierre-Yves Rofes (py) and Robert Buchholz (rbu) will be the new French-German duo that is our Team Leads. We would like to publicly thank Raphael Marichez (falco) and Matthias Geerdsen (vorlon) for doing the job the years past. They were both not available for another term. === Additions to the team === Alex Legler (a3li) recently joined the Security Team. However we still need more people helping with the daily maintenance work. This call for help applies to both developers and users. For more details on how to join the Security team, see: http://www.gentoo.org/proj/en/security/ Or, more specifically: http://www.gentoo.org/security/en/padawans.xml http://www.gentoo.org/security/en/coordinator_guide.xml http://www.gentoo.org/security/en/vulnerability-policy.xml http://www.gentoo.org/security/en/bug-searching.xml == Maintenance == === Bugs and GLSAs === We have reached new highs in the number of open bugs and the length it takes all of us to resolve them. A shortness in Gentoo developers in general and on our team is leading to three issues: (1) Security bugs are not resolved by ebuild maintainers Some security bumps are staying open for weeks with teams not responding to pings. Even issues that could be resolved before being public (what we call embargoed bugs) are not resolved due to maintainers not being responsive on such bugs. In fairness, I have to note this is limited to only some herds and not architectures. Architectures and in particular their Arch Security Liaisons are doing their job in a reliable and timely fashion. (2) GLSAs are delayed We're slow! We are sorry. I feel this is a great disappointment especially in those cases where maintainers and arch teams are doing a fast job and we take 4 weeks to write the accompanying GLSA. I see potential for improvement with the GLSAMaker rewrite described below. Contributors to GLSA writing are greatly welcome. (3) Security Team is not resolving bugs either In the past, we have been conducting simple version bumps ourselves or have masked vulnerable ebuilds. Currently, doing other people's jobs in the security process is mostly on hold as we have a hard time struggling to cope with our part of the job. === Documentation update === We actually updated our existing documentation to reflect more of our security process. Isn't that awesome? Read our project pages to find out more: http://www.gentoo.org/proj/en/security/ === GLSA dtd and glsa-check === We have been discussing changes to the GLSA DTD for ages now. There's few people interested in the subject and I have been slacking on it. I have picked up glsa-check maintenance recently and we will announce changes to the DTD to the dev lists as soon as they are fully drafted. Since the GLSA format is supported in all package managers, the change will be announced at least 6 weeks before going live. Oh, and glsa-check will see some bugs fixed, I hope. And support for UTF-8. And support for mask-glsas. Hmm.. anyone else here to help? glsa-check changes in 0.2.4: http://sources.gentoo.org/viewcvs.py/gentoolkit/branches/gentoolkit-0.2.4/src/glsa-check/ glsa-check changes in trunk (0.3): http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/ New DTD proposals: http://git.goodpoint.de/?p=glsa-check.git;a=tree;h=refs/heads/glsa-2 == Feature extensions == === GLSAMaker === The GLSAMaker is a web application that we use to draft, comment on and refine GLSAs. It allows for the export of the GLSA texts and XML files you might know from gentoo-announce or /usr/portage/metadata/glsa. The application is considered helpful by all of us, however its shortcomings require to duplicate some work that could be automated and its usability makes working with it less fun than it could be and slows our work down quite a bit. Alex Legler (a3li) and Pierre-Yves Rofes (p-y) are currently working on a rewrite that covers the current functionality and extensions to ease the workflow dramatically by integrating metadata from Portage, Bugzilla, the CVE database and Secunia. We
[gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs
Hello, the Security Team would like to create a new DTD for our GLSAs. GLSAs are distributed via our web site and the tree. Their format is defined by a DTD. When the format was initially defined in 2004, some use cases were considered that never got implemented or used. Other use cases only came up later. For this reason, we want to update the GLSA for the needs of 2009. Since this includes changes that make existing GLSAs invalid we are going to introduce a new DTD called glsa-2.dtd. I would like to announce the changes we want to introduce. If you have any feedback, please speak up. This can include feature requests. After this discussion, we would like to freeze the DTD and ask all consumers of GLSA XML files (such as package managers) to implement said changes. The first GLSA using the new DTD will be at the earliest six weeks after the DTD was frozen. Once the new GLSA format is in use, we are going to convert some or all of the existing GLSAs to use the format. Find the existing DTD here: http://dev.gentoo.org/~rbu/glsa-2/glsa.dtd The new DTD here: http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd And a diff between them here: http://dev.gentoo.org/~rbu/glsa-2/glsa-2.dtd.diff Here's a list of changes: (-) Dropping of the product type. GLSAs will be used solely to announce security issues in the Portage Tree. The infrastructure and informational product type are not needed and the type attribute will be dropped altogether. (-) Dropping of service tag. Same rationale as above, if we drop infrastructure, we do not need the service tag. (-) Drop the 'name' attribute to unaffected. This is not implemented in glsa-check or Portage 2.2 and it was never part of our Policy to mix GLSAs with package moves or similar. (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' and 'unaffected' tag will be introduced. This limits the scope of the range specifiers to ebuilds in the specified slot. The default is '*' meaning all slots. [1] (+) Addition of a 'count' attribute to the 'revised' tag. We stop formatting revision dates as 'May 26, 2009: 03' and use 'revised count=32009-05-26/revised' instead. (*) UTF-8 support. We would like to release GLSAs containing UTF-8 characters in places where they make sense (that is, not package names, version information, etc.). Please check whether your tools support this. A GLSA XML file containing said changes, including UTF-8 characters, is up here: http://dev.gentoo.org/~rbu/glsa-2/glsa-200012-34.txt Robert [1] This does not allow for undefined situations if you employ the following algorithm: An ebuild is vulnerable if falls into any of the ranges specified by the 'vulnerable' tags unless it also falls into any of the ranges specified by the 'unaffected' tags. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: GLSA-2, a new DTD for GLSAs
On Tuesday 26 May 2009, Tiziano Müller wrote: Am Dienstag, den 26.05.2009, 16:19 +0200 schrieb Robert Buchholz: I would like to announce the changes we want to introduce. If you have any feedback, please speak up. This can include feature requests. Maybe add a 'tag' attribute to the reference link to give them a meaning, like: uri tag='upstream' link='http://bugs.samba.org/...'.../uri or keeping a table of tags in the XSL and replace it on transformation: uri tag='samba-bugs' id='1234'Upstream Bug 1234/uri not sure whether uri would be the right point for such stuff though. In 98% of all cases, these are either links to the corresponding CVE identifiers or previous GLSAs. The CVE identifier then features a list of references of different types, such as upstream bugs, patches, advisories. See this CVE id for example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4316 You will notice that some links carry machine-readable information such as DEBIAN:DSA-1747 and upstream bugs and the like are usually called confirm (such as CONFIRM:http://svn.gnome.org/...). With how we use our references, we could define three types of elements: uri link='', cve id='' / and glsa id='' / The latter two could then be transformed to either URIs or local links (say, in applications displaying the content). After this discussion, we would like to freeze the DTD and ask all consumers of GLSA XML files (such as package managers) to implement said changes. The first GLSA using the new DTD will be at the earliest six weeks after the DTD was frozen. Once the new GLSA format is in use, we are going to convert some or all of the existing GLSAs to use the format. I wouldn't do that since a properly written tool should be able to handle both versions anyway. That is true. I was referring (at least) to existing GLSAs that can benifit from added slot support that we must keep updated by hand today. Also, I think there were issues with the date formatting in current XML files and how they are displayed on our site. (+) SLOT support. An implied attribute 'slot' to the 'vulnerable' and 'unaffected' tag will be introduced. This limits the scope of the range specifiers to ebuilds in the specified slot. The default is '*' meaning all slots. [1] I don't think this is really a good idea since the version may or may not be tied to a slot (at the moment it is in most cases I know). I'm not following -- maybe we had a misunderstanding. The slot attribute is additional to the tag, but its value is implied as '*' if it is not specified. This is what we have today (from GLSA 200804-20): package name=dev-java/sun-jdk auto=yes arch=* vulnerable range=lt1.6.0.05/vulnerable unaffected range=ge1.6.0.05/unaffected unaffected range=rge1.5.0.15/unaffected unaffected range=rge1.5.0.16/unaffected unaffected range=rge1.5.0.17/unaffected unaffected range=rge1.5.0.18/unaffected unaffected range=rge1.4.2.17/unaffected unaffected range=rge1.4.2.18/unaffected unaffected range=rge1.4.2.19/unaffected /package This is would imply the following (in glsa-2): package name=dev-java/sun-jdk auto=yes arch=* vulnerable slot=* range=lt1.6.0.05/vulnerable unaffected slot=* range=ge1.6.0.05/unaffected unaffected slot=* range=rge1.5.0.15/unaffected unaffected slot=* range=rge1.5.0.16/unaffected unaffected slot=* range=rge1.5.0.17/unaffected unaffected slot=* range=rge1.5.0.18/unaffected unaffected slot=* range=rge1.4.2.17/unaffected unaffected slot=* range=rge1.4.2.18/unaffected unaffected slot=* range=rge1.4.2.19/unaffected /package And (thank god!) should be equivalent to: package name=dev-java/sun-jdk auto=yes arch=* vulnerable slot=* range=lt1.6.0.05/vulnerable unaffected slot=* range=ge1.6.0.05/unaffected unaffected slot=1.5 range=rge1.5.0.15/unaffected unaffected slot=1.4 range=rge1.4.2.17/unaffected /package Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Apache herds needs your help
On Monday 08 June 2009, Benedikt Böhm wrote: Hi all, currently I am the only active developer in the apache herd, but quite busy with work and life, so I'd like to ask all of you to fix bugs assigned to apache-bugs@ if you come across them/if they annoy you etc, since i cannot keep up with bugs currently. I'd also like to see more active members in the herd as well in the future, so that bugs can be resolved in a reasonable time again. If you're interested, feel free to add yourself to herds.xml and join #gentoo-apache. I would like to raise special attention to the open security bugs: http://tinyurl.com/apache-security Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
On Monday 08 June 2009, Maciej Mrozowski wrote: ... While it usually doesn't do any particular harm (but I guess security and prefix/alt team won't agree on this) - insanely enabling everything by default is not the best idea in my opinion. The Security Team supports all use flag combinations, even those not enabled by default. Masked use flags are not supported. As far as proactively disabling certain codecs go, that certainly exploits of certain (disabled) codecs. However, if the user was tricked into downloading a file and will see that he cannot play it due to a missing codec, he might just enable that use flag and rety. The only way to be safe is to minimize the untrusted input to your application, keep it updated, and employ other means of hardening (privilege separation). Of course we need an example. Let's have a look at latest stable media- video/mplayer-1.0_rc2_p20090322 ebuild: ... Personally I'd really like to hear some explanation from maintainers about the reasons mplayer needs all those dependencies or why they are *really* recommended for every user of *any* profile (let me remind this). You should see the list of referenced bug reports in the ChangeLog for an explanation: https://bugs.gentoo.org/show_bug.cgi?id=260588 As stated there, all internally supported codecs are enabled, and only very few default USE flags require external deps. But thats's not the point - the point is, Gentoo probably needs some policy to advise, when some newly added USE flags are appropriate to be enabled by default. I suggest as follows: - When newly added USE flag makes already provided feature optional - needs to be enabled by default (this is required to make package feature set somewhat invariant after update) - When newly added USE flag adds new feature that is considered very common (that's tricky part and decision should be always made by herd, not individual developer) *but* *does* *not* *pull* *any* *dependencies* - enable by default - in any other case *do* *not* *enable* by default - (why? because I use it so I'll enable it by default is not enough of an explanation) What's the opinion on that? I guess we need some policy or at least some suggestion mentioned in devmanual - really.. I am in favor of applying common sense (hah!). An application (and an OS, in general) in the default config should run the common use cases, and some more. It's just as easy to remove a use flag as it is to enable it. And personally, I hate having to enable USE=png on all my desktop machines so I can use a desktop background. Just as much as I hate downloading some video and realizing I forgot to add USE=schroedinger for mplayer, and then wait for a recompile before the fun. Robert signature.asc Description: This is a digitally signed message part.
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
On Saturday 13 June 2009, Sebastian Pipping wrote: One of the stronger points for collaborating at the source is that poeple who are not Gentoo devs (yet) and therefore have no write access to the Gentoo tree can still extend and fix the Gentoo packagemap entries. Doing it downstream would hurt the whole project in several ways. To drive the project forward and find cross-distro acceptance, the packagemap repo/server has to be the authorative source of information for distributions that participate. However, I see advantages in a distributed model to collect the information. Gentoo developers could feed cpe tags into the metadata.xml of the tree and do not need to sign up to commit to the third-party packagemap repository. Synchronizing changed tags to the packagemap repository should be easy to automate. Changes in the repository could be propagated back to the tree by a designated team of Gentoo developers interested in the packagemap project. I have a feeling other distributions might also favor a model where they have more control about the data without giving all their devs access to one big repo. Robert signature.asc Description: This is a digitally signed message part.
Re: [packagekit] [gentoo-dev] Inviting you to project PackageMap
On Monday 15 June 2009, Sebastian Pipping wrote: However there are a few more things to take into account, please have a look at my reply to Paul: http://lists.alioth.debian.org/pipermail/popcon-developers/2009-June/ 001759.html Sorry for not CC'ing you, I should have though of that. Thinking the other way around: Is there anything we could do to make the central place approach work and feel better for everybody? The consumers of the PackageMap will always only use the central database. It is only the populators of the database that would be distributed. I am convinced the project will be more viable if people can choose their level of contribution. Many developers just won't care enough to take the extra hassle. If you make it easy enough for them to contribute to the CPE mapping, i.e. update their debian/controls or metadata.xml, they will (or not :-). Other developers that care more can then extract the data and merge it at the database and do extra maintenance tasks such as updating the substition map. If you make merging easy, I don't see how this hurts the project. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
On Sunday 12 July 2009, Fabian Groffen wrote: since I assume you can't reliably use the checked out version of the overlay (by e.g. layman), can you try to retrieve the repo_name file from the overlay? Probably a lot of efforts. So alternative, what if we extend the layman-global.txt (which is xml in reality...) file with an extra property per overlay which holds the contents of it's repo_name? Would be optimal, since you're fetching this file anyway to check it. Alternative is to use another file somewhere on the interweb that you keep up to date automatically, by having all overlays checked out and recording their repo_name ... I think it should be a requirement that repo_name == layman name for an overlay to be added to layman. If that file changes later, we should see a warning *somewhere*. It is a perfect opportunity to revisit the overlays+metadata cache idea presented by patrick a while ago (and do other overdue changes!). Since writing down stuff into an IDEAS file in my $HOME does not get anything implemented, and I'm still looking for a way to have a wiki-like lightweight GLEP (which I prefer for collecting ideas), here's what I have so far: Background: Overlays are useful, fast-moving playground for inclusion of new ebuilds and distributed community effort. layman-global.txt is the central list of overlays Issues: 1. In layman-global.txt: 1. has no DTD/xml validation schema 2. overlays have only a contact address, no real name 3. overlay name in xml file might not be overlay's repo_name 4. Exactly one overlay URL, no mirrors possible 2. overlays.g.o website: 1. Feed is out of date 2. Only lists dev and proj overlays, not third-party 3. Has no overlay content index 4. Has no overlay search 3. Overlays do not have metadata 4. Overlays are not natively supported by package manager, but through an external app and a 'source' in make.conf Ideas: 1. Revamp layman-global.txt, keep it as authority file: 1. Move file to overlays.xml (but keep a compatibility copy) 2. Create XML DTD/schema to make it validatable 3. Change 'official' attribute to differentiate between 'dev', 'proj' and '3rdparty/unofficial' 4. Add value for overlay RSS feed if available 5. Add real name for owner 6. Have multiple overlay URIs with checkout priorities 2. Write script to generate planet config from overlays.xml 3. Have copies of the overlays on official gentoo.org infra, generate metadata for them and export them via rsync (the bonsaikitten proposal at http://thread.gmane.org/gmane.linux.gentoo.devel/62025/ ) 4. Validate repo_name vs. XML file (needs 3.) 5. Move search and browse features to overlays.g.o website, see: 1. http://git.exherbo.org/summer/ 2. http://gpo.zugaina.org/ 3. http://gentoo-overlays.zugaina.org/ 6. Extend layman to use one of many overlay URIs or allow user select Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Wanted: Stats collection (not submission!) testimonials
On Sunday 12 July 2009, Tobias Klausmann wrote: Interestingly, my cross-compile alpha setup (created using crossdev) is noticed as a secret package - I presume that is on purpose? That's an interesting phenomenon that pops up with both g-cpan and crossdev, because they generate new ebuilds. I don't know how crossdev works in detail, but g-cpan will create ebuilds in the first overlay in PORTAGE_OVERLAYS -- if that is a public overlay, the stats client will report them. If it has a private or no repo_name, the stats client will not do that. I would assume crossdev generared the ebuilds in a private overlay? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
On Sunday 12 July 2009, Sebastian Pipping wrote: Robert Buchholz wrote: 1. has no DTD/xml validation schema I'd like to be part of the schema creation process but feel that having pre-mature schema's on the list and it's archives is not a good idea. It's probably wise not to discuss the specifics of that file on this list, but keep experimentation in a smaller group. I wonder if a new mailing list is needed or whether we just do this over the overlays alias. If we had a schema file: where would we store it? Possibly here: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/dtd/ Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: 14 X input drivers
On Monday 13 July 2009, Rémi Cardona wrote: Le 13/07/2009 16:56, Marijn Schouten (hkBst) a écrit : All have in common that they've been broken (in portage) for many months and no-one noticed until Sabayon folks started doing tinderbox builds :) We're using the x11-drivers/xf86-input-microtouch for a cash register. It works fine, but I think the machine is still on Xorg Server 1.3. I don't have the capacity to maintain this driver myself, but it seems bug #276615 has a patch, so I wonder why it needs to be abandoned. Whom exactly shall I contact upstream about the deprecation? Thanks, Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool
On Thursday 23 July 2009, Sérgio Almeida wrote: You changedir, you call uprofile, and voila, new profile. You login again, default profile. Most shells have the ability to execute a command when a new prompt is generated. Users do not need to call uprofile themselves, they could set up their ~/.*shrc to do this. For zsh (and tcsh), you can define a function: chpwd Executed whenever the current working directory is changed. precmd Executed before each prompt. Note that precommand functions are not re-executed simply because the command line is redrawn, as happens, for example, when a notification about an exiting job is displayed. For bash, you can set a variable: PROMPT_COMMAND If set, the value is executed as a command prior to issuing each primary prompt. You could utilize this to call uprofile, have it output environment variables and set them in the shell environment. A portable (bug ugly, code wise) way would be to do this as part of the PS1 variable. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] autobuilds and the current* symlinks
On Sunday 09 August 2009, Robin H. Johnson wrote: In the wake of bug #279260 that continues to break the ISO builds, I've restructured the symlinks under releases/$ARCH. Previously with autobuilds, we only have one symlink, current/, at the same level as autobuilds. Now there are two [1] convenience symlinks, pointing to symlinks of the same name inside the autobuilds directory. Inside the autobuilds directory we have: - one or more MMDD directories - current-iso symlink to actual date. - current-stage3 symlink to actual date. - latest-iso.txt - latest-stage3.txt If a spin fails to generate an ISO or stage3, that won't be considered for updating the symlink. Example for x86: The last successful spin with an ISO was 20090623. The last spin for stage3 was 20090804. current-iso - 20090623 current-stage3 - 20090804 Why not flip the directory structure around and handle it similar to what we do with the portage snapshots on the mirror? At each architecture directory, have one iso and one stage3 or stages directory, and put the autobuilds in there. Their filenames make them easy to sort and we can have one latest symlink for each set of files. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Multimedia overlay
On Tuesday 11 August 2009, Maciej Mrozowski wrote: On Tuesday 11 of August 2009 11:08:34 Robert Buchholz wrote: In my opinion, the entrance barrier for devs is lower on git.overlays, there is no signup, password, mail verification required. There's scripts to keep the ssh keys in LDAP and on git.overlays in sync, and people can just request access to at overl...@g.o and usually get it done within 24 hours. Except usually it takes much longer than 24 hours (like over a month in my case). No, thank you. Please do not generalise from your case. I do not have the history back when your key was added, but the last mail dates I could correlate to gitosis commits draw a different image: 2009-07-29: dev overlay creation, 80 minutes lag 2009-07-23: user key change, 27 minutes lag 2009-07-12: user added, 17 minutes lag 2009-06-09: user key change, 18:50 hours lag 2009-06-07: project overlay creation, 14:28 hours lag 2009-05-18: user key added, 14 minutes lag If you need something, mail overl...@g.o and if no one replies within three days, mail again. And if you still encounter shortage of time, sign up to be a dev and help out. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stats test server running, please check it out
On Wednesday 12 August 2009, Sebastian Pipping wrote: cvs Missing documentation, but valid, see make.conf.example split-debug This is probably invalid. preserve-libs splitdebug unmerge-logs These are documented in Portage 2.2 make.conf(5). Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-19
On Wednesday 19 August 2009, Duncan wrote: FWIW, It'd be useful to know about @system packages as well, particularly portage, I'd guess, and there's likely others. AFAIK smolt depends on portage ATM, but the particular versions installed and percentage for each could be /very/ helpful as more people run smolt. There's definately interesting numbers in the packages people have installed that are not in the world file. Judging from the page Sebastian prepared a table Non-world-file packages, which can list other ebuilds. The table cannot list all packages anyone has installed, but maybe a selected number of ebuilds. Another interface (query form, sql export, or regular custom reports) could then allow maintainers to query for specific packages or combinations. And is there an anonymous ID number or other means taken to ensure that a user that reports daily is going to refresh his own stats, but not crowd out the guy reporting monthly or quarterly? Yes, the client associates its submits with a uuid it stores locally, and the server will update the client's profile (deleting the old data). How often /should/ we update? Every time we sync and finish our routine updates? Only once a quarter? Fedora (where Smolt originated) recommends people to submit once a month using a cron entry. But that was back when Smolt only supported Hardware and OS statistics (that change less often). Maybe a weekly schedule is more appropriate in Gentoo? I think the Fedora people will kill us though for the increased server load as they run the official receiving server (they currently have 100 000 people submitting each month). Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of Python 3.1
On Sunday 20 September 2009, Arfrever Frehtes Taifersar Arahesis wrote: Some packages (whose older versions might be stable) might soon start requiring Python 3. Stabilization of these packages cannot be delayed due to the fact that some other packages don't work with Python 3. Of course they can. That is exactly the reason I am using a distribution (instead of LFS), because I expect maintainers of packages to coordinate and define a working set of packages for me to use. This includes holding back updates, fast-tracking updates, forward- and backward-porting. Automatisms in updates and blindly following upstream removes that extra value we are there to provide. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] layman-global.txt, repositories.xml, layman, overlays.gentoo.org
On Thursday 01 October 2009, Tiziano Müller wrote: Am Mittwoch, den 30.09.2009, 18:17 +0200 schrieb Sebastian Pipping: Ciaran McCreesh wrote: Sure. Just periodically fetch the repository centrally. Have a master list of sync URLs with expected repository names, and use that to generate the full master list that includes metadata. Added bonus: you can quickly remove any repository that no longer exists. How long do you want the time frame for add-meta-data-or-get-kicked to be? If half the repos don't not make it will kicking them help anybody? Yes, then they're not maintained. And unmaintained overlays tend to contain even more broken ebuilds than others. There are plenty of unmaintained overlays. Keeping them in our index allows everyone to use what is still usable, and develoers to pick up maintenance. Removing them from the index makes it harder to do this. I guess what you want to do is keep unsuspecting users safe from these overlays, and the quality levels (i.e. graveyard in this case) are there to serve this purpose. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Saturday 24 October 2009, Maciej Mrozowski wrote: Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. (From your email) I fail to see the advantage as other commenters have pointed out. What problem is there that cannot be solved using dependencies and kde/gnome use flags? This decision just seems to increase the split between KDE and Gnome and that does not reflect user's realities: They use both. Gnome desktop + kmail, k3b, yakuake or KDE with evince, etc. Why add one more decision to make where the result is unclear (and honestly, profile documentation is almost zero)? Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] g15 and freevo up for grabs
Hello, I want to drop maintenance for some of the packages that I have acquired over the years. Some of them are still co-maintained, some are now unmaintained. === Freevo === Freevo is split up in different Python components. They are all maintained by a herd, but a dedicated maintainer is needed. media-tv/freevo# media-tv herd dev-python/kaa-base# python herd dev-python/kaa-display # python herd dev-python/kaa-imlib2 # python herd dev-python/kaa-metadata# python herd dev-python/pynotifier # python herd == G15 tools === These packages are now without a maintainer: app-misc/g15macro app-misc/g15message dev-libs/libg15render media-plugins/audacious-g15-spectrum app-misc/g15mpd app-misc/g15stats # already maintainer-needed These are maintained by Chainsaw: app-misc/g15composer app-misc/g15daemon dev-libs/libg15 Most g15 tools are part of the LCD herd. Since that is only actively myself, it does not help. I will replace the herd association in four weeks if no new maintainer steps up or a new g15 herd is formed. Otherwise the lack of maintenance is just hidden. Thanks, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Marking bugs for bugday?
On Tuesday 02 March 2010, Sebastian Pipping wrote: On 03/02/10 20:28, Nathan Zachary wrote: This looks like overkill to me. One keyword should be enough, and for supplementary information Status Whiteboard could be used. I agree. Simply having the BUGDAY keyword should be sufficient, and more information can be provided elsewhere in the report. If more than one keyword is commonly considered overkill I would at least request the whiteboard for it: somewhere in the report involves more than zero searching for it. Some people use the whiteboard for their own marking of bugs (e.g. security, and myself). If you add more information in there, you might be breaking other people's marking / sorting algorithms. I'd say one keyword BUGDAY is enough. Any bug editor can set and remove it and the bug history will show who set and removed it when. Sorting any syntax is taken care of by Bugzilla that way. It seems to me problem you seem to try to solve (review of bugs) can also be tackled with tools displaying new bugs that have the keyword set and just removing the keyword. If bugs are repeatedly spammed with BUGDAY comments, talk to the spammers or leave a comment. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] commit reviewing ... new list or keep it on -dev ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.09.2007 um 01:33 schrieb Mike Frysinger: ive been sending private e-mails as i didnt want to make a lot of noise, but many of the comments i make i imagine would be applicable to a lot of people ... i also see others doing reviews and such /me also likes reading them on this list. If anyone wants to filter them, procmailing [gentoo-dev].*[gentoo- commits] will do. Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG73cvyZx3L/ph1soRAidUAJ4hw+RE26wq1vaR5MHEaV2wdL9KjwCfeXzB ldFjS6tBKxjBLEd8SJz68AE= =Wpdu -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/linuxtv-dvb-apps: ChangeLog linuxtv-dvb-apps-1.1.1.20070924.ebuild
On Tuesday, 25. September 2007, Donnie Berkholz wrote: On 20:04 Mon 24 Sep , Doug Goldstein (cardoe) wrote: if ! use usb; then sed -i util/Makefile \ -e '/ttusb_dec_reset/d' \ -e '/dib3000-watch/d' fi # do not compile test-progs sed -i Makefile -e '/-C test/d' You might want to die if these seds fail. I already wondered a while back: sed only fails if the file does not exist, but not if there was no replacement. Is there any way to force it to? Regards, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Bugzilla improvements
On Thursday, 27. September 2007, Robin H. Johnson wrote: On Thu, Sep 27, 2007 at 03:05:28PM +0300, Olivier Cr?te wrote: Is this really required? It pushes the real content even farther down the window. Or if you really want to keep it for new users, please allow us to disable that. Bugzilla does not generate the mail once per user, but rather once and then send it multiple times, so no, I can't customize it per user. Is it possible to display the text only once when blocking bugs change? Especially because of the please visit in the middle isn't followed by a link. Here's how it looks: 8888 DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=186030 Secure: https://bugs.gentoo.org/show_bug.cgi?id=186030 DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person whose email is mentioned below. To comment on this bug, please visit: Bug 186030 depends on bug 193737, which changed state. Bug 193737 Summary: media-gfx/imagemagick-6.3.5.9 breaks external apps - libgomp.so.1: shared object cannot be dlopen()ed Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=193737 Secure: https://bugs.gentoo.org/show_bug.cgi?id=193737 8888 Regards, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new-style virtual/editor
On Friday, 5. October 2007, Olivier Crête wrote: On Fri, 2007-05-10 at 11:46 -0700, Donnie Berkholz wrote: How many packages depend on virtual/editor? Should it be a virtual at all? Tester_ !rdep virtual/editor jeeves virtual/editor - app-admin/sudo sys-process/fcron I think the answer is none that really should, I would favor just removing virtual/editor. A lot more applications need it, see subversion and cvs, which invoke $EDITOR. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new-style virtual/editor
On Sunday, 7. October 2007, Alec Warner wrote: On 10/7/07, Robert Buchholz [EMAIL PROTECTED] wrote: On Friday, 5. October 2007, Olivier Crête wrote: On Fri, 2007-05-10 at 11:46 -0700, Donnie Berkholz wrote: How many packages depend on virtual/editor? Should it be a virtual at all? Tester_ !rdep virtual/editor jeeves virtual/editor - app-admin/sudo sys-process/fcron I think the answer is none that really should, I would favor just removing virtual/editor. A lot more applications need it, see subversion and cvs, which invoke $EDITOR. I think you missed the train when someone mentioned we put an editor in system, thus making one always available. I thought this discussion was going into a direction that had the system dependency removed. I guess I was mistaking. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: dev-php5/pecl-pdo*
On Thursday, 4. October 2007, Christian Hoffmann wrote: # Christian Hoffmann [EMAIL PROTECTED] (04 Oct 2007) # Outdated (no releases since May 2006), buggy and possibly vulnerable # to security problems Anything security-related you know of or just a wild guess? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild
On Thursday, 4. October 2007, Josh Sled wrote: Wolfram Schlich [EMAIL PROTECTED] writes: * Donnie Berkholz [EMAIL PROTECTED] [2007-10-03 19:12]: On 12:43 Wed 03 Oct , Wolfram Schlich wrote: And *please*, don't send such mails to this list *and* to my address in addition. You can add a procmail rule to detect duplicates using a cache and checking Message-Id, with formail. Examples of this are all over the place. It's a useful rule to have for many reasons besides this. Yeah, but it's unpredictable *which* one of the two mails makes it first onto my system, thus the one *not* sent to the list might Sigh. It is the same message, addressed To/Cc: you and/or the list, no matter which one is delivered first. So just put all list(+private) filtering before personal filtering. That doesn't work when filtering for List-Id headers which can be nicely used with regex matching like so: # Gentoo lists :0 * ^List-Id: .*[]gentoo-\/[^.]+ .gentoo.gentoo-$MATCH/ Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: dev-php5/pecl-pdo*
Am 08.10.2007 um 10:05 schrieb Christian Hoffmann: On 2007-10-08 at 05:37 +0200, Robert Buchholz wrote: On Thursday, 4. October 2007, Christian Hoffmann wrote: # Christian Hoffmann [EMAIL PROTECTED] (04 Oct 2007) # Outdated (no releases since May 2006), buggy and possibly vulnerable # to security problems Anything security-related you know of or just a wild guess? Not exactly a wild guess, I just didn't want to make a statement on whether these are security problems or not: * INFILE LOCAL option handling vs. open_basedir or safe_mode * A crash inside pdo_pgsql on some non-well-formed SQL queries (both from php-5.2.4 ChangeLog) Since the second is only locally invoked* DoS and the first an ever-beloved workaround for the basedir restriction, we don't need to say goodbye with a maskglsa. Thanks, Robert * unless someone allows remote users to submit SQL queries... :-) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New staff : Elias Pipping (pipping)
On Saturday, 27. October 2007, Denis Dupeyron wrote: It's my pleasure to introduce Elias Piping (pipping) who is joining us as staff. He will do general development and bug solving for the Gentoo/alt project. Elias is familiar with Tcl, Ruby, Python, Perl, Java, sed, awk and bash. He admits having above average knowledge of regular expressions, and I suspect that should be read way above average. He has previously contributed to the MacPorts project. Elias studies mathematics in Berlin where he has always lived as he doesn't like to travel. He doesn't have a TV and reads only programming-related books. He enjoys english and frequently goes to the movies. Please everybody, give a very warm welcome to Elias. Welcome to the Berlin conspiracy. You owe me a beer now! Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: USE flag transition: tetex and latex
Am 07.11.2007 um 14:09 schrieb Ferris McCormick: On Wed, 2007-11-07 at 09:13 +0100, Alexis Ballier wrote: Hi, Yes, we should introduce tex, latex and kpathsea USE flags. Anyone? +1 for latex kpathsea. How/when do we start ? :) I'd say start moving useflags on a per package basis, making them local for now. Once there are enough, let us move to a global one. Once this is finished, let us deprecate the tetex useflag. +0.5 for tex: it's a good idea, but I dont know about any package using only tex and not latex (and where it would be optional). Perhaps I'm wrong there. I don't think documentation using texinfo.tex (the documentation that comes in .texi files) uses latex --- I believe that texinfo.tex uses just plain tex. Do we even provide plain tex via an ebuild or useflag? If not, why bother to differentiate? Robert -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: pam_console
# Diego Pettenò [EMAIL PROTECTED] (15 Nov 2007) # Masked for security vulnerability, see bug #199193. # Will be removed on December 15th 2007. sys-auth/pam_console (in case of replies, please keep Diego in CC) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] scm package version suffix
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
Why not just have something like
sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
2) It will break updating from the feature branch, once you installed:
sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1
and
sys-devel/gcc-4.2.4
comes out, it'll update to that, regardless of the inclusion of
${BRANCHNAME}'s feature.
Regards,
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] scm package version suffix
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
Why not have them block each other such that only one branch can be
installed at a time? There can be no concept of upgrading between
branches since they all have different features.
That would still mean everything relies on n ebuilds with mutual blocks.
Even if that would work and it block upgrades, it is still not a
solution in terms of how to display a list of ebuilds in one tree in an
ordered list.
2) It will break updating from the feature branch, once you
installed: sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1
and
sys-devel/gcc-4.2.4
comes out, it'll update to that, regardless of the inclusion of
${BRANCHNAME}'s feature.
Well, first off, most cases will assume that the branch has been
merged by 4.2.4. Secondly, if the branch has not been merged, and is
continuing independent of the releases, why give it a version number
at all? Just call it sys-devel/gcc-scm_b${BRANCHNAME}-r1
You are right. But this just shows that named feature branches do not
fit the context of this GLEP, as you usually cannot know when a feature
will be merged at the time one version is branched.
Regards,
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Improving use.desc
On Friday, 4. January 2008, Donnie Berkholz wrote: On 14:59 Wed 02 Jan , Mike Kelly wrote: While you're at it, I think almost everything in desc/video_cards.desc, desc/input_devices.desc, and a few more, could use some attention. In particular, things like nv vs. nvidia are quite confusing. I usually end up reading the xorg-server ebuild when I want to makes sense of it, which defeats the point of video_cards.desc altogether. Are there any programs (make.conf / USE editors) that manage to read and set that stuff? By read, do you mean read the setting from make.conf or read the description? If the latter, quse reads it. $ quse -D nvidia local:nvidia:gnome-extra/sensors-applet: Enable support for nvidia sensors local:nvidia:sys-power/cpufreqd: Enable nvidia overclocking (nvclock) plug-in video_cards.desc:nvidia: VIDEO_CARDS setting to build driver for nvidia video cards Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Seeking questions for a user survey
On Monday, 14. January 2008, Robin H. Johnson wrote: Ok, so per the one discussion in #-dev this evening, I'm looking for questions to put on a new user survey. For style of questions, multiple choice (both pick-one and pick-many) or simple integers would be best. However some freeform questions are probably going to end up in there anyway. 'Prefer not to answer' and 'I don't know' should be available in most questions. I don't have the original questions on hand right now (but i'm trying to get them), so used some classical census questions. Some of the ones I threw in are just what came to mind, I'd love to hear more questions and more sections. Just some ideas: Usage of Gentoo Services (could be differentiated between read only and have an account) - Forums - Bugzilla - Planet Larry - Mailing Lists (more differentiated) (for read-only) - Planet Gentoo - Gentoo *ly Newsletter - Handbook - Other Docs - Security Announcements (GLSA) -- maybe: If so, how? (Forums, Website, RSS, Announce List, glsa-check) - External Gentoo-related sites: - Gentoo-Wiki.com - ...? * Do you use overlays? (If so, which?) Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] retiring + looking maintainers for sendmail, tenshi, scapy, ftester
On Wednesday 06 February 2008, Andrea Barisani wrote: Hi folks, I'm retiring. Sorry to hear that. I was maintaining the following packages: app-admin/tenshi (note: I'm upstream as well) mail-mta/sendmail net-analyzer/scapy net-analyzer/ftester (note: I'm upstream as well) sys-apps/systrace is in need of love too, and has open bugs. But maybe we should just toss it away? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New keyword monkey: Kenneth Prug (ken69267)
On Saturday 08 March 2008, Petteri Räty wrote: Joining us from the zoos of Florida, we have Kenneth keninsert random numbers here Prugh. Ken did such a fine job testing all those random packages for amd64 that it will be the sole purpose of his life from now on. He tells me his hobby is to learn new programming languages so I guess he doesn't get bored easily. Time for the usual spanking everyone. Another one breaking our precious and outdated amd64 stable tree. Now stop reading and get working! Oh, and great to have you on the team. Rob signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work
On Tuesday 18 March 2008, Robin H. Johnson wrote: As the Bugzilla admin, this sounds reasonable, and it plays into some of my plans wrt to Bugzilla3. In that, depending on some bits with Bugzie3, I'd like to consider a radical re-arrangement of Products and Components, to help users find the right place to file stuff, and also reduce some of the needless complexity that we have. As a short-list quickly on products: - Demote the 'Bugzilla' product down to a component under the 'Infrastructure' product. - Demote 'Mirrors' to a component under 'Infrastructure'. - Promote the components under 'Gentoo Hosted Projects' to Products of their own, to enable them to have their own components (I can see several of them benefiting from this). - Merge the Admin product to the Infrastructure product. Can you add deleting the Security component in the Gentoo Linux product to that list? Thanks, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)
On Monday 21 April 2008, Santiago M. Mola wrote: On Mon, Apr 21, 2008 at 9:01 PM, Samuli Suominen [EMAIL PROTECTED] wrote: # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked for removal in 30 days. Doesn't build # wrt bug 178036 and has open CVE-2007-4773 wrt # security bug 203195. sys-apps/systrace -- gentoo-dev@lists.gentoo.org mailing list http://www.citi.umich.edu/u/provos/systrace/systrace-1.6e.tar.gz 1.6e solves the security problem. Just in case someone wants to fix it. I remember I tried bumping to 1.6e to fix the security bug, however it also does not compile and I had no intention to look into why. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thursday 08 May 2008, Doug Goldstein wrote: Additionally to follow myself up, I believe one of the security issues was execution of arbitrary data either when untarred or just decompressed (assuming a specially crafted lzma file). Can you please point me to the location where this is mentioned. I read through the lzma git log, and I all I could find was data corruption (which usually is not a security issue) and the mention of the word security inside the announcement. Thanks, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: new 'virtualization' project or herd
On Friday, 16. May 2008, Tiziano Müller wrote: Mike Auty wrote: As one of the primary vmware devs, I'm not sure that vmware easily fits into this group based on it's closed-source nature, and the complex (but just about workable) module system we've put in place. I also wouldn't want to muddy the virtualization email address with all the random vmware module bugs... 5:) I'm pretty happy for the vmware group to go under the virtualization herd, but I'd very much like to maintain the vmware email alias/assignment for bugs, and I'm not sure how much we'd be able to integrate with the larger group. Do you think it's worthwhile vmware joining the umbrella or should we just stay separate? That's true. How about having a virtualization project which takes care of the common part, the docs and the coordination (if any) and have separate herds for larger subprojects? I have to agree here for the Xen part. One big alias for all packages will only jam up everybody's mailbox. So we keep the existing herds (vmware, xen) and maintain common packages such as libvirt under a super-herd. Question is what happens with the packages that are not part of any herd yet (such as virtualbox, qemu)? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-05-18 23h59 UTC
On Monday 19 May 2008, Robin H. Johnson wrote: Removals: ... dev-libs/libsigcx 2008-05-14 11:43:18 uid2153 Why was the username screwed up here? Judging from bug 191855, it was Remi who deleted it. Also, do we need the mail cross-posted to both -dev and -dev-announce? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] VCS repository overview for Gentoo
On Friday 30 May 2008, Robin H. Johnson wrote: This is more of a reminder email than anything else, in my capacity as the VCS administrator for Gentoo. Thanks a lot for the overview, especially the part about public/private repositories. It would be great if this list could be maintained as parts of the infrastructure project docs. I can convert to xml if necessary. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc-2.8 / gcc-4.3 build failures
On Monday 09 June 2008, Mike Frysinger wrote: it seems packages are failing when built with glibc-2.8 and/or gcc-4.3. these are issues in the package, not the toolchain. previous versions were lazy and included API bleeding which packages took advantage of. with these newer versions, things bleed less means those packages break. some common examples: - code not including limits.h yet using defines from it - code using GNU-specific features but not defining _GNU_SOURCE for it - maybe some other stuff please refrain from assigning to toolchain. if you have questions, feel free to ask. -mike Just for reference, there are the following tracker bugs for ebuilds failing with either of the two. Please mark build failures as blockers of those. # [tracker] GCC 4.3 porting https://bugs.gentoo.org/show_bug.cgi?id=198121 # [TRACKER] ebuilds failing to build against sys-libs/glibc-2.8 https://bugs.gentoo.org/show_bug.cgi?id=225459 Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Merging or overwriting KEYWORDS from eclass
Hi, I've stumbled upon an inconsitency between package managers the other day [1], which was due to both an ebuild and an eclass defining inconsisting KEYWORDS. bla-1.ebuild: inherit myeclass KEYWORDS=~arch myeclass.eclass: KEYWORDS=arch Portage will resolve this by overwriting the variable, so the last (~arch) wins. Paludis, on the other hand, merges the variables, so it is KEYWORDS=~arch arch. The PMS draft [2] defines that IUSE, DEPEND, RDEPEND and PDEPEND variables be merged when defined in both eclass and ebuild (Section 7.2), but only says May be defined in an eclass about KEYWORDS (Section 8.2). Anyone up to toss a coin whose bug it is, and maybe we can have a more specific wording in the PMS? Robert [1] http://trac.pioto.org/paludis/ticket/586#comment:10 [2] http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Friday 01 August 2008, Chrissy Fullam wrote: Debian did exactly the same a couple of months ago prior to them moving out to OFTC (http://www.debian.org/News/2006/20060604) This addresses a question I raised a few days back regarding whether we were concerned that Gentoo moving to any another network would have a negative impact on our community. This demonstrates that not only is this not a new idea, but that a peer community did the same thing. Does anyone have any contacts within Debian that would be willing to share their 'lessons learned' from the transition? I don't know if this counts as a lesson learned, but their move seems to have lead to a split. All documentation since 2006 points to OFTC, but #debian on freenode is still the largest channel, whereas even developer channels have to be maintained. It looks to me as if most developers accepted the move, while users did not. number of users (as of Sat Aug 2 14:30 CEST 2008) ~irc.freenode.net irc.oftc.net #debian 826 326 #debian.se183 #debian.de 128 124 #debian-devel 41 353 #debian-boot 6 89 Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Tuesday 19 August 2008, Mark Loeser wrote: I am not sure how we would be able to enforce this across the board for forcefully retired developers. If we are talking policies, can someone please define the term 'forecefully retired'? What about people whom had been complained about to devrel, and who then resigned? Does it include people who are retired due to inactivity? What benifit does this proposal have over an enforcement of the CoC on retired developers? If they choose to stay part of our community, any misbehaviour can also be penalized using that document. If they choose to stay and contribute properly, why ban them? I'm happy about all bugs I get, even by the most evil compile persons. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Friday 05 September 2008, Fernando J. Pereda wrote: On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote: David Leverton wrote: 2008/9/5 Zac Medico [EMAIL PROTECTED]: Both approaches are essentially equivalent but it's a little simpler for ebuild writer if they don't have to customize the output file name. But is it so much simpler as to justify adding a special gitweb-specific hack to the package managers? Well, it's not much different from the existing file extension logic that's already built into the unpack function. I think what really matters is whether or not the majority of people see it as a useful extension. I'm wondering why would one fetch a tarball instead of using git.eclass which is much better for both upstream and users (in terms of bandwidth and resources usage). How is using the eclass better for bandwidth usage? It won't allow for mirroring, and all users would have to checkout the repository from one place. Furthermore, you cannot have (signed) Manifests that allow integrity checks. I wonder if that is an issue in gitweb in general: Will it generate the same tarball every time? If not, that will create issues with users not using gentoo mirrors, or the mirroring system itself (because the dev could commit a Manifest for another file than the server delivers later). For what it's worth, I also see no reason to double functionality for one special case where we also create a solution for the more general one. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] EAPI 2 Draft
On Friday 05 September 2008, Mike Auty wrote: From what I understand of the idea, the eclass will just change the SRC_URI field from the first case (sf=tgz) to the second case (-). Eclasses have to be sourced before the SRC_URI is determined because they can already add (and presumably alter) elements of the SRC_URI variable. So I'm not sure how this would directly affect mirroring or manifests any more than simply using the - notation? Could you explain what you mean when you say it won't allow for mirroring? I was under the impression ferdy meant to use live checkouts instead of tarballs. I might have misunderstood that. Generating different tarballs is much more of an issue, and would impact on manifests too. I guess it's a try-it-and-see situation... I think it would be a better idea to check whether this feature actually works before implementing. I just don't know a gitweb site that tars up revisions / tags to test. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] One-Day Gentoo Council Reminder for September
On Thursday 11 September 2008, Ciaran McCreesh wrote: On Wed, 10 Sep 2008 23:43:54 -0700 Zac Medico [EMAIL PROTECTED] wrote: [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html By table 6.11, are you implying that you consider the new pkg_ phase order to be part of EAPI 2? Really, Portage needs to revert the order and go back to the way it used to be for all EAPIs. The change breaks lots of existing ebuilds (you claim you've probably fixed everything in ::gentoo, but you don't know that and you've definitely not fixed overlays), including ebuilds using a common documented technique recommended by the devmanual. If you want the new pkg_* ordering to go through at all, it really needs a lengthy discussion on its own and it mustn't apply to any action that involves any existing EAPI. I'd like the Council to say that for anything involving EAPIs 0, 1 or 2 we stick to the pkg_* phase ordering we've used years. What is the change of order you witnessed in table 6.11 of the draft? Comparing that to the PMS on [3], the order looks identical to me (except for the two new phases). Am I missing something? Robert [3] http://dev.gentoo.org/~coldwind/pms.pdf Section 10.2 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
On Tuesday 23 September 2008, Thomas Sachau wrote:
Ulrich Mueller schrieb:
And I still don't see why we would need the most general solution
for a *default* function. There's always the possibility to write
your own src_install() for the few ebuilds that need it.
Ulrich
I aggree with Ulrich in this case. This is just a suggestion for a
default src_install funcion, nothing that should cover every possible
case. So if you have some special DOC that does not work with the
default install, you can still do it the normal way. So my suggestion
for a default src_install:
default_src_install() {
if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
if emake DESTDIR=${D} install || einstall ; then
die install failed
else
if [[ -n ${DOCS} ]]; then
dodoc ${DOCS} || die dodoc failed
fi
fi
fi
}
Any more comments? Good? Bad? Interested?
Let's go with an even simpler default implementation:
default_src_install() {
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR=${D} install || die emake install failed
fi
if [ -n ${DOCS} ]; then
dodoc ${DOCS} || die dodoc failed
fi
}
It addresses the following issues:
* Do not run einstall if emake fails
* Run dodoc even if no Makefile is present, this might come in handy for
ebuilds calling default()
* die dodoc failure case
* hopefully fix the flaws (not really) pointed out by zlin
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
On Sunday, 5. October 2008, Ulrich Mueller wrote:
On Tue, 30 Sep 2008, Petteri Räty wrote:
dodoc ${DOCS} || die dodoc failed
This seems alright fine to me
It's not. If you want to have default DOCS then you should loop
through the items and check with [[ -e ]] before trying to install
them.
I'm not convinced that this is a good idea. Then you won't catch cases
where upstream removes or renames files.
Besides, dodoc already checks for -e by itself (and emits a warning if
the file does not exist).
So, maybe just do a 'dodoc ${DOCS}' and omit the die? Then it won't
fail but the warning message would be preserved.
I understood Petteri's comment to be related to the default case (i.e. the
else-branch), and I have to agree there: Ebuilds that do not override
src_install should not emit a warning when some ChangeLog file is missing
that the ebuild never specified to install.
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI
On Sunday, 5. October 2008, Ulrich Mueller wrote:
On Sun, 5 Oct 2008, Robert Buchholz wrote:
It's not. If you want to have default DOCS then you should loop
through the items and check with [[ -e ]] before trying to
install them.
So, maybe just do a 'dodoc ${DOCS}' and omit the die? Then it won't
fail but the warning message would be preserved.
I understood Petteri's comment to be related to the default case
(i.e. the else-branch), and I have to agree there: Ebuilds that do
not override src_install should not emit a warning when some
ChangeLog file is missing that the ebuild never specified to
install.
The default would be an empty DOCS variable, or did I miss something?
Correct.
So if the ebuild includes non-existing files in DOCS, then why would
you want to suppress the warnings?
I don't. My point was that the default action on an empty DOCS variable is
to dodoc AUTHORS ChangeLog NEWS README, and this should not emit
warnings, because it is merely a heuristic.
To be clearer:
else
-# No die here because we don't know if any of these exist
-dodoc AUTHORS ChangeLog NEWS README
+for x in AUTHORS ChangeLog NEWS README; do
+if [ -e ${x} ]; then
+dodoc ${x} || die dodoc ${x} failed
+fi
+done
fi
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)
On Sunday 05 October 2008, Thilo Bangert wrote:
Ciaran McCreesh [EMAIL PROTECTED] said:
On Sun, 5 Oct 2008 03:44:20 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:
Either we need special cases to declare that it no longer has a
homepage, or we need to allow the empty HOMEPAGE.
HOMEPAGE=( )
HOMEPAGE=http://this-package-has-no-homepage.gentoo.org/;
Why not use our package site for this, i.e.
HOMEPAGE=http://packages.gentoo.org/package/${CAT}/${PN};
i.e. for this particular use case,
http://packages.gentoo.org/package/app-mobilephone/smssend
The site contains a link to ChangeLog, description, current version,
forums and bugs. I would suggest it is the most usable homepage a user
can expect if no other exists.
Robert
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
Hello, currently, PMS section 10.1 states: Some functions may assume that their initial working directory is set to a particular location; these are noted below. If no initial working directory is mandated, it may be set to anything and the ebuild must not rely upon a particular location for it. Please consider the following addition to this paragraph: The ebuild can rely that the chosen initial working direcotry is a trusted location that is not world-writable and owned by a privileged user and group. This change affects all pkg_ functions. Rationale: This feature presents a security hardening to work around vulnerabilities in ebuilds and applications called by ebuilds, and the Gentoo Security Team considers this the official solution to bug 239560 / GLSA 200810-02. I would like: * everyone to comment on the change and propose changes to the wording * council to vote on this change to EAPI-0, -1 and -2. Portage implements this in 2.1.4.5 and 2.2_rc12, Paludis in 0.30.2. I have not heard back from Brian on pkgcore (because this issue has been disclosed to him on a really short notice). Thanks, Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On Monday 13 October 2008, Ciaran McCreesh wrote: On Mon, 13 Oct 2008 10:42:21 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: It seems to me that this is an EAPI=0 change. Since EAPI=1 and EAPI=2 are just differences to EAPI=0, they wouldn't be voted on. Since EAPI=0 isn't actually approved yet, council wouldn't vote either. As it's a draft standard, this would be resolved amongst package-manager developers and PMS editors. It's a retroactive change to EAPI 0 that requires changes from package managers and has security implications... Robert isn't requesting that we specify and mandate existing behaviour here, so it's not really something that should be left up to PMS to decide and enforce. All package manager developers have implemented this change, and PMS editors have not objected to adding it to the spec. If Ciaran is uncomfortable with adding this change, I would like council to sign off on it. If council will not add this to the agenda, please state so and I hope the PMS folks can add it to the spec without a vote. Furthermore, what are the blockers to vote on PMS as a draft standard for EAPI=0 ? Is there a timeframe for its ratification? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
On Sunday 19 October 2008, Robin H. Johnson wrote: Now into it's Nth great year, I bring you the fourth edition of the automatic assignment proposal. /truman-show Yay! 5. Javascript then appends the server results into the Additional Comments box: a suggested assignee and suggested CC values, with logic as to why. 6. The wrangler can copy and paste the data into the fields, editing further as desired. It would be nice if we had a checkbox Accept Changes or of that Suggest button would fill in the fields itself. Two more copy and paste actions less. 2. If the summary line contains a package atom for a package that does not exist, but a category that does exist, use the metadata.xml for that category. We have three alternatives here: If at least one valid atom is found, but other atoms are present that only have an existing category... (1) ignore metadata for that category (2) treat category as regular metadata (3) append categtory metadata to the end of maintainer list For example, dev-java/ibm-jkd-bin breaks with x11-base/xorg-server-1.3.0.0 With the typo in ibm-jdk-bin, the ordered list of maintainers to assign/cc would* be (1) [EMAIL PROTECTED] (2) [EMAIL PROTECTED],[EMAIL PROTECTED] (3) [EMAIL PROTECTED],[EMAIL PROTECTED] * if java herd maintained dev-java category 3. If a maintainer element contains the non-default 'ignoreauto=1' attribute AND a non-empty role element (describing why this maintainer should not be contacted), delete it from the list. The role element is not present for maintainers in metadata.xml, only in herds.xml. Should we leave this out, or do you mean the description element? 1. For handling herdno-herd/herd, we should add an entry into herds.xml to catch it (maintainer-needed at g.o). Every herd listed in an ebuild MUST be in herds.xml. I agree for consistency reasons, the no-herd should be listed on herds.xml. However, it should not implicate maintainer-needed, as a lot of maintained ebuilds carry no-herd and all maintainer-needed ebuilds carry a [EMAIL PROTECTED] maintainer in their own metadata.xml Effects on metadata.xml syntax == - Category metadata is now permitted to have herd and maintainer elements. - New attribute under maintainer, 'ignoreauto'. Just to add a rationale here: This entry is used to assign / cc to ebuild submissions, i.e. Add dev-perl/Some-CPAN-Module to the tree could figure out [EMAIL PROTECTED] automatically. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI change: Call ebuild functions from trusted working directory
On Friday 17 October 2008, Robert Buchholz wrote: On Monday 13 October 2008, Ciaran McCreesh wrote: It's a retroactive change to EAPI 0 that requires changes from package managers and has security implications... Robert isn't requesting that we specify and mandate existing behaviour here, so it's not really something that should be left up to PMS to decide and enforce. All package manager developers have implemented this change, and PMS editors have not objected to adding it to the spec. If Ciaran is uncomfortable with adding this change, I would like council to sign off on it. If council will not add this to the agenda, please state so and I hope the PMS folks can add it to the spec without a vote. Furthermore, what are the blockers to vote on PMS as a draft standard for EAPI=0 ? Is there a timeframe for its ratification? Has this been discussed in the last council meeting? If not, can you please give a reply for the questions above? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] bugs.g.o supported overlays should register
On Saturday 03 January 2009, Robin H. Johnson wrote: On Fri, Jan 02, 2009 at 11:50:07PM -0600, Jeremy Olexa wrote: So you are asking for the layman file to be updated properly or what? layman -i overlay name As a start: 1. How about somebody actually taking ownership of the layman.txt file for changes? I've seen a couple of emails come to overlays@ asking about the file, without answers. As far as I know, any dev can commit to the file. I've been meaning to answer the requests, but I was afk over the holidays. 2. Include bug tracking details in the layman file or other overlay listing. Good idea. Keeping a second list around with all overlays is just one more place to update. Do we want/have an extra product or component in Bugzilla as well (for all overlay issues)? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] bugs.g.o supported overlays should register
On Saturday 03 January 2009, Jeroen Roovers wrote: On Fri, 02 Jan 2009 23:50:07 -0600 Jeremy Olexa darks...@gentoo.org wrote: So you are asking for the layman file to be updated properly or what? I specifically didn't go into the minor technical details (of files and formats and so on) and described a basic process. Currently there is no well-defined process, and frankly, 1) I don't use layman since it hates the locations where I keep repos, 2) the implicit connection between layman and overlays is lost on me, and 3) where is that layman.txt file kept anyway (I'd like to have a look at it)? It's in the gentoo CVS repository under the overlays project, i.e.: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/overlays/ It is then exported to: http://www.gentoo.org/proj/en/overlays/layman-global.txt I think the filename ending in txt might have something to do with the web server processing xml files as guidexml, but renaming it to be something like overlays.xml would be preferable IMO. We'd also need to create a proper DTD for it (I was looking for that earlier today, without success). Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
On Sunday 19 October 2008, Robin H. Johnson wrote: Now into it's Nth great year, I bring you the fourth edition of the automatic assignment proposal. /truman-show Previously: http://thread.gmane.org/gmane.linux.gentoo.devel/48485 [v1] http://thread.gmane.org/gmane.linux.gentoo.devel/49601 [v2] http://thread.gmane.org/gmane.linux.gentoo.devel/57159 [v3] Bleeding edge prototype: http://dev.gentoo.org/~rbu/assign.py MANY thanks to rbu. If there are no further changes or objections at this time, it would be nice to implement this by the end of November. I updated the assign.py with suggestions from this thread, in particular: * maintainer/herd elements in categories' metadata.xml are respected * Anything that looks like a CAT/PN in the string is caught if it is either a valid CAT/PN or valid CAT * Order in metadata.xml is what dictates assignee, i.e.: The first herd or maintainer listed in the metadata.xml of the first CAT or CAT/PN is who is assignee, all other follow as CC. What are the next steps for this to go forward? Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
On Sunday 04 January 2009, Mike Auty wrote: Jeroen Roovers wrote: The order (first maintainer as assignee or first maintainer/herd as assignee) is open to discussion and I think this is the proper forum to have that discussion. It seems sensible to me. I would've thought that being more specific would surely be better? Splitting them up means those who are mostly in charge of a package see it easily, and it's also then easier to spot packages that only have a herd, rather than them getting lost in all the packages that do have individual maintainers... I've attached a quick patch that should fix up assign.py to add all the herds on the end. Since the order of the second item onwards doesn't matter, all herds are added at the end. If we do need an ordering (like maintainer1, herd1, maintainer2, maintainer3, herd2) then it'll need a more complex patch... I actually implemented it this way before (only that I had all herds with higher priority than all maintainers, which is the reverse of your patch). The outcome of the previous discussion for me was that there is no real consent on who should be the assignee. Robin put it this way: On Sunday 19 October 2008, Robin H. Johnson wrote: As an addenda, from v1, different teams and developers DO want different behaviors: 1. Assign to herd, CC all others (eg: GNOME, base-system) 2. Assign to first maintainer, CC herd and others (eg: net-mail) That was deliberately why I had logic about using the order in the metadata.xml file, with the addition that later duplicate entries of an email would override the first one. Your generic rule of (assign to first non-herd maintainer, CC rest) doesn't fit all of the cases. Accepting the fact that different teams have different preferences, we need to find a solution for them to set theirs individually. This could either be the order of elements in metadata.xml (and would set the preference on a per-package basis) or some attribute in herds.xml (which would be a global setting per herd, and we'd need to find a default). Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Handling Launchpad SRC_URI
On Sunday 25 January 2009, Josh Saddler wrote:
Right now, there's no canonical (heh) way of handling SRC_URI for
projects that have their files at launchpad.net. We need a standard
way of handling Launchpad SRC_URIs, similar to what we do with
mirror://sourceforge/ SRC_URIs.
1. Some packages use the launchpadlibrarian.net download redirect,
which results in a non-helpful server-generated number:
(gnome-catalog)
SRC_URI=http://launchpadlibrarian.net/11326737/${PN}_${PV}.orig.tar.
gz
^^ This just uses launchpad since the file has been removed upstream and
Ubuntu happens to archive their source files there. You could just as
well use this link:
http://snapshot.debian.net/archive/2008/01/19/debian/pool/main/g/gnomecatalog/gnomecatalog_0.3.3.orig.tar.gz
or bump to the latest upstream version (and use the sf.net mirror).
2. Some hack up interesting MY_P stuff:
(gnome-do-plugins)
MY_PN=do-plugins
PVC=$(get_version_component_range 1-2)
PVC2=$(get_version_component_range 1-3)
SRC_URI=https://launchpad.net/${MY_PN}/${PVC}/${PVC2}/+download/${P}
.tar.gz
(avant-window-navigator-extras)
MY_P=awn-extras-applets-${PV}
SRC_URI=https://launchpad.net/awn-extras/${PV%.*}/${PV}/+download/${
MY_P}.tar.gz
The AWN-extras ebuild is the closest to the right way of doing it,
I think.
So can we agree on a standard way of treating Launchpad SRC_URIs and
get the handler support into Portage?
I haven't seen the inside of administrating a project in Launchpad yet,
but that version part (${PV%.*}) seems to be an arbitrary string, and
there are quite a few examples where this URL handler does not work:
* https://launchpad.net/tangocms/+download
* https://launchpad.net/terminator/+download
* https://launchpad.net/get-you/+download
* https://launchpad.net/do-plugins/+download
[ this is the second package mentioned above, even here some of the
links would not work with the proposed solution ]
Robert
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: Re: Re: Re: Dependencies on system packages
Steve Long wrote: Alec Warner wrote: Er, his point being that if you don't do the upgrade all at once, you have two classes of package. 1. Packages that don't require C-compiler 2. Packages that don't yet depend upon C-compiler When doing the upgrade over a period of time the two classes of package become indistinguishable. Does Foo not need a C compiler, or has it just not gotten updated yet, it's impossible to tell without looking, so it's very difficult for people to report 'problem packages' because they have to unpack and examine the package every time (at worst). I understand that there'd be two types of pkg in the tree; what I don't get is why that is such a problem. Excuse my missing something obvious. What do you mean by a `problem package' in this context? A problem package would be one that does not need a C compiler. It can't be distinguished from the one which was not yet changed to depend on C. The problem here is that one can not say when the whole tree is updated to the new standard, because for the packages which were not touched, it could mean that they needed no change or that they were not looked at yet. A solution to distinguish the two categories is to mark the packages which were checked, so you know: 1. If it's checked and doesn't depend on cc - category 1 2. If it's not checked and doesn't depend on cc - category 2 Then, when all packages are checked, the tree is upgraded. Regards, Robert -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages
Steve Long wrote: Robert Buchholz wrote: The problem here is that one can not say when the whole tree is updated to the new standard, because for the packages which were not touched, it could mean that they needed no change or that they were not looked at yet. I can understand that as a maintenance issue. My query is whether having two different types of pkg would effect users in any way. You're right, it would not be a problem for usability. A solution to distinguish the two categories is to mark the packages which were checked, so you know: 1. If it's checked and doesn't depend on cc - category 1 2. If it's not checked and doesn't depend on cc - category 2 Then, when all packages are checked, the tree is upgraded. Sure, that makes sense. It sounds a heckuva lot like a database ;) Minor point- how can you tell in cat 2 that it definitely does not need a C compiler if it hasn't been checked? I'm guessing you were tired :) In any event in terms of maintenance, we'd need a tri-state: unchecked, checked and needs compiling, checked and doesn't (eg scripts). No, no. I did not mean that category 2 does not need a C compiler. I referred to Alec's mail which had 2. Packages that don't yet depend upon C-compiler. As for the state problem, when saving checked and unchecked as a package's metadata, you will get the other properties (needs cc, needs insert system dep) out of its DEPEND. In terms of maintaining the metadata, am I right in thinking it's all just kept within the text files in the tree? Since the tree itself is the best database of the packages available, anything else would be a lot more overhead. But I had the impression the idea was discarded anyway. So I should focus my thoughts somewhere else :-) Ciao, Robert -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Robert Buchholz (rbu)
Petteri Räty wrote: It's my pleasure to introduce to you Robert rbu Buchholz. Before it's too late, I wanted to send thanks to Jokey who was and is a great mentor. And also to all who sent greetings. Hope to see some of you at the next German conspiracy meeting. Robert -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: metadatabase
Ryan Hill wrote: Steve Long wrote: Robert Buchholz wrote: Since the tree itself is the best database of the packages available, anything else would be a lot more overhead. I really don't agree, altho I could well be missing something. Surely there should be a maintenance/QA database which tracks the tree and where you could put information like this (ie a boolean flag for this instance) which simply shouldn't be exposed to users. There's no need for it, it doesn't effect them, and why should it go in the ebuilds where a maintainer might delete it? I just use a local db to keep track of stuff like this, but haven't thought of a way to turn this into a service and i don't think it's really doable. I think you'd need an entry for every ebuild in portage, times the number of archs, times an unlimited number of arbitrary fields (one for each thing you're tracking). Something like, say, checking every package in the tree for GPL-2 or GPL-2+ licenses doesn't need the separate arch entries of course, but stuff like GCC testing definitely does. Even if you did manage to set this up, I wouldn't want to maintain it. I don't want to sound negative and I like the idea a lot, but two things are on my mind about this: It should also sync with changes in the tree, like package removals, additions and package moves. When you're talking about it on ebuild base: When a version bump is out, will it inherit the flags of the version before? Regards, Robert -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: Dependencies on system packages
Steve Long schrieb: In terms of maintaining the metadata, am I right in thinking it's all just kept within the text files in the tree? Since the tree itself is the best database of the packages available, anything else would be a lot more overhead. I really don't agree, altho I could well be missing something. Surely there should be a maintenance/QA database which tracks the tree and where you could put information like this (ie a boolean flag for this instance) which simply shouldn't be exposed to users. There's no need for it, it doesn't effect them, and why should it go in the ebuilds where a maintainer might delete it? You are totally right. Though there's one little effect: Before someone files a bug because the package does not depend on a CC, (s)he will have to know whether it's already checked. But if the DB is public, that's not an issue. But I had the impression the idea was discarded anyway. So I should focus my thoughts somewhere else :-) Please focus your thoughts wherever you wish. I gotta ask tho; what idea? I thought we were just talking about excess dependencies in the tree. I somehow lost track of the messages in this thread, but the idea of having large scale dependencies any system package needed seemed not realistically doable. If it's just about adding virtual/c-toolchain, was there arguments against it? Regards, Robert -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Add LCD_DEVICES to USE_EXPAND
Hi *, both app-misc/lcdproc and app-misc/lcd4linux can use numerous kinds of displays. The device selections are right now handled via environment variables and/or single use flags. I would like to unify possible devices via the USE_EXPAND'ed LCD_DEVICES. Right now, this would contain about 50 devices [1]. Out of these, some common devices should be installed by default (these are considered default by lcdproc upstream, too): LCD_DEVICES=bayrad CFontz CFontz633 curses CwLnx glk lb216 lcdm001 MtxOrb pyramid text This will of course introduce changes in the configurations for lcdproc and lcd4linux users, but I think that it needs to be done and the changes are mostly renaming USE flags and environment variables. If no one objects, I'd like to implement these changes. But there are some questions still open: * Who will add the entries to base/make.defaults? Can I do this? * Should the defaults and the USE_EXPAND entry be in base/ even though both programs do not are not keyworded for all arches? Regards, Robert [1] http://dev.gentoo.org/~rbu/lcd_devices.desc signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add LCD_DEVICES to USE_EXPAND
Ciaran McCreesh schrieb: On Wed, 10 Jan 2007 01:15:45 +0100 Robert Buchholz [EMAIL PROTECTED] wrote: | I would like to unify possible devices via the USE_EXPAND'ed | LCD_DEVICES. Right now, this would contain about 50 devices [1]. How standardised is the naming of these devices? It's not. It's the union of the (upstream) driver's names in lcdproc and lcd4linux. Those devices that are supported by both programs had the lcdproc name staying and the lcd4linux one cut. It's also hard to standardise the names as some of the drivers are not actual devices (as curses or X11) while others stand for a whole family of devices or can talk to several different devices depending on the user configuration. Regdards, Robert signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add LCD_DEVICES to USE_EXPAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.01.2007 at 13:56, Chris Gianelloni wrote: On Wed, 2007-01-10 at 01:15 +0100, Robert Buchholz wrote: * Who will add the entries to base/make.defaults? Can I do this? Not only *can* you, but you absolutely *must* do this if you're making the changes. The profiles aren't some black box that nobody can touch. The only thing anyone asks is that you know the ramifications of your actions. Asking here and getting sound advice should suffice for determining whether something is worth doing and the proper solution. *Not* adding these yourself means pawning work off on someone else, and possibly breaking (at least) your packages, and a violation of policy (the don't break the tree one). Just wanted to make sure I don't break an unknown to me or unwritten rule here :-) * Should the defaults and the USE_EXPAND entry be in base/ even though both programs do not are not keyworded for all arches? Yes. After all, they *may* be keyworded on any arch. It isn't like the hardware/software *can't* run on those arches. Good point. Regards, Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFpR51yZx3L/ph1soRAgWXAKDh52GHFPK1ue3zO19Zato5/E9ESACggmvU mo0Od4tmTpQ6vD3N7ER0X/g= =LG0s -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: profile changelogs
Chris Gianelloni wrote: On Fri, 2007-01-12 at 09:22 -0700, Steve Dibb wrote: Would that Changelog in profiles/ need to be updated for stuff recursively as well? I made some changes to default-linux/amd64/ stuff, but I added the changes to the ChangeLog for that directory. That would be correct. The rightmost ChangeLog should be used. What I am hoping we end up with is: ... profiles/base/ChangeLog: This is for anything affecting everyone. ... I added the base/ChangeLog after discussion on #-dev when I just edited the make.defaults to implement the proposed LCD_DEVICES changes. Regards, Robert signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Distrowatch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.03.2007 um 09:35 schrieb Ioannis Aslanidis: What I personally think out of all this situation is nice propaganda for Gentoo, which we could somehow exploit in 'our benefit'. Anyone with ideas on how to promote our distribution even with that kind of propaganda? Gentoo is hot. Just look at all the flames. Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF/+hZyZx3L/ph1soRAtjkAJ9tfAS/PECSTAM9id78dBqoADAuTACeLm0o Zk61RV70fqw5r1id1fC2Zms= =nMak -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Grant Goodyear wrote: Ciaran McCreesh wrote: [Sat Mar 24 2007, 11:38:45AM CDT] On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Weird, I haven't received Mike's e-mail yet, although I got ciaranm's reply. Me neither, but the mail is here: http://article.gmane.org/gmane.linux.gentoo.devel/47260 The bug: https://bugs.gentoo.org/141904 Regards, Robert signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Increasing contributions and interest via personal project aggregation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 09.05.2007 um 07:44 schrieb Donnie Berkholz: Hi all, I'm sure I'm not the only one with a number of projects I'll never get to, but I'd really like them to happen anyway. I suggest we create some sort of page that aggregates all of these personal projects together, so anyone can browse through them and look for stuff that sounds fun. The goal is to increase contributions from outside by giving them a ready list of projects of all sizes and difficulty levels to work on, projects that go beyond what happens at Bugday. Further, it could also help current Gentoo developers who are bored or have lost interest in what they're doing by helping them to find somewhere new to contribute. A prototype with just my projects is at http://dev.gentoo.org/~dberkholz/proj/ Great idea! I hope I don't break down religious discussions, but I pretty much like what I see from Ubuntu's Launchpad, which handles so callled Blueprints, see for example: https://blueprints.launchpad.net/soyuz/+spec/personal-package- archives Unfortunately, Launchpad is not yet open sourced completely, some code lies around here: https://launchpad.net/launchpad As registering a project at the launchpad.net service is not an option for Gentoo, any other idea for a good management of ideas that includes comments, assignments, filtering, etc? Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGQauCyZx3L/ph1soRAnk3AKC3OqTvRV4wxwmnEXxHkgg//U5d1QCbBoiC 0jHyx/akV8BvGOu+pxi8DC4= =MaMu -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.06.2007 um 13:29 schrieb Christoph Mende: On Tue, 12 Jun 2007 12:59:42 +0200 cilly [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 12:53 PM, cilly wrote: Additional: Sometimes the chance for the users to place the ebuild comfortably into overlay is simply taken, since the ebuild has been removed and doesn't exist after a sync anymore. It's not, CVS keeps every ebuild around, just go to sources.gentoo.org and hit Show X dead files in the dir of the ebuild you want ;) The problem is rather that the patches are gone from the distfiles mirror after two weeks. The sources often stay upstream, but could also be gone. Is there an archive for these files I missed? Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGcACzyZx3L/ph1soRAutQAKCMQ2f6nCzoXgATbIPTO6sbTv32ugCeP+JP tqC13Sfmy1t30jU6aCWgZug= =A832 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch
On Friday, 6. July 2007 10:09, Petteri Räty wrote: Mike Frysinger kirjoitti: get your waaait dont do it votes in now, i plan on pushing: glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86 gcc-4.2.0 ~amd64 ~x86 in the next day or so -mike About how many packages will break with the new gcc version? Of course switch not used by default so that's ok. Debian is going to 4.2 in unstable these days too and they already found and fixed a lot of bugs. You can view a list of current and fixed ones here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.2;[EMAIL PROTECTED] A lot of the bugs are already quite old and might be fixed upstream already. Robert -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: media-tv/freevo
On Wednesday, 11. July 2007 21:28, Stefan Schweizer wrote: Hi, # unmaintained, masked for removal, bug 156497 # You can find a new version in the sunrise overlay media-tv/freevo-1.7.2 I'll take over (proxy) maintenance of it, beandog (media-tv) agreed to lend a hand and we have _AxS_ from #gentoo-sunrise for the rescue who already committed the ebuild there. Moving it over to the tree as soon as I have a closer look at it. The package.mask for 1.7 stays. Robert -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Am 13.07.2007 um 00:43 schrieb Chrissy Fullam: The -dev mailing list would be the list for development discussion. The reason it does not replace -core is because it would still be open to be viewed by the public. Many devs have stated that they do not wish to read -dev presently due to the quantity of off topic emails, or at least those that are not productive. These devs would be able to continue to read -dev and reduce the volume of email to wade through to only those pertinent to the topic at hand. Non-devs would still subscribe and post, but those posts must first be approved by ANY developer. ... The -project mailing list would be the place for the unmoderated and potentially off topic correspondence. I don't think anyone is married to the name. It also is a required list for a dev to join. Isn't that two solutions for one problem? Creating the -project list is a way to discuss off-topic non-technical stuff on a place other than -dev. Why would we need to enforce moderation on the -dev list along with that? I have to second the voices that a lot of user mails are productive. I did not do any stats, but I feel that most mails to -dev are currently by Gentoo devs anyway, so it will not seriously reduce the amount of mail in total. As far as the usually fast technical discussions are concerned, my problem here is that users are in practical kept out of the discussion by the mere delay of their mails. We might experience double replies, users writing replies which get dumped -- because someone else already wrote the same mail 30 minutes ago and it did not get approved until he wrote his mail. If you ever spent 30 minutes figuring out a problem in Mac OS X and filing a decent bug report on their bug tracker just to find out it gets DUPed, but you could not know before because the search is not public, you know what I am talking about. My imagination of this would be: Create the project list for open discussion and restrict the *topic* range, not the *participant* range of this list. We can evaluate whether the SNR did improve enough after some time. Regards, Robert -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
On Tuesday, 17. July 2007 13:16, Mike Auty wrote: It also means that if a developer has had to move files around or in some way create the specific layout of the tarball for the ebuild, they won't be lost if the dev goes away, or retires, etc. So attaching the specific package creation code to the specific package unpacking code seems fairly sensible. Although, I can see why there may be objections, given the very specific circumstances in which it's useful... Having it inside the ebuild could also be useful for people who want to bump packages themselves and file bugs: They can use the dev's original create function and package the sources for testing. Regards, Robert -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Improving developer/user communication (was Re: net-im/pidgin protocols)
On Thursday, 19. July 2007 22:39, Jeroen Roovers wrote: Marijn Schouten (hkBst) wrote: Associate an irc-channel with each package. Associate how? Sounds like a lot of work at the least and a lot of cruft at the worst. It could be included in the herds.xml: herd namekde/name email[EMAIL PROTECTED]/email descriptionKDE and related packages/description ircirc://irc.freenode.net/#gentoo-kde/irc ircirc://irc.freenode.net/#gentoo-desktop/irc maintainer email[EMAIL PROTECTED]/email /maintainer ... /herd This way, it would not cruft any packages. Still for packages where a certain group of people maintain, it would show where to find them and other users. Where could it be displayed to users? I mean, herdstat of course, but somehow the info would have to reach Joe User, too. -R. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Improving developer/user communication (was Re: net-im/pidgin protocols)
On Friday, 20. July 2007 23:48, Chris Gianelloni wrote: On Fri, 2007-07-20 at 18:54 +0200, Thomas Scharl wrote: Anyways this is more of philosophical/social issue to discuss about than a technical one. One thing that I had been considering bringing up and getting help with is some scripts/whatever to get users to do things they might not know they can do during installation. For example, let's say we've got a little script, called sub_to_gwn, which takes a single argument, an email address. At the end of the Installer, we can ask Would you like to subscribe to the Gentoo Weekly Newsletter? and subscribe people that say yes. We could do the same thing for a stats client, or any other projects that we deemed would be useful. The idea here is to present some of these things that we would like the users to be doing to provide us feedback (and disseminate information) to the user when they're installing. Of course, we'd also add the scripts into the documentation, so people can simply run them w/o the Installer, so we're not tying this stuff to Installer-only installs. Anyway, some things I think we could/should do are: - GWN - gentoo-announce - gentoo-stats (or whatever we have now, if anything) Anything else? I don't know whether that is what you mean by gentoo-stats, but other distros have quite some interesting usage statistics by having their users submit hardware profiles to a server. I like the idea and wanted to have a look at Smolt [1]. The Fedora people would be interested in providing the client for Gentoo and would extend the web interface to enable better filtering of distros, too. But right now that's just some random ideas until after my exams next weeks :-) Robert [1] https://hosted.fedoraproject.org/projects/smolt/ , http://smolt.fedoraproject.org/stats -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: RFC: Forbid using versions in DESCRIPTION
On Tuesday, 24. July 2007 14:26, Petteri Räty wrote:
Ciaran McCreesh kirjoitti:
On Tue, 24 Jul 2007 13:44:52 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
Perhaps we should just move DESCRIPTIONs to metadata. That would
make it impossible to use ${PV} and more importantly also remove
some duplication.
Got to be careful here. In the past it's been stated that Portage
won't use XML for anything that it has to parse.
Well here we need to answer the question whether searching
DESCRIPTION strings is a core feature. I have never used emerge
--searchdesc but that might be just me.
I believe it to be a core feature. How else am I to find an rss reader
in portage without having any preference or knowledge before
installing? Or some random tool to convert X to Y.
Often, features are not part of the name.
Robert
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Release managment
On Thursday, 2. August 2007 19:35, Christian Faulhammer wrote: Martin Michlmayr, Debian Project Leader from 2003 to 2005, has finished his Phd thesis about Quality improvement in volunteer software projects [1] .. he gave a short introduction on the whole topic on Google Tech Talks: http://video.google.com/videoplay?docid=-5503858974016723264 (for those who rather spend an hour listening than reading :-) P.S.: Is -dev the correct list? I guess that depends on what we can/want to learn from his research. -R. pgpnoplZEkiKc.pgp Description: PGP signature
