Fedora 12 x86 DVD images
Hi all, some Fedora users just pointed me out that the x86 DVD image names are not accurate. The install DVD is called Fedora-12-i386-DVD.iso while the live DVD is called Fedora-12-i686-Live.iso. Please note the i386 text in the install DVD file name. This is creating some confusion among users because they tend to believe that packages are still compiled for i386 and not for i686. Bye. Andrea. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
2009/11/23 Otto Haliburton ottohalibur...@tx.rr.com: - Original Message - From: Adam Williamson awill...@redhat.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Sent: Monday, November 23, 2009 3:03 PM Subject: Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM On Mon, 2009-11-23 at 12:44 +0100, Andreas Tunek wrote: I seem to get crashes when I sometimes close tabs in Epiphany of Firefox. I have a ATI Mobile 340 (based on the R100 series I think). I do not get the same error on my other computer with intel gfx. That has absolutely nothing to do with what Liang posted, but please do file a separate bug report for it: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems thanks! again criticizing the reporter for reporting his case. That was what he was doing when it crashed, he might not know that it is unrelated, but just reporting what he was doing at the time of the crash. I did not feel very criticized :) I should file a bug, I just haven't got around to it yet. Maybe tonight :) -- 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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Am 23.11.2009 22:50, schrieb Adam Williamson: He already said that he had talked to his upstreams and they had said they would not adjust their code. In that case, he really has done everything he possibly can in his position as maintainer, and sending him further nag emails is achieving nothing constructive and serving only to annoy him. And eventually may lead to packagers stopping to contribute to the Fedora Project. I do not wish to be used as a medium for a fight between a stubborn Font Guideline Evangelist and a stubborn upstream. If it's upstream's decision not to adjust their code then that's the way it is. If the package does not cause any unexpected behavior by not following the Font Guidelines there is nothing further I as a package maintainer am required to do. Felix -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091124 changes
Compose started at Tue Nov 24 08:15:09 UTC 2009
New package erlang-erlsom
Support for XML Schema in Erlang
New package libcue
Cue sheet parser library
New package libunistring
GNU Unicode string library
New package pidgin-sipe
Pidgin plugin for connecting to MS Communications Server
New package polkit-qt
Qt bindings for PolicyKit
New package rubygem-marc
Ruby library for MARC catalog
New package rubygem-minitest
Small and fast replacement for ruby's huge and slow test/unit
Removed package kdebluetooth
Updated Packages:
Cython-0.12-1.fc13
--
* Mon Nov 23 2009 Neal Becker ndbeck...@gmail.com - 0.12.1-1.rc1
- Update to 0.12.1
* Mon Nov 23 2009 Neal Becker ndbeck...@gmail.com - 0.12-1.rc1
- Make that 0.12
Glide3-20050815-10.fc13
---
* Mon Nov 23 2009 Adam Jackson a...@redhat.com 20050815-10
- Fix BuildRequires for new DGA and VidMode packaging (#538961)
MySQL-python-1.2.3-0.4.c1.fc13
--
* Mon Nov 23 2009 Tom Lane t...@redhat.com 1.2.3-0.4.c1
- Fix format mismatch in _mysql_ConnectionObject_kill
Resolves: #538234
R-qtl-1.14.2-2.fc13
---
* Sun Nov 22 2009 Mattias Ellert mattias.ell...@fysast.uu.se - 1.14.2-2
- Modify build for R 2.10 and higher - remove scriptlets
SoQt-1.4.1-14.fc13
--
* Mon Nov 23 2009 Ralf Corsépius corse...@fedoraproject.org - 1.4.1-14
- Let soqt-config search in %{_libdir}/Coin2.
Vuurmuur-0.7-7.fc13
---
* Mon Nov 23 2009 Stjepan Gros stjepan.g...@gmail.com - 0.7-7
- Parallel make enabled for libvuurmuur and disabled for vuurmuur_conf
amarok-2.2.1-3.fc13
---
* Mon Nov 23 2009 Rex Dieter rdie...@fedoraproject.org - 2.2.1-3
- rebuild (for qt-4.6.0-rc1, f13+)
autofs-5.0.5-10.fc13
* Tue Nov 24 2009 Ian Kent ik...@redhat.com - 1:5.0.5-10
- fix pidof init script usage.
avogadro-1.0.0-3.fc13
-
* Mon Nov 23 2009 Rex Dieter rdie...@fedoraproject.org - 1.0.0-3
- rebuild (for qt-4.6.0-rc1, f13+)
avr-binutils-2.20-2.fc13
avr-gcc-4.4.2-2.fc13
bitfrost-1.0.4-1.fc13
-
blender-2.49b-3.fc13
* Mon Nov 23 2009 Jochen Schmitt Jochen herr-schmitt de 2.49b-3
- Remove symlink to DejaVu font from package
cluster-glue-1.0-0.12.b79635605337.hg.fc13
--
* Mon Nov 23 2009 Andrew Beekhof and...@beekhof.net - 1.0-0.12.b79635605337.hg
- Correctly select libuuid for building on rhel =6
* Mon Oct 12 2009 Andrew Beekhof and...@beekhof.net - 1.0-0.11.b79635605337.hg
- Add install dependancy on perl-TimeDate for hb_report
- Update to upstream version b79635605337
+ Build: fix defines for pacemaker-pygui compatibility.
+ High: Tools: hb_report: log/events combining
+ High: doc: new README for wti_mpc
+ High: hb_report: add man page hb_report.8
+ High: hb_report: extract important events from the logs
+ High: stonith: external/ibmrsa-telnet: add support for later RSA cards
+ High: stonith: wti_mpc: support for MIB versions 1 and 3
+ Logd: Start/stop priorities are not created by configure
+ Med: sbd: Fix definition of size_t.
+ Med: sbd: Nodename comparison should be case insensitive (bnc#534445)
+ Med: wti_nps: add support for internet power switch model (bnc#539912)
+ Medium (LF 2194): LRM: fix return code on RA exec failure
+ Medium: Tools: hb_report: add -v option (debugging)
+ Medium: Tools: hb_report: options -C and -D are obsoleted
+ ha_logd: Fix a compile error/warning.
+ hb_report: report corosync packages too.
+ sbd: Accept -h (bnc#529574)
+ sbd: really fix the sector_size type.
cups-1.4.2-10.fc13
--
* Mon Nov 23 2009 Tim Waugh twa...@redhat.com 1:1.4.2-9
- Fixed small typos introduced in fix for bug #536741.
* Mon Nov 23 2009 Tim Waugh twa...@redhat.com 1:1.4.2-10
- Undo last change as it was incorrect.
dhcp-4.1.0p1-14.fc13
* Mon Nov 23 2009 Jiri Popelka jpope...@redhat.com - 12:4.1.0p1-14
- Honor DEFROUTE=yes|no for all connection types (#530209)
eclipse-callgraph-0.4.0-1.fc13
--
* Mon Nov 23 2009 Charley Wang chw...@redhat.com 0.4.0-1
- Update to version 0.4 of Linux Tools Project and remove tests feature
eclipse-eclox-0.8.0-4.20090616svn.fc13
--
* Mon Nov 23 2009 Alexander Kurtakov akurt...@redhat.com 0.8.0-4.20090616svn
- Fix build.
etoys-4.0.2332-2.fc13
-
* Mon Nov 23 2009 Daniel Drake d...@laptop.org - 4.0.2332-2
- don't own /usr/share/sugar/activities and move sugar activity to subpackage
fedora-gnome-theme-13.1-1.fc13
--
* Tue Nov 24 2009 Matthias Clasen mcla...@redhat.com 13.0-1
- Drop fedora-icon-theme dep, use Mist directly
* Tue Nov 24 2009 Matthias Clasen mcla...@redhat.com 13.1-1
- Revert the previous change, since we need the Fedora
heads-up: Oracle db-4.8.24 in rawhide
Hi, this is a short announce that there is a new db4 in rawhide for a while now. Please modify your package accordingly and consider rebuild. Older db-4.7.25 is now moved to compat-db so no broken dependencies should occur. If your package uses the /usr/bin/db* utilities please consider immediate rebuild as these are not present in the compat-db package. Thanks, Jindrich -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
review swaps
I have a couple of imaging-related packages, I'm happy to swap reviews for them: jai-imageio-core - Core Java Advanced Imaging Image I/O Tools API https://bugzilla.redhat.com/show_bug.cgi?id=536944 This is a plugin for Java that enables support for BMP, GIF, PCX, PNM, Raw (not digital camera RAW), TIFF, PCX, WBMP. Does not support JPEG 2000 or JAI stuff, since that is not free software. mingw32-openjpeg - mingw32 package for openjpeg https://bugzilla.redhat.com/show_bug.cgi?id=537897 Win32 version of OpenJPEG, a JPEG 2000 library. Adam signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 14:17, Felix Kaechele a écrit : Am 23.11.2009 22:50, schrieb Adam Williamson: He already said that he had talked to his upstreams and they had said they would not adjust their code. In that case, he really has done everything he possibly can in his position as maintainer, and sending him further nag emails is achieving nothing constructive and serving only to annoy him. And eventually may lead to packagers stopping to contribute to the Fedora Project. I do not wish to be used as a medium for a fight between a stubborn Font Guideline Evangelist and a stubborn upstream. If it's upstream's decision not to adjust their code then that's the way it is. If the package does not cause any unexpected behavior by not following the Font Guidelines there is nothing further I as a package maintainer am required to do. To repeat myself once again, core fonts are not free, they have a maintenance cost, and none of the packagers that claimed using core fonts is not a problem so far has made the logical step of taking charge of what they say is no problem. Either it is no problem, and you are ready to take it out of my hands, or it is a problem, so stop pretending it is not and I'm unreasonable saying it is so. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 19:01 -0500, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? If I am not misunderstand, can you point me to the real reason that this feature was removed? Your understanding is not correct. The 'feature that was removed' is retention of authorizations (for more than a very short period). PolicyKit 0.x had keep_always policies, which asked a user to authenticate for an operation just once and then kept that authorization indefinitely. These are what were removed in PolicyKit 1.x, leaving only the keep policies, which retain authorization for just a few minutes. -- 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
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: To repeat myself once again, core fonts are not free, they have a maintenance cost, What is the real maintenance cost? You have said that core fonts are not going away, so the maintenance cost will not go away. How is badgering other maintainers a good thing? If you don't want to maintain something, then the normal way is to orphan it and let someone else take the job, not badger everybody else using the thing you don't want to maintain anymore. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
Rahul Sundaram wrote: On 11/24/2009 02:21 AM, Ben Williams wrote: If release engineering would like to release liveusb.iso for people to use to install or just to look at the new features, that is fine But from the #fedora channel the # of people installing off of the livecd images are very high (if you want to search the logs i am sure they can be provided, and yes the # installing useing the livecd.iso on usb is high as well.) Have you done a survey asking if a 1 GB Live image won't satisfy their needs? To reverse the question - has there been any solicitation of feedback about how many people would be adversely affected by this change? This is the first I'd heard of it. I appreciate the desire to put more content on the default desktop spin and think it would be a good thing to be able to include this sort of material, but please be aware that this will adversely affect a number of users (actual or potential) of fedora (and no I can't tell you how many). To give you a couple of scenarios for uses this will affect: 1) Plenty of hardware being used today doesn't support booting from USB and doesn't have a DVD drive. I've seen many of these machines turned over to using linux after grinding to a halt running other OSs. 2) Plenty of people don't have a network conection or bandwidth cap which would allow them to do a live install. Even my ADSL connection in the UK wouldn't be able to do this. Anyone with a combination of problems 1 and 2 is now unable to easily install F13+. Before discarding the idea of CD images all together would it not be worth finding out how many users this might affect? The other problem I would have is that I give away plenty of CDs. They're dirt cheap and it's easy to have a few lying around to distribute when necessary. I'm not about to start giving away USB keys instead. On a larger scale I've been involved with Software Freedom Day where we distribute hundreds of CDs of free software. We couldn't afford to move to DVDs (because of cost, time to burn and coverage of hardware) so Fedora would have to be removed from the list of discs our group distributed. I'm all for having the USB image as well, but if there's any way to keep a live CD then some of us would really appreciate it. Thanks for listening Simon. -- 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/24/2009 08:35 PM, Simon Andrews wrote: Rahul Sundaram wrote: On 11/24/2009 02:21 AM, Ben Williams wrote: If release engineering would like to release liveusb.iso for people to use to install or just to look at the new features, that is fine But from the #fedora channel the # of people installing off of the livecd images are very high (if you want to search the logs i am sure they can be provided, and yes the # installing useing the livecd.iso on usb is high as well.) Have you done a survey asking if a 1 GB Live image won't satisfy their needs? To reverse the question - has there been any solicitation of feedback about how many people would be adversely affected by this change? This is the first I'd heard of it. I appreciate the desire to put more content on the default desktop spin and think it would be a good thing to be able to include this sort of material, but please be aware that this will adversely affect a number of users (actual or potential) of fedora (and no I can't tell you how many). To give you a couple of scenarios for uses this will affect: 1) Plenty of hardware being used today doesn't support booting from USB and doesn't have a DVD drive. I've seen many of these machines turned over to using linux after grinding to a halt running other OSs. 2) Plenty of people don't have a network conection or bandwidth cap which would allow them to do a live install. Even my ADSL connection in the UK wouldn't be able to do this. Anyone with a combination of problems 1 and 2 is now unable to easily install F13+. Before discarding the idea of CD images all together would it not be worth finding out how many users this might affect? We are not discarding CD images all together. If you feel there is a compelling reason to continue with a Live CD, I am afraid you will have to step up and do it. The tools are easy enough to learn and I am willing to help you or anyone else interested. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 24 Nov 2009, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. See, this is the problem, with all the exceptions you'd need to codify it would make much more sense to document how to set them up and make it relatively easy to do so that the local admin can do so. Think of it like documentation for sudo but with docs that don't make everyone cry. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tuesday, 24 November 2009 at 16:24, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. I can imagine an additional drop-down list of user roles on the user account creation screen in firstboot GUI. What you described above would be a home user. However, parents may not want to let their kids install all the games they can from Fedora software collection, so we'd also need some tool to manage allowed root-level actions associated with these roles. Looks like a kind of enhanced sudo to me. ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
Thanks, everyone. I update to kernel-2.6.31.6-148, compiz and gnome-shell return to normal. I think that I should write a post after searching the FP wiki for radeon and KMS, Liang -- urlhttp://www.liangsuilong.info/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 24.11.2009 16:00, schrieb Chris Adams: What is the real maintenance cost? You have said that core fonts are not going away, so the maintenance cost will not go away. How is badgering other maintainers a good thing? If you don't want to maintain something, then the normal way is to orphan it and let someone else take the job, not badger everybody else using the thing you don't want to maintain anymore. Unfortunately, I have not following the discussion about X core fonts and I'm not a font specialist. If you mean the original bitmap oriented fonts of X11, so they are several reasons to avoid the usage of this kinds of fonts. The may issue with this fonts is, that they are not scaleable to any size you want. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAksL/8oACgkQZLAIBz9lVu/XVwQAqiDLEJfCAxFSTVRaXc2iCod8 buWz0rHqZ1EF2HrULNZP8/5f5XI6pOwmke1R52Zv/q29qWmIHTqTBSUByRfCsnbg 1D4SWmV3tLyiDnX8VyTjia5Qmd3gFVu+swWrZoErvOC0byW6HCFympdnM8pXfd/g ArpyT/VQiG5BpAWESAU= =K0tx -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 16:00, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: To repeat myself once again, core fonts are not free, they have a maintenance cost, What is the real maintenance cost? You have said that core fonts are not going away, so the maintenance cost will not go away. The costs could go down to nothing if there was no core font user left in Fedora How is badgering other maintainers a good thing? It is reducing the problem envelope. If you don't want to maintain something, then the normal way is to orphan it and let someone else take the job, not badger everybody else using the thing you don't want to maintain anymore. Does not work that way. If it was a clear package dependency, I could orphan the stuff, and all the people who complain at me now would be forced to take themselves in charge and do the work needed by the stuff they use. Because of the brain-damaged way core fonts were specified, the dependency is not expressed in that way and I can not stop caring about core fonts without stopping caring about other fonts (because as long as I have a fonts hat, and no one has a core fonts one, people come to me by default and don't want to hear about differences in font systems). If you insist, I can ask formally FESCO if it thinks I do more harm than good. It it thinks so, I'll do the logical thing, and go back to being just the DejaVu maintainer, which was actually fun to do, and less time-wasting besides. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le Mar 24 novembre 2009 16:00, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: To repeat myself once again, core fonts are not free, they have a maintenance cost, What is the real maintenance cost? You have said that core fonts are not going away, so the maintenance cost will not go away. The costs could go down to nothing if there was no core font user left in Fedora That's not an answer. What is the real maintenance cost? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Nicolas Mailhot wrote: The costs could go down to nothing if there was no core font user left in Fedora Surely some are required for external legacy applications (including free software and propitiatory applications)? Even logging into a remote old linux system will require the old font system. Jeremy -- http://jeremysanders.net/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
On Tue, 2009-11-24 at 16:59 +0100, Nicolas Mailhot wrote: Le Mar 24 novembre 2009 16:00, Chris Adams a écrit : What is the real maintenance cost? You have said that core fonts are not going away, so the maintenance cost will not go away. The costs could go down to nothing if there was no core font user left in Fedora .. continuing the reasoning: if there were no packages in Fedora, the maintenance costs would vanish. However, there is still a justification for legacy software. Even if some utility only supported the ASCII code set, it would be stupid to bar its inclusion just because it doesn't support UTF-8, as it probably was not designed to serve that purpose. If you don't want to maintain something, then the normal way is to orphan it and let someone else take the job, not badger everybody else using the thing you don't want to maintain anymore. Does not work that way. If it was a clear package dependency, I could orphan the stuff, and all the people who complain at me now would be forced to take themselves in charge and do the work needed by the stuff they use. Because of the brain-damaged way core fonts were specified, the dependency is not expressed in that way and I can not stop caring about core fonts without stopping caring about other fonts (because as long as I have a fonts hat, and no one has a core fonts one, people come to me by default and don't want to hear about differences in font systems). Don't fix what ain't broken. There are always st00p1d users asking silly questions on the internet. Instead of ranting about legacy fonts that have been used for decades, you can direct your energy towards something useful: making sure that new fonts that are compatible with modern font handling systems are correctly packaged. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On 11/20/2009 01:06 PM, Jiri Moskovcak wrote: snip 1-4 are more RFEs for bugzilla, but I'll try to elaborate here and start some discussion: 1. Can Fedora enable anonymous/unauthenticated bug submission. We're thinking about this, but it can be flood the BZ, so the solution might be, that anonymous reports won't go directly to BZ. We can ge some ideas from kerneloops.org. What about to use user abrt as a reporter? Which will be set by default and would be able to change. This user abrt will have some limited privileges in bugzilla (just only to report bugs for example). snip RR -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F12 install stops at screen switch (language select)
Hi, I had the crazy idea to try F12 again on an IBM system (SurePOS 565, specific Point-of-Sale hardware, with 82915G/GV/910GL), on which RHEL4 was the last RHEL/Fedora version I could install without problems (see also https://bugzilla.redhat.com/show_bug.cgi?id=339361 for some comments about RHEL5 on this system). Well, while graphics didn't work at some point in older releases (I don't remember which Fedora I tried last, maybe F9 or F10), now the install stops even earlier, just after: running /sbin/loader detecting hardware waiting for ... Then the screen blanks (instead of showing the language selection) and I can't do anything more than CTRL-ALT-DEL. Any suggestions? Thanks, -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- 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 23, 2009 at 06:10:59PM -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. I'm very much against that. Fedora, Linux, and Unix-like operating systems have built a reputation as a more secure alternative to Windows and other operating systems. We have to have some level of security that comes enabled on all systems no matter what the spin. Also, conflating Fedora with the Desktop Spin is something I'm very uncomfortable with here. A spin meant to highlight what the authors think is the most convenient experience for a single user desktop system apparently wants to do things that I am not at all for highlighting as the default Fedora environment. We need to separate these so that the Desktop Spin can live its own life without the additional constraints of being Fedora. -Toshio pgpa3sZCYOABb.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 24 Nov 2009 10:38:49 +0100 Andrea Musuruane musur...@gmail.com wrote: Hi all, some Fedora users just pointed me out that the x86 DVD image names are not accurate. The install DVD is called Fedora-12-i386-DVD.iso while the live DVD is called Fedora-12-i686-Live.iso. Please note the i386 text in the install DVD file name. This is creating some confusion among users because they tend to believe that packages are still compiled for i386 and not for i686. Yeah, everything was supposed to be 'i386' for f12. i386 in this case meaning 32 bit. ;( I agree this causes confusion... kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 10:38 +0100, Andrea Musuruane wrote: Hi all, some Fedora users just pointed me out that the x86 DVD image names are not accurate. The install DVD is called Fedora-12-i386-DVD.iso while the live DVD is called Fedora-12-i686-Live.iso. Please note the i386 text in the install DVD file name. This is creating some confusion among users because they tend to believe that packages are still compiled for i386 and not for i686. Bye. Andrea. The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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
PolicyKit and syslog
One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'. PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 17:01, Chris Adams a écrit : That's not an answer. What is the real maintenance cost? I already explained yesterday : there are rotting Fedora Core packages to merge review, packaging guidelines to write to define how they are supposed to be cleaned up, a huge pile of existing fonts to re-check for licensing, a huge pile of fonts to re-check for technical soundness (ie a lot of fonts for that area are not encoded properly or declare bad names, should it continue to be hidden via manual fonts.dir or should they be converted to something cleaner, it we continue to go the manual fonts.dir way someone needs to review existing files) etc. We still had crashes this year due to problems in some fonts.dir. When i18n asked what was the exact need for bitmap-fonts no one answered. There is a need of someone that can answer other Fedora groups when such questions are asked. etc, etc -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote: One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'. PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? PolicyKit itself is not running anything. It is just answering the question of a mechanism: 'is X allowed to do foo ?'. It would make more sense for the mechanisms that use PolicyKit to log privileged actions that they do or deny to do. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 17:06, Jeremy Sanders a écrit : Nicolas Mailhot wrote: The costs could go down to nothing if there was no core font user left in Fedora Surely some are required for external legacy applications (including free software and propitiatory applications)? If no one Fedora-side wants to do the work, this is a problem for RHEL. The Fedora xorg team as far as I've seen only checks the core fonts code stays operational and the built-in core fonts work. Current Fedora core fonts apps exercise much more than that. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le Mar 24 novembre 2009 17:09, Jussi Lehtola a écrit : uestions on the internet. Instead of ranting about legacy fonts that have been used for decades, you can direct your energy towards something useful: making sure that new fonts that are compatible with modern font handling systems are correctly packaged. As I've already stated, I'm ready to ask the usefulness question to FESCO. But I don't owe you doing one and not the other if you don't want to help me so the other does not interferes with my main interest. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (48/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: 48/2009 Time: 2009-11-24 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-24 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-24/fedora-meeting.2009-11-24-13.59.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-24/fedora-meeting.2009-11-24-13.59.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * StevenParrish * ThanNgo * MaryEllenFoster -- = Agenda = * Shaman 2 for Fedora? It's plugable package management tool by Dario Freddi, he asks for comments and what we want for Fedora (if we want to ship it, at least as optional package - he's working on PackageKit support right now) * soprano/sesame2 status report [1] * KDE 4.3.3 : in updates-testing, ready for stable updates ? * KDE 4.3.75 Builds almost done (kdebindings, kdepim, extragear left) Issues: kdelibs -- Konsole menu item patch is obsolete (kde-settings may be able to fix this) kdebindings -- Build failure; fails to find its own built libs (??) kdepim -- one .desktop file of unknown usefulnes getting caught in the validator = Summary = Shaman 2 for Fedora * jreznik to work on shaman2 packaging soprano/sesame2 status report * mefoster will submit package reviews soon and keep [2] updated KDE 4.3.3 : in updates-testing, ready for stable updates? * rdieter will queue kde-4.3.3 bits for stable updates KDE 4.3.75 * mathstuff to merge 4.3.75 into rawhide asap (tue or wed) to be ready for kde-4.4-beta1 -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-12-01 -- = Links = [1] http://lists.fedoraproject.org/pipermail/fedora-kde/2009- November/004709.html [2] https://fedoraproject.org/wiki/MaryEllenFoster/SopranoSesame -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le Mar 24 novembre 2009 17:01, Chris Adams a écrit : That's not an answer. What is the real maintenance cost? I already explained yesterday : there are rotting Fedora Core packages to merge review, packaging guidelines to write to define how they are supposed to be cleaned up, a huge pile of existing fonts to re-check for licensing, a huge pile of fonts to re-check for technical soundness (ie a lot of fonts for that area are not encoded properly or declare bad names, should it continue to be hidden via manual fonts.dir or should they be converted to something cleaner, it we continue to go the manual fonts.dir way someone needs to review existing files) etc. And how much of this is still going to be done no matter what, since core font support is not going to be dropped? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthew Miller wrote: One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'. PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? I see nothing noting any changes to the policy state whatsoever. I'd recommend filing this as a bug. thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthias Clasen wrote: On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote: One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'. PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? PolicyKit itself is not running anything. It is just answering the question of a mechanism: 'is X allowed to do foo ?'. It would make more sense for the mechanisms that use PolicyKit to log privileged actions that they do or deny to do. when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote: when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. That might be ok to log, indeed. polkitd need not be running, though. It is activated as needed. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. That I would consider spamming. But maybe at absurd log levels... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bug triage: further change upcoming
Hi, guys. Just a quick note - Matej Cepl pointed out that the already-agreed BugZappers plan to switch to using the Triaged keyword only for Fedora 13 and later presents problems. Most significantly, it's impossible to reliably construct a Bugzilla search which will find bugs that have been triaged under *both* the F13+ and F12- methods. So, we've come up with a plan. With the help of David Lawrence we propose to add the Triaged keyword to all existing F10-F12 bugs that are in ASSIGNED state, with the exception of anaconda bugs, PackageReview bugs and FutureFeature bugs. No other change will be made to the bugs (they won't, for instance, be changed back to NEW). This will be done without generating any email notifications, so there won't be an email flood. We can't think of any problems this could cause; some bugs that haven't actually gone through the triage process may get marked as 'Triaged', but that won't have any negative effects. All we really use the flag for is searching to find which bugs need triage and which don't. If anyone can see why this may present a big problem, please let us know; we're holding off on the change for a day or so just in case. Thanks. -- 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
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthias Clasen wrote: On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote: when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. That might be ok to log, indeed. polkitd need not be running, though. It is activated as needed. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. That I would consider spamming. But maybe at absurd log levels... Policy changes should be warning level notices b/c it notes a change in state. any/all communication should be at debug level notices. debugging is a lot easier when you can follow the whole process along. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug triage: further change upcoming
On 11/24/2009 10:32 PM, Adam Williamson wrote: Hi, guys. Just a quick note - Matej Cepl pointed out that the already-agreed BugZappers plan to switch to using the Triaged keyword only for Fedora 13 and later presents problems. Most significantly, it's impossible to reliably construct a Bugzilla search which will find bugs that have been triaged under *both* the F13+ and F12- methods. So, we've come up with a plan. With the help of David Lawrence we propose to add the Triaged keyword to all existing F10-F12 bugs that are in ASSIGNED state, with the exception of anaconda bugs, PackageReview bugs and FutureFeature bugs. Why the exception for Anaconda? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Hide the kittens and the babies, a message from your friendly KDE-SIG
For those brave souls still running or trying to run rawhide just wanted to let you know that KDE is broken. As we speak most Qt based apps will just crash with a message about a missing symbol. To top that we are also preparing for KDE 4.4 beta 1; so don't expect a quick resolution, in fact things will get worse before they get better. Look on the bright side, F12 is rock solid, and with your patience F13 will be even better. We are shooting to have everything fixed by Monday the 30th, so please bear with us as we work to bring you another great KDE release. Steven -- = Steven M. Parrish - gpg fingerprint: 4B6C 8357 059E B7ED 8095 0FD6 1F4B EDA0 A9A6 13C0 http://tuxbrewr.fedorapeople.org/ irc.freenode.net: SMParrish @ #fedora-kde, #fedora-olpc, #sugar, #fedora- devel ___ 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: Bug triage: further change upcoming
On Tue, 2009-11-24 at 22:35 +0530, Rahul Sundaram wrote: On 11/24/2009 10:32 PM, Adam Williamson wrote: Hi, guys. Just a quick note - Matej Cepl pointed out that the already-agreed BugZappers plan to switch to using the Triaged keyword only for Fedora 13 and later presents problems. Most significantly, it's impossible to reliably construct a Bugzilla search which will find bugs that have been triaged under *both* the F13+ and F12- methods. So, we've come up with a plan. With the help of David Lawrence we propose to add the Triaged keyword to all existing F10-F12 bugs that are in ASSIGNED state, with the exception of anaconda bugs, PackageReview bugs and FutureFeature bugs. Why the exception for Anaconda? at present anaconda is in a state of having opted-out from the typical triage process, so we generally leave them out of things like this and let them handle their own bugs. in practice this change was actually partly designed to bring the bugzappers practice and anaconda practice closer together, and in future this may well change, but for now we're leaving it out just to be consistent with the current official status of anaconda wrt bugzappers. -- 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
Re: PolicyKit and syslog
On Tue, Nov 24, 2009 at 11:35:13AM -0500, Matthias Clasen wrote: PolicyKit itself is not running anything. It is just answering the question of a mechanism: 'is X allowed to do foo ?'. It would make more sense for the mechanisms that use PolicyKit to log privileged actions that they do or deny to do. That makes sense. However, I can see strengths in both approaches. A good analogy is PAM, particularly the auth section, which does basically the same thing¹ as PolicyKit. There, you get logs both from the application itself and from PAM directly. There are four particular strengths I see in logging at the PolicyKit level. 1) Existing applications don't need to be changed, and new applications don't need to be counted on to do the right thing. Appropriate logging just starts happening. 2) Log levels and debugging are easier to admin because there's a central configuration (and PolicyKit already has config files). If I want to turn on more authentication 3) Log messages are automatically consistent between programs, making analysis and monitoring much easier. 4) PolicyKit is in a position to log more about the decisions it makes than is (or should be) exposed to the client application. This can be particularly useful for debugging but may also be useful for auditing. (If a user was allowed access for a certain reason, and that reason turns out to be something they shouldn't have access to but do, we can know to investigate.) Also, since this is a security/auditing issue, I thing it's never wrong to error on the side of more logging. I absolutely agree that client applications should also log their elevated-privilege actions. 1. In fact, a PAM-backed authority for PolicyKit might be interesting and useful -- but there's a tangent. -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, Nov 24, 2009 at 11:47:03AM -0500, Seth Vidal wrote: I'd recommend filing this as a bug. I definitely will -- I just want to get some feedback first. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 2009-11-24 at 10:27 -0500, Seth Vidal wrote: On Tue, 24 Nov 2009, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. See, this is the problem, with all the exceptions you'd need to codify it would make much more sense to document how to set them up and make it relatively easy to do so that the local admin can do so. Think of it like documentation for sudo but with docs that don't make everyone cry. Oh, I agree 100%. My bad for not explaining what I meant. I'm not saying the GUI pkg installer should come with the above as defaults, just that it should work towards being able to easily provide the above functionality. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 2009-11-24 at 12:29 -0500, Matthew Miller wrote: 1. In fact, a PAM-backed authority for PolicyKit might be interesting and useful -- but there's a tangent. What do you think PolicyKit is using for authentication ? See http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polkitagenthelper.c -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
On 11/24/2009 04:17 PM, Jos Vos wrote: Hi, I had the crazy idea to try F12 again on an IBM system (SurePOS 565, specific Point-of-Sale hardware, with 82915G/GV/910GL), on which RHEL4 was the last RHEL/Fedora version I could install without problems (see also https://bugzilla.redhat.com/show_bug.cgi?id=339361 for some comments about RHEL5 on this system). Well, while graphics didn't work at some point in older releases (I don't remember which Fedora I tried last, maybe F9 or F10), now the install stops even earlier, just after: running /sbin/loader detecting hardware waiting for ... Then the screen blanks (instead of showing the language selection) and I can't do anything more than CTRL-ALT-DEL. Any suggestions? Thanks, Try adding the kernel parameters nomodeset and xdriver=vesa or xdriver=intel and vga=ask and select any of the 24 bit values offered.. If install is successful then boot into run level 3 and run Xorg -configure and adapt accordingly something like.. Section ServerLayout IdentifierLayout[all] InputDevice Keyboard[0] CoreKeyboard InputDevice Mouse[1] CorePointer InputDevice Mouse[3] SendCoreEvents OptionClone off OptionXinerama off ScreenScreen[0] EndSection Section InputDevice Driverdriver IdentifierMouse[3] OptionButtonNumber 1 OptionButtonThreshold 17 OptionDevice /dev/ttySn OptionInputFashion Touchpanel OptionMinX 6 OptionMaxX 4066 OptionMinY 163 OptionMaxY 4023 OptionName unique_device_id OptionReportingMode Scaled OptionSendCoreEvents on EndSection You could reopen https://bugzilla.redhat.com/show_bug.cgi?id=473101 and bother to provide feed back when asked for it.. ( got closed insufficient data ) if you want to get this fixed.. JBG attachment: johannbg.vcf-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
tangent: PolicyKit and PAM
On Tue, Nov 24, 2009 at 12:44:00PM -0500, Matthias Clasen wrote: 1. In fact, a PAM-backed authority for PolicyKit might be interesting and useful -- but there's a tangent. What do you think PolicyKit is using for authentication ? See http://cgit.freedesktop.org/PolicyKit/tree/src/polkitagent/polkitagenthelper.c It uses it for authentication *and* for authorization, but it uses one service name (polkit-1) for everything (which is in turn configured by default to just defer to the standard system-auth service definition). This arrangement isn't particularly useful for a flexible authorization policy. You can use it for the big-hammer user-is-locked out stuff, but not for things like local users can install packages without a password, only during business hours, which PAM is perfectly expressive enough to do (with existing modules, even). I don't think, offhand, that it could be quite as flexible as the Local Authority currently in PolicyKit or via some fancy LDAP Authority, but I don't think it necessarily would need to be. The main advantage would be that instead of having yet another way (and again, I want to emphasize that I think PolicyKit is good work) to implement authorization policy, one could use PolicyKit with a well-understood mechanism that's been in production use since the 90s. Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
On Tue, Nov 24, 2009 at 06:00:20PM +, Jóhann B. Guðmundsson wrote: Try adding the kernel parameters nomodeset and xdriver=vesa or xdriver=intel and vga=ask and select any of the 24 bit values offered.. If install is successful then boot into run level 3 and run Xorg -configure and adapt accordingly something like.. OK, installing with nomodeset xdriver=intel vga=ask seems to work (chosen VESA 1024x768) and is busy now. I'll reopen my old bug and report more tomorrow. Thanks, -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, Nov 24, 2009 at 10:22 AM, Jesse Keating jkeat...@redhat.com wrote: On Tue, 2009-11-24 at 10:38 +0100, Andrea Musuruane wrote: Hi all, some Fedora users just pointed me out that the x86 DVD image names are not accurate. The install DVD is called Fedora-12-i386-DVD.iso while the live DVD is called Fedora-12-i686-Live.iso. Please note the i386 text in the install DVD file name. This is creating some confusion among users because they tend to believe that packages are still compiled for i386 and not for i686. Bye. Andrea. The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. -- 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, 2009-11-24 at 20:47 +0530, Rahul Sundaram wrote: We are not discarding CD images all together. If you feel there is a compelling reason to continue with a Live CD, I am afraid you will have to step up and do it. The tools are easy enough to learn and I am willing to help you or anyone else interested. I'm not sure that's entirely true. To my knowledge, only the desktop team is considering making this change. I haven't heard that the KDE, LXDE and Xfce spins are all moving to 1GB images. -- 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
Re: Security testing: need for a security policy, and a security-critical package process
I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) 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 11/24/2009 11:57 PM, Adam Williamson wrote: On Tue, 2009-11-24 at 20:47 +0530, Rahul Sundaram wrote: We are not discarding CD images all together. If you feel there is a compelling reason to continue with a Live CD, I am afraid you will have to step up and do it. The tools are easy enough to learn and I am willing to help you or anyone else interested. I'm not sure that's entirely true. To my knowledge, only the desktop team is considering making this change. I haven't heard that the KDE, LXDE and Xfce spins are all moving to 1GB images. I was referring only to the desktop Live CD since that is the only one being changed afaik. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
On Tue, Nov 24, 2009 at 06:00:20PM +, Jóhann B. Guðmundsson wrote: Try adding the kernel parameters nomodeset and xdriver=vesa or xdriver=intel and vga=ask and select any of the 24 bit values offered.. If install is successful then boot into run level 3 and run Xorg -configure and adapt accordingly something like.. BTW it looks like the nomodeset parameter is missing in the list of boot options at these two places: http://docs.fedoraproject.org/install-guide/f12/en-US/html/sn-bootoptions-hardware.html http://fedoraproject.org/wiki/Anaconda/Options I checked these lists to find a usable option first, but couldn't find it. -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tangent: PolicyKit and PAM
On Tue, 2009-11-24 at 13:18 -0500, Matthew Miller wrote: Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. Just as everybody else is struggling to get away from pam's awful apis...I don't think this would be a step forward; but sure, it might be doable. -- 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
Gregory Maxwell (gmaxw...@gmail.com) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
BTW it looks like the nomodeset parameter is missing in the list of boot options at these two places: http://fedoraproject.org/wiki/Anaconda/Options That's because it's not an anaconda option. - Chris -- 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 Mon, Nov 23, 2009 at 3:51 PM, Ben Williams wrote: (yes i know the size sux, but not everyone has highspeed internet thats why they are downloading the livecd and not the dvd) Another interpretation would be: The contents of the DVD does not satisfy the needs of many people. I am in that ship for instance. There is so much useless stuff in the DVD that I will never use that makes it a waste of time for me to download. In that sense, I use the LiveCD for installation, because I *have* fast internet, so I can pull and install packages real fast. Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Tue, 2009-11-24 at 17:13 +0100, Roman Rakus wrote: On 11/20/2009 01:06 PM, Jiri Moskovcak wrote: snip 1-4 are more RFEs for bugzilla, but I'll try to elaborate here and start some discussion: 1. Can Fedora enable anonymous/unauthenticated bug submission. We're thinking about this, but it can be flood the BZ, so the solution might be, that anonymous reports won't go directly to BZ. We can ge some ideas from kerneloops.org. What about to use user abrt as a reporter? Which will be set by default and would be able to change. This user abrt will have some limited privileges in bugzilla (just only to report bugs for example). snip RR What if package maintainer would need to followup on the issue? Last bug reported from abrt for subdownloader package was useless, there was not enough info that I could reproduce issue and I'm waiting if reporter will give me more info. With anonymous reports, I will not get info which I will need. Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tangent: PolicyKit and PAM
On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote: Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. Just as everybody else is struggling to get away from pam's awful apis...I don't think this would be a step forward; but sure, it might be doable. The awful API is actually an argument _for_ doing such a thing: it gets encapsulated away in only one place that needs to be maintained, and everyone can just write to PolicyKit. Annd speaking of tangents and horrible interfaces, I should add that one thing I'm very genuinely happy to learn in all of this is that the pkla config files are key=value rather than the old PolicyKit.conf xml file. So much nicer for humans to work with! -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- 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-11-24 at 13:28 -0500, Bill Nottingham wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator. perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though. -- 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
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 24 Nov 2009, Bill Nottingham wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) provided those pkgs are not required anywhere or set in our default pkg groups, then sure. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
On Tue, 2009-11-24 at 19:28 +0100, Jos Vos wrote: On Tue, Nov 24, 2009 at 06:00:20PM +, Jóhann B. Guðmundsson wrote: Try adding the kernel parameters nomodeset and xdriver=vesa or xdriver=intel and vga=ask and select any of the 24 bit values offered.. If install is successful then boot into run level 3 and run Xorg -configure and adapt accordingly something like.. BTW it looks like the nomodeset parameter is missing in the list of boot options at these two places: http://docs.fedoraproject.org/install-guide/f12/en-US/html/sn-bootoptions-hardware.html http://fedoraproject.org/wiki/Anaconda/Options I checked these lists to find a usable option first, but couldn't find it. it is documented in the Common Bugs: https://fedoraproject.org/wiki/Common_F12_bugs#intel-misc-gfx it could stand to be in the install guide, I guess, but it will likely go away in future - the UMS (userland mode setting) code path is going away. -- 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
Re: F12 install stops at screen switch (language select)
On 11/24/2009 06:28 PM, Jos Vos wrote: On Tue, Nov 24, 2009 at 06:00:20PM +, Jóhann B. Guðmundsson wrote: Try adding the kernel parameters nomodeset and xdriver=vesa or xdriver=intel and vga=ask and select any of the 24 bit values offered.. If install is successful then boot into run level 3 and run Xorg -configure and adapt accordingly something like.. BTW it looks like the nomodeset parameter is missing in the list of boot options at these two places: http://docs.fedoraproject.org/install-guide/f12/en-US/html/sn-bootoptions-hardware.html http://fedoraproject.org/wiki/Anaconda/Options I checked these lists to find a usable option first, but couldn't find it. There are bunch of kernel parameters hidden in the corners of the internet however Rule of thumb is always look at the common bugs page for the current release before anything else.. https://fedoraproject.org/wiki/Common_F12_bugs#Miscellaneous_problems_with_Intel_graphics_adapters JBG attachment: johannbg.vcf-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On 2009/11/24 12:24 (GMT-0600) Sir Gallantmon composed: Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. +1 -- The husband should fulfill his marital duty to his wife, and likewise the wife to her husband. 1 Corinthians 7:3 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tangent: PolicyKit and PAM
On Tue, 24 Nov 2009, Matthew Miller wrote: On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote: Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. Just as everybody else is struggling to get away from pam's awful apis...I don't think this would be a step forward; but sure, it might be doable. The awful API is actually an argument _for_ doing such a thing: it gets encapsulated away in only one place that needs to be maintained, and everyone can just write to PolicyKit. And in general having the logging of security-elevation events be in the lowest common denominator piece of code or interface keeps important information from getting lost due to insufficient logging in a calling app. -sv -- 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-11-24 at 10:44 -0800, Adam Williamson wrote: As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator. perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though. or, I suppose more trivially, a PackageKit policy for the ability to install PolicyKit policy packages. heh, now that's a bizarre sentence. -- 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
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 12:24 -0600, Sir Gallantmon wrote: Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. Because that's not what uname says. Change that, and then we'll talk. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 10:54 -0800, Jesse Keating wrote: On Tue, 2009-11-24 at 12:24 -0600, Sir Gallantmon wrote: Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. Because that's not what uname says. Change that, and then we'll talk. it doesn't change the fact that, logically speaking, either the DVD or CD images is wrong. Or at least, less right. I can see no sustainable argument that they should be different. -- 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
Re: abrt + X Error = zillions of duplicate bug reports?
On Sun, 2009-11-22 at 19:21 +0100, Martin Sourada wrote: So, since I've already received 3 separate bug reports caused by BadIDChoice X Error in subtitleeditor [1][2][3] (haven't had enough time to debug and try to fix it yet though) by abrt, I wonder if there is any room for duplicity detection improvement in these cases, or if we are doomed to zillions of duplicates in rhbz? (btw. otherwise abrt is awesome, IMHO the bugreports from abrt are much more useful than before :-) We discussed this issue at the Bugzappers meeting today. BZ would like to register that the high level of duplicates reported by abrt is a significant issue for triage work. We're not sure we can sustainably triage some major components (e.g. Firefox) if the current situation continues. We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. Second, we wondered if abrt team might be able to assist in running any improved duplicate detection mechanisms over already-reported bugs in Bugzilla retrospectively. We will follow up with them about that. Third, we agreed to look at methods used in GNOME and other Bugzillas to cope with high levels of duplicate reporting from automated tools, such as extracting significant sections of tracebacks as bug comments to make manual duplicate detection faster and easier. Finally, we considered - and rather approved of - the proposal that's been floated on this list (and was floating in the meeting by Will Woods) to consider using the mechanism used by the kernel developers for kernel oopses: instead of being reported direct to Bugzilla, these are reported to an intermediate site (kerneloops.org) and can be promoted from there to Bugzilla if appropriate. Will is planning to work on this idea after finishing up some AutoQA work, and will talk to abrt team about it and see if they are interested in helping. He would welcome contact from anyone else who's interested in helping with that, too. That's all, really - I just took an action item to pass on our thoughts about this :) -- 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
Re: Fedora 12 x86 DVD images
On 11/25/2009 12:24 AM, Jesse Keating wrote: On Tue, 2009-11-24 at 12:24 -0600, Sir Gallantmon wrote: Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. Because that's not what uname says. Change that, and then we'll talk. What uname says doesn't have to match the ISO arch name at all. The suggestion above is very valid and you should consider implementing it to avoid confusion. Our users would be thankful and so would I, not having to answer questions about this anymore. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Le mardi 24 novembre 2009 à 10:44 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le Mar 24 novembre 2009 17:01, Chris Adams a écrit : That's not an answer. What is the real maintenance cost? I already explained yesterday : there are rotting Fedora Core packages to merge review, packaging guidelines to write to define how they are supposed to be cleaned up, a huge pile of existing fonts to re-check for licensing, a huge pile of fonts to re-check for technical soundness (ie a lot of fonts for that area are not encoded properly or declare bad names, should it continue to be hidden via manual fonts.dir or should they be converted to something cleaner, it we continue to go the manual fonts.dir way someone needs to review existing files) etc. And how much of this is still going to be done no matter what, since core font support is not going to be dropped? You confuse core font support (=xorg code) and core fonts (= rotting font files that no one wants to maintain, and the associated fonts.dir indexes that break regularly) To keep core fonts support available anything but the built-in fonts (not the full historic xorg font suite, just the single fallback font built in xorg) can be dropped. Of course the packagers of the apps that use this stuff are going to howl, since it will reduce what their apps can do, but none of them have shown the slightest interest in contributing to the maintenance of the stuff they use so far (to keep things interesting a lot of said apps request fonts without checking they are actually available, and will crash if those fonts are not present. But that's not a core fonts support problem, that's a coding problem in those apps. They can be broken without technically removing core fonts support from Fedora). In fact one conclusion of this thread is that core fonts users are emphatically not interested in contributing to the stuff they use, and that it's better to remove the most rotten parts from Fedora, instead of keeping it, and continuing to wait for them to fix it. Like I said, this can be done without removing the xorg code Fedora is commited to maintain to keep X11 protocol compatibility. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/23/2009 07:01 PM, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. The way around this is role-based privileges, which is what polkit is implementing - it means that for some actions, the user is automatically authorized by being assigned a role (for some actions, that is by being a member of the desktop_admin_r group). For some actions, the user may need to prove that he's who he says by entering /his/ password, but not the root password. The user does not thus get trained to enter the root password into dialog boxes. The important part here is that there's granularity on the actions - it's not assume root access, it's assume access to start $task that performs $action, so a) if the fake dialog attack does occur, it's a password with limited abilities which gets betrayed, and b) the admin is not necessarily giving free reign to the user in the first place. The model here is actually pretty good. The policy was clearly not what it should have been, and documentation/communication of the various roles and the rollout plan could have been better. Though tbf, on the polkit side there's plenty of how this works documentation that is useful and thorough; the communication of the roles and associated policy itself, that is, how PackageKit is using polkit and what admins need to know to lock a machine down, is what I'm talking about. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? I don't understand what it is you think fast user switching does. You're just logged on as a different user. It's just like being logged in with a different getty on tty2 than on tty1. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
Adam Williamson wrote: it doesn't change the fact that, logically speaking, either the DVD or CD images is wrong. Or at least, less right. I can see no sustainable argument that they should be different. The same is true for the directory labels (i386/ for install images and i686/ for live images). BTW, the live image directory was originally i386/ in F7, and then changed to i686/ for F8 and later (although the ISO name was always i686). signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On 11/25/2009 12:56 AM, Michael Cronenworth wrote: Should there be a RFE bug or rel-eng ticket created so this e-mail thread is not for nothing? It's been discussed since the beginning of time AFAIK. Tickets have been filed and closed before, IIRC. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
Michael Cronenworth wrote: Should there be a RFE bug or rel-eng ticket created so this e-mail thread is not for nothing? It's been discussed since the beginning of time AFAIK. There's already one: https://fedorahosted.org/rel-eng/ticket/2476 which was closed as wontfix. signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, Nov 24, 2009 at 5:22 PM, Jesse Keating jkeat...@redhat.com wrote: The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... Then why the Live DVD and the Install DVD have different names? And why the same is true for the directory labels (i386/ for install DVD and i686/ for live DVD)? Can we at least have some consistency? Thanks! Andrea. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
PolicyKit and syslog -- now bug #541040
On Tue, Nov 24, 2009 at 11:47:03AM -0500, Seth Vidal wrote: I'd recommend filing this as a bug. Bug 541040 - Enable logging in PolicyKit (for policy changes and for authorizations.) https://bugzilla.redhat.com/show_bug.cgi?id=541040 -- Matthew Miller mat...@mattdm.org http://mattdm.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 20:38 +0100, Andrea Musuruane wrote: On Tue, Nov 24, 2009 at 5:22 PM, Jesse Keating jkeat...@redhat.com wrote: The base arch of the family is i386, just like we call the ppc spin ppc even though it only supports a subset of the ppc family, ditto sparc, arm, etc... Then why the Live DVD and the Install DVD have different names? And why the same is true for the directory labels (i386/ for install DVD and i686/ for live DVD)? Can we at least have some consistency? Thanks! Andrea. Yes, we may rename the Live images to i386. When they were first introduced, we had both an i586 and an i686 kernel in Fedora, and the Live images were only usable on i686, they had no i586. Now that we don't have i586 anymore, we can change the live image name to i386. It was too late to do this for F12 at the time somebody suggested it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: Security testing: need for a security policy, and a security-critical package process
On Tue, Nov 24, 2009 at 01:29:11PM -0500, Bill Nottingham wrote: You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) Annnd if you set a root password, stuff breaks. -- Matthew Miller mat...@mattdm.org Senior Systems Architect Cyberinfrastructure Labs / Instructional Research Computing Computing Information Technology Harvard School of Engineering Applied Sciences -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On 11/21/2009 11:50 AM, Michael Schwendt wrote:
Given that Epoch can make an update go from a higher %{version} to a lower
one (which even may be a completely normal scenario for upstream project
splits), you can't avoid making Epoch the most-significant portion of RPM
version comparison. One can only work around versioning scheme flaws until
one runs into an unexpected problem where an Epoch is needed. Introduce
an Epoch, and it must be considered in any other explicit references
(Obsoletes'n'friends).
Essentially, these proposals can be seen as attempts to introduce a
2-dimensional ordering: on one hand, classifying packages by their
version number, and on the other hand by a distribution. Mathematically
this is impossible---it's a well-known mathematical fact that there's no
consistent ordering relation in a complex plane. Indeed, people came up
with use cases for both version number being more important and less
important than the distribution number.
I agree that this is a 'process' issue---packages should be ordered
simply by the underlying software version and release, and there should
be a distribution release QA step that simply makes sure that all
released packages from distro N+1 are newer than latest updates in distro N
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
Jesse Keating wrote: Yes, we may rename the Live images to i386. When they were first introduced, we had both an i586 and an i686 kernel in Fedora, and the Live images were only usable on i686, they had no i586. Now that we don't have i586 anymore, we can change the live image name to i386. It was too late to do this for F12 at the time somebody suggested it. That makes everything consistent, but creates the same user confusion for live images that presently exists for install images. Since uname isn't strictly adhered to even now, why not just change the install labels to i686 instead? signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
2009/11/24 Adam Williamson awill...@redhat.com: snip Finally, we considered - and rather approved of - the proposal that's been floated on this list (and was floating in the meeting by Will Woods) to consider using the mechanism used by the kernel developers for kernel oopses: instead of being reported direct to Bugzilla, these are reported to an intermediate site (kerneloops.org) and can be promoted from there to Bugzilla if appropriate. Will is planning to work on this idea after finishing up some AutoQA work, and will talk to abrt team about it and see if they are interested in helping. He would welcome contact from anyone else who's interested in helping with that, too. Why not cut a bit of the bureaucraucy and extra levels here? Instead of an intermediate system with all the overhead that goes in to creating and maintaining such a system, why not just class all the bugs from abrt in a seperate tag or component or something in bugzilla? If there's an intermediate system, someone has to go through it, packagemaintainers need to be trained to use it, and the entire thing needs to be triaged, so bugs can be combined and sent to bugzilla. This is alot of work. If you use bugzilla for this, you still have to triage all the bugs, combine duplicates, but package maintainers can still see bugs. We might allow them to ignore the untriaged abrt bugs if it bugs them (pun intended) but it avoids the issue where they go 'well i'm not learning yet another system to track bugs, bugzilla is annoying enough'. -Yaakov signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Tue, Nov 24, 2009 at 1:42 PM, Jan Klepek jan.kle...@brandforge.sk wrote: What if package maintainer would need to followup on the issue? Last bug reported from abrt for subdownloader package was useless, there was not enough info that I could reproduce issue and I'm waiting if reporter will give me more info. With anonymous reports, I will not get info which I will need. https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01574.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[RFC] unified i386/x86_64 install media.
I was thinking and thought id get an idea out there. rather than ship 2 dvds one for i386 and one for x86_64 we would ship one dvd that has the package set for both arches. they would likely only have the packages for a desktop install on them we would need to have both arches under 2.4GiB, you could choose your own adventure by enabling the everything repo. this way you could carry a usb key or dvd that you can plug into any intel based machine and be sure of having it installable. this would end the discussions of what arch to promote we have a single install media. syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. I think we should also push the netinstall.iso along with kickstarting machines. we could make a single netinstall.iso for both arches as well. it would make it ~375MB iso. Dennis 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: [RFC] unified i386/x86_64 install media.
On 11/24/2009 02:50 PM, Dennis Gilmore wrote: I was thinking and thought id get an idea out there. rather than ship 2 dvds one for i386 and one for x86_64 we would ship one dvd that has the package set for both arches. they would likely only have the packages for a desktop install on them we would need to have both arches under 2.4GiB, you could choose your own adventure by enabling the everything repo. this way you could carry a usb key or dvd that you can plug into any intel based machine and be sure of having it installable. this would end the discussions of what arch to promote we have a single install media. syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. I think we should also push the netinstall.iso along with kickstarting machines. we could make a single netinstall.iso for both arches as well. it would make it ~375MB iso. Dennis I know there's still a lot of users who install on computers with no/unreliable internet access, and they're definitely worth going the extra mile to support given where that use case tends to pop up, but I still wonder if this is worthy to be default anymore. Shipping netinst.iso by default would be a good way to do what Dennis describes without all the pain of trying to squeeze the arches down. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
for me sounds a good idea On Tue, Nov 24, 2009 at 5:50 PM, Dennis Gilmore den...@ausil.us wrote: I was thinking and thought id get an idea out there. rather than ship 2 dvds one for i386 and one for x86_64 we would ship one dvd that has the package set for both arches. they would likely only have the packages for a desktop install on them we would need to have both arches under 2.4GiB, you could choose your own adventure by enabling the everything repo. this way you could carry a usb key or dvd that you can plug into any intel based machine and be sure of having it installable. this would end the discussions of what arch to promote we have a single install media. syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. I think we should also push the netinstall.iso along with kickstarting machines. we could make a single netinstall.iso for both arches as well. it would make it ~375MB iso. Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Itamar Reis Peixoto e-mail/msn/google talk/sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- 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
Chris Ball (c...@laptop.org) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. Bill -- 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-11-24 at 15:34 -0500, Bill Nottingham wrote: Chris Ball (c...@laptop.org) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. SoaS is not Fedora-branded in any way, AFAIK. -- 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
Re: Security testing: need for a security policy, and a security-critical package process
Adam Williamson (awill...@redhat.com) said: It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. SoaS is not Fedora-branded in any way, AFAIK. Yes, but how often have we touted XO, Sugar, et. al. as being 'based on Fedora' over the past 4 years? Heck, you could argue it's gotten more press than some of our official spins. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote: On 11/23/2009 07:01 PM, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. Sure, that's _a_ problem ... assuming the user has been trained. But that's a _big_ assumption, esp. when we are only talking about installing _new_ packages (doesn't happen often, so the user isn't trained to accept it). But, of course, taking advantage of a user trained to input a password without thinking is not the only attack ... another area of attack would be when you have an assumed small privilege escalation, that has no authentication (hence this thread). The way around this is role-based privileges, which is what polkit is implementing In so far as role-based privileges is code for can be configured to N number of actual checks, including the auth_as_root check we are comparing it against. Then sure, it has to be at least as secure as auth_as_root because it can be auth_as_root¹. But suggesting that whatever polkit is configured to use is automatically better than auth_as_root is, at best, misleading. Personally I don't think _anyone_ knows how to make a usable and thus. in practice secure desktop. So some of the comments I've read saying basically We know X is insecure, so we are now using Y which is secure/better are not helping (in fact I'd suggest that this mindset is what lead to this problem initially). ¹ Noting that polkit force removed the remember auth option, for no particularly sane reason that I've seen ... so if that option turns out to be the best option, then role-based privileges has (at least currently) hurt security. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
I dunno, that sounds like a bad idea because it relies on said internet connection. A unified x86_32 and x86_64 Live image is unlikely though, given that any efforts to make this possible have been scorned because of two things: saying that packages solve the arch problem (because any changes to make this possible would affect everything), and that anything that would offer this capability is more useful to proprietary software than open source software. Personally, I don't agree with either argument. The first argument about package managers is somewhat true, but at the same time, not true. Packages do make it easier to handle arch-specific dependencies, and generally arch-independent data is split out into a separate package that is pulled during installation, but the initial point of entry for either arch requires KNOWING that your system actually uses either arch. While it is true most systems sold today are x86_64 capable, it isn't true that most systems in USE are x86_64 capable. As far as the installable media goes, I don't really see too much of a reason to fuse the x86_32 and x86_64 stuff together, because frankly, the people that are installing through traditional media have to know what they are doing anyway, since you have to know what you are doing to be able to select all those packages and stuff. The Live images though, are intended not only for demonstration, but for easy installation. In this case, I could see fusing the two arches together. As for the second argument, open source software typically do not need to offer binaries, since source is available. However, being able to offer binaries that will work on a wide variety of UNIX platforms would be wonderful, and also it would be easier to support, since the binaries are configured in a specific way. As it currently works, it isn't a good idea to bring issues you have with distro packages of software to the actual maker of the software, because there are too many variables to help predict the issue, mainly because each distribution configures packages differently for package generation. Having a single set of binaries that can be offered for a multitude of platforms that anyone can download makes it easier on upstream to handle cases. However, I will grant that it makes life for proprietary software makers a lot easier. Since there are lots of haters to those makers here and in other distributions, it is unlikely you will see any solution like this in a distribution unless they want to get flamed out of existence. -- 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, Nov 24, 2009 at 12:41 PM, Orcan Ogetbil oget.fed...@gmail.comwrote: On Mon, Nov 23, 2009 at 3:51 PM, Ben Williams wrote: (yes i know the size sux, but not everyone has highspeed internet thats why they are downloading the livecd and not the dvd) Another interpretation would be: The contents of the DVD does not satisfy the needs of many people. I am in that ship for instance. There is so much useless stuff in the DVD that I will never use that makes it a waste of time for me to download. In that sense, I use the LiveCD for installation, because I *have* fast internet, so I can pull and install packages real fast. Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list If there are systems that cannot boot to USB, why not offer a boot disc that would automatically search for USB drives, offer a list of bootable USB drives, and allow the user to select one to boot from? There really is a huge need for this kind of option. I love installing from USB, since it is so much faster and more reliable, but I have many systems that are unable to boot from USB. And if it is done right, this boot disc would rarely (if ever) have to be updated, since it would work for past and future Fedora releases. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/24/2009 03:49 PM, James Antill wrote: On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote: That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. Sure, that's _a_ problem ... That's what I said, yes. assuming the user has been trained. But that's a _big_ assumption, No, not that they /have been/ trained. That the policy in question has the ability to train many users. I think this is ,in fact, a very /small/ assumption. esp. when we are only talking about installing _new_ packages (doesn't happen often, so the user isn't trained to accept it). We were discussing the dialog box in general, and not necessarily only this specific use of it. But, of course, taking advantage of a user trained to input a password without thinking is not the only attack ... another area of attack would be when you have an assumed small privilege escalation, that has no authentication (hence this thread). Yes, but it's often helpful to talk about specific improvements that can be made, not merely all problems that may emerge on a system. Or, to put that a different way, your thesis in this statement is that everywhere there's privilege escalation without secondary authentication is a risk. While that's certainly not incorrect, I don't think there's really much utility in discussing potential attack vectors in /bin/ping in *this* thread. The way around this is role-based privileges, which is what polkit is implementing In so far as role-based privileges is code for can be configured to N number of actual checks, including the auth_as_root check we are comparing it against. Then sure, it has to be at least as secure as auth_as_root because it can be auth_as_root¹. It's a fair point that the policy as defined for the role still needs to be a good one, but I think some people on this thread are dwelling on the mistake that was made, while at the same time placing blame incorrectly on the mechanism. That doesn't help us. The mechanism does improve things if used well by application developers and admins. But suggesting that whatever polkit is configured to use is automatically better than auth_as_root is, at best, misleading. I wasn't meaning to suggest that the system as a whole is necessarily more secure if you use a mechanism which allows for policy and role based decision making. I am suggesting that it certainly appears to be a good method to make a system which allows for /less/ privilege escalation on the whole while at the same time making a system which is more usable where individual authorized users don't /need/ more privileges. That's improvement. For it to also be more secure, it's true that the policies that govern the mechanism also have to be crafted in such a way as to enforce security. But that's true with what we had before, too. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On 11/24/2009 02:15 PM, Adam Williamson wrote: We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. What's the technical limitation to coming close here? It seems likely that there will be some edge cases, but I would think that the majority of cases aren't all that exceptional, and are fundamentally straightforward to work out. -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
Once upon a time, Peter Jones pjo...@redhat.com said: Not that I actually believe in these systems that are i686 or newer and won't boot off of usb-storage devices, but if they were to exist, you wouldn't be able to do what you're saying on them. I have run into such systems unfortunately. When the bootloader is running, it can only see devices BIOS provides to it. Not true. See for example PXE-boot floppies. Google USB boot cd, and the first hit is how to boot an Ubuntu USB flash drive using a CD boot loader. There are also floppy images to boot from USB. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On Tue, 2009-11-24 at 16:21 -0500, Peter Jones wrote: On 11/24/2009 02:15 PM, Adam Williamson wrote: We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. What's the technical limitation to coming close here? It seems likely that there will be some edge cases, but I would think that the majority of cases aren't all that exceptional, and are fundamentally straightforward to work out. Matej? -- 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
Re: livecds in the future
On 11/24/2009 04:25 PM, Adam Williamson wrote: On Tue, 2009-11-24 at 16:17 -0500, Peter Jones wrote: On 11/24/2009 04:07 PM, Sir Gallantmon wrote: If there are systems that cannot boot to USB, why not offer a boot disc that would automatically search for USB drives, offer a list of bootable USB drives, and allow the user to select one to boot from? Not that I actually believe in these systems that are i686 or newer and won't boot off of usb-storage devices, but if they were to exist, you wouldn't be able to do what you're saying on them. When the bootloader is running, it can only see devices BIOS provides to it. If a system can't boot off of a usb-storage device, it's because the BIOS isn't enumerating it. So it's not a case of we can start from another device and then look at the device we meant to be using - you can't see the device at all, regardless of your starting point. Mandriva Flash - Mandriva's commercial system-on-a-USB-stick thingy - does exactly what you confidently proclaim to be impossible. It comes with a CD ISO you can burn onto a CD (or mini-CD) that allows you to 'chain-boot' the Flash on systems with crappy BIOSes that can't boot from a USB stick (yes, they exist, but are getting progressively rarer, obviously). I don't suppose you can easily fish out a url for the source to this? I'd like to see what they're actually doing. -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
Once upon a time, Dennis Gilmore den...@ausil.us said: rather than ship 2 dvds one for i386 and one for x86_64 we would ship one dvd that has the package set for both arches. they would likely only have the packages for a desktop install on them we would need to have both arches under 2.4GiB, you could choose your own adventure by enabling the everything repo. Well, since there is some overlap (there are still some core 32 bit packages included on the 64 bit DVD for multilib), the limit isn't exactly 2.4G. Also, it seems that with a little work, you could use a single install image (always a 32 bit userland, with minimal 64 bit libs, and a 32 or 64 bit kernel as appropriate), which would save some space. It might be nice to have a 32/64 combined netinst/rescue image in any case. I just dumped the F12 i386 and x86_64 DVDs in a directory and hardlinked them, and I get 5.2G. If the install image and repodata were unified, you would be too far off from it fitting. syslinux would need to be able to detect the arch to install Somebody said that there's already a SYSLINUX module that allows you to choose a different menu file based on the CPU type. and likely also have a flag to force 32 bit That just needs an extra menu option for the 64 bit menu that loads the 32 bit kernel. Or, you just make the combined image for dual-layer DVDs, Blu-Ray, or USB flash drives only. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Tue, 24 Nov 2009 14:59:20 -0500, Przemek wrote: Essentially, these proposals can be seen as attempts to introduce a 2-dimensional ordering: on one hand, classifying packages by their version number, and on the other hand by a distribution. Mathematically this is impossible---it's a well-known mathematical fact that there's no consistent ordering relation in a complex plane. Indeed, people came up with use cases for both version number being more important and less important than the distribution number. If you see it like that, ordering in the 1st dimension is a problem already, because it's not always possible to map upstream versions into RPM versions without violating a strict ordering relation. Fedora's versioning guidelines avoid many pitfalls, but odd cases remain -- and situations when you want to downgrade without creating a fake package version. I agree that this is a 'process' issue---packages should be ordered simply by the underlying software version and release, and there should be a distribution release QA step that simply makes sure that all released packages from distro N+1 are newer than latest updates in distro N Especially during freeze of the development dist that's to be released as N+1. That's the time when packagers make N and N-1 move ahead of N+1 because freeze procedures. If N+1 doesn't get the same package updates *and* upgrades as the older dists [because of issues], it simply isn't ready to be released. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On Tue, 2009-11-24 at 13:50 -0600, Dennis Gilmore wrote: syslinux would need to be able to detect the arch to install and likely also have a flag to force 32 bit we could easily implement the 64 bit kernel and 32 bit userland idea that was put forward a few releases ago. pungi will need to learn how to make the new iso. but i think it is achievable. As I'm actually trying this on one of the laptops on my desk, I'd point out that this almost certainly requires yum changes to work well. yum gets its idea of arch from uname, which reports what the kernel is, not what the current glibc is. Not that it's not a good idea - it seems to work surprisingly well - but it's not turnkey yet. - 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
Re: abrt + X Error = zillions of duplicate bug reports?
Dne 24.11.2009 22:37, Adam Williamson napsal(a): We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. What's the technical limitation to coming close here? It seems likely that there will be some edge cases, but I would think that the majority of cases aren't all that exceptional, and are fundamentally straightforward to work out. Don't ask me, I am just a humble bug triager (putting abrt developer on CC of this message). What I can say is that even though I can see abrt devs work hard to eliminate duplicates, they don't succeed much. Apparently eliminating duplicates of bugs from beasts like Firefox or OpenOffice is excessively hard. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC A GOOD name is rather to be chosen than great riches. -- Proverbs 22:1 smime.p7s Description: S/MIME Cryptographic Signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
