[PATCH] remove kernel-firmware prereq

[Don Zickus]

Now that kernel-firmware is no longer built, can we remove the pre-req so
we don't need to use --nodeps when installing a new kernel?  Or am I
missing some other magic when installing?

Cheers,
Don

Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.1911
diff -u -r1.1911 kernel.spec
--- kernel.spec 3 Feb 2010 21:09:14 -   1.1911
+++ kernel.spec 5 Feb 2010 20:26:42 -
@@ -445,7 +445,7 @@
 # Packages that need to be installed before the kernel is, because the %post
 # scripts use them.
 #
-%define kernel_prereq  fileutils, module-init-tools, initscripts = 8.11.1-1, 
kernel-firmware = %{rpmversion}-%{pkg_release}, grubby = 7.0.4-1
+%define kernel_prereq  fileutils, module-init-tools, initscripts = 8.11.1-1, 
grubby = 7.0.4-1
 %if %{with_dracut}
 %define initrd_prereq  dracut = 001-7
 %else
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [Bug 225969] Merge Review: kernel

[Don Zickus]

On Tue, Oct 26, 2010 at 02:10:23PM -0400, Dave Jones wrote:
 
   kernel.x86_64: W: dangling-relative-symlink
   /lib/modules/2.6.36-1.fc15.x86_64/build
   ../../../usr/src/kernels/2.6.36-1.fc15.x86_64
   
   (It seems odd that /lib/modules/2.6.36-1.fc15.x86_64/build is packaged in
   kernel, but the symlink it points to is in kernel-devel. Is there a reason 
 that
   the /lib/modules/2.6.36-1.fc15.x86_64/build ownership isn't in 
 kernel-devel?)
 
 We flip-flopped on this a few years ago. It used to be that way iirc, but I'm
 not recalling the exact reasoning for why it changed.

I think the problem was the -devel package could be installed without a
kernel package behind it making it awkward to install a symlink.  Even if
you just dropped the symlink on the floor, installing the kernel later
would never re-create the symlink leaving things broken.

IIRC, the dangling symlink was the lesser of two evils.

Not that I care either way.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [Bug 225969] Merge Review: kernel

[Don Zickus]

On Thu, Oct 28, 2010 at 10:50:25AM -0400, Tom spot Callaway wrote:
 On 10/27/2010 11:02 AM, Don Zickus wrote:
  Not that I feel like arguing to save dangling symlink, what happens in the
  case when you install kernel-devel-$KERNVER but there is no
  kernel-$KERNVER installed to match?  Does the rpm fail because
  /lib/modules/$KERNVER doesn't exist?  Or are we going to add a dependency
  to prevent that from happening?
 
 I think that in this situation, it is permissable for both kernel and
 kernel-devel to own /lib/modules/$KERNVER. I'd rather have that
 duplicate directory ownership than a dangling symlink, and the Packaging
 Guidelines permit it.

I didn't realize rpm would allow it.  Let's try it then and see who
screams. :-)

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Wed, Jan 05, 2011 at 11:36:40PM +, Mr Dash Four wrote:
 
  vi .config (this is to add the magic # x86_64 at the top)
  I don't understand why you need a commented line???
  What's the magic about it? A comment is ignored.
 See the Fedora Wiki ( :-D ) for building the kernel - the target arch 
 needs to be added as a comment on the first line of that .config file 
 (that is particularly important if I do cross-compilation of the kernel 
 - I add # i386 for i686 targets for example). If that is not present 
 all hell breaks loose!

I think we use it during the 'make nonint_oldconfig' stage, ala

for i in $config_list
  ARCH=`cat $i|head -1|sed 's/# //'`
  cp $i .config
  make ARCH=$ARCH nonint_oldconfig
  cp .config configs/$i

without the #$arch thing, we wouldn't know what arch to pass into the
kernel Makefile system to get the right config options.

 
  cp .config ~/rpmbuild/SOURCES/config-x86_64-generic

Yeah that won't work (explained below)

 
  This will not guarantee that the config file will not be modified.
  I have done this numerous times, and I can tell you unequivocally,
  it will not keep all the options you want, nor will it exclude all the
  options you do NOT want.
  What it will give you is a beast that is niether what you want nor
  what you do not want.
  This is the wierdness of the .spec file operations and the Makefile
  script in ...SOURCES/Makefile.config
 What would you advice me to do then?! I need to end up with 3 
 kernel-*.rpm files plus one perf*.rpm, which I can distribute to all my 
 machines. The above set of instructions is what Fedora Wiki ( :-D ) 
 advices on building the kernel...
 
  The fedora release people have not provided us with a mechanism
  that will let us build a kernel EXACTLY as the config file we save in
  the SOURCES directory.
 What do they actually change - after I build and install the kernel and 
 then check the corresponding .config file in the /boot 
 partition/directory it is the same as the one I have copied as 
 config-x86_64-generic, so, naturally, I assume that nothing has been 
 modified/changed. Is that not the case?

The way the config options work is basically a bunch of templates that
override each other as they get stacked on top.  So

config-generic is usually the base config that all arches start with
config-$ARCH-generic is merged onto config-generic and overrides those
options
config-$ARCH-$VARIANT is merged onto that with more overrides

the result config blob is full of stuff that may or may not be relevant to
the particular type of kernel we are building, therefore we use the
for-loop (from earlier in the email), to filter out that cruft.  The magic
is 'make ARCH=$ARCH nonint_oldconfig'  (think make oldconfig without the
prompting).

The output files are kernel-$version-$arch.config.  If you want to copy
.config files somewhere, it really should be the kernel-*.config files.
But I don't have the .spec file handy to know if those get repeatedly
overwritten on a rpmbuild.

The way the kernel maintainers set the options is to modify the
config-$pickone-generic  file with the option you care about to on/off.

But as explained in other threads, we never supported custom configs so no
one really designed a process to make it easy.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Thu, Jan 06, 2011 at 04:14:08AM +, Mr Dash Four wrote:
 
 See the Fedora Wiki ( :-D ) for building the kernel - the
 target arch needs to be added as a comment on the first line of
 that .config file (that is particularly important if I do
 cross-compilation of the kernel - I add # i386 for i686
 targets for example). If that is not present all hell breaks
 loose!
 
 I think we use it during the 'make nonint_oldconfig' stage, ala
 
 for i in $config_list
   ARCH=`cat $i|head -1|sed 's/# //'`
   cp $i .config
   make ARCH=$ARCH nonint_oldconfig
   cp .config configs/$i
 
 without the #$arch thing, we wouldn't know what arch to pass into the
 kernel Makefile system to get the right config options.
 When I start the rpmbuild -bb process (from where everything kicks
 on) I could specify a --target=XX parameter. Why can't the build
 system utilise that? A simple solution would be echo
 target_parameter_value  .target_arch, not to mention that this
 can also be stored in the environment as a variable. To add '# arch'
 every time I change the .config file is a bit, well, archaic, don't
 you think?

Well it was written 6-7 years ago. ;-)  No one cared enough to change it.
But regardless, it is only used as a temporary thing to get by running
'make ARCH=$ARCH nonint_oldconfig' I think.

Most developers here are used to doing the equivalent of a
'rpmbuild -bp' and have the config files spit out for all the arches
regardless of the --target passed in.

Anyway, patches welcome, if you think it is worth fixing.

 
 cp .config ~/rpmbuild/SOURCES/config-x86_64-generic
 
 Yeah that won't work (explained below)
 Would it work if I delete ALL .config files and leave the one I
 quoted above? If all .configs just 'stack-up', then by deleting
 everything else but what I actually configured should, in theory, do
 the trick, right?

Never tried it, but your theory makes sense to me.  Try it and see what
happens.

 
 
 What do they actually change - after I build and install the
 kernel and then check the corresponding .config file in the
 /boot partition/directory it is the same as the one I have
 copied as config-x86_64-generic, so, naturally, I assume that
 nothing has been modified/changed. Is that not the case?
 
 The way the config options work is basically a bunch of templates that
 override each other as they get stacked on top.  So
 
 config-generic is usually the base config that all arches start with
 config-$ARCH-generic is merged onto config-generic and overrides those
 options
 config-$ARCH-$VARIANT is merged onto that with more overrides
 
 the result config blob is full of stuff that may or may not be relevant to
 the particular type of kernel we are building, therefore we use the
 for-loop (from earlier in the email), to filter out that cruft.  The magic
 is 'make ARCH=$ARCH nonint_oldconfig'  (think make oldconfig without the
 prompting).
 Rght! I get it now - a bit complicated, but at least I know what
 is happening! Thanks for that insight! My suggestion above stays
 though - would it work that way?
 
 The output files are kernel-$version-$arch.config.  If you want to copy
 .config files somewhere, it really should be the kernel-*.config files.
 I've noticed there are 2 files like that
 linux-ver-arch/configs/kernel-ver-arch.config and another
 file called kernel-debug-ver-arch.config. these files have the
 DRM_NOVEAU section of options missing from my .34 config file, but
 they are just a starting point and if I want to merge an older
 version (.34) with these by using oldconfig, that won't work - I
 already tried that as well.

I guess the kernel-*.config files get overwritten every time then.

 
 But I don't have the .spec file handy to know if those get repeatedly
 overwritten on a rpmbuild.
 Tomorrow when I have more time to play with this stuff I would be
 able to check it out.
 
 The way the kernel maintainers set the options is to modify the
 config-$pickone-generic  file with the option you care about to on/off.
 
 But as explained in other threads, we never supported custom configs so no
 one really designed a process to make it easy.
 So, if I use my customised .config file from the .34 version and
 call it config-x86_64-generic would that do the trick? Would I be
 able to get all the options merged in the final
 configs/kernel-2.6.35.xx-xx.config file do you think?

That could work too, I believe (again never tried).

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Wed, Jan 05, 2011 at 07:53:38PM -0800, JD wrote:
 Thank you for the elucidation, Don.  I find it very useful,
 as I have struggled with this issue for a long time.
 
 So, for a sysadmin, who needs a custom configured kernel
 for multiple machines, and wants to produce the custom
 binaries for these machines that have same architecture and
 devices, to enable features and drivers that are not by
 default enabled in the vanilla fedora binary rpm: what is the
 sysadmin to do?
 
 It seems to me that the rpm packagers need to provide a way
 for the admin to use an existing config file which has enabled
 all that is needed, as a base config file. Thus running rpmbuild
 should somehow use this base config file, and add to it if necessary,
 but at least keep the features/drivers that are enabled in the
 base config file, enabled for the actual build.
 
 To date, I have not succeeded in producing a kernel with my drivers
 enabled as per an existing config file, using the rpmbuild method.
 PS: my needed drivers are in staging, and they work. But I do not
 seem to be able to use my current .config file 
 (/boot/config-2.6et...etc)
 as a base config file (such as ~/rpmbuild/SOURCES/config-x86-generic
 (my arch is i686), when building from a new source rpm release.
 It never yielded a kernel with my drivers enabled.

Try config-i686-PAE and see if that works instead.  That file overrides
config-x86-generic (according to Makefile.config) and fedora uses i686-PAE
by default.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Wed, Jan 05, 2011 at 11:47:41PM -0500, Jarod Wilson wrote:
  So, what do I do? I simply prep from source
  (rpmbuild -bp kernel.spec)
  and then cd to ~/rpmbuild/BUILD/kernel-2.6.35.10-74/linux-2.6.35.i686,
  copy my current kernel's config file to .config, run
  make oldconfig and
  male all
  and that does it.
  The new config file inherits my enabled drivers selections.
 
 From the kernel spec:
 
 # Dynamically generate kernel .config files from config-* files
 make -f %{SOURCE20} VERSION=%{version} configs
 
 And Source20 is Makefile.config, from which with a bit of effort, you can
 determine the order in which the various config-* files are smashed
 together to form the end result .config files.
 
 I think this topic actually came up once in the past, and an idea to add
 an extra layer similar to the 'if rhel' clause in the spec was kicked
 around, but never came to fruition. In theory, that file would, if
 present, apply additional Kconfig changes from an additional overrides
 file. It could be an empty file by default, but obviously named or
 documented, so that anyone rebuilding could simply put their assorted
 additional config options in there, and they'd always be applied over the
 top of the stock config options.

Ha!  I can't believe the rhel stuff I added is still there.
We could probably mimic the old linux-kernel-test.patch which was a stub
patch to allow developers to quickly test their patches without mucking
with the spec file, but instead for config files (like the %rhel thing).

Now that I finally figured out how to use the fedpkg thing, I can actually
look at the spec file.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Thu, Jan 06, 2011 at 10:18:42AM -0500, Jarod Wilson wrote:
  We could probably mimic the old linux-kernel-test.patch which was a stub
  patch to allow developers to quickly test their patches without mucking
  with the spec file, but instead for config files (like the %rhel thing).
 
 I think this would suffice:
 
 # This file is empty in stock builds, but can be populated with local
 # config option overrides for custom local builds
 Source1000: config-local
 
 
 Then, in %prep, in a loop similar to the if rhel one:
 
 ./merge.pl %{SOURCE1000} $i.tmp  $i
 
 
 Since the file is empty in stock configs, the above in that case would
 simply be a no-op. If its populated by someone doing a local rebuild, then
 their config options get overlayed on top of the stock ones.

That is sorta what I was thinking too.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: linux-2.6-debug-nmi-timeout.patch

[Don Zickus]

On Mon, Jan 10, 2011 at 10:12:23AM -0500, Kyle McMartin wrote:
 arch/x86/kernel/apic/nmi.c has been removed upstream, so I'm wondering
 how to merge this patch...
 
 The most appropriate place to change the sample period appears to be
 kernel/watchdog.c::get_sample_period and making the '5' configurable,
 but obviously that isn't quite the same as what the original patch
 intended.
 
 Or, should I drop the patch since it seems to be generally
 unnecessary...

Dropping the patch is appropriate.  x86 stopped using the old nmi watchdog
awhile ago, and Fedora seemed to have been using the new nmi_watchdog, so
the patch does nothing now.

As for its intent, what started with Aris' patch slowly diverged into a
rewrite of the nmi watchdog upstream. :-)  Upstream, I slow everything
down to 60 seconds per Ingo's suggestion.  This should also help for
laptops too (well a little bit, we have room for improvement here).

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Tue, Jan 11, 2011 at 07:16:33PM +, Mr Dash Four wrote:
 
 Executing make oldconfig does not change that! DRM_NOVEAU group of
 options are vital as they compile the driver for my video card and
 if this is missing I am getting the VGA-style bootup screen and
 everything is a mess - all this I have already described in the
 first post of this thread.
 
 Am I doing something wrong?

Can you show me in your attached config file where DRM_NOVEAU is defined?
I don't see it in either of the .config files you attached?

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Tue, Jan 11, 2011 at 08:03:04PM +, Mr Dash Four wrote:
 
 
 Don Zickus wrote:
 On Tue, Jan 11, 2011 at 07:16:33PM +, Mr Dash Four wrote:
 Executing make oldconfig does not change that! DRM_NOVEAU group of
 options are vital as they compile the driver for my video card and
 if this is missing I am getting the VGA-style bootup screen and
 everything is a mess - all this I have already described in the
 first post of this thread.
 
 Am I doing something wrong?
 
 Can you show me in your attached config file where DRM_NOVEAU is defined?
 I don't see it in either of the .config files you attached?
 Lines 3080-3082 of solar-34-options.config (which is later copied to
 config-local):
 
 CONFIG_DRM_NOUVEAU=m
 CONFIG_DRM_NOUVEAU_BACKLIGHT=y
 CONFIG_DRM_NOUVEAU_DEBUG=y

Oh, I suck, I searched for DRM_NOVEAU instead of DRM_NOUVEAU.


Jarod figured it out.  For some reason CONFIG_STAGING needs to be set to
'y' for DRM_NOUVEU to be enabled for some reason.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: 2.6.35.10-74 compilation (and build) problems

[Don Zickus]

On Tue, Jan 11, 2011 at 08:38:32PM +, Mr Dash Four wrote:
 
 Oh, I suck, I searched for DRM_NOVEAU instead of DRM_NOUVEAU.
 I did exactly the same as you as my French is really crap!
 
 Jarod figured it out.  For some reason CONFIG_STAGING needs to be set to
 'y' for DRM_NOUVEU to be enabled for some reason.
 How did it work in my .34 version without CONFIG_STAGING being set
 then? Do I really need to scan through all Kconfig files in order to
 see what has/hasn't changed and then figure out what needs to be
 changed/added to the config-local file then?
 
 The patch should be transferring my options - it doesn't, end of!

It did and worked perfect.  The problem was you overrode CONFIG_STAGING
which in turn disabled things that you cared about.

 
 CONFIG_DRM_NOUVEAU is a case in point - at least I should have been
 warned what's coming! It is not just these options that haven't been
 transferred - run diff on the two files I attached and see how many
 other options have not been transferred over.
 
 If I am supposed to check every Kconfig file in order to see what
 will be applied and what not, then I am better off ditching the
 bl**dy patch and entering everything manually - why bother
 otherwise?!

Listen the tools Fedora uses are designed to help maintainers catch config
options that are not specified.  They were never designed to help people
swim through the sea of endless config options.  The maintainers already
go through the Kconfig files to see what options to select.  It sucks
everyone knows that.  This is why Fedora selects as many as possible and
provides them.  This is why upstream has a 'make defconfig' option.

Choose the options that are important to you and stick them into
config-local.  Let Fedora choose the rest for you.

Cheers,
Don

___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH 2/3] [RFC] Print a watchdog message at KERN_WARNING level

[Don Zickus]

On Fri, Feb 04, 2011 at 06:32:33PM +0100, Paul Bolle wrote:
 On Fri, 2011-02-04 at 10:27 -0500, Don Zickus wrote:
  I am concerned about the error you are seeing, -95.  Is it possible you can
  provide me a 'dmesg' log of your boot up.  I want to see what chipset the
  perf subsystem thinks it found.
 
 Sure, no problem. Off-list or on-list?

on-list is fine.

 
 And what messages in dmesg are you interested in? All or just some?
 
 I suppose I should try a boot without the quiet kernel parameter. Is
 there some debug parameter that would be helpful here too?

you can just run 'dmesg  /tmp/dmesg.out' after you login and then attach
that file to a reply to this thread.  I'll I am interested in is the few
lines above the NMI watchdog error that starts with Performance Events:
But you can post the whole thing for completeness.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH 2/3] [RFC] Print a watchdog message at KERN_WARNING level

[Don Zickus]

On Fri, Feb 04, 2011 at 08:42:34PM +0100, Paul Bolle wrote:
 On Fri, 2011-02-04 at 13:38 -0500, Don Zickus wrote:
  [All] I am interested in is the few
  lines above the NMI watchdog error that starts with Performance Events:
 
 [0.016136] Performance Events: 
 [0.016139] no APIC, boot with the lapic boot parameter to force-enable 
 it
 [0.016142] no hardware sampling interrupt available.
 [0.016146] p6 PMU driver.
 [0.016151] ... version:0
 [0.016153] ... bit width:  32
 [0.016156] ... generic registers:  2
 [0.016158] ... value mask: 
 [0.016161] ... max period: 7fff
 [0.016163] ... fixed-purpose events:   0
 [0.016166] ... event mask: 0003
 [0.017455] NMI watchdog disabled for cpu0: unable to create perf event: 
 -95
 
 Feel free to ask me for what else might be needed here.

Thanks for the info.  This is what I thought, the system has no lapic.  I
think I am going to re-arrange some code to properly deal with this
scenario.  Not having a lapic should not be a KERN_ERR, the nmi watchdog
should just accept it, print out a quiet message and move on. :-)

Thanks for finding this and providing the info!

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH 2/3] [RFC] Print a watchdog message at KERN_WARNING level

[Don Zickus]

On Wed, Feb 09, 2011 at 02:10:49PM +0100, Paul Bolle wrote:
 On Tue, 2011-02-08 at 16:46 -0500, Don Zickus wrote:
  Here is a patch I was looking to post upstream.  This should address your
  concerns.  Let me know how it works out for you.
 
 0) Compiles cleanly.
 1) Nothing shows up anymore at boot a with Fedora's default command
 line.
 2) dmesg -r | grep NMI
 6[0.019692] NMI watchdog disabled (cpu0): not supported (no LAPIC?)
 
 For what testing one of three branches is worth:
 
 Tested-by: Paul Bolle pebo...@tiscali.nl

Thanks!

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH] Add patch to let watchdog and perf work on Pentium4s (rhbz 713675)

[Don Zickus]

On Wed, Oct 19, 2011 at 04:32:07PM -0400, Dave Jones wrote:
 On Wed, Oct 19, 2011 at 02:43:44PM -0400, Don Zickus wrote:
   Not sure what the patch prefence is for the mailing list.  This patch 
 applies
   to the fedpkg kernel git tree.  Better changelog below.
   
   Waiting on test feedback.
  
 Patch looks ok.  The bug is against f15, but I'm assuming we want this
 on all branches. (And amusingly, f15 gets the most rejects..)

These are 3.1 backports, so I think just f15.  I assume f16 will go out
the door with 3.1?

 
 (16:24:26:davej@adamo:fedora-kernel)$ ./apply.sh f15 perf.diff 
 patching file kernel.spec
 Hunk #1 FAILED at 649.
 Hunk #2 FAILED at 1240.
 2 out of 2 hunks FAILED -- saving rejects to file kernel.spec.rej
 patching file x86-p4-make-watchdog-and-perf-work-together.patch

Yeah, sorry I wasn't sure if I should post the patch or the what I
committed to git.
 
 the spec rejects are pretty trivial of course, but do you want to just
 create a fedora account, for committing stuff like this ?
 Backports are usually non-controversial.

For some bizarre reason I am still enjoying other people committing my
patches. ;-p

I think I have a fedora account (maybe not commit permission), but it
doesn't matter to me.  Josh asked me to post, so I posted. :-)

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Kernel-3.1 Crash

[Don Zickus]

On Thu, Oct 27, 2011 at 06:59:12PM +0200, Antonio Trande wrote:
 The digital picture are here:
 http://sagitter.fedorapeople.org/kernel-boot.tar.gz

According to our DM guys this fix just missed 3.1

http://git.kernel.dk/?p=linux-block.git;a=commit;h=f26d8f0562da76731cb049943a0e9d9fa81d946a
http://git.kernel.dk/?p=linux-block.git;a=commit;h=8f02b3a09b1b7d2a4d24b8cd7008f2a441f19a14

I cc'd Jeff Moyer he knows about it.  The DM folks assume that you are
using multipath (as that is the only way you can hit this bug from their
point of view).

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Kernel-3.1 Crash

[Don Zickus]

On Thu, Oct 27, 2011 at 02:29:56PM -0400, Jeff Moyer wrote:
 Don Zickus dzic...@redhat.com writes:
 
  On Thu, Oct 27, 2011 at 06:59:12PM +0200, Antonio Trande wrote:
  The digital picture are here:
  http://sagitter.fedorapeople.org/kernel-boot.tar.gz
 
  According to our DM guys this fix just missed 3.1
 
  http://git.kernel.dk/?p=linux-block.git;a=commit;h=f26d8f0562da76731cb049943a0e9d9fa81d946a
  http://git.kernel.dk/?p=linux-block.git;a=commit;h=8f02b3a09b1b7d2a4d24b8cd7008f2a441f19a14
 
  I cc'd Jeff Moyer he knows about it.  The DM folks assume that you are
  using multipath (as that is the only way you can hit this bug from their
  point of view).
 
 This doesn't look like the same problem.  Here we've got BUG: scheduling
 while atomic.  If it was the bug fixed by the above commits, then you
 would hit a BUG_ON.  I would start looking at the btrfs bits to see if
 they're holding any locks in this code path.

Ignore that one and move to IMG_0350.IMG.  'scheduling while atomic' is
just noise.  Besides Mike and Vivek told me to blame you for not pushing
Jens harder on these fixes. :-)

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Kernel-3.1 Crash

[Don Zickus]

On Thu, Oct 27, 2011 at 02:43:22PM -0400, Jeff Moyer wrote:
  This doesn't look like the same problem.  Here we've got BUG: scheduling
  while atomic.  If it was the bug fixed by the above commits, then you
  would hit a BUG_ON.  I would start looking at the btrfs bits to see if
  they're holding any locks in this code path.
 
  Ignore that one and move to IMG_0350.IMG.  'scheduling while atomic' is
  just noise.  Besides Mike and Vivek told me to blame you for not pushing
  Jens harder on these fixes. :-)
 
 I'm looking at 0355, which shows the very top of the trace, and that
 says BUG: scheduling while atomic.  So the problem reported here *is*
 different from the one fixed by the above two commits.  In fact, I don't
 see evidence of the multipath + flush issue in any of these pictures.

You have to ignore the 'schedule while atomic' thing it is just a

printk(BUG: scheduling while atomic), it is _not_ a BUG().  :-)
(hint read kernel/sched.c::__schedule_bug)

I see those messages all the time, it really should be a WARN and not a
misleading BUG, but whatever. 

His machine died because the NMI watchdog detected a lockup.  The lockup
was because in blk_insert_cloned_request(), spin_lock_irqsave disabled
interrupts and spun forever waiting on the q-queue_lock (IMG_0350.JPG).

Mike and Vivek both said that is what you fixed for 3.2.  They also said
the only caller of blk_insert_cloned_request() is multipath, hence that
argument.  I'll cc them.  Or maybe I can have them walk over to your cube.
:-)

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: grubby fatal error: unable to find a suitable template

[Don Zickus]

On Mon, Dec 19, 2011 at 05:56:42PM -0500, Steve Dickson wrote:
 Hello all,
 
 I'm getting the $SUBJECT error when I try to
 install a rawhide kernel on an updated f16 vm.
 
 # rpm -ihv  kernel-3.2.0-0.rc6.git0.1.pnfsdlexp.fc16.x86_64.rpm   
 Preparing...### 
 [100%]  
1:kernel ### 
 [100%]  
 grubby fatal error: unable to find a suitable template
 # uname -r
 3.1.5-6.fc16.x86_64

My experience with the upgrading to F16 was the new grub2 was causing the
problems.  However, the way the install scripts were written, they update
both grub.conf (grub1) and grub2.cfg (grub2).  grub.conf is updated
correctly, it is just the grub2.cfg isn't (in fact it is empty, hence the
warning).  Because my system still uses grub1 in the bootloader (not sure
how to force it to use grub2), everything boots fine for me (for now :-/
).  So I just ignore the warning.

 
 Things like the network and NFS do not come up due the fact the modules can 
 not 
 be found... so things are not being installed correctly 

