Re: [gentoo-dev] Call to Emacs Gentoo Devs: Help Make My Package Pretty?

On 9 May 2014 01:22, Jeroen Roovers wrote: > > Title of the mail is a little confusing/distracting/misleading ... > > It's proper English, and if you didn't immediately get it, the body > of the message did the job. Last time I checked, pidgin wasn't the norm > here. > Also, my apologies, I do n

Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

On 12 May 2014 21:35, Tom Wijsman wrote: > What about putting multiple doc / man / info files in a single .xz file > for each package? > How would one use them if they're installed as a single .xz file per package? Is there a trick that exists to allow this to even work for "man man" ? I'm gu

Re: [gentoo-dev] Re: perl-module.eclass: respect CFLAGS, LDFLAGS - please review

On 23 June 2014 01:02, Duncan <1i5t5.dun...@cox.net> wrote: > > The usual conditional for that is USE=custom-cflags or a similar variant > like custom-optimization. See the firefox ebuilds, which use both. > > $ equery -N u firefox | grep custom > - - custom-cflags: Build with user-speci

Re: [gentoo-dev] Re: perl-module.eclass: respect CFLAGS, LDFLAGS - please review

On 23 June 2014 06:13, Andreas K. Huettel wrote: > > PERL_CFLAGS_HANDLING=yes > inherit perl-module > I'd probably go with PERL_C_BINDINGS=yes or PERL_XS=yes or similar. Because there's probably other things that we can infer from that property and use for other things. And its reasonably

Re: [gentoo-dev] Re: perl-module.eclass: respect CFLAGS, LDFLAGS - please review

On 23 June 2014 07:10, Kent Fredric wrote: > I'd probably go with PERL_C_BINDINGS=yes or PERL_XS=yes or similar. > > Because there's probably other things that we can infer from that property > and use for other things. > > > And its reasonably straight forward t

Re: [gentoo-dev] Is || ( Atom... ) broken?

On 8 July 2014 00:45, James Potts wrote: > > In this case, it would be nice if Portage would see if one package of > the set could be resolved without blocks or required config changes > (i.e. if one package can be installed *now* choose it over > earlier-listed not-installable packages). The pr

Re: [gentoo-dev] last rites: virtual/perl-Filter

On 8 July 2014 06:59, Andreas K. Huettel wrote: > # Filter never was part of core Perl, no idea why we have a virtual. > # It was moved from perl-core to dev-perl and the virtual will be > # removed. Please depend on dev-perl/Filter directly. > virtual/perl-Filter > https://metacpan.org/release/

Re: [gentoo-dev] Re: Is || ( Atom... ) broken?

On 8 July 2014 16:39, Duncan <1i5t5.dun...@cox.net> wrote: > But from the sound of things, default backtrack=10, multilib, full > @system set and default profile use, on spinning rust, is getting all but > intolerable now. =:^( > I'm not sure I follow what scenario is happening to make it so slow

Re: [gentoo-dev] don't rely on dynamic deps

On 22 July 2014 19:25, "Paweł Hajdan, Jr." wrote: > On 7/21/14, 11:52 PM, Alexander Berntsen wrote: > > Michał has documented the shortcomings of dynamic deps in our wiki[0]. > > (Thank you!) This documentation also includes two of our possible > > solutions. > > > > [0]

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 27 July 2014 02:12, Martin Vaeth wrote: > > Do not forget modification of eclasses which then require mass bumps! I'm curious what the -r1.1 technique would do here. I mean, wouldn't that mean you have 2 ebuilds that are identical except for the '.1' simply due to the eclass change? That's

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 27 July 2014 19:16, Martin Vaeth wrote: > Not at all, it is completely identical to a revision bump: > If you would use -r2 instead of -r1.1, you also would end up > in -r1 and -r2 being identical. > Actually, in both cases, you would *remove* -r1, since -r1 is incorrect > since it should have

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 02:42, Rich Freeman wrote: > One thing I would question in that table is "applied immediately (but > can break hard when dynamic-deps stop working))." How can dynamically > removing an "unused dependency" cause something to break, setting > aside bugs in the package manager? If

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 03:52, Rich Freeman wrote: > Why? Is this about removing an unused dependency? > > > 3. Gentoo simply tweaks the ebuild and doesn't bump [A] > > What is "[A]?" What ebuild was tweaked, and how was it tweaked? > Here, "A" is the derived version of the ebuild of "Foo" the user in

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 08:56, Ciaran McCreesh wrote: > > To me it seems like a simple data model bug that vdb does not get > > updated to reflect the new situation after step 2 above. > > Rewriting VDB won't help if the user doesn't sync at the right time. > Indeed. pkgmove has this problem solved with

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 09:34, Rich Freeman wrote: > and if it doesn't work for them, > they'll sync in the updates one way or another (using an overlay if > necessary). > However, in the case the package gets removed from tree, an updates based approach would allow the dependencies to be cleaned up lon

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 28 July 2014 09:46, Rich Freeman wrote: > Then portage could look for any change in state and that would trigger > a build-less re-merge, which would update vdb with the new state > (including the new hash). > If we're scared about this being worse than what we have, I notice there's a bunch

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 29 July 2014 19:33, Peter Stuge wrote: > I think the vdb can and should be updated according to portage changes. > > Someone just needs to code it. ;) > And an appropriate method for doing this must be decided upon. And that part entails >70% of the discussion dispute :) -- Kent *KENTNL*

