Re: FC12: Hidden files in /usr/bin/*
On Fri, Jan 22, 2010 at 11:23 AM, Garrett Holmstrom wrote: > On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius wrote: >>> - in some circumstances (government, regulated companies) encryption >>> must be certified to the FIPS 140-2 standard >> >> I don't know this "standard". >> >> May-be this "fips standard" collides with the FHS, may-be this standard >> is defective? >> >> Do you have a pointer/reference to this "standard"? Does it really >> mandate pollution /usr/bin and thus $PATH? > > FIPS 140-2 is a US government standard for crypto system security. > Its full text is available at > http://csrc.nist.gov/groups/STM/cmvp/standards.html if you're > interested. > > I have no idea if it actually requires them to be alongside the > executables, but hopefully the link will help. It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc to get included in Red Hat Enterprise Linux 5 (a separate review from the Fedora one), and pointed out this same problem, and it was done properly for RHEL5: $ rpm -ql hmaccalc /usr/bin/sha1hmac /usr/bin/sha256hmac /usr/bin/sha384hmac /usr/bin/sha512hmac /usr/lib64/hmaccalc /usr/lib64/hmaccalc/sha1hmac.hmac /usr/lib64/hmaccalc/sha256hmac.hmac /usr/lib64/hmaccalc/sha384hmac.hmac /usr/lib64/hmaccalc/sha512hmac.hmac /usr/share/doc/hmaccalc-0.9.6 /usr/share/doc/hmaccalc-0.9.6/LICENSE /usr/share/doc/hmaccalc-0.9.6/README /usr/share/man/man8/sha1hmac.8.gz /usr/share/man/man8/sha256hmac.8.gz /usr/share/man/man8/sha384hmac.8.gz /usr/share/man/man8/sha512hmac.8.gz It should be simple enough to just update the Fedora packages with the changes in RHEL5 and we can all go eat cake. But first, I'm going to go play some pickup soccer... -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson wrote: > On Fri, Jan 22, 2010 at 11:23 AM, Garrett Holmstrom > wrote: >> On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius wrote: >>>> - in some circumstances (government, regulated companies) encryption >>>> must be certified to the FIPS 140-2 standard >>> >>> I don't know this "standard". >>> >>> May-be this "fips standard" collides with the FHS, may-be this standard >>> is defective? >>> >>> Do you have a pointer/reference to this "standard"? Does it really >>> mandate pollution /usr/bin and thus $PATH? >> >> FIPS 140-2 is a US government standard for crypto system security. >> Its full text is available at >> http://csrc.nist.gov/groups/STM/cmvp/standards.html if you're >> interested. >> >> I have no idea if it actually requires them to be alongside the >> executables, but hopefully the link will help. > > It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc to > get included in Red Hat Enterprise Linux 5 (a separate review from the > Fedora one), and pointed out this same problem, and it was done > properly for RHEL5: > > $ rpm -ql hmaccalc > /usr/bin/sha1hmac > /usr/bin/sha256hmac > /usr/bin/sha384hmac > /usr/bin/sha512hmac > /usr/lib64/hmaccalc > /usr/lib64/hmaccalc/sha1hmac.hmac > /usr/lib64/hmaccalc/sha256hmac.hmac > /usr/lib64/hmaccalc/sha384hmac.hmac > /usr/lib64/hmaccalc/sha512hmac.hmac > /usr/share/doc/hmaccalc-0.9.6 > /usr/share/doc/hmaccalc-0.9.6/LICENSE > /usr/share/doc/hmaccalc-0.9.6/README > /usr/share/man/man8/sha1hmac.8.gz > /usr/share/man/man8/sha256hmac.8.gz > /usr/share/man/man8/sha384hmac.8.gz > /usr/share/man/man8/sha512hmac.8.gz > > It should be simple enough to just update the Fedora packages with the > changes in RHEL5 and we can all go eat cake. But first, I'm going to > go play some pickup soccer... Oh. Wait. Crap. We're talking about packages other than hmaccalc itself that do integrity checks. But I do agree with Ralf here, the checksum files don't belong in /usr/bin/, and there's no standard-based need for them to be there. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
2010/8/3 Björn Persson : > Adam Williamson wrote: >> Would it be nice to stick this customization into fedora-packager, or >> would it just confuse/surprise people? > > Is it fast enough to not delay the prompt noticeably even on old computers? No. At least, not the first time that you cd into a reasonably large git tree after a boot (i.e., data isn't cached in memory yet). I've got a core 2 duo laptop w/this enabled, and the first time going into a kernel git tree, its a good bit of disk churn and a very noticeable wait before I get a prompt back. After that first hit though, its reasonably fast to return. > What's the worst thing that could happen if it were to break? If Git were to > enter an infinite loop for example, would it render my shell useless? No clue. But I'd have to say no, don't just go enable it by default on people's systems. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
On Tue, Aug 3, 2010 at 7:04 PM, Peter Hutterer wrote: > Apologies if this was asked for and answered in another thread, I lost > overview. Ralf and Kevin made me realise something that I have > misinterpreted initially in regards to how packages are tagged now. > > https://fedoraproject.org/wiki/Using_Fedora_GIT claims that tagging is not > necessary and that the commitid is now submitted to koji. fair enough, but > the confusing thing here is: > "When successful on Koji, the build will trigger the package to be tagged > with the corresponding tag (e.g., dist-f15 for Rawhide [...]" > > does this mean the dist-f15 tag is forcibly updated each time a build is > successful? If so, where is this tag hiding? I can't seem to get it into my > repo even though it is listed as a koji tag in the emails. Or are we not > talking about git tags here anyway? Not sure about this part. > The other question and that may just be a feature request: > the CVS tags are still visible in my repo, e.g. > mtdev-1_0_1-1_20100706_fc14. these tags are useful, because in a few weeks > time I won't be able to remember the commit ID of a specific version (I know > I can get it from the logs, but it's annoying). > > If a build succeeds and is to be released as a package, can koji apply the > tag again to the git repo? It would allow for simple things like git diff > foo-1.1-2.fc12..foo-1.1-3.fc13. The plan, as I understand it, is for koji to apply the git tags after a successful build, but its not yet been implemented. For the time being, I plan to simply add annotated tags myself after each successful build of packages I own. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
On Tue, Aug 3, 2010 at 8:56 PM, Dennis Gilmore wrote: > On Tuesday, August 03, 2010 06:12:50 pm Jarod Wilson wrote: ... >> The plan, as I understand it, is >> for koji to apply the git tags after >> a successful build, but its not yet >> been implemented. For the time >> being, I plan to simply add annotated tags >> myself after each >> successful build of packages I own. > > Koji will never > interact directly with git. the plan is to have something watching for > successful builds and to apply a tag to git then. We don't currently have > that piece yet Sorry, right, koji would drop a note on the messaging bus, which something else would be looking for and act upon. Semantics. :) -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
On Tue, Aug 3, 2010 at 11:04 PM, Kevin Kofler wrote: > Dennis Gilmore wrote: >> the plan is to have something watching for successful builds and to apply >> a tag to git then. We don't currently have that piece yet > > Then why was dist-git brought live without this ESSENTIAL component? I'm not having any problems submitting builds and adding tags by hand *which is exactly what we did in cvs*. What exactly is ESSENTIAL about the nvr tags being automated for you? > Why did we have to rush migration to buggy (see all the complaints about > fedora-packager/fedpkg bugs) and incomplete infrastructure? New > infrastructure should first be COMPLETED before it is migrated to. I see no > reason why the switchover to git couldn't have waited until later (say, > after the F14 release), with the missing pieces in place. > > And once that component is in place, will it also retroactively tag git for > all the builds that are happening now or will we be stuck with builds > without a matching named tag in the repo forever? Yes, because its so incredibly hard to manually tag things. Never mind that its exactly what you did with cvs. Its just not explicitly required before submitting a build anymore, as builds are done based on git hash instead of cvs tag. Is it too hard to type 'git tag n-v-r'? Would you like a 'fedpkg tag' command that mimics the old 'make tag'? Shouldn't be more than a few lines of python to implement. Seriously. You probably could have already written it in far less than the amount of time you've spent moaning about how terrible things are now. Rel-Eng, and especially my man Jesse: THANK YOU. Can't wait until we get to kill cvs internally too. Git is worlds better. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
On Wed, Aug 4, 2010 at 12:40 AM, Kevin Kofler wrote: > Jarod Wilson wrote: >> I'm not having any problems submitting builds and adding tags by hand >> *which is exactly what we did in cvs*. What exactly is ESSENTIAL about >> the nvr tags being automated for you? > > The fact that most builds will end up with no named tags at all because > dist-git doesn't enforce manual tagging nor is it in the packager SOP. > Having successfully built versions be tagged in the SCM so that the sources > corresponding to a given NVR can be easily checked out at any time was > posted as one of the essential requirements on the SCM setup. The current > implementation does not comply to that essential requirement. Define "easily". I can look at koji for a specific build n-v-r, and get its git hash quite easily. Then I can tell git to show me the tree when it was at that git hash. Not as easy as if n-v-r tags were already in place, which would avoid the need to talk to koji, but still hardly hard. > Thus, this is > a showstopper which should have blocked putting dist-git into production. See above. > Plus, automatic tagging was promised as THE reason we switch to dist-git in > the first place. Huh? "THE" reason? Um, no. And there *are* automatic tags. They're call git hashes. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
On Wed, Aug 4, 2010 at 1:05 AM, Peter Hutterer wrote: > On Wed, Aug 04, 2010 at 12:55:09AM -0400, Jarod Wilson wrote: >> On Wed, Aug 4, 2010 at 12:40 AM, Kevin Kofler wrote: >> > Jarod Wilson wrote: >> >> I'm not having any problems submitting builds and adding tags by hand >> >> *which is exactly what we did in cvs*. What exactly is ESSENTIAL about >> >> the nvr tags being automated for you? >> > >> > The fact that most builds will end up with no named tags at all because >> > dist-git doesn't enforce manual tagging nor is it in the packager SOP. >> > Having successfully built versions be tagged in the SCM so that the sources >> > corresponding to a given NVR can be easily checked out at any time was >> > posted as one of the essential requirements on the SCM setup. The current >> > implementation does not comply to that essential requirement. >> >> Define "easily". I can look at koji for a specific build n-v-r, and >> get its git hash quite easily. Then I can tell git to show me the tree >> when it was at that git hash. Not as easy as if n-v-r tags were >> already in place, which would avoid the need to talk to koji, but >> still hardly hard. >> >> > Thus, this is >> > a showstopper which should have blocked putting dist-git into production. >> >> See above. >> >> > Plus, automatic tagging was promised as THE reason we switch to dist-git in >> > the first place. >> >> Huh? "THE" reason? Um, no. And there *are* automatic tags. They're >> call git hashes. > > I don't think git hashes are an equivalent to the nvr tags though. I may > have multiple commits for each nvr, a tag that explicitly specifies which > version ended up as an rpm in koji would be quite helpful. I have troubles > remembering hashes long-term, nvr is marginally easier. it also simplifies > things like "git diff foo-1.2-1..foo-1.2-2" or the automation of that > process. I completely agree. But the situation isn't "ZOMG CRITICAL" like Kevin makes it out to be. You *can* work back to a git hash if you know the nvr by looking at koji, and you *can* add the tags yourself right now. There's just an extra manual step involved until post-build auto-nvr-tagging gets deployed. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel maintainers - please review and commit patch in #528232
On Mon, Aug 30, 2010 at 5:53 PM, Marius Andreiana wrote: > Hi all, > > There's a long standing bug which prevents FC14 to boot on most EFI systems > : > https://bugzilla.redhat.com/show_bug.cgi?id=528232 > > Would a knowledgeable kernel developer please review the patch for > drivers/video/efifb.c and commit it? https://bugzilla.redhat.com/show_bug.cgi?id=528232#c37 is in fact authored by one of the Fedora kernel maintainers, so it would seem they're already on it. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Jun 9, 2011, at 6:37 PM, Dave Jones wrote: > On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: >> On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: >> >>> I agree. As virtualization technology becomes more and more involved >>> and frequent on users systems, particularly with advanced Linux users, >>> I think there needs to be a strong focus on ensuring that all releases >>> run in virtualized environments without any major issues. ie. >>> Virtualbox. >>> >>> Perhaps a dedicated team among the developers who specialize in this area. >> >> I don't think there are any developers working on this area, where "this >> area" is Virtualbox. We don't ship Virtualbox. We don't ship a kernel >> that has any knowledge of Virtualbox. There's a good argument for having >> this be part of the QA process and requiring that we boot in the common >> virtualisation environments as part of the release criteria, but I don't >> think we can realistically suggest that our virtualisation developers >> (who work on code that has nothing to do with Virtualbox) be responsible >> for that. > > I'm curious why virtualbox has gained so much inertia so quickly. > Based solely on the number of kernel bug reports we get that seem to be > related to it, I have almost zero confidence in it being reliable. > > Why are people choosing it over other solutions, and what can we change > in qemu/kvm to get users using that instead ? Beer-free and multi-platform, like others have said. I use VirtualBox myself on my MacBook Pro running Mac OS X. Note, however, that I have a Fedora 15 guest installed and running perfectly fine this very minute, so I dunno what the supposed problems are... (For Linux hosts, I do use kvm.) -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning a few packages
I have no use for these packages anymore, and didn't even really remember I owned them, until Ralf jumped in and fixed a ftbfs bug against isic filed all of 4 days ago without saying boo to me, other than suggesting in the bug that the AWOL maintainer dance be started after he'd already fixed the build. So thanks for the fix. And for the reminder that I still have ownership of some packages I just don't care about, I guess. I'll save the trouble of the whole AWOL stuff and just orphan it, along with three other packages: isic - ip stack integrity checker ip6sic ipv6 stack integrity checker ctrlproxy - an irc proxy rinputd - remote input daemon There's a ftbfs bug just filed against rinputd as well, looks like an easy fix, possibly even already fixed upstream, though it was only filed 4 days ago, so maybe not. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 12: Make Dell machines boot again
On Tue, Apr 6, 2010 at 3:43 PM, Adam Williamson wrote: > On Mon, 2010-04-05 at 10:28 -0400, John W. Linville wrote: >> On Sat, Apr 03, 2010 at 10:48:39PM +0200, Felix Schwarz wrote: >> >> > since the last stable kernel update in Fedora 12, a lot of Dell machines >> > do not boot anymore due to a kernel oops... Of course bugzilla has a >> > couple of bug reports (e.g. #578217, #579118, #578663, #578590). >> > >> > There is a known fix/workaround which is already present in CVS >> > (kernel-2.6.32.10-94.fc12) and a koji build which fixes the issue for >> > all users. However there's no update in bodhi yet. >> > >> > Due to the severity of the problem, I'd like to see a push to >> > updates-testing as soon as possible. >> >> Thanks, Felix. I have created the update. >> >> Since I created the problem for the b44 people in kernel -90, I >> wanted to be sure to get some positive test reports before pushing >> the -94 update. I apologize for the extended delay over the weekend! > > From what I can tell, it looks like the -90 update got 'auto-pushed' by > hitting +3 karma, despite the fact that two people had reported the > regression in Bodhi. This is a classic case of 'works for me' positive > feedback overriding 'there's a regression!' feedback, which is one of > the issues we're trying to fix with the proposals to improve Bodhi. > > For now, might I suggest disabling auto-push for kernel updates? Even more fun, the request was initially submitted and told to ignore karma for auto-push, but the initial submission had an incorrect bug number in it. Went in to fix that, and apparently didn't notice that bodhi had helpfully decided to re-enable the auto-push check box when all I wanted to do was fix a bug number. (in other words, "edit" doesn't properly honor the current settings of the ticket). -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer - Chris Ricker
On Nov 10, 2010, at 5:54 AM, Jaroslav Skarvada wrote: > Hi, > > I was unsuccessful in all attempts to contact Chris Ricker (kaboom AT > oobleck.net). He seems non-responsive for a long time, I did not receive any > reply from him at least from February. > > Tracker bug: > http://bugzilla.redhat.com/show_bug.cgi?id=554334 > > Previous attempt to contact through devel: > http://lists.fedoraproject.org/pipermail/devel/2010-November/144873.html > > Personally I am interested in rrdtool (and I can take it), but there are also > more packages with unresolved bugs I have to second someone taking over rrdtool. I handed it off to Chris a while back, but have still done far more work on it since then than he has, and I've not seen him touch an rrdtool bz in ages. :( (And no, I don't want maintainership back.) -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git repository with Fedora kernel(s) sources
On Feb 27, 2011, at 1:09 PM, Thomas Moschny wrote: > 2011/2/27 Kyle McMartin : >> Our workflow is an SRPM of patches, so that's what we work with. > > You really do that "by hand", without some sort of patch manager? The spec file and the fedora packaging scm *are* the patch manager. Seriously, it works quite well. Most of us do all of our devel work against upstream kernel trees, then spit out patches from there to apply on top of the Fedora kernel. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git repository with Fedora kernel(s) sources
On Feb 27, 2011, at 1:19 PM, Kyle McMartin wrote: > On Fri, Feb 25, 2011 at 08:32:34AM -0800, Garrett Holmstrom wrote: >> Fedora's patched kernel sources in a git repository and then include >> kernel-2.6.38-1.1.fc15.tar.bz2 in the source RPM instead of vanilla >> kernel-2.6.38.tar.bz2 and fifty patches. Red Hat appears to do this >> with RHEL 6's kernel, but their kernel repository is not >> publicly-accessible. >> > > RHEL also never rebases, which means their git tree is virtually linear. I'd say its not even virtually linear, its linear, period. Once a given RHEL major release goes out the door, the kernel tree is never branched or rebased, no git merges, or anything, just a series of linear commits, all done by a single maintainer. Patches aren't pulled from sub-maintainer git trees, they're pulled from a patchwork database, once deemed ready, so the commit history remains 100% linear. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RealTek 8191SEvB wifi
On Mar 3, 2011, at 7:54 AM, Jos Vos wrote: > Hi, > > Will F15 (and maybe also newer F14 kernels?) support the RTL8191SEvB > Wireless LAN Controller? AFAIK at least stock F14 does not support it. Looks like it, based on the addition of the rtl8192ce driver upstream in 2.6.38, which includes support for multiple 8191 devices as well. Knowing your PCI device ID would lead to more certainty. Devices the driver claims to support: #define RTL_PCI_8192_DID 0x8192 /*8192 PCI-E */ #define RTL_PCI_8192SE_DID 0x8192 /*8192 SE */ #define RTL_PCI_8174_DID 0x8174 /*8192 SE */ #define RTL_PCI_8173_DID 0x8173 /*8191 SE Crab */ #define RTL_PCI_8172_DID 0x8172 /*8191 SE RE */ #define RTL_PCI_8171_DID 0x8171 /*8191 SE Unicron */ #define RTL_PCI_0045_DID 0x0045 /*8190 PCI for Ceraga */ #define RTL_PCI_0046_DID 0x0046 /*8190 Cardbus for Ceraga */ #define RTL_PCI_0044_DID 0x0044 /*8192e PCIE for Ceraga */ #define RTL_PCI_0047_DID 0x0047 /*8192e Express Card for Ceraga */ #define RTL_PCI_700F_DID 0x700F #define RTL_PCI_701F_DID 0x701F #define RTL_PCI_DLINK_DID 0x3304 #define RTL_PCI_8192CET_DID0x8191 /*8192ce */ #define RTL_PCI_8192CE_DID 0x8178 /*8192ce */ #define RTL_PCI_8191CE_DID 0x8177 /*8192ce */ #define RTL_PCI_8188CE_DID 0x8176 /*8192ce */ #define RTL_PCI_8192CU_DID 0x8191 /*8192ce */ #define RTL_PCI_8192DE_DID 0x092D /*8192ce */ #define RTL_PCI_8192DU_DID 0x092D /*8192ce */ -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compilation error building kernel-2.6.32.12-115.fc12
On Sun, May 23, 2010 at 6:13 AM, Richard Zidlicky wrote: > On Thu, May 20, 2010 at 05:35:04PM -0700, JD wrote: >> On x86 (32 bit) notebook: >> After running make xconfig, and make all, I got this error: > > You need a completely different procedure to build fedora kernel packages. > > http://fedoraproject.org/wiki/Docs/CustomKernel > > I found the description somewhat overcomplicated, if you just want to rebuild > use > rpm -ihv kerne-package.src.rpm > rpmbuild -ba --target=`uname -m` ~/rpmbuild/SPECS/kernel.spec If you *just* want to rebuild, 'rpmbuild --rebuild kernel-package.src.rpm' is even simpler. You only need to install the srpm bits if you're going to actually change something. It only gets complex if you want to patch things, modify config options, etc. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compilation error building kernel-2.6.32.12-115.fc12
On Sun, May 23, 2010 at 5:23 PM, Genes MailLists wrote: > On 05/23/2010 02:45 PM, Jarod Wilson wrote: > >> If you *just* want to rebuild, 'rpmbuild --rebuild >> kernel-package.src.rpm' is even simpler. You only need to install the >> srpm bits if you're going to actually change something. It only gets >> complex if you want to patch things, modify config options, etc. >> > > I thought the OP wanted to build upstream kernel Then that would be rpmbuild --rebuild --with vanilla kernel-package.src.rpm. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compilation error building kernel-2.6.32.12-115.fc12
On Sun, May 23, 2010 at 11:05 PM, Genes MailLists wrote:
> On 05/23/2010 08:50 PM, Jarod Wilson wrote:
>> On Sun, May 23, 2010 at 5:23 PM, Genes MailLists wrote:
>>> On 05/23/2010 02:45 PM, Jarod Wilson wrote:
>>>
>>>> If you *just* want to rebuild, 'rpmbuild --rebuild
>>>> kernel-package.src.rpm' is even simpler. You only need to install the
>>>> srpm bits if you're going to actually change something. It only gets
>>>> complex if you want to patch things, modify config options, etc.
>>>>
>>>
>>> I thought the OP wanted to build upstream kernel
>>
>> Then that would be rpmbuild --rebuild --with vanilla kernel-package.src.rpm.
>>
>>
> There is no vanilla-kernel.src.rpm - thats the point.
I didn't say there was a vanilla-kernel.src.rpm, but there doesn't
need to be. You rebuild the Fedora kernel src.rpm file using rpmbuild,
passing in the flag '--with vanilla', which results in building a
(mostly) pure vanilla upstream kernel without (most of) the Fedora
patches, and spits out a resulting kernel-vanilla binary package.
*That* is the point. :)
Excerpt from the Fedora kernel spec file:
8<
# Want to build a vanilla kernel build without any non-upstream patches?
# (well, almost none, we need nonintconfig for build purposes).
Default to 0 (off).
%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
8<
--
Jarod Wilson
ja...@wilsonet.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compilation error building kernel-2.6.32.12-115.fc12
On Mon, May 24, 2010 at 9:06 AM, Genes MailLists wrote: > On 05/24/2010 12:01 AM, Jarod Wilson wrote: > >> I didn't say there was a vanilla-kernel.src.rpm, but there doesn't >> need to be. You rebuild the Fedora kernel src.rpm file using rpmbuild, >> passing in the flag '--with vanilla', which results in building a >> (mostly) pure vanilla upstream kernel without (most of) the Fedora >> patches, and spits out a resulting kernel-vanilla binary package. >> *That* is the point. :) >> >> Excerpt from the Fedora kernel spec file: > > That is good to know - thank you I wasn't aware of that flag. Usually > people want to build upstream kernels to try newer versions with bug > fixes, new featiures etc. > > Lets say for example, (s)he wants to build 2.6.34 upstream ... > following your recipe - what exactly needs to be done on fedora 12 ? Rawhide typically tracks upstream pretty closely, so you can usually find an apropos srpm in the build system. For example, for 2.6.34: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.34/11.fc14/ Navigate up just two levels from there, and you can see every upstream base kernel version for which there's a source rpm available. No 2.6.35-to-be builds just yet, but there will be relatively soon. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git project update
On Thu, Jun 10, 2010 at 5:44 PM, Jesse Keating wrote: > It's been a while since I last updated folks on dist-git, and in reality > it's been a while since I last worked on it. Fedora 13 took up all my > time. > > Since my last update we've made great progress on fedpkg, the new tool > that will replace the make system. It is packaged up with > fedora-packager and has the ability to do many tasks that our Make > system handled. ... > Based on this testing, and some decisions around git tagging and branch > usage, we stand a good chance at being able to roll this out prior to > the F14 branch event. I hope you are all as excited as I am about this! Oh hell yeah. Looking forward to the day when none of the projects I work on are using cvs any longer (this includes you, Red Hat internal cvs, and you, lirc upstream)... -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git project update
On Fri, Jun 18, 2010 at 7:53 PM, Jesse Keating wrote: > On Sat, 2010-06-19 at 01:08 +0200, Kevin Kofler wrote: >> Jaroslav Reznik wrote: >> > Fedpkg should hide the GIT details from you. >> >> But it's a command-line tool. Cervisia (what I use on the CVS repos) is a >> GUI. >> >> Kevin Kofler >> > > fedpkg is also a library, where all the interesting things are done in > the library, so that somebody could write a gui (or even web) frontend > for it. I'm making a strong effort to keep the separation between > library and frontend as clean as possible. Plus, cervisia is a *cvs* gui, not a Fedora Makefile gui, no? There are a fair number of git guis too. -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, Jul 7, 2010 at 4:29 PM, Tom "spot" Callaway wrote: > [jwilson] ctrlproxy: ctrlproxy-devel-3.0.8-6.fc14.x86_64 > [jwilson] lirc: lirc-doc-0.8.6-5.fc14.x86_64 > lirc-libs-0.8.6-5.fc14.x86_64 lirc-remotes-0.8.6-5.fc14.x86_64 All better now. At least, mostly. Sent off a ctrlproxy build (I thought someone else had taken over maintainership of this, but I guess its still mine...), didn't do an lirc build yet though, as I need to update to the forthcoming 0.8.7 code w/patchification for the new hotness about to be merged upstream lirc support... -- Jarod Wilson ja...@wilsonet.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