This I noticed on my one box is because systemd starts network and NFS in
parallel and NFS finishes ahead (and fails) of a fully configured network.
After I log in, usually a 'mount -a' fixes my NFS woes (though it is
annoying).  It would be nice to tell NFS to block until the network is up.

That is my experiences so far with the same problems you have.  I should
probably file bugzilla, then again you said others have already done that.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: How to fix the kernel RPM build problem when a patch is applied?

[Don Zickus]

cc'ing fedora in case this helps others.

On Mon, Jan 09, 2012 at 07:51:43PM +0800, GaoYi wrote:
 Hi Don,
 
I 've encounter the same error as your previous message:
 http://markmail.org/message/6pkwdnxfhlh35cld#query:+page:1+mid:yf2bsyvd6l3g5rke+state:results
 .
 
I would like to know  make non_oldconfig will use which config file when
 build the kernel RPM package. And can you provide more details about how
 you finally fix this problme?

I assume you added a custom patch to your rpm package.  This patch
probably required an option.  The fedora tree was designed to fail if an
option is not defaulted to on/off.  So you have to tell the build how you
want to set the option.

In order to do that, you might need to understand how the config stuff
gets merged.  It starts with config-generic and gets various arch and
kernel variant configs applied on top (overriding what was underneath).

The easiest thing for you to do is to take the config option that is spit
out as an error (CONFIG_TIPC_UNICLUSTER_FRIENDLY and others in your link
above), and add it to the bottom of config-generic with either a y/n/m
like so:

CONFIG_TIPC_UNICLUSTER_FRIENDLY=y
or
CONFIG_TIPC_UNICLUSTER_FRIENDLY=m
or
# CONFIG_TIPC_UNICLUSTER_FRIENDLY is not set

That should solve your 'make non_oldconfig' problem.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: How to fix the kernel RPM build problem when a patch is applied?

[Don Zickus]

On Mon, Jan 09, 2012 at 09:59:30AM -0500, Josh Boyer wrote:
 On Mon, Jan 9, 2012 at 9:55 AM, Don Zickus dzic...@redhat.com wrote:
  The easiest thing for you to do is to take the config option that is spit
  out as an error (CONFIG_TIPC_UNICLUSTER_FRIENDLY and others in your link
  above), and add it to the bottom of config-generic with either a y/n/m
  like so:
 
  CONFIG_TIPC_UNICLUSTER_FRIENDLY=y
  or
  CONFIG_TIPC_UNICLUSTER_FRIENDLY=m
  or
  # CONFIG_TIPC_UNICLUSTER_FRIENDLY is not set
 
  That should solve your 'make non_oldconfig' problem.
 
 Or just add it to config-local.  That gets merged last and is intended
 for local builds and such.

Ah good point.  Always useful to cc the list. :-)

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: How to fix the kernel RPM build problem when a patch is applied?

[Don Zickus]

please keep fedora kernel cc'd, there are better people who can answer
this than me.

On Tue, Jan 10, 2012 at 11:19:26AM +0800, GaoYi wrote:
 Hi Don,
 
Thanks very much for your prompt reply. I've tried your method to
 modified the config-generic in the extracted path: /root/rpmbuild/SOURCES/.
 
I am using the kernel-2.6.33.3-85.fc13.src.rpm. There seems to be a
 nonint_config patch: linux-2.6-build-nonintconfig.patch.

yes, but there is no need to touch that.

 
I wonder which config file will be exactly used when performing 'make
 noint_oldconfig'. It may be generated by copying from the other file in
 building process. If so, which is the orginal one?

what are you trying to do?  Josh already correctly suggested to add whatever
config options you need into config-local.

There is no one config file, it is a combination of config files merged
together.  And 'make noint_oldconfig' does not create the config file,
just executes on .config.

Hope that helps.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Using merge_config.sh

[Don Zickus]

On Wed, Feb 01, 2012 at 01:33:41PM -0500, Josh Boyer wrote:
 Hi All,
 
 We've been using merge.pl to merge Fedora's config file fragments for as
 long as I can remember.  However, in the interest of using what's
 upstream, I took a look at the newly added merge_config.sh script and
 what it would take to use that instead.

I remember looking at this last week and thinking the same thing.  I
remember hacking on merge.pl years ago and optimizing to run really fast.
Even today there are RH folks who complain it still runs slow.

I thought the same as you, why not start using the upstream approach and
have one less thing to maintain/worry about in the fedora spec file.

But the major plus with using perl was you could cache the file in memory
and it only had to be read once.  With the script, files are read multiple
times which add to the delay.

There is really no way around it unless upstream converts to perl or
python or even 'c'.

So I would be torn and lean away from it until the speed improves.  I know
if this makes it to RHEL people would complain and it would get ripped out
in favor of the old way.

My two cents.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Modular Kernel Packaging for Cloud

[Don Zickus]

On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote:
 On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus dzic...@redhat.com wrote:
  On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro red Mathys wrote:
  For example, lets start with 100MB package requirement for the kernel (and
  say 2 GB for userspace).  This way the kernel team can implement
  reasonable changes and monitor proper usage (because things grow over
  time).
 
  If later on you realize 100 MB is not competitive enough, come back and
  chop it down to say 50 MB and let the kernel team figure it out.
 
  But please do not come in here with a 'every MB counts' approach.  It is
  not very sustainable for future growth nor really easy to implement from
  an engineering approach.
 
  Is that acceptable?  The kernel team can start with a hard limit of 100MB
  package requirement (or something reasonably less)?  Let's work off budget
  requirements please.
 
 This is a fair point.  To be honest, I've ignored the every MB
 counts aspect entirely for now.  I've instead been focusing on
 required functionality, because that's likely going to be the main
 driver of what the resulting size will be.

Of course. :-)

 
 FWIW, the existing kernel package installed today (a debug kernel
 even) is ~142 MB.  123MB of that is the /lib/modules content.  ~6MB of
 that is vmlinuz.  The remaining 13MB is the initramfs, which is
 actually something that composes on the system during install and not
 something we can shrink from a packaging standpoint.

It also helps with monitoring.  3-4 years from now after all the chopping,
these pacakges bloat right back up and everyone forgets why we chopped in
the first place.  Hard requirements help keep everything in check and
forces people to request more space which the cloud team can evaluate
properly and still control their enviroment.

Anyway, this was just my rant for the day.  I saw the initial email and
immediately disagreed with the approach.  Spent a few minutes thinking of
a better way and thought, well I wasted a few minutes thinking about it
might as well respond in email. :-)

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Modular Kernel Packaging for Cloud

[Don Zickus]

On Wed, Mar 05, 2014 at 09:28:45AM -0700, Kevin Fenzi wrote:
 On Wed, 5 Mar 2014 10:16:21 -0500
 Don Zickus dzic...@redhat.com wrote:
 
  Also,  I just arbitrarly threw out 100MB, if we should start higher,
  say 150MB, then it doesn't matter to me. :-)
 
 This entire disk size optimization seems kind of weird to me. 
 
 I just booted a f20 offiical cloud image in our openstack cloud. I used
 the m1.tiny (smallest size, no persistent storage): 
 
 Filesystem  Size  Used Avail Use% Mounted on
 /dev/vda120G  1.1G   19G   6% /
 
 Is a few 10's of MB's really worth making our kernel a bunch more
 complex? Is disk space the right thing to be trying to optimize? 
 
 Perhaps I am missing it, but are there cases where the current cloud
 image is too large? what are they?

Haha.  Great point!

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Modular Kernel Packaging for Cloud

[Don Zickus]

On Thu, Mar 06, 2014 at 08:16:00AM +0900, Sandro red Mathys wrote:
 On Thu, Mar 6, 2014 at 12:13 AM, Don Zickus dzic...@redhat.com wrote:
  On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote:
  On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus dzic...@redhat.com wrote:
   On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro red Mathys wrote:
   For example, lets start with 100MB package requirement for the kernel 
   (and
   say 2 GB for userspace).  This way the kernel team can implement
   reasonable changes and monitor proper usage (because things grow over
   time).
  
   If later on you realize 100 MB is not competitive enough, come back and
   chop it down to say 50 MB and let the kernel team figure it out.
  
   But please do not come in here with a 'every MB counts' approach.  It is
   not very sustainable for future growth nor really easy to implement from
   an engineering approach.
  
   Is that acceptable?  The kernel team can start with a hard limit of 100MB
   package requirement (or something reasonably less)?  Let's work off 
   budget
   requirements please.
 
  This is a fair point.  To be honest, I've ignored the every MB
  counts aspect entirely for now.  I've instead been focusing on
  required functionality, because that's likely going to be the main
  driver of what the resulting size will be.
 
 That's the point, we want a reasonably small package while still
 providing the required functionality. Not sure how providing a fixed
 size number is helping in this. But most of all, I didn't throw in a
 number because I have no idea what is reasonably possible. I really
 only just said every MB counts because the question came up before
 (in Josh's old thread) and I hoped I could stop this discussion from
 happening again before we have any numbers for this.

Ever work in the embedded space?  Every MB counts there too. :-)  This was
solved by creating budgets for size and memory requirements.  This helped
control bloat, which is going to be your biggest problem with cloud
deployment.

What concerns me is that you don't know what size your cloud deployment is
but expect everyone to just chop chop chop.  How do we know if the kernel
is already at the right size?

There is s a huge difference between re-architecting the kernel packaging
to save 1 or 2 MB (off ~143 MB size currently) vs. re-architecting to save
50 MB.  The former is really a wasted exercise in the bigger picture,
wherease the latter (if proven needed) accomplishes something.

But again it comes down to understanding your environment.  Understanding
your environment revovles around control.  I get the impression you are
not sure what size your environment should be.

So I was proposing the kernel stay put or maybe create _one_ extras
package that gets installed in addition to the bzImage.  But from the
sound of it, the chopping is really going to get you savings of about
~30MB or so.

The thing is a few years ago, the kernel converted a lot of modules to
built-ins (inside the kernel).  What that means from a novice perspective
is we took a whole bunch of external bloat that could be stripped away and
stuffed it into the kernel binary itself.  The goal at the time was to
speed up boot times (because loading modules was slow).

Now with the re-design of module loading in the last couple of years,
maybe this can be reverted.  This could shave MBs off the kernel binary
itself.  And then you can only package the modules cloud really needs.

This at least has the ability to scale across other SIGs too.

However, this all hinges on _how much chopping we should do_.  I doubt
Josh really wants to embark on this thrashing without very good convincing
reason to do so.

So having some numbers to work off of, provides us the right idea how much
and what type of work needs to get done (little tweaks vs re-think the
whole approach).


 
  Of course. :-)
 
 
  FWIW, the existing kernel package installed today (a debug kernel
  even) is ~142 MB.  123MB of that is the /lib/modules content.  ~6MB of
  that is vmlinuz.  The remaining 13MB is the initramfs, which is
  actually something that composes on the system during install and not
  something we can shrink from a packaging standpoint.
 
  It also helps with monitoring.  3-4 years from now after all the chopping,
  these pacakges bloat right back up and everyone forgets why we chopped in
  the first place.  Hard requirements help keep everything in check and
  forces people to request more space which the cloud team can evaluate
  properly and still control their enviroment.
 
 Well, if we can remember why we put up a fixed size requirement, why
 can't we remember why we did the chopping? ;) Anyway, I think it's

Heh.  Ever work with open source projects?  The turnover and lost
knowledge is one thing.  However, to me the biggets problem would be the
'lack of caring'.

Trust me you can convince everyone to chop MBs out of their packages.  You
might even get something really small for your cloud

Re: Modular Kernel Packaging for Cloud

[Don Zickus]

On Thu, Mar 06, 2014 at 08:38:44AM +0900, Sandro red Mathys wrote:
 On Thu, Mar 6, 2014 at 1:45 AM, Kevin Fenzi ke...@scrye.com wrote:
  On Wed, 05 Mar 2014 17:37:42 +0100
  Reindl Harald h.rei...@thelounge.net wrote:
  in general you need to multiply the wasted space for each instance
 
 Exactly, you usually have hundreds or even thousands of instances
 running. Sure, every MB counts isn't to be taken literal here, maybe
 I should rather have said every 10 MB count.
 
  At least for my uses, the amount of non persistent disk space isn't a
  big deal. If I need disk space, I would attach a persistent volume...
 
 Figure you get your additional persistent volumes for free somehow, so
 all those Amazon AWS, HP Cloud, Rackspace, etc. users envy you. And
 those admins that need to buy physical disks to put into their private
 clouds, too.
 
 Also, more data equals more network traffic and more time - both
 things that matter in terms of costs, at least in public clouds.

Sure, but what if the trade-off in size comes with a cost in speed?  Is
cloud ok with the kernel taking twice as long to boot?  Or maybe running
slower?  Or maybe crashing more often (because we removed safety checks?).

I mean if Josh wanted to he could make everything modular and have a
really small kernel footprint (like 40MB or so) running in 50MB of memory
(I have done this with kdump).  But it costs you speed in loading modules
(as opposed to built into the kernel).  You may lose other optional
optimizations that help speed things up.

Other SIGs made not like it, but again it depends on how you frame your
environment.  Maybe cloud really needs its own kernel.  We don't know.

What is cloud willing to sacrafice to obtain smaller size?

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Modular Kernel Packaging for Cloud

[Don Zickus]

On Thu, Mar 06, 2014 at 11:32:55AM -0500, Matthew Miller wrote:
 On Thu, Mar 06, 2014 at 11:02:47AM -0500, Josh Boyer wrote:
  If it's _necessary_, that's one thing.  I've yet to really see any data
  backing up necessity on any of this at all though.  Right now it seems
  to be sitting in the nice to have category.
 
 For the record, it is _literally_ sitting in our nice to have category.
 See
 https://fedoraproject.org/wiki/Cloud_Changelist#Change:_Cloud-Friendly_Kernel_Packaging
 
 :)
 
 
  Perhaps someone from the cloud team could look at existing images from
  other distros and figure out kernel sizes there, and how it plays into
  usage and cost in those environments?
 
 On the ubuntu EC2 image, /lib/modules/$(uname -r) is 24M + 5.2M vmlinuz +
 1.1M in /lib/firmware. Total package size is 32M on disk. And 5.9M initrd.
 
 CoreOS is bigger, with 33M in /lib/modules and 5.2M in lib/firmware, and a
 /19M vmlinuz.

Yeah, hard numbers to compete with! :-)

I think Josh is mostly there.  He has 58MB + 5M vmlinuz + similar?
firmwre.

He just has to cut 35MB or so from /lib/modules/.  We can probably nickel
and dime and review a lot of cruft to get there, but what is that 35MB
really doing to get us anything?  I am sure half of that can be removed by
re-examining the minimal-list he sent (I can even help there).

Maybe impose only xfs as the fs of choice or some other restrictions and
chop it further, but then we lose flexibility.

Instead of competing with Ubuntu on minimalist can we compete on pretty
close but a lot more flexible?  Do Ubuntu users have much choice on how
they configure their environment?  Or is Fedora Cloud providing a generic
cookie cutter installation?

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Modular Kernel Packaging for Cloud

[Don Zickus]

On Fri, Mar 07, 2014 at 08:23:15AM -0500, Josh Boyer wrote:
 On Fri, Mar 7, 2014 at 2:16 AM, Sandro red Mathys
 r...@fedoraproject.org wrote:
  I think Josh is mostly there.  He has 58MB + 5M vmlinuz + similar?
  firmwre.
 
  Firmware is owned by linux-firmware, not the kernel package.  I didn't
  include it in my kernel numbers for that reason.
 
  He just has to cut 35MB or so from /lib/modules/.  We can probably nickel
  and dime and review a lot of cruft to get there, but what is that 35MB
  really doing to get us anything?  I am sure half of that can be removed by
  re-examining the minimal-list he sent (I can even help there).
 
  Right.  Considering the bloat elsewhere in the distro, I think we can
  start with what I have and work from there if needed.
 
  Excellent progress there. So 35MB are already gone and I figure
  (re)moving graphics, sound and other obvious things will gain us quite
  some more MB. Nice job.
 
 No.  62MB are already gone.  The 35MB was what is needed
 additionally to get to comparable numbers with ubuntu.  Sound I could
 see dropping.  Graphics, not so much.
 
 Really, I'm likely to start with what I have and if there are major
 reasons that get brought up (with data) to trim further, we can look
 at it.

I agree too.  I think you did an awesome job Josh.  Most of the fat is
trimmed. :-)  Anything more should really come with some numbers/data.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [WIP] Create kernel-core and kernel-drivers subpackages

[Don Zickus]

On Mon, Mar 17, 2014 at 03:13:54PM -0400, Josh Boyer wrote:
 TODO:
 
 Right now this is what has been building in my COPR for the past week.
 It works well on x86_64 (which is all I've tested), and i686 builds but
 I know it's broken on ARM.  To finish it up, I need:
 
 1) Review from you all.

I took a stab at this.

Let's start with the dumb question first because I couldn't find the
obvious answer, why kernel-driver? and not just kernel and
kernel-modules-extras?  IOW what does kernel-core buy us except for spec
churn.  I am sure yum is invovled in that answer.

Second, the whole mv .. restore/ and back again dance made me cry.  Can we
just hack the scripts/Makefile.modinst file to pass a filter argument such
that the installs look like

#kernel core
make modules_install INSTALL_MOD_DIR=core INSTALL_MOD_FILTER=modules.list
#kernel module extras
make modules_install INSTALL_MOD_DIR=suppl INSTALL_MOD_FILTER_INV=modules.list

then you have two directories core/ and suppl/ that you can run depmod on
individually and for filelist purposes.  Then you can combine it later for
packaging purposes I think.  Something like that.  Heck you might be able
to run a depmod check on the filtered files and fail if a dependency isn't
copied over during install (or just do it automagically to keep
modules.list smaller).

Just a thought.

Most of this is just moving and renaming so that isn't too bad.  I didn't
focus on the small subtle changes on the %post stuff.

I keep telling myself I would love to rework the spec file to simplify
again by moving some of the junk into rpm properly.  The number of people
who can fully understand the spec file is becoming a dying breed. :-(

So all this churn doesn't make it any better.  Hence why I was looking for
kernel Makefile solutions or other rpm solutions to simplify the quirks.

 
 2) A per-arch filter list, because the existing one that works on
 x86_64 leaves modules in kernel-core on ARM that lack their
 dependencies.  Bad.

Much like the config files?

 
 3) Further testing on all arches.
 
 4) To make the depmod call fatal to the build.  Without making this
 fatal we run the risk of pushing kernel-core packages that aren't
 self-contained and that seems pretty bad to me.  It shouldn't be a huge
 issue as I would think most of the breakage is going to come from merge
 window stuff and settle down after that.

I was trying to envision a 'make depcheck' or something similar to a 'make
configs' that fails early as opposed to an hour after the build completes.
But everytime I dive to deep into the Makefile I get lost, try a quick
hack and make things worse (I still dream of a 'make kabi' like command
for rhel reasons...).

Cheers,
Don

 
 josh
 
 diff --git a/kernel.spec b/kernel.spec
 index e055bb2..4ffa1b6 100644
 --- a/kernel.spec
 +++ b/kernel.spec
 @@ -34,7 +34,7 @@ Summary: The Linux kernel
  # For non-released -rc kernels, this will be appended after the rcX and
  # gitX tags, so a 3 here would become part of release 0.rcX.gitX.3
  #
 -%global baserelease 1
 +%global baserelease 8
  %global fedora_build %{baserelease}
  
  # base_sublevel is the kernel version we're starting with and patching
 @@ -385,29 +385,6 @@ Summary: The Linux kernel
  %define kernel_prereq  fileutils, systemd = 203-2
  %define initrd_prereq  dracut = 027
  
 -#
 -# This macro does requires, provides, conflicts, obsoletes for a kernel 
 package.
 -#%%kernel_reqprovconf subpackage
 -# It uses any kernel_subpackage_conflicts and kernel_subpackage_obsoletes
 -# macros defined above.
 -#
 -%define kernel_reqprovconf \
 -Provides: kernel = %{rpmversion}-%{pkg_release}\
 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{pkg_release}%{?1:+%{1}}\
 -Provides: kernel-drm-nouveau = 16\
 -Provides: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
 -Requires(pre): %{kernel_prereq}\
 -Requires(pre): %{initrd_prereq}\
 -Requires(pre): linux-firmware = 20130724-29.git31f6b30\
 -Requires(preun): systemd = 200\
 -%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: 
 %%{kernel%{?1:_%{1}}_conflicts}}}\
 -%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: 
 %%{kernel%{?1:_%{1}}_obsoletes}}}\
 -%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: 
 %%{kernel%{?1:_%{1}}_provides}}}\
 -# We can't let RPM do the dependencies automatic because it'll then pick up\
 -# a correct but undesirable perl dependency from the module headers which\
 -# isn't required for the kernel proper to function\
 -AutoReqProv: no\
 -%{nil}
  
  Name: kernel%{?variant}
  Group: System Environment/Kernel
 @@ -419,8 +396,9 @@ Release: %{pkg_release}
  # SET %%nobuildarches (ABOVE) INSTEAD
  ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ppc64p7 s390 s390x %{arm} 
 aarch64 ppc64le
  ExclusiveOS: Linux
 +Requires: kernel-%{?variant:%{variant}-}core-uname-r = %{KVERREL}%{?variant}
 +Requires: kernel-%{?variant:%{variant}-}drivers-uname-r = 
 %{KVERREL}%{?variant}
  
 -%kernel_reqprovconf
  
  #
  # List the packages used during the kernel build
 @@ 

Re: [WIP] Create kernel-core and kernel-drivers subpackages

[Don Zickus]

On Thu, Mar 20, 2014 at 02:51:13PM -0400, Josh Boyer wrote:
 On Thu, Mar 20, 2014 at 02:13:20PM -0400, Don Zickus wrote:
  On Mon, Mar 17, 2014 at 03:13:54PM -0400, Josh Boyer wrote:
   TODO:
   
   Right now this is what has been building in my COPR for the past week.
   It works well on x86_64 (which is all I've tested), and i686 builds but
   I know it's broken on ARM.  To finish it up, I need:
   
   1) Review from you all.
  
  I took a stab at this.
 
 Thanks!
 
 
  Let's start with the dumb question first because I couldn't find the
  obvious answer, why kernel-driver? and not just kernel and
  kernel-modules-extras?  IOW what does kernel-core buy us except for spec
  churn.  I am sure yum is invovled in that answer.
 
 kernel - metapackage the requires the equivalent of what kernel is
 today.
 kernel-core - the tiny thing Cloud wants.  vmlinux + a small set of
 drivers
 kernel-drivers - the other half of what kernel is today
 kernel-modules-extra - modules that really aren't needed anywhere by
 default and I wish we could just turn off entirely.
 
 So kernel-modules-extra already exists today and repurposing it to be
 the equivalent of kernel-drivers could happen I guess.  However, just
 having kernel be the tiny thing is probably broken from a conceptual
 standpoint because just installing kernel isn't enough to fully boot on
 most bare-metal machines.  If we made it so, then it would probably be
 large enough to just not bother with this at all.  Hence kernel-core.

Right, I guess I don't understand how kernel-drivers magically
installs/not installs.  I had assumed some of this was hardcoded in some
install file anaconda reads.  So my initial assumption was kernel and
kernel-drivers would auto install on a normal desktop.  I didn't think far
enough to understand how an update would work..

So in this case, I suppose cloud only installs kernel-core whereas desktop
installs kernel (which installs both -core and -driver)?

 
  Second, the whole mv .. restore/ and back again dance made me cry.  Can we
  just hack the scripts/Makefile.modinst file to pass a filter argument such
  that the installs look like
  
  #kernel core
  make modules_install INSTALL_MOD_DIR=core INSTALL_MOD_FILTER=modules.list
  #kernel module extras
  make modules_install INSTALL_MOD_DIR=suppl 
  INSTALL_MOD_FILTER_INV=modules.list
  
  then you have two directories core/ and suppl/ that you can run depmod on
  individually and for filelist purposes.  Then you can combine it later for
  packaging purposes I think.  Something like that.  Heck you might be able
  to run a depmod check on the filtered files and fail if a dependency isn't
  copied over during install (or just do it automagically to keep
  modules.list smaller).
 
 Er... no?  I mean, we could install to core and suppl directories if we
 had modules.list.  But if we had modules.list already then we wouldn't
 need to generate the %files list, which is what this hunk is doing.
 
 Essentially this is avoiding hardcoded, one line per .ko lists by going
 through and removing entire directories of things and saving off the
 list as the contents of kernel-core and kernel-drivers.  Then we fix it
 up since we actually want kernel-drivers to install to
 /lib/modules/`uname -r`/kernel/ also.
 
 It's probably clearer if you have filter-modules.sh to look at.  I've
 attached it below.  Apologies for not including it to begin with.

Ah, yes, now things are clearer.  I had assumed you were listing
everything one by one (sorta akin to what is done with the config
options).