Re: [gentoo-dev] minimalistic emerge

On 9 August 2014 01:12, Igor wrote: > Most of the maintainers just depend on new > packages not knowing if it's necessary or not resulting in a really HUGE > update that in the absolute majority of cases destabilize GENTOO making it > not operational and WORSE than it was before. You then STABILI

Re: [gentoo-dev] minimalistic emerge

On 9 August 2014 04:58, Igor wrote: > Maintainers have no feedback from their ebuilds, they all do their best > but there are no tools > to formalize their work. No compass. They have no access to user > space where the packages are installed, unaware how users are using their > ebuilds. It's the

Re: [gentoo-dev] minimalistic emerge

On 9 August 2014 07:34, Peter Stuge wrote: > ebuilds often (for me) have artificial dependencies, when the actual > version required is too old to be in the tree, but maybe not too old > to be installed on an existing system. > The inverse is also true, sometimes you see people go: "Well, upst

Re: [gentoo-dev] minimalistic emerge

On 9 August 2014 08:52, Igor wrote: > Hello Kent, > > Friday, August 8, 2014, 9:29:54 PM, you wrote: > > But it's possible to fix many problems even now! > > What would you tell if something VERY simple is implemented like - > reporting > every emerge failed due to slot conflict back home with d

Re: [gentoo-dev] minimalistic emerge

On 9 August 2014 09:39, Ian Stakenvicius wrote: > *AND* (just to tie this back) it's unlikely that this is going to > actually help the original issue posted, ie, reducing the amount of > dependency updates being done "unnecessarily" on a system, or making > blind/automated system updates (of the

Re: [gentoo-dev] A constructive reommendation on stablity improvemt

On 10 August 2014 04:18, Igor wrote: > 5. Wait for server-side implementations to appear. They will appear once >emerge can report. And once it's clear for the rest that there is > seriously >going to be a change soon. > It really needs to be designed from the server side, not the client

Re: [gentoo-dev] A constructive reommendation on stablity improvemt

On 10 August 2014 06:15, Igor wrote: > Communication protocol is already there - it's HTTP, method POST > HTTP protocol is already with Python - CURL, WGET > A reliable server ready to accept data from portage is all so there - > it's Apache web server. For the sake of this discussion, those p

Re: [gentoo-dev] A constructive reommendation on stablity improvemt

On 10 August 2014 07:22, Jeroen Roovers wrote: > > Example 2: Mr. I.B. User configured his system with CFLAGS=-fomg-faster > and now it generates a ton of build failures. All of these should go > to /dev/null, but there we are running an automated service that cannot > be taught how to distinguis

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On 17 August 2014 09:54, William Hubbs wrote: > I strongly oppose this change, because I feel it will make our > entire tree very unpredictable at best. I realize this might eliminate > boilerplating from our tree. Weighing that against the possible > ramifications in this big of a change in auto

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On 17 August 2014 19:03, Michał Górny wrote: > > > So if you could sculpt it to be broader by default and have less scope > for > > developer error, that'd be an improvement. > > > > --- code start -- > > ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack" > > inherit foo bar baz > > > > > > --- code

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

