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
Hello!
Below are some packages that I fail to take care of as needed and have
not been using myself for a while. Please take over whatever you have
interest in:
Latest Open bugs
app-text/xmlstarlet
Hi!
Since we're causing at least mild upheaval process-wise, I
thought I'd bring up a topic that will be exacerbated by the git
migration if it's not really addressed.
AIUI, we try to avoid merge conflicts, unless the merge is a
meaningful integration of divergent processes.
However, one
On Thu, 18 Sep 2014, Tobias Klausmann wrote:
However, one aspect of how ebuilds are written these days will
cause a non-trivial amount of merge commits that are not actually
useful in that sense.
This is due to the way keywording and stabilization work on an
ebuild level. Since keywords
On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller u...@gentoo.org wrote:
On Thu, 18 Sep 2014, Tobias Klausmann wrote:
However, one aspect of how ebuilds are written these days will
cause a non-trivial amount of merge commits that are not actually
useful in that sense.
Git can do merge
On Thu, 18 Sep 2014 17:04:55 +1200
Kent Fredric kentfred...@gmail.com wrote:
What's more, you can in fact do:
git mv foo-1.ebuild foo-2.ebuild
git commit
and you can still easily tell git to show that as a difference in a
log.
Example script to emulate this and example output:
On Thu, Sep 18, 2014 at 3:33 PM, Diamond diam...@hi-net.ru 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):
On Thu, Sep 18, 2014 at 11:33:40PM +0400, 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):
On Thu, 18 Sep 2014 16:00:59 -0400
Rich Freeman ri...@gentoo.org wrote:
What would you propose? The problem you raise is just as much an
issue with cvs. I don't get a continuous history across revbumps in
cvs today, so I don't really see a problem with moving to git.
I don't know what to
Diamond wrote:
I stumbled over this problem when started to use git for packages.
Use git show -M to unstumble yourself.
//Peter
On Thu, 18 Sep 2014 13:08:11 -0700
W. Trevor King wk...@tremily.us wrote:
Git can check for copies if you like:
$ git clone git://github.com/cerebrum/dr.git
$ cd dr/
$ git show --find-copies-harder 311df9b04
…
copy from games-strategy/openra/openra-20140608.ebuild
copy to
On Fri, Sep 19, 2014 at 01:01:13AM +0400, Diamond wrote:
On Thu, 18 Sep 2014 13:08:11 -0700 W. Trevor King wrote:
Git can check for copies if you like:
$ git clone git://github.com/cerebrum/dr.git
$ cd dr/
$ git show --find-copies-harder 311df9b04
…
copy from
On Thu, 18 Sep 2014 14:29:41 -0700
W. Trevor King wk...@tremily.us wrote:
So Git works great, and GitHub's web UI doesn't support all of Git's
bells and whistles, so… switch to a different VCS? Personally, my
conclusion is “just use Git from the command line”. It's not like
you're
On 19 September 2014 07:33, Diamond diam...@hi-net.ru 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):
On 19 September 2014 10:13, Diamond diam...@hi-net.ru 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.
Diamond wrote:
we probably can arrive at a conclusion that git itself isn't good
at all for package management.
I don't think we can. Please stop the nonsense, at least until you
have created something superior to git.
//Peter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
For future reference, please use git's send-email option with
- --in-reply-to, to send the patches inline. The way they are sent now,
(I assume) most of us have to download your patches and open them in a
text viewer to review it. If the patches
Dnia 2014-09-17, o godz. 14:57:10
Bertrand Simonnet bsimon...@google.com napisał(a):
I'd rather use the env/ mechanism instead of the package.env one as it is
more flexible.
It depends on what you aim to do. As portage(5) points out, both have
their advantages:
- package.env is parsed early,
For my purpose, I think bash scripting would be more useful. I thought
about package.env
in the beginning (see first few messages on this thread) as it would help
us reuse code but
variable setting only will limit what we can do.
If you want package.env, we can implement it too and have both
This fixes _backtrack_depgraph to immediately report necessary
REQUIRED_USE changes instead of discarding the graph. This is
accomplished by replacing the depgraph.success_without_autounmask
method with a new need_config_change method that accounts for both
autounmask and REQUIRED_USE changes.
On 09/18/2014 11:46 AM, Zac Medico wrote:
This fixes _backtrack_depgraph to immediately report necessary
REQUIRED_USE changes instead of discarding the graph. This is
accomplished by replacing the depgraph.success_without_autounmask
method with a new need_config_change method that accounts for
On Thu, 18 Sep 2014 11:46:55 -0700
Zac Medico zmed...@gentoo.org wrote:
This fixes _backtrack_depgraph to immediately report necessary
REQUIRED_USE changes instead of discarding the graph. This is
accomplished by replacing the depgraph.success_without_autounmask
method with a new
From 963efa6fcf1e61d836d5292c88500a7c032cf46e Mon Sep 17 00:00:00 2001
From: Zac Medico zmed...@gentoo.org
Date: Thu, 18 Sep 2014 16:16:13 -0700
Subject: [PATCH] _solve_..slot_conflicts: fix bug #522084
Fix _solve_non_slot_operator_slot_conflicts to add all parents to the
conflict_graph, even for
23 matches
Mail list logo