I could argue you would have better control if you mimic'd the config
options and created a modules.list.  But I am not maintaining this, so I
won't. :-)

 
  Most of this is just moving and renaming so that isn't too bad.  I didn't
  focus on the small subtle changes on the %post stuff.
 
 Yeah, that's fairly trivial.
 
  I keep telling myself I would love to rework the spec file to simplify
  again by moving some of the junk into rpm properly.  The number of people
  who can fully understand the spec file is becoming a dying breed. :-(
  
  So all this churn doesn't make it any better.  Hence why I was looking for
  kernel Makefile solutions or other rpm solutions to simplify the quirks.
 
 Except the complexities don't come from the kernel makefiles.  They come
 from RPM :\.  It needs a file with a list of files to include for the
 %files -f directive of both kernel-core and kernel-drivers to work.  If
 we don't use %files -f, we're stuck listing out individual directories
 and .ko files in the %files section for each.  That would be a nightmare
 to maintain, so I've automated it with %files -f.

I wasn't referring to the %files stuff.  More like all the shell scripting
prep work for restore/ and friends.  Just trying to think of ways to
simplify things.

 
 Some of this could be avoided (not a whole lot) if we invented
 /lib/modules/`uname -r`/suppl and installed the kernel-drivers content

Re: [WIP] Create kernel-core and kernel-drivers subpackages

[Don Zickus]

On Thu, Mar 20, 2014 at 03:47:19PM -0400, Josh Boyer wrote:
 I believe anaconda does install kernel today.  So since the kernel
 metapackage Requires:kernel-drivers, it will bring that in
 automatically.  Updates from existing installs would pick up kernel,
 kernel-core, and kernel-drivers based on the Requires: present.
 
 It looks like 3 packages instead of one, but the overall installed size
 is literally the same as the existing kernel package today.  It's a
 split to keep things working, while allowing new approaches at the same
 time.
 
  So in this case, I suppose cloud only installs kernel-core whereas desktop
  installs kernel (which installs both -core and -driver)?
 
 Yes, exactly.  That would be done via kickstart (and is extendable to
 anyone that wants to avoid kernel-drivers but Cloud is the main user.)


Thanks!

 
Second, the whole mv .. restore/ and back again dance made me cry.  Can 
we
just hack the scripts/Makefile.modinst file to pass a filter argument 
such
that the installs look like

#kernel core
make modules_install INSTALL_MOD_DIR=core 
INSTALL_MOD_FILTER=modules.list
#kernel module extras
make modules_install INSTALL_MOD_DIR=suppl 
INSTALL_MOD_FILTER_INV=modules.list

then you have two directories core/ and suppl/ that you can run depmod 
on
individually and for filelist purposes.  Then you can combine it later 
for
packaging purposes I think.  Something like that.  Heck you might be 
able
to run a depmod check on the filtered files and fail if a dependency 
isn't
copied over during install (or just do it automagically to keep
modules.list smaller).
   
   Er... no?  I mean, we could install to core and suppl directories if we
   had modules.list.  But if we had modules.list already then we wouldn't
   need to generate the %files list, which is what this hunk is doing.
   
   Essentially this is avoiding hardcoded, one line per .ko lists by going
   through and removing entire directories of things and saving off the
   list as the contents of kernel-core and kernel-drivers.  Then we fix it
   up since we actually want kernel-drivers to install to
   /lib/modules/`uname -r`/kernel/ also.
   
   It's probably clearer if you have filter-modules.sh to look at.  I've
   attached it below.  Apologies for not including it to begin with.
  
  Ah, yes, now things are clearer.  I had assumed you were listing
  everything one by one (sorta akin to what is done with the config
  options).
  
  I could argue you would have better control if you mimic'd the config
  options and created a modules.list.  But I am not maintaining this, so I
  won't. :-)
 
 I might be able to generate a list of modules (.ko files) based on the
 config settings.  That would basically be the equivalent of the first
 find we do in the spec file change.  Not sure it would simplify anything
 else, but I'll think about it a bit and see if there's further
 optimizations to be done.

It was just a different point of view.  Not saying it is any better.  Just
thought it might simplify the spec file changes and control the
kernel-core bloat over a number of releases.

The thought was if you the average desktop user was install kenrel-core
and kernel-driver, then it doesn't matter where the .kos are because in
the end, all the .kos end up on the machine.  So the kernel-core
module.list would really be for cloud.  And someone could keep trimming
that list until the cloud folks had something super small that made them
excited.  If the list was too small it didn't impact the desktop folks
(not that your approach causes any negative impact either).

Again it was just solving a problem from a different perspective.  If you
are happy with your approach continue with it.  I'll have to see how it
works in RHEL in a couple of years. :-)

 
Most of this is just moving and renaming so that isn't too bad.  I 
didn't
focus on the small subtle changes on the %post stuff.
   
   Yeah, that's fairly trivial.
   