On 10 September 2014 10:23, Michał Górny wrote: > I don't understand your concern. I'm only saying we should stop relying > on that stupid out-of-repository herds.xml file and put the e-mail > address directly in metadata.xml. Bugzilla and bug assignment would > work pretty much the same -- excep

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 00:03, Michał Górny wrote: > This means we don't have to wait till someone figures out the perfect > way of converting the old CVS repository. You don't need that history > most of the time, and you can play with CVS to get it if you really do. > Once somebody works this out

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 02:40, Michał Górny wrote: > However, I'm wondering if it would be possible to restrict people from > accidentally committing straight into github (e.g. merging pull > requests there instead of to our main server). > Easy. Put the Gentoo repo in its own group. Don't give a

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 10:56, hasufell wrote: > According to Robin, it's not about rebasing, it's about signing all > commits so that messing with the blob (even if it has the same sha-1) > will cause signature verification failure. > Correct me if I'm wrong, but wouldn't a SHA1 attack on the tree

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 11:15, W. Trevor King wrote: > All cherry-pick and am do is apply one commit's diff to a different > parent. Changing the parent hash (which is stored in the commit body > [1]), so old signatures won't apply to the new commit. If there have > been other tree changes between

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 11:21, Patrick Lauer wrote: > iow, git doesn't allow people to work on more than one item at a time? > > That'd mean I need half a dozen checkouts just to emulate cvs, which > somehow > doesn't make much sense to me ... > Use the Stash. Or just commit items, then swap branch

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 11:25, hasufell wrote: > Robin said > > The Git commit-signing design explicitly signs the entire commit, > including blob contents, to avoid this security problem. > > Is this correct or not? > I can verify a commit by hand with only the commit object and gpg, but without a

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 13:06, Peter Stuge wrote: > even after > the commits. > I've even made branches in "detached head" state ( that is, without a branch ) and given them branches after the fact. After all, branches aren't really "things", they're just pointers to SHA1s, that get repointed to n

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 13:30, Tim Harder wrote: > I haven't run portage metadata regen on a beefy machine lately, but I > don't think it could keep up in all cases. Perhaps someone can prove me > wrong. > > Anyway, things could definitely be sped up if portage merges a few speed > tweaks used in pk

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 15 September 2014 22:10, Jauhien Piatlicki wrote: > So signing of git commits does not guarantee enough security (taking > that SHA1 is weak and can be broken), right? Could we than just use > usual (not thin) manifests? > However, the attackability of SHA1 may be entirely immaterial, because

Re: [gentoo-dev] git security (SHA-1)

On 17 September 2014 01:44, Ian Stakenvicius wrote: > bottom of the comment a clearsign on the contents of the commit? > I don't see that being useful as written, because that's presently exactly what git does. the very best I think you could do is sign the commit *diff*, ie: recursively compa

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 18 September 2014 08:02, Diamond wrote: > Git doesn't do this by default and it > will might be a nightmare to compare such revbumps by hand. > git diff -M1 -C1 ^ is usually sufficient to show new files as differences between similar files that were already there, including revbumps. --

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 18 September 2014 13:01, Rich Freeman wrote: > With git a revbump is: > cp foo-1.ebuild foo-2.ebuild > git add foo-2.ebuild > git commit > > (I left out changelogs, repoman, etc, since there is no change with > any of these, and I left out syncing the git repo.) > > There really is nothing new

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 19 September 2014 07:33, Diamond wrote: > Lets assume, that I don't want to scrap old ebuild yet. There's no git > cp command. git mv is just git rm + git add. That's what does it look > like (usual revbump with git add in reality): > > https://github.com/cerebrum/dr/commit/311df9b04d876f58474

Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)

