I understand the use case, I'm still not super keen on having official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real live code is actually on a branch.
Surely all previous
Downloading linux-2.6.31.tar.bz2...
That is the make sources part. Just try it again.
IIRC it just runs curl from some fedoraproject.org site.
So if that is hanging, then talk to the Fedora infrastructure folks.
___
Fedora-kernel-list mailing list
$ make git/utrace/prep
it hung here witout any output
No such problem for me. Look with ps what is hanging. Note that since
this weekend Fedora pkgs checkouts using cvs.fedora.redhat.com no longer
work and cvs will tend to hang for a long time if you use them. Try a
fresh checkout being sure
That is job control weirdness. Something about the state of tty magic is
different in the two different contexts where you run the test. The things
to look at are whether the tests are using a temporary pty and what 'ps j'
says about all the processes involved in the build/test (including mock
Unfortunately that level of magic is mostly beyond me.
That's OK. We can translate for you.
RM The things to look at are whether the tests are using a
RM temporary pty
I do not really know how to determine that.
The TTY column in ps is a start.
However, it simplifies things to know
Another data point for this thread:
x86 is unlike other architectures because 64-bit also has twice as many
registers as 32-bit. So you get to trade off the benefits of register
allocation across more registers against the memory/cache footprint of
64-bit pointers.
--
fedora-devel-list
It's certainly possible that users will rsync the Everything tree, but they
won't be able to do much with it. Is that the usecase you're worried about?
I just rsync'd it from my mirror of choice (kernel.org) and was very glad
to get it releases/12/Everything quickly populated with hard links
It sounds like you are saying that there is no way to export the same
host filesystems with the same client-perceived names under v4 as was
being done before under v[23]. Is that really true?
My old /etc/exports is:
/mirror*(ro,insecure,sync,mp,all_squash)
So clients
But with with older releases I don't messing with people configuration
files since I would not want to break an existing configuration...
Still never suggested that.
Note, there is a number of people who are currently running with
correctly configured v4 server... I would hate to mess
Of course. So push an F-11 update where whatever configuration never
mentions v4 and doesn't work for v4, doesn't advertise v4.
Not sure how I would do this without the update being called a
regression... any update that disables features does not seem
like a good thing...
I described
At the least, there ought to be an F-11 update of whatever server-side
stuff needs to change (in the minimal way not touching non-v4 uses) to
make v4 exports work without temporary configuration hacks. IMHO if you
can't do anything better, you should make F-11 default to not registering
as a v4
That is one of the valid options, but I would think it would better if
the server owner did that tweak, than an nfs-utils update, no?
I'm not suggesting that you do an update that just tweaks config files in
%post or anything like that. I'm suggesting you make the out-of-the-box
behavior with
If it's true cross support, then that should be a noarch package and the
file names it uses should not depend on %{_lib} that way.
Arguably it even belongs in %{_sharedir}, since it is fixed binary content
across all host machines.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
On Thu, Sep 17, 2009 at 09:31:52PM +0200, Jakub Jelinek wrote:
I've noticed the dot in front of the symbol, is kernel using still the for
years deprecated oldish ppc64 ABI instead of the new one (i.e. uses
-mcall-aixdesc instead of not using this option at all)? Maybe it is broken
only
This is an interesting question. I'd hate to think that something being
unable to be included because of technical reasons would cause us to be
unable to call something Fedora.
Well, I think it's more or less whatever works. That is, we require
the various kernel features that the rest of
If we tracked the results of the build process independently of the RPM
itself, we could track much more complicated relationships between
packages (for example, the kernel borrowing bits of the output from the
last glibc build to make its initrd).
Koji's database has that information, sort
Yes, but I do not think we are in good faith satisfying the requirement
to distribute the source for those binaries by pointing back to koji
pages and possibly forcing the user to dig into the lookaside cache.
The requirement is to provide a written offer to give someone the source
when
So that's where I get clobbered. Need to figure out why, but at least I
solved the watch location question.
Yes. Sorry I disappeared there for a bit talking to compiler people about
whether there is a method other than reading the disassembly to find it.
I think there isn't, but I'll see
I agree with Jeff here. Sorry, Jim. I know life is too complicated to
keep track of, but that's just how it is. A robustly-written application
really needs to distinguish the build-time vs runtime dependencies it has.
If you want to make an assumption at run time, then you really have to make
-pthread means -D_REENTRANT and -lpthread. -D_REENTRANT is basically
useless and you should use standard feature test macros or _GNU_SOURCE for
what you want. So just linking with -lpthread is what I would call the
normal and recommended practice.
The man pages are not maintained by people
IMHO koji (and mock for that matter) ought to be running the builds inside
a captive pty whose ouytput it logs anyway, even if they redirect
everything. You never know what crazy nonsense some package is going to try.
You can put LIBC_FATAL_STDERR_=1 in the environment to get those messages
to
How does one setup one of these things?
Since I assume you are implementing it in Python, you might have to ask,
you know, someone who knows Python. I don't, but I have a web browser.
I even have locate '*python*pty*'. So maybe:
import pty
(pid, fd) = pty.fork()
or pty.spawn(...)
--
From build log:
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id
/builddir/build/BUILD/spambayes-1.0.4
find: `debug': No such file or directory
At first glance this appears to be a problem with the debuginfo
script. Is this a known issue?
It should not even be run on a noarch build, I
It sounds like something that looks at an SELinux policy's rules for SECMARK
and generates corresponding iptables rules would amount to the same thing
you have in mind. Since you load new SELinux policy in a big static-switch
sort of way, it doesn't seem much different in a way you could discern
I don't think I explained it well. I was thinking what if you had this rule:
-A INPUT -Z cups_t -j ACCEPT
and then cups was compromised and started listening on port 80. Since the
above rule has no port restrictions and cups is allowed to accept
connections,
would cups now be able to
So I think most of us in this discussion probably don't actually understand
SECMARK. I sure didn't. I think I might now, sort of. The SELinux policy
just says contexts, and it doesn't say anything about the port numbers.
The point of SECMARK is that you write port-matching rules that are what
/home on this system is a symlink to /disk/data/home, and %_topdir was
/home/beorn/rpm. This caused debuginfo packages without sources, where the
.debug files referenced the sources in the build directory. After I changed
%_topdir to /disk/data/home/beorn/rpm the debuginfo packages seem
You actually want overlap for a while so that when rsyncing you can use
hardlinks instead of having to redownload files you already have.
This is going to be more relevant if koji signing happens and packages don't
get different signatures depending on which repo they are in.
That would be
Releases prior to F-11 wouldn't benefit from that at all, as the RPMs
actually change when going from updates-testing to updates due to being
signed with different keys.
I think it still helps a lot with rsync. The old .all/* files are there to
be seen as almost the same and get rsync
I reproduced what jwb reported on the powerstation.
Mine is with F10 + updates userland, only the kernel seems to matter.
The test case is:
# modprobe iscsi_tcp
Illegal Instruction
#
On -16[278], same oops that jwb saw, wrong text appearing at a page boundary.
This
Great. I ended up having lots of other issues with vanilla build. At
some point during the build, the make oldconfig becomes interactive
during the %install phase.
%install?? Weird. That should not be happening. Maybe a V=1 on the make
command would make kbuild explain why it decided
You should always specify an arch.
make prep uses noarch and generally works fine. You can just ignore the
strange assembler messages in the 'make configs' phase and the .config
files come out fine, in my experience.
___
Fedora-kernel-list mailing
- Should we be using the PAE kernel *regardless* of memory size (as
implied above) or do we want some memory requirements?
It's always preferable on hardware (where pae actually works) that also has
the nx cpu feature. True PROT_EXEC enforcement (NX) is only available in
PAE mode.
Thanks,
Patch below seems to dtrt.. comments?
Why kill the configs, instead of just changing the spec settings?
@@ -1477,7 +1481,9 @@ mkdir -p $RPM_BUILD_ROOT/boot
cd linux-%{kversion}.%{_target_cpu}
%if %{with_debug}
+%ifnarch i686
BuildKernel %make_target %kernel_image debug
+%endif
%if
git://fedorapeople.org/git/$user/$repo.git
instead of:
git://fedorapeople.org/home/fedora/$user/public_git/$repo.git
You can already use:
git://fedorapeople.org/git/~$user/$repo.git
___
Fedora-infrastructure-list mailing list
git://fedorapeople.org/git/$user/$repo.git
instead of:
git://fedorapeople.org/home/fedora/$user/public_git/$repo.git
You can already use:
git://fedorapeople.org/git/~$user/$repo.git
Oops, that's:
git://fedorapeople.org/~$user/$repo.git
elfutils is switching to git, and AFAIK no other fedorahosted projects use mtn.
I don't intend to work on the hosting support for mtn any more.
(I've stopped maintaining any mtn-related Fedora/EPEL packages too.)
Thomas Moschny maintains the mtn-related Fedora packages.
He's also the author of
I've been thinking for a while execshield.patch could be split into two or
three cleaner patches. Some of those might even be upstreamable as config
options or something. It really isn't that big a patch at this point.
___
Fedora-kernel-list mailing
Fedora kernel folks don't really pay attention to utrace innards except to
make sure that I get the flames about them. The place dedicated to
discussion of those innards is [EMAIL PROTECTED]. (It's fine to
mention the Fedora kernel versions and bugzilla links on that list.)
That fix is one that
Have you also looked at the kerneloops.org data? That tends to have a
nice collection of utrace oopses/warnings...
I typed utrace in the Function Search box. The only common one (many
many hits) was fixed a while ago (on 9/15 around lunch time, it so happens).
The other ones for non-ancient
What's this about?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
23f3c3c8bbe725577a63c07c24ebab0e2c6e26aa has these nit fixes:
libdwfl/
2008-09-29 Roland McGrath [EMAIL PROTECTED]
* segment.c (insert): Must realloc DWFL-lookup_module here too.
(dwfl_report_segment): Clear DWFL-lookup_module before insert calls.
2008-08-28 Roland McGrath [EMAIL PROTECTED
linux-2.6-acpi-video-dos.patch
linux-2.6-defaults-acpi-video.patch
These are policy decisions. Probably not going usptream.
Can they be turned into upstream config options?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
I reenabled kernel-doc and tweaked it up.
* Make htmldocs too. Some pithy bits are only in the .tmpl stuff and it is
nice to be able to point people at install kernel-doc and point your
browser at file:///..., etc.
* make in %build, only install in %install. Pure rpm anality.
* Use
Uh, who cares? It should be at least one less than the number for the
second zone update of the day. ;-)
The elisp mode I use for zone files does 0.
When in doubt, start a 0/1-origin flame war just for the hell of it.
___
Fedora-infrastructure-list
Running rebase.sh was so much fun that I for some reason decided to do
Dave's job today and once I'd run it then I had to cope with the kconfig
changes upstream.
I hacked linux-2.6-build-nonintconfig.patch and is seems to be about
right again. But I never did try to really understand that
Sorry, it was a local problem.
--
Fedora-websites-list mailing list
Fedora-websites-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-websites-list
I find myself doing a lot of make prep lately in the days of frequent
new upstream base patches. The untar still takes a lot longer than
the big patch. So I committed this to speed it up for the repeated
rebase case.
Thanks,
Roland
Index: kernel.spec
All sounds fairly reasonable to me, but why not have make vdso_install
install the file?
Yeah, that will be the right thing for upstream eventually.
Probably for upstream it is preferred to install files only
in $INSTALL_MOD_PATH and not go touching /etc.
So I think the norm will be something
I added these to config-generic to keep building with -git11.
I have no idea if these are the right settings.
+# CONFIG_MFD_TC6393XB is not set
+# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
+CONFIG_DMADEVICES=y
+CONFIG_INTEL_IOATDMA=m
+# CONFIG_DMATEST is not set
Thanks,
Roland
Why bother? If it comes up in the future, the macro will be handy.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
If you try and use e.g. kernel_obsoletes, you'll soon find
that it's actually kernel__obsoletes you currently need :-)
So you want kernel to have an Obsoletes: that kernel-foo do not get?
___
Fedora-kernel-list mailing list
On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote:
If you try and use e.g. kernel_obsoletes, you'll soon find
that it's actually kernel__obsoletes you currently need :-)
So you want kernel to have an Obsoletes: that kernel-foo do not get?
Yes; kernel-PAE.i686 obsoletes kernel
We should really only install ld.so.conf files from packages
that actually have CONFIG_XEN enabled, but it would be
slightly messy to have only kernel-PAE.i686 and kernel.x86_64
include it.
It wouldn't really be so hard to conditionalize it at least for the arch's
that ever need it. (The
BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/
for a kernel-vanilla build I did of 2.6.26.
This gives a baseline for regression testing any problems to see if they
are caused by some Fedora patches (e.g. utrace) or are also upstream.
I think koji scratch only stays around for
very simply put:
it's between getting this level of information:
http://www.kerneloops.org/raw.php?rawid=32356
with pointing at the exact code, and only getting this
http://www.kerneloops.org/raw.php?rawid=32287
Thanks. I'd like to help improve the tools so that we can close this
The best plan is to use whatever directory organization floats your boat,
and then massage the patches. Start with 'yum install patchutils'.
Then usually you want something like
diff -rpuNB --exclude={'*~','*.orig'} kernel-2.5.24{.orig,} |
filterdiff --remove-timestamps
What is the relationship between
git://git.fedorahosted.org/git/fedora-infrastructure.git
and the configs/system scripts in puppet1:/cvs/puppet?
If I want to commit a new version of a script and then get it deployed,
what is the procedure?
Thanks,
Roland
Is there an alternate Koji or some other means by which I can try
rawhide/ia64 rpm builds?
This is caused by the change of
#define TIF_RESTORE_SIGMASK 5
to
#define TIF_RESTORE_SIGMASK 22
Is there a need to change this bit from 5 to 22? If that really is
needed we are going to
I will probably continue to find it desireable to make a dozen different
100-200M partitions to use as /boot for installs, so I don't really care
about the name noncollision. But it sure would make it a little simpler
to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
I'm
I've put the 2.6.25 rebase of utrace back in and kicked off a build.
I'll pick up the pieces if it comes out all broken.
(It already did, cause I forgot to test the ppc32 build upstream.)
For the moment it's applied as one big patch instead of a series.
I haven't figured out the arrangement for
Huh? debugfiles.list populates kernel-debuginfo-common.
debuginfo.list populates kernel-debuginfo.
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
M linux-2.6-i386-vdso-install-unstripped-copies-on-disk.patch
needs a bit of inspection, looks right (and builds ok)
This one should be upstream now. If anything is still missing, I should be
able to get it in for 2.6.25.
M linux-2.6-utrace-core.patch
M linux-2.6-utrace-tracehook.patch
I needed the following patch to be able to build the fedora rpms
on i386. This is likely a case of the new code doing the right thing,
but me not being able to figure out the debug stuff in the spec file
at the time though.
I sent a fix upstream for that.
Thanks,
Roland
Your attachment was empty.
The execshield patch has gotten much smaller than it was in the beginning.
It still hasn't gotten all the cleanup it could get though. The patch does
a few different things that ideally would be in separate patches.
1. Segment-based PAGE_EXEC for no-NX hardware (and
David is correct that eu-elfcmp is meant to see the stripped and unstripped
files as matching. Josh is correct that the .gnu.attributes section is the
new thing that is provoking the problem, owing to GCC 4.3.
I'm doing three things:
1. elfcmp's bug is that it sees the .gnu.attribute sections
Could this be yet another problem caused by the switch to GCC 4.3?
Hard to see what it could have done to cp. ;-)
+ cp vmlinux /var/tmp/kernel-2.6.24-14.fc9-root-ppc/boot/vmlinuz-2.6.24-14.fc9
...
+ cp vmlinux
/var/tmp/kernel-2.6.24-14.fc9-root-ppc/usr/lib/debug/lib/modules/2.6.24-14.fc9
Oh wait, the copied not linked warning probaby explains the whole thing.
The /usr/lib/debug copy is not stripped, so it's not identical.
Yeah, ok. I wonder why this wasn't happening before.
I think it is just fixed by resolving the problems with too many copies of
vmlinux.
Thanks,
Roland
Why are we building kernels with this broken compiler?
http://bugzilla.kernel.org/show_bug.cgi?id=8501
http://koji.fedoraproject.org/koji/getfile?taskID=388196name=build.log
Why are we building these broken kernels with our shiny new compiler?
Roland, I don't suppose any of the recent changes I seem to recall
hearing you were going to make to debuginfo might have anything to do
with this...
Seems unlikely since I haven't actually made any yet.
___
Fedora-kernel-list mailing list
Maybe this is because even after we strip out the debuginfo, file was
reporting not stripped, so someone decided to override that and always
report them as stripped? I just used eu-unstrip to reassemble a module
with the full debuginfo and file still doesn't say anything about it...
file's
Is F-[78] going to stay on 2.6.23 for a while, or switch to 2.6.24 fairly soon?
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Ok, thanks for the info. If it's not likely to be weeks and weeks, then I
don't think I'll update the utrace/2.6.23 backport any more with recent fixes.
utrace/2.6-current is now on 2.6.24, and I won't rebase it for a few days.
When it breaks rawhide or when I get to it, I'll branch utrace/2.6.24
On Wed, 23 Jan 2008 23:03:15 -0800 (PST)
Roland McGrath [EMAIL PROTECTED] wrote:
It is probably a better solution not to have a vmlinux.debug but instead
keep the simple cp, and avoid the vmlinu[xz].debug files by explicitly
stripping the /boot copy of vmlinux.
I wish you wouldn't
I browsed a few of the internals, and it looks like the ppc variant includes
a complete source tree
in /usr/src/debug
It's normal to have every source file referenced by any binary's DWARF info.
for x in */debug/kernel-debuginfo-2*.rpm; do for y in $x `echo $x | sed
I may have hashed this out with davej only in private before, so perhaps
you aren't aware of the normal plan for utrace updates. You disabled
utrace when you should have just run ./scripts/pull-upstreams.sh to get the
current patch set. The 2008-1-3 version of the patches already applied
fine.
I've had the same problem and not gotten around to reporting it. I hadn't
tried reboot=bios. For me, x86_64 kernels reboot fine but i386 kernels
hang at reboot, on the same machine. Mine has BIOS version A06, and
behaved the same with A04 before upgrading. This started in upstream
kernels
The reasons against it in the past were that it slowed down
the common case (people who aren't using the feature)
It doesn't look like it should.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
Just noticed the git server is all kinds of broken for the original uses
that worked before the setup got as organized as it is now.
git-ls-remote http://git.fedoraproject.org/kernel/roland.git/
git-ls-remote git://git.fedoraproject.org/kernel/roland.git/
If you would like to rename my
On Fri, 2007-08-17 at 12:29 -0700, Roland McGrath wrote:
I'd like to help figure out what the specific problem is, so we can solve
it properly.
OK, but how do we start? :)
I've CC'd Jakub, who has a tendency to know every corner of this sort of thing.
If that alone doesn't do
I fixed this in rawhide kernel.spec over the weekend and left a somewhat
detailed comment in the changed bit. But I thought I'd bring this up
directly and explain the story.
The short version of What Broke is what, you sha1 on me? no, i sha1 on you!
Module signing works by feeding all the
Is there a reason to add a hack to the kernel %post in particular,
instead of just making people use rpm triggers? I mean, horror and all that.
But at least it's generic SEP horror, and not new hair for the kernel rpm
itself (i.e. our problem).
Thanks,
Roland
I put in the macroified kernel.spec last night. It also has some new magic
changes to play well with the new find-debuginfo.sh. It hasn't built yet
since I threw in some other broken changes at the same time, which are
probably fixed by now for the next build Dave does.
I made the bits that
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last, not first. This way, when
we forget to reset fedora_cvs_origin after a rebase,
On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version number last
On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote:
I propose we change the release format for snapshot kernels.
Now we get e.g.:
kernel-2.6.23-0.89.rc2.git2.fc8
and I suggest instead:
kernel-2.6.23-0.rc2.git2.89.fc8
That is, put the spec file version
Do -debuginfo packages for variants get produced automatically?
Yes. The %kernel_variant_package macro uses %kernel_debuginfo_package (and
%kernel_devel_package). The main package (kernel) uses those two macros,
but not %kernel_variant_package. I didn't define a separate
The patch below revamps kernel.spec using macros to minimize duplication.
There is now very little boilerplate to write/update for each variant
built. It's now just a few %kernel_variant_foo macro lines for each flavor
(plus %description, which is unchanged). When the common boilerplate
details
It's non-obvious to me what %{?buildid} is, but it seems to
auto-increment.
buildid is the please set this to .me one.
fedora_build is the one to bump on commit.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote:
On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote:
It's non-obvious to me what %{?buildid} is, but it seems to
auto-increment.
buildid is the please set this to .me one.
fedora_build
What about before the first -rcN tag?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
I presume you're referring to the likes of say kernel 2.6.21-gitX, which
was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn't thought about that
case. Okay, will have to do some further twiddling to cover that case...
Yes, that's what I meant. Faking it as rc0 might be the easiest thing to
keep
What's Patch5?
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
to be a mapping of
an ELF file. Including these pages in the core dump may give sufficient
identifying information to associate the original DSO and executable file
images and their debugging information with a core file in a generic way
just from its contents.
Signed-off-by: Roland McGrath [EMAIL PROTECTED
Dave disabled utrace because sched-cfs has a line that conflicts. It only
conflicts under -F1, and with default patching (-F2) utrace applies fine
after sched-cfs. This tweak to the spec file's ApplyPatch makes it easy to
make one patch use -F2 when you need it, instead of disabling a patch
There was some complaining here about problems dealing with separate
debuginfo files. In elfutils-0.128, in an f6 and fc7 update near you,
there is now eu-strip. This doesn't improve any non-elfutils tools you
were using that weren't handling separate debuginfo well, but it makes it
easy to
In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel
out but really want to get this update in. If it's broken I can revert.
I haven't gotten folks to test that build yet, but already I have a few
more fixes (242694, 244162). The updated patches are on the web (all
Same goes for F-7 I guess. For devel however, it's a bit of a pain to
have to disable a dozen ApplyPatch's during the (brief) window
Really? Inserting true || { before and } after seems not much worse than
commenting out a line or two.
when I rebase, and you haven't rediffed utrace yet (if
Here I am again with those hacks to do alternate builds from the kernel
spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
--- kernel-2.6.spec 08 Jun 2007 12:55:12 -0700 1.3213
+++ kernel-2.6.spec 08 Jun 2007 12:55:05 -0700
@@ -63,7
On Fri, Jun 08, 2007 at 12:59:26PM -0700, Roland McGrath wrote:
Here I am again with those hacks to do alternate builds from the kernel
spec file. Can I commit at least the spec parts to rawhide now?
The diff is only this:
# This patch adds a make nonint_oldconfig which
1 - 100 of 104 matches
Mail list logo