I keep telling myself I would love to rework the spec file to simplify
again by moving some of the junk into rpm properly.  The number of 
people
who can fully understand the spec file is becoming a dying breed. :-(

So all this churn doesn't make it any better.  Hence why I was looking 
for
kernel Makefile solutions or other rpm solutions to simplify the quirks.
   
   Except the complexities don't come from the kernel makefiles.  They come
   from RPM :\.  It needs a file with a list of files to include for the
   %files -f directive of both kernel-core and kernel-drivers to work.  If
   we don't use %files -f, we're stuck listing out individual directories
   and .ko files in the %files section for each.  That would be a nightmare
   to maintain, so I've automated it with %files -f.
  
  I wasn't referring to the %files stuff.  More like all the shell scripting
  prep work for restore/ and 

Re: [PATCH] perf: install trace-event plugins

[Don Zickus]

On Mon, Jun 02, 2014 at 03:11:01PM -0400, Kyle McMartin wrote:
 perf hardcodes $libdir to be lib for all but x86_64, so kludge around it
 until upstream gets their act together.

Did you post this upstream too?

Cheers,
Don

 
 --kyle
 
 diff --git a/kernel.spec b/kernel.spec
 index fbfa738..bee43f2 100644
 --- a/kernel.spec
 +++ b/kernel.spec
 @@ -641,6 +641,8 @@ Patch25071: 
 s390-appldata-add-slab.h-for-kzalloc-kfree.patch
  # CVE-2014-3917 rhbz 1102571 1102715
  Patch25093: auditsc-audit_krule-mask-accesses-need-bounds-checking.patch
  
 +Patch26000: perf-lib64.patch
 +
  # END OF PATCH DEFINITIONS
  
  %endif
 @@ -723,7 +725,7 @@ This package provides debug information for the perf 
 package.
  # symlinks because of the trailing nonmatching alternation and
  # the leading .*, because of find-debuginfo.sh's buggy handling
  # of matching the pattern against the symlinks file.
 -%{expand:%%global debuginfo_args %{?debuginfo_args} -p 
 '.*%%{_bindir}/perf(\.debug)?|.*%%{_libexecdir}/perf-core/.*|XXX' -o 
 perf-debuginfo.list}
 +%{expand:%%global debuginfo_args %{?debuginfo_args} -p 
 '.*%%{_bindir}/perf(\.debug)?|.*%%{_libexecdir}/perf-core/.*|.*%%{_libdir}/traceevent/plugins/.*|XXX'
  -o perf-debuginfo.list}
  
  %package -n python-perf
  Summary: Python bindings for apps which will manipulate perf events
 @@ -1358,6 +1360,8 @@ ApplyPatch 
 s390-appldata-add-slab.h-for-kzalloc-kfree.patch
  # CVE-2014-3917 rhbz 1102571 1102715
  ApplyPatch auditsc-audit_krule-mask-accesses-need-bounds-checking.patch
  
 +ApplyPatch perf-lib64.patch
 +
  # END OF PATCH APPLICATIONS
  
  %endif
 @@ -1893,7 +1897,7 @@ find $RPM_BUILD_ROOT/usr/include \
  
  %if %{with_perf}
  # perf tool binary and supporting scripts/binaries
 -%{perf_make} DESTDIR=$RPM_BUILD_ROOT install-bin
 +%{perf_make} DESTDIR=$RPM_BUILD_ROOT MULTILIBDIR=%{_lib} install-bin 
 install-traceevent-plugins
  # remove the 'trace' symlink.
  rm -f %{buildroot}%{_bindir}/trace
  
 @@ -2092,6 +2096,8 @@ fi
  %files -n perf
  %defattr(-,root,root)
  %{_bindir}/perf
 +%dir %{_libdir}/traceevent/plugins
 +%{_libdir}/traceevent/plugins/*
  %dir %{_libexecdir}/perf-core
  %{_libexecdir}/perf-core/*
  %{_mandir}/man[1-8]/perf*
 diff --git a/perf-lib64.patch b/perf-lib64.patch
 new file mode 100644
 index 000..3e3a33e
 --- /dev/null
 +++ b/perf-lib64.patch
 @@ -0,0 +1,17 @@
 +diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
 +index 802cf54..7f30bfa 100644
 +--- a/tools/perf/config/Makefile
  b/tools/perf/config/Makefile
 +@@ -621,8 +621,12 @@ endif
 + ifeq ($(IS_X86_64),1)
 + lib = lib64
 + else
 ++ifdef MULTILIBDIR
 ++lib = $(MULTILIBDIR)
 ++else
 + lib = lib
 + endif
 ++endif
 + libdir = $(prefix)/$(lib)
 + 
 + # Shell quote (do not use $(call) to accommodate ancient setups);
 ___
 kernel mailing list
 kernel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/kernel
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Uhhuh - Dazed and confused, but trying to continue :)

[Don Zickus]

On Sun, Jan 18, 2015 at 11:50:38AM +0100, poma wrote:
 
 Salutem
 
 This happened only on thaw from S4 aka hibernate.
 What should be strange power saving mode these messages relate!?
 
 [  208.252986] Uhhuh. NMI received for unknown reason 3d on CPU 0.
 [  208.252991] Do you have a strange power saving mode enabled?
 [  208.252992] Dazed and confused, but trying to continue
 
 3.18.3-200.fc21.x86_64

This looks to be an external unknown NMI (unless you can reproduce on
something other than cpu0).

I would have to know what hardware you have and see the dmesg log after
the resume from hibernate.

You can open a bz and assign it to me.

Just attach the dmesg log, lspci and lspci -t output to the bz.

Though this is most likely a pci device firmware problem.  But I can try
to narrow it down.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH] kernel.spec: no more files in /boot

[Don Zickus]

On Wed, May 06, 2015 at 11:34:41AM +0200, Harald Hoyer wrote:
 Meh, not in CC and not subscribed to kernel-list. Anyway...
 
 On 04.05.2015 19:57, Tom Callaway wrote:
  On 05/04/2015 01:49 PM, Josh Boyer wrote:
 
  So if I understand the patch correctly, your usecase will still be
  valid as the actual files are still in /boot.  Nobody is expecting grub
  (or whatever other loaded) to read files out of /usr/.
 
  Moving files in %posttrans to a different location seems like one heck of
  a hack. What problem are we trying to solve here with a self-contained
  installation in /usr?
 
  ~tom
 
  == Red Hat
 
 
 heck of a hack??
 We do a lot more for the kernel in postrans:
 - depmod
 - create the initrd and move it to /boot
 - modify the bootloader conf (grubby)
 
 I don't see why additionally copying some files make it a heck of a hack?
 
 With self-contained installation in /usr we want to minimize the location
 of distributed files, so we can have:
 - stateless systems with a shared /usr gold master
 - easy distribution of vendor supplied OS parts
 - factory reset

Hi,

Not that my opinion matters much, but I think this is an interesting
mind shift.  The end result is the same as today, just extra files in
/lib/modules/`uname -r`, right?

This is one of those ideas, I am curious to see how it plays out.  It can
turn into nothing or allow us to do more interesting things from a package
maintaince or sysadmin perspective.

The only problem is how does one go about implementing ideas like this,
aside from creating their own distro?

If all we are doing is adding new files to /lib/modules, then it is low
risk, I would think.  But I would probably keep this in rawhide somehow (if
at all possible).

Then again I like some of the ideas of the stateless model as it makes
updating machines (servers big and small) easier.  I almost think Docker
but with distros instead of apps.

Just my 2cents.

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH] kernel.spec: no more files in /boot

[Don Zickus]

On Thu, May 07, 2015 at 04:29:11PM -0500, Ian Pilcher wrote:
 On 05/06/2015 02:00 PM, Josh Boyer wrote:
 On Wed, May 6, 2015 at 2:53 PM, Jarod Wilson ja...@redhat.com wrote:
 One other thought: what happens when /boot is on the same file system as
 /usr and/or /lib? Does the file get unnecessarily copied, or is it
 hardlinked or _?
 
 Copied as far as I know.  Yes it's slightly inefficient, but worrying
 about that case (which isn't default at all) seems kind of pointless.
 
 Hmm.  If don't know off the top of my head if Fedora cloud images have a
 separate /boot or not, but disk space is a big concern in such
 environments.

You could also argue simplifying package maintenance and sysadmin stuff is a
big concern for throw away cloud images. ;-)  With a change like this you
could almost throw away /boot and regenerate it on the fly. :-)

As I stated in another thread, it is hard to know what interesting things
you could do with this approach if you don't play around with it. 

Maybe if you detect /boot is on the same partition as /usr you go completely
nuts and symlink the kernel images to the /usr/lib/modules ones (or maybe
just /lib if /lib/modules hasn't moved to /usr/lib/modules yet).

Cheers,
Don
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: [PATCH] kernel.spec: no more files in /boot

[Don Zickus]

On Wed, May 06, 2015 at 10:41:28AM -0400, Josh Boyer wrote:
  Not that my opinion matters much, but I think this is an interesting
  mind shift.  The end result is the same as today, just extra files in
  /lib/modules/`uname -r`, right?
 
 Actually, I was hoping some other kernel maintainers would chip in so
 your opinion does matter.  I really don't want to change this in Fedora
 to only have it reverted in a future RHEL.  Maybe Jarod or Rafael would
 be kind enough to review as well...

Off the top of my head, if it works out for Fedora, I currently can't see a
reason RHEL would revert it.  But that depends on what quirks falls out. :-)

 
 And yes, your summary is correct.

Thanks!

Cheers,
Don

 
  This is one of those ideas, I am curious to see how it plays out.  It can
  turn into nothing or allow us to do more interesting things from a package
  maintaince or sysadmin perspective.
  
  The only problem is how does one go about implementing ideas like this,
  aside from creating their own distro?
 
  If all we are doing is adding new files to /lib/modules, then it is low
  risk, I would think.  But I would probably keep this in rawhide somehow (if
  at all possible).
 
 If we apply it, it would start in rawhide and work its way through the
 normal Fedora release process.  So at this point the earliest release it
 would land in would be Fedora 23.  The backwards compatibility Harald
 noted was for ease of use in testing rawhide kernels on older userspace.
 
  Then again I like some of the ideas of the stateless model as it makes
  updating machines (servers big and small) easier.  I almost think Docker
  but with distros instead of apps.
  
  Just my 2cents.
 
 Thanks.
 
 josh
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Fedora kernel git tree and package maintenance

[Don Zickus]

On Thu, Jul 09, 2015 at 07:42:08AM -0400, Josh Boyer wrote:
 On Thu, Jun 25, 2015 at 12:02 PM, Josh Boyer jwbo...@fedoraproject.org 
 wrote:
  Will the exploded tree go away if we don't change to this model?  Also
  unclear.  I'd hesitantly say it would stick around, but it might
  change in the way it is created and published.
 
  I'm sure there will be more questions, so please ask away.  Looking
  forward to hearing other's thoughts.
 
  So.  Given that it has been a week and we've heard nothing back, I'm
  going to assume that either nobody cares how we maintain our tree
  (which tbh is a fair point of view), or all of this sounds great to
  everyone.
 
  So here is our plan going forward.  We need a place to try this out to
  make sure it is actually a net positive for us.  We intend to drive
  the master branch in pkg-git (rawhide) using the tree and scripts for
  the 4.2 merge window.  What that means for other people is basically
  this:
 
 The team and I were discussing this topic yesterday, and it really
 isn't working as we'd hoped.  The exploded tree is great for rebasing
 patches.  It's trivial and integrated into the workflow just fine.
 However, taking that source code and producing an RPM is pretty
 cumbersome now.  The scripts work, but they can be fragile in certain
 places.  It's also still double commits in the long run, one in
 pkg-git and another in the exploded tree for all the junk that is
 needed for tracking and updating pkg-git.  Over time, a 'git rebase'
 call will take forever as those commits pile up because they're never
 going upstream.  Thorsten and Peter also pointed out that changes
 sneak into pkg-git and only are mentioned in the RPM changelog, not
 as separate commits.

Hi Josh,

Thanks for the effort!  Sad to hear it isn't working out, but I understand
your reasons.

While it is still fresh in your mind, can I ask a few questions for
curiousity.

Not that submodules is a good solution (from what I hear) but would a
solution like that (if made easier) work for those fedora scripts?  The idea
would be a rebase and a single commit on top to add the submodule-like
directory/area that pulls in a separate tree full of those changes?

This would sidestep the rebase growing larger over time, sort of
(one initial commit, but a growing set of commits brought in later??).

It might address the 'sneaky' changes problem too.

The only thing it doesn't handle is the extra Fedora kernel patches
themselves that is carried (but I think you have that minimized and under
control anyway).

I don't expect you to hold your breathe for that solution to arise, but if
it did, would it help do you think?

Cheers,
Don

 
 So going from exploded tree - kernel.spec just isn't paying off.  In
 the spirit of fail fast, we're probably going to scrap this experiment
 in the next few days.  However, we still want the exploded tree
 available so we're going to look at making it easier to go from
 kernel.spec - exploded tree.  Primarily, we are likely going to
 change how we apply patches in the spec file to use git-am.  What does
 this mean for contributors?
 
 a) Your patch _must_ conform to something git-am accepts.  Ironically,
 git-show does not produce such a patch so if you are using a git tree
 to create a patch, use git format-patch.  Plain diff won't work
 either.  It needs a From: a Date: and a Subject: at a minimum.
 
 b) The spec will undergo some surgery and you will no longer need to
 specify an ApplyPatch line.  This means the order of patch
 applications is determined by the order they are listed in the
 PatchXXX section.  Do not change this order randomly.
 
 c) 'fedpkg prep' time on a fresh tree will take a bit longer.
 Subsequent 'fedpkg prep' runs will be faster, but still a bit slower
 than today's method.  Creating the initial git tree is somewhat time
 consuming.  Still, we're talking on the order of just over a minute
 for a fresh tree, and about 40 seconds for subsequent runs.  This is
 not world ending.
 
 This will be tried in rawhide to start.  Aside from the above changes,
 the workflow will go back to what we had for years.  I'll look at
 creating the exploded tree on the side and it shouldn't impact anyone
 aside from the above requirements.
 
 josh
 ___
 kernel mailing list
 kernel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/kernel
___
kernel mailing list
kernel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel

Re: Fedora kernel git tree and package maintenance

[Don Zickus]

On Thu, Jul 09, 2015 at 11:17:29AM -0400, Josh Boyer wrote:
 On Thu, Jul 9, 2015 at 10:17 AM, Don Zickus dzic...@redhat.com wrote:
  On Thu, Jul 09, 2015 at 07:42:08AM -0400, Josh Boyer wrote:
  On Thu, Jun 25, 2015 at 12:02 PM, Josh Boyer jwbo...@fedoraproject.org 
  wrote:
   Will the exploded tree go away if we don't change to this model?  Also
   unclear.  I'd hesitantly say it would stick around, but it might
   change in the way it is created and published.
  
   I'm sure there will be more questions, so please ask away.  Looking
   forward to hearing other's thoughts.
  
   So.  Given that it has been a week and we've heard nothing back, I'm
   going to assume that either nobody cares how we maintain our tree
   (which tbh is a fair point of view), or all of this sounds great to
   everyone.
  
   So here is our plan going forward.  We need a place to try this out to
   make sure it is actually a net positive for us.  We intend to drive
   the master branch in pkg-git (rawhide) using the tree and scripts for
   the 4.2 merge window.  What that means for other people is basically
   this:
 
  The team and I were discussing this topic yesterday, and it really
  isn't working as we'd hoped.  The exploded tree is great for rebasing
  patches.  It's trivial and integrated into the workflow just fine.
  However, taking that source code and producing an RPM is pretty
  cumbersome now.  The scripts work, but they can be fragile in certain
  places.  It's also still double commits in the long run, one in
  pkg-git and another in the exploded tree for all the junk that is
  needed for tracking and updating pkg-git.  Over time, a 'git rebase'
  call will take forever as those commits pile up because they're never
  going upstream.  Thorsten and Peter also pointed out that changes
  sneak into pkg-git and only are mentioned in the RPM changelog, not
  as separate commits.
 
  Hi Josh,
 
  Thanks for the effort!  Sad to hear it isn't working out, but I understand
  your reasons.
 
  While it is still fresh in your mind, can I ask a few questions for
  curiousity.
 
  Not that submodules is a good solution (from what I hear) but would a
  solution like that (if made easier) work for those fedora scripts?  The idea
  would be a rebase and a single commit on top to add the submodule-like
  directory/area that pulls in a separate tree full of those changes?
 
  This would sidestep the rebase growing larger over time, sort of
  (one initial commit, but a growing set of commits brought in later??).
 
 I thought about this when I originally started, but avoided it for a
 few different reasons.  The main one was my unfamiliarity with
 submodules.  Another was now you're going from 2 trees to manage
 (pkg-git, linux.git) to 3 (pkg-git, linux.git, submodule).  It would
 help the rebase issue, but that is about all it would help.

Ok.

 
  It might address the 'sneaky' changes problem too.
 
 I'm not sure about that one.  The issue there stems from multiple
 things happening in linux.git, and then when we sync to pkg-git it all
 just gets sucked into one large commit.  Unless you held to a strict
 1:1 linux.git - pkg-git rule, you're always going to face that
 problem.  And if you go to 1:1, you aren't really treating linux.git
 as the canonical source at that point.  It is just an exploded tree
 mirror essentially.
 
 In some scenarios, this isn't a big deal.  Some distros don't expose
 their package SCM and their users/customers are used to the SRPM as
 being the canonical source, with %changelog being the equivalent of
 the SCM commit logs.  However, since the Core+Extras merge Fedora has
 always used the package SCM as the transparent location to see what
 changed and why.  Deviating from that, while it makes things easier
 for my team, is somewhat against Fedora's transparency.
 
 (It's also the reason why I bothered to spit out separate patches and
 tarballs.  The easiest solution is to just suck up the output of
 git-archive of the linux.git tree and use that as a tarball and build
 it, but not having patches would probably cause people to lose their
 minds in the Fedora world.)

Sure.  We had a 'create-patches.sh' script that did the 1:1 thing based on
an initial tarball in RHEL that worked well for years.  Just throwing it out
there.

 
  The only thing it doesn't handle is the extra Fedora kernel patches
  themselves that is carried (but I think you have that minimized and under
  control anyway).
 
  I don't expect you to hold your breathe for that solution to arise, but if
  it did, would it help do you think?
 
 I think the only thing that would really make working from an exploded
 tree viable is if koji could be pointed at it directly.  Even then,
 the mechanics of source - spec - srpm - rpm(s) isn't
 straightforward.

We do this in RHEL, not sure if koji was passed that technology or not but
we have already solved this years ago.

Again, I am not trying to persuade you to try your mind, just trying

Re: Kernel configurations for Fedora

[Don Zickus]

On Tue, Oct 25, 2016 at 10:46:00AM -0700, Laura Abbott wrote:
> The Fedora kernel has had roughly the same system for generating
> the kernel configuration for a very long time. There are a series
> of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
> is not set etc.) that get combined to generate the final config
> files. This has gotten unsustainable for several reasons:
> 
> - When the system was first introduced, the only supported
> arches were x86_32 and x86_64. Fedora now supports enough
> other arches that we have a config-$arch-generic in addition to
> config-generic
> - It's difficult to tell what is actually enabled since
> there are several layers of configuration combining (I have to
> look at config-generic, then config-$arch-generic, then
> the final config-$specific file to see what the option actually
> is)
> - Keeping the files organized requires manual work and pruning
> 
> I've been thinking about alternatives to the existing config
> generation. One proposal was to take advantage of the upstream
> kernel now supporting config fragments and keep some part of
> the fedora configuration upstream. This would have the disadvantage
> of requiring the configuration to be kept in sync with upstream.
> 
> Another option is to switch to a system of generation where
> each configuration option is kept in a separate file. There
> is no sorting or organization necessary. This would result
> in a lot of small files for all the arches Fedora supports though.

Hi Laura,

Just to throw it out there,  RHEL has been using the one option per file
mechanism for years now with success.  Minimizes the maintenance and
conflicts.  ( I know you already know that, just wanted to publicly state
that).

The volume of files is large, but it is hidden away and you only package the
resulting kernel.config files into the src.rpm.

Just a thought.

Cheers,
Don

> 
> Anyone have experiences with or opinions about the kernel
> configuration generation? The goal is to only change the way
> the configurations are generated and not the options that are
> enabled.
> 
> Thanks,
> Laura
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Don Zickus]

On Thu, Dec 01, 2016 at 07:53:06AM -0600, Justin Forbes wrote:
> On Wed, Nov 30, 2016 at 8:03 PM, Don Zickus <dzic...@redhat.com> wrote:
> 
> > On Wed, Nov 30, 2016 at 04:25:30PM -0800, Laura Abbott wrote:
> > > >  I don't think it would be a bad idea to enable in rawhide and see how
> > it works out, from there it will trickle down as the stable releases get
> > rebased.  While turning it on in theory shouldn't create a problem. I
> > honestly don't get warm fuzzies making such a change without at least some
> > time testing in rawhide. We are just a week or two away from 4.9 final now,
> > so it isn't a huge delay.  The changes being proposed upstream are not even
> > in next yet, so it has some time to be shaken out before it would ever see
> > a stable release, though the feature would need to be enabled in rawhide
> > for testing as that happens.
> > > >
> > > > Justin
> > > >
> > > >
> > >
> > > I'm not opposed to turning it on but I'm a little bit wary
> > > of this causing unexpected problems for users. From
> > > experience, how likely is it that a module passes the version
> > > checks but something else has changed such that it no longer
> > > works? Even if we can't officially support 3rd party modules,
> > > I'd like to not make it too much worse within reason.
> >
> > Hi Laura,
> >
> > Thanks for the feedback!
> >
> > That can always be the case, static inlines for example.  But RHEL has been
> > relying on this since RHEL-5 with many 3rd party drivers.  Various fixes
> > have gone in to the genksyms tool to make this interface fairly reliable.
> >
> 
> RHEL relying on this without major issues is very different than Fedora
> relying on it.  Fedora 23 which will EOL this month released with a 4.2
> kernel and is currently using 4.8.10.

Hi Justin,

In that scenario, I would fully expect lots of symbols to break after each
major kernel version release.  As a result a driver would fail to load and
would need to be rebuilt.  No different than today.

I don't expect Fedora to change any process or policy here.  I was just
trying to point out that the MODVERSIONS technology works well (despite the
upstream thread which broke things when enabling EXPORT_SYMBOL in asm
files due to a bad binutil version).  :-)

Based on the upstream thread, it seems there is widespread frustration with
guaranteeing correct module load with different kernel versions.
MODVERSIONS is pretty good today, but folks want better.  Red Hat would like
to help promote better technology here as kabi is something of a value add
on RHEL.

It is easier to do that if we can sync up some of RHEL's process with Fedora
to aid in flushing out issues.  That is really my main motivation here.

We can then use RH's internal testing and tooling to help verify things.

I believe it should have zero impact on Fedora.  The upstream discussion is
now resolved for 4.9 if I understand things correctly.  But feel free to
wait until 4.9 is actually released to make sure MODVERSIONS is no longer
depending on BROKEN.



In case you want to understand the technology a little bit better.  Today in
Fedora, module loading is based on a version string check.  If the module's
version string matches the kernel's string, it will load.  No other sanity
check. So if a kernel is modified but the version string isn't updated, bad
things may happen.

MODVERSIONS takes a checksum of the _whole_ path of an EXPORT_SYMBOL and its
parameters, recursively diving through structs until it gets to the very
basic types of int, char, void, etc..  Sometimes 100 levels deep.  This is
done by preprocessing the .c file into a .i fisrt. Once that extremely long
string is created, it is checksummed and stored in the .ko as the CRC.

Any out-of-tree module compiled has to go through the same steps and uses
the crc symbols from Modules.symvers as its dependency.

Upon module loading, if the CRCs don't match the module is blocked.  If they
do match, it implies the structs, the offsets, the variable names,
everything has not changed for that EXPORT_SYMBOL (ignoring code use of
those struct elements).  That is a pretty decent sanity check that the
driver should work on that kernel version.  Nothing is 100%, I get that, but
with our experience on RHEL (and all the hairy rebased subsystems we do), it
has worked pretty well.

If Fedora continues to promote DKMS and akmod, then no one has to worry
about this issue as those drivers will get stuck in extras/ and only be
available to that kernel.  :-)


Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH] config: Enable CONFIG_MODVERSIONS

[Don Zickus]

Hi,

I noticed that CONFIG_MODVERSIONS was not enabled in Fedora.  I do not know
the history and would be curious to know if someone knew.

Otherwise, I would like to propose enabling it.  Traditionally this option
helps 3rd party drivers update to newer kernel versions if the symbol
checksums match from the symbol list the driver needs in the kernel.

Fedora normally is not interested in 3rd party drivers.  I am not going to
ask Fedora to start being interested either. :-)

My reason for enabling this is really to help with RHEL technology.  RHEL
does support 3rd party drivers for business reasons.  Having better support
in Fedora for 3rd party drivers helps us iron out some of our technology
in this area.

As a bonus, it does help make sure existing Fedora 3rd party drivers don't
accidentally get loaded with the wrong kernel version.  This gets blocked at
load time and can help prevent various panics.  Though Fedora traditionally
closes such bugs anyway.

Signed-off-by: Don Zickus <dzic...@redhat.com>


diff --git a/config-generic b/config-generic
index 7444895..e0e9387 100644
--- a/config-generic
+++ b/config-generic
@@ -91,7 +91,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_MODULE_FORCE_LOAD is not set
 # -- MODULE_FORCE_UNLOAD is controlled by config-debug/nodebug
-# CONFIG_MODVERSIONS is not set
+CONFIG_MODVERSIONS=y
 # CONFIG_MODULE_SRCVERSION_ALL is not set
 
 CONFIG_PCI=y
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Don Zickus]

On Thu, Dec 01, 2016 at 08:49:24AM -0800, Laura Abbott wrote:
> On 12/01/2016 06:58 AM, Don Zickus wrote:
> > On Thu, Dec 01, 2016 at 07:53:06AM -0600, Justin Forbes wrote:
> >> On Wed, Nov 30, 2016 at 8:03 PM, Don Zickus <dzic...@redhat.com> wrote:
> >>
> >>> On Wed, Nov 30, 2016 at 04:25:30PM -0800, Laura Abbott wrote:
> >>>>>  I don't think it would be a bad idea to enable in rawhide and see how
> >>> it works out, from there it will trickle down as the stable releases get
> >>> rebased.  While turning it on in theory shouldn't create a problem. I
> >>> honestly don't get warm fuzzies making such a change without at least some
> >>> time testing in rawhide. We are just a week or two away from 4.9 final 
> >>> now,
> >>> so it isn't a huge delay.  The changes being proposed upstream are not 
> >>> even
> >>> in next yet, so it has some time to be shaken out before it would ever see
> >>> a stable release, though the feature would need to be enabled in rawhide
> >>> for testing as that happens.
> >>>>>
> >>>>> Justin
> >>>>>
> >>>>>
> >>>>
> >>>> I'm not opposed to turning it on but I'm a little bit wary
> >>>> of this causing unexpected problems for users. From
> >>>> experience, how likely is it that a module passes the version
> >>>> checks but something else has changed such that it no longer
> >>>> works? Even if we can't officially support 3rd party modules,
> >>>> I'd like to not make it too much worse within reason.
> >>>
> >>> Hi Laura,
> >>>
> >>> Thanks for the feedback!
> >>>
> >>> That can always be the case, static inlines for example.  But RHEL has 
> >>> been
> >>> relying on this since RHEL-5 with many 3rd party drivers.  Various fixes
> >>> have gone in to the genksyms tool to make this interface fairly reliable.
> >>>
> >>
> >> RHEL relying on this without major issues is very different than Fedora
> >> relying on it.  Fedora 23 which will EOL this month released with a 4.2
> >> kernel and is currently using 4.8.10.
> > 
> > Hi Justin,
> > 
> > In that scenario, I would fully expect lots of symbols to break after each
> > major kernel version release.  As a result a driver would fail to load and
> > would need to be rebuilt.  No different than today.
> > 
> > I don't expect Fedora to change any process or policy here.  I was just
> > trying to point out that the MODVERSIONS technology works well (despite the
> > upstream thread which broke things when enabling EXPORT_SYMBOL in asm
> > files due to a bad binutil version).  :-)
> > 
> > Based on the upstream thread, it seems there is widespread frustration with
> > guaranteeing correct module load with different kernel versions.
> > MODVERSIONS is pretty good today, but folks want better.  Red Hat would like
> > to help promote better technology here as kabi is something of a value add
> > on RHEL.
> > 
> > It is easier to do that if we can sync up some of RHEL's process with Fedora
> > to aid in flushing out issues.  That is really my main motivation here.
> > 
> > We can then use RH's internal testing and tooling to help verify things.
> > 
> > I believe it should have zero impact on Fedora.  The upstream discussion is
> > now resolved for 4.9 if I understand things correctly.  But feel free to
> > wait until 4.9 is actually released to make sure MODVERSIONS is no longer
> > depending on BROKEN.
> > 
> > 
> > 
> > In case you want to understand the technology a little bit better.  Today in
> > Fedora, module loading is based on a version string check.  If the module's
> > version string matches the kernel's string, it will load.  No other sanity
> > check. So if a kernel is modified but the version string isn't updated, bad
> > things may happen.
> > 
> > MODVERSIONS takes a checksum of the _whole_ path of an EXPORT_SYMBOL and its
> > parameters, recursively diving through structs until it gets to the very
> > basic types of int, char, void, etc..  Sometimes 100 levels deep.  This is
> > done by preprocessing the .c file into a .i fisrt. Once that extremely long
> > string is created, it is checksummed and stored in the .ko as the CRC.
> > 
> > Any out-of-tree module compiled has to go through the same steps and uses
> > the crc symbols from Modules.symvers a

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Don Zickus]

On Wed, Nov 30, 2016 at 04:25:30PM -0800, Laura Abbott wrote:
> >  I don't think it would be a bad idea to enable in rawhide and see how it 
> > works out, from there it will trickle down as the stable releases get 
> > rebased.  While turning it on in theory shouldn't create a problem. I 
> > honestly don't get warm fuzzies making such a change without at least some 
> > time testing in rawhide. We are just a week or two away from 4.9 final now, 
> > so it isn't a huge delay.  The changes being proposed upstream are not even 
> > in next yet, so it has some time to be shaken out before it would ever see 
> > a stable release, though the feature would need to be enabled in rawhide 
> > for testing as that happens.
> > 
> > Justin
> > 
> > 
> 
> I'm not opposed to turning it on but I'm a little bit wary
> of this causing unexpected problems for users. From
> experience, how likely is it that a module passes the version
> checks but something else has changed such that it no longer
> works? Even if we can't officially support 3rd party modules,
> I'd like to not make it too much worse within reason.

Hi Laura,

Thanks for the feedback!

That can always be the case, static inlines for example.  But RHEL has been
relying on this since RHEL-5 with many 3rd party drivers.  Various fixes
have gone in to the genksyms tool to make this interface fairly reliable.

Fedora doesn't need to support or promote it.  Just a service to try and see
if it adds value to someone.  I don't expect this change to make things
worse.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH] config: Enable CONFIG_MODVERSIONS

[Don Zickus]

On Wed, Nov 30, 2016 at 11:29:25PM +0100, Paul Bolle wrote:
> On Wed, 2016-11-30 at 17:15 -0500, Don Zickus wrote:
> > I noticed that CONFIG_MODVERSIONS was not enabled in Fedora.  I do not know
> > the history and would be curious to know if someone knew.
> > 
> > Otherwise, I would like to propose enabling it.
> 
> Shouldn't Fedora at least wait until the dust settles in
>     https://lkml.kernel.org/r/<20161123210256.31501-1-kilob...@angband.pl>
> 
> and related, and equally lively, threads?

Oh dear lord..  Thank you for pointing that thread to me.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv2] Switch to more standard debuginfo generation

[Don Zickus]

On Mon, Apr 10, 2017 at 06:22:06PM -0700, Laura Abbott wrote:
> Once upon a time, the kernel needed a lot of special handling to
> generate proper debuginfo as the kernel was ahead in technology. These
> days, rpm has improved debuginfo support. The kernel has not kept up
> with this and it's forward looking calls are now out of date. Switch to
> more standard invocations of debuginfo calls.
> ---
> This is a slightly reduced version of the previous patch. It keeps the 
> existing
> behavior by using the standard find-debuginfo.sh call with the proper 
> undefines.

Thanks Laura!  Sorry about the previous version.

Acked-by: Don Zickus <dzic...@redhat.com>


Mark W.,

Do you have much insight into how the below definitions would interact with
the kernel?

> @@ -395,7 +395,14 @@ BuildRequires: pciutils-devel gettext ncurses-devel
>  BuildConflicts: rhbuildsys(DiskFree) < 500Mb
>  %if %{with_debuginfo}
>  BuildRequires: rpm-build, elfutils
> -%define debuginfo_args --strict-build-id -r
> +# Most of these should be enabled after more investigation
> +%undefine _include_minidebuginfo
> +%undefine _find_debuginfo_dwz_opts
> +%undefine _unique_build_ids
> +%undefine _unique_debug_names
> +%undefine _unique_debug_srcs
> +%global _find_debuginfo_opts -r
> +%global _missing_build_ids_terminate_build 1
>  %endif

I am only poking you because it seems like you spent a lot of time cleaning
up some of the rpm macros in the rpm pkg.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv2] Switch to more standard debuginfo generation

[Don Zickus]

On Wed, Apr 12, 2017 at 12:55:34PM +0200, Mark Wielaard wrote:
> Hi,
> 
> On Tue, 2017-04-11 at 11:01 -0400, Don Zickus wrote:
> > Mark W.,
> > 
> > Do you have much insight into how the below definitions would interact with
> > the kernel?
> > 
> > > @@ -395,7 +395,14 @@ BuildRequires: pciutils-devel gettext ncurses-devel
> > >  BuildConflicts: rhbuildsys(DiskFree) < 500Mb
> > >  %if %{with_debuginfo}
> > >  BuildRequires: rpm-build, elfutils
> > > -%define debuginfo_args --strict-build-id -r
> 
> I am happy you seem able to use the defines instead of having to
> override the whole find-debuginfo call. Please let me know if there are
> other defines you need/want.

Hi Mark,

Thanks for responding.  Laura already provided some good feedback.
I was curious if some of this would correctly for our non-kernel package
stuff we build.  I might be reading Laura's patch wrong, but I think some of
the options applied to the kernel _and_ the userspace applications too.


Also, I was trying to understand Laura's previous patch with the -p changes.
It looked like the output of the application's debuginfo binaries did not
match with other programs.  I was curious if you had some thoughts on that
patch (it was split out of this one; you would have to see the original
patch to understand).

Cheers,
Don

> 
> > > +# Most of these should be enabled after more investigation
> > > +%undefine _include_minidebuginfo
> 
> This prevents adding a .gnu_debugdata section to the binaries which
> contains a minisymtab with just the function symbols/addresses. This is
> not really relevant for the kernel and modules. If added to
> binaries/shared libraries it allows some tools to show function names
> for more addresses even without having any debuginfo installed.
> 
> > > +%undefine _find_debuginfo_dwz_opts
> 
> This prevents running dwz (the DWARF compressor) which doesn't work for
> the kernel and kernel modules. The problem is that kernel modules are
> not normal ET_EXEC or ET_DYN, but look like ET_REL object files. object
> files contain relocations between ELF sections that dwz cannot handle.
> It would be nice to fix this because kernel modules are ideal for DWARF
> deduplication. They all contain the same basic debug type information
> that could be shared. eu-strip --reloc-debug-sections (-r, see below)
> could help with this, but hasn't been integrated. I'll try to make some
> time (no promises!) to look at it, because getting dwz working against
> the kernel modules would probably provide a huge saving.
> 
> > > +%undefine _unique_build_ids
> > > +%undefine _unique_debug_names
> > > +%undefine _unique_debug_srcs
> 
> It is somewhat unfortunate these don't work with the kernel build. The
> idea is that the package nvra is used to make all of the above unique
> between all versions of the package/debuginfo.
> 
> If I understand correctly we "uniqueify" too late assuming nothing
> depends on the build-id till we start handling the debuginfo. But the
> kernel builds seem to already pick out build-ids to store and embeds
> some ELF images in other ELF images and then those build-ids shouldn't
> be touched anymore. The AFTER_LINK hack was used to counter this, but it
> is somewhat fragile/doesn't really seem to interact correctly anymore.
> 
> If you don't have _unique_build_ids you should also set:
> %global _build_id_links alldebug
> to make sure build-ids are only used for the debuginfo packages
> (otherwise your main packages stops being parallel installable, which
> the kernel needs).
> 
> I think _unique_debug_names and _unique_debug_srcs should in theory
> still work. But they aren't very useful if the build-ids aren't unique.
> 
> > > +%global _find_debuginfo_opts -r
> 
> This was specifically designed for the kernel. It makes sure relocations
> between debug sections are removed in ET_REL files. Which normally would
> not be correct if those ET_REL object files would be linked together
> again. But kernel modules are not real/normal object files. It should
> save a couple of 100MBs when installing the debuginfo for the .ko files.
> (As said above we really should figure out a way to combine this with
> dwz processing so we can safe even more space.)
> 
> > > +%global _missing_build_ids_terminate_build 1
> 
> Yes please. It should show if any ELF file rpm processes doesn't have a
> build-id, which would be a bug in the toolchain.
> 
> > I am only poking you because it seems like you spent a lot of time cleaning
> > up some of the rpm macros in the rpm pkg.
> 
> Thanks. I am really interested in this. I did see one of the earlier
> patches, but missed that I had be

Re: [PATCH] Switch to more standard debuginfo generation

[Don Zickus]

On Tue, Apr 04, 2017 at 02:36:48PM -0700, Laura Abbott wrote:
> From: Laura Abbott 
> 
> Once upon a time, the kernel needed a lot of special handling to
> generate proper debuginfo as the kernel was ahead in technology. These
> days, rpm has improved debuginfo support. The kernel has not kept up
> with this and it's forward looking calls are now out of date. Switch to
> more standard invocations of debuginfo calls.
> ---
> Bringing this out from the previous thread. This drops the special invocations
> of find-debuginfo.sh and debugedit. The results seem to be reasonable as far
> as I can tell.


Looking at the /usr/lib/rpm/macros and the find_debuginfo stuff in
particular, those pieces of your patch makes sense to drop and replace with
the find_debuginfo_opts[1].

I am curious about the AFTER_LINK patch.  What is the reason to drop it?
The patch probably needs to be dropped as either stale or integrated
differently upstream, just thought it would be nice to have it documented.


Can I assume your testing was install the debuginfo package and have an
application like gdb or crash read in the symbols to verify the contents?


I think this patch is a good direction forward, just a little nitpick in
[1].

Cheers,
Don


[1] - Adding the VERSION and RELEASE stuff to find_debuginfo_opts must have
been painful.  It also makes it hard to read.  I was curious if a macro
would work there, where we pass a list of files and the macro spits out the
files with the VERSION, RELEASE, _arch, _debug junk appended to it?

This might make it easier to add to later and maintain?


> ---
>  kbuild-AFTER_LINK.patch | 126 
> 
>  kernel.spec |  40 +++
>  2 files changed, 6 insertions(+), 160 deletions(-)
>  delete mode 100644 kbuild-AFTER_LINK.patch
> 
> diff --git a/kbuild-AFTER_LINK.patch b/kbuild-AFTER_LINK.patch
> deleted file mode 100644
> index ab738c6..000
> --- a/kbuild-AFTER_LINK.patch
> +++ /dev/null
> @@ -1,126 +0,0 @@
> -From 649d991ca7737dd227f2a1ca4f30247daf6a7b4b Mon Sep 17 00:00:00 2001
> -From: Roland McGrath 
> -Date: Mon, 6 Oct 2008 23:03:03 -0700
> -Subject: [PATCH] kbuild: AFTER_LINK
> -
> -If the make variable AFTER_LINK is set, it is a command line to run
> -after each final link.  This includes vmlinux itself and vDSO images.
> -
> -Bugzilla: N/A
> -Upstream-status: ??
> -
> -Signed-off-by: Roland McGrath 
> 
> - arch/arm64/kernel/vdso/Makefile | 3 ++-
> - arch/powerpc/kernel/vdso32/Makefile | 3 ++-
> - arch/powerpc/kernel/vdso64/Makefile | 3 ++-
> - arch/s390/kernel/vdso32/Makefile| 3 ++-
> - arch/s390/kernel/vdso64/Makefile| 3 ++-
> - arch/x86/entry/vdso/Makefile| 5 +++--
> - scripts/link-vmlinux.sh | 4 
> - 7 files changed, 17 insertions(+), 7 deletions(-)
> -
> -diff --git a/arch/arm64/kernel/vdso/Makefile 
> b/arch/arm64/kernel/vdso/Makefile
> -index 62c84f7..f44236a 100644
>  a/arch/arm64/kernel/vdso/Makefile
> -+++ b/arch/arm64/kernel/vdso/Makefile
> -@@ -54,7 +54,8 @@ $(obj-vdso): %.o: %.S FORCE
> - 
> - # Actual build commands
> - quiet_cmd_vdsold = VDSOL   $@
> --  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
> -+  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@ \
> -+$(if $(AFTER_LINK),;$(AFTER_LINK))
> - quiet_cmd_vdsoas = VDSOA   $@
> -   cmd_vdsoas = $(CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/powerpc/kernel/vdso32/Makefile 
> b/arch/powerpc/kernel/vdso32/Makefile
> -index 78a7449..c9592c0 100644
>  a/arch/powerpc/kernel/vdso32/Makefile
> -+++ b/arch/powerpc/kernel/vdso32/Makefile
> -@@ -44,7 +44,8 @@ $(obj-vdso32): %.o: %.S FORCE
> - 
> - # actual build commands
> - quiet_cmd_vdso32ld = VDSO32L $@
> --  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^)
> -+  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^) \
> -+ $(if $(AFTER_LINK),; $(AFTER_LINK))
> - quiet_cmd_vdso32as = VDSO32A $@
> -   cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/powerpc/kernel/vdso64/Makefile 
> b/arch/powerpc/kernel/vdso64/Makefile
> -index 31107bf..96aded3 100644
>  a/arch/powerpc/kernel/vdso64/Makefile
> -+++ b/arch/powerpc/kernel/vdso64/Makefile
> -@@ -33,7 +33,8 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
> - 
> - # actual build commands
> - quiet_cmd_vdso64ld = VDSO64L $@
> --  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^)
> -+  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^) \
> -+$(if $(AFTER_LINK),; $(AFTER_LINK))
> - 
> - # install commands for the unstripped file
> - quiet_cmd_vdso_install = INSTALL $@
> -diff --git a/arch/s390/kernel/vdso32/Makefile 
> b/arch/s390/kernel/vdso32/Makefile
> -index 6cc9478..94fb536 100644
>  

Re: [PATCH] Switch to more standard debuginfo generation

[Don Zickus]

On Fri, Apr 07, 2017 at 11:16:05AM -0700, Laura Abbott wrote:
> >>
> >> It's really not pretty, I spent at least a full day figuring out the
> >> regexes because I had no idea how they work. I'm sorely tempted to
> >> put some ascii art warning of the horrors within. More macros might help
> >> things, I'll see what I can do. What I'd really like is a find-debuginfo.sh
> >> flag to add the buildid automatically for the filtering. This might turn
> >> into a feature request or a patch if I get around to it.
> > 
> > That was my fear, it was so painful that attempt at future changes, scares
> > folks off. :-(
> > 
> > So I just spent some time trying to explore your changes a little bit.  I
> > thought the VERSION and RELEASE stuff was for the kernel but in fact it
> > really is only for the tools (perf and kernel-tools).
> > 
> > Looking at current kernel-tools-debuginfo doesn't show any VERSION and
> > RELEASE stuff.  Your patch seems to add that.  I guess I am curious why?  If
> > you can only have one version of the tools installed at one time, what does
> > VERSION and RELEASE provide us?
> > 
> > My thinking is why don't all the other userspace applications need similar
> > naming?
> > 
> > Sorry for being picky, just trying to understand those particular changes.
> > 
> 
> Switching over to the default find-debuginfo.sh calls adds the unique
> build-ids and unique debug names for the kernel. This gets added for
> all files, even the userspace components. It seems like this is the
> direction find-debuginfo wants to go in so I figured it was worth the
> effort to move to it. I went by what needed the ids although maybe I should
> take a closer look.

Ok.  I am still trying to wrap my head around your answer.  I think my
confusion comes from looking at current debuginfo output and seeing
.build-id in there currently.

Using kernel version 4.10.8-100.fc24

#rpm -ql kernel-debuginfo |less
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/00
/usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a
/usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a.debug
/usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528
/usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528.debug


#rpm -ql kernel-tools-debuginfo|less
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/0e
/usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7
/usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7.debug
/usr/lib/debug/.build-id/17
/usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b
/usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b.debug



I see unique .build-id stuff already there.

Now comparing your scratch build with say glibc-debuginfo or rpm-debuginfo
info, I noticed your scratch build appends a VERSION-RELEASE to every binary
name, whereas the other packages do not.  On the flip side, the other two
packages do add a /usr/src/debug/-VERSION-RELEASE/...source files... ,
which the kernel-tools and perf does not.


So I was trying to investigate some of this stuff and noticed that Kyle went
down this road a couple of years ago, which Josh reverted the next day  in
006e9acec2708eb48b148b3f1ed3cb8e89107447.  This looks similar to your work.

It seemed to have broken on a 'fedpkg local' for some reason. :-( 

And then Mark did some magic symlink cleanup in the rpm macros last year,
which leads me to wonder, if we can just remove all that ugly '-p' stuff
entirely.

Of course, I was going to play around with this by short circuiting the
kernel build and only build kernel-tools and perf, but my laptop was
spitting out kernel config errors with 'make oldconfig' for some reason and
bypassing that lead to bizarre EXTRA_CFLAGS macro expansion problems with
perf.  So I failed there. :-(


But my initial thought was to see what happens in the binary images when all
that stuff is ripped out and see if /usr/src/debug magically reappears in
kernel-tools and perf.



At the same time, maybe it makes sense to split this patch in half.  Commit
the parts we agree on and then continue hacking on this part to include a
little later?

I could be completely missing something and my thoughts will fail miserably.
But at the same time Mark looks willing to help hack find-debuginfo.sh to
possible help the kernel?  Worth utilizing? :-)

Thoughts?

Cheers,
Don



> 
> Some of this comes back to the problem that the kernel repo doesn't
> just have the kernel, it has a bunch of other userspace tools that should
> really be a separate repo. As a result we have to keep a bunch of
> stuff in the kernel.spec and treat it as a homogeneous project.
> Nobody has put in the work to fight for moving stuff out of the kernel
> repo so alas we deal with what's there.
> 
> > The rest of the patch looks fine to me.
> > 
> 
> Thanks, I really appreciate getting a review on this.
> 
> > Cheers,
> > Don
> > 
> >>
> >> Thanks,
> >> Laura
> >> 

Re: [PATCH] Switch to more standard debuginfo generation

[Don Zickus]

On Thu, Apr 06, 2017 at 12:53:10PM -0700, Laura Abbott wrote:
> On 04/05/2017 07:52 AM, Don Zickus wrote:
> > On Tue, Apr 04, 2017 at 02:36:48PM -0700, Laura Abbott wrote:
> >> From: Laura Abbott <labb...@redhat.com>
> >>
> >> Once upon a time, the kernel needed a lot of special handling to
> >> generate proper debuginfo as the kernel was ahead in technology. These
> >> days, rpm has improved debuginfo support. The kernel has not kept up
> >> with this and it's forward looking calls are now out of date. Switch to
> >> more standard invocations of debuginfo calls.
> >> ---
> >> Bringing this out from the previous thread. This drops the special 
> >> invocations
> >> of find-debuginfo.sh and debugedit. The results seem to be reasonable as 
> >> far
> >> as I can tell.
> > 
> > 
> > Looking at the /usr/lib/rpm/macros and the find_debuginfo stuff in
> > particular, those pieces of your patch makes sense to drop and replace with
> > the find_debuginfo_opts[1].
> > 
> > I am curious about the AFTER_LINK patch.  What is the reason to drop it?
> > The patch probably needs to be dropped as either stale or integrated
> > differently upstream, just thought it would be nice to have it documented.
> > 
> 
> The purpose of AFTER_LINK was to run the debugedit command. If we're running
> the standard find-debuginfo.sh, it calls debugedit already so there should
> be no reason to need the command at all.

Ok, sounds good.  Thanks!

> 
> > 
> > Can I assume your testing was install the debuginfo package and have an
> > application like gdb or crash read in the symbols to verify the contents?
> > 
> 
> Yes, that's roughly what I did.
> 
> > 
> > I think this patch is a good direction forward, just a little nitpick in
> > [1].
> > 
> > Cheers,
> > Don
> > 
> > 
> > [1] - Adding the VERSION and RELEASE stuff to find_debuginfo_opts must have
> > been painful.  It also makes it hard to read.  I was curious if a macro
> > would work there, where we pass a list of files and the macro spits out the
> > files with the VERSION, RELEASE, _arch, _debug junk appended to it?
> > 
> > This might make it easier to add to later and maintain?
> > 
> > 
> 
> It's really not pretty, I spent at least a full day figuring out the
> regexes because I had no idea how they work. I'm sorely tempted to
> put some ascii art warning of the horrors within. More macros might help
> things, I'll see what I can do. What I'd really like is a find-debuginfo.sh
> flag to add the buildid automatically for the filtering. This might turn
> into a feature request or a patch if I get around to it.

That was my fear, it was so painful that attempt at future changes, scares
folks off. :-(

So I just spent some time trying to explore your changes a little bit.  I
thought the VERSION and RELEASE stuff was for the kernel but in fact it
really is only for the tools (perf and kernel-tools).

Looking at current kernel-tools-debuginfo doesn't show any VERSION and
RELEASE stuff.  Your patch seems to add that.  I guess I am curious why?  If
you can only have one version of the tools installed at one time, what does
VERSION and RELEASE provide us?

My thinking is why don't all the other userspace applications need similar
naming?

Sorry for being picky, just trying to understand those particular changes.

The rest of the patch looks fine to me.

Cheers,
Don

> 
> Thanks,
> Laura
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCHv3] Update debuginfo generation

[Don Zickus]

On Thu, May 04, 2017 at 04:38:25PM -0700, Laura Abbott wrote:
> 
> Once upon a time, the kernel needed a lot of special handling to
> generate proper debuginfo as the kernel was ahead in technology. These
> days, rpm has improved debuginfo support. The kernel has not kept up
> with this and it's forward looking calls are now out of date. Switch to
> more standard invocations of debuginfo calls.
> ---
> v3: Adds the new flag to never touch the buildids. I think I got the
> BuildConflicts tag correct?


Hi Laura,

Thanks for the work!  The patch seems reasonable to me.  I will let Mark
comment on it too.  Do you have a scratch build that I could look at?

Cheers,
Don

> ---
>  kbuild-AFTER_LINK.patch | 126 
> 
>  kernel.spec |  49 ---
>  2 files changed, 19 insertions(+), 156 deletions(-)
>  delete mode 100644 kbuild-AFTER_LINK.patch
> 
> diff --git a/kbuild-AFTER_LINK.patch b/kbuild-AFTER_LINK.patch
> deleted file mode 100644
> index ab738c62..
> --- a/kbuild-AFTER_LINK.patch
> +++ /dev/null
> @@ -1,126 +0,0 @@
> -From 649d991ca7737dd227f2a1ca4f30247daf6a7b4b Mon Sep 17 00:00:00 2001
> -From: Roland McGrath 
> -Date: Mon, 6 Oct 2008 23:03:03 -0700
> -Subject: [PATCH] kbuild: AFTER_LINK
> -
> -If the make variable AFTER_LINK is set, it is a command line to run
> -after each final link.  This includes vmlinux itself and vDSO images.
> -
> -Bugzilla: N/A
> -Upstream-status: ??
> -
> -Signed-off-by: Roland McGrath 
> 
> - arch/arm64/kernel/vdso/Makefile | 3 ++-
> - arch/powerpc/kernel/vdso32/Makefile | 3 ++-
> - arch/powerpc/kernel/vdso64/Makefile | 3 ++-
> - arch/s390/kernel/vdso32/Makefile| 3 ++-
> - arch/s390/kernel/vdso64/Makefile| 3 ++-
> - arch/x86/entry/vdso/Makefile| 5 +++--
> - scripts/link-vmlinux.sh | 4 
> - 7 files changed, 17 insertions(+), 7 deletions(-)
> -
> -diff --git a/arch/arm64/kernel/vdso/Makefile 
> b/arch/arm64/kernel/vdso/Makefile
> -index 62c84f7..f44236a 100644
>  a/arch/arm64/kernel/vdso/Makefile
> -+++ b/arch/arm64/kernel/vdso/Makefile
> -@@ -54,7 +54,8 @@ $(obj-vdso): %.o: %.S FORCE
> - 
> - # Actual build commands
> - quiet_cmd_vdsold = VDSOL   $@
> --  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
> -+  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@ \
> -+$(if $(AFTER_LINK),;$(AFTER_LINK))
> - quiet_cmd_vdsoas = VDSOA   $@
> -   cmd_vdsoas = $(CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/powerpc/kernel/vdso32/Makefile 
> b/arch/powerpc/kernel/vdso32/Makefile
> -index 78a7449..c9592c0 100644
>  a/arch/powerpc/kernel/vdso32/Makefile
> -+++ b/arch/powerpc/kernel/vdso32/Makefile
> -@@ -44,7 +44,8 @@ $(obj-vdso32): %.o: %.S FORCE
> - 
> - # actual build commands
> - quiet_cmd_vdso32ld = VDSO32L $@
> --  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^)
> -+  cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^) \
> -+ $(if $(AFTER_LINK),; $(AFTER_LINK))
> - quiet_cmd_vdso32as = VDSO32A $@
> -   cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/powerpc/kernel/vdso64/Makefile 
> b/arch/powerpc/kernel/vdso64/Makefile
> -index 31107bf..96aded3 100644
>  a/arch/powerpc/kernel/vdso64/Makefile
> -+++ b/arch/powerpc/kernel/vdso64/Makefile
> -@@ -33,7 +33,8 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
> - 
> - # actual build commands
> - quiet_cmd_vdso64ld = VDSO64L $@
> --  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^)
> -+  cmd_vdso64ld = $(CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) 
> $(filter %.o,$^) \
> -+$(if $(AFTER_LINK),; $(AFTER_LINK))
> - 
> - # install commands for the unstripped file
> - quiet_cmd_vdso_install = INSTALL $@
> -diff --git a/arch/s390/kernel/vdso32/Makefile 
> b/arch/s390/kernel/vdso32/Makefile
> -index 6cc9478..94fb536 100644
>  a/arch/s390/kernel/vdso32/Makefile
> -+++ b/arch/s390/kernel/vdso32/Makefile
> -@@ -46,7 +46,8 @@ $(obj-vdso32): %.o: %.S
> - 
> - # actual build commands
> - quiet_cmd_vdso32ld = VDSO32L $@
> --  cmd_vdso32ld = $(CC) $(c_flags) -Wl,-T $^ -o $@
> -+  cmd_vdso32ld = $(CC) $(c_flags) -Wl,-T $^ -o $@ \
> -+ $(if $(AFTER_LINK),; $(AFTER_LINK))
> - quiet_cmd_vdso32as = VDSO32A $@
> -   cmd_vdso32as = $(CC) $(a_flags) -c -o $@ $<
> - 
> -diff --git a/arch/s390/kernel/vdso64/Makefile 
> b/arch/s390/kernel/vdso64/Makefile
> -index 2d54c18..a0e3e9d 100644
>  a/arch/s390/kernel/vdso64/Makefile
> -+++ b/arch/s390/kernel/vdso64/Makefile
> -@@ -46,7 +46,8 @@ $(obj-vdso64): %.o: %.S
> - 
> - # actual build commands
> - quiet_cmd_vdso64ld = VDSO64L $@
> --  cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $^ -o $@
> -+  cmd_vdso64ld = $(CC) $(c_flags) -Wl,-T $^ -o $@ \
> -+ $(if 

Re: RFC: Moving kernel-tools out of kernel.spec

[Don Zickus]

On Tue, Nov 28, 2017 at 02:03:16PM -0800, Laura Abbott wrote:
> Like all good bits of software, the kernel.spec has grown over time.
> Part of this growth has come from building more of the userspace
> tools that live under the tools directory of the kernel. I've been
> experimenting with moving these to a separate spec file.
> 
> Advantages:
> - Less stuff in the kernel.spec file (~300 line deletion)
> - Fewer build deps for things like perf
> - People building the kernel only get the kernel
> - Issues with userspace tools don't impact the kernel
> - Can likely drop most of the debuginfo regex nightmare for the userspace 
> packages
> 
> Disadvantages:
> - Would need to manually keep in sync on some cadence. This is mostly
> an issue for rawhide. Could we actually get away with only re-building
> on each new kernel version or do we need to resync on each -rc?
> - Would probably need to rework how tools are tied to kernel versions at
> the package level
> - Others added here
> 
> I've experimented with something at https://pagure.io/kernel-tools-pkggit
> which is mostly a copy/paste of parts of the kernel.spec file. I'm
> mostly looking for general feedback about if this a good idea but
> I'm also interested in specific feedback if you have it.

Hi Laura,

I read the feedback from people about the multiple bzs and keeping things in
sync.  This is similar to userspace utilities and I thought a Requires line
in either the kernel or utilities file would help with it.

I am more curious about the source.  Does that mean you have similar source
trees but under two different dist-git packages?

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH 2/2] configs: Update config generation script to use configs/fedora

[Don Zickus]

The previous patch moved the configs/base-{generic,debug} to configs/fedora.
Now we update the scripts to reflect that change.  Changing the scripts
was straightforward.  Handling overrides that didn't use generic names
was a little trickier.

To handle random override names (well rhel), I added some extra logic
in the config_generation script called "ORDER".  This tells the scripts
which configs to lay down first and which one overrides it.

Through some testing, I realized I could simplify things and just create
an outer 'order' loop.  This removed some duplicated code.

The other change is the 'skip_if_missing' flag.  The overrides directory
will not mimic the baseline directory layout 100%.  Ensure the baseline
config files are all there, but allow the overrides to have missing files.

Tested on my Fedora and my RHEL tree with success.
---
 configs/build_configs.sh  | 62 ---
 configs/config_generation |  5 
 2 files changed, 37 insertions(+), 30 deletions(-)

diff --git a/configs/build_configs.sh b/configs/build_configs.sh
index f345e2af..15ab6b38 100755
--- a/configs/build_configs.sh
+++ b/configs/build_configs.sh
@@ -6,7 +6,7 @@
 
 PACKAGE_NAME="${1:-kernel}" # defines the package name used
 KVERREL="${2:-}"
-SUBARCH="${3:-}" # defines a specific arch for use with rh-configs-arch-prep 
target
+SUBARCH="${3:-}" # defines a specific arch
 SCRIPT="$(readlink -f $0)"
 OUTPUT_DIR="$PWD"
 SCRIPT_DIR="$(dirname $SCRIPT)"
@@ -49,29 +49,31 @@ function merge_configs()
archvar=$1
arch=$(echo "$archvar" | cut -f1 -d"-")
configs=$2
+   order=$3
name=$OUTPUT_DIR/$PACKAGE_NAME-$archvar.config
echo -n "Building $name ... "
touch config-merging config-merged
 
-   # apply base first
-   for config in $(echo $configs | sed -e 's/:/ /g')
+   # apply based on order
+   skip_if_missing=""
+   for o in $order
do
-   perl merge.pl config-base-$config config-merging > config-merged
-   if [ ! $? -eq 0 ]; then
-   die "Failed to merge base"
-   fi
-   mv config-merged config-merging
-   done
-   for config in $(echo $configs | sed -e 's/:/ /g')
-   do
-   # not all override files exist
-   test -e config-$config || continue
-
-   perl merge.pl config-$config config-merging > config-merged
-   if [ ! $? -eq 0 ]; then
-   die "Failed to merge configs"
-   fi
-   mv config-merged config-merging
+   for config in $(echo $configs | sed -e 's/:/ /g')
+   do
+   cfile="config-$o-$config"
+
+   test -n "$skip_if_missing" && test ! -e $cfile && 
continue
+
+   perl merge.pl $cfile config-merging > config-merged
+   if [ ! $? -eq 0 ]; then
+   die "Failed to merge $cfile"
+   fi
+   mv config-merged config-merging
+   done
+
+   # first configs in $order is baseline, all files should be
+   # there.  second pass is overrides and can be missing.
+   skip_if_missing="1"
done
if [ "x$arch" == "xaarch64" ]; then
echo "# arm64" > $name
@@ -93,22 +95,22 @@ function merge_configs()
echo "done"
 }
 
-glist=$(find base-generic -type d)
-dlist=$(find base-debug -type d)
-gllist=$(test -d generic && find generic -type d)
-dllist=$(test -d debug && find debug -type d)
-
-for d in $glist $dlist $gllist $dllist
-do
-   combine_config_layer $d
-done
-
 while read line
 do
if [ $(echo "$line" | grep -c "^#") -ne 0 ]; then
continue
elif [ $(echo "$line" | grep -c "^$") -ne 0 ]; then
continue
+   elif [ $(echo "$line" | grep -c "^ORDER") -ne 0 ]; then
+   order=$(echo "$line" | cut -f2 -d"=")
+   for o in $order
+   do
+   glist=$(find $o -type d)
+   for d in $glist
+   do
+   combine_config_layer $d
+   done
+   done
else
arch=$(echo "$line" | cut -f1 -d"=")
configs=$(echo "$line" | cut -f2 -d"=")
@@ -117,7 +119,7 @@ do
continue
fi
 
-   merge_configs $arch $configs
+   merge_configs $arch $configs "$order"
fi
 done < $control_file
 
diff --git a/configs/config_generation b/configs/config_generation
index b88a5ea9..e8614c43 100644
--- a/configs/config_generation
+++ b/configs/config_generation
@@ -3,6 +3,11 @@
 # the first arg is arch and variant, the second is a hierarchy of
 # config options, lowest priority to highest
 
+# tells the build_configs.sh which order to build the 

[PATCH 1/2] configs: Move base-debug and base-generic to configs/fedora

[Don Zickus]

It was suggested that base-debug and base-generic were not good names
to use.  Further discussion led to using configs/fedora for the base
config files and configs/rhel for any overrides.

This patch does a plain

mkdir configs/fedora
git mv configs/base-{generic,debug} configs/fedora

No code changes.
---


___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Updating config option layout and scripts

[Don Zickus]

Hi Laura,

As per our conversation, here is my pull request for the config changes:
https://pagure.io/fedora-kernel-dzickus.git rh_sync


As part of an effort to foster better cross collaboration with internal Red
Hat kernels, align the configs layout to match that kernel.  This will allow
Red Hat engineers to provide easier guidance on how to set various config
options.

In addition, the scripts that process the config options will migrate to the
configs/ directory too.  Future config workflows will stage all work in the
configs/ area.

A simple diff between the kernels will easily expose which config options
are different.  Reading the comments in the file provides guidance to Fedora
to determine if that kernel should make a similar change or not.  While the
RH kernel stays internal, requested changes will be posted publicly for
review with said reason.

Rename debugconfig -> configs/base-debug
Rename baseconfig -> configs/base-generic
Rename configs/base-generic/arm/arm64 -> configs/base-generic/arm/aarch64

You can browse the changes here:
https://pagure.io/fedora-kernel-dzickus/branch/rh_sync

Note: Laura asked me not post the patches as the diffstat for the 'git mv'
is obnoxiously large.  Instead I am providing the changes on pagure.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Don Zickus]

On Fri, Nov 10, 2017 at 01:17:50PM -0500, Nathaniel McCallum wrote:
> The more I look at lshw, the more I'm ambivalent (I'm not against it,
> just not for it either). It certainly collects a lot of relevant
> information. However, I see the following problems.
> 
> 1. lshw tries to make things human readable. This is bad for
> databases. We want to record things like immutable numeric hardware
> IDs rather than the current contents of pci.ids. lshw does provide
> -numeric, but this just adds the numbers to the human readable
> strings.
> 
> 2. lshw collects a lot of data we may not be interested in. For
> example, it reports the four different kinds of floppy disk drives my
> BIOS supports. Also, L1, L2 and L3 cache. There is a bunch of stuff
> like this. Is it useful? Some of it definitely is. But transferring
> unwanted data over the wire is not being a good netizen. Also, some
> people pay for data per MB transferred. We should be respectful.
> 
> 3. lshw supports '-sanitize', but this merely replaces the values with
> '[REMOVED]'. See above for why we don't want to transmit this data.
> 
> 4. lshw reports bus configuration. I'm not sure if this is relevant or
> how we would want to map this data. For example, if Dell uses the same
> hardware in a bunch of laptops then we can deduplicate this to one
> "hardware profile." But if bus configuration is part of this profile,
> then we will have much higher cardinality. If this information is
> important to have, we can make it work. But if not, it would be better
> to try to save storage.
> 
> 5. lshw doesn't seem to have a way to separate "system hardware" from
> "transient hardware." To be fair, this may be impossible. But it would
> be nice to understand the difference between, say, my bluetooth radio
> and my YubiKey. I can't easily remove the former but I can the latter.
> This also goes to cardinality reduction.
> 
> 6. lshw mixes things that are transient with things that are
> permanent. We can remove the timestamps with -notime. But, for
> example, it reports the kernel module currently assigned to a piece of
> hardware. This is probably relevant information, but we will have to
> carefully separate the data based on its lifespan.
> 
> 7. lshw reports virtual NICs as physical ones. We probably don't care
> about this and I certainly don't want to bloat the database with
> everyone's docker subnets unnecessarily.

Again, I was just pointing out a tool we use internally for inventorying our
hardware that I thought might be useful.  If it doesn't work for you, feel
free to choose something else. :-)  I do appreciate the feedback you
provided.  I might work with folks on my team to address some of them as
they could be of benefit for our work too.

Cheers,
Don


> 
> 
> On Fri, Nov 10, 2017 at 12:38 PM, Jeremy Cline <jer...@jcline.org> wrote:
> > On 11/09/2017 09:12 AM, Don Zickus wrote:
> >> On Wed, Nov 08, 2017 at 05:02:05PM -0500, Nathaniel McCallum wrote:
> >>> It isn't documented in F27, but it does work. However, we probably
> >>> want at least this patch:
> >>> https://github.com/lyonel/lshw/commit/135a853c60582b14c5b67e5cd988a8062d9896f4
> >>
> >> And some beaker stuff looks interesting in
> >>
> >> https://github.com/lyonel/lshw/commit/f95aa917a84a8ee74ce79e9b4f9e198d21a2e4d9
> >>
> >> Regardless.  My overall point was the lshw tool seems to embody a lot of
> >> what you were looking for and thought it could be useful (with some more
> >> fixes) instead of re-inventing the wheel with new plugins. :-)
> >>
> >> Up to you guys.
> >
> > I have no desire to re-invent wheels so I think it makes sense for us to
> > use lshw. Knowing it's being used internally is also good.
> >
> >
> > --
> > Jeremy Cline
> > XMPP: jer...@jcline.org
> > IRC:  jcline
> >
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Don Zickus]

On Wed, Nov 08, 2017 at 05:02:05PM -0500, Nathaniel McCallum wrote:
> It isn't documented in F27, but it does work. However, we probably
> want at least this patch:
> https://github.com/lyonel/lshw/commit/135a853c60582b14c5b67e5cd988a8062d9896f4

And some beaker stuff looks interesting in

https://github.com/lyonel/lshw/commit/f95aa917a84a8ee74ce79e9b4f9e198d21a2e4d9

Regardless.  My overall point was the lshw tool seems to embody a lot of
what you were looking for and thought it could be useful (with some more
fixes) instead of re-inventing the wheel with new plugins. :-)

Up to you guys.

Cheers,
Don

> 
> On Wed, Nov 8, 2017 at 4:28 PM, Don Zickus <dzic...@redhat.com> wrote:
> > On Wed, Nov 08, 2017 at 04:09:26PM -0500, Nathaniel McCallum wrote:
> >> I just looked at the code for lshw. The master branch already supports
> >> JSON. We just need them to release it.
> >
> > Eh?  'lshw -json' doesn't work for you?  I thought that was a supported
> > output for a while now.  At least it works on my F27 box, but I think we
> > have it running successfully under RHEL-7 too.
> >
> > Cheers,
> > Don
> >
> >>
> >> On Wed, Nov 8, 2017 at 3:23 PM, Don Zickus <dzic...@redhat.com> wrote:
> >> > On Wed, Nov 08, 2017 at 03:16:24PM -0500, Nathaniel McCallum wrote:
> >> >> I just played around with lshw a bit. We should totally make it export
> >> >> JSON. We can then submit this directly (as one census plugin).
> >> >
> >> > Yes, that is how we use it to update hardware info internally to our 
> >> > Beaker
> >> > instance. :-)
> >> >
> >> > Cheers,
> >> > Don
> >> >
> >> >>
> >> >> On Wed, Nov 8, 2017 at 12:34 PM, Don Zickus <dzic...@redhat.com> wrote:
> >> >> > On Tue, Nov 07, 2017 at 10:49:02PM +, Jeremy Cline wrote:
> >> >> >> Hey folks,
> >> >> >>
> >> >> >> For some time now, Fedora has operated without a database of hardware
> >> >> >> users have. Smolt, the old hardware database, was retired in 2012[0] 
> >> >> >> and
> >> >> >> its intended successor[1] was never deployed by Fedora 
> >> >> >> Infrastructure.
> >> >> >>
> >> >> >> It would be nice to have a hardware database, so I (and hopefully 
> >> >> >> some
> >> >> >> others) would like to get Census up and running for Fedora. Before we
> >> >> >> look at deploying Census, however, it would be good to make sure it 
> >> >> >> has
> >> >> >> everything we need.
> >> >> >>
> >> >> >> Census has client plugins to collect information[2]. At the moment, 
> >> >> >> it
> >> >> >> has plugins for:
> >> >> >>
> >> >> >> * The vendor, device, subsystem_vendor, subsystem_device, and class 
> >> >> >> from
> >> >> >>   each PCI device
> >> >> >>
> >> >> >> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB 
> >> >> >> devices
> >> >> >>   as well as the bInterfaceClass, bInterfaceSubClass, and
> >> >> >>   bInterfaceProtocol for each interface
> >> >> >>
> >> >> >> * The contents of /etc/os-release
> >> >> >>
> >> >> >> * All the RPMs installed on a system
> >> >> >>
> >> >> >> Other than the drivers bound to the PCI and USB devices (which is an
> >> >> >> open PR[3]), what else would be good to collect?
> >> >> >>
> >> >> >> [0] https://fedoraproject.org/wiki/Smolt_retirement
> >> >> >> [1] https://github.com/npmccallum/census
> >> >> >> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
> >> >> >> [3] https://github.com/npmccallum/census/pull/3
> >> >> >
> >> >> > Internally, we have been focusing on using 'lshw' as the tool that 
> >> >> > provides
> >> >> > all that info and handles all the arch funkiness (and includes 
> >> >> > firmware).
> >> >> > If there is anything missing, we have tried to push upstream to that
> >> >> > project.
> >> >> >
> >> >> > Would that cover a lot of the info you are looking for?
> >> >> >
> >> >> > Cheers,
> >> >> > Don
> >> >> ___
> >> >> kernel mailing list -- kernel@lists.fedoraproject.org
> >> >> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> >> ___
> >> kernel mailing list -- kernel@lists.fedoraproject.org
> >> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Don Zickus]

On Thu, Nov 09, 2017 at 09:19:04AM -0500, Nathaniel McCallum wrote:
> Agreed completely. But I still need someone with experience using lshw
> to write a data processor (json => SQL) for that data. Also, we will
> need to sanitize the lshw output to ensure we omit identifying
> information. For example, ip addresses on the network interfaces need
> to be filtered out. It might be better to write an option for upstream
> lshw to anonymize the output.

You mean like 'lshw -sanitize'? :-)

Cheers,
Don

> 
> Any volunteers to work with me on those two items?
> 
> On Thu, Nov 9, 2017 at 9:12 AM, Don Zickus <dzic...@redhat.com> wrote:
> > On Wed, Nov 08, 2017 at 05:02:05PM -0500, Nathaniel McCallum wrote:
> >> It isn't documented in F27, but it does work. However, we probably
> >> want at least this patch:
> >> https://github.com/lyonel/lshw/commit/135a853c60582b14c5b67e5cd988a8062d9896f4
> >
> > And some beaker stuff looks interesting in
> >
> > https://github.com/lyonel/lshw/commit/f95aa917a84a8ee74ce79e9b4f9e198d21a2e4d9
> >
> > Regardless.  My overall point was the lshw tool seems to embody a lot of
> > what you were looking for and thought it could be useful (with some more
> > fixes) instead of re-inventing the wheel with new plugins. :-)
> >
> > Up to you guys.
> >
> > Cheers,
> > Don
> >
> >>
> >> On Wed, Nov 8, 2017 at 4:28 PM, Don Zickus <dzic...@redhat.com> wrote:
> >> > On Wed, Nov 08, 2017 at 04:09:26PM -0500, Nathaniel McCallum wrote:
> >> >> I just looked at the code for lshw. The master branch already supports
> >> >> JSON. We just need them to release it.
> >> >
> >> > Eh?  'lshw -json' doesn't work for you?  I thought that was a supported
> >> > output for a while now.  At least it works on my F27 box, but I think we
> >> > have it running successfully under RHEL-7 too.
> >> >
> >> > Cheers,
> >> > Don
> >> >
> >> >>
> >> >> On Wed, Nov 8, 2017 at 3:23 PM, Don Zickus <dzic...@redhat.com> wrote:
> >> >> > On Wed, Nov 08, 2017 at 03:16:24PM -0500, Nathaniel McCallum wrote:
> >> >> >> I just played around with lshw a bit. We should totally make it 
> >> >> >> export
> >> >> >> JSON. We can then submit this directly (as one census plugin).
> >> >> >
> >> >> > Yes, that is how we use it to update hardware info internally to our 
> >> >> > Beaker
> >> >> > instance. :-)
> >> >> >
> >> >> > Cheers,
> >> >> > Don
> >> >> >
> >> >> >>
> >> >> >> On Wed, Nov 8, 2017 at 12:34 PM, Don Zickus <dzic...@redhat.com> 
> >> >> >> wrote:
> >> >> >> > On Tue, Nov 07, 2017 at 10:49:02PM +, Jeremy Cline wrote:
> >> >> >> >> Hey folks,
> >> >> >> >>
> >> >> >> >> For some time now, Fedora has operated without a database of 
> >> >> >> >> hardware
> >> >> >> >> users have. Smolt, the old hardware database, was retired in 
> >> >> >> >> 2012[0] and
> >> >> >> >> its intended successor[1] was never deployed by Fedora 
> >> >> >> >> Infrastructure.
> >> >> >> >>
> >> >> >> >> It would be nice to have a hardware database, so I (and hopefully 
> >> >> >> >> some
> >> >> >> >> others) would like to get Census up and running for Fedora. 
> >> >> >> >> Before we
> >> >> >> >> look at deploying Census, however, it would be good to make sure 
> >> >> >> >> it has
> >> >> >> >> everything we need.
> >> >> >> >>
> >> >> >> >> Census has client plugins to collect information[2]. At the 
> >> >> >> >> moment, it
> >> >> >> >> has plugins for:
> >> >> >> >>
> >> >> >> >> * The vendor, device, subsystem_vendor, subsystem_device, and 
> >> >> >> >> class from
> >> >> >> >>   each PCI device
> >> >> >> >>
> >> >> >> >> * The idVendor, idProduct, bcdDevice, and bDeviceClass fo

Re: Reviving the hardware census

[Don Zickus]

On Tue, Nov 07, 2017 at 10:49:02PM +, Jeremy Cline wrote:
> Hey folks,
> 
> For some time now, Fedora has operated without a database of hardware
> users have. Smolt, the old hardware database, was retired in 2012[0] and
> its intended successor[1] was never deployed by Fedora Infrastructure.
> 
> It would be nice to have a hardware database, so I (and hopefully some
> others) would like to get Census up and running for Fedora. Before we
> look at deploying Census, however, it would be good to make sure it has
> everything we need.
> 
> Census has client plugins to collect information[2]. At the moment, it
> has plugins for:
> 
> * The vendor, device, subsystem_vendor, subsystem_device, and class from
>   each PCI device
> 
> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices
>   as well as the bInterfaceClass, bInterfaceSubClass, and
>   bInterfaceProtocol for each interface
> 
> * The contents of /etc/os-release
> 
> * All the RPMs installed on a system
> 
> Other than the drivers bound to the PCI and USB devices (which is an
> open PR[3]), what else would be good to collect?
> 
> [0] https://fedoraproject.org/wiki/Smolt_retirement
> [1] https://github.com/npmccallum/census
> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
> [3] https://github.com/npmccallum/census/pull/3

Internally, we have been focusing on using 'lshw' as the tool that provides
all that info and handles all the arch funkiness (and includes firmware).
If there is anything missing, we have tried to push upstream to that
project.

Would that cover a lot of the info you are looking for?

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Don Zickus]

On Wed, Nov 08, 2017 at 04:09:26PM -0500, Nathaniel McCallum wrote:
> I just looked at the code for lshw. The master branch already supports
> JSON. We just need them to release it.

Eh?  'lshw -json' doesn't work for you?  I thought that was a supported
output for a while now.  At least it works on my F27 box, but I think we
have it running successfully under RHEL-7 too.

Cheers,
Don

> 
> On Wed, Nov 8, 2017 at 3:23 PM, Don Zickus <dzic...@redhat.com> wrote:
> > On Wed, Nov 08, 2017 at 03:16:24PM -0500, Nathaniel McCallum wrote:
> >> I just played around with lshw a bit. We should totally make it export
> >> JSON. We can then submit this directly (as one census plugin).
> >
> > Yes, that is how we use it to update hardware info internally to our Beaker
> > instance. :-)
> >
> > Cheers,
> > Don
> >
> >>
> >> On Wed, Nov 8, 2017 at 12:34 PM, Don Zickus <dzic...@redhat.com> wrote:
> >> > On Tue, Nov 07, 2017 at 10:49:02PM +, Jeremy Cline wrote:
> >> >> Hey folks,
> >> >>
> >> >> For some time now, Fedora has operated without a database of hardware
> >> >> users have. Smolt, the old hardware database, was retired in 2012[0] and
> >> >> its intended successor[1] was never deployed by Fedora Infrastructure.
> >> >>
> >> >> It would be nice to have a hardware database, so I (and hopefully some
> >> >> others) would like to get Census up and running for Fedora. Before we
> >> >> look at deploying Census, however, it would be good to make sure it has
> >> >> everything we need.
> >> >>
> >> >> Census has client plugins to collect information[2]. At the moment, it
> >> >> has plugins for:
> >> >>
> >> >> * The vendor, device, subsystem_vendor, subsystem_device, and class from
> >> >>   each PCI device
> >> >>
> >> >> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices
> >> >>   as well as the bInterfaceClass, bInterfaceSubClass, and
> >> >>   bInterfaceProtocol for each interface
> >> >>
> >> >> * The contents of /etc/os-release
> >> >>
> >> >> * All the RPMs installed on a system
> >> >>
> >> >> Other than the drivers bound to the PCI and USB devices (which is an
> >> >> open PR[3]), what else would be good to collect?
> >> >>
> >> >> [0] https://fedoraproject.org/wiki/Smolt_retirement
> >> >> [1] https://github.com/npmccallum/census
> >> >> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
> >> >> [3] https://github.com/npmccallum/census/pull/3
> >> >
> >> > Internally, we have been focusing on using 'lshw' as the tool that 
> >> > provides
> >> > all that info and handles all the arch funkiness (and includes firmware).
> >> > If there is anything missing, we have tried to push upstream to that
> >> > project.
> >> >
> >> > Would that cover a lot of the info you are looking for?
> >> >
> >> > Cheers,
> >> > Don
> >> ___
> >> kernel mailing list -- kernel@lists.fedoraproject.org
> >> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Don Zickus]

On Wed, Nov 08, 2017 at 01:48:36PM -0500, Josh Boyer wrote:
> >> [1] https://github.com/npmccallum/census
> >> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
> >> [3] https://github.com/npmccallum/census/pull/3
> >
> > Internally, we have been focusing on using 'lshw' as the tool that provides
> > all that info and handles all the arch funkiness (and includes firmware).
> > If there is anything missing, we have tried to push upstream to that
> > project.
> >
> > Would that cover a lot of the info you are looking for?
> 
> It sounds like lshw could provide the output for the local system if
> someone wrote a census plugin for it.  What it doesn't seem to cover
> at all is the "gather data and send it somewhere" part, right?

I think it covers part of the 'gather data', no? :-)  I had assumed the
census tool handles the 'send it' somewhere.

As part of the kernel CI work I am doing internally, we are trying to figure
out a more universal way of exchange machine info when providing feedback
that a test or patch broke.  Lots of folks have been using lshw.  This has
made it easier to write scripts on top of that output compared to various
custom output.  It isn't perfect, but it seems to do a reasonable job today.


Cheers,
Don

> 
> josh
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Reviving the hardware census

[Don Zickus]

On Wed, Nov 08, 2017 at 03:16:24PM -0500, Nathaniel McCallum wrote:
> I just played around with lshw a bit. We should totally make it export
> JSON. We can then submit this directly (as one census plugin).

Yes, that is how we use it to update hardware info internally to our Beaker
instance. :-)

Cheers,
Don

> 
> On Wed, Nov 8, 2017 at 12:34 PM, Don Zickus <dzic...@redhat.com> wrote:
> > On Tue, Nov 07, 2017 at 10:49:02PM +, Jeremy Cline wrote:
> >> Hey folks,
> >>
> >> For some time now, Fedora has operated without a database of hardware
> >> users have. Smolt, the old hardware database, was retired in 2012[0] and
> >> its intended successor[1] was never deployed by Fedora Infrastructure.
> >>
> >> It would be nice to have a hardware database, so I (and hopefully some
> >> others) would like to get Census up and running for Fedora. Before we
> >> look at deploying Census, however, it would be good to make sure it has
> >> everything we need.
> >>
> >> Census has client plugins to collect information[2]. At the moment, it
> >> has plugins for:
> >>
> >> * The vendor, device, subsystem_vendor, subsystem_device, and class from
> >>   each PCI device
> >>
> >> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices
> >>   as well as the bInterfaceClass, bInterfaceSubClass, and
> >>   bInterfaceProtocol for each interface
> >>
> >> * The contents of /etc/os-release
> >>
> >> * All the RPMs installed on a system
> >>
> >> Other than the drivers bound to the PCI and USB devices (which is an
> >> open PR[3]), what else would be good to collect?
> >>
> >> [0] https://fedoraproject.org/wiki/Smolt_retirement
> >> [1] https://github.com/npmccallum/census
> >> [2] https://github.com/npmccallum/census/blob/master/client/plugins/
> >> [3] https://github.com/npmccallum/census/pull/3
> >
> > Internally, we have been focusing on using 'lshw' as the tool that provides
> > all that info and handles all the arch funkiness (and includes firmware).
> > If there is anything missing, we have tried to push upstream to that
> > project.
> >
> > Would that cover a lot of the info you are looking for?
> >
> > Cheers,
> > Don
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Updating config option layout and scripts

[Don Zickus]

On Fri, Dec 08, 2017 at 05:24:22PM -0500, Jarod Wilson wrote:
> > It is, but was specifically added so kernels that want to do overrides like
> > RHEL could add their own custom configs/debug and configs/generic.
> > 
> > I am open to name changes but the goal was to use Fedora configs as a base
> > and then allow the ability to override through other directories.
> > 
> > So if you have a proposal to allow that, I am open to it. :-)
> 
> Why not configs/fedora/{generic,debug} and then we tack on a
> configs/rhel/{generic,debug} when forking for the next RHEL kernel? Trying
> to keep them from polluting each other with specific names?

Ok.  I don't have any objection to that.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Updating config option layout and scripts

[Don Zickus]

On Mon, Dec 11, 2017 at 04:50:03PM -0500, Jarod Wilson wrote:
> On 2017-12-11 9:24 AM, Don Zickus wrote:
> > On Fri, Dec 08, 2017 at 05:24:22PM -0500, Jarod Wilson wrote:
> > > > It is, but was specifically added so kernels that want to do overrides 
> > > > like
> > > > RHEL could add their own custom configs/debug and configs/generic.
> > > > 
> > > > I am open to name changes but the goal was to use Fedora configs as a 
> > > > base
> > > > and then allow the ability to override through other directories.
> > > > 
> > > > So if you have a proposal to allow that, I am open to it. :-)
> > > 
> > > Why not configs/fedora/{generic,debug} and then we tack on a
> > > configs/rhel/{generic,debug} when forking for the next RHEL kernel? Trying
> > > to keep them from polluting each other with specific names?
> > 
> > Ok.  I don't have any objection to that.
> 
> Something I haven't actually looked at... Are those 'generic' and 'debug'
> items actually files, or folder full of individual config option files, like
> we have in Red Hat Enterprise Linux 7's tree? Either way, we could still do
> individual files under configs/rhel/generic/CONFIG_FOO that override either
> a stack of files or an individual file from Fedora.

That was the plan.  Fedora provides individual files and we have the ability
to override it with our changes.  In fact, I am hoping to go one further and
provide our changes as feedback to Fedora as suggestions for them to
consider.  But that is a side benefit.

> 
> I'm quite partial to the one config option per file route we've taken in
> RHEL7, because people so infrequently get it wrong, where the old pile of
> files approach in RHEL-6, people were frequently adding config options to
> what were originally the Fedora configs, iirc, rather than the RHEL override
> configs. The one config per file approach is also less prone to requiring
> rediffing when someone else's config option gets in before yours. I think
> having configs/fedora/* for the base and configs/rhel/* for the RHEL
> overrides/updates/additions should be clear enough that it won't get tanked
> either, and continues to provide the benefit of collision avoidance.

Yup.  Makes sense.

I will put together a patch to share either tomorrow or the next day.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Updating config option layout and scripts

[Don Zickus]

On Wed, Dec 06, 2017 at 02:34:28PM +, Peter Robinson wrote:
> On Wed, Dec 6, 2017 at 2:17 PM, Don Zickus <dzic...@redhat.com> wrote:
> > On Wed, Dec 06, 2017 at 05:34:18AM +, Peter Robinson wrote:
> >> On Mon, Nov 13, 2017 at 5:42 PM, Laura Abbott <labb...@redhat.com> wrote:
> >> > On 11/10/2017 11:48 AM, Don Zickus wrote:
> >> >>
> >> >> Hi Laura,
> >> >>
> >> >> As per our conversation, here is my pull request for the config changes:
> >> >> https://pagure.io/fedora-kernel-dzickus.git rh_sync
> >> >>
> >> >>
> >> >> As part of an effort to foster better cross collaboration with internal
> >> >> Red
> >> >> Hat kernels, align the configs layout to match that kernel.  This will
> >> >> allow
> >> >> Red Hat engineers to provide easier guidance on how to set various 
> >> >> config
> >> >> options.
> >> >>
> >> >> In addition, the scripts that process the config options will migrate to
> >> >> the
> >> >> configs/ directory too.  Future config workflows will stage all work in
> >> >> the
> >> >> configs/ area.
> >> >>
> >> >> A simple diff between the kernels will easily expose which config 
> >> >> options
> >> >> are different.  Reading the comments in the file provides guidance to
> >> >> Fedora
> >> >> to determine if that kernel should make a similar change or not.  While
> >> >> the
> >> >> RH kernel stays internal, requested changes will be posted publicly for
> >> >> review with said reason.
> >> >>
> >> >> Rename debugconfig -> configs/base-debug
> >> >> Rename baseconfig -> configs/base-generic
> >>
> >> Any chance we could drop the base- in those names and just have
> >> configs/debug/
> >> configs/generic
> >>
> >> The base- is somewhat superfluous and is annoying for auto complete ;-)
> >
> > It is, but was specifically added so kernels that want to do overrides like
> > RHEL could add their own custom configs/debug and configs/generic.
> >
> > I am open to name changes but the goal was to use Fedora configs as a base
> > and then allow the ability to override through other directories.
> 
> I don't see how 's/base-//' would stop the ability for overrides? Do
> you have an explicit example of how you see that working?

THe way it works is configs/base-generic creates the initial template.  Then
the scripts walk the configs/generic directory to override anything it
finds.  This makes it clear what the differences are with Fedora and when
Fedora changes an option, it makes it easy to trigger a review of said
change.

I hope that clarifies things.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Updating config option layout and scripts

[Don Zickus]

On Wed, Dec 06, 2017 at 05:34:18AM +, Peter Robinson wrote:
> On Mon, Nov 13, 2017 at 5:42 PM, Laura Abbott <labb...@redhat.com> wrote:
> > On 11/10/2017 11:48 AM, Don Zickus wrote:
> >>
> >> Hi Laura,
> >>
> >> As per our conversation, here is my pull request for the config changes:
> >> https://pagure.io/fedora-kernel-dzickus.git rh_sync
> >>
> >>
> >> As part of an effort to foster better cross collaboration with internal
> >> Red
> >> Hat kernels, align the configs layout to match that kernel.  This will
> >> allow
> >> Red Hat engineers to provide easier guidance on how to set various config
> >> options.
> >>
> >> In addition, the scripts that process the config options will migrate to
> >> the
> >> configs/ directory too.  Future config workflows will stage all work in
> >> the
> >> configs/ area.
> >>
> >> A simple diff between the kernels will easily expose which config options
> >> are different.  Reading the comments in the file provides guidance to
> >> Fedora
> >> to determine if that kernel should make a similar change or not.  While
> >> the
> >> RH kernel stays internal, requested changes will be posted publicly for
> >> review with said reason.
> >>
> >> Rename debugconfig -> configs/base-debug
> >> Rename baseconfig -> configs/base-generic
> 
> Any chance we could drop the base- in those names and just have
> configs/debug/
> configs/generic
> 
> The base- is somewhat superfluous and is annoying for auto complete ;-)

It is, but was specifically added so kernels that want to do overrides like
RHEL could add their own custom configs/debug and configs/generic.

I am open to name changes but the goal was to use Fedora configs as a base
and then allow the ability to override through other directories.

So if you have a proposal to allow that, I am open to it. :-)

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 0/2] configs: Rename base-{generic,debug} to configs/fedora/

[Don Zickus]

On Wed, Dec 13, 2017 at 04:39:26PM -0500, Don Zickus wrote:
> This patchset renames the configs/base-{generic,debug} to
> configs/fedora/{generic,debug} and updates the scripts to reflect that.

Hi Jarod, Peter,

Does this approach work better?

Cheers,
Don

> 
> Because the configs rename patch is huge and Laura prefers not to have it
> on the list, I am purposely excluding the content of that particular patch.
> 
> The script changes are attached for public review.
> 
> The code can be reviewed here:
> https://pagure.io/fedora-kernel-dzickus.git rh_sync2
> 
> 
> Don Zickus (2):
>   configs: Move base-debug and base-generic to configs/fedora
>   configs: Update config generation script to use configs/fedora
> 
>  configs/build_configs.sh   | 62 
> +++---
>  configs/config_generation  |  5 ++
> 
> 
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: [PATCH 0/2] configs: Rename base-{generic,debug} to configs/fedora/

[Don Zickus]

On Thu, Jan 04, 2018 at 11:00:03AM -0800, Laura Abbott wrote:
> On 12/20/2017 04:04 PM, Laura Abbott wrote:
> > On 12/20/2017 09:39 AM, Don Zickus wrote:
> > > On Wed, Dec 13, 2017 at 04:39:26PM -0500, Don Zickus wrote:
> > > > This patchset renames the configs/base-{generic,debug} to
> > > > configs/fedora/{generic,debug} and updates the scripts to reflect that.
> > > 
> > > Hi Jarod, Peter,
> > > 
> > > Does this approach work better?
> > > 
> > > Cheers,
> > > Don
> > > 
> > 
> > Sorry, I forgot about this last week. I'm pretty much indifferent to
> > what this gets called so I'll wait for feedback from someone before
> > applying.
> > 
> 
> I haven't heard any more feedback. If you are still interested in having
> these applied, can you rebase to the latest rawhide?

Actually I am as I think it simplifies things on the script side.

https://pagure.io/fedora-kernel-dzickus.git rh_sync2

is a forced update.  Nothing on this patchset changed other than moving new
config files to the new directory.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Can't capture vmcore?

[Don Zickus]

(cc'ing Dae Young)

On Tue, Jan 16, 2018 at 07:41:36AM -0500, Josh Boyer wrote:
> On Tue, Jan 9, 2018 at 1:51 PM, Maxim Burgerhout  wrote:
> > I'm getting kernel panics in a VM that functions as a hypervisor, the moment
> > I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That is
> > annoying, of course, so I try to be a good citizen and file a bug.
> >
> > For some reason though, I cannot get the core dumped. I get a core fine with
> > sysrq, but not with this actual panic. I've followed [1] to set up kdump and
> > crash, but everytime I trigger the crash and see my VM reboot, I see an
> > empty /var/crash afterwards.
> >
> > As was able to get the vmcore written to /var/crash on in a RHEL7 guest, I'm
> > starting to suspect a bug, but I'm unsure.
> >
> > Any pointers on how to debug this?
> >
> > [1] https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
> 
> Adding the Fedora kernel list.
> 
> Kdump isn't automatically tested in Fedora and while it can work, it
> can often be broken as well.  There might be someone on the kernel
> list that is more familiar with the current state of kdump support in
> Fedora, or alternative methods for getting the kernel backtrace.
> 
> josh
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

[PATCH] Fix misnamed CONFIG files

[Don Zickus]

A couple of CONFIG file names were misnamed during their creation.
Fix them up.

configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance isn't 
horrible -> configs/fedora/generic/CONFIG_DEBUG_VM_RB

and

configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug -> 
configs/fedora/generic/CONFIG_DPM_WATCHDOG
---
 .../CONFIG_DEBUG_VM_RB revisit this if performance isn't horrible| 1 -
 configs/fedora/generic/CONFIG_DPM_WATCHDOG   | 1 +
 configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)
 delete mode 100644 configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if 
performance isn't horrible
 create mode 100644 configs/fedora/generic/CONFIG_DPM_WATCHDOG
 delete mode 100644 configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in 
debug

diff --git a/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if 
performance isn't horrible b/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit 
this if performance isn't horrible
deleted file mode 100644
index fbc8aaef..
--- a/configs/fedora/generic/CONFIG_DEBUG_VM_RB revisit this if performance 
isn't horrible  
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_DEBUG_VM_RB is not set # revisit this if performance isn't horrible
diff --git a/configs/fedora/generic/CONFIG_DPM_WATCHDOG 
b/configs/fedora/generic/CONFIG_DPM_WATCHDOG
new file mode 100644
index ..c12b35c4
--- /dev/null
+++ b/configs/fedora/generic/CONFIG_DPM_WATCHDOG
@@ -0,0 +1 @@
+# CONFIG_DPM_WATCHDOG is not set # revisit this in debug
diff --git a/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug 
b/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug
deleted file mode 100644
index c12b35c4..
--- a/configs/fedora/generic/CONFIG_DPM_WATCHDOG revisit this in debug  
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_DPM_WATCHDOG is not set # revisit this in debug
-- 
2.14.3
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Don Zickus]

On Thu, Feb 01, 2018 at 12:34:50PM +0100, Hans de Goede wrote:
> Hi All,
> 
> For the "Improved Laptop Battery Life" feature:
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> 
> I'm working on for Fedora 28 I would like to also try and enable
> Panel Self Refresh on laptops with Intel graphics, some quick tests
> have shown this to save another 0.5W (when idle / nothing on the
> screen changes). This is currently off be default because it is
> known to cause issues on some devices. So I think we will probably
> need a white- or black-list. But first we need more data on this.
> 
> If you can spare 10 minutes, please see my blogpost for how to test
> this and send me a mail with the info request in the blogpost:
> https://hansdegoede.livejournal.com/18653.html

Hi Hans,

I didn't exactly play with the psr like you asked, but your blog intrigued
me to play with powertop again.

On my Dell 5510 laptop, which has two graphics chips (intel for display,
nvidia for external displays), setting the following to good:

Runtime PM for PCI Device NVIDIA Corporation GM107GLM [Quadro M1000M]

dropped me from 14W down to 6-7W.  And doubled my battery life.  Considering
I normally don't connect up the external display, I find this a huge
savings.

So indirectly I want to say thank you!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Don Zickus]

On Fri, Feb 02, 2018 at 10:11:03AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 01-02-18 15:59, Don Zickus wrote:
> > On Thu, Feb 01, 2018 at 12:34:50PM +0100, Hans de Goede wrote:
> > > Hi All,
> > > 
> > > For the "Improved Laptop Battery Life" feature:
> > > https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> > > 
> > > I'm working on for Fedora 28 I would like to also try and enable
> > > Panel Self Refresh on laptops with Intel graphics, some quick tests
> > > have shown this to save another 0.5W (when idle / nothing on the
> > > screen changes). This is currently off be default because it is
> > > known to cause issues on some devices. So I think we will probably
> > > need a white- or black-list. But first we need more data on this.
> > > 
> > > If you can spare 10 minutes, please see my blogpost for how to test
> > > this and send me a mail with the info request in the blogpost:
> > > https://hansdegoede.livejournal.com/18653.html
> > 
> > Hi Hans,
> > 
> > I didn't exactly play with the psr like you asked, but your blog intrigued
> > me to play with powertop again.
> > 
> > On my Dell 5510 laptop, which has two graphics chips (intel for display,
> > nvidia for external displays), setting the following to good:
> > 
> > Runtime PM for PCI Device NVIDIA Corporation GM107GLM [Quadro M1000M]
> > 
> > dropped me from 14W down to 6-7W.  And doubled my battery life.  Considering
> > I normally don't connect up the external display, I find this a huge
> > savings.
> > 
> > So indirectly I want to say thank you!
> 
> Interesting, nouveau.runpm defaults to 1, so I wonder why it is not doing
> this by default on your system. Can you file a bug against 
> xorg-x11-drv-nouveau
> please and put the following people in the Cc:

I did, bz: https://bugzilla.redhat.com/show_bug.cgi?id=1541495

This may be the reason:

[14321.977201] pci :01:00.0: optimus capabilities: enabled, status
dynamic power, hda bios codec supported
[14321.977205] VGA switcheroo: detected Optimus DSM method
\_SB_.PCI0.PEG0.PEGP handle
[14321.977207] nouveau: detected PR support, will not use DSM
[14321.977236] nouveau :01:00.0: enabling device ( -> 0003)
[14321.977376] nouveau :01:00.0: unknown chipset ()
[14321.977381] nouveau: probe of :01:00.0 failed with error -12

> 
> Ben Skeggs <bske...@redhat.com>
> Lyude Paul <ly...@redhat.com>
> Hans de Goede <hdego...@redhat.com>
> 
> Note Lyude works from the Westford office, not sure where you are located,
> but if you're also in Westford you might just want to drop by her desk :)

She switched to the Boston office, so I can't walk over anymore.  But I can
still reach out to her.

Thanks!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Don Zickus]

On Thu, Feb 01, 2018 at 01:16:55PM -0500, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > On Thu, Feb 01, 2018 at 12:34:50PM +0100, Hans de Goede wrote:
> > > Hi All,
> > > 
> > > For the "Improved Laptop Battery Life" feature:
> > > https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> > > 
> > > I'm working on for Fedora 28 I would like to also try and enable
> > > Panel Self Refresh on laptops with Intel graphics, some quick tests
> > > have shown this to save another 0.5W (when idle / nothing on the
> > > screen changes). This is currently off be default because it is
> > > known to cause issues on some devices. So I think we will probably
> > > need a white- or black-list. But first we need more data on this.
> > > 
> > > If you can spare 10 minutes, please see my blogpost for how to test
> > > this and send me a mail with the info request in the blogpost:
> > > https://hansdegoede.livejournal.com/18653.html
> > 
> > Hi Hans,
> > 
> > I didn't exactly play with the psr like you asked, but your blog intrigued
> > me to play with powertop again.
> > 
> > On my Dell 5510 laptop, which has two graphics chips (intel for display,
> > nvidia for external displays), setting the following to good:
> > 
> > Runtime PM for PCI Device NVIDIA Corporation GM107GLM [Quadro M1000M]
> > 
> > dropped me from 14W down to 6-7W.  And doubled my battery life.  Considering
> > I normally don't connect up the external display, I find this a huge
> > savings.
> > 
> > So indirectly I want to say thank you!
> 
> FWIW, switcheroo-control is supposed to turn off the discrete device on boot,
> so you wouldn't need to do this. But it doesn't work with Secure Boot enabled
> because of the location of the vga_switcheroo in /sys (under debug).

I don't think I have secure boot enabled.  But good to know
switcheroo-control exists!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Current specfile misapplies v4.14.10 stable update for fc26

[Don Zickus]

On Sat, Dec 30, 2017 at 01:52:49PM +0100, Paul Bolle wrote:
> 0) The v4.14.10 stable updates adds a new executable (tools/objtool/sync-
> check.sh). Somehow this was added non-executable during my local build of
> v4.14.10 (on fc26, that is). This made the build fail:
> 
> [...]
> + make -s ARCH=x86_64 V=1 -j4 bzImage
> make[2]: execvp: ./sync-check.sh: Permission denied
> make[2]: *** [Makefile:49: 
> [...]/BUILD/kernel-4.14.fc26/linux-4.14.10-1.local0.fc26.x86_64/tools/objtool/objtool]
>  Error 127
> make[1]: *** [Makefile:62: objtool] Error 2
> make: *** [Makefile:1623: tools/objtool] Error 2
> make: *** Waiting for unfinished jobs
> error: Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
> 
> 
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
> 
> Anybody else seeing this?
> 
> 1) Switching the specfile from patch to "git apply" seems to do the right
> thing. This is what I tried:
> 
> diff --git a/kernel.spec b/kernel.spec
> index 965345c2a26e..b2a1ffbe843d 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -1267,8 +1267,9 @@ fi
>  # released_kernel with possible stable updates
>  %if 0%{?stable_base}
>  # This is special because the kernel spec is hell and nothing is consistent
> -xzcat %{SOURCE5000} | patch -p1 -F1 -s
> -git commit -a -m "Stable update"
> +xzcat %{SOURCE5000} | git apply -

if you get rid of '-F1' does that cause it to work? Or if you add '-C1' to
git-apply, does that make it fail?  I am assuming the strict context is the
difference here.

Cheers,
Don

> +git add -A
> +git commit -m "Stable update"
>  %endif
>  
>  # Drop some necessary files from the source dir into the buildroot
> 
> 2) Would it make sense to further gitify the specfile and move from patch to
> "git apply" here (and a few other places)? Or should we expect patch to do the
> right thing? (In the latter case I guess I might have to report a bug against
> patch.)
> 
> Thanks,
> 
> 
> Paul Bolle
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Current specfile misapplies v4.14.10 stable update for fc26

[Don Zickus]

On Tue, Jan 02, 2018 at 05:13:59PM +0100, Paul Bolle wrote:
> On Tue, 2018-01-02 at 09:50 -0500, Don Zickus wrote:
> > On Sat, Dec 30, 2017 at 01:52:49PM +0100, Paul Bolle wrote:
> > > diff --git a/kernel.spec b/kernel.spec
> > > index 965345c2a26e..b2a1ffbe843d 100644
> > > --- a/kernel.spec
> > > +++ b/kernel.spec
> > > @@ -1267,8 +1267,9 @@ fi
> > >  # released_kernel with possible stable updates
> > >  %if 0%{?stable_base}
> > >  # This is special because the kernel spec is hell and nothing is 
> > > consistent
> > > -xzcat %{SOURCE5000} | patch -p1 -F1 -s
> > > -git commit -a -m "Stable update"
> > > +xzcat %{SOURCE5000} | git apply -
> > 
> > if you get rid of '-F1' does that cause it to work?
> 
> No, it still fails.
> 
> > Or if you add '-C1' to git-apply, does that make it fail?
> 
> No, I still get 755 file permissions.
> 
> (Nit: I think '-C2' is the equivalent of patch's '-F1', given the default of
> three lines of context in patches, so I used '-C2'.)

Nevermind.  I was half asleep when I responded and didn't notice it was a
file permissions problem.  Laura fixed it with chmod, which patch doesn't
do. Whereas git-apply can.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

CONFIG name typos?

[Don Zickus]

Hi Laura, Justin,

I stumbled upon these CONFIG names today.  I assume they are wrong?

(full file name in quotes)
configs/fedora/generic/'CONFIG_DEBUG_VM_RB revisit this if performance isn't 
horrible'
configs/fedora/generic/'CONFIG_DPM_WATCHDOG revisit this in debug'


Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: CONFIG name typos?

[Don Zickus]

On Wed, Jan 24, 2018 at 12:26:23AM -0800, Laura Abbott wrote:
> On 01/23/2018 06:26 PM, Don Zickus wrote:
> > Hi Laura, Justin,
> > 
> > I stumbled upon these CONFIG names today.  I assume they are wrong?
> > 
> > (full file name in quotes)
> > configs/fedora/generic/'CONFIG_DEBUG_VM_RB revisit this if performance 
> > isn't horrible'
> > configs/fedora/generic/'CONFIG_DPM_WATCHDOG revisit this in debug'
> > 
> > 
> > Cheers,
> > Don
> > 
> 
> Yes, those are typos from my automatic conversion scripts.
> Feel free to submit a patch to fix/remove them.

Will do.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Fedora kernel workflow feedback

[Don Zickus]

Hi,

For those that don't know me, my name is Don Zickus, a RHEL kernel engineer
for the last decade or so.  I am the group lead of various projects
including the Fedora kernel workflow changes.

I know as Jeremy and Justin have rolled out changes recently there have been
concerns over technical and non-technical issues.  While they are happy to
make various tweaks to the workflow that might have broken during the
conversion, I am asking for some of the bigger concerns, folks reach out to
me.

A couple of years ago, I convinced Laura Abbott and Jeremy to pursue this
workflow change with me and they implemented the pieces to make this work.
Laura even gave a talk about this at Flock in 2019.

I am sure there are pieces we overlooked in our attempt to change the
workflow and over the next few months we will try to address what makes
sense.  I just ask folks to redirect their concerns to me and work with us
to get them resolved.

The two concerns I am aware that need addressing are:
* broken out patches
* handle drive-by users who know dist-git by not the source git tree

Is there any other large concern with the new workflow?

-
Why did we go this way?
* The goal was to create a proper development environment and have
  developers use the Fedora ecosystem to do their work in a natural way and
  easily leverage creating and building rpms, using CI services and any
  other Fedora infrastructure.  IOW make it easier to use Fedora as the
  place to do development.
* Another goal was to respectfully integrate the RHEL kernel workflow
  (_without_ removing Fedora freedoms and liberties) such that our partners
  and customers can contribute to the stability of this kernel in
  preparation for future RHEL kernels.  Increasing focus on Fedora kernel
  was considered a good thing.

The downside of this approach is the impact on those users who prefer a
dist-git world.

The result we have today is what the RHEL development world has looked like
for 10+ years.  Is it perfect? No.  Is there better ways to do things?
Absolutely.

The Fedora kernel is not the only package going in this direction.  Dozens
of other packages are looking to packages like the kernel to see what this
world would look like.  As a leader in this direction, there will be
unforseen bumps that we need to work through.

However, over time, we would like this new source git tree world to be a new
type of standard and the dist-git world a mechanical back-end process.

We understand not everyone will agree with this change, but are hopeful that
we can work with everyone to address the concerns respectfully and still
achieve our goal of having Fedora be the easiest and most natural way to do
upstream development.

Thanks!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Fedora kernel workflow feedback

[Don Zickus]

On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
> Just a quick clarification:
> 
> Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
> > Am 17.04.20 um 20:55 schrieb Don Zickus:
> 
> >> Is there any other large concern with the new workflow?
> > 
> > The more I think about this the more I dislike that we are not using
> > official, pristine tarballs anymore. This "Source0 is a tarball
> > generated from a git tree maintained outside of the Fedora infra and
> > patched with buildscripts" IMHO violates the intention of the SourceURL
> > part of the Fedora Packaging Guidelines that was put in place for good
> > reasons (by both red hat and community contributors):
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
> > 
> > This can be fixed afaics, as it was already discussed in this mail and
> > the answer to it:
> > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/I2JXHKX3P4EIRXGRU7JRY33EBQRCLRI4/#IBRZXHKW72PNN7USTJJHPCQQZJAVOEMD
> > 
> > Yes, it will be some work, but I think it would be wise to do that "to
> > cleanly separate upstream source from vendor modifications" (that's a
> > quote from the guidelines).
> 
> Note: What I wrote might sound like I want to stick to tarballs forever.
> That is not the case, I only would prefer something where all vendor
> modifications are clearly separated from the sources upstream released
> (which was the case for the kernel.spec until a few days ago). IOW: I'm
> totally fine if RPM and/or Dist-Git learn to understand source URLs that
> download sources from a signed tag somehow (say: "Source0:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.7-rc1.tar.gz;
> – which is a bad example, as that is a tarball again, but you get the idea).

Hi knurd,

Thanks for the feedback!  I believe we would like to work out a solution for
this.  But as Jeremy and Laura (in your reference thread) pointed out, there
are multiple ways to solve this.  It comes down to what is a reasonable and
comfortable approach for the community.

Signed tags could work, but they are only applied to releases, not the -rcX
updates.  So there is limitation to that.

Looking through the Fedora Doc you posted, they seem to provide examples of
using a git commit for reference (despite kernel.org using tarballs).  In
essence that is what we are doing, using more of the upstream commit and
generating our own tarball from that commit.

Obviously, the problem comes down to trust.  Just trying to figure out the
most reasonable way to prove we didn't make any mistakes when generating the
tarball using the tools we have available.

Thoughts?

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Fedora kernel workflow feedback

[Don Zickus]

On Thu, Apr 23, 2020 at 07:36:45AM -0400, Prarit Bhargava wrote:
> > Thx.
> > 
> >> For now, I am tracking this issue as
> >> https://gitlab.com/cki-project/kernel-ark/-/issues/28 to not lose it.
> >> Does that work for you?
> > 
> > Yeah, sure, no need to hurry.
> > 
> > BTW: I know, renaming branches is hard, but when you go thought the
> > spaghetti could you please consider renaming the "internal" branch to
> > something more intuitive? I have no better name at hand, but "rpmify" or
> > something like that would make it a lot more obvious what the changes in
> > that branch are about.
> > 
> 
> "os-build" is what I was suggesting.


Haha.  Yes.  That seems to be everyone's top suggestion lately. :-)  I will
see what we can do.  Thanks!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Fedora kernel workflow feedback

[Don Zickus]

On Tue, Apr 21, 2020 at 05:44:14PM +0200, Thorsten Leemhuis wrote:
> Am 20.04.20 um 18:55 schrieb Don Zickus:
> > On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote:
> >> Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis:
> >>> Am 17.04.20 um 20:55 schrieb Don Zickus:
> >>>> Is there any other large concern with the new workflow?
> >>> The more I think about this the more I dislike that we are not using
> >>> official, pristine tarballs anymore. This "Source0 is a tarball
> >>> generated from a git tree maintained outside of the Fedora infra and
> >>> patched with buildscripts" IMHO violates the intention of the SourceURL
> >>> part of the Fedora Packaging Guidelines that was put in place for good
> >>> reasons (by both red hat and community contributors):
> >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
> > […]
> > Thanks for the feedback!  I believe we would like to work out a solution for
> > this. […]> Signed tags could work, but they are only applied to releases, 
> > not the -rcX> updates.  So there is limitation to that.
> > 
> > Looking through the Fedora Doc you posted, they seem to provide examples of
> > using a git commit for reference (despite kernel.org using tarballs).  In
> > essence that is what we are doing, using more of the upstream commit and
> > generating our own tarball from that commit.
> > 
> > Obviously, the problem comes down to trust.  Just trying to figure out the
> > most reasonable way to prove we didn't make any mistakes when generating the
> > tarball using the tools we have available.
> > 
> > Thoughts?
> 
> This overlaps a bit with my reply I just sent to Jeremy  (
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/PZ3ZCUL2WI7ECONM5HNE6QNZMKTO64VR/
> ), nevertheless:
> 
> How about something like this:
> 
> * For Source0 on Rawhide with its daily snapshots use something like this:
> Source0: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-ae83d0b416db002fe95601e7f97f64b59514d936.tar.gz
> (taken from
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae83d0b416db002fe95601e7f97f64b59514d936
> 
> Use something like this everywhere else:
> 
> Source0: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.6.6.tar.gz
> 
> * For rawhide and its daily snapshots just trust what everyone can download 
> at git.kernel.org. Everywhere else verify the signed tag in the %prep section 
> of the spec file just like the packaging guidelines suggest:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures

Hi Knurd,

Thanks for the suggestions!  In order to make this merge happen and satisfy
our goals in the timeframe my management chain was looking for, we hacked the
Fedora and ARK trees together in a rather un-clean way.

Implementing your suggested changes make take a little time to go through
the spaghetti we created.  Let me work with Jeremy and Justin about what is
the best course of action.

For now, I am tracking this issue as
https://gitlab.com/cki-project/kernel-ark/-/issues/28 to not lose it.

Does that work for you?

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Stepping down as Fedora kernel maintainer

[Don Zickus]

On Mon, May 11, 2020 at 10:11:36PM +, Jeremy Cline wrote:
> Hi folks,
> 
> I'm moving on to other things at Red Hat, so I'm stepping down as a
> kernel maintainer. I'm not going very far and I'll still be involved in
> Fedora generally, so you'll still see me around (especially for the
> next few weeks as we complete the transition to the new kernel work-
> flow). I leave you in the very capable hands of Justin, who I'd like to
> thank for putting up with me these last few years.

Thanks Jeremy for all the work you have put in as kernel maintainer and
working with myself and Laura to merge Fedora and ARK.  In addition your
knowledge of all the automation and the email bridge has been amazing and
really moved things forward!

I am happy to hear you will still apply those creative solutions other parts
of Fedora!

Thanks again!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCHv4] redhat: Change Makefile target names to dist-

[Don Zickus]

On Thu, May 14, 2020 at 05:13:27PM -, GitLab Bridge on behalf of prarit 
wrote:
> From: Prarit Bhargava 
> 
> The distribution specific Makefile target names begin with rh-.  Switch
> them to be use the distro agnostic dist-.
> 
> rh-dist-git-test and rh-dist-git are renamed to dist-git-test and
> dist-git.

Acked-by: Don Zickus 

> 
> Signed-off-by: Prarit Bhargava 
> 
> v2: Update to include jcline's newly added docs
> v3: Clean up rh-help and rh-full-help output.  I made all text conform
> to 80 chars.
> ---
>  makefile|   6 +-
>  redhat/Makefile | 281 
>  redhat/Makefile.cross   |  18 +-
>  redhat/configs/README   |   2 +-
>  redhat/configs/editconfig   |   2 +-
>  redhat/configs/evaluate_configs |   2 +-
>  redhat/docs/index.rst   |   8 +-
>  redhat/docs/maintaining.rst |  12 +-
>  redhat/koji/Makefile|   2 +-
>  redhat/koji/kernel.spec |   2 +-
>  redhat/scripts/ci/ark-create-release.sh |   8 +-
>  redhat/scripts/ci/ark-update-configs.sh |   4 +-
>  redhat/scripts/configdiff.sh|   4 +-
>  redhat/scripts/download_cross.sh|   2 +-
>  14 files changed, 182 insertions(+), 171 deletions(-)
> 
> diff --git a/makefile b/makefile
> index 7dc9bcb3267e..819ac9a5cd60 100644
> --- a/makefile
> +++ b/makefile
> @@ -1,4 +1,4 @@
> -ifeq ($(filter rh-% rhg-%,$(MAKECMDGOALS)),)
> +ifeq ($(filter dist-% distg-%,$(MAKECMDGOALS)),)
>   include Makefile
>  endif
>  
> @@ -8,9 +8,9 @@ ifeq ("$(origin O)", "command line")
>_OUTPUT := "$(abspath $(O))"
>_EXTRA_ARGS := O=$(_OUTPUT)
>  endif
> -rh-%::
> +dist-%::
>   $(MAKE) -C redhat $(@) $(_EXTRA_ARGS)
>  
> -rhg-%::
> +distg-%::
>   $(MAKE) -C redhat $(@) $(_EXTRA_ARGS)
>  
> diff --git a/redhat/Makefile b/redhat/Makefile
> index 0118e5b9e2e9..1465469cab95 100644
> --- a/redhat/Makefile
> +++ b/redhat/Makefile
> @@ -57,9 +57,9 @@ KABIDW := $(REDHAT)/kabi-dwarf
>  
>  include Makefile.cross
>  
> -default: rh-help
> +default: dist-help
>  
> -rh-python-check:
> +dist-python-check:
>   @if [ ! -f /usr/libexec/platform-python ]; then \
>   if ! which python3 > /dev/null 2>&1; then \
>   echo "ERROR: Python 3 is needed." ; \
> @@ -71,7 +71,7 @@ rh-python-check:
>   exit 1; \
>   fi
>  
> -rh-kabi: rh-python-check
> +dist-kabi: dist-python-check
>   @for KABIARCH in $(ARCH_LIST); do \
>   $(REDHAT)/kabi/show-kabi -k $(REDHAT)/kabi/kabi-module/ -m \
>   -a $$KABIARCH -r $(RHEL_MAJOR).$(RHEL_MINOR) > 
> $(REDHAT)/kabi/Module.kabi_$$KABIARCH;\
> @@ -83,7 +83,7 @@ rh-kabi: rh-python-check
>   done;
>   @(cd $(REDHAT)/kabi/ && ln -Tsf kabi-rhel$(RHEL_MAJOR)$(RHEL_MINOR) 
> kabi-current)
>  
> -rh-kabi-dup: rh-python-check
> +dist-kabi-dup: dist-python-check
>   @for KABIARCH in $(ARCH_LIST); do \
>   touch $(REDHAT)/kabi/Module.kabi_dup_$$KABIARCH;\
>   if [ -d $(REDHAT)/kabi/kabi-dup-module/kabi_$$KABIARCH ]; then \
> @@ -93,7 +93,7 @@ rh-kabi-dup: rh-python-check
>   fi \
>   done;
>  
> -rh-check-kabi: rh-kabi
> +dist-check-kabi: dist-kabi
>   @if [ ! -e $(_OUTPUT)/Module.symvers ]; then \
>   echo "ERROR: You must compile the kernel and modules first";\
>   exit 1;\
> @@ -101,7 +101,7 @@ rh-check-kabi: rh-kabi
>   @$(REDHAT)/kabi/check-kabi -k $(REDHAT)/kabi/Module.kabi_$(MACH) \
>-s $(_OUTPUT)/Module.symvers
>  
> -rh-check-kabi-dup: rh-kabi-dup
> +dist-check-kabi-dup: dist-kabi-dup
>   @if [ ! -e $(_OUTPUT)/Module.symvers ]; then \
>   echo "ERROR: You must compile the kernel and modules first";\
>   exit 1;\
> @@ -109,18 +109,18 @@ rh-check-kabi-dup: rh-kabi-dup
>   @$(REDHAT)/kabi/check-kabi -k $(REDHAT)/kabi/Module.kabi_dup_$(MACH) \
>   -s $(_OUTPUT)/Module.symvers
>  
> -rh-kabi-dw-base: rh-kabi
> +dist-kabi-dw-base: dist-kabi
>   @echo "Generating baseline dataset for KABI DWARF-based comparison..."
>   @echo " GENERATING DWARF-based kABI baseline dataset "
>   @$(KABIDW)/run_kabi-dw.sh generate \
>   $(REDHAT)/kabi/kabi-current/kabi_whitelist_$(CURARCH) \
>   $(_OUTPUT) $(KABIDW)/base/$(CURARCH)/
>  
> -rh-kabi-dw-check: rh-kabi
> +dist-kabi-dw-check: dist-kabi
>   @if [ ! -d $(KABIDW)/base/$(CURARCH) ]; then \
>   

Re: [OS-BUILD PATCH] Drop the static path configuration for the Sphinx docs

[Don Zickus]

On Mon, May 18, 2020 at 07:42:26PM -, GitLab Bridge on behalf of 
jeremycline wrote:
> From: Jeremy Cline 
> 
> There are no static files at this time. I don't know the first thing
> about CSS and rely on my elders and betters to make the documentation
> look presentable. Configuring a static directory also generates a Sphinx
> warning when it isn't present (which it isn't on clean checkouts because
> it's empty) so just remove it.
> 
> Signed-off-by: Jeremy Cline 
> ---
>  redhat/docs/conf.py | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/redhat/docs/conf.py b/redhat/docs/conf.py
> index b5e60902cd65..d873a31d984d 100644
> --- a/redhat/docs/conf.py
> +++ b/redhat/docs/conf.py
> @@ -40,8 +40,3 @@ html_theme_options = {
>  "show_related": True,
>  "sidebar_collapse": True,
>  }
> -
> -# Add any paths that contain custom static files (such as style sheets) here,
> -# relative to this directory. They are copied after the builtin static files,
> -# so a file named "default.css" will overwrite the builtin "default.css".
> -html_static_path = ["_static"]

I assume you will update the gitlab-ci.yml file in kernel-ark-ci next?

Acked-by: Don Zickus 

> -- 
> 2.26.2
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH] Fix boot hang caused by buggy TPM support in some EFI firmwares

[Don Zickus]

Hi Javier,

We update the fedora kernel process to use a git tree to submit patches now.

Can I ask you to spend a few minutes to read over the new steps

https://cki-project.gitlab.io/kernel-ark/submitting-contributions.html

and resubmit your request as a merge request?

Hopefully after the initial setup, the steps are simple enough.

Thanks in advance!

Cheers,
Don


On Thu, May 14, 2020 at 05:44:56PM +0200, Javier Martinez Canillas wrote:
> ---
>  kernel.spec   |  3 +
>  ...log-version-before-reading-final-eve.patch | 76 +++
>  2 files changed, 79 insertions(+)
>  create mode 100644 tpm-check-event-log-version-before-reading-final-eve.patch
> 
> diff --git a/kernel.spec b/kernel.spec
> index ce66ad47a5b..6ee76a76dbb 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -911,6 +911,9 @@ Patch512: 
> drm-dp_mst-Fix-drm_dp_send_dpcd_write-return-code.patch
>  # CVE-2020-10711 rhbz 1825116 1834778
>  Patch513: net-netlabel-cope-with-NULL-catmap.patch
>  
> +# https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> +Patch514: tpm-check-event-log-version-before-reading-final-eve.patch
> +
>  # END OF PATCH DEFINITIONS
>  
>  %endif
> diff --git a/tpm-check-event-log-version-before-reading-final-eve.patch 
> b/tpm-check-event-log-version-before-reading-final-eve.patch
> new file mode 100644
> index 000..49010406034
> --- /dev/null
> +++ b/tpm-check-event-log-version-before-reading-final-eve.patch
> @@ -0,0 +1,76 @@
> +From  Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Lo=C3=AFc=20Yhuel?= 
> +Date: Tue, 12 May 2020 06:01:13 +0200
> +Subject: [PATCH] tpm: check event log version before reading final events
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +This fixes the boot issues since 5.3 on several Dell models when the TPM
> +is enabled. Depending on the exact grub binary, booting the kernel would
> +freeze early, or just report an error parsing the final events log.
> +
> +We get an event log in the SHA-1 format, which doesn't have a
> +tcg_efi_specid_event_head in the first event, and there is a final events
> +table which doesn't match the crypto agile format.
> +__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
> +either fails, or loops long enough for the machine to be appear frozen.
> +
> +So we now only parse the final events table, which is per the spec always
> +supposed to be in the crypto agile format, when we got a event log in this
> +format.
> +
> +Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
> +Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log 
> in the TCG2 log")
> +Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> +Signed-off-by: Loïc Yhuel 
> +Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yh...@gmail.com
> +Reviewed-by: Javier Martinez Canillas 
> +Reviewed-by: Jerry Snitselaar 
> +Reviewed-by: Matthew Garrett 
> +Signed-off-by: Ard Biesheuvel 
> +---
> + drivers/firmware/efi/libstub/tpm.c | 5 +++--
> + drivers/firmware/efi/tpm.c | 3 ++-
> + 2 files changed, 5 insertions(+), 3 deletions(-)
> +
> +diff --git a/drivers/firmware/efi/libstub/tpm.c 
> b/drivers/firmware/efi/libstub/tpm.c
> +index 1d59e103a2e..e9a684637b7 100644
> +--- a/drivers/firmware/efi/libstub/tpm.c
>  b/drivers/firmware/efi/libstub/tpm.c
> +@@ -54,7 +54,7 @@ void efi_retrieve_tpm2_eventlog(void)
> + efi_status_t status;
> + efi_physical_addr_t log_location = 0, log_last_entry = 0;
> + struct linux_efi_tpm_eventlog *log_tbl = NULL;
> +-struct efi_tcg2_final_events_table *final_events_table;
> ++struct efi_tcg2_final_events_table *final_events_table = NULL;
> + unsigned long first_entry_addr, last_entry_addr;
> + size_t log_size, last_entry_size;
> + efi_bool_t truncated;
> +@@ -127,7 +127,8 @@ void efi_retrieve_tpm2_eventlog(void)
> +  * Figure out whether any events have already been logged to the
> +  * final events structure, and if so how much space they take up
> +  */
> +-final_events_table = get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID);
> ++if (version == EFI_TCG2_EVENT_LOG_FORMAT_TCG_2)
> ++final_events_table = 
> get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID);
> + if (final_events_table && final_events_table->nr_events) {
> + struct tcg_pcr_event2_head *header;
> + int offset;
> +diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> +index 55b031d2c98..77e101a395e 100644
> +--- a/drivers/firmware/efi/tpm.c
>  b/drivers/firmware/efi/tpm.c
> +@@ -62,7 +62,8 @@ int __init efi_tpm_eventlog_init(void)
> + tbl_size = sizeof(*log_tbl) + log_tbl->size;
> + memblock_reserve(efi.tpm_log, tbl_size);
> + 
> +-if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR)
> ++if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR ||
> ++