On 19 September 2014 10:13, Diamond wrote: > P.S. As you see from description this option affects git performance. > So, we probably can arrive at a conclusion that git itself isn't good > at all for package management. Maybe there are better architectural > decisions for that. > Well. Yes. You'

Re: [gentoo-scm] Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

On 19 September 2014 06:51, Rich Freeman wrote: > > Git even allows the use of tools like meld to resolve conflicts, > besides the usual fill-the-file-with-diffs-to-cleanup approach. I'd personally discourage any kind of collision resolution in the merge itself. Mostly because I've been bitten

Re: [gentoo-dev] Re: git security (SHA-1)

On 21 September 2014 09:01, hasufell wrote: > Because there are other VCSs it is not a bug?? > > No, it just means "using SHA1 for making a repository work" is not a bug, just like using "i am number 6, parent is number 5" is not a "security" bug. > Of course it is a bug since it is in the gpg-

Re: [gentoo-dev] Re: git security (SHA-1)

On 21 September 2014 09:18, hasufell wrote: > Kent Fredric: > > > > He is proposing quite the opposite. He's saying "git is not secure in > this > > way, but lets not let that stop us, migrate and fix that after the fact > or > > we'll never

Re: [gentoo-dev] Re: git security (SHA-1)

On 21 September 2014 09:18, hasufell wrote: > I didn't see him saying that. It rather sounds like we want to have > thick signed Manifests and break pull requests and whatnot. > Those aren't the only options. We could of course develop a custom commit signature system, either in the commit itse

Re: [gentoo-dev] Add bc back to the stage3

On 28 September 2014 00:22, Ciaran McCreesh wrote: > > I agree. It's time to replace nano with Vim. http://i.imgur.com/qRNTQGi.png -- Kent *KENTNL* - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] [EBUILD] unknown description

On 17 October 2014 08:54, sp4ze wrote: > I looked the other ebuild using faad ( mpd, mplayer... ) but I see no > difference with mine. > grep faad /usr/portage/media-video/mplayer/metadata.xml Use external faad library for AAC decoding grep faad /usr/portage/media-sound/mpd/metadata.xml

Re: [gentoo-dev] RFC: new QA_NEEDED variable for files installed by pre-built binary packages with broken soname dependencies

On 8 November 2014 13:59, Zac Medico wrote: > Okay, sure. I'll save it for the day when someone finds a valid reason > to install binaries with broken soname deps (not likely). > Another candidate for a possible valid reason: https://bugs.gentoo.org/show_bug.cgi?id=460468 There's probably a be

Re: [gentoo-dev] REQUIRED_USE="test" vs. repoman

On 9 November 2014 09:06, Zac Medico wrote: > Since EAPI 5, you need to either add test to IUSE, or else we need to > add the test flag to IUSE_IMPLICIT in the base profile (that would > require some discussion of pros/cons). > It should have been needed on EAPI4 too, but due to a side effect of

Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

On 1/11/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote: On Wed, 2007-01-10 at 09:40 +0100, Jakub Moc wrote: > into pkg_setup and be done with it; no need for RESTRICT=sandbox or > ACCEPT_RESTRICT. Users can decide whether they really wish to install > such app and disable sandbox temporarily if t

Re: [gentoo-dev] deprecating /etc/make.profile

On 1/11/07, Marius Mauch <[EMAIL PROTECTED]> wrote: And I assume there is a non-trivial number of custom scripts out there using make.profile, but that's nothing we can do about. You could give them all a grace period for which have to comply with the new standard by then end of it, and have

Re: [gentoo-dev] deprecating /etc/make.profile

On 1/11/07, Ned Ludd <[EMAIL PROTECTED]> wrote: Or we/gentoo could just support it and stop breaking the end user. uh, the point was, what will happen to all those apps for users who switched to the -new- standard by using make.conf, who will therefore have no make.profile dir, so programs lo

Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

On 1/11/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote: getting quite hostile. The only thing I can possibly gather from this is you're intentionally being fucking dense, so it's not worth my time. How is it that you can ignore half an email and only respond to something out of context and then

