On 11/02/2014 03:08 AM, Rich Freeman wrote:
>
> Well, nothing is ever ideal, but as issues come up they are being
> dealt with now. I can't think of any situations where somebody has
> been able to block out new contributors in the last year or two.
> Sure, there have been a few attempts, but we'
On 11/01/2014 01:18 AM, Rich Freeman wrote:
>
> What we can't do is force somebody to contribute. If somebody says
> that if we don't do multilib their way, they'll stop being the only
> libreoffice maintainer, and nobody else wants to maintain libreoffice,
> then we are left in a hard place (com
On 10/31/2014 05:58 PM, Jeroen Roovers wrote:
> On Fri, 31 Oct 2014 16:28:56 +
> Diego Elio Pettenò wrote:
>
>> So who wants to pick up the pieces now? Because I'm almost pissed off
>> enough to turn down the tinderbox and give a big FU to Gentoo already.
>> https://bugs.gentoo.org/show_bug.c
Patrick Lauer (patrick):
> patrick 14/10/27 02:58:21
>
> Modified: stone-soup-0.14.1.ebuild
> stone-soup-0.15.1-r1.ebuild
> stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild
> stone-soup-0.14.2.ebuild ChangeL
Rich Freeman:
>
> If maintainers want to NEEDINFO or WONTFIX a tinderbox bug, well,
> they'll be the ones picking up the pieces when the gcc upgrade moves
> ahead.
We are all picking up the pieces.
> I don't get why anybody wouldn't like seeing them.
>
I do, it's childish and uncollaborative b
Kent Fredric:
> 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
>
We need a moderated development mailing list.
Michał Górny:
> Dnia 2014-09-19, o godz. 18:17:12
> "Andreas HAttel (dilfridge)" napisał(a):
>
>> dilfridge14/09/19 18:17:12
>>
>> Modified: ChangeLog perl-module.eclass
>> Log:
>> Remove support for EAPI 1, 2, 3 in perl-module.eclass (no packages left in
>> the tree)
>
>
On 09/22/2014 08:40 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 22 Sep 2014, hasufell wrote:
>
>> Ulrich Mueller:
>>> | • atomic commits (one logical change)
>>>
>>> A version bump plus cleaning up older ebuilds will be considered
>>> o
Ulrich Mueller:
>>>>>> On Sun, 21 Sep 2014, hasufell wrote:
>
>> https://wiki.gentoo.org/wiki/Gentoo_git_workflow
>
>> But so far, not many people have been particularly interested in the
>> details of these things. I'm also not sure if the ML
Tobias Klausmann:
> When we do the migration, there _will_ be
> confusion and breakage and those who actually have deep knowledge
> will likely cringe a lot. Documentation is the way out of that.
>
https://wiki.gentoo.org/wiki/Gentoo_git_workflow
But so far, not many people have been particularl
Ulrich Mueller:
>> On Sun, 21 Sep 2014, Michał Górny wrote:
>
>> Do you really consider keeping a key open for machine signing
>> somewhat secure?
>
> You mean, as compared to manifests (or commits) signed by 250
> different developers' keys?
>
That's the actual security problem in gentoo:
Ulrich Mueller:
>
> Full manifests could be generated automatically (and signed with an
> infra key) when copying the tree from the repository to the master
> mirror.
>
Would you like to implement it?
You'v quoted the wrong guy.
Ulrich Mueller:
>> So you are suggesting to not migrate at all or severely break the
>> workflow because someone might forge _working code_ with a specific
>> SHA1? There is no efficient algorithm for that afaik, those are just
>> about finding _any_ collision and even then it takes considerable
>>
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 get around to it, because all this debate is the perfect being
> the enemy of the good".
>
I didn't see him say
Ulrich Mueller:
>>>>>> On Sat, 20 Sep 2014, hasufell wrote:
>
>>> Have these plans been abandoned, and are we now planning to
>>> distribute the tree to users via Git, where everything goes through
>>> the bottleneck of a SHA-1 sum, which was neve
Ulrich Mueller:
>
> Have these
> plans been abandoned, and are we now planning to distribute the tree
> to users via Git, where everything goes through the bottleneck of a
> SHA-1 sum, which was never intended as a security feature?
>
This is a bug in git. Do you want us to wait until it is reso
Rich Freeman:
> On Sat, Sep 20, 2014 at 12:48 PM, hasufell wrote:
>> Steven J. Long:
>>
>>> Either way, I don't think the discussion about Changelogs should *at all*
>>> affect the move to git;
>>
>> Correct, because this wouldn't even be a
Steven J. Long:
>
> VCS commit messages are very different to the ebuild Changelogs ime.
Yes, but this does not even apply to the current gentoo CVS workflow
(compare the cvs commit messages with the ChangeLog entries, e.g. for
sys-apps/portage).
> I would ask that you consider the different pur
Rich Freeman:
>
> Would it make more sense to use a migrated repository as the starting
> point, such as this one:
> https://github.com/rich0/gentoo-gitmig-2014-09-15
>
Not sure why. The old history is irrelevant for testing git workflow.
The repository is also fairly small, even without shallo
Ian Stakenvicius:
>> I wonder if it would make sense to set up a practice git tree
>> somewhere so that people can try working together on workflows/etc.
>> We can clone a migrated tree (I have one from a few days ago on
>> github).
>
> Definitely. I'd volunteer for that (doing my updates to bot
Ian Stakenvicius:
> Git on the other hand will update the entire
> tree and there's no way around that, right?
Yeah, people have to understand that we cannot map the cvs workflow 1:1
to git.
That's for a reason and that little inconvenience it causes is pretty
minor compared to the breakage CVS a
Tobias Klausmann:
>>>
>>> If this should really turn out to be a problem, then we could also:
>>>
>>> 4) Replace git's default merge driver by our own one that is better
>>> suited for ebuilds. This can be done per repository via .git/config
>>> and .gitattributes.
>>>
>>
>> Certainly that would be
hasufell:
>
> First draft and only the basic ebuild workflow.
>
I'm working out the rest here
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#step_by_step_example_.28ebuild.29
Daniel Campbell:
> As a prospective Gentoo developer, having a guide around meant
> specifically for Gentoo's practices would be incredibly helpful. I use
> git in my own hobby development and learned from Pro Git, et al, but
> it'd still be really nice to have, and give developers a place to
> poi
Aaron W. Swenson:
>
> This is what's been driving me batty. None of you verified my identity
> before letting me be an official Gentoo Developer. Yet I have access to
> the repo. All I had to do was complete the quizzes.
>
The only way to improve security in the sense of random collaborators is
Luca Barbato:
> On 15/09/14 01:21, Patrick Lauer wrote:
>> On Sunday 14 September 2014 15:42:15 hasufell wrote:
>>> Patrick Lauer:
>>>>> Are we going to disallow merge commits and ask devs to rebase local
>>>>> changes in order to keep the history
Michael Orlitzky:
> On 09/16/2014 10:03 AM, Rich Freeman wrote:
>>
>> The gpg signature is on the entire contents of the "commit." However,
>> the contents of the commit do not include the files that are being
>> committed - it includes hashes of the parent commit, the commit
>> message, other hea
Rich Freeman:
> On Tue, Sep 16, 2014 at 6:18 AM, hasufell wrote:
>> Ulrich Mueller:
>>>
>>> ChangeLogs are aimed at users
>>
>> Did any1 ask them if they care?
>>
>
> I'm sure somebody will reply and say that they care.
>
>
Ulrich Mueller:
>
> ChangeLogs are aimed at users
Did any1 ask them if they care?
Rich Freeman:
>
> I'm not sure ditching rsync entirely is necessary - it might be more
> trouble than it is worth as it is a very effective simple way to
> distribute the tree. However, I'm not really opposed to it either.
>
The few people I personally know who use gentoo never use rsync for
sy
Ian Stakenvicius:
>
> It's generally considered safe to push to origin/master a commit from
> a temporary local branch?
Why not?
Even if you have to rebase/merge, nothing will happen with your unstaged
local changes as long as no one has messed with the firefox ebuild in
the meantime... and then
hasufell:
> Ian Stakenvicius:
>>
>> Repeating my example, say i'm working on a new release of firefox, it
>> takes ~40 mins to compile and there's some stuff it needs to do with
>> files in ${FILESDIR} during src_install. So i'm 'ebuild ...
>&g
Ian Stakenvicius:
>
> Repeating my example, say i'm working on a new release of firefox, it
> takes ~40 mins to compile and there's some stuff it needs to do with
> files in ${FILESDIR} during src_install. So i'm 'ebuild ...
> install'ing that. In the meantime, there's a high-priority fix that
>
Ian Stakenvicius:
> On 14/09/14 09:06 PM, Peter Stuge wrote:
>> Rich Freeman wrote:
>>> If you just want to do 15 standalone commits before you push you
>>> can do those sequentially easily enough. A branch would be more
>>> appropriate for some kind of mini-project.
>> ..
>>> That is the beauty o
Rich Freeman:
>
> I suggest we just get git working in a fashion that is "good enough."
Sure, that's what I've been saying. Otherwise I'd propose to remove
access for everyone and only grant project leads/reviewers direct push
access. But as said... we are not ready for something like that.
Howe
Rich Freeman:
> It would make a lot more sense if we had a release-oriented strategy,
> even if releases were hourly/daily/etc.
>
If we are going that way, then we should think over the whole branching
model. I have a few things in mind, but I think we are already
fine-tuning stuff here that can
Ian Stakenvicius:
>
> I'm not that worried about the big (multi-package) commits, as it does
> make sense we're going to have difficulty and lots of potential
> conflicts there, but aren't we going to run into this issue just with
> multiple people committing separate single-package commits at the
Rich Freeman:
> On Mon, Sep 15, 2014 at 9:13 AM, hasufell wrote:
>> Yes, you have to rerun repoman after a rebase or merge. On the tip of
>> the local master branch (as in: right before you try to push).
>>
>> Sure, this may lead to problems if repoman takes long... b
Rich Freeman:
> On Mon, Sep 15, 2014 at 7:37 AM, hasufell wrote:
>> * repoman must be run from all related directories (or the top-level
>> directory) on the latest commit that is being pushed
>
> This should be clarified. Does repoman need to be run on the exact
> com
hasufell:
>
> * there is no known SHA-1 collision afais
> * calculating one isn't that hard. NSA might be able to do it in
> reasonable time
> * however, the algorithms to do that will come up with random garbage,
> so it's a completely different thing to hide a use
Andreas K. Huettel:
>>
>> However, rebasing changes *on* master, before they are pushed, is a good
>> thing, because that kills non-fast-forward merges.
>>
>
> Nontrivial rebases *on* master can be problematic because you're changing
> history.
>
> Imagine you pull some nice commits from a user
Jauhien Piatlicki:
> Hi,
>
> On 09/15/2014 01:37 AM, Kent Fredric wrote:
>> On 15 September 2014 11:25, hasufell wrote:
>>
>>> Robin said
>>>> The Git commit-signing design explicitly signs the entire commit,
>>> including blob contents, to avoi
Patrick Lauer:
> On Monday 15 September 2014 11:27:34 Kent Fredric wrote:
>> 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
>>> does
Patrick Lauer:
> On Sunday 14 September 2014 15:42:15 hasufell wrote:
>> Patrick Lauer:
>>>> Are we going to disallow merge commits and ask devs to rebase local
>>>> changes in order to keep the history "clean"?
>>>
>>> Is that going to
Rich Freeman:
> On Sun, Sep 14, 2014 at 6:56 PM, 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.
>>
&g
W. Trevor King:
> On Sun, Sep 14, 2014 at 10:38:41PM +0000, hasufell wrote:
>> Yes, there is a possible attack vector mentioned in this comment
>> https://bugs.gentoo.org/show_bug.cgi?id=502060#c16
>
> From that comment, the point 1.2 is highly unlikely [1]:
>
> 1. A
W. Trevor King:
> On Sun, Sep 14, 2014 at 05:40:30PM +0200, Michał Górny wrote:
>> Dnia 2014-09-15, o godz. 03:15:14 Kent Fredric napisał(a):
>>> Only downside there is the way github pull reqs work is if the
>>> final SHA1's that hit tree don't match, the pull req doesn't
>>> close.
>>>
>>> Soluti
"C. Bergström":
> Pretty please do NOT allow "merge" commits.. they are the bane of evil
> for the long term ability to have any sane work-flow.
It works pretty well for the linux kernel.
Ofc it's a matter of actually handling it. If people are unable to
properly handle tools/methods, everything
William Hubbs:
> On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
>>
>>> Deciding on a _commit policy_ should be fairly straightforward and we
>>> already have one point
>>> * gpg sign every commit (unless it's a merged branch, then we only care
>>> about the merge commit)
>>
>>
Rich Freeman:
> On Sun, Sep 14, 2014 at 10:56 AM, Michał Górny wrote:
>> Dnia 2014-09-14, o godz. 10:33:03
>>
>> With git, we can finally do stuff like preparing everything and pushing
>> in one go. Rebasing or merging will be much easier then, since
>> the effective push rate will be smaller than
Patrick Lauer:
>> Are we going to disallow merge commits and ask devs to rebase local
>> changes in order to keep the history "clean"?
>
> Is that going to be sane with our commit frequency?
>
You have to merge or rebase anyway in case of a push conflict, so the
only difference is the method and
Rich Freeman:
>
> This is one of the blockers. We haven't actually decided how we want
> to use git.
>
There are IMO 3 main things to consider for a git workflow:
* commit policy
* branching model
* remote model
(and history format somewhere implicitly)
Deciding on a _commit policy_ should be
Jauhien Piatlicki:
>
> Or well, have our own pull requests review tool.
>
>
Also only a secondary problem. Mirroring on github/bitbucket whatever
should be fairly straightforward to allow user contributions.
In addition the usual git workflow via e-mail/ML would become more
popular (either via
Davide Pesavento:
>> Main developer repo
>> ---
>>
>> I was able to create a start git repository that takes around 66M
>> as a git pack (this is how much you will have to fetch to start working
>> with it). The repository is stripped clean of history and ChangeLogs,
>> and has thin
Jauhien Piatlicki:
>
> Again, how will user check the integrity and authenticity if Manifests are
> unsigned?
>
While this is an issue to be solved, it shouldn't be a blocker for the
git migration.
There is no regression if this isn't solved. There is no sane automated
method for verifying sig
Jauhien Piatlicki:
> In the ideal country of elves. In the real life it can be not possible to
> build and install software in a given distribution without downstream
> patches. You can find examples of such live ebuilds in Gentoo tree.
I think it's not appropriate and shouldn't generally be do
Tom Wijsman:
> On Wed, 10 Sep 2014 15:09:38 +
> hasufell wrote:
>
>> Tom Wijsman:
>>>> It improves usability by providing additional information.
>>>
>>> Usability is not to be found in information that is subject to
>>> change
Tom Wijsman:
>> It improves usability by providing additional information.
>
> Usability is not to be found in information that is subject to change.
>
Please also set DEPEND, RDEPEND, EGIT_REPO_URI, DESCRIPTION and the rest
of them to "", because they are all subject to change.
> So, both quot
Tom Wijsman:
> On Tue, 09 Sep 2014 19:12:28 +
> hasufell wrote:
>
>> Jauhien Piatlicki:
>>>
>>> When I accept ~arch I expect that no live ebuilds will be built. I
>>> think other gentoo users expect the same.
>>
>> Just because users a
Jauhien Piatlicki:
>
> When I accept ~arch I expect that no live ebuilds will be built. I think
> other gentoo users expect the same.
Just because users are used to it doesn't make it better.
>
> Emerging live ebuild usually is quite a risky thing, so hiding such stuff
> behind dropped keywor
Michał Górny:
>
> And how can you test a VCS ebuild? You can't assume upstream will be
> stuck on one commit.
>
I don't see the argument. It sounds like you are saying "one day,
upstream might stop supporting architecture xy, so better we just omit
all of them from KEYWORDS". Err?
For example,
Michał Górny:
> Dnia 2014-09-09, o godz. 17:41:27
> hasufell napisał(a):
>
>> Samuli Suominen:
>>>
>>> On 08/09/14 06:47, Rick "Zero_Chaos" Farina wrote:
>>>> On 09/07/2014 09:03 PM, Rich Freeman wrote:
>>>>> Right now
Samuli Suominen:
>
> On 08/09/14 06:47, Rick "Zero_Chaos" Farina wrote:
>> On 09/07/2014 09:03 PM, Rich Freeman wrote:
>>> Right now the general policy is that we don't allow unmasked (hard or
>>> via keywords) ebuilds in the tree if they use an scm to fetch their
>>> sources. There are a bunch o
Patrick Lauer:
>
That means either say "you cannot expect anything, because there might
or might not be metadata" or say "you can expect metadata for any
provided/installed package" in which case package.provided feature has
to be removed from portage.
>>>
>>> "Provided" means
Anthony G. Basile:
> On 09/07/14 22:36, Patrick Lauer wrote:
>> On Saturday 06 September 2014 16:22:46 hasufell wrote:
>>> Anthony G. Basile:
>>>> On 09/06/14 12:12, hasufell wrote:
>>>>> Anthony G. Basile:
>>>>>>> And when yo
Patrick Lauer:
> On Saturday 06 September 2014 16:22:46 hasufell wrote:
>> Anthony G. Basile:
>>> On 09/06/14 12:12, hasufell wrote:
>>>> Anthony G. Basile:
>>>>>> And when you do ask, is a package that's "provided" installed, and if
Anthony G. Basile:
> On 09/06/14 12:12, hasufell wrote:
>> Anthony G. Basile:
>>>> And when you do ask, is a package that's "provided" installed, and if
>>>> so, what's its metadata?
>>>>
>>> When the package is installed
Anthony G. Basile:
>>
>> And when you do ask, is a package that's "provided" installed, and if
>> so, what's its metadata?
>>
>
> When the package is installed, that data should have been cached.
>
Afaik there is nothing "cached" if you put stuff in package.provided.
It's a terrible hack, unless
Anthony G. Basile:
>>
>>> A list of all files belonging to the package, along with a designation
>>> of the file type (regular, directory, symlink, pipe, etc), MD5SUM or
>>> other checksum, and mtime time.
>> Packages aren't allowed to install pipes.
>
> Okay I will remove pipes. Do you have a re
Yixun Lan (dlan):
>
> EAPI=5
>
> AUTOTOOLS_AUTORECONF=1
> AUTOTOOLS_IN_SOURCE_BUILD=1
> inherit autotools-utils
>
> DESCRIPTION="Command line tools and C library for accessing Mega cloud
> storage"
> HOMEPAGE="https://github.com/megous/megatools";
> SRC_URI="https://github.com/megous/${PN}/arch
Patrick Lauer:
> On Sunday 31 August 2014 11:39:22 hasufell wrote:
>> Martin Vaeth:
>>> hasufell wrote:
>>>> On 08/30/2014 02:35 PM, J. Roeleveld wrote:
>>>>> For net-im/skype,
>>>>
>>>> Screw skype.
>>>
>>> P
Martin Vaeth:
> However, until that day is reached, please do not think about
> removing skype from the portage tree.
>
You have confused something. I did not say that anywhere.
Martin Vaeth:
> hasufell wrote:
>> On 08/30/2014 02:35 PM, J. Roeleveld wrote:
>>>
>>> For net-im/skype,
>>
>> Screw skype.
>
> Please don't. Not all communication partners are linux users.
>
Tox is multiplatform.
>> We have tox [1
On 08/30/2014 02:35 PM, J. Roeleveld wrote:
>
> For net-im/skype,
Screw skype. We have tox [1] on the way. Try tox-overlay (not in tree,
because there is no release yet, however it already works relatively well).
[1] https://tox.im
Michał Górny:
>> sed -i -e '/^CPPFLAGS\s*=/ s/-g //' \
>> qmake/Makefile.unix || die "sed failed (CPPFLAGS for
>> qmake build)"
>>
>> # Respect CXX in {bsymbolic_functions,fvisibility,precomp}.test
>> sed -i -e "/^QMAKE_CONF_COMPILER=/ s:
Kristian Fiskerstrand:
> On 08/19/2014 10:46 PM, hasufell wrote:
>> "Paweł Hajdan, Jr.":
>>> On 8/19/14 1:00 AM, Robin H. Johnson wrote:
>>>> The new SSH keys, in case you still didn't have them: On Mon,
>>>> Jun 30, 2014 at 10:26:52PM +
"Paweł Hajdan, Jr.":
> On 8/19/14 1:00 AM, Robin H. Johnson wrote:
>> The new SSH keys, in case you still didn't have them:
>> On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote:
>>> 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA)
>>> 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:1
Chris Reffett:
>
>
> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" wrote:
>> Dnia 2014-08-18, o godz. 09:22:46
>> Chris Reffett napisał(a):
>>
>>> On 8/18/2014 8:56 AM, hasufell wrote:
>>>> Almost forgot, of course this does
Chris Reffett:
> On 8/18/2014 8:56 AM, hasufell wrote:
>> hasufell:
>>>
>>> Even more interesting... you can work around this by inheriting
>>> base.eclass explicitly before e.g. unpacker.eclass, something like
>>>
>>> inherit base unpacker ga
hasufell:
>
> Even more interesting... you can work around this by inheriting
> base.eclass explicitly before e.g. unpacker.eclass, something like
>
> inherit base unpacker games
>
> => unpacker_src_unpack() is carried out by default (and the ebuild
> breaks if someon
hasufell:
> Sergey Popov:
>> 18.08.2014 16:04, hasufell пишет:
>>>> You have my strong opposition on such change as well. It will turn
>>>> ebuilds into unreadable and undpredictable mess, please do not do that
>>>>
>>>
>>> They are
Sergey Popov:
> 18.08.2014 16:04, hasufell пишет:
>>> You have my strong opposition on such change as well. It will turn
>>> ebuilds into unreadable and undpredictable mess, please do not do that
>>>
>>
>> They are already fairly unreadable and unpredict
William Hubbs:
> All,
>
> I spoke with mgorny on IRC and found out what his concerns are about our
> current eclasses.
>
> First, he thinks we should get rid of base.eclass.
>
> I know there is work going on to get rid of it, but I haven't really
> looked into the status much yet. I do agree tho
Sergey Popov:
>
> You have my strong opposition on such change as well. It will turn
> ebuilds into unreadable and undpredictable mess, please do not do that
>
They are already fairly unreadable and unpredictable.
Tom Wijsman:
> On Sat, 9 Aug 2014 18:10:51 +0100
> Ciaran McCreesh wrote:
>
>> On Sat, 09 Aug 2014 11:12:46 -0400
>> Chris Reffett wrote:
>>> Then write it. Portage's source is available to anyone.
>>
>> It's quicker to start from scratch than to try to add things to
>> Portage's source...
>
>
Chris Reffett:
>
> if people want to run this by Council
I'll laugh my ass off if this thing makes it on the council agenda xD
Ian Stakenvicius:
> So instead of, for
> instance, dropping the DESCRIPTION-ending-in-period check, it could
> instead be relegated to a "nag" that could be hidden with --nonag.
It will still be broken, even if you hide it.
Rich Freeman:
> so striving for grammatical perfection is a bit optimistic.
In that case, we should just rm the repoman warning and stop discussing
this matter.
William Hubbs:
> On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>
> *snip*
>
>> These links might be helpful:
>>
>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914
Duncan:
> Peter Stuge posted on Sat, 09 Aug 2014 10:34:58 +0200 as excerpted:
>
>> Duncan wrote:
>>> Red Hat is the gold standard, very long term commercial support,
>>> IIRC 10 years, and very good community relations
>>
>> I've heard this on occasion, but reality is actually quite different.
>>
Igor:
> Hello Ciaran,
>
> Friday, August 8, 2014, 5:22:03 PM, you wrote:
>
>>> get the result - install the application you need, leaving everything
>>> else AS IS untouched and stable?
>
>> cave resolve --lazy :P
>
> A great option name :-) I liked it. Wish it were there.
>
It is.
Igor:
> Hi,
>
> About 60% of all the packages are installed and work with nodep flag
> without any problems for years. 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 destabiliz
Ulrich Mueller:
>> On Sun, 27 Jul 2014, Martin Vaeth wrote:
>
>> Kent Fredric wrote:
>>> -r1.1 weirdness feels like it may cause more problems than it solves.
>
>> So far, nobody pointed out any problem which would be caused by -r1.1.
>> Which is not surprising, since the idea is that -r1.1
Samuli Suominen:
>
> On 27/07/14 14:50, hasufell wrote:
>> Samuli Suominen:
>>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>>> Martin Vaeth wrote:
>>>>> hasufell wrote:
>>&g
Andreas K. Huettel:
> Am Sonntag, 27. Juli 2014, 14:04:00 schrieb hasufell:
>>>> I'm not sure if you realize that you just disabled dynamic deps support
>>>> on most of those converted ebuilds.
>>>
>>> PLEASE, everyone, don't just make stat
Andreas K. Huettel:
> Am Sonntag, 27. Juli 2014, 13:50:43 schrieb hasufell:
>
>>> So, broken? Far from it. More like essential feature.
>
>>
>> I'm not sure if you realize that you just disabled dynamic deps support
>> on most of those converted ebuild
"Paweł Hajdan, Jr.":
> On 7/27/14, 1:42 PM, Samuli Suominen wrote:
>> Only one person said he had to manually build 2 GNOME related packages,
>> simple-scan and something else
>>
>> So, broken? Far from it. More like essential feature.
>>
>> People have just listed some known races dynamic deps hav
Samuli Suominen:
>
> On 26/07/14 15:49, Ciaran McCreesh wrote:
>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>> Martin Vaeth wrote:
>>> hasufell wrote:
>>>> Dynamics deps are already broken, not consistently enabled (e.g.
>>>> when subslots are
Martin Vaeth:
>
> Indeed, it just would just need a little programming.
>
would you like to implement it?
301 - 400 of 803 matches
Mail list logo
