[PATCH] Drop stable_rc macros
by Josh Boyer
We never use the stable_rc mechanism. It just adds clutter to the spec
and in the rare case where we grab patches from a stable RC we've just
applied them via ApplyPatch. Get rid of it.
---
kernel.spec | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index 87639cc..574ce19 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -47,16 +47,10 @@ Summary: The Linux kernel
# Do we have a -stable update to apply?
%define stable_update 0
-# Is it a -stable RC?
-%define stable_rc 0
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev %{stable_update}
%define stable_base %{stable_update}
-%if 0%{?stable_rc}
-# stable RCs are incremental patches, so we need the previous stable patch
-%define stable_base %(echo $((%{stable_update} - 1)))
-%endif
%endif
%define rpmversion 3.%{base_sublevel}.%{stable_update}
@@ -136,12 +130,7 @@ Summary: The Linux kernel
# pkg_release is what we'll fill in for the rpm Release: field
%if 0%{?released_kernel}
-%if 0%{?stable_rc}
-%define stable_rctag .rc%{stable_rc}
-%define pkg_release 0%{stable_rctag}.%{fedora_build}%{?buildid}%{?dist}
-%else
%define pkg_release %{fedora_build}%{?buildid}%{?dist}
-%endif
%else
@@ -512,10 +501,6 @@ Source2001: cpupower.config
%define stable_patch_00 patch-3.%{base_sublevel}.%{stable_base}.xz
Patch00: %{stable_patch_00}
%endif
-%if 0%{?stable_rc}
-%define stable_patch_01 patch-3.%{base_sublevel}.%{stable_update}-rc%{stable_rc}.xz
-Patch01: %{stable_patch_01}
-%endif
# non-released_kernel case
# These are automagically defined by the rcrev and gitrev values set up
@@ -1143,9 +1128,6 @@ cd linux-%{KVERREL}
%if 0%{?stable_base}
ApplyPatch %{stable_patch_00}
%endif
-%if 0%{?stable_rc}
-ApplyPatch %{stable_patch_01}
-%endif
# Drop some necessary files from the source dir into the buildroot
cp $RPM_SOURCE_DIR/config-* .
--
1.8.4.2
10 years, 3 months
Re: [PATCH] Drop buildid macros
by Josh Boyer
On Mon, Jan 13, 2014 at 6:00 PM, Jarod Wilson <jarod(a)redhat.com> wrote:
> On Mon, Jan 13, 2014 at 05:43:45PM -0500, Josh Boyer wrote:
>> On Mon, Jan 13, 2014 at 5:25 PM, Jarod Wilson <jarod(a)redhat.com> wrote:
>> > On Mon, Jan 13, 2014 at 04:07:06PM -0500, Josh Boyer wrote:
>> >> On Mon, Jan 13, 2014 at 3:53 PM, Paul Bolle <pebolle(a)tiscali.nl> wrote:
>> >> > Josh Boyer schreef op ma 13-01-2014 om 15:41 [-0500]:
>> >> >> As far as I know, nobody actually uses buildid to differentiate between
>> >> >> kernel builds.
>> >> >
>> >> > Well, I do!
>> >>
>> >> OK, so it would be fairer to say "it is infrequently used". :)
>> >
>> > Its actually used on a very regular basis by some folks for one-off
>> > builds. However, said folks are pretty much all internal to Red Hat, doing
>> > RHEL builds. For example, I craft a test build via 'make rh-srpm
>> > BUIDLID=".test_foo"', which subs in the BUILDID value for the buildid bit
>> > in the spec file. We can of course just graft that back in when RHEL8
>> > branches from Fedora <20 + mumble> in the future. But I personally like
>> > having the "edit this" part on its own line as its own thing regardless.
>> > You can have a spec file patch or script that does it much more simply
>> > than if you have to worry about other things that might be in the var
>> > you want to tweak.
>>
>> OK, I guess I'll just drop this one. So much for low-hanging fruit.
>
> Note: the variant of the buildid stuff in the fedora spec looks far more
> complicated than what is in the rhel7 spec. There are only 2 lines of spec
> goo with buildid on them. I'd certainly endorse a patch that stripped out
> all the extraneous crap. All I really need is:
>
> # % define buildid .local
>
> and
>
> %define pkg_release %{fedora_build}%{?buildid}%{?dist}
Yeah, I'll look into that.
>> As an aside, some of the other changes I'm playing with to split up
>> the kernel packaging so the cloud people get a tiny kernel to install
>> are much more invasive. In terms of RHEL<mumble> they'll be a much
>> bigger impact. They will likely need to be adopted in RHEL land
>> eventually and not reverted/replaced. I will, of course, post them
>> first because I'd like review for a bunch of different reasons. I've
>> already posted this on some of the other discussions, but the general
>> premise is splitting it into kernel-core and kernel-drivers packages.
>
> Heh, history repeats itself, somewhat (kernel, kernel-unsupported). Just
> kernel-core and kernel-drivers or perhaps kernel-core,
> kernel-network-drivers, kernel-storage-drivers, etc? (and with a "kernel"
> meta-package that requires all of them).
Variations on the theme, but yes. I have kernel-core and
kernel-drivers working for the ultimately simplistic cases with the
kernel meta-package requiring both of them. Where it currently breaks
is flavors, which winds up with e.g. kernel-debug-core,
kernel-debug-drivers, but no kernel-debug meta-package. I just
haven't gotten back to it yet.
Once I get them working, the real "fun" is going to be getting the
content of those packages settled. I'm sure kernel-core is going to
have to be more than just the contents of /boot, which is all it is in
my initial test runs right now (with -drivers being the /lib/module/
content). For that though, I'm waiting on the cloud people to tell me
what they need other than "uh... small!"
josh
10 years, 3 months
kernel.spec: drop superfluous call of headers_check
by Paul Bolle
Josh,
Here's a possible cleanup of kernel.spec. It also addresses one of my
pet peeves: headers_check is run twice when building the kernel rpms.
See, CONFIG_HEADERS_CHECK is already set to "y" in config-generic. But
there are also a few lines in kernel.spec where headers_check is invoked
again. And, as far as I can see
grep -q exist hdrwarnings.txt
will never match. Perhaps it made sense to grep for exist in the past, I
don't know. Or was it intended to grep for an error message? But errors
are not directed to hdrwarnings.txt.
Entirely untested patch, by the way.
Paul Bolle
-------->8-------
kernel.spec | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index a83abb0..09967a0 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1844,15 +1844,6 @@ cd linux-%{KVERREL}
# Install kernel headers
make ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr headers_install
-# Do headers_check but don't die if it fails.
-make ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr headers_check \
- > hdrwarnings.txt || :
-if grep -q exist hdrwarnings.txt; then
- sed s:^$RPM_BUILD_ROOT/usr/include/:: hdrwarnings.txt
- # Temporarily cause a build failure if header inconsistencies.
- # exit 1
-fi
-
find $RPM_BUILD_ROOT/usr/include \
\( -name .install -o -name .check -o \
-name ..install.cmd -o -name ..check.cmd \) | xargs rm -f
--
1.8.4.2
10 years, 3 months
[PATCH] Drop upstream_branch related spec stuffs
by Josh Boyer
We haven't set using_upstream_branch to 1 since we started using git.
Almost 7 years is a long time to carry something around we aren't using.
Drop the upstream_branch stuff.
---
kernel.spec | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index a83abb0..fb65acb 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -208,16 +208,6 @@ Summary: The Linux kernel
%if %{nopatches}
%define with_bootwrapper 0
%define variant -vanilla
-%else
-%define variant_fedora -fedora
-%endif
-
-%define using_upstream_branch 0
-%if 0%{?upstream_branch:1}
-%define stable_update 0
-%define using_upstream_branch 1
-%define variant -%{upstream_branch}%{?variant_fedora}
-%define pkg_release 0.%{fedora_build}%{upstream_branch_tag}%{?buildid}%{?dist}
%endif
%if !%{debugbuildsenabled}
@@ -383,7 +373,7 @@ Summary: The Linux kernel
# Should make listnewconfig fail if there's config options
# printed out?
-%if %{nopatches}%{using_upstream_branch}
+%if %{nopatches}
%define listnewconfig_fail 0
%else
%define listnewconfig_fail 1
@@ -572,10 +562,6 @@ Patch00: patch-3.%{base_sublevel}-git%{gitrev}.xz
%endif
%endif
-%if %{using_upstream_branch}
-### BRANCH PATCH ###
-%endif
-
# we also need compile fixes for -vanilla
Patch04: compile-fixes.patch
@@ -1021,14 +1007,12 @@ ApplyPatch()
if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
exit 1
fi
-%if !%{using_upstream_branch}
if ! grep -E "^Patch[0-9]+: $patch\$" %{_specdir}/${RPM_PACKAGE_NAME%%%%%{?variant}}.spec ; then
if [ "${patch:0:8}" != "patch-3." ] ; then
echo "ERROR: Patch $patch not listed as a source patch in specfile"
exit 1
fi
fi 2>/dev/null
-%endif
case "$patch" in
*.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
*.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
@@ -1191,10 +1175,6 @@ ApplyPatch %{stable_patch_00}
ApplyPatch %{stable_patch_01}
%endif
-%if %{using_upstream_branch}
-### BRANCH APPLY ###
-%endif
-
# Drop some necessary files from the source dir into the buildroot
cp $RPM_SOURCE_DIR/config-* .
cp %{SOURCE15} .
--
1.8.4.2
10 years, 3 months
[net-wireless] rtl8187l issues
by Priscila Veiga
Hello kernel-list :)
I have tried with AWUS036H (usb-wifi) that uses driver rtl8187 in F19 and F20 (kernel-3.11 until 3.12.6) but the card stops working (I still need to generate a dump, yeah) after 10 or 15 minutes (it hangs and disconnect). Using airodump-ng I notice no beacons are got, unless of my own bssid.
I tested kali-linux (that is debian) and the card works pretty well.
I compared the driver provided by RealTek ( http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=1&PF... ) and Red Hat ( https://access.redhat.com/knowledge/sources/source_rpms/kernel-2.6.32-358... ) and there seems to be differences since the beginning.
As far I was able to check the Fedora and RHEL drivers are the same. Debian seems use the one provided by RealTek but already compiled (of course).
If you google you will notice this issue (no beacons) is reported since 2010.
Someone already was able to make rtl8187l work in Fedora? How?
Our driver is old? Is the same provided by RealTek or we would need a backport?
Speaking about "backport" I tried use backports ( http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ ) but no luck too. I didn't investigated why once Fedora was not working before anyway.
Any feedback, comments, words, are welcome.
Thanks!
Priscila Veiga
priscila(a)redhat.com
10 years, 3 months
Re: [PATCH] Drop buildid macros
by Josh Boyer
On Mon, Jan 13, 2014 at 5:25 PM, Jarod Wilson <jarod(a)redhat.com> wrote:
> On Mon, Jan 13, 2014 at 04:07:06PM -0500, Josh Boyer wrote:
>> On Mon, Jan 13, 2014 at 3:53 PM, Paul Bolle <pebolle(a)tiscali.nl> wrote:
>> > Josh Boyer schreef op ma 13-01-2014 om 15:41 [-0500]:
>> >> As far as I know, nobody actually uses buildid to differentiate between
>> >> kernel builds.
>> >
>> > Well, I do!
>>
>> OK, so it would be fairer to say "it is infrequently used". :)
>
> Its actually used on a very regular basis by some folks for one-off
> builds. However, said folks are pretty much all internal to Red Hat, doing
> RHEL builds. For example, I craft a test build via 'make rh-srpm
> BUIDLID=".test_foo"', which subs in the BUILDID value for the buildid bit
> in the spec file. We can of course just graft that back in when RHEL8
> branches from Fedora <20 + mumble> in the future. But I personally like
> having the "edit this" part on its own line as its own thing regardless.
> You can have a spec file patch or script that does it much more simply
> than if you have to worry about other things that might be in the var
> you want to tweak.
OK, I guess I'll just drop this one. So much for low-hanging fruit.
As an aside, some of the other changes I'm playing with to split up
the kernel packaging so the cloud people get a tiny kernel to install
are much more invasive. In terms of RHEL<mumble> they'll be a much
bigger impact. They will likely need to be adopted in RHEL land
eventually and not reverted/replaced. I will, of course, post them
first because I'd like review for a bunch of different reasons. I've
already posted this on some of the other discussions, but the general
premise is splitting it into kernel-core and kernel-drivers packages.
josh
10 years, 3 months
[PATCH] Enable SGI UV systems.
by Prarit Bhargava
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1051284
Set CONFIG_X86_UV to 'y' and CONFIG_UV_MMTIMER to 'm' for large SGI boxes.
These settings will enable the booting of more than 16 processors.
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
Cc: glaubitz(a)physik.fu-berlin.de
Cc: jwboyer(a)redhat.com
---
config-x86_64-generic | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/config-x86_64-generic b/config-x86_64-generic
index 15ad1cd..0bb4160 100644
--- a/config-x86_64-generic
+++ b/config-x86_64-generic
@@ -6,7 +6,8 @@ CONFIG_64BIT=y
CONFIG_GENERIC_CPU=y
# CONFIG_X86_VSMP is not set
-# CONFIG_X86_UV is not set
+CONFIG_X86_UV=y
+CONFIG_UV_MMTIMER=m
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_AMD_NUMA=y
--
1.8.3.1
10 years, 3 months
[PATCH] config-generic: disable aic94xx driver
by Paul Bolle
aic94xx is unmaintained upstream. It's not even possible to get a
buildtime warning fixed. No-one seems to be using it. Disable this
driver.
Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl>
---
0) Bravely untested.
1) aic94xx is "maintainerless": https://lkml.org/lkml/2012/10/29/215
2) Three attempts to get its buildtime warning fixed:
- https://lkml.org/lkml/2013/2/20/478
- https://lkml.org/lkml/2012/9/25/265 (I've carried that patch locally
ever since)
- https://lkml.org/lkml/2012/1/30/445
3) There's exactly one report in bugzilla (for the Fedora product and
the kernel component) where someone has actually loaded this driver. But
the hard drive involved was actually broken:
https://bugzilla.redhat.com/show_bug.cgi?id=848798 ! This suggests there
are simply no Fedora users for this driver.
config-generic | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/config-generic b/config-generic
index 1bb85ed..67b0d28 100644
--- a/config-generic
+++ b/config-generic
@@ -437,8 +437,7 @@ CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
-CONFIG_SCSI_AIC94XX=m
-# CONFIG_AIC94XX_DEBUG is not set
+# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_BFA_FC=m
CONFIG_MEGARAID_NEWGEN=y
--
1.8.4.2
10 years, 3 months
