Re: [gentoo-dev] CVS -> git, list of where non-infra folk can contribute
On Wed, 3 Oct 2012 11:46:15 +0800 Ben de Groot wrote: > On 3 October 2012 04:51, Theo Chatzimichos > wrote: > > One of the things that would be nice to have before the Git > > migration is Documentation. Feel free to submit docs in the wiki, > > and I'll help a lot after the conference as well. > > Can you be more specific as to what kind of docs are needed? > Just a quick browse through our docs, leaving out examples where there is merely mention of "CVS repositories" (where CVS is equated with any version control system) instead of CVS specific material: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=4 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap1 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5 http://devmanual.gentoo.org/general-concepts/cvs-to-rsync/index.html http://www.gentoo.org/proj/en/infrastructure/cvs-sshkeys.xml http://www.gentoo.org/doc/en/cvs-tutorial.xml http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt jer
Re: [gentoo-dev] Re: CIA replacement
On Wed, 3 Oct 2012 11:43:09 +0800 Ben de Groot wrote: > I don't think any of the replacement options I've seen have this > feature. Does anyone know of something that might offer us this? Or > should we develop something in-house? AFAIK some devrel related group already has some tool running that checks how long developers have been inactive (on our source code repositories). I don't think that information is disclosed publicly at this point, whereas CIA clearly did that publicly. jer
[gentoo-dev] Re: Discussing stuff that is not appropriate to discuss
On Mon, 01 Oct 2012 14:00:58 -0700 Diego Elio Pettenò wrote: > (Among other things, because it feels like most of the complains about > the way tinderbox's logs are handled, "it's easy!" but nobody but me is > ever going to pick up the task, ...) Well, duh. You designed, developed, and are the sole architect of the system. You made an error in the design. You might have had good reasons at the time, and you can argue them til you turn blue to anyone who will listen, but if your end consumers see it as a flaw it isn't going to change a thing. You're a service provider now. You need to provide everything your customers ask for, before they ask for it, or you'll get nailed to the nearest tree. Welcome to the wonderful world of customer service. :) Sorry to start yet another tangent. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
> On 30/09/12 06:15 PM, Brian Harring wrote:
>
> yngwin has a point that I've not seen addressed.
>
> What /is/ wrong with the whole CDEPEND intermediate var idea?
>
The problem appears as we introduce more DEPEND variables
(which is what prompted the proposal, IIRC). If we have
ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some
(i.e. not total) sharing going on then the COMMON_DEPEND
pattern starts to fall apart. You potentially need,
AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND
ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND
(COMMON_DEPEND)
This obviously gets worse as more DEPEND vars are introduced.
>>>
>>> Well not really, no -- the additional *DEPENDs that are being
>>> proposed (or at least mentioned) for new EAPI will either remove
>>> atoms from COMMON_DEPEND/DEPEND/RDEPEND or will be used so
>>> tersely that a COMMON_DEPEND or other intermediate variable won't
>>> really be necessary for them.
Another thing I wanted to point out is that those "potential" extra
variables are not needed in practice. We already have 98% of the tree
(if I got the previously mentioned stats right) that does fine with
just one or two ({R,}DEPEND). The majority of that other 2% needs just
one more variable. There may be corner cases where more vars would be
needed, but those will never be more than a few ebuilds.
It's just not worth it to completely change the way we do things (or
use two systems in parallel) just for a few ebuilds that would
significantly benefit.
If we were a new distro and designing our ebuild format from scratch,
then yes, I would say your proposal has merit. But we aren't. We have
hundreds of people and tens of thousands of ebuilds using *DEPEND just
fine. There are no big problems, only corner-cases. We're not talking
about incremental improvements either (such as was the case e.g. with
use deps).
Let's just keep things simple, and refrain from "fixing" what isn't broken.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] CVS -> git, list of where non-infra folk can contribute
On 3 October 2012 04:51, Theo Chatzimichos wrote: > One of the things that would be nice to have before the Git migration is > Documentation. Feel free to submit docs in the wiki, and I'll help a lot after > the conference as well. Can you be more specific as to what kind of docs are needed? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: CIA replacement
On 3 October 2012 08:21, Jeroen Roovers wrote: > Responding to no one in particular, but to the sub-thread about IRC > bots: > > On Tue, 2 Oct 2012 08:32:26 +0200 > Fabian Groffen wrote: > >> On 02-10-2012 12:40:20 +0800, Ben de Groot wrote: >> > The irker proxy was mentioned in this thread. I think we should look >> > into this. Unless someone has a better idea. >> >> I think it might be more beneficial to try and relay -commits email to >> irc. > > An IRC bot is nice, but CIA also provided current (!) statistics, which > isn't merely useful in order to boost your own morale/ego/self-esteem, > but also provided up to date information about other developers' > activity, which can help other developers decide if and when to step in > and start (temporarily) maintaining packages that need immediate > attention. ohloh cannot do that for us, presently, and a simple IRC > bot cannot either. Indeed. I mentioned that in passing as well (that their website was useful), and you explain why. I don't think any of the replacement options I've seen have this feature. Does anyone know of something that might offer us this? Or should we develop something in-house? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Re: CIA replacement
On 3 October 2012 00:51, Peter Stuge wrote: > Ben de Groot wrote: >> > What is the source data, > > Still unanswered. I'll ask something which would be equally helpful: > > Where is the software that currently sends out emails to the -commits list? I don't know, but I assume it's a commit hook in our CVS repository. Someone from infra should be able to shed more light on that. >> > and what does the desired output look like? >> >> tetromino * gentoo-x86/x11-themes/gnome-themes-standard/ (7 files): >> Version bump for gtk+-3.6; high contrast and low contrast >> themes are no longer provided. Make license more precise.. >> (Portage version: 2.2.0_alpha132/cvs/Linux x86_64) >> ssuominen * gentoo-x86/xfce-extra/xfce4-power-manager/ (3 >> files in 2 dirs): >> Fix crash with en_GB locale wrt #419973 by Ciprian Ciubotariu >> (Portage version: 2.2.0_alpha128/cvs/Linux x86_64) > .. >> tetromino proj/gnome:master * r78959387 >> /dev-util/gdbus-codegen/ (gdbus-codegen-.ebuild >> gdbus-codegen-2.33.14.ebuild): dev-util/gdbus-codegen: 2.34.0 now in >> gx86 >> >> So basically: >> >> $committer $repo $path: >> $changelog > > Well it's more complicated, but thanks for the sample output! Yeah, but we don't need an exact replica. Just a quick way to see who committed what where, and the changelog message. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] About disabling DISABLE_DEPRECATED
On Sunday 30 September 2012 17:44:05 Gilles Dartiguelongue wrote:
> +# @USAGE: gnome2_disable_deprecation_warning
no need for this
> + for makefile in $(find "${S}" -name "Makefile.in" \
> + -o -name "Makefile.am" -o -name "Makefile.decl" | sort); do
`local makefile` missing. also, this does not preserve quoting. you would
have to do:
while read makefile ; do
...
done < <(find ...)
> + if ! grep -qE "(DISABLE_DEPRECATED|GSEAL_ENABLE)"
> "${makefile}"; then
`grep -E` -> `egrep`
> + LC_ALL=C sed -e 's:-D[A-Z_]\+_DISABLE_DEPRECATED:$(NULL):g' \
> + -e 's:-DGSEAL_ENABLE:$(NULL):g' \
> + -i "${makefile}"
use -r instead of escaping. it's also more readable to split -e from the rest
since that tends to be the meat of sed.
LC_ALL=C sed -i -r \
-e '...' \
-e '...' \
"${makefile}"
> + fails[$(( ${#fails[@]} + 1 ))]="${makefile}"
fails+=( "${makefile}" )
> + eerror "Failed to disable deprecation warnings in $makefile"
${makefile}
also, if you're using eerror, this really should end in a `die`. or it should
use ewarn.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: CIA replacement
On Tue, Oct 2, 2012 at 8:21 PM, Jeroen Roovers wrote: > Responding to no one in particular, but to the sub-thread about IRC > bots: > > On Tue, 2 Oct 2012 08:32:26 +0200 > Fabian Groffen wrote: > >> On 02-10-2012 12:40:20 +0800, Ben de Groot wrote: >> > The irker proxy was mentioned in this thread. I think we should look >> > into this. Unless someone has a better idea. >> >> I think it might be more beneficial to try and relay -commits email to >> irc. > > An IRC bot is nice, but CIA also provided current (!) statistics, which > isn't merely useful in order to boost your own morale/ego/self-esteem, > but also provided up to date information about other developers' > activity, which can help other developers decide if and when to step in > and start (temporarily) maintaining packages that need immediate > attention. ohloh cannot do that for us, presently, and a simple IRC > bot cannot either. Bouncing over to -scm list. Maybe this can be implemented in a post-commit hook. -- :wq
Re: [gentoo-dev] Re: CIA replacement
On 10/02/2012 08:21 PM, Jeroen Roovers wrote: Responding to no one in particular, but to the sub-thread about IRC bots: On Tue, 2 Oct 2012 08:32:26 +0200 Fabian Groffen wrote: On 02-10-2012 12:40:20 +0800, Ben de Groot wrote: The irker proxy was mentioned in this thread. I think we should look into this. Unless someone has a better idea. I think it might be more beneficial to try and relay -commits email to irc. An IRC bot is nice, but CIA also provided current (!) statistics, which isn't merely useful in order to boost your own morale/ego/self-esteem, but also provided up to date information about other developers' activity, which can help other developers decide if and when to step in and start (temporarily) maintaining packages that need immediate attention. ohloh cannot do that for us, presently, and a simple IRC bot cannot either. jer jer thanks for saying that. That's exactly how I was using CIA. Now I'm just using the gentoo-commits@ list which gives the same info but requires more sorting effort on my brain. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Re: CIA replacement
Responding to no one in particular, but to the sub-thread about IRC bots: On Tue, 2 Oct 2012 08:32:26 +0200 Fabian Groffen wrote: > On 02-10-2012 12:40:20 +0800, Ben de Groot wrote: > > The irker proxy was mentioned in this thread. I think we should look > > into this. Unless someone has a better idea. > > I think it might be more beneficial to try and relay -commits email to > irc. An IRC bot is nice, but CIA also provided current (!) statistics, which isn't merely useful in order to boost your own morale/ego/self-esteem, but also provided up to date information about other developers' activity, which can help other developers decide if and when to step in and start (temporarily) maintaining packages that need immediate attention. ohloh cannot do that for us, presently, and a simple IRC bot cannot either. jer
Re: [gentoo-dev] CVS -> git, list of where non-infra folk can contribute
On Tuesday 02 of October 2012 12:58:04 Ben de Groot wrote: > Thank you so much for taking the time to give us this clear list of > things that need to be done to take this forward! Disclaimer: I haven't read Brian's long mail (and most of the mails in this mailing list for the past month) One of the things that would be nice to have before the Git migration is Documentation. Feel free to submit docs in the wiki, and I'll help a lot after the conference as well. Theo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Tue, 2 Oct 2012 13:40:45 -0700 Brian Harring wrote: > Same difference applies; he's making the claim that the resolver > can't tell that the python atom should be the same between build/run: > > dep:build,run? ( dev-lang/python:2.7= ) > build: dev-python/snakeoil > > # vs labels > > build+run: dev-lang/python:2.7= > build: dev-python/snakeoil > > The argument there is basically predicated on the belief that only > labels can 'color' the sections it contains. This is a bullshit > claim, and possibly specific to paludis internal failings. No, it's specific to failings in the way you've written your proposal, which in turn are due to you wanting to implement it as a quick rendering hack in Portage. Unfortunately, the way you define things in terms of rendering dependencies forces everyone to emulate these failings so as to deliver a compliant handling of the || ( dep:build? ( a ) dep:run? ( b ) ) case. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Tue, Oct 02, 2012 at 02:08:02PM -0400, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/10/12 01:56 PM, Ciaran McCreesh wrote: > > On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius > > wrote: > >> On 30/09/12 05:53 PM, Ciaran McCreesh wrote: > >>> On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring > >>> wrote: > > The second is that it starts the conceptual shift from > > "cat/pkg is a build dep, and cat/pkg is a run dep" to > > "cat/pkg is a dep that is required for build and run". > > Fairly weak argument at best; you're claiming that via > labels, "contextually they know it's these deps" in > comparison to via dep:build "contextually they know it's > exposed only in build". > > Same difference. > >>> > >>> It's rather a big deal now that we have := dependencies. > >>> > > > >> So you would using your labels syntax, specify an atom with a := > >> dep using certain labels and the same atom without ':=' on other > >> labels? I don't quite follow what you're getting at here as to > >> how this is a big deal.. > > > > A := only makes sense for a dependency that is present both at > > build time and at runtime. Currently, the only place you should be > > seeing a := is on a spec that is listed in both DEPEND and > > RDEPEND. > > > > Conceptually, the := applies to "the spec that is in both DEPEND > > and RDEPEND". But with the current syntax, there's no such thing as > > "the spec that is in both". There are two specs, which happen to > > be identical as strings, one in DEPEND and one in RDEPEND, and > > there's no way for the two to be associated. > > > > Current syntax = *DEPEND, yes. Completely agree. > > In relation to Brian's proposal for DEPENDENCIES, tho, the two specs > which happen to be identical strings would be rolled out from the same > - -actual- string in the ebuild, and so, I don't see any such 'big deal' > between the ability to conceptually express what's going on via his > syntax and your labels. > > Unless i'm missing something, 'same difference' still fits.. Same difference applies; he's making the claim that the resolver can't tell that the python atom should be the same between build/run: dep:build,run? ( dev-lang/python:2.7= ) build: dev-python/snakeoil # vs labels build+run: dev-lang/python:2.7= build: dev-python/snakeoil The argument there is basically predicated on the belief that only labels can 'color' the sections it contains. This is a bullshit claim, and possibly specific to paludis internal failings. A sane implementation can walk that parse tree, and minimally infer that on it's own via the walk- or if it's saner, just track where things came from, and sort it via that way. Realistically a *good* implementation would likely be doing a partial rendering anyways (a good implementation already has the machinery for this for QA analysis reasons)- meaning conditionals beyond dep: would be finalized, leaving just those nodes unrendered, and then doing quick pass rendering of that intermediate form to get each phases specific requirements. Honestly it's a bullshit argument anyways; the unstated, but core argument of such nonsense is that the resolver if it saw dep:build? ( dev-lang/python:2.7= ) dep:run? ( dev-lang/python:2.7= ) would, because it's not one single build/run construct, think it can vary python:2.7 Any/all sane resolver already do collapsing and stabilization of common nodes across dep phases (and if paludis doesn't, well, that's their mess to sort; we're not getting any PROPERTIES=funky-slots hacks to work around their brain dead breakage here). The same situation can occur w/ labels via eclass dep manipulation; this is an artificial example, but anyone who has done deps know this sort of thing can/does occur via eclasses injecting common deps in: encode? ( build: dev-lang/python:2.7= ) build,run: dev-lang/python:2.7= Oh noes. How ever will the resolver know that it shouldn't vary the micro version of dev-lang/python:2.7 between build and run in that case! You just *know* it wants to vary the micro version because, such a completely fucking worthless thing for the resolver, it must do because it can, right? Etc. It's a pure bullshit argument, potentially derived from implementation issues for his own code, or just academic wankery; unsure of which, don't care which since the core argument is a new level of cracked out. ~harring
Re: [gentoo-dev] CVS -> git, list of where non-infra folk can contribute
Brian Harring wrote: 1) We need a thin manifest -> thick manifest converter. Thin manifests are used for git- they store just DIST entries. Thick (also known as 'full'), are what cvs/rsync users are familiar with- it holds checksums for all content. carebear is the current person volunteering to sort this (help may be appreciated, talk to him/her/it). heh :) I'll read up, spend some time on IRC, and see what I can do to help here. replay it into git via tailor; Never knew about that tool... not sure about the wisdom of adding an extra moving part just to keep the lights on for those few hours... Given the "2G of history" issue Diego mentioned, which if I understand correctly, effectively means that the future gentoo git can never rebase its commit history, why chance it? In my last experience with cvs->git (at the time I was building a rsync (binutils cvs)->git mirror for a client), the most difficult thing about cvs->git was trying to scrub the identity data. I don't remember the exact issue, but somehow, git had identity uniqueness constraints that cvs happily ignored, or something like that. I never thought to try using svn as an intermediate -- but I like that idea a lot and wish I had thought of it when I needed to. Anyhow, wrong ml for this, I'll subscribe to -scm. -gmt
Re: [gentoo-dev] glibc-2.16 moving to ~arch
On Friday 17 August 2012 23:31:36 Mike Frysinger wrote: > with glibc-2.15 gone stable, it's time to get 2.16 in the pipe. the big > issues have been sorted out already. there's a few packages still known to > build fail, but they've had quite some time to sort their stuff out, so i > don't see delaying further making a difference there. if anything, > they'll be more inclined to get their stuff fixed ;). this will be happening by the end of October or when boost-1.50 is sorted out. whichever comes first. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 02 Oct 2012 14:08:02 -0400 Ian Stakenvicius wrote: > > A := only makes sense for a dependency that is present both at > > build time and at runtime. Currently, the only place you should be > > seeing a := is on a spec that is listed in both DEPEND and > > RDEPEND. > > > > Conceptually, the := applies to "the spec that is in both DEPEND > > and RDEPEND". But with the current syntax, there's no such thing as > > "the spec that is in both". There are two specs, which happen to > > be identical as strings, one in DEPEND and one in RDEPEND, and > > there's no way for the two to be associated. > > > > Current syntax = *DEPEND, yes. Completely agree. > > In relation to Brian's proposal for DEPENDENCIES, tho, the two specs > which happen to be identical strings would be rolled out from the same > - -actual- string in the ebuild, and so, I don't see any such 'big > deal' between the ability to conceptually express what's going on via > his syntax and your labels. > > Unless i'm missing something, 'same difference' still fits.. Brian has DEPENDENCIES as being syntactic sugar that is "rendered" into separate *DEPEND variables. Conceptually, a := spec would be treated as two different, unrelated specs. If we're doing that, though, then there's not really any point in the proposal -- we want the model change, not just for := dependencies, but also to allow us to fix some of the awful mess that is ||. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBrL2kACgkQ96zL6DUtXhE1EgCeNANLVxtyb6OSir9LqA+PB+bJ zUkAn2dV2OjMYMB95+tBUYvb3Eda4rU7 =0Cwb -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/10/12 01:56 PM, Ciaran McCreesh wrote: > On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius > wrote: >> On 30/09/12 05:53 PM, Ciaran McCreesh wrote: >>> On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring >>> wrote: > The second is that it starts the conceptual shift from > "cat/pkg is a build dep, and cat/pkg is a run dep" to > "cat/pkg is a dep that is required for build and run". Fairly weak argument at best; you're claiming that via labels, "contextually they know it's these deps" in comparison to via dep:build "contextually they know it's exposed only in build". Same difference. >>> >>> It's rather a big deal now that we have := dependencies. >>> > >> So you would using your labels syntax, specify an atom with a := >> dep using certain labels and the same atom without ':=' on other >> labels? I don't quite follow what you're getting at here as to >> how this is a big deal.. > > A := only makes sense for a dependency that is present both at > build time and at runtime. Currently, the only place you should be > seeing a := is on a spec that is listed in both DEPEND and > RDEPEND. > > Conceptually, the := applies to "the spec that is in both DEPEND > and RDEPEND". But with the current syntax, there's no such thing as > "the spec that is in both". There are two specs, which happen to > be identical as strings, one in DEPEND and one in RDEPEND, and > there's no way for the two to be associated. > Current syntax = *DEPEND, yes. Completely agree. In relation to Brian's proposal for DEPENDENCIES, tho, the two specs which happen to be identical strings would be rolled out from the same - -actual- string in the ebuild, and so, I don't see any such 'big deal' between the ability to conceptually express what's going on via his syntax and your labels. Unless i'm missing something, 'same difference' still fits.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrLYIACgkQ2ugaI38ACPBb4gD+KnH0izbhJZuhm0JD1cHG6s0D 4/0gxZk3Z+TEy9I0W84A/1Yt0ilqJ0SfNTHr9P6hjQkUvLsHzPzkh4Kiz8VMah/w =8amf -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius wrote: > On 30/09/12 05:53 PM, Ciaran McCreesh wrote: > > On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring > > wrote: > >>> The second is that it starts the conceptual shift from "cat/pkg > >>> is a build dep, and cat/pkg is a run dep" to "cat/pkg is a dep > >>> that is required for build and run". > >> > >> Fairly weak argument at best; you're claiming that via labels, > >> "contextually they know it's these deps" in comparison to via > >> dep:build "contextually they know it's exposed only in build". > >> > >> Same difference. > > > > It's rather a big deal now that we have := dependencies. > > > > So you would using your labels syntax, specify an atom with a := dep > using certain labels and the same atom without ':=' on other labels? > I don't quite follow what you're getting at here as to how this is a > big deal.. A := only makes sense for a dependency that is present both at build time and at runtime. Currently, the only place you should be seeing a := is on a spec that is listed in both DEPEND and RDEPEND. Conceptually, the := applies to "the spec that is in both DEPEND and RDEPEND". But with the current syntax, there's no such thing as "the spec that is in both". There are two specs, which happen to be identical as strings, one in DEPEND and one in RDEPEND, and there's no way for the two to be associated. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBrKsEACgkQ96zL6DUtXhEyOACfQgN7K9iPf0o8NF4w95HpFq3j MHQAoKwMwmbJHuF65PIX9b6W0EQLqukl =pzQn -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/09/12 05:53 PM, Ciaran McCreesh wrote: > On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring > wrote: >>> The second is that it starts the conceptual shift from "cat/pkg >>> is a build dep, and cat/pkg is a run dep" to "cat/pkg is a dep >>> that is required for build and run". >> >> Fairly weak argument at best; you're claiming that via labels, >> "contextually they know it's these deps" in comparison to via >> dep:build "contextually they know it's exposed only in build". >> >> Same difference. > > It's rather a big deal now that we have := dependencies. > So you would using your labels syntax, specify an atom with a := dep using certain labels and the same atom without ':=' on other labels? I don't quite follow what you're getting at here as to how this is a big deal.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrKYUACgkQ2ugaI38ACPAMJAD9FzCH4ifbkanbC17w2KGjMHP7 G4qBrJ9v2dd7sHV338EA/iK/J+NZosc+M7wefJ8J6fU4mVczlM4WiOkCNVsTSO6w =Io2B -END PGP SIGNATURE-
Re: [gentoo-dev] Re: example conversion of gentoo-x86 current deps to unified dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/09/12 06:15 PM, Brian Harring wrote: > > Pardon the belated response; responding to emails that are quick > where possible, but lagging on -dev. Missed this one however... > No worries, there's a lot going on.. :D yngwin has a point that I've not seen addressed. What /is/ wrong with the whole CDEPEND intermediate var idea? >>> >>> The problem appears as we introduce more DEPEND variables >>> (which is what prompted the proposal, IIRC). If we have >>> ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some >>> (i.e. not total) sharing going on then the COMMON_DEPEND >>> pattern starts to fall apart. You potentially need, >>> >>> AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND >>> ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND >>> (COMMON_DEPEND) >>> >>> This obviously gets worse as more DEPEND vars are introduced. >>> >> >> Well not really, no -- the additional *DEPENDs that are being >> proposed (or at least mentioned) for new EAPI will either remove >> atoms from COMMON_DEPEND/DEPEND/RDEPEND or will be used so >> tersely that a COMMON_DEPEND or other intermediate variable won't >> really be necessary for them. > > It depends on the dep type actually, and how we're viewing those > deps- if they must be complete or not. [ .. Snip! .. ] > > The point I'm trying to make here is that each dep phase should be > authorative; in doing so, you start getting a lot of potential > subsets (DEPEND is a subset of TDEPEND, TDEPEND isn't completely, > but mostly a subset of RDEPEND as RDEPEND is a likely a superset of > DEPEND; PDEPEND is a superset of RDEPEND). > > So... you could do COMMON_DEPEND, COMMON_TDEPEND, COMMON_RDEPEND in > the ebuild. Or you could just use a syntax form that allows you > to directly inline that up front, rather than having to muck around > w/ intermediate vars. > ... I think what you've just described here might be where the primary difference in thinking is for most of us, between moving to DEPENDENCIES and keeping the current *DEPENDs -- to me, from an ebuild writer's perspective, the *DEPENDS -shouldn't- be authoritative. IE, instead of thinking of PDEPEND as a superset of RDEPEND I consider they are two separate sets, which should not intersect, and are unioned together to form the full set of runtime dependencies. IE: FULL_RUNTIME_DEPEND="$RDEPEND $PDEPEND" somewhere inside portage, if portage actually needed it this way. And I see this as how many of the other proposed new *DEPENDs would work too, ie, they are a refined subset of the bigger sets and should not intersect with the 'parent' *DEPEND that was used instead on older EAPIs. So if this were to change, it might make sense (as Duncan i think pointed out in his response to this message), to a debate on whether or not ebuilds must specify an authoritative list for each dep phase. (I haven't read through PMS but I'm going to assume that it doesn't specify this anywhere yet--and if it does, i'm sure Ciaran or someone will quote it in response :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrKKsACgkQ2ugaI38ACPBA9wD/a+XVf2g9s6dcpW1513aXQpYV tK94QdLkax0Hs6tKFqcA/0+v6oFON2Bd3hedv9DHg7N42NNvtTKK6sOw18OpL0aO =frmC -END PGP SIGNATURE-
Re: [gentoo-dev] Re: CIA replacement
Ben de Groot wrote: > > What is the source data, Still unanswered. I'll ask something which would be equally helpful: Where is the software that currently sends out emails to the -commits list? > > and what does the desired output look like? > > tetromino * gentoo-x86/x11-themes/gnome-themes-standard/ (7 files): > Version bump for gtk+-3.6; high contrast and low contrast > themes are no longer provided. Make license more precise.. > (Portage version: 2.2.0_alpha132/cvs/Linux x86_64) > ssuominen * gentoo-x86/xfce-extra/xfce4-power-manager/ (3 > files in 2 dirs): > Fix crash with en_GB locale wrt #419973 by Ciprian Ciubotariu > (Portage version: 2.2.0_alpha128/cvs/Linux x86_64) .. > tetromino proj/gnome:master * r78959387 > /dev-util/gdbus-codegen/ (gdbus-codegen-.ebuild > gdbus-codegen-2.33.14.ebuild): dev-util/gdbus-codegen: 2.34.0 now in > gx86 > > So basically: > > $committer $repo $path: > $changelog Well it's more complicated, but thanks for the sample output! //Peter
Re: [gentoo-dev] Re: CIA replacement
On 2 October 2012 23:56, Peter Stuge wrote: > Ben de Groot wrote: >> The -commits ML is okay (tho I don't want to subscribe to such a >> high-volume ML), but we miss an IRC interface. The website and >> statistics of cia.vc were nice too. > > What is the source data, and what does the desired output look like? > > (I mean what should the messages in channel look like.) We used to have it like this: tetromino * gentoo-x86/x11-themes/gnome-themes-standard/ (7 files): Version bump for gtk+-3.6; high contrast and low contrast themes are no longer provided. Make license more precise.. (Portage version: 2.2.0_alpha132/cvs/Linux x86_64) ssuominen * gentoo-x86/xfce-extra/xfce4-power-manager/ (3 files in 2 dirs): Fix crash with en_GB locale wrt #419973 by Ciprian Ciubotariu (Portage version: 2.2.0_alpha128/cvs/Linux x86_64) mr_bones_ * gentoo-x86/games-roguelike/falconseye/ (5 files in 2 dirs): games-roguelike/falconseye is gone mr_bones_ * gentoo-x86/profiles/package.mask: games-roguelike/falconseye is gone tetromino proj/gnome:master * r78959387 /dev-util/gdbus-codegen/ (gdbus-codegen-.ebuild gdbus-codegen-2.33.14.ebuild): dev-util/gdbus-codegen: 2.34.0 now in gx86 So basically: $committer $repo $path: $changelog -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Re: Lastrite: net-misc/mediatomb and www-apache/mod_musicindex
On Tue, 2 Oct 2012 03:48:20 -0400 Mike Frysinger wrote: > On Wednesday 26 September 2012 01:24:32 Ryan Hill wrote: > > On Tue, 25 Sep 2012 18:17:03 +0300 Samuli Suominen wrote: > > > # Samuli Suominen (25 Sep 2012) > > > # Multiple build failures: #435394, #423991 and #425806 > > > # Other bugs: #270830, #368409 > > > # Unmasking would require addressing the build failure bugs > > > # Removal in 30 days > > > net-misc/mediatomb > > > > I use this daily so I'll have a look if no one else does. > > i've fixed all the important bugs. if you want to look at the libav one, > that'd be nice (fedora might have a patch). and maybe double check the mozjs > one cause their documentation is non-existent. Groovy, thanks. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: CIA replacement
Ben de Groot wrote: > The -commits ML is okay (tho I don't want to subscribe to such a > high-volume ML), but we miss an IRC interface. The website and > statistics of cia.vc were nice too. What is the source data, and what does the desired output look like? (I mean what should the messages in channel look like.) //Peter
Re: [gentoo-dev] Re: Lastrite: net-misc/mediatomb and www-apache/mod_musicindex
On Wednesday 26 September 2012 01:24:32 Ryan Hill wrote: > On Tue, 25 Sep 2012 18:17:03 +0300 Samuli Suominen wrote: > > # Samuli Suominen (25 Sep 2012) > > # Multiple build failures: #435394, #423991 and #425806 > > # Other bugs: #270830, #368409 > > # Unmasking would require addressing the build failure bugs > > # Removal in 30 days > > net-misc/mediatomb > > I use this daily so I'll have a look if no one else does. i've fixed all the important bugs. if you want to look at the libav one, that'd be nice (fedora might have a patch). and maybe double check the mozjs one cause their documentation is non-existent. -mike signature.asc Description: This is a digitally signed message part.
