From: Joe MacDonald <Joe.MacDonald@windriver.com>
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-networking] Update to standalone tree
Date: Wed, 24 Jul 2013 12:58:57 -0400 [thread overview]
Message-ID: <20130724165857.GB3797@windriver.com> (raw)
In-Reply-To: <20130723202409.GA4136@jama>
[-- Attachment #1: Type: text/plain, Size: 4310 bytes --]
[Re: [oe] [meta-networking] Update to standalone tree] On 13.07.23 (Tue 22:24) Martin Jansa wrote:
> On Tue, Jul 23, 2013 at 01:51:59PM -0400, Joe MacDonald wrote:
> >
> > If you are only using meta-networking from meta-openembedded, you
> > need read no further. This is only for people using my side-project
> > on github. Absolutely nothing has changed in the official
> > meta-networking.
>
> Just out of curiosity why do you keep separate tree for it?
Mostly it spawned out of non-technical reasons and since it's nearly
free for me to continue to do, I continue to do it. It's worked well
for me on some setups as well (eg. a new clone over an exceptionally
slow link where I only need to build yocto+a handful of meta-networking
apps) but if it actually amounted to any real work for me, I would've
dropped it by now.
> Is there some diff or is it exactly the same (now also with the same
> commit IDs?).
Note that the commit IDs aren't actually the same. They can't be
because it has a pseudo-history constructed using git-subtree. That's
why I made this most recent change to include the original meta-oe
commit IDs in the subtree'd version.
-J.
>
> >
> >
> >
> > For anyone using the standalone meta-networking subtree I maintain on
> > github, please be aware that I've made a change to the way I create the
> > subtree which, unfortunately, will result in a forced update for all of
> > your branches. And probably a merge on whatever branch you happen to be
> > on already (eg. master). If you get into that scenario, I suggest
> > pushing your current branch with the merge in it off a cliff and
> > re-creating the current branch tracking the up-stream. If you're not in
> > the habit of doing a git-pull, though, this will probably be cleaner:
> >
> > % git fetch --all --tags ; git rebase origin/<up-stream-branch-name
> >
> > The reason for this (and the advantage) has been in response to requests
> > I've had to preserve the original (that is, meta-oe) commit hash so it
> > is easy to connect a commit in the standalone meta-networking with the
> > official meta-networking I maintain as a part of the larger meta-oe.
> > The change is small and hopefully self-explanatory, but I won't let that stop
> > me.
> >
> > Before:
> >
> > commit a0f9363caddbfb92212b4bf5d4a2590c451b7cef
> > Author: Roy.Li <rongqing.li@windriver.com>
> > Date: Fri Jul 19 10:19:25 2013 +0800
> >
> > Upgrade vsftpd to 3.0.0
> >
> > Upgrade vsftpd to 3.0.0 with below modification:
> > 1. more strict access limitation, like: do not allow anonymous access
> > 2. use vsftpd.ftpusers and vsftpd.user_list to confine user access
> > 3. enable pam if DISTRO_FEATURE includes pam
> > 4. enable tcp-wrapper
> > 5. install vsftpd.conf with 0600 permission, not 0755
> >
> > Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> > Signed-off-by: Joe MacDonald <joe.macdonald@windriver.com>
> >
> > After:
> >
> > commit b188e402a04db35424e22cb2b2100b7070648948
> > Author: Roy.Li <rongqing.li@windriver.com>
> > Date: Fri Jul 19 10:19:25 2013 +0800
> >
> > Upgrade vsftpd to 3.0.0
> >
> > (original commit: 441502b68d03a4ce7796436a53c5e95399724ad2)
> >
> > Upgrade vsftpd to 3.0.0 with below modification:
> > 1. more strict access limitation, like: do not allow anonymous access
> > 2. use vsftpd.ftpusers and vsftpd.user_list to confine user access
> > 3. enable pam if DISTRO_FEATURE includes pam
> > 4. enable tcp-wrapper
> > 5. install vsftpd.conf with 0600 permission, not 0755
> >
> > Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> > Signed-off-by: Joe MacDonald <joe.macdonald@windriver.com>
> >
> > Where 441502b6... is the commit in meta-oe from Roy that happens to
> > upgrade vsftpd.
> >
> > FWIW, I don't anticipate doing anything destructive like this again.
> >
> > --
> > -Joe MacDonald.
> > :wq
>
>
>
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2013-07-24 16:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 17:51 [meta-networking] Update to standalone tree Joe MacDonald
2013-07-23 20:24 ` Martin Jansa
2013-07-24 16:58 ` Joe MacDonald [this message]
2013-07-23 21:53 ` Khem Raj
2013-07-24 16:54 ` Joe MacDonald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130724165857.GB3797@windriver.com \
--to=joe.macdonald@windriver.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.