Re: astronomy-bookmarks conflicts with fedora-bookmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2009 04:50 PM, Paul W. Frields wrote: > On Mon, Dec 14, 2009 at 04:32:56PM -0500, Eric Christensen wrote: >> When trying to install astronomy-bookmarks I get the error that >> "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I >> looked at the source (an HTML file) but I can't quite figure out why it >> would conflict. Does anyone know? > > [p...@scarlett ~]$ repoquery -q --provides astronomy-bookmarks > astronomy-bookmarks = 1-6.fc12 > system-bookmarks > [p...@scarlett ~]$ repoquery -q --provides fedora-bookmarks > fedora-bookmarks = 11-2 > system-bookmarks > > They both provide 'system-bookmarks'. > Okay, that makes sense. Thanks Paul. - --Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLJrUsAAoJEDbiLlqcYamxHlgQAIP7AGOXwGIyvD93YXywRTf/ 9/vEDR9ti92gNjJ21EEw3QRYTD6czsUOZZ/EfJDldIaSQPx6aktZJQT1neBlLlgD lRFvqLY29/ZokPqF0gyBznl5FFpkbVHhClSPsBJzfPkeQ7jb50ZQU5w5z2IUSk7l yzih0lskGCeDT2RGBg3SrKVhWX1sgO8dRdmfVORg0uRRkJgDLgq7i6Fp2mkSIPqT R8iErKs8bAP24FgIZMKJGNGjUW3oUS7NuC0n1sB169y2ProPmLfMzHfagJzR438i PPQHb9QHkXhzd8YedjGGG3ks3OaZ1xoTuj6eDga9UquvZ3gKcX/gqbOH7U7b4nuC LDrCskYOhgoR+rFvP9rpgP13nUj7iK4iWu00jRNS4nvDe/Jh9oI44r4A2v7xwOCI lI1ZNZZYCM2Ci2kzKvIuezS3kOcgKXYVl/Zsio81rLgc3/Kp3RYDErmuRcuvQD9M sIe1QTVw8q0sAMuCxNDH9DuIAB4luHc3hAAdtl+n78qokmS0g4iWSMzvVteBBJB/ Q2GEBl7q4BiLAQe8HnX0bAT496yuIFMGzSbbA7qWv6oeccN16W1fLKWjPFb8xhpO xCjJsVzYsuI8aFFXxO/cXyQuojNoPw34KRi8df/71KIvlIfaQ02DKkiauJfCMIg7 zyl+TSdhiUV4ReUZwAUZ =O57+ -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
astronomy-bookmarks conflicts with fedora-bookmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When trying to install astronomy-bookmarks I get the error that "astronomy-bookmarks conflicts with fedora-bookmarks" in PackageKit. I looked at the source (an HTML file) but I can't quite figure out why it would conflict. Does anyone know? Thanks, Eric -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLJq8IAAoJEDbiLlqcYamx+sMP/j36892hx9wLAY+dJ1HAaQW0 Kw8TgyfW0sWvkLwcv45wwla9lP7FIvc9yFl5Bh7/84/x0fxApX0j9E50wzepYnaX Xb4MCCEM7FSMpjLRuDkN9xi1ppKr4hUKReY5oa7gfRM1sRepNHXg8pcOHv6Y3zcD NMtEZCcrZzQuPA6kSLF6QG79cS0dXJHSl2DUx8SQOoe48ETnOhSmG6870+CzTp9D 7B4LKPms0zZsnJFLl/YMm1PCgIARWumwIIJ3DQfzMjhRsVj2HF0Dfwz/I7l28pk2 eldHzGuIgfCheAB6SK/TyQzniAM2O43EVDU0e+2oEU6LVFvvlw8yXwraFNJR+Iw2 bM5Xu7bBJhZO0784idC6fMntAqBHZW6WF6I8JOD/VzgQPUs9RZwWTuOXo9kMK2kM FqtlgdzNs8HOt5N64+H45FUMTko2avLspmQuoEQBtNGXtSkpQ/luukn/kja7i812 lwttf/AmA7mzMIxA8OrsE6F9uwi9fcRcJLxHQMmVXBrXhw9kYM0wzv4Xe0IkmP/F 2dn9l/8c2L86xltN+7vpEL1++nitnhM7IPBbZesA0p9eBxH5LXokAnuW0jI/ccjF mLc78O9bIgQqIrHasUSSh/JM5g5n/1TpledJox5LIGb3eQiXUVZBLCXD5VVjN7Dn bnmtJ97j97nowuSmdQh3 =YAJh -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski wrote: > On Monday 30 November 2009 18:16:50 Adam Williamson wrote: > > Where I'm currently at is that I'm going to talk to some Red Hat / > > Fedora security folks about the issues raised in all the discussions > > about this, including this thread, and then file a ticket to ask FESco > > to look at the matter, possibly including a proposed policy if the > > security folks help come up with one. And for the moment, only really > > concerned with the question of privileges. > > > Start small with just privilege escalation and it can be grown to be > something > more comprehensive. FESco is the right place to go and see what the > project > wants to do. > There is already a security policy in place. It's not formalized nor is it written down but it's there. It's the current posture of Fedora. We set a root passphrase at the beginning of install and we give people the option of securing GRUB with a passphrase and encrypting the hard drive. We also have the unwritten rule of user privileges. It may be time to document our current posture to at least show where we are and the standard we expect all developers to live up to. In the process of documenting you may find that we are lacking somewhere. --Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 30, 2009 at 22:40, Hal Murray wrote: > > g...@czarc.net said: > ... > > A written description of the security policy is a must! > ... > > Is the idea of a single one-size-fits-all security policy reasonable? I > think Fedora has a broad range of users. > Probably not but there are some basics that should be implemented for everyone. > > Security is a tradeoff. If you make it impossible for the bad guys to get > in, the good guys probably can't get any work done. How secure do you need > to be? How much are you willing to pay for it? > How much are you willing to pay to clean up the aftermath? > > I'd much rather have an overview document that explains the likely attacks > and potential solutions, and their costs and benefits. Additionally, I > think > it's much easier to follow a policy if I understand the reasonaing behind > it. > The Fedora Security Guide (found at docs.fedoraproject.org and in a friendly repo near you) started out that way and has blossomed into that and a whole lot more. As always suggestions and patches are welcome. > I think sample policy documents with descriptions of their target audience > and checklists for how to implement them would be helpful. > +1 --Eric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski wrote: > Although I have read all of the messages on this thread as of the date/time > of > this message, I am replying to this first message with all of my comments. > > My background: I am currently retired but a few years ago I was still being > paid the big bucks for working on computer security and security assessment > of > systems in US classified environments. > > On the whole, I believe that Adam has outlined a good approach to the > problem > of doing QA on security for Fedora! > > General comment: I have read messages which claim that the approach is > wrong > and that we need to look at things that a user can do rather than what a > user > cannot do. I disagree. While the right approach for design/development is > to > assume that a user can do nothing except what they are specifically > authorized > to do, for security QA this needs to be turned around and the testing needs > to > demonstrate what a user cannot do. > > On Monday 23 November 2009 17:08:31 Adam Williamson wrote: > > We can't do any meaningful security testing without knowing exactly what > > we should be testing for, in which packages. I believe Seth Vidal's > > upcoming proposal for covering 'major changes' may touch on this, but I > > doubt they'll cover exactly the same ground. > > > > So, if we are to have meaningful security testing in future releases - > > which QA believes would be a good thing - we need the project to define > > a security policy. We believe there's a genuine need for this anyway, as > > the introduction and widespread adoption of PolicyKit will likely lead > > to much more complex and significant potential changes in security > > posture than any previous change. > > > > It's not QA's role to define exactly what the security policy should > > look like or what it should cover, but from the point of view of > > testing, what we really need are concrete requirements. The policy does > > not have to be immediately comprehensive - try and cover every possible > > security-related issue - to be valuable. Something as simple as spot's > > proposed list of things an unprivileged user must not be able to do - > > http://spot.livejournal.com/312216.html - would serve a valuable purpose > > here. > +1 > > A written description of the security policy is a must! Without it being > written down in simple english (with translations as appropriate), there > will > be far too much subjective interpretation of what the policy is. I believe > spot's list is a good starting point for F13. > > However, the policy should consider how Fedora should work with respect to > security and not how it does work as currently implemented. For example, > you > cannot currently login as root from the gui (gdm) interface but you can > login > as root from a virtual terminal ... is this the way the system should work? > > Keep it simple (KISS) for the initial attempt. It will grow more > complicated > all by itself as time passes. > > BTW, the security policy should assume that a grub password is in use so > that > a user cannot do something like disabling selinux by editing the kernel > command line. This should be tested by the security QA. > > > > > The second thing QA would require, aside from a policy with concrete and > > testable requirements, is a list of security-sensitive components to > > test. Obviously we couldn't test every package in the entire > > distribution for compliance with even such a simple list as spot's, and > > it would be a waste of time to try. > +1 > > You definitely need to define a "reference implementation" that will be > tested. > Security assurance testing is done on "as-built" systems ... not "as > designed"! It may be possible but is not practical to test everything. [or > will take so long that the release will no longer be supported] > > Furthermore, I believe you should initially focus on a small subset of what > is > in Fedora (perhaps gnome only) and with a selected set of services > (servers). > > At this point in time, considering all of the various windows > implementations > (gnome, kde, openbox, xfce, etc.) will result in a lot of motion but little > of > it in a forward direction. KISS!!! > > ... > Given a written security policy for Fedora and a written description of the > "reference implementation" that will be tested, these need to be vetted and > "tuned" from comments. > > After a reasonable amount of time, these documents/specifications should be > approved by the Fedora Executive Committee (or whatever). Any variation or > change, should require additional approval. There should be some > independent > oversight of the security QA process to minimize subjective > (re)interpretation. > > This will NOT make everyone happy. Sorry, but there is only so much > resources > and you really do not want this to be a black hole which consumes > everything > else. > > Start small, grow, and learn. Two years from now, the secu
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 18:10 -0800, Adam Williamson wrote: > On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote: > > > How that translates in packages and defaults is not really the most > > important part, but the plan is to have strict package defaults + a > > policy package that makes things work. > > > > The important part is that we QA the combination, not just the strict > > defaults. > > Right. If the Grand Plan is to go down this path, then what I've been > referring to as 'the security policy' would include the policies defined > for each spin, and hence any testing QA did for any given spin would > involve the policy defined for that spin. > > Having said that - is everyone agreeing that it's fine for each spin SIG > to be entirely in charge of defining and implementing security policy > for each spin? At the very least, that would possibly be problematic > given the known border issues between 'the desktop spin' and 'Fedora'. > Just another issue contributing to why we would need to settle that. > Honestly, leaving PackageKit wide open would only make sense. All operating systems that I'm aware of generally install open and require the end user to shore up their own installation because from the engineer's point of view they want the operating system to work on everyone's computer so they do things like leave the firewall wide open and allow you to login to ssh as root. Of course being able to flip a couple of switches to shut that down is more than appropriate. I'm not saying that I agree with this open policy, however. Many people don't know that they should do anything to secure their computers from install. It's also a pain to harden these systems after each install. I've often thought about doing a spin for those of us that use Fedora within the U.S. Government or U.S. Military that would be pre-hardened and ready to go. Just install and go. It would pass NIST and DISA controls from the get go. While that would also be great for home users it might be a bit overkill (or maybe not). If Fedora (and every other operating system) wants to make a change in security posture the hardening script similar to the one that comes with MySQL would be a great place to start. The user would install the software and go through the standard installation stuff and then would be presented by a little icon on their desktop that when selected would ask them simple questions that would automagically harden their system depending on the answers. Would be a heck of a lot better than going through the NSA's RHEL Hardening Guide (which is an awesome text, by the way). Just my 2 cents worth. --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thu, 2009-11-19 at 07:52 +0530, Rahul Sundaram wrote: > On 11/19/2009 07:50 AM, Mike McGrath wrote: > > On Wed, 18 Nov 2009, Jeff Garzik wrote: > > >> 1) We should recognize this new policy departs from decades of Unix and > >> Linux > >> sysadmin experience. > >> > >> 2) F12 policy should be reverted to F11, ASAP. Possibly with a CVE. > >> > >> 3) Due to #1, F13+ should not deviate from the decades-old default. > >> > >> 4) Release notes should explain new [and after step #2, optional] policy in > >> detail, including how to turn it off again. Seth's laudable write-up > >> efforts > >> should not have been necessary -- that info should be prepared. > >> > >> 5) The people who want this new security policy should add an opt-in > >> checkbox > >> in Anaconda or firstboot. > > > > > > Does anyone disagree with anything in 1-5? It all sounds reasonable to > > me? > > Release notes are being updated as we speak. I think, the "role" of a > system, be it a personal desktop, workstation, server or something else > can change post-installation as well. I don't think a simple checkbox in > Anaconda is going to be useful enough. We need a tool to switch policies > easily so that we can tweak the policies across a wide range of tools > with things like PolicyKit and each of these policies can be written > with particular audiences in mind. > > Rahul > I agree with 1-4 and Rahul. --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 15:43 -0900, Jeff Spaleta wrote: > On Wed, Nov 18, 2009 at 3:35 PM, Eric Christensen > wrote: > > PackageKit is something right there on the desktop that, to its credit, > > needs little knowledge to use whereas many of your attack vectors noted > > above are generally fixed in my shop by use of a kickstart and securing > > the box from physical access and require a higher skill to perform. > > So can't you harden this with a kickstart file line like you do in > your other hardening steps in your shop? I think to point Bill is > trying to make is that there are of a number of other settings that > need to be hardened and that this choice is just one of many choices > associated with security associated with a console user. Console user > security is already a leaky ship and PK is just one more hole. > > -jef > Maybe. I mean removing (or not installing) PK is a snap with kickstart. I haven't visited my kickstart in a while so... :) I guess the big thing, to me, is that this vulnerability wasn't presented, documented, or talked about and it is the opposite policy to what most (all?) SYSADMINS would expect. If you don't know to fix it then you are pwned. Most of the hardening guides that I've read or have contributed to assumed that the operating system wouldn't allow this kind of behavior by default and thus doesn't really address it. I know the hardening guide for RHEL from the NSA talks about setting up sudo and how to use it but doesn't talk about securing pup, IIRC. --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 19:23 -0500, Bill Nottingham wrote: > Jeff Garzik (jgar...@pobox.com) said: > > Sorry, but this default (desktop users can install pkgs without > > root) is just stupid. It is antithetical to all standard security > > models that have come before in Fedora and other Linux > > distributions. > > Out of the box, a desktop user has the ability to shut down the machine. > This gives them the ability, out of the box, to: > - DoS everyone on it > - get a root shell > -- install whatever they want > -- put viruses on > - hell, slap in a livecd or USB key and reinstall the box > > It's a behavior change, for sure. For people who want to lock down their > systems, it's a default they will need to be able to change, and they > should have been able to discover it through the normal mechanisms for > that. (i.e., the release notes.). It likely should have been discussed > when it was introduced - it's obviously not something that's applicable > to all usage cases for the OS. > > But really, given that users out of the box can do *far far worse*, I'm > not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND > YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are > tired of bagging tea and want new things to be outraged about. > > Bill > Bill, You are assuming that the users have physical access to the box and also know how to get a root shell and that the box hasn't been hardened (before the PK vulnerability was known). PackageKit is something right there on the desktop that, to its credit, needs little knowledge to use whereas many of your attack vectors noted above are generally fixed in my shop by use of a kickstart and securing the box from physical access and require a higher skill to perform. I'm not saying this new "functionality" in PK is necessarily bad but it should have been easily ENABLED (not by default) by an admin with root privileges. Of course, in my thought process, now, PK should probably not be installed on systems where users shouldn't have unrestricted access to the repo. --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 18:03 -0500, Jeff Garzik wrote: > On 11/18/2009 05:51 PM, Rahul Sundaram wrote: > > On 11/19/2009 04:19 AM, Richard Hughes wrote: > >> 2009/11/18 Seth Vidal: > >>> Richard, > >>> to be fair, when I asked you how to edit a .pkla file you couldn't tell > >>> me. > >>> So, if our engineers don't know the basics, how should our users? > >> > >> Fair comment. Release notes additions might be good in this regard. > > > > It should have been announced and documented with the rationale for the > > change *before* the release. Just pretending that everyone should know > > about how PolicyKit works when documentation is just lacking doesn't cut > > it. You didn't even respond to by bugzilla comment and just closed the > > Agreed 100.1%. > > > > bug. We will still do a post-release update for the release notes now > > but that's scrambling to minimize damage. > > The only thing that will fix the damage is to update PK, reverting the > default-insecure policy. > > May I remind folks that it is easy to UPGRADE INTO INSECURITY here. > Admins with servers, coming from F10/F11, can very easily fall into this > trap simply by updating their current systems. > > Jeff Has anyone drafted a notice to go out on the Announce List explaining this vulnerability? If admins don't know to fix/remove PK then they are putting their systems at risk. --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 14:49 -0800, Adam Williamson wrote: > On Wed, 2009-11-18 at 10:52 -0800, Jesse Keating wrote: > > On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote: > > > > > > 7. And the most obvious one ... how hard is it to get a bad package into > > > one of the repos. that the machine has enabled. > > > > Right, PK is counting on this being sufficiently difficult enough to > > prevent bad things from happening. While I'd like to think that, and > > would like to say that, I can't. > > I do not see how that's relevant, frankly. For it to be relevant it > would have to be true to state that, if you need root privileges to > install signed packages, it's absolutely no problem if a signed package > is evil. Obviously, that's not at all true. An evil 'trusted' package > would be a Very Bad Thing in any case. Whether you need to be root to > install a trusted package or not is entirely orthogonal, as far as I can > see. > > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > I'd like to point out that there are trusted packages that I wouldn't want my users downloading. John is a good example but there are others. Anyone requested that CVE yet? --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help needed with fedora-security-guide-en-US-1.0-16.fc12
On Sun, 2009-07-26 at 20:09 +0100, Richard Fearn wrote:
> Hi Eric,
>
> > I'm having problems with a Publican package (the Security Guide). Below
> > you will see the latest build error from Koji. I'm not familiar with the
> > error and I can't find anything listed on the wiki pages that I'm used to
> > finding solutions to packaging errors.
> >
> > The SPEC file can be seen at
> > http://sparks.fedorapeople.org/Packages/security-guide/fedora-security-guide-en-US.spec.
> >
> > I'd appreciate any suggestions.
>
> I just looked at your spec file in CVS (it's newer than the one you
> provided a link to):
>
> http://cvs.fedoraproject.org/viewvc/rpms/fedora-security-guide-en-US/devel/fedora-security-guide-en-US.spec?revision=1.4&view=markup
>
> You have this in the %install section:
>
> desktop-file-install %{?vendoropt}
> --dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{name}.desktop
>
> but you have this in the %files section:
>
> %{_datadir}/applications/%{?vendor}%{name}.desktop
>
> That "%{?vendor}" causes "Fedora Project" to be inserted into the
> filename, resulting in these errors in build.log:
>
> Processing files: fedora-security-guide-en-US-1.0-16.fc12.noarch
> error: Two files on one line: /usr/share/applications/Fedora
> error: File must begin with "/": Projectfedora-security-guide-en-US.desktop
>
> Looks like you need to remove "%{?vendor}".
>
> Regards,
>
> Rich
>
I'll forward this along as this is default coming out of Publican.
Thanks for the eyes, Rich.
-- Eric
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Help needed with fedora-security-guide-en-US-1.0-16.fc12
I'm having problems with a Publican package (the Security Guide). Below you will see the latest build error from Koji. I'm not familiar with the error and I can't find anything listed on the wiki pages that I'm used to finding solutions to packaging errors. The SPEC file can be seen at http://sparks.fedorapeople.org/Packages/security-guide/fedora-security-guide-en-US.spec. I'd appreciate any suggestions. Thanks, Eric Package: fedora-security-guide-en-US-1.0-16.fc12 Tag: dist-f12-rebuild Status: failed Built by: jkeating ID: 117516 Started: Sat, 25 Jul 2009 16:44:37 UTC Finished: Sat, 25 Jul 2009 16:49:17 UTC fedora-security-guide-en-US-1.0-16.fc12 (117516) failed on x86-5.fedora.phx.redhat.com (noarch), x86-1.fedora.phx.redhat.com (noarch): BuildError: error building package (arch noarch), mock exited with status 1; see build.log for more information SRPMS: fedora-security-guide-en-US-1.0-16.fc12.src.rpm Failed tasks: - Task 1503758 on x86-5.fedora.phx.redhat.com Task Type: build (dist-f12-rebuild, /cvs/pkgs:rpms/fedora-security-guide-en-US/devel:fedora-security-guide-en-US-1_0-16_fc12) Task 1513511 on x86-1.fedora.phx.redhat.com Task Type: buildArch (fedora-security-guide-en-US-1.0-16.fc12.src.rpm, noarch) logs: http://koji.fedoraproject.org/koji/getfile?taskID=1513511&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1513511&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=1513511&name=state.log Closed tasks: - Task 1513488 on x86-5.fedora.phx.redhat.com Task Type: buildSRPMFromSCM (/cvs/pkgs:rpms/fedora-security-guide-en-US/devel:fedora-security-guide-en-US-1_0-16_fc12) logs: http://koji.fedoraproject.org/koji/getfile?taskID=1513488&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=1513488&name=checkout.log http://koji.fedoraproject.org/koji/getfile?taskID=1513488&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=1513488&name=state.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1503758 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=117516 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal to drop gMFSK in favor of fldigi
On Wed, 2009-07-15 at 23:09 -0400, Randall J. Berry wrote: > This is a proposal to drop gMFSK > (http://koji.fedoraproject.org/koji/packageinfo?packageID=5883) in favor > of fldigi > (http://koji.fedoraproject.org/koji/packageinfo?packageID=5817) which > already supports all the same modes as gMFSK and then some. > > Also; gMFSK has not been updated in a while whereas fldigi seems to > still be an active project. gMFSK is also having troubles being built on > rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=511780) Shall we > work on the error and build it for rawhide or retire it in favor of > fldigi. What say you? > > 73 de Randy N3LRX (a.k.a. Dp67) > Randy, Sounds good to me as I only use fldigi. I wonder how many users out there are using gMFSK? Eric W4OTN signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