Re: kernel-ark | Pipeline #145379201 has failed for osnamechange | 1b1d4554 in !354

[Don Zickus]

On Wed, May 13, 2020 at 10:21:31AM -0500, Justin Forbes wrote:
> On Wed, May 13, 2020 at 10:13 AM Prarit Bhargava  wrote:
> >
> > On 5/13/20 10:31 AM, Don Zickus wrote:
> > > On Wed, May 13, 2020 at 07:22:45AM -0400, Prarit Bhargava wrote:
> > >> On 5/13/20 3:50 AM, Jiri Benc wrote:
> > >>> On Tue, 12 May 2020 20:19:09 -0400, Prarit Bhargava wrote:
> > >>>> My patch in merge request 354 changes the names of makefile targets 
> > >>>> from rh-* to
> > >>>> dist-*
> > >>>
> > >>> I haven't seen that patch on kernel@lists.fedoraproject.org. What's
> > >>> going on?
> > >
> > > The piece of the puzzle you are probably missing is:
> > > https://gitlab.com/cki-project/kernel-ark-ci
> > >
> >
> > Thanks.  That's what I was looking for.
> >
> > > which holds the CI scripts.  It is in a separate repo for security reasons
> > > (don't want a kernel change to include modifying the CI scripts to falsely
> > > pass something malicious).
> > >
> > > However, that split leads to the scenario you are in, how to update both 
> > > at
> > > the same time, which we were trying to avoid again for security reasons
> > > (always want to use either a tag or head of master, not a custom branch 
> > > for
> > > the CI scripts).
> > >
> > > We may have to create a transition patch to handle this.  Unfortunately 
> > > you
> > > hit this scenario sooner than we were expecting to deal with it. :-(
> >
> > Heh :)  Of course it's my fault :) :)
> >
> > How about these steps?
> >
> > 1) I patch to add the dist-* targets and keep the old rh-* targets 
> > temporarily.
> > This patch will be messy unless someone has some  Makefile-fu.
> > 2) I modify the kernel-ark-ci scripts to use the dist-* targets.
> > 3) I patch to remove the old rh-* targets which will result in an overall 
> > clean
> > patch.

