Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1742848
| From | Randy Dunlap <rdunlap@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: How to verify linux-next |
| Date | 2017-10-01 18:50 +0200 |
| Message-ID | <uvPBh-4ux-33@gated-at.bofh.it> (permalink) |
| References | (6 earlier) <uvbu9-3kX-5@gated-at.bofh.it> <uvh6y-7cr-3@gated-at.bofh.it> <uvivD-8h5-1@gated-at.bofh.it> <uvPhT-4nz-1@gated-at.bofh.it> <uvPBg-4ux-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 10/01/17 09:44, Damian Tometzki wrote: > > Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar: >> On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o <tytso@mit.edu> >> wrote: >>> >>> On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote: >>>> >>>> I need to submit a patch to mainline which should be verified >>>> against >>>> linux-next tree with latest API. >>> If you want to verify a patch that you intend to submit upstream, >>> my >>> suggestion is to *not* use linux-next, but rather use the latest >>> tagged -rc from Linus's tree. So for example, you might want to >>> use >>> v4.14-rc2 as your base, and then apply your patch on top of v4.14- >>> rc2. >>> And then test v4.14-rc2. That way you don't need to worry about >>> debugging problems that might be caused by code in other people's >>> development trees. >>> >>> If you know which subsystem tree your commit is going to be sent >>> to, >>> you might use as your base the current development branch of that >>> subsystem tree. But in general, it's fine to use something like >>> v4.14-rc2; if the subsystem maintainer you plan to be submitting >>> your >>> patch has other preference, he or she will let you know, or take >>> care >>> of rebasing your patch onto his subsystme tree. >>> >>>> >>>> My patch is related to some test utility based on client/server >>>> model. >>>> So, I need 2 terminal, one for server and one for client. >>> That implies you're running the commands to run the test by >>> hand. In >>> the ideal world, tests should be automated, even those that are >>> using >>> client/server so that tests can be run unattended, over and over >>> again. >>> >>> For example, here's an example of test involving a client and a >>> server >>> in xfstests: >>> >>> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g >>> eneric/131 >>> >>> See? No terminal required, and certainly not two terminals! >>> >>> Remember, it's important not just to run one test, because the risk >>> is >>> that fixing one bug might cause a test regression somewhere >>> else. So >>> when I "validate" a kernel, I'm running thousands of tests, just to >>> test the ext4 file system. For each bug that we fix, we try to add >>> a >>> new automated test, so we can be sure that some future change >>> doesn't >>> cause a bug to reappear. And if you're running hundreds or >>> thousands >>> of tests, you certainly aren't going to be wanting to manually set >>> up >>> each test by using putty to login to the VM using ssh! >>> >>>> >>>> 1) How to resolve linux-next build error with ubuntu virtual box >>>> 5.1.28 >>> Virtual box is not relevant. What is relevant is the kernel config >>> file you are using, and what compiler version / distro are you >>> using >>> to build the kernel. And as I said, you're better off using >>> something >>> like v4.14-rc2 instead of linux-next. >>> >> Ok thank you so much for your reply. >> Now I am able to boot with v4.14-rc2. But now I am facing another >> problem. >> Now, I am not able to connect to internet from virtual box. >> When I switch back to the default 4.10 the internet works normally. >> I think the dlclient stopped working. >> I am getting continuous logs related to apparmor like this: >> apparmor="DENIED" comm=dhclient >> apparmor="DENIED" comm=cups-browsed >> >> With 4.10, I tried installing apparmor-utils and then reboot with >> 4.14-rc2, but it did not help. >> Any suggestions on this? > > Hello, > > i resolved the issue with: > sudo /etc/init.d/apparmor stop or boot with: apparmor=0 -- ~Randy
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-09-29 11:50 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-09-29 11:50 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-09-29 12:40 +0200
Re: How to verify linux-next valdis.kletnieks@vt.edu - 2017-09-29 15:00 +0200
Re: How to verify linux-next Damian Tometzki <damian.tometzki@icloud.com> - 2017-09-29 15:20 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-09-29 16:30 +0200
Re: How to verify linux-next valdis.kletnieks@vt.edu - 2017-09-29 17:50 +0200
Re: How to verify linux-next Kamil Konieczny <k.konieczny@partner.samsung.com> - 2017-10-02 10:20 +0200
Re: How to verify linux-next valdis.kletnieks@vt.edu - 2017-10-02 13:10 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-09-29 20:00 +0200
Re: How to verify linux-next Theodore Ts'o <tytso@mit.edu> - 2017-09-30 00:00 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-09-30 06:00 +0200
Re: How to verify linux-next Theodore Ts'o <tytso@mit.edu> - 2017-09-30 07:30 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-10-01 18:30 +0200
Re: How to verify linux-next Damian Tometzki <damian.tometzki@icloud.com> - 2017-10-01 18:50 +0200
Re: How to verify linux-next Randy Dunlap <rdunlap@infradead.org> - 2017-10-01 18:50 +0200
Re: How to verify linux-next Mike Galbraith <efault@gmx.de> - 2017-10-01 19:10 +0200
Re: How to verify linux-next Pintu Kumar <pintu.ping@gmail.com> - 2017-10-01 20:50 +0200
Re: How to verify linux-next Theodore Ts'o <tytso@mit.edu> - 2017-10-01 18:50 +0200
Re: How to verify linux-next Damian Tometzki <damian.tometzki@icloud.com> - 2017-09-29 16:10 +0200
csiph-web