Re: [gentoo-dev] [RFC]: gentoo-politics ML

On 6/7/07, Kumba <[EMAIL PROTECTED]> wrote: Anyways, thoughts? --Kumba +1 possible alternative names: gentoo-soap, gentoo-gossip ( not to be confused with net-im/gossip ) And just for fits and giggles, the occasional person can start a fake flame war just to keep us on our toes as to whats

Re: [gentoo-dev] [RFC] Non-Dev Contributors and the Tree

On 6/7/07, Michael Cummings <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...or, Trees and Tree Climbers: Shaking up the tree Comments? ~mcummings As a non-dev with not a lot of free time, I applaud this suggestion. However, my core fear is the potential for i

Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML

On 6/11/07, Ryan Hill <[EMAIL PROTECTED]> wrote: > 3) said increase means proctors/devrel have more work (meaning more > random outbursts at the proctors/devrel when folks realize that they > *are* going to enforce the behaviour rules, and that the outburstes > can be punished too). It should pr

Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML

On 6/12/07, Alexander Gabert <[EMAIL PROTECTED]> wrote: A Philosophy I picked up in a Politics chat room, was discuss problems & issues, not people. People in said room were repremanded for discussing others either directly or indirectly whether or not said persons were present ( this did exc

Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML

On 6/12/07, Alexander Gabert <[EMAIL PROTECTED]> wrote: There are others like him and there will be others after him. There were even people doing that before him. As with trolls, theres more where they came for, but that doesn't make gentoo-ML 'different' to as to how we slay a troll. I agr

Re: OT: gentoo-kindergarten (was: Re: [gentoo-dev] [RFC]: gentoo-politics ML)

On 6/13/07, Thilo Bangert <[EMAIL PROTECTED]> wrote: I want a gentoo-kindergarten list, where useless discussions like this (sub)thread can be directed to. kids, grow up! *cries in his corner* Yes mummy :] -- Kent ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x| print "enNO

Re: [gentoo-dev] QA issue: No stable skype in Tree

On 6/14/07, Vlastimil Babka <[EMAIL PROTECTED]> wrote: Also, ion3 was IIRC removed recently also for upstream trying to force new versions against our stable policy. And that was opensource. [U] x11-wm/ion3 Available versions: (~)20060326 (~)20061223 (~)20070318-r2 (~)20070506-r1 {doc ion3

Re: [gentoo-dev] QA issue: No stable skype in Tree

On 6/14/07, Abhay Kedia <[EMAIL PROTECTED]> wrote: On Thursday 14 Jun 2007 1:54:51 am Vlastimil Babka wrote: > > But maybe Skype is not so pressing to upgrade, just doesn't provide > distfiles anymore. Then maybe we don't have to obey, but still it's > really questionable if it should be marked s

Re: [gentoo-dev] Are you guys for real?

On 6/14/07, Jayson Vaughn <[EMAIL PROTECTED]> wrote: etc I'll be back. Love the distro, but Jesus the politics and the bitching gets out. From one non-dev to another: You'll be back. Once somebody has learnt the truth, most find they can only deny it for so long. :) I agree a lot of the

Re: [gentoo-dev] EAPI-1 (or >1, perhaps) Proposal: AND Dependencies

On 6/15/07, John R. Graham <[EMAIL PROTECTED]> wrote: I occasionally run across a package version dependency issue that cannot be elegantly solved by the current dependency syntax. Every time I've come across this, it's boiled down to a range. For example, package some-cat/foo has the followin

Re: [gentoo-dev] Re: EAPI-1 (or >1, perhaps) Proposal: AND Dependencies

On 6/18/07, Steve Long <[EMAIL PROTECTED]> wrote: Ciaran McCreesh wrote: > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: >> > Paludis allows users to do some-cat/foo[>=4.0&<4-3] and >> > some-cat/foo[=4.1|=4.2|=4.3] . The syntax isn't particularly pretty, >> > but it's cleaner

Re: [gentoo-dev] Re: Re: EAPI-1 (or >1, perhaps) Proposal: AND Dependencies