That was the approach I was thinking of too.

> >
> > Would that work for everyone?
> >
> This seems unnecessarily messy. Why not modify the CI scripts to check
> both and as long as at least one of them passes, CI passes?

That is another way.  But is there any value to leaving the rh- stuff in the
scripts?  Unless we want to preserve legacy like rhel-7/8.

I don't mind either way.  I would like to preserve the idea that for
security reasons the code and the ci rules are split and updated
asynchronously.  I think both approaches respect that idea.

Now ARK/Fedora CI scripts don't really necessitate a split other than the
branching scheme we use.  But when CentOS-stream ramps up later this year,
more rules and resources get involved and the security from the separation
becomes stronger.  So practicing now helps test out a solution.

Hopefully that makes sense!

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: kernel-ark | Pipeline #145379201 has failed for osnamechange | 1b1d4554 in !354

[Don Zickus]

On Wed, May 13, 2020 at 07:22:45AM -0400, Prarit Bhargava wrote:
> On 5/13/20 3:50 AM, Jiri Benc wrote:
> > On Tue, 12 May 2020 20:19:09 -0400, Prarit Bhargava wrote:
> >> My patch in merge request 354 changes the names of makefile targets from 
> >> rh-* to
> >> dist-*
> > 
> > I haven't seen that patch on kernel@lists.fedoraproject.org. What's
> > going on?

