Fwd: recent changes in build system behavior?
Vadim Bendebury
branch. When I run `repo sync .' it starts rebasing the working tree
over the tracking branch, wrecking terrible havoc on the checked out
tree. Isn't 'repo sync' supposed to update the local copy of the
repository not touching the working tree?!
Another recent change I noticed is that the log file generated by
emerge-xxxx has the timestamp attached to it. Say before this
'enhancement' I could say
grep error: <log file name>
see the error, reemerge the package, and if there are still some
errors - just use the arrow up to get back to the 'grep error:' line
to see what else is there. Now I need to retype the log file name anew
each time. What was the point of adding the timestamp to the file name
- isn't it getting destroyed after every successful emerge?
cheers,
/v
Chris Sosa
> guys, say I have a git repo checked out on a non-tracking remote
> branch. When I run `repo sync .' it starts rebasing the working tree
> over the tracking branch, wrecking terrible havoc on the checked out
> tree. Isn't 'repo sync' supposed to update the local copy of the
> repository not touching the working tree?!
I can't comment on the latter issue, however, repo sync was changed a
while back to sync any working branches that don't have a
corresponding upload. This means if you haven't run repo upload . on
the branch, it'll attempt to rebase your changes. If you'd like to
just update the remote behavior, use repo sync -n ...
>
> Another recent change I noticed is that the log file generated by
> emerge-xxxx has the timestamp attached to it. Say before this
> 'enhancement' I could say
>
> grep error: <log file name>
>
> see the error, reemerge the package, and if there are still some
> errors - just use the arrow up to get back to the 'grep error:' line
> to see what else is there. Now I need to retype the log file name anew
> each time. What was the point of adding the timestamp to the file name
> - isn't it getting destroyed after every successful emerge?
>
> cheers,
> /v
>
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
Mike Frysinger
> guys, say I have a git repo checked out on a non-tracking remote
> branch. When I run `repo sync .' it starts rebasing the working tree
> over the tracking branch, wrecking terrible havoc on the checked out
> tree. Isn't 'repo sync' supposed to update the local copy of the
> repository not touching the working tree?!
afaik, that's how `repo sync` has always worked. sounds like you want
to use the -n option to sync.
> Another recent change I noticed is that the log file generated by
> emerge-xxxx has the timestamp attached to it. Say before this
> 'enhancement' I could say
>
> grep error: <log file name>
>
> see the error, reemerge the package, and if there are still some
> errors - just use the arrow up to get back to the 'grep error:' line
> to see what else is there. Now I need to retype the log file name anew
> each time.
really ? you can't use a shell glob ?
> What was the point of adding the timestamp to the file name
> - isn't it getting destroyed after every successful emerge?
no. that was the whole point of the change.
-mike
Vadim Bendebury
>
> really ? you can't use a shell glob ?
>
I guess I could, but before I'd just copy and paste the file name
>> What was the point of adding the timestamp to the file name
>> - isn't it getting destroyed after every successful emerge?
>
> no. that was the whole point of the change.
so, if the logs all are there then when using a glob I'd see output
from all of them?
I wonder who decides making changes like that - is there a discussion,
some kind of vote, etc? Could the enhancement be optional, at least
for a while? Preserving default behavior always seemed such a good
idea to me... :P
cheers,
/vb
> -mike
Vadim Bendebury
> On Fri, Apr 20, 2012 at 4:51 PM, Vadim Bendebury <vbe...@chromium.org> wrote:
>> guys, say I have a git repo checked out on a non-tracking remote
>> branch. When I run `repo sync .' it starts rebasing the working tree
>> over the tracking branch, wrecking terrible havoc on the checked out
>> tree. Isn't 'repo sync' supposed to update the local copy of the
>> repository not touching the working tree?!
>
> I can't comment on the latter issue, however, repo sync was changed a
> while back to sync any working branches that don't have a
> corresponding upload. This means if you haven't run repo upload . on
> the branch, it'll attempt to rebase your changes. If you'd like to
> just update the remote behavior, use repo sync -n ...
>
isn't this a bug - it just messes up the source tree completely in this case.
cheers,
/v
Brian Harring
On Fri, Apr 20, 2012 at 4:55 PM, Chris Sosa <so...@google.com> wrote:isn't this a bug - it just messes up the source tree completely in this case.
> On Fri, Apr 20, 2012 at 4:51 PM, Vadim Bendebury <vbe...@chromium.org> wrote:
>> guys, say I have a git repo checked out on a non-tracking remote
>> branch. When I run `repo sync .' it starts rebasing the working tree
>> over the tracking branch, wrecking terrible havoc on the checked out
>> tree. Isn't 'repo sync' supposed to update the local copy of the
>> repository not touching the working tree?!
>
> I can't comment on the latter issue, however, repo sync was changed a
> while back to sync any working branches that don't have a
> corresponding upload. This means if you haven't run repo upload . on
> the branch, it'll attempt to rebase your changes. If you'd like to
> just update the remote behavior, use repo sync -n ...
>
Either way, there isn't an issue here. I *suspect* you probably want to take a look at `repo sync -d` also; generally speaking you should be resetting repo's back to detached head (aka, no local changes) if you're not actively working on them at that time.
Vadim Bendebury
> On Fri, Apr 20, 2012 at 5:05 PM, Vadim Bendebury <vbe...@chromium.org>
> wrote:
>>
>> On Fri, Apr 20, 2012 at 4:55 PM, Chris Sosa <so...@google.com> wrote:
>> > On Fri, Apr 20, 2012 at 4:51 PM, Vadim Bendebury <vbe...@chromium.org>
>> > wrote:
>> >> guys, say I have a git repo checked out on a non-tracking remote
>> >> branch. When I run `repo sync .' it starts rebasing the working tree
>> >> over the tracking branch, wrecking terrible havoc on the checked out
>> >> tree. Isn't 'repo sync' supposed to update the local copy of the
>> >> repository not touching the working tree?!
>> >
>> > I can't comment on the latter issue, however, repo sync was changed a
>> > while back to sync any working branches that don't have a
>> > corresponding upload. This means if you haven't run repo upload . on
>> > the branch, it'll attempt to rebase your changes. If you'd like to
>> > just update the remote behavior, use repo sync -n ...
>> >
>>
>> isn't this a bug - it just messes up the source tree completely in this
>> case.
>
>
> To be clear, you explicitly told repo to sync- meaning "update my tree to
> current ToT".
>
well, why does it matter than if there were uploads from this tree
before? It looks like default behavior changes to 'do not rebase'
after an upload - do I get it right? if so - what difference does the
fact that there has been an upload make?
cheers,
/v
Mike Frysinger
> On Fri, Apr 20, 2012 at 4:55 PM, Chris Sosa wrote:
>> On Fri, Apr 20, 2012 at 4:51 PM, Vadim Bendebury wrote:
>>> guys, say I have a git repo checked out on a non-tracking remote
>>> branch. When I run `repo sync .' it starts rebasing the working tree
>>> over the tracking branch, wrecking terrible havoc on the checked out
>>> tree. Isn't 'repo sync' supposed to update the local copy of the
>>> repository not touching the working tree?!
>>
>> I can't comment on the latter issue, however, repo sync was changed a
>> while back to sync any working branches that don't have a
>> corresponding upload. This means if you haven't run repo upload . on
>> the branch, it'll attempt to rebase your changes. If you'd like to
>> just update the remote behavior, use repo sync -n ...
>
> isn't this a bug - it just messes up the source tree completely in this case.
it isn't really anymore a bug than `git pull` messes up your tree. if
you think otherwise, file a bug with the repo people. ChromeOS
doesn't maintain that tool.
-mike
Mike Frysinger
> On Fri, Apr 20, 2012 at 4:55 PM, Mike Frysinger wrote:
>> really ? you can't use a shell glob ?
>
> I guess I could, but before I'd just copy and paste the file name
which you still can
>>> What was the point of adding the timestamp to the file name
>>> - isn't it getting destroyed after every successful emerge?
>>
>> no. that was the whole point of the change.
>
> so, if the logs all are there then when using a glob I'd see output
> from all of them?
yes
> I wonder who decides making changes like that - is there a discussion,
> some kind of vote, etc?
obviously the build team does
> Could the enhancement be optional
you're free to put whatever customizations you want in your chroot's
/etc/make.conf.user
> at least for a while?
it's been deployed for almost 2 months at this point
> Preserving default behavior always seemed such a good
> idea to me... :P
yes, let's never move forward
-mike
Vadim Bendebury
> On Fri, Apr 20, 2012 at 20:02, Vadim Bendebury wrote:
>> On Fri, Apr 20, 2012 at 4:55 PM, Mike Frysinger wrote:
>>> really ? you can't use a shell glob ?
>>
>> I guess I could, but before I'd just copy and paste the file name
>
> which you still can
>
I know I can, but this makes the workflow less fluid
>>>> What was the point of adding the timestamp to the file name
>>>> - isn't it getting destroyed after every successful emerge?
>>>
>>> no. that was the whole point of the change.
>>
>> so, if the logs all are there then when using a glob I'd see output
>> from all of them?
>
> yes
So, your globing advice was not quite appropriate, was it.
Also, does the backlog of log files get cleaned automatically or is
this the user responsibility to purge this directory once in a while?
>
>> I wonder who decides making changes like that - is there a discussion,
>> some kind of vote, etc?
>
> obviously the build team does
>
>> Could the enhancement be optional
>
> you're free to put whatever customizations you want in your chroot's
> /etc/make.conf.user
>
Is there a way to restore old behavior?
>> at least for a while?
>
> it's been deployed for almost 2 months at this point
>
>> Preserving default behavior always seemed such a good
>> idea to me... :P
>
> yes, let's never move forward
no need to be acrimonious, changes in default behavior should not be
introduced lightly and should be widely - did I miss an announcement?
cheers,
/vb
> -mike
Mike Frysinger
> On Sat, Apr 21, 2012 at 12:05 AM, Mike Frysinger wrote:
>> On Fri, Apr 20, 2012 at 20:02, Vadim Bendebury wrote:
>>> On Fri, Apr 20, 2012 at 4:55 PM, Mike Frysinger wrote:
>>>>> What was the point of adding the timestamp to the file name
>>>>> - isn't it getting destroyed after every successful emerge?
>>>>
>>>> no. that was the whole point of the change.
>>>
>>> so, if the logs all are there then when using a glob I'd see output
>>> from all of them?
>>
>> yes
>
> So, your globing advice was not quite appropriate, was it.
works fine for me
> Also, does the backlog of log files get cleaned automatically or is
> this the user responsibility to purge this directory once in a while?
mainline portage already has support for that which is pending for
merging into the chromiumos version of portage
>>> I wonder who decides making changes like that - is there a discussion,
>>> some kind of vote, etc?
>>
>> obviously the build team does
>>
>>> Could the enhancement be optional
>>
>> you're free to put whatever customizations you want in your chroot's
>> /etc/make.conf.user
>
> Is there a way to restore old behavior?
like i said, put whatever settings you want in your make.conf.user.
as announced on this list some time ago, that file is now sourced last
and thus has full control over the portage settings.
>>> at least for a while?
>>
>> it's been deployed for almost 2 months at this point
>>
>>> Preserving default behavior always seemed such a good
>>> idea to me... :P
>>
>> yes, let's never move forward
>
> no need to be acrimonious
pot, meet kettle
> changes in default behavior should not be
> introduced lightly and should be widely
you're making quite a lot of assumptions here. we can't realistically
analyze every angle in which a change affects things, nor can we
announce every change we make to the build system. the specific thing
you're talking about (which i assume is the log file path displayed in
the `die` error summary when an `emerge` fails since you've provided
nothing but vague references) is a side effect of storing all the
build logs in a common location instead of throwing them away after an
emerge succeeds.
-mike
Jonathan Kliegman
What should be put into that file to enable the old behavior?
> >>> at least for a while?
> >>
> >> it's been deployed for almost 2 months at this point
> >>
> >>> Preserving default behavior always seemed such a good
> >>> idea to me... :P
> >>
> >> yes, let's never move forward
> >
> > no need to be acrimonious
>
> pot, meet kettle
>
> > changes in default behavior should not be
> > introduced lightly and should be widely
>
> you're making quite a lot of assumptions here. we can't realistically
> analyze every angle in which a change affects things, nor can we
> announce every change we make to the build system. the specific thing
> you're talking about (which i assume is the log file path displayed in
> the `die` error summary when an `emerge` fails since you've provided
> nothing but vague references) is a side effect of storing all the
> build logs in a common location instead of throwing them away after an
> emerge succeeds.
> -mike
>
Mike Frysinger
> What should be put into that file to enable the old behavior?
try setting PORT_LOGDIR="". if that doesn't work, lemme know and i'll
take a look for you.
-mike