Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
В Срд, 06/08/2008 в 14:18 -0700, Robin H. Johnson пишет: Getting the bot out there - If you would like to have the new bot in your #gentoo-* channel, would each channel founder/leader please respond to this thread, stating the channel name, and that they are the contact for any problems/troubles. #gentoo-ru #gentoo-doc-ru Thank you for your work guys, -- Peter.
Re: [gentoo-dev] Unmasking of qt 4.4?
Ben de Groot wrote: Hanno Böck wrote: So question, what are the showstoppers for qt 4.4? And more general comment, especially on important packages that many people rely on, please provide more informative comments in package mask, e.g. bug numbers. Bug numbers should indeed have been provided. The tracker bugs are: #217528 - [Tracker] x11-libs/qt-4.4.0 unmasking #217161 - [Tracker] split Qt 4.4 Mostly it's a question of packages not having split qt-4 deps yet. Other than that, the ebuilds have seen enough testing, as they are needed for kde-4.1 for example, so that is not an issue anymore. For the dependencies, I think this isn't a showstopper either, as if you don't have split dependencies on qt, it'll just take the metapackage and everything is like before. Except that as per bug 217161 nothing should depend on the metapackage. At the moment I'm going through all the remaining open bugs. If things are easy to fix for me I am fixing the deps, otherwise I'm leaving a comment that the package needs fixing ASAP, because I don't want to wait with unmasking qt-4.4 any longer. I hope to be able to do that by tomorrow. (Although I'm still waiting on the remainder of the qt team to officially become a member.) Regards, Ben That being said, anyone wanna give me a hand with MythTV 0.22 depends? I'd appreciate it.
Re: [gentoo-dev] Re: Retirement
On Tue, 12 Aug 2008 00:26:18 + (UTC) Xx [EMAIL PROTECTED] wrote: I picked this message as the current last in thread to reply to. Please allow me to express my sincere distaste at the hijacking of this retirement announcement thread for (political) profit and/or fun. To the retirees: best of luck and happiness in your future (current!) endeavours and pity we didn't get along. Kind regards, JeR
[gentoo-dev] best way to use profiles and package.use.mask?
Okay, this is something that I've wondered about for a while, but need to ask -- what is the best way (do we even have a policy) for using package.use.mask in profiles? A couple of specific questions: If I need to mask a use flag because of use flag dependencies that won't work on a particular arch, do I need to contact the arch teams to modify their package.use.mask profile? If the answer is yes, I can see that as a huge blocker since I'd have to wait on the arches to do something before I can even put an ebuild in the tree. I realize this is a per-arch question depending on how each one might respond, but a common consensus would be good. Are there ever any cases where we could just simply put the use flag as restricted in the global package.use.mask and then unrestrict them in the profiles ones if, for example, it only worked on one or a few arches? Or is the best policy always to mask it on each profile? As for a specific example, mplayer's dxr2/dxr3 use flag now pulls in a dependency (media-video/em8300-libraries) which is only keyworded for x86, ppc, and amd64. That means I'd have to mask the use flag in alpha, hppa, ia64, ppc64 and sparc (according to repoman). I could skirt the issue completely and just run an if statement checking if they are using any of those three arches, but I'd prefer to do it the right way. And not piss off any arch teams in the process. So I guess my question is, can individual ebuild devs freely edit package.use.mask files in profiles? Steve
Re: [gentoo-dev] best way to use profiles and package.use.mask?
Maybe we should ask Recruiters what most people answered to that eom-quiz question :) I personally think no, individual ebuild devs shouldn't touch arch-profiles. They should simply drop the (broken) keywords and file a keywordreq bug for those arches. Then the arch-teams can test and eventually decide whether to keyword the package or mask the use-flag. This way it will be documented in the package's ChangeLog which is usually the first one I check and we won't pollute the profiles's ChangeLog with lots of added, removed, added, removed entries. Cheers, Friedrich Am Dienstag, den 12.08.2008, 12:00 -0600 schrieb Steve Dibb: Okay, this is something that I've wondered about for a while, but need to ask -- what is the best way (do we even have a policy) for using package.use.mask in profiles? A couple of specific questions: If I need to mask a use flag because of use flag dependencies that won't work on a particular arch, do I need to contact the arch teams to modify their package.use.mask profile? If the answer is yes, I can see that as a huge blocker since I'd have to wait on the arches to do something before I can even put an ebuild in the tree. I realize this is a per-arch question depending on how each one might respond, but a common consensus would be good. Are there ever any cases where we could just simply put the use flag as restricted in the global package.use.mask and then unrestrict them in the profiles ones if, for example, it only worked on one or a few arches? Or is the best policy always to mask it on each profile? As for a specific example, mplayer's dxr2/dxr3 use flag now pulls in a dependency (media-video/em8300-libraries) which is only keyworded for x86, ppc, and amd64. That means I'd have to mask the use flag in alpha, hppa, ia64, ppc64 and sparc (according to repoman). I could skirt the issue completely and just run an if statement checking if they are using any of those three arches, but I'd prefer to do it the right way. And not piss off any arch teams in the process. So I guess my question is, can individual ebuild devs freely edit package.use.mask files in profiles? Steve signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] best way to use profiles and package.use.mask?
On Tue, 2008-08-12 at 12:00 -0600, Steve Dibb wrote: Okay, this is something that I've wondered about for a while, but need to ask -- what is the best way (do we even have a policy) for using package.use.mask in profiles? A couple of specific questions: If I need to mask a use flag because of use flag dependencies that won't work on a particular arch, do I need to contact the arch teams to modify their package.use.mask profile? If the answer is yes, I can see that as a huge blocker since I'd have to wait on the arches to do something before I can even put an ebuild in the tree. I realize this is a per-arch question depending on how each one might respond, but a common consensus would be good. What happens now is that the ebuild gets added, keywords get dropped as needed, and whoever added the new ebuild opens a rekeywording bug. Are there ever any cases where we could just simply put the use flag as restricted in the global package.use.mask and then unrestrict them in the profiles ones if, for example, it only worked on one or a few arches? Or is the best policy always to mask it on each profile? Personally, I prefer the first. But then, if a package is not going to work someplace, sparc is often one of those places. Down side comes if perhaps we are actually testing the package out of /usr/local/portage or some such, and suddenly the use flag for it comes up masked. As for a specific example, mplayer's dxr2/dxr3 use flag now pulls in a dependency (media-video/em8300-libraries) which is only keyworded for x86, ppc, and amd64. That means I'd have to mask the use flag in alpha, hppa, ia64, ppc64 and sparc (according to repoman). I could skirt the issue completely and just run an if statement checking if they are using any of those three arches, but I'd prefer to do it the right way. And not piss off any arch teams in the process. So I guess my question is, can individual ebuild devs freely edit package.use.mask files in profiles? Freely? Of course not. We (the arch developers) need to know about it. :) Steve I see what you are after. I don't see a good answer for your specific request that does not usually involve a bug of some sort, asking the arch teams to look at what you have done or what you want to do. There are edge cases, of course. Like, I've package.use.masked fast-x86 for bigmath-3.3.3 on sparc because it pulls in the fast-x86 package which is a fast math x86 package written in x86 assembler. But we still want to know what you've done and why, although in a case like that, a ChangeLog entry would likely be enough. Speaking for myself and not for all of sparc: If you do what seems best at the time (drop keywords and ask for rekeyword, package.use.mask, use.mask with selective unmasking) and document it, along with just asking on IRC when there is doubt, you won't go far wrong. We might scream at you, but we do that to package developers all the time anyway. Default now seems to be to drop keywords and open bugs requesting rekeywording, and that seems to work fine. But unnecessary in edge cases like the one I made up above (and yes, there are some like that). And if you know ahead of time you have something like this coming up, as I mentioned before, ask on IRC if you think of it before playing with profiles. I didn't answer your question. Mostly, I guess, do what seems right and let us know what you did. The best way to do that is through a bug usually. You might not find us on IRC when you need us, and we probably won't read your mail. :) Sorry for not helping, Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
Robin H. Johnson wrote: If you would like to have the new bot in your #gentoo-* channel, would each channel founder/leader please respond to this thread, stating the channel name, and that they are the contact for any problems/troubles. #gentoo.cs please, me as a contact. -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Should we introduce PROPERTIES into the ebuild metadata cache on the rsync mirrors?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please consider the introduction of a new PROPERTIES variable to
the ebuild metadata cache that's distributed via the rsync mirrors
and resides locally in the ${PORTDIR}/metadata/cache/ directory.
This variable is intended to have identical syntax to the existing
RESTRICT variable, including support for the USE conditional syntax
that is also supported by the LICENSE, PROVIDE, SRC_URI, and *DEPEND
variables.
The idea to introduce the PROPERTIES variable arose from discussion
about the introduction of a new RESTRICT value [1]. By using a new
PROPERTIES variable instead of the existing RESTRICT variable, we
will have two separate categories of boolean attributes. This will
be useful since some boolean attributes, such as primaruri and
live-sources, have an inverted nomenclature when compared to the
other boolean attributes that currently exist within the RESTRICT
set, show here:
binchecks - Disable all QA checks for binaries.
bindist - Distribution of binary packages is restricted.
fetch - Files will not be fetched via SRC_URI.
installsources - Disable FEATURES=installsources.
mirror - Disable mirroring.
primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS.
strip - Final binaries/libraries will not be stripped.
test - Do not run src_test even if user has FEATURES=test.
userpriv - Disables FEATURES=userpriv.
We can add the new PROPERTIES variable to the metadata cache and it
will be fully backward compatible as long as PROPERTIES only
contains information that can be safely ignored by older versions of
portage. Newer versions of portage that are aware of the new
variable will simply have a superset of the information that's
available to older versions of portage.
The addition of the PROPERTIES variable isn't entirely necessary
since any PROPERTIES value can alternatively be expressed as a
RESTRICT value. However, numerous people have expressed a desire to
have a new variable to represent a different category of boolean
attributes, so as not to pollute the RESTRICT variable with values
that don't fit well into existing RESTRICT nomenclature conventions.
We haven't made any firm decisions yet on specific PROPERTIES values
and their meanings. However, it would be nice to have the cache
support in place so that we are prepared to start defining
PROPERTIES in ebuilds as soon as we've decided on the names and
meanings of specific values such as live [2], virtual [3], and
interactive [4].
Introducing the PROPERTIES variable into the cache will require a
very small patch to portage. As soon as this patch is applied to
portage on the master rsync mirror, it will be possible to define
the PROPERTIES variable in any ebuild and have that value
automatically distributed via the metadata cache on the rsync
mirrors. The current cache format has space to store the values of
22 variables, delimited by newlines, of which 7 are currently
unused. The attached patch will cause the PROPERTIES value to be
stored on line number 16, following the EAPI value.
Should we go ahead an apply this patch to the master rsync mirror,
or would anybody like to discuss any alternatives? In the future we
may want to discuss a change in cache format. However, in this
thread I think we should limit discussion simply to whether or not
adding this one variable to the cache is a good idea at this time.
Thanks,
Zac
[1]
http://archives.gentoo.org/gentoo-dev/msg_d8adb5d0dab3e8546c416781c452d81d.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_187585c5d49b69034183719ff473710d.xml
[3] http://article.gmane.org/gmane.linux.gentoo.devel/57610
[4]
http://archives.gentoo.org/gentoo-dev/msg_e145fc04e907de72e30d88285afb134c.xml
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkiiJGIACgkQ/ejvha5XGaMIfQCguxt0Z0k1V3SEtW+PrhQPsdIK
MPIAn37AWGFONJsbdD6oRJryzQ8EHkxt
=d5Jf
-END PGP SIGNATURE-
Index: pym/portage/__init__.py
===
--- pym/portage/__init__.py (revision 11402)
+++ pym/portage/__init__.py (working copy)
@@ -6797,7 +6797,7 @@
'RESTRICT', 'HOMEPAGE', 'LICENSE', 'DESCRIPTION',
'KEYWORDS', 'INHERITED', 'IUSE', 'CDEPEND',
'PDEPEND', 'PROVIDE', 'EAPI',
- 'UNUSED_01', 'UNUSED_02', 'UNUSED_03', 'UNUSED_04',
+ 'PROPERTIES', 'UNUSED_02', 'UNUSED_03', 'UNUSED_04',
'UNUSED_05', 'UNUSED_06', 'UNUSED_07',
]
auxdbkeylen=len(auxdbkeys)
Index: bin/ebuild.sh
===
--- bin/ebuild.sh (revision 11404)
+++ bin/ebuild.sh (working copy)
@@ -2046,7 +2046,7 @@
auxdbkeys=DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
DESCRIPTION KEYWORDS INHERITED IUSE CDEPEND PDEPEND
PROVIDE EAPI
- UNUSED_01 UNUSED_02 UNUSED_03 UNUSED_04 UNUSED_05
UNUSED_06
+