The piece of the puzzle you are probably missing is:
https://gitlab.com/cki-project/kernel-ark-ci

which holds the CI scripts.  It is in a separate repo for security reasons
(don't want a kernel change to include modifying the CI scripts to falsely
pass something malicious).

However, that split leads to the scenario you are in, how to update both at
the same time, which we were trying to avoid again for security reasons
(always want to use either a tag or head of master, not a custom branch for
the CI scripts).

We may have to create a transition patch to handle this.  Unfortunately you
hit this scenario sooner than we were expecting to deal with it. :-(

Cheers,
Don

> > 
> 
> jbenc,
> 
> My patch will be posted only after it passes CKI by the bridge.  I'm using the
> suggested kernel-ark wiki procedure at
> 
> https://gitlab.com/cki-project/kernel-ark/-/wikis/Contributor-guide
> 
> You can see my patch here
> 
> https://gitlab.com/prarit/kernel-ark/-/commit/1b1d4554fc1b7f76a690fe9255ad75609e9ffe25
> 
> The patch fails CKI because first test builds an srpm using 'make rh-srpm'.  
> My
> patch changes all the rh-* makefile target names from rh-* to dist-*, which
> breaks the CKI test because 'rh-srpm' is not longer a makefile target.
> 
> IOW this is a chicken-and-egg problem and I'm not sure how get around it.
> 
> P.
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Building custom kernel from src.rpm fails for kernel 5.7

[Don Zickus]

On Mon, May 11, 2020 at 09:52:43AM -0700, stan wrote:
> On Mon, 11 May 2020 09:44:54 -0700
> stan  wrote:
> 
> > On Mon, 11 May 2020 11:30:26 -0500
> > Justin Forbes  wrote:
> > 
> > > when building the kernel with multiple threads, it is entirely
> > > possible that the failure happens in one thread, but the remaining
> > > threads make noise while they continue their current task. The error
> > > can end up a good bit higher in the build log. It is best to look
> > > through the entire log.  The current 5.7 kernels do have some
> > > changes to support GCC 10, but they should continue to build fine
> > > on F31 as well, and the ELN builds of these kernels are doing
> > > headers and tools as well, so the spec should be working with that
> > > now.  
> > 
> > Thank you, I'll look into that.
> 
> This is the actual error.
> 
> arch/x86/kernel/setup.c: In function 'rh_check_supported':
> arch/x86/kernel/setup.c:824:11: error: 'x86_hyper_type' undeclared (first use 
> in this function); did you mean 'x86_hyper_init'?
>   824 |  guest = (x86_hyper_type != X86_HYPER_NATIVE || 
> boot_cpu_has(X86_FEATURE_HYPERVISOR));
>   |   ^~
>   |   x86_hyper_init
> arch/x86/kernel/setup.c:824:11: note: each undeclared identifier is reported 
> only once for each function it appears in
> At top level:
> arch/x86/kernel/setup.c:820:13: warning: 'rh_check_supported' defined but not 
> used [-Wunused-function]
>   820 | static void rh_check_supported(void)
>   | ^~
> make[2]: *** [scripts/Makefile.build:267: arch/x86/kernel/setup.o] Error 1
> make[1]: *** [scripts/Makefile.build:488: arch/x86/kernel] Error 2
> make: *** [Makefile:1732: arch/x86] Error 2
> make: *** Waiting for unfinished jobs

Odd, the ELN build didn't fail for that reason.

You should able to wrap rh_check_supported() with 

#ifdef CONFIG_RHEL_DIFFERENCES
...
#endif

(as I am pretty sure your config has the disabled)

OR

s/x86_hyper_type != X86_HYPER_NATIVE/!hypervisor_is_type(X86_HYPER_NATIVE)/


More fallout quirks.  Thanks for your patience!

In theory, an ELN build should have failed, someone noticed it was related
to a specific RH patch, we revert it temporarily until it is fixed and then
re-apply.  Still some kinks.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCHv3] Add git config hook

