Hi all -
There are a few things I do every time I expand the source tree
with sequence-patch.sh.
Or, rather, things I should do and forget to do a lot.
The first I always remember to do: Copy the config I want to test with
to my build directory.
The second I forget more often than not: Expand the kABI references
into my build directory.
One of the things that bites me occasionally is when there are kABI
changes that go un-noticed until the automated build checker flags them
and sends me an email yelling at me for my carelessness.
This patch adds three options to scripts/sequence-patch.sh to take care
of these automatically.
--build-dir=PATH allows you to specify the build directory you'll be
using. It will create the directory if it doesn't exist. It defaults to
$PATCH_DIR.
--config=ARCH-FLAVOR allows you to specify the config you'll use. It
will copy the config to your build directory. It is not a fatal error if
the config does not exist. It will just not copy one.
--kabi allows you to direct sequence-patch to expand the kABI references
into your build directory. Since the references are arch/flavor specific,
it depends on --config=ARCH-FLAVOR. It is not a fatal error if the kABI
reference doesn't exist since this is always the case in the master branch.
The --build-dir PATH is subject to shell expansion. It is expanded late
enough in the script that most variables should be available.
There are also three new variables available when --config is used:
$CONFIG contains the --config contents. $CONFIG_ARCH contains the arch
part of the config. $CONFIG_FLAVOR contains the flavor part.
For reference, I have this in my .bashrc:
export SEQUENCE_PATCH_ARGS="--config=x86_64-desktop --build-dir=~/src/scratch/build/\$CONFIG_ARCH/linux-\$SRCVERSION-\$TAG-\$CONFIG_FLAVOR --kabi"
I've also added patches for --ctags and --cscope which will automatically
generate the databases for either of those tools in the build directory
after the source tree is expanded.
- Issues addressed in patchset #2:
- Help text is now a here document for easy addition of more documentation
- Explanation of which variables are allowed by --build-dir
- Missing rpm/modversions script is not an error on older branches
- Missing symvers files are not errors
- Uses true/false for simple feature flags
-Jeff
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi,
Folks in #opensuse-security were asking what stops TOMOYO from being
enabled in newer kernels.
FATE#310292
https://bugzilla.novell.com/show_bug.cgi?id=668381
Not sure what the issue is with enabling it.
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Kernel developers,
I've seen some requests for a workshop (see $subject) for the openSUSE
conference. Are there any volunteers?
Details on how to submit a proposal:
http://news.opensuse.org/2011/06/02/opensuse-conference-cfp-going-strong/
You can also submit other proposals that you like!
Andreas
--
Andreas Jaeger, Program Manager openSUSE
aj(a){novell.com,suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi;
Everytime kernel is updated I see something similar to this:
Problem: preload-kmp-desktop-1.2_k3.0.0_rc3_3-66.7.x86_64 requires
kernel-desktop = 3.0.rc3-3, but this requirement cannot be provided
deleted providers: kernel-desktop-3.0.rc3-3.1.x86_64
Solution 1: do not keep
preload-kmp-desktop-1.2_k3.0.0_rc3_3-66.7.x86_64 installed
Solution 2: do not install kernel-desktop-3.0.rc4-2.2.x86_64
Solution 3: break preload-kmp-desktop by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c):
I think preload-kmp is the system similar to DKMS, is there any work
going to replace kmp with DKMS which I _think_ (maybe naively?) would
create less update problems?
Regards.
--
Ismail Dönmez - openSUSE Booster
SUSE LINUX Products GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi developers!
Is the Bug #673944[0] related to Linux kernel or just (vendor)
hardware's fault (bios, acpi?) ?
If it is about the kernel, then what part of the kernel that "solves"
the issue (c#9)?
Thanks in advance.
[0] https://bugzilla.novell.com/show_bug.cgi?id=673944
Best regards,
--
Andi Sugandi. Bandung, Indonesia.
openSUSE-id Team, openSUSE Community Member.
http://en.opensuse.org/User:Andisugandi
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi all,
after I found today that with 3.0-rc2 the "mei" module successfully
prevents suspend with
[39736.728116] pci_pm_suspend(): mei_pci_suspend+0x0/0xc0 [mei] returns 9999
I was wondering if it is a good idea to autoload staging drivers :-)
mei being a staging driver and 3.0-rc2 being ancient, I have not yet
opened a bug on LKML.
I have, however, looked at the code and could not find out where the 9999
come from...
--
Stefan Seyfried
"Dispatch war rocket Ajax to bring back his body!"
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi:
In current kernel head there is an entry in
sysctl.conf-3.0.0-rc2-1-default that says:
kernel.hung_task_timeout = 0
which is an invalid sysctl value
it should say AFAICS
kernel.hung_task_timeout_secs = 0
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
The following post is about the following bug that you must read to
understand the rest...
https://bugzilla.novell.com/show_bug.cgi?id=696474
After removing commit=100 from the mount options the symptoms mentioned
in the bug report disappear, but still there is a mayor weirdness..
I call it, "everything is fine before midnight"
Between 23:00 and 00:00 each day, cron jobs start rsync and various IO
intensive processes, and it is when the apache server running in the
same machine starts to segfault with random errors, sometimes there is
not even a workable backtrace, memory gets corrupted somehow, It will
keep segfaulting randomly even after rsync process has ended, the only
solution is the reboot the box after those processes end.
There is no kernel warning, error, I have run memtest86++ and memtester
user-space utility, more than once, even for a complete night.
The machine is not out of ram, it has at least 5 GB free and other 5GB
cached.
The only remotely related (????) warning I get is this:
un 15 00:19:32 eq6 smartd[2555]: Device: /dev/twa0 [3ware_disk_00],
SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 110 to 111
Jun 15 00:19:32 eq6 smartd[2555]: Device: /dev/twa0 [3ware_disk_00],
SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 34 to 35
Googling says it is not something to worry about unless smart reports
fail, neither the raid controller built-in error reporting nor smartd
says nothing about broken disks.
Everything is fine after reboot, until next midnight approaches..
Lossing hair here, any hints ?
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org
Hi,
Today I finally got round to properly fix the versioning mess in master
and the upstream branches (vanilla and linux-next). This mail is meant
to document how it's supposed to work. You can skip to the table at the
end of the mail for a summary.
In upstream
~~~~~~~~~~~
Upstream git tags look like "v3.0-rc1", "v3.0-rc2", the final tag is
going to be "v3.0" and the subsequent stable releases will be tagged as
"v3.0.1", "v3.0.2" and so on. The tarballs are named after these tags,
so we have linux-3.0-rc2.tar.bz2 that contains the linux-3.0-rc2 directory.
HOWEVER: Several userspace programs expect the kernel release string be
three numbers and fail if it isn't the case. This also affects depmod,
so omitting the third zero would break all setups using modules. So the
kernel continues to call itself "3.0.0-rc2" and this will probably stay
for some time now.
In short, there are two version numbers now: I'll refer to them as the
"tarball" version and the "uname" version (might differ from the
"tarball" version in the trailing zero).
In openSUSE
~~~~~~~~~~~
The SRCVERSION variable in the config.sh file is set to the "tarball"
version. The mkspec script takes this and generates two more versions:
The "uname" version (appends a zero if necessary), that is used during
the build (so the actual build didn't require any modifications in the
end) and the "rpm" version. I used the fact that the build was broken
anyway as an opportunity to revamp the way the rpm packages are
numbered. The final releases will have three numbers, i.e.
"kernel-desktop-3.0.0-...", "kernel-desktop-3.0.1-...", etc. However,
-rc releases will use the "rcX" tag instead of the last zero, so the
current package will look like "kernel-desktop-3.0.rc2-...". Letters
sort before numbers in rpm, so this will not break ordering and at the
same time you will be able to tell the upstream version from the rpm
version easily. Until now, we abused the rpm Release: field for this,
but this only worked in the Kernel:* projects and not in the official
distribution. To summarize, the mapping will be like:
rpm tarball uname -r
kernel-desktop-3.0.rc2-* linux-3.0-rc2.tar.bz2 3.0.0-rc2-*-desktop
kernel-desktop-3.0.0-* linux-3.0.tar.bz2 3.0.0-*-desktop
kernel-desktop-3.0.1-* linux-3.0.1.tar.bz2 3.0.1-*-desktop
The "*" above is the rpm Release: number assigned by the build service.
I hope that despite the long mail, the scheme will actually be easy to
understand, that would will be able to quickly tell what kernel is in
the distro by just looking at the rpm packages.
Michal
PS: I didn't cover KMPs at all at this point, they might work or there
might be some fixes needed, I'll look into this later.
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org