On 6/19/07, Steve Long <[EMAIL PROTECTED]> wrote: Kent Fredric wrote: > If you can, try integrate a name based syntax into the requirement. > using decorative characters alone may have their uses, but there are > only so many you can use, and so many combinations you can create &g

Re: [gentoo-dev] Re: Re: QA issue: No stable skype in Tree

On 6/19/07, Steve Long <[EMAIL PROTECTED]> wrote: Chris Gianelloni wrote: > On Mon, 2007-06-18 at 06:01 +0100, Steve Long wrote: >> Stephen Bennett wrote: >> > Not everyone sees that as a reason not to use a potentially useful >> > piece of software. We're not debian. >> >> Could you clarify whet

Re: [gentoo-dev] Re: Pony Colour Schemes [was: QA issue: No stable skype in Tree]

On 6/19/07, Ryan Hill <[EMAIL PROTECTED]> wrote: Andrew Gaffney wrote: > Chris Gianelloni wrote: >> If the Gentoo developers as a whole decided to dedicate this list to >> pink ponies, we can. > > Are pretty purple ponies acceptable as well? As *everybody* knows, purple ponies aren't pretty.

Re: [gentoo-dev] Re: RFC: Unifying the behavior of the doc use flag and document it

On 6/25/07, Steve Long <[EMAIL PROTECTED]> wrote: Petteri Räty wrote: >> Maybe the flag needs to be renamed/split up to clarify it's meaning, >> it's too generic in it's current form (many people enable it blindly and >> don't really have any clue what the result is). >> Like using USE=apidoc for

Re: [gentoo-dev] Feedback req: Confirm/thank on bug fix or is that unwanted bug spam?

On 7/7/07, Duncan <[EMAIL PROTECTED]> wrote: When I open or CC on a bug that then gets fixed, I often feel like adding a thanks to the bug. However, while it may be polite in other circumstances, in this case it could be viewed as bug spam, so I've hesitated. I reviewed the bug reporting guidel

Re: [gentoo-dev] automated extended information gathering

On 7/8/07, Kevin Lacquement <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > > 5) considering 3), I'd rather see such information be specified by > ebuilds somehow, not a global file (think about overlays). Maybe by > installing a script in a specifi

Re: [gentoo-dev] automated extended information gathering

On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Saturday 07 July 2007, Kent Fredric wrote: > Implementation details wise, I would like to see packages have > possibly 2 functions, > 1: Info, and 2: Check. > Reason Being that you wont be able to fetch installation

Re: [gentoo-dev] automated extended information gathering

On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Saturday 07 July 2007, Kent Fredric wrote: > On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Saturday 07 July 2007, Kent Fredric wrote: > > > Implementation details wise, I would like to see

Re: [gentoo-dev] automated extended information gathering

On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: On Sunday 08 July 2007, Kent Fredric wrote: > Ok, I've re-thought some of my ideas and tried to come up with a more > concise explanation > with some practical example syntax. The basic concept of 'check' was

Re: [gentoo-dev] Gentoo

On 7/18/07, Michael Sullivan <[EMAIL PROTECTED]> wrote: On Fri, 2007-07-13 at 07:16 -0500, Rick Sivernell wrote: > I am trying to contact somebody in charge of gentoo. I have tried for years now to get my email address off your list, but all has failed. If someone knows this person or will sen

Re: [gentoo-dev] default desktop profile

On 8/2/07, Martin Schwier <[EMAIL PROTECTED]> wrote: > Hello developers, > > today I posted a bug (187475) about a minor issue about the useflag > libnotify not beeing in the default desktop profile. Me was told that > this sould be discussed on gentoo-dev. I can't really understand why > such a mi

Re: [gentoo-dev] Re: perl-5.10.1 status update

On Tue, Oct 27, 2009 at 11:10 PM, Torsten Veller wrote: > * Torsten Veller: > > After that I'll minimize my perl work if no more people join to help. > > Plan revised: I stop doing perl work right now. > > Thanks > > Sorry to see you go. Thanks for all that you have done so far anyway, its great

Re: [gentoo-dev] Re: QA: package.mask policies

