Re: livecds in the future
On 11/30/2009 07:27 PM, Matthias Clasen wrote: 2. More download choices are not a part of the solution, but a part of the problem... We already have the problem that people are choosing to download the DVD just because DVD> CD; but unlike the spins, the DVD is not a designed product at all. This may mean also a good number of people to not care about a "designed product", they just want the packages. Or it may be the case the design for the "designed products" (that is the Desktop Spin, right?) is not that great (I think is not, I am completely out of its target). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Dne 1.12.2009 21:43, Bill Nottingham napsal(a): If the e1000 driver is broken in the kernel for some people, we don't support shipping an alternate driver. If a new version of the intel graphics driver is broken for some people, we don't support shipping a pre-KMS version of the driver. Why would we do differently here? Because if e1000 is broken, we can be sure with reasonably high level of certainity, it will be fixed without undue delay. For Xorg drivers (especially with regards to 3D support) we have hope that it will be slightly better in the next Fedora release, but complete coverage is still just a dream. Moreover, I don't know what's your problem with radeonhd driver in Fedora. Hanz does IMHO excellent job on maintaining it and it doesn't drag much additional resources on anybody (except on me, perhaps, because I triage bugs for him as well, which is the reason that this time I even a little know what I am talking about ;)). And of course comparing -radeonhd bugs (http://is.gd/59Hc0) with -ati bugs (http://is.gd/59Hp0) is unfair, because there are many more users of -ati driver, but at least it shows that radeonhd is really not burning issue. What's the problem? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Our lives are spectacles of powerlessness. -- Richard Rohr -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
gnumeric-1.9.16-1.fc13 in rawhide now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Just updated gnumeric in rawhide to gnumeric-1.9.16-1.fc13. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLFfbszHDc8tpb2uURAuCaAJ9PcscbyiZtgvVfy7ZYDu450dkTBgCdGvsT TyMKWiajZ4Y3Dz17JW/DgKs= =60AZ -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build Failure regarding Boost
On Tue, December 1, 2009 6:26 pm, Sir Gallantmon wrote: > Perhaps CMake needs to be updated to 2.8.0 final? I think there was a > FindBoost.cmake update in 2.8.0... cmake 2.8.0 final is in rawhide so you can test there. I'm not comfortable pushing it to F12/11. We could make an update with an updated FindBoost.cmake if necessary. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upcoming multi-day outage
On Tue, Dec 01, 2009 at 08:39:39PM -0500, Josh Boyer wrote: >On Wed, Dec 02, 2009 at 01:54:57AM +0100, Kevin Kofler wrote: >>Mike McGrath wrote: >>> Starting on December 12th The Fedora Project will start to move several >>> servers, disk trays and related hardware from our current hosting location >>> to another. This move is planned to be completed on December 15th and >>> will ultimately provide better hosting facilities and room for growth. >> >>Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that >>the last day to file F10 updates in Bodhi will be December 14, that's now >>right within the outage window. > >Hm. Crap, you are correct. I had been thinking I said it was Dec 11 >for several days now. I have no idea why, but we might seriously want >to change the final F10 push date to Dec 11 to accommodate for the >outage. I've created https://fedorahosted.org/fesco/ticket/282 to track this. Normally a final push date doesn't require FESCo approval, but given that this is a change in the date that gives people less time I thought it might be prudent. (I'm going to ignore the fact that this is pushing updates to a release that will be EOL'd 6 days later.) Transparency and junk and stuff. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upcoming multi-day outage
On Wed, Dec 02, 2009 at 01:54:57AM +0100, Kevin Kofler wrote: >Mike McGrath wrote: >> Starting on December 12th The Fedora Project will start to move several >> servers, disk trays and related hardware from our current hosting location >> to another. This move is planned to be completed on December 15th and >> will ultimately provide better hosting facilities and room for growth. > >Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that >the last day to file F10 updates in Bodhi will be December 14, that's now >right within the outage window. Hm. Crap, you are correct. I had been thinking I said it was Dec 11 for several days now. I have no idea why, but we might seriously want to change the final F10 push date to Dec 11 to accommodate for the outage. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Odd partition error in F12, but not in F11
I have a friend that doesn't read the list that has been fighting a very odd issue with F12, which does not surface in F11. On a clean install from the F12 DVD with the updates repo enabled, he created a RAID 5 setup across 6 drives. Each drive has only one partition on it. When the machine reboots it cannot rebuild the raid because it cannot find 4 of the 6 partitions. It drops to the root prompt and from there if you do an ls /dev/sd?* four of the drives show no entries for the partitions while the other two show the normal one partition. If you open one of the incorrect drives with fdisk it shows the correct partition table and if you write it out from fdisk it then shows correctly in /dev If you do this to each of the drives they all show up and then mdadm can assemble the raid correctly. Reboot the machine and you are right back to where you started. dmesg seems to show the kernel correctly listing each drive and correctly listing them with each one partition, but the entries are not in /dev for the partitions. We rolled back to F11 and performed the same process and it worked fine. I am really at a loss for what to look at or what to test against. We currently have the machine up and working with F11, so I can get any information about hardware that might help. I posted it here rather than the users list, because I don't really think this is a configuration problem. It seems like a bug in F12, but I don't know what to check it against. Brent -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build Failure regarding Boost
On Tue, Dec 1, 2009 at 6:53 PM, Tim Niemueller wrote: > On 01.12.2009 19:15, Braden McDaniel wrote: > > Broadly speaking (beyond just Fedora), there's enough variability in the > > potential names of Boost libraries that a package's configuration needs > > the ability to specify a Boost library suffix. It sounds like your > > package's configuration is trying to be clever and divine the required > > suffix--and it's failing and falling back to no suffix. > > > > If your package's configuration won't let you specify a suffix, the most > > expedient thing to do may be just to hack it on. But an upstream-worthy > > patch would add a means to specify an arbitrary suffix. Also, -mt is a > > saner default than no suffix at all. > > The suffix is determined in /usr/share/cmake/Modules/FindBoost.cmake > which is part of cmake, so there is nothing I can do about this in the > Player package. Could this be a problem with new cmake or boost versions? > >Tim > > -- >Tim Niemueller www.niemueller.de > = > Imagination is more important than knowledge. (Albert Einstein) > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Perhaps CMake needs to be updated to 2.8.0 final? I think there was a FindBoost.cmake update in 2.8.0... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upcoming multi-day outage
Mike McGrath wrote: > Starting on December 12th The Fedora Project will start to move several > servers, disk trays and related hardware from our current hosting location > to another. This move is planned to be completed on December 15th and > will ultimately provide better hosting facilities and room for growth. Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that the last day to file F10 updates in Bodhi will be December 14, that's now right within the outage window. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build Failure regarding Boost
On 01.12.2009 19:15, Braden McDaniel wrote: > Broadly speaking (beyond just Fedora), there's enough variability in the > potential names of Boost libraries that a package's configuration needs > the ability to specify a Boost library suffix. It sounds like your > package's configuration is trying to be clever and divine the required > suffix--and it's failing and falling back to no suffix. > > If your package's configuration won't let you specify a suffix, the most > expedient thing to do may be just to hack it on. But an upstream-worthy > patch would add a means to specify an arbitrary suffix. Also, -mt is a > saner default than no suffix at all. The suffix is determined in /usr/share/cmake/Modules/FindBoost.cmake which is part of cmake, so there is nothing I can do about this in the Player package. Could this be a problem with new cmake or boost versions? Tim -- Tim Niemueller www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build Failure regarding Boost
Tim Niemueller wrote: > The package uses cmake for building, where I suspect the problem. On my > (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses > the non-mt version (well, a non-multithreaded threading library is kind > of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. > Is there a known problem? Does anyone else maintain a project build with > cmake and using Boost and can give a hint how to solve? Does the package ship its own FindBoost.cmake? If it does, try removing it in %prep and seeing if that helps. (It'll use CMake's version then.) If the package isn't shipping its own FindBoost.cmake or if removing it doesn't fix the problem, please file a bug against CMake. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Ian Pilcher (arequip...@gmail.com) said: > On 12/01/2009 09:35 AM, Bill Nottingham wrote: > > So, if our X maintainers won't handle bugs with it, we have a working > > default alternative that is maintained upstream, and it's *known* to > > be broken in the default configuration, why ship it? If we're trying to > > focus on quality, I'm not sure why we'd ship something that's known > > broken. > > Because the alternative may be more broken for some people? > > https://bugzilla.redhat.com/show_bug.cgi?id=495688 If the e1000 driver is broken in the kernel for some people, we don't support shipping an alternate driver. If a new version of the intel graphics driver is broken for some people, we don't support shipping a pre-KMS version of the driver. Why would we do differently here? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
On 12/01/2009 09:35 AM, Bill Nottingham wrote: > So, if our X maintainers won't handle bugs with it, we have a working > default alternative that is maintained upstream, and it's *known* to > be broken in the default configuration, why ship it? If we're trying to > focus on quality, I'm not sure why we'd ship something that's known > broken. Because the alternative may be more broken for some people? https://bugzilla.redhat.com/show_bug.cgi?id=495688 -- Ian Pilcher arequip...@gmail.com -- 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 Tuesday 01 December 2009 13:04:02 Eric Christensen wrote: > 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. Yes, there has always been a security policy as defined by the written code (software). But, that is subject to individual interpretation. I agree that creating a written security policy is likely to identify shortcomings such as my point about the GRUB password. Lots of folks who use computers clearly do not understand the underlying technology and are clearly not paranoid enough. Given a home computer, do you really want your teenager installing file-sharing software. Recently, the US Congress discovered that some of their users had installed file-sharing software --- and the result was not positive. Fedora needs to provide good functionality while keeping our collective sanity ... we need software which is not just easy to use but is smarter about how it is used. Gene -- 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 Tuesday 01 December 2009 13:56:51 Adam Williamson wrote: > On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote: > > I suspect that most commercial and government customers will be > > interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora > > is the technology base on which future Red Hat Enterprise Linux releases > > are built. The better Fedora is, the more confidence customers will have > > the the Red Hat product. > > I agree. What I'm really worried about here, ultimately, is PolicyKit, > and the way it permits a lot more grey areas than have been possible > before. If you look at previous privilege escalation mechanisms, they're > simplistic; whether you're using sudo or consolehelper or whatever, > ultimately you either have a process run as root or as user. And it's > pretty obvious what should run as root and what shouldn't; I don't > remember there being any real serious debates about that, everyone > pretty much reaches the same conclusions independently. The > authentication question is equally simple: basically either the process > just runs as root automatically (which everyone agrees should happen for > as few processes as possible), or you have to authenticate each time - > for Fedora, basically you have to type the root password, since we never > really used sudo. > > Things like 'well, we can perform this one specific type of operation > with this one specific type of authentication' just weren't possible. > Now they are, so stuff like the PackageKit issue was bound to start > happening. The things PolicyKit make possible really need some kind of > coherent oversight, I think, and that is indeed something Red Hat > Enterprise Linux will also need to address, so obviously from an RH > perspective, it helps RH if Fedora develops some kind of policy for > this. But I think it's necessary for Fedora anyway, regardless of RH. > What you are saying put more emphasis on getting a security policy written and ratified by FESco. And you will also need some oversight of what the developers are doing with respect to security and this security policy. The QA process should catch the "oops" problems ... not those done intentionally by a well-intentioned developer. I do not know that much about PolicyKit and given my interests in security, I probably need to learn about it. One thing that occurs to me is to wonder if PolicyKit is using SELinux (see SELinux Users and Roles). If not, why not? Regardless of how PolicyKit works, the default should be locked-down with an easy-to-use sysadmin tool to provide configuration with the ability to open- things-up in a controlled manner. You should talk to the folks handling SELinux. My impression of them is that they know what they are doing and may provide some insight into the PolicyKit "problem". Fedora has come a long way since SELinux was first introduced. It would be a shame if the enhanced security provided by SELinux was negated by PolicyKit. A couple of other comments: - No, I do not believe that regular users should be able to update or install software globally without transitioning to an admin role ... they can put stuff in their home directory but not globally. - I agree with Smooge in one of the messages he wrote ... there are many users who would like to run Fedora just like Windows95. That may be but that does not mean that Fedora should follow that idea. Gene -- 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, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote: > I suspect that most commercial and government customers will be interested in > Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology > base on which future Red Hat Enterprise Linux releases are built. The better > Fedora is, the more confidence customers will have the the Red Hat product. I agree. What I'm really worried about here, ultimately, is PolicyKit, and the way it permits a lot more grey areas than have been possible before. If you look at previous privilege escalation mechanisms, they're simplistic; whether you're using sudo or consolehelper or whatever, ultimately you either have a process run as root or as user. And it's pretty obvious what should run as root and what shouldn't; I don't remember there being any real serious debates about that, everyone pretty much reaches the same conclusions independently. The authentication question is equally simple: basically either the process just runs as root automatically (which everyone agrees should happen for as few processes as possible), or you have to authenticate each time - for Fedora, basically you have to type the root password, since we never really used sudo. Things like 'well, we can perform this one specific type of operation with this one specific type of authentication' just weren't possible. Now they are, so stuff like the PackageKit issue was bound to start happening. The things PolicyKit make possible really need some kind of coherent oversight, I think, and that is indeed something Red Hat Enterprise Linux will also need to address, so obviously from an RH perspective, it helps RH if Fedora develops some kind of policy for this. But I think it's necessary for Fedora anyway, regardless of RH. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Upcoming multi-day outage
Starting on December 12th The Fedora Project will start to move several servers, disk trays and related hardware from our current hosting location to another. This move is planned to be completed on December 15th and will ultimately provide better hosting facilities and room for growth. Since the servers will physically be loaded onto a truck and moved, this means lots of services people rely on will be down. We'll be working hard and using whatever tricks we have at our disposal to keep things as normal as possible, for example http://mirrors.fedoraproject.org/ will remain up (which includes the mechanism yum uses to get its mirror list). Some critical services like the buildsystem will be completely unavailable for 48 hours or longer. I'll be sending another update out as the day gets closer to remind everyone. Also this is the official ticket we're tracking with for those who care to watch it: https://fedorahosted.org/fedora-infrastructure/ticket/1845 Please do stop by #fedora-admin on irc.freenode.net or comment in the ticket with any questions or concerns you have. -Mike ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build Failure regarding Boost
On Tue, 2009-12-01 at 18:31 +0100, Nicolas Chauvet wrote: > 2009/12/1 Tim Niemueller : > > Hi all. > > > > I'm trying to build the newest version 3.0.0 of the Player package. It > > builds just fine on F11/F12, but it fails with an error that > > "-lboost_thread" cannot be found on rawhide. boost-devel is in the BR, > > boost-thread is being installed according to root.log. > > > > The package uses cmake for building, where I suspect the problem. On my > > (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses > > the non-mt version (well, a non-multithreaded threading library is kind > > of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. > > Is there a known problem? Does anyone else maintain a project build with > > cmake and using Boost and can give a hint how to solve? > aqsis use cmake and boost, but also explicitly tell which boost library to > use. > You may have to adapt the cmake option if they are non-standardized. Broadly speaking (beyond just Fedora), there's enough variability in the potential names of Boost libraries that a package's configuration needs the ability to specify a Boost library suffix. It sounds like your package's configuration is trying to be clever and divine the required suffix--and it's failing and falling back to no suffix. If your package's configuration won't let you specify a suffix, the most expedient thing to do may be just to hack it on. But an upstream-worthy patch would add a means to specify an arbitrary suffix. Also, -mt is a saner default than no suffix at all. -- Braden McDaniel -- 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 Monday 30 November 2009 18:16:50 Adam Williamson wrote: > On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote: > > Gene, > > (Ahh... someone with a similar background...) > > > > So the biggest question, to me, is to what standard do we start? > > There are plenty to choose from from DISA to NIST. I, personally, > > find the NSA's "Guide to the Secure Configuration of Red Hat > > Enterprise Linux 5" very good and might be a good place to start. I'm > > not saying that we do everything that is in the guide but maybe take > > the guide and strike things out that don't make sense and add stuff to > > it that does make sense. > > Thanks for the thoughts, Gene and Eric. You seem to be running a long > way ahead here :). I should probably say that I think I mistitled the > thread: what I was really thinking about here is not 'security', but the > more limited area of 'privilege escalation'. I'm not sure we're ready to > bite off a comprehensive distro-wide security policy yet, to the extent > you two are discussing. But, you did say the right words for what is needed to do security QA and not just privilege escalation. > > 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. I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product. Gene -- 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 Monday 30 November 2009 22:40:07 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. > No. Initially, I recommend one security policy and one reference implementation to test against. Each variation needs its own security policy and reference implementation definition. Later ones are easier to create because they can use the early ones as "guidance". So, why go through all of this paperwork and bureaucratic bullshit? Well, those of us who have done this before believe that it is necessary. I do not like the bureaucratic BS any more than anyone else but, if you do not do it, then you are not quite sure what you have when you say that something meets security requirements. Gene -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build Failure regarding Boost
2009/12/1 Tim Niemueller : > Hi all. > > I'm trying to build the newest version 3.0.0 of the Player package. It > builds just fine on F11/F12, but it fails with an error that > "-lboost_thread" cannot be found on rawhide. boost-devel is in the BR, > boost-thread is being installed according to root.log. > > The package uses cmake for building, where I suspect the problem. On my > (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses > the non-mt version (well, a non-multithreaded threading library is kind > of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. > Is there a known problem? Does anyone else maintain a project build with > cmake and using Boost and can give a hint how to solve? aqsis use cmake and boost, but also explicitly tell which boost library to use. You may have to adapt the cmake option if they are non-standardized. Nicolas (kwizart) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (49/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 49/2009 Time: 2009-12-01 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-01 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-12-01/kde-sig.2009-12-01-14.13.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2009-12-01/kde- sig.2009-12-01-14.13.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * MaryEllenFoster * SebastianVahl * StevenParrish * ThanNgo * ThomasJanssen -- = Agenda = * Qt 4.6 * KDE 4.4 Beta 1 * KDE 4.3.4 * Phonon/PulseAudio issues due to the F12 Live CD missing xine-lib-pulseaudio = Summary = Qt 4.6: * Qt 4.6 is now available in rawhide. * In the next build a regression causing trouble in KMail will be fixed. * Qt 4.6 builds for F12 will probably not be build before KDE 4.4.0. KDE 4.4 Beta 1: * LukasTinkl is working on KDE 4.4 Beta 1 in rawhide. * WebKit support (which is currently disabled) needs to be reenabled. KDE 4.3.4: * ThanNgo started work on KDE 4.3.4. * There will likely be no update for F-10 (at least there was no clear decision because the EOL is quite near). Phonon/PulseAudio issues due to the F12 Live CD missing xine-lib-pulseaudio: * Missing xine-lib-pulseaudio on Fedora 12 Live images causes Phonon not to use Pulseaudio. * There seems to be no easy solution (or hacks) for enabling Pulseaudio again on an already installed system without overwriting settings that intentionally disabled Pulseaudio. * An updated Phonon from trunk with a supplied device-manager-module in Pulseaudio (#541419) could help in this issue by disabling Phonon's device management. [1] * KevinKofler is going to discuss shipping the device-manager module and Phonon PA integration with lennart. -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-08 -- = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=541419 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
gnucash updated to development branch in rawhide
As a consequence of the goffice update, I've updated gnucash to the 2.3.x development branch in rawhide. (Backporting the fixes for newer goffice-0.7.x series to the stable branch was looking a bit ugly, and 2.4.0 should be out well before F13 is frozen.) Of note is that this release includes the rewritten SQL backend for storage, and uses webkit for HTML rendering instead of gtkhtml. Please file bugs in bugzilla, etc. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On Tue, Dec 1, 2009 at 10:18 AM, Peter Jones wrote: > On 12/01/2009 10:42 AM, Sir Gallantmon wrote: > > > I found another tool that claims to be able to search and boot a USB > device, > > from a floppy disk no less! The tool is called PLoP[1], and it is a > custom > > boot manager that can boot USB, CD, and hard disks. > > > > Maybe that will help some people figure out how it is done. > > > > [1]: http://www.plop.at/en/bootmanager.html > > That's pretty neat, but probably not much help to us. What this is is a > custom (proprietary, closed source, it seems) bootloader which basically > does this: > > 1) installs what amounts to a DOS TSR driver for each of: > a) IDE (of some unspecified variety) > b) [EOU]HCI > c) ATAPI and similar (i.e. SCSI MMC/SBC command sets along with > encapsulation for CDROM and USB-storage) > d) notably not any SATA/AHCI/etc > 2) acts as a chainloading boot loader for whatever bootloader is on > media that it finds. > > Which is also just a fancy way of saying it /replaces/ some of your BIOS's > int 13h routines with what are plausibly slightly smarter (but also > plausibly slightly dumber) ones. > > If somebody wants to implement an open source version of this, it could be > helpful, I guess. But it's a lot of fairly difficult work, and the only > real advantage it has over the other scheme I've discussed is that the CD > (or whatever) you're booting from doesn't have to match the OS being > booted. > > Anyway, if somebody's looking for a truly complex and isolating project to > work on, go right ahead, but I'm not going to ;) > > -- > Peter > > The Shuttle is now going five times the sound of speed. >-- Dan Rather, first landing of Columbia > > Couldn't something like that be implemented into GRUB/GRUB2? Unlike PLoP, GRUB doesn't really have a size restriction, so maybe smarter methods of detection could be implemented. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 12/01/2009 10:42 AM, Sir Gallantmon wrote: > I found another tool that claims to be able to search and boot a USB device, > from a floppy disk no less! The tool is called PLoP[1], and it is a custom > boot manager that can boot USB, CD, and hard disks. > > Maybe that will help some people figure out how it is done. > > [1]: http://www.plop.at/en/bootmanager.html That's pretty neat, but probably not much help to us. What this is is a custom (proprietary, closed source, it seems) bootloader which basically does this: 1) installs what amounts to a DOS TSR driver for each of: a) IDE (of some unspecified variety) b) [EOU]HCI c) ATAPI and similar (i.e. SCSI MMC/SBC command sets along with encapsulation for CDROM and USB-storage) d) notably not any SATA/AHCI/etc 2) acts as a chainloading boot loader for whatever bootloader is on media that it finds. Which is also just a fancy way of saying it /replaces/ some of your BIOS's int 13h routines with what are plausibly slightly smarter (but also plausibly slightly dumber) ones. If somebody wants to implement an open source version of this, it could be helpful, I guess. But it's a lot of fairly difficult work, and the only real advantage it has over the other scheme I've discussed is that the CD (or whatever) you're booting from doesn't have to match the OS being booted. Anyway, if somebody's looking for a truly complex and isolating project to work on, go right ahead, but I'm not going to ;) -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Build Failure regarding Boost
Hi all. I'm trying to build the newest version 3.0.0 of the Player package. It builds just fine on F11/F12, but it fails with an error that "-lboost_thread" cannot be found on rawhide. boost-devel is in the BR, boost-thread is being installed according to root.log. The package uses cmake for building, where I suspect the problem. On my (F-11) machine it links with -lboost_thread-mt). But on rawhide it uses the non-mt version (well, a non-multithreaded threading library is kind of an issue). On my system I have cmake 2.6.3, while rawhide has 2.8.0. Is there a known problem? Does anyone else maintain a project build with cmake and using Boost and can give a hint how to solve? The failed build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=1840649 Any ideas to get this fixed are welcome, Tim -- Tim Niemueller www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On Tue, Dec 1, 2009 at 9:23 AM, Peter Jones wrote: > On 11/30/2009 01:27 PM, Peter Jones wrote: > > On 11/30/2009 12:27 PM, Matthias Clasen wrote: > >> 3. 'Chain-booting' from cd to usb sounds like an elegant way to avoid > >> the 'Can't boot USB' problem. Did we figure out how Mandriva are doing > >> it ? > > > > No, we didn't. There are some things we might be able to do here, though, > > which may solve this problem without actually "chain-booting". The most > > obvious is to make sure the live image's initrd searches for a USB device > > with the right filesystem label (and possibly other criteria) and mounts > > that as root, and then build a liveboot.iso with one boot image and no[1] > > real filesystem. The boot image would contain the kernel and initrd as > > the only boot option. > > > > This is fairly trivial to do, actually. > > > > [1] It'd have to have an iso9660 filesystem with the isolinux/ directory > > much like our current boot.iso does, but the kernel and initrd there > would > > be the ones from the live image, and we wouldn't put the rest of the live > > OS on the disc. > > > > Further research[1] seems to indicate that this is almost exactly what > they're doing. > > [1] Adam pointed me at > http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/rescue/make_flash_rescue?revision=263686&view=markup > > -- >Peter > > The Shuttle is now going five times the sound of speed. >-- Dan Rather, first landing of Columbia > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I found another tool that claims to be able to search and boot a USB device, from a floppy disk no less! The tool is called PLoP[1], and it is a custom boot manager that can boot USB, CD, and hard disks. Maybe that will help some people figure out how it is done. [1]: http://www.plop.at/en/bootmanager.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Answers from the Candidate Questionnaire now in the Wiki (Was: Candidate Questionnaire status)
On Wed, Nov 25, 2009 at 09:02:45AM +0100, Thorsten Leemhuis wrote: > Hi > > Me again ;-) > > Thorsten Leemhuis wrote on 24.11.2009 08:44: > > Thorsten Leemhuis wrote on 17.11.2009 20:47: > >> On 17.11.2009 07:54, Thorsten Leemhuis wrote: > >>> Thorsten Leemhuis wrote on 11.11.2009 22:30: > As you may have heard already, several seats of the Fedora > Board, FESCo, and FAMSCO are up for election soon(¹). Right now > we are in the nomination period, which will be followed by a > "Candidate Questionnaire." [...] > >> Deadline for answers: 20091124-06:00 UTC [...] > > Quick status update: I sent the questions to 23 people and 19 of them > > replied with the answers. I didn't get any replies to the questions (or > > my reminder mail from Sunday evening) from > > > > * Rodrigo Padula de Oliveira (RodrigoPadula) > > * Max Spevack (spevack) > > * Scott Seiersen (sseiersen) > > * Will Woods (wwoods) > > Max sent a apology, but the other remained silent afaics. > > > I hope to find time to work through the answers later today (in > > something like 12 hours from now) and publish them afterwards. > > Compiled a wiki page with the answers and gave the nominees 12 hours to > check the results. A few bugs were found and fixed, but I think > everything is fine now. > > So the answers are now free for public consumption on this page: > https://fedoraproject.org/wiki/Elections/F13_Questionnaire Thorsten, thanks for the time and effort you put into this. We'll make sure to notify the community that if they want to see results for a questionnaire for the next election, someone will need to take over this responsibility. Your help has been much appreciated! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Blocking radeonhd (was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?)
Dave Airlie (airl...@redhat.com) said: > On Fri, 2009-11-27 at 08:07 +0200, Pekka Savola wrote: > > Well, here's one graphics regression: > > https://bugzilla.redhat.com/show_bug.cgi?id=540476 > > > > radeon.modeset=0 worked around the problem. > > > > (I'm not sure if it's filed against the right component.) > > Don't use radeonhd, the Fedora X team don't support it and never have. > > I'm thinking it should reallyt be removed from the distro at this point > as it makes things worse rather than better. remove your xorg.conf > and turn modesetting on and if its still horrible, then we can talk. > > So you've proven you can break your own machine that is all. So, if our X maintainers won't handle bugs with it, we have a working default alternative that is maintained upstream, and it's *known* to be broken in the default configuration, why ship it? If we're trying to focus on quality, I'm not sure why we'd ship something that's known broken. Hans, are you OK if we block this from rawhide? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notification of uploads to the lookaside cache
Adam Jackson wrote: > Can we get an X-Fedora-Upload: header in these or something? > Filtering by subject line always makes me feel dirty. How about using the Keywords header? That way we can also use it to create a topic for the fedora-extras-commits list. Something like: Keywords: Fedora file upload ($package, $filename) perhaps? -- ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Tell a man there are 300 billion stars in the universe, he'll believe you. Tell him a bench has wet paint on it and he'll have to touch it to be sure. pgp3455PcwnQy.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 11/30/2009 01:27 PM, Peter Jones wrote: > On 11/30/2009 12:27 PM, Matthias Clasen wrote: >> 3. 'Chain-booting' from cd to usb sounds like an elegant way to avoid >> the 'Can't boot USB' problem. Did we figure out how Mandriva are doing >> it ? > > No, we didn't. There are some things we might be able to do here, though, > which may solve this problem without actually "chain-booting". The most > obvious is to make sure the live image's initrd searches for a USB device > with the right filesystem label (and possibly other criteria) and mounts > that as root, and then build a liveboot.iso with one boot image and no[1] > real filesystem. The boot image would contain the kernel and initrd as > the only boot option. > > This is fairly trivial to do, actually. > > [1] It'd have to have an iso9660 filesystem with the isolinux/ directory > much like our current boot.iso does, but the kernel and initrd there would > be the ones from the live image, and we wouldn't put the rest of the live > OS on the disc. > Further research[1] seems to indicate that this is almost exactly what they're doing. [1] Adam pointed me at http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/rescue/make_flash_rescue?revision=263686&view=markup -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notification of uploads to the lookaside cache
On Sat, 2009-11-21 at 19:34 -0500, Jon Stanley wrote: > As part of our ever vigilant stance towards security around our > packaging process, we have added a new feature to upload.cgi (which > accepts file uploads into the lookaside cache) which will email the > package owner (-ow...@fedoraproject.org, specifically) and > fedora-extras-comm...@redhat.com whenever a file is uploaded to the > lookaside cache. Previously this was a big black box and an area of > concern. > > The message will contain the name of the file, the package concerned, > the md5sum, and the user that uploaded it. An example is below: > > File upload.cgi for package sportrop-fonts has been uploaded to the > lookaside cache with md5sum 26489f9e92601f0f84cfbb278c2b98e1 by > jstanley > > Please let me know if you have any questions, comments, or room for > improvement! Can we get an X-Fedora-Upload: header in these or something? Filtering by subject line always makes me feel dirty. - ajax 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
rawhide report: 20091201 changes
Compose started at Tue Dec 1 08:15:10 UTC 2009 Broken deps for i386 -- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 blacs-mpich2-1.1-33.fc12.i686 requires libmpich.so.1.1 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 evolution-exchange-2.28.0-1.fc12.i686 requires libexchange-storage-1.2.so.3 galeon-2.0.7-19.fc13.i686 requires gecko-libs = 0:1.9.1.5 gnome-chemistry-utils-0.10.9-1.fc13.i686 requires libgoffice-0.6.so.6 gnucash-2.2.9-2.fc12.i686 requires libgoffice-0.6.so.6 1:gnumeric-1.8.4-5.fc13.i686 requires libgoffice-0.6.so.6 1:gnumeric-devel-1.8.4-5.fc13.i686 requires pkgconfig(libgoffice-0.6) hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.i686 requires libortp.so.7 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 maniadrive-1.2-18.fc12.i686 requires libphp5-5.3.0.so maniadrive-track-editor-1.2-18.fc12.i686 requires libphp5-5.3.0.so monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 postgis-jdbc-1.4.1-rc2_1.fc13.1.i686 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 postgis-utils-1.4.1-rc2_1.fc13.1.i686 requires postgis = 0:1.4.1rc2-rc2_1.fc13.1 raydium-1.2-18.fc12.i686 requires libphp5-5.3.0.so rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext_activerecord) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(locale) = 0:2.0.4 scalapack-mpich2-1.7.5-7.fc12.i686 requires libmpich.so.1.1 1:xmms-1.2.11-9.20071117cvs.fc12.i686 requires /usr/share/desktop-menu-patches/redhat-audio-player.desktop Broken deps for x86_64 -- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) blacs-mpich2-1.1-33.fc12.x86_64 requires libmpich.so.1.1()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) evolution-exchange-2.28.0-1.fc12.x86_64 requires libexchange-storage-1.2.so.3()(64bit) galeon-2.0.7-19.fc13.x86_64 requires gecko-libs = 0:1.9.1.5 gnome-chemistry-utils-0.10.9-1.fc13.i686 requires libgoffice-0.6.so.6 gnome-chemistry-utils-0.10.9-1.fc13.x86_64 requires libgoffice-0.6.so.6()(64bit) gnucash-2.2.9-2.fc12.x86_64 requires libgoffice-0.6.so.6()(64bit) 1:gnumeric-1.8.4-5.fc13.i686 requires libgoffice-0.6.so.6 1:gnumeric-1.8.4-5.fc13.x86_64 requires libgoffice-0.6.so.6()(64bit) 1:gnumeric-devel-1.8.4-5.fc13.i686 requires pkgconfig(libgoffice-0.6) 1:gnumeric-devel-1.8.4-5.fc13.x86_64 requires pkgconfig(libgoffice-0.6) hulahop-0.6.0-2.fc12.x86_64 requires xulrunner-python hulahop-0.6.0-2.fc12.x86_64 requires libpyxpcom.so()(64bit) inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python 7:kdenetwork-4.3.75-0.3.svn1048496.fc13.x86_64 requires libortp.so.7()(64bit) kst-fits-1.8.0-3.fc12.x86_64 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf.so.4()(64bit) kst-netcdf-1.8.0-3.fc12.x86_64 requires libnetcdf_c++.so.4()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) maniadrive-1.2-18.fc12.x86_64 requires libphp5-5.3.0.so()(64bit) maniadrive-track-editor-1.2-18.fc12.x86_64 requires libphp5-5.3.0.so()(64bit) monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686
Review request - django-lint
Hi everybody, just a few days ago I've made a package django-lint. rpmlint is happy, koji builder too. https://bugzilla.redhat.com/show_bug.cgi?id=540617 I'd be glad, if someone is willing and able to support me, since it's my first packet. Cheers, Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Package Review Stats for last 7 days ending 29th Nov
Top four FAS account holders who have completed reviewing "Package review" components on bugzilla for last 7 days ending 29th Nov were Steve Traylen, Andreas Osowski, Jiri Popelka and Mamoru Tasaka. Steve Traylen : 4 https://bugzilla.redhat.com/show_bug.cgi?id=516523 https://bugzilla.redhat.com/show_bug.cgi?id=516525 https://bugzilla.redhat.com/show_bug.cgi?id=516531 https://bugzilla.redhat.com/show_bug.cgi?id=516535 Andreas Osowski : 3 https://bugzilla.redhat.com/show_bug.cgi?id=529254 https://bugzilla.redhat.com/show_bug.cgi?id=529255 https://bugzilla.redhat.com/show_bug.cgi?id=529256 Jiri Popelka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=226106 https://bugzilla.redhat.com/show_bug.cgi?id=226206 https://bugzilla.redhat.com/show_bug.cgi?id=226665 Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=515230 https://bugzilla.redhat.com/show_bug.cgi?id=540791 https://bugzilla.redhat.com/show_bug.cgi?id=541185 Lubomir Rintel : 2 https://bugzilla.redhat.com/show_bug.cgi?id=536684 https://bugzilla.redhat.com/show_bug.cgi?id=537451 Parag AN(पराग) : 2 https://bugzilla.redhat.com/show_bug.cgi?id=541317 https://bugzilla.redhat.com/show_bug.cgi?id=539486 Peter Lemenkov : 2 https://bugzilla.redhat.com/show_bug.cgi?id=537897 https://bugzilla.redhat.com/show_bug.cgi?id=537563 Andrew Overholt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=510195 Antti Andreimann : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541004 Caolan McNamara : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541533 Chitlesh GOORAH : 1 https://bugzilla.redhat.com/show_bug.cgi?id=538087 Christof Damian : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529544 David Timms : 1 https://bugzilla.redhat.com/show_bug.cgi?id=508922 Jan Zeleny : 1 https://bugzilla.redhat.com/show_bug.cgi?id=175840 Jochen Schmitt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=538046 Kalev Lember : 1 https://bugzilla.redhat.com/show_bug.cgi?id=523224 Kevin Fenzi : 1 https://bugzilla.redhat.com/show_bug.cgi?id=541154 Matthew Kent : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539606 Michael Schwendt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533803 Michal Ingeli : 1 https://bugzilla.redhat.com/show_bug.cgi?id=534135 Michal Nowak : 1 https://bugzilla.redhat.com/show_bug.cgi?id=226423 Petr Machata : 1 https://bugzilla.redhat.com/show_bug.cgi?id=225789 Remi Collet : 1 https://bugzilla.redhat.com/show_bug.cgi?id=528469 Ryan Rix : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533765 Thomas Janssen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=526444 Total reviews modified: 37 Merge Reviews: 5 Review Requests: 32 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
On Tue, 1 Dec 2009 08:34:29 -0200, Paulo wrote: > On Mon, Nov 30, 2009 at 8:36 AM, Michal Schmidt wrote: > [patch] > Your patch almost worked. Audacious starts at the right volume level. > However, when audacious volume slider is hit for the first time, > the volume goes to the maximum again. I've explained that earlier in the thread. Audacious' volume slider does not reflect volume level changes made with external tools. Only with Audacious 2.2 that will become possible. [That also means that when you start Audacious, it does not know what volume level to show with its volume slider as it hasn't connected with Pulse Audio yet.] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
On Mon, Nov 30, 2009 at 8:36 AM, Michal Schmidt wrote:
> Dne Mon, 30 Nov 2009 11:12:38 +0100 Michael Schwendt napsal(a):
> > On Mon, 30 Nov 2009 10:38:15 +0100, Michal wrote:
> >
> > > Dne Mon, 30 Nov 2009 07:05:28 -0200 Paulo Cavalcanti napsal(a):
> > > > Thanks for the explanation.
> > > >
> > > > At least 3 applications are not restoring the volumes:
> > > >
> > > > xmms, mplayer and audacious.
> > >
> > > Interesting. Maybe these programs try to be too clever and force the
> > > volume themselves.
> >
> > It's not an attempt at being "too clever", but several upstream
> > developers feel lost in what they have to do or what they have not to
> > do to get something right. Temporarily, Audacious devlopers have
> > dropped their "pulse_audio" driver (originally from XMMS) even, since
> > they were of the impression that "it didn't work anyway". Ubuntu
> > users currently feel punished with Pulse Audio. With a first bunch of
> > fixes [for volume issues in Fedora 12 Rawhide, volume decreased for
> > every new song], the driver was restored again for Audacious 2.2
> > development. With more recent changes in Pulse Audio, it seems, more
> > changes are necessary. But Audacious 2.1 cannot reflect external
> > volume level changes in its UI anyway. Its volume slider cannot move
> > for volume level changes made with external tools. Only the next
> > release can do that, and it suffers from new bugs (such as a bug in
> > alsa-lib that will require an update in Fedora, too).
>
> Thanks for the explanation. Before I saw your reply, I played with
> audacious-plugins and made a kludge to prevent it from forcing 100 %
> volume on startup. It probably breaks something else, I haven't really
> tested it too much.
>
> Notice that the documentation for pa_stream_connect_playback strongly
> recommends passing NULL as volume.
>
> Index: audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c
> ===
> --- audacious-plugins-fedora-2.1.orig/src/pulse_audio/pulse_audio.c
> +++ audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c
> @@ -666,7 +666,7 @@ static int pulse_open(AFormat fmt, int r
> pa_stream_set_write_callback(stream, stream_request_cb, NULL);
> pa_stream_set_latency_update_callback(stream, stream_latency_update_cb,
> NULL);
>
> -if (pa_stream_connect_playback(stream, NULL, NULL,
> PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, &volume, NULL) <
> 0) {
> +if (pa_stream_connect_playback(stream, NULL, NULL,
> PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, NULL, NULL) < 0)
> {
> AUDDBG("Failed to connect stream: %s",
> pa_strerror(pa_context_errno(context)));
> goto unlock_and_fail;
> }
> @@ -715,6 +715,7 @@ static int pulse_open(AFormat fmt, int r
> }
>
> pa_operation_unref(o);
> +#if 0
> /* set initial volume */
> if (!(o = pa_context_set_sink_input_volume(context,
> pa_stream_get_index(stream), &volume, NULL, NULL))) {
> g_warning("pa_context_set_sink_input_volume() failed: %s",
> pa_strerror(pa_context_errno(context)));
> @@ -725,6 +726,7 @@ static int pulse_open(AFormat fmt, int r
> pa_threaded_mainloop_wait(mainloop);
> }
> pa_operation_unref(o);
> +#endif
>
> do_trigger = 0;
> written = 0;
>
>
>
Your patch almost worked. Audacious starts at the right volume level.
However, when audacious volume slider is hit for the first time,
the volume goes to the maximum again.
--
Paulo Roma Cavalcanti
LCG - UFRJ
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
On 12/01/2009 07:50 AM, Dan Williams wrote: On Mon, 2009-11-30 at 19:52 +, Terry Barnaby wrote: On 11/30/2009 06:12 PM, Dan Williams wrote: On Mon, 2009-11-30 at 09:55 +, Terry Barnaby wrote: On 11/29/2009 11:30 PM, Dan Williams wrote: On Sat, 2009-11-28 at 09:10 +, Terry Barnaby wrote: On 11/28/2009 08:35 AM, Rakesh Pandit wrote: 2009/11/28 Terry Barnaby wrote: If the NetworkManager service is running, but not managing the current network connection, then Firefox starts up in offline mode. Is this a bug in NetworkManager or Firefox ? This is odd behaviour and needs to be fixed. I would suggest open up a bug against firefox. I know one can change toolkit.networkmanager.disable preference, but it is a PITA for our users. One of use cases is: Sometime network manager does not connect me via my CDMA usb modem (in case signal is weak), but wvdial does and once I switch from NM to wvdial, my firefox gets to offline mode, which I don't expect it to as I am connected. Ok, filed as: 542078 NetworkManager is intended to control the default internet connection. If NetworkManager cannot control the default internet connection, then you may not want to use NetworkManager. In your case, you're using a mobile broadband device. The real bug here is that for whatever reason, NM/MM aren't connecting your modem, and we should follow up on that bug instead. Dan I am not using a mobile broadband device. The network connection my systems My mistake. I guess it was Rakesh Pandit who was using a CDMA 3G connection. use is not just the Internet it is a local network LAN connection that also serves the internet. Most of my systems use a local network server which provides NIS, /home and /data using NFS and VPN etc. I normally use the service "network" to bring up wired or wireless networking for this. Fedora, by default, uses NetworkManager to manage all network devices though. I use the service "network" as, for some reason, the NetworkManager service is started after the netfs and other services are started. Is there a reason for this ?? No particular reason, in fact that looks like a bug. NM no longer depends on HAL, but that dependency is still in the initscript, which looks like it pushes NM later than netfs. But in reality, you're looking for a dependency based initsystem which we don't quite yet have. There are already scripts that kick netfs to mount stuff when NM brings the network up (/etc/NetworkManager/dispatcher.d/05-netfs), so you get asynchronous bootup *and* your mounts. The rest of the system, if it requires something from the mounted directories, needs to be smart enough to know that. If you need to, you can set NETWORKWAIT=yes in /etc/sysconfig/network, which causes the NetworkManager initscript to block until a network connection is brought up, or 30 seconds have passed. I can obviously turn of the NetworkManager service, which I have done on the desktop systems. However, I also have a few Laptops that can roam. In F11 and before I have used the network and NetworkManager services. When the laptop boots away from home, the "network" service fails and I can then use the NetworkManager service to connect to whatever wireless network or G3 network is available. It does seem sensible to me that the "system" provides applications with info on if the network is up (not just the Internet). The NetworkManager service seems the place to do this and it looks like the applications are starting to use it for this purpose. So maybe a generic NM "isNetworkUp()" API call is called for ? See the other mail; the problem with a generic isUp() is that it simply says hey, is there a connection? It doesn't provide enough information about the networking state of the system for anything to make an intelligent decision about anything. It's a "hey I'm connected to something" but there's no information about *what* you're connected to; whether it's a secure home network, whether it's a slow 3G network, whether it's billed by the minute or the hour or unlimited, etc. Dan Hi, Thanks for the info. I would have thought that a generic isUp() is good enough for the likes of Firefox and Pidgen though to decide if to start offline. Being connected to a Network is probably all you need, you may be accessing an Intranet as all my systems Firefox home pages do ... Anyway, following your email (And notes in Bugzilla) I thought I'd try and use NM properly for my config. However I have a problem, which may be a bug. I have turned off the Network services and turned on NetworkManger. I have two main network interfaces eth0 (wired) and eth1 (Wifi), both are set to be managed by NM and to start at boot. I have also added NETWORKWAIT=yes in /etc/sysconfig/network. When I boot with this the network (eth1 (eth0 is disconnected)) does not come up at boot. There is a message stating a failure on the line where it is waiting for the network to come up. When I log in as a local user the network then c