[Don Zickus]

On Wed, May 06, 2020 at 01:45:34PM +0200, Jiri Benc wrote:
> On Wed, 6 May 2020 07:37:35 -0400, Prarit Bhargava wrote:
> > Good idea and I think it would be a smart thing to do.
> 
> I generally agree but I don't think "ark" is the best option. The
> kernels are used for Fedora, too, and they will be used for RHEL. We
> should find a prefix that works for all of those kernels/distros.
> I was trying to think of something but I could not find anything
> suitable. It should be short (rules out "downstream") and easily
> remembered (rules out abbreviations for "downstream").

I had the same opinion.  As we migrated the redhat/ over directly from RHEL,
it is very much polluted with RHELisms.  I am happy to clean up the
RHELisms, I would like to use a generic term that covers
Fedora/CentOS-stream/RHEL/ARK.

I had thoughts of using 'distro' and using that as a generic framework to
push upstream for other distros to plug into, but I never fully flushed out
that idea (ie s/redhat\//distro\//;s/rh-/distro-/).

Though 'distro' is a tad cumbersome.  'os' may work as it is short enough
(using Prarit's suggestion) but is it intuitively descriptive enough?

Thoughts?

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCHv3] Add git config hook

[Don Zickus]

On Fri, May 08, 2020 at 12:50:13PM -0400, Prarit Bhargava wrote:
> On 5/7/20 7:32 PM, Prarit Bhargava wrote:
> > On 5/6/20 3:55 PM, Jeremy Cline wrote:
> >> On Wed, May 06, 2020 at 09:44:55AM -0400, Don Zickus wrote:
> >>> On Wed, May 06, 2020 at 01:45:34PM +0200, Jiri Benc wrote:
> >>>> On Wed, 6 May 2020 07:37:35 -0400, Prarit Bhargava wrote:
> >>>>> Good idea and I think it would be a smart thing to do.
> >>>>
> >>>> I generally agree but I don't think "ark" is the best option. The
> >>>> kernels are used for Fedora, too, and they will be used for RHEL. We
> >>>> should find a prefix that works for all of those kernels/distros.
> >>>> I was trying to think of something but I could not find anything
> >>>> suitable. It should be short (rules out "downstream") and easily
> >>>> remembered (rules out abbreviations for "downstream").
> >>>
> >>> I had the same opinion.  As we migrated the redhat/ over directly from 
> >>> RHEL,
> >>> it is very much polluted with RHELisms.  I am happy to clean up the
> >>> RHELisms, I would like to use a generic term that covers
> >>> Fedora/CentOS-stream/RHEL/ARK.
> >>>
> >>> I had thoughts of using 'distro' and using that as a generic framework to
> >>> push upstream for other distros to plug into, but I never fully flushed 
> >>> out
> >>> that idea (ie s/redhat\//distro\//;s/rh-/distro-/).
> >>>
> >>> Though 'distro' is a tad cumbersome.  'os' may work as it is short enough
> >>> (using Prarit's suggestion) but is it intuitively descriptive enough?
> >>>
> >>
> >> 'dist'? I like the shortness of os, but as you say it's not super
> >> descriptive. I don't have strong feelings either way, though.
> > 
> > dist would work too.  jbenc?  dzickus?  Anyone else before I push a patch?
> > 
> 
> Since there isn't a strenuous objection to 'os' (although I do like 'dist' 
> too),
> I'm going to go with 'os' for the sake of brevity.

I will throw my hat in the ring for 'dist' over 'os'.

Cheers,
Don
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCHv2 0/2] Fix 'make scripts' for kernel-devel package

[Don Zickus]

On Tue, May 19, 2020 at 07:35:30PM -, GitLab Bridge on behalf of masneyb 
wrote:
> From: masneyb on gitlab.com
> 
> This merge request contains two patches from the RHEL kernel:
> 
> - One to fix the 'make scripts' functionality in the kernel-devel
> package. Once the patch https://src.fedoraproject.org/rpms/kernel/c/a443
> bcbf915cc5797ae3d950ee6c26b71e57e92e?branch=master is merged into the
> ARK kernel, then 'make scripts' will work properly.
> 
> - A minor patch to fix the help text for rh-cross--rpms in 'make
> rh-full-help'
> 
> I didn't make these separate merge requests to avoid conflicts between
> the two patches since both touch the spec file.

Acked-by: Don Zickus 

> 
> Signed-off-by: Brian Masney 
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH] Fix boot hang caused by buggy TPM support in some EFI firmwares

[Don Zickus]

On Mon, May 18, 2020 at 05:19:12PM -0500, Justin Forbes wrote:
> On Mon, May 18, 2020 at 3:48 PM Don Zickus  wrote:
> 
> > Hi Javier,
> >
> > We update the fedora kernel process to use a git tree to submit patches
> > now.
> >
> 
> This was a request for stable, which doesn't follow this process.  Javier
> asked before he sent it here.  It has been added and included in the 5.6.13
> builds.

Sorry about that Javier!  Thanks for explaining that to me Justin.

Cheers,
Don

> 
> Justin
> 
> 
> >
> > Can I ask you to spend a few minutes to read over the new steps
> >
> > https://cki-project.gitlab.io/kernel-ark/submitting-contributions.html
> >
> > and resubmit your request as a merge request?
> >
> > Hopefully after the initial setup, the steps are simple enough.
> >
> > Thanks in advance!
> >
> > Cheers,
> > Don
> >
> >
> > On Thu, May 14, 2020 at 05:44:56PM +0200, Javier Martinez Canillas wrote:
> > > ---
> > >  kernel.spec   |  3 +
> > >  ...log-version-before-reading-final-eve.patch | 76 +++
> > >  2 files changed, 79 insertions(+)
> > >  create mode 100644
> > tpm-check-event-log-version-before-reading-final-eve.patch
> > >
> > > diff --git a/kernel.spec b/kernel.spec
> > > index ce66ad47a5b..6ee76a76dbb 100644
> > > --- a/kernel.spec
> > > +++ b/kernel.spec
> > > @@ -911,6 +911,9 @@ Patch512:
> > drm-dp_mst-Fix-drm_dp_send_dpcd_write-return-code.patch
> > >  # CVE-2020-10711 rhbz 1825116 1834778
> > >  Patch513: net-netlabel-cope-with-NULL-catmap.patch
> > >
> > > +# https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> > > +Patch514: tpm-check-event-log-version-before-reading-final-eve.patch
> > > +
> > >  # END OF PATCH DEFINITIONS
> > >
> > >  %endif
> > > diff --git a/tpm-check-event-log-version-before-reading-final-eve.patch
> > b/tpm-check-event-log-version-before-reading-final-eve.patch
> > > new file mode 100644
> > > index 000..49010406034
> > > --- /dev/null
> > > +++ b/tpm-check-event-log-version-before-reading-final-eve.patch
> > > @@ -0,0 +1,76 @@
> > > +From  Mon Sep 17 00:00:00 2001
> > > +From: =?UTF-8?q?Lo=C3=AFc=20Yhuel?= 
> > > +Date: Tue, 12 May 2020 06:01:13 +0200
> > > +Subject: [PATCH] tpm: check event log version before reading final
> > events
> > > +MIME-Version: 1.0
> > > +Content-Type: text/plain; charset=UTF-8
> > > +Content-Transfer-Encoding: 8bit
> > > +
> > > +This fixes the boot issues since 5.3 on several Dell models when the TPM
> > > +is enabled. Depending on the exact grub binary, booting the kernel would
> > > +freeze early, or just report an error parsing the final events log.
> > > +
> > > +We get an event log in the SHA-1 format, which doesn't have a
> > > +tcg_efi_specid_event_head in the first event, and there is a final
> > events
> > > +table which doesn't match the crypto agile format.
> > > +__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
> > > +either fails, or loops long enough for the machine to be appear frozen.
> > > +
> > > +So we now only parse the final events table, which is per the spec
> > always
> > > +supposed to be in the crypto agile format, when we got a event log in
> > this
> > > +format.
> > > +
> > > +Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
> > > +Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event
> > log in the TCG2 log")
> > > +Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> > > +Signed-off-by: Loïc Yhuel 
> > > +Link:
> > https://lore.kernel.org/r/20200512040113.277768-1-loic.yh...@gmail.com
> > > +Reviewed-by: Javier Martinez Canillas 
> > > +Reviewed-by: Jerry Snitselaar 
> > > +Reviewed-by: Matthew Garrett 
> > > +Signed-off-by: Ard Biesheuvel 
> > > +---
> > > + drivers/firmware/efi/libstub/tpm.c | 5 +++--
> > > + drivers/firmware/efi/tpm.c | 3 ++-
> > > + 2 files changed, 5 insertions(+), 3 deletions(-)
> > > +
> > > +diff --git a/drivers/firmware/efi/libstub/tpm.c
> > b/drivers/firmware/efi/libstub/tpm.c
> > > +index 1d59e103a2e..e9a684637b7 100644
> > > +--- a/drivers/firmware/efi/libstub/tpm.c
> 

Re: [OS-BUILD PATCH] configs/aarch64: Fix CONFIG_FORCE_MAX_ZONEORDER

[Don Zickus]

On Tue, May 19, 2020 at 01:47:09PM -, GitLab Bridge on behalf of prarit 
wrote:
> From: Prarit Bhargava 
> 
> The internal make command 'make rh-brew'/'make dist-brew' is failing with
> 
> Processing 
> /home/prarit/git-kernel/kernel-ark/redhat/configs/kernel-aarch64-debug-fedora.config
>  ... Error: Mismatches found in configuration files
> Found CONFIG_FORCE_MAX_ZONEORDER=11 after generation, had 
> CONFIG_FORCE_MAX_ZONEORDER=13 in Source tree
> 
> ARK commit f5ca593e1c2e ("configs: Adjust CONFIG_FORCE_MAX_ZONEORDER for
> Fedora") set this to 11, and follow-on ARK commit dd028d261347 ("[redhat]
> Sync up ARK's Fedora config tree with Fedora's dist-git") erroneously
> overwrote the value back to 13.
> 
> Set CONFIG_FORCE_MAX_ZONEORDER back to 11 for aarch64.

This works for os-build but fails for ark-latest because there is a patch in
ark-patches that changes the default to 13.

The problem is we tried to keep the redhat/ changes separate from the
redhat/fedora only patches in ark-patches.  The goal was os-build could
build standalone and the combination of ark-patches into ark-latest could
build standalone.

Because of that arm64 change of the default to 13, we broke the os-build
standalone build.  And because the ark-patches does not have the redhat/
area, we can't make config changes on that branch.

Hence the problem and why it hasn't been solved yet.  It is annoying and I
would love to fix it, but this solution just moves the breakage from
os-build to ark-latest. :-(

Therefore,

Nacked-by: Don Zickus 

> 
> Fixes: dd028d261347 ("[redhat] Sync up ARK's Fedora config tree with Fedora's 
> dist-git")
> Signed-off-by: Prarit Bhargava 
> Cc: ho...@redhat.com
> Cc: jcl...@redhat.com
> ---
>  .../fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER 
> b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> index b730690db048..8220d67904ea 100644
> --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> @@ -1,4 +1,4 @@
>  # We technically want this to be 13 for Fedora with 4K pages but that's only
>  # an option with an out of tree patch. Keep this 11 for compatibility until
>  # we figure out what we want here
> -CONFIG_FORCE_MAX_ZONEORDER=13
> +CONFIG_FORCE_MAX_ZONEORDER=11
> -- 
> 2.26.2
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCH] configs/aarch64: Fix CONFIG_FORCE_MAX_ZONEORDER

[Don Zickus]

+ Mark S.

On Tue, May 19, 2020 at 04:34:50PM +0100, Peter Robinson wrote:
> > From: Prarit Bhargava 
> >
> > The internal make command 'make rh-brew'/'make dist-brew' is failing with
> >
> > Processing 
> > /home/prarit/git-kernel/kernel-ark/redhat/configs/kernel-aarch64-debug-fedora.config
> >  ... Error: Mismatches found in configuration files
> > Found CONFIG_FORCE_MAX_ZONEORDER=11 after generation, had 
> > CONFIG_FORCE_MAX_ZONEORDER=13 in Source tree
> >
> > ARK commit f5ca593e1c2e ("configs: Adjust CONFIG_FORCE_MAX_ZONEORDER for
> > Fedora") set this to 11, and follow-on ARK commit dd028d261347 ("[redhat]
> > Sync up ARK's Fedora config tree with Fedora's dist-git") erroneously
> > overwrote the value back to 13.
> >
> > Set CONFIG_FORCE_MAX_ZONEORDER back to 11 for aarch64.
> 
> For reference the reason we have this disparity goes back to why
> Fedora doesn't have 64K page sizes for aarch64. The reason is because
> with 64K pages it makes CMA 512Mb rather than the 64Mb (which I think
> can actually be 16) we have with 4K pages. I seem to remember its
> something to do with CMA using large pages and with 64K page sizes
> that makes the smallest large page to be 512Mb.
> 
> Losing 512Mb is obviously fatal on devices with small amounts of RAM
> like a bunch of the SBCs we support on Fedora so to support SBCs we
> had to move to 4K pages until we got a proper fix for this. Related it
> actually also affects RHEL for things like AWS images with small
> amounts of memory so I suspect it would be useful to be fixed in the
> RHEL use case too.

Thanks Peter for the context!

Mark should we enable this for ARK / RHEL-9?

> 
> Peter
> 
> > Fixes: dd028d261347 ("[redhat] Sync up ARK's Fedora config tree with 
> > Fedora's dist-git")
> > Signed-off-by: Prarit Bhargava 
> > Cc: ho...@redhat.com
> > Cc: jcl...@redhat.com
> > ---
> >  .../fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER   | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git 
> > a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER 
> > b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> > index b730690db048..8220d67904ea 100644
> > --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> > +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> > @@ -1,4 +1,4 @@
> >  # We technically want this to be 13 for Fedora with 4K pages but that's 
> > only
> >  # an option with an out of tree patch. Keep this 11 for compatibility until
> >  # we figure out what we want here
> > -CONFIG_FORCE_MAX_ZONEORDER=13
> > +CONFIG_FORCE_MAX_ZONEORDER=11
> > --
> > 2.26.2
> > ___
> > kernel mailing list -- kernel@lists.fedoraproject.org
> > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCH] configs/aarch64: Fix CONFIG_FORCE_MAX_ZONEORDER

[Don Zickus]

On Tue, May 19, 2020 at 10:33:52AM -0400, Don Zickus wrote:
> On Tue, May 19, 2020 at 01:47:09PM -, GitLab Bridge on behalf of prarit 
> wrote:
> > From: Prarit Bhargava 
> > 
> > The internal make command 'make rh-brew'/'make dist-brew' is failing with
> > 
> > Processing 
> > /home/prarit/git-kernel/kernel-ark/redhat/configs/kernel-aarch64-debug-fedora.config
> >  ... Error: Mismatches found in configuration files
> > Found CONFIG_FORCE_MAX_ZONEORDER=11 after generation, had 
> > CONFIG_FORCE_MAX_ZONEORDER=13 in Source tree
> > 
> > ARK commit f5ca593e1c2e ("configs: Adjust CONFIG_FORCE_MAX_ZONEORDER for
> > Fedora") set this to 11, and follow-on ARK commit dd028d261347 ("[redhat]
> > Sync up ARK's Fedora config tree with Fedora's dist-git") erroneously
> > overwrote the value back to 13.
> > 
> > Set CONFIG_FORCE_MAX_ZONEORDER back to 11 for aarch64.
> 
> This works for os-build but fails for ark-latest because there is a patch in
> ark-patches that changes the default to 13.
> 
> The problem is we tried to keep the redhat/ changes separate from the
> redhat/fedora only patches in ark-patches.  The goal was os-build could
> build standalone and the combination of ark-patches into ark-latest could
> build standalone.
> 
> Because of that arm64 change of the default to 13, we broke the os-build
> standalone build.  And because the ark-patches does not have the redhat/
> area, we can't make config changes on that branch.

I forgot to point out the patch that causes this:
(git log -p origin/master..origin/ark-patches arch/arm64)


commit df97e71c24526cabc6a434d9f35ef493056b1bcf
Author: Peter Robinson 
Date:   Wed Feb 26 13:38:40 2020 -0500

Add option of 13 for FORCE_MAX_ZONEORDER

This is a hack, but it's what the other distros currently use
for aarch64 with 4K pages so we'll do the same while upstream
decides what the best outcome is (which isn't this).

Upstream Status: RHEL only
Signed-off-by: Peter Robinson 
[Add a dependency on RHEL_DIFFERENCES]
Signed-off-by: Jeremy Cline 

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9e87f5847c92..f57bee916600 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1125,6 +1125,7 @@ config XEN
 config FORCE_MAX_ZONEORDER
int
default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
+   default "13" if (ARCH_THUNDER && !ARM64_64K_PAGES && !RHEL_DIFFERENCES)
default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
default "11"
    help


> 
> Hence the problem and why it hasn't been solved yet.  It is annoying and I
> would love to fix it, but this solution just moves the breakage from
> os-build to ark-latest. :-(
> 
> Therefore,
> 
> Nacked-by: Don Zickus 
> 
> > 
> > Fixes: dd028d261347 ("[redhat] Sync up ARK's Fedora config tree with 
> > Fedora's dist-git")
> > Signed-off-by: Prarit Bhargava 
> > Cc: ho...@redhat.com
> > Cc: jcl...@redhat.com
> > ---
> >  .../fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER   | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git 
> > a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER 
> > b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> > index b730690db048..8220d67904ea 100644
> > --- a/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> > +++ b/redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER
> > @@ -1,4 +1,4 @@
> >  # We technically want this to be 13 for Fedora with 4K pages but that's 
> > only
> >  # an option with an out of tree patch. Keep this 11 for compatibility until
> >  # we figure out what we want here
> > -CONFIG_FORCE_MAX_ZONEORDER=13
> > +CONFIG_FORCE_MAX_ZONEORDER=11
> > -- 
> > 2.26.2
> > ___
> > kernel mailing list -- kernel@lists.fedoraproject.org
> > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCH 1/2] Makefile: correct help text for rh-cross--rpms

[Don Zickus]

On Tue, May 19, 2020 at 06:35:37PM -, GitLab Bridge on behalf of masneyb 
wrote:
> From: Brian Masney 
> 
> Upstream Status: RHEL only
> 
> The rh-full-help target shows the target rh-cross--rpm, however
> it's really rh-cross--rpms. Let's go ahead and correct the help
> text.

Justin just merged Prarit's patch which changes all 'rh-' stuff to 'dist-'.
Can you fetch and rebase on top of that?

Cheers,
Don

> 
> Signed-off-by: Brian Masney 
> ---
>  redhat/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/redhat/Makefile b/redhat/Makefile
> index 0118e5b9e2e9..ddf1a0f1b9d8 100644
> --- a/redhat/Makefile
> +++ b/redhat/Makefile
> @@ -422,7 +422,7 @@ rh-full-help:
>   $$(sed -n 's/.*--target \([^ ]*\).*/\1/p' Makefile.cross | sort 
> -u)
>   @echo  '  rh-cross-all-rpms - [x86_64 only] execute rpm builds for 
> all supported'
>   @echo  '  archs using RHEL cross compiler.'
> - @echo  '  rh-cross--rpm   - [x86_64 only] execute rpm builds for 
> specified'
> + @echo  '  rh-cross--rpms  - [x86_64 only] execute rpm builds for 
> specified'
>   @echo  '   using RHEL cross compiler.'
>   @echo  '  See rh-cross--build for the 
> supported archs.'
>  
> -- 
> 2.26.2
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCH] Add Documentation back to kernel-devel as it has Kconfig now

[Don Zickus]

On Tue, May 19, 2020 at 06:28:26PM -, GitLab Bridge on behalf of jmflinuxtx 
wrote:
> From: "Justin M. Forbes" 
> 
> This was fixed in Fedora back in January, and then got dropped in the
> ARK switch over for some reason.  Kernel-devel needs
> Documentation/Kconfig.

Acked-by: Don Zickus 

> 
> rhbz 1789641
> 
> Signed-off-by: Justin M. Forbes 
> ---
>  redhat/kernel.spec.template | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
> index 836fe8cb6af9..04f146e5a76c 100644
> --- a/redhat/kernel.spec.template
> +++ b/redhat/kernel.spec.template
> @@ -1594,7 +1594,6 @@ BuildKernel() {
>  %endif
>  
>  # then drop all but the needed Makefiles/Kconfig files
> -rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/Documentation
>  rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts
>  rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
>  cp .config $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
> -- 
> 2.26.2
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

test - please ignore

[Don Zickus]

Just testing out the bot.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [OS-BUILD PATCH] kernel.spec: don't override upstream compiler flags for ppc64le

[Don Zickus]

On Mon, Sep 07, 2020 at 03:06:52PM -, GitLab Bridge on behalf of sharkcz 
wrote:
> From: =?UTF-8?q?Dan=20Hor=C3=A1k?= 
> 
> Related: rhbz#1866485

Acked-by: Don Zickus 

> 
> Signed-off-by: Dan Horák 
> ---
>  redhat/kernel.spec.template | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
> index d47c9cce8a0e..f29f6ad56f93 100644
> --- a/redhat/kernel.spec.template
> +++ b/redhat/kernel.spec.template
> @@ -353,7 +353,6 @@ Summary: The Linux kernel
>  %define kernel_image vmlinux
>  %define kernel_image_elf 1
>  %define all_arch_configs kernel-%{version}-ppc64le*.config
> -%define kcflags -O3
>  %endif
>  
>  %ifarch s390x
> -- 
> GitLab
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org