On Sun, Nov 8, 2009 at 1:08 PM, Nirbheek Chauhan wrote: > On Sun, Nov 8, 2009 at 12:33 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > 2) That won't necessarily stop the bugs from rolling in. Some devs may > > get tired of live pkg bugs and package.mask it, thus putting up a double- > > barrier to t

Re: [gentoo-dev] Re: RFC: split up media-sound/ category

On 22 June 2011 08:37, Michał Górny wrote: >> Right.  mplayer, xine, etc, work just fine as for instance mp3 >> players. So media- is fine for them. > > But probably we'll move it into media-players and so on then. mplayer and some other things most-often used for playback might be a bit of a

Re: [gentoo-dev] RFC: split up media-sound/ category

On 22 June 2011 21:38, Joshua Saddler wrote: > > Whatever happened to implementing tags for the Portage tree? The idea > behind tags was to avoid spamming users with more and more > directories, especially for apps that are hard to categorize. Which, Agreed. From the perspective of what will need

Re: [gentoo-dev] RFC: split up media-sound/ category

On 23 June 2011 09:46, Zac Medico wrote: > It could be implemented with a metadata.xml extension, or possibly an > new ebuild variable. A GLEP would be a good way to propose such an > extension. I'd myself see metadata.xml or ebuild variables, on their own, less than useful. For me, the primary

Re: [gentoo-dev] Re: Tags (Was: RFC: split up media-sound/ category)

Another question I think that needs be asked, is "What does a tag look like", or "What sort of values can a 'tag' have?". People are probably assuming it will be some arbitrary name like "video" or "sound" or soforth, but there is potential to use tags for more than that. Consider ideas such as t

Re: [gentoo-dev] Re: Tags (Was: RFC: split up media-sound/ category)

On 24 June 2011 20:14, Wyatt Epp wrote: > On Fri, Jun 24, 2011 at 02:51, Ciaran McCreesh > wrote: >> If you abolish categories in favour of tags, but tags don't uniquely >> identify a package, how do you uniquely identify a package? >> >> Remember that your solution has to work with overlays and

Re: [gentoo-dev] Re: Tags (Was: RFC: split up media-sound/ category)

On 25 June 2011 00:51, Nathan Phillip Brink wrote: > On Wed, Jun 22, 2011 at 11:20:40PM -0400, Wyatt Epp wrote: >> I bring this up because there are several packages with the same name >> and different qualification.  Obviously, they'll have different tags >> because they're not the same thing, bu

Re: [gentoo-dev] Tags (Was: RFC: split up media-sound/ category)

On 25 June 2011 00:57, Nathan Phillip Brink wrote: > On Wed, Jun 22, 2011 at 08:57:47PM -0400, Wyatt Epp wrote: >> >> media >> video >> kde >> editors >> > I'm strongly of the mind that by making the tag system arbitrarily flat, you might be prematurely limiting yourself, as well as risking a

Re: [gentoo-dev] RFC: split up media-sound/ category

On 25 June 2011 23:55, Maciej Mrozowski wrote: > > IMHO the best approach is to forget about categories and: > > - make package names unique identifiers (it's not that hard, renaming stuff in > app-xemacs mostly) - categories would serve no purpose as id anymore (though > may need to be provided a

Re: [gentoo-dev] Re: RFC: split up media-sound/ category

On 26 June 2011 05:29, Ulrich Mueller wrote: >> On Sat, 25 Jun 2011, Maciej Mrozowski wrote: > >> Assuming package names are unique identifiers, tags are not >> necessary to be available for ebuild.sh so metadata.xml is the best >> place. > > But we know that package names are _not_ unique. Th

Re: [gentoo-dev] Re: RFC: split up media-sound/ category

On 26 June 2011 15:49, Wyatt Epp wrote: > As for the latter part, the size of a git repo becoming umanageable > over time had not occurred to me, I'm afraid-- would it work to use > shallow clones?  Otherwise, the herd-wise division is probably > acceptable.  Need to think about that one more.

Re: [gentoo-dev] Thoughts about broken package handling

On 26 June 2011 17:44, Benedikt Böhm wrote: > these just exist because python and perl ebuilds are horribly broken. > take a look at RUBY_TARGETS or PHP_TARGETS for an example of how to do > it right. this would also fix all the failures that python and perl > introduce to binary packages. Perl d

Re: [gentoo-dev] Thoughts about broken package handling

On 26 June 2011 14:59, Stuart Longland wrote: > Hi all, > > I've been busy for the past month or two, busy updating some of my > systems.  In particular, the Yeeloong I have, hasn't seen attention in a > very long time.  Soon as I update one part however, I find some swath of > packages break beca

Re: [gentoo-dev] Re: RFC: split up media-sound/ category

2011/6/26 Jesús J. Guerrero Botella : > I am really amazed that someone didn't want to use links (a solution > with next to zero work involved) because they are not available in > fat32 (as if fat32 was relevant at all for us) but then people is > suggesting that we should put everything into a fla

Re: [gentoo-dev] Re: RFC: split up media-sound/ category

On 26 June 2011 21:53, Patrick Lauer wrote: > > I disagree. If I put postgresql in x11-libs that's just wrong, and then > you fix it with a package move. Doesn't mean the category system is > broken, just means that it was in the wrong place at the wrong time. > >> >> As far as app-xemacs is conce

Re: [gentoo-dev] Are tags just sets?

On 26 June 2011 19:02, Ciaran McCreesh wrote: > Here's a completely different way of doing tags: > > First, standardise sets. We probably want to go with a format along the > lines of: > >    eapi = 4 >    description = Monkeys > >    dev-monkey/howler >    dev-monkey/spider >    >=dev-monkey/span

Re: [gentoo-dev] Re: RFC: split up media-sound/ category

On 26 June 2011 23:40, Rich Freeman wrote: > > I think we should avoid changing the fundamental design of portage, > such as removing categories or allowing tags to be used as > dependencies/etc.  At least, not right now.  If we set up namespaces > for tags that might allow for such a thing in the

Re: [gentoo-dev] Are tags just sets?

On 27 June 2011 03:12, Maciej Mrozowski wrote: > > I see major disadvantage with this approach. It's painful to maintain. > Imagine hundreds of different tags, with each package having at least two > tags. You certainly don't expect anyone to be able to maintain that. > Also those files cannot be

Re: [gentoo-dev] SHA256 and indention in metadata.xml

On 27 June 2011 03:20, Maciej Mrozowski wrote: >> I personally prefer tabs, but I also like using EAPI="", >> sorting everything alphabetically and even use the following depend blocks: > >> *DEPEND=" >>       !>       !Y >>       >>       >>       ... >>       >>       a? ( ) >>       b? ( )

Re: [gentoo-dev] Are tags just sets?

On 28 June 2011 15:26, Brian Harring wrote: > This is a bit inverted- tagging is fundamentally pkg specific.  If we > did as you proposed and I wanted to find out all tags/descriptions for > a pkg, the PM would have to scan every tags file there. > > Additionally, as others have indicated, it suck

Re: [gentoo-dev] Re: Thoughts about broken package handling

On 28 June 2011 04:44, Graham Murray wrote: > Ciaran McCreesh writes: > >> The fix for that is to slot things properly. You're screwed anyway if a >> preserved library tries to access installed data that has either been >> removed or upgraded to a new format that it doesn't recognise. > > Or some

Re: [gentoo-dev] [Council] ChangeLog generation within Gentoo

On 27 October 2011 06:33, Bruno wrote: > > Is there some guideline about old entries in the ChangeLog? > > Over the past months ChangeLogs represent a big part of the tree, some > of them being pretty big and going back many changes (hundreds of them) > and years (even for actively maintained ebu

Re: [gentoo-dev] Old changelogs / eclass dir

On 27 October 2011 06:46, Andreas K. Huettel wrote: > > 2) I'd like to suggest that for changelogs that grow beyond a certain size > (e.g. profiles/ChangeLog) > the file is "rotated" similar to /var/log logfiles. I.e. the current file > is renamed with a date extension and a > new file is started

<    1   2   3   4   5   6   7   8   9   >