Re: jack2
On Sat, Nov 21, 2009 at 11:23 PM, Orcan Ogetbil oget.fed...@gmail.com wrote: My proposal is to use alternatives for parallel installation, the way java does. Then the user can switch between jack1 and jack2 as he wants. Is it okay with everyone if I write a specfile for jack2 that uses alternatives? It's ok for me. I can submit review for jack2. -- With Best Regards, Andy Shevchenko -- 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?
Martin, I am working on the duplication detection these days. I looked into your backtraces: it's obvious those are duplicates, and the new code will catch them. Best regards, Karel On 11/22/2009 07:21 PM, 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 :-) Martin References: [1] https://bugzilla.redhat.com/show_bug.cgi?id=538382 [2] https://bugzilla.redhat.com/show_bug.cgi?id=539040 [3] https://bugzilla.redhat.com/show_bug.cgi?id=540180 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
After updating the package, compiz crashed and glxgears can not run. However, KMS and plymouth can still run well. Here is dmesg message that I grabbed: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! But I reboot with kernel-2.6.31.5-127. All the thing return to normal. My desktop is running on Fedora 12 x86_64. My graphic card is HD3650. ATi display drivers: xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12 Kernel: 2.6.31.6-134.fc12.x86_64 Mesa: 7.6-0.15.fc12 Does any guy meet the same situation? -- 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: abrt and bugzilla
On 11/20/2009 11:34 PM, Kevin Kofler wrote: Jiri Moskovcak wrote: Yes, I'm planning to write another config backend for kwalet, but didn't find any usable API reference so far :( This is the official API: http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKWallet_1_1Wallet.html This should also be usable through PyKDE4. Kevin Kofler Thx, btw, I thought there was a plan to unite the dbus interfaces for kwallet and g-keyring. Jirka attachment: jmoskovc.vcf-- 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/21/2009 10:28 PM, Gene Czarcinski wrote: On Saturday 21 November 2009 05:54:56 Caolán McNamara wrote: On Sat, 2009-11-21 at 00:42 +, Colin Walters wrote: Look at it this way - it's more information than you had before, not less. And I personally have often been able to find a problem with no more than a traceback (especially given -debuginfo being installed, or an enthusiast/developer running code from revision control and thus having un-stripped binaries). Which brings up another thing, all the ones I'm getting are without debuginfo installed, which is rather gruesome. Can we get info sharedlib called in the gdb batch (https://fedorahosted.org/abrt/ticket/90) I have had problems with using abrt to report a problem because the backtrace does not include symbolics ... that is, debuginfo was not downloaded and installed. At least once during the F12 development cycle I used abrt to report a problem and it downloaded and installed the needed debuginfo packages. Is abrt suppose to download and install debuginfo packages? Is this an option and if it is how is it enabled? Is there an abrt bug right now preventing debuginfo processing? Gene Yes, ABRT is supposed to download and use the debuginfo (it doesn't install it actually, but that's another thing), but there are many potential problems that may prevent ABRT from finding/donwloading the proper debuginfo (most common is that yum --provides doesn;t work for some files :() You can always use debuginfo-install and then recreate the backtrace in ABRT. Jirka attachment: jmoskovc.vcf-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: texlive 2009 - should set TEXMFCNF?
Hi Jonathan, On Sun, Nov 22, 2009 at 10:30:44PM +, Jonathan Underwood wrote: 2009/10/30 Jindrich Novy jn...@redhat.com: I'm presenting a complete list of packages shipped in TeX Live to discuss another possible obsoletions: dvipdfm dvipdfmx I think the latest TeXLive doesn't include dvipdfm as its functionality is now covered by dvipdfmx. Anyway, In both cases I am the packager, and would rather see the texlive variant shipped and the packages obsoleted. TeX Live 2009 builds dvipdfm when it is not explicitely disabled. Also collection-basic depends on both dvipdfm and dvipdfmx. So I decided to ship them both. xdvi Again, would prefer if we obsoleted the separate package and went with the texlive variant. Here however we may need to shipp a separate package for the japanese patched version. Or we could integrate the japanese patch into texlive - this may need some work though, as the japanese patch seems to be unmaintined presently. Longer term I hope xdvi just goes away, as its functionality increasingly gets added to evince - xdvi is only minimally maintained at this point and is rather... crusty. I'm not sure about Japanese support here. IIRC Takanori MATSUURA works on this support for TL2009. At this point I would prefer to propose this effort to TL upstream so that we needn't to forwardport these patches too often. I could imagine that Takanori could be official upstream of the new xdvi package providing Japanese support if TL upstream is not against it. dvipng Yep, we should simply go with the texlive version - I am happy with this, as dvipng maintainer. xdvipdfmx I'm not primary maintainer of this one, but again, I think we should go with the texlive shipped version (which is ahead of the version available as a separate tarball). Let me know if you need any help with this. Cheers, Jonathan At last but not least, all the mentioned packages are obsoleted by their TeX Live variant for some time already in the Fedora repo. Cheers, 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
Re: Improve the way rpm decides what is newer
On Sun, 22 Nov 2009 21:26:11 -0500, Orcan wrote:
On Sat, Nov 21, 2009 at 12:03 PM, Michael Schwendt wrote:
On Sat, 21 Nov 2009 11:31:27 -0500, Tony wrote:
On 09-11-21 06:40:45, drago01 wrote:
...
You misunderstood me, I was not suggesting adding another epoch but
simply bump the %{epoch} for every release.
If this were really important to do, just putting the release first in
the version would take care of it without dragging in Epochs.
That's %build number (= super-Epoch) style:
1-2.10 2-2.10 3-2.10 4-2.20 5-2.3 (!) 6-2.31 7-2.40
... [a year later] ... 1337-3.0 1338-3.0 1339-3.10
This has the same effect as bumping the release tag on every update
and not resetting it to 1 on upstream releases, and make the Release
tag take precedence over the Version tag. Wasn't this proposed before?
Yeah, long ago. It doesn't fix much and even bears a higher risk of
breaking versioned Req/Obs/Conf/BR in ways that have been covered before
in this thread.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Head-up - new firefox in rawhide
On 11/22/2009 02:17 PM, Ville-Pekka Vainio wrote: to, 2009-11-19 kello 14:30 -0800, Christopher Aillon kirjoitti: Perhaps we should continue to provide -unstable, though. Things that still need the unstable libs can continue Require -unstable which will make it a heck of a lot easier to figure out what to rebuild... +1. I'd like to see a decision made soon on whether you will provide -unstable or not. My xulrunner unstable dependent package (mozvoikko) has been broken in Rawhide for a few days now, I'd like to know which will be the best way to fix it. Okay, what about this: - all packages should switch to unified mozilla package config files, libxul-embedding.pc libxul.pc. Old libxul-embedding-unstable.pc libxul-unstable.pc will be provided for compatibility. - packages built against unfrozen interfaces will keep BuildRequire: gecko-devel-unstable. It helps mozilla team to decide which packages should be rebuild in update. You may identify frozen (stable) interface by: - at http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html - at sources - look for @status string in appropriate idl file (in /usr/share/idl/xulrunner-sdk-1.9.2), all frozen interfaces have status FROZEN there. Recently, a few F12 packages (looks like browser plug-ins only) are built against frozen (stable) interface [1] and all others require unstable interface. ma. [1]: gecko-sharp2-0:0.13-13.fc12.src gnome-chemistry-utils-0:0.10.8-1.fc12.src gxine-0:0.5.903-4.fc12.src libproxy-0:0.2.3-12.fc12.src openoffice.org-1:3.1.1-19.14.fc12.src openvrml-0:0.18.3-5.fc12.src -- 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 Liang Suilong liangsuil...@gmail.com: After updating the package, compiz crashed and glxgears can not run. However, KMS and plymouth can still run well. Here is dmesg message that I grabbed: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! But I reboot with kernel-2.6.31.5-127. All the thing return to normal. My desktop is running on Fedora 12 x86_64. My graphic card is HD3650. ATi display drivers: xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12 Kernel: 2.6.31.6-134.fc12.x86_64 Mesa: 7.6-0.15.fc12 Does any guy meet the same situation? -- 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! 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. -- 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
upperlimit for considering a separate doc subpackage
In case one is writing a warning check for packager about you should rather make a separate doc subpackage rather then put everything in main package? Should 1024 KB be upper limit or may be 100 files ? Also if one can also help in listing the exceptions which can be considered here ? oget (suggested) and filled up a request here https://fedorahosted.org/gach/ticket/6 Any suggestions ? And any more requests for any kind of guideline checks are welcome. I have been fairly active now targeting a release in near future. Project page[1] has all details and we have a separate mailing list[2]. Please consider discussing on ticket and concerned mailing list. In case you don't know what gach is consider checking [3]. It was renamed from review-o-matic. Thanks, [1] https://fedorahosted.org/gach/ [2] https://fedorahosted.org/mailman/listinfo/gach-dev [3] http://www.mailinglistarchive.com/fedora-devel-list@redhat.com/msg69129.html -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Head-up - new firefox in rawhide
On 11/23/2009 12:34 PM, Martin Stransky wrote: On 11/22/2009 02:17 PM, Ville-Pekka Vainio wrote: to, 2009-11-19 kello 14:30 -0800, Christopher Aillon kirjoitti: Perhaps we should continue to provide -unstable, though. Things that still need the unstable libs can continue Require -unstable which will make it a heck of a lot easier to figure out what to rebuild... +1. I'd like to see a decision made soon on whether you will provide -unstable or not. My xulrunner unstable dependent package (mozvoikko) has been broken in Rawhide for a few days now, I'd like to know which will be the best way to fix it. Okay, what about this: - all packages should switch to unified mozilla package config files, libxul-embedding.pc libxul.pc. Old libxul-embedding-unstable.pc libxul-unstable.pc will be provided for compatibility. built as xulrunner-1.9.2.1-0.4.b3.fc13. - packages built against unfrozen interfaces will keep BuildRequire: gecko-devel-unstable. It helps mozilla team to decide which packages should be rebuild in update. You may identify frozen (stable) interface by: - at http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html - at sources - look for @status string in appropriate idl file (in /usr/share/idl/xulrunner-sdk-1.9.2), all frozen interfaces have status FROZEN there. Recently, a few F12 packages (looks like browser plug-ins only) are built against frozen (stable) interface [1] and all others require unstable interface. ma. [1]: gecko-sharp2-0:0.13-13.fc12.src gnome-chemistry-utils-0:0.10.8-1.fc12.src gxine-0:0.5.903-4.fc12.src libproxy-0:0.2.3-12.fc12.src openoffice.org-1:3.1.1-19.14.fc12.src openvrml-0:0.18.3-5.fc12.src -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Package Review Stats for last 15 days ending 22nd Nov
Top four FAS account holders who have completed reviewing Package review components on bugzilla for last 15 days ending 22nd Nov were Parag AN(पराग), Thomas Spura, Lubomir Rintel and Mamoru Tasaka. Parag AN(पराग) : 17 https://bugzilla.redhat.com/show_bug.cgi?id=531987 https://bugzilla.redhat.com/show_bug.cgi?id=538332 https://bugzilla.redhat.com/show_bug.cgi?id=538335 https://bugzilla.redhat.com/show_bug.cgi?id=538337 https://bugzilla.redhat.com/show_bug.cgi?id=538339 https://bugzilla.redhat.com/show_bug.cgi?id=538340 https://bugzilla.redhat.com/show_bug.cgi?id=538673 https://bugzilla.redhat.com/show_bug.cgi?id=539230 https://bugzilla.redhat.com/show_bug.cgi?id=539231 https://bugzilla.redhat.com/show_bug.cgi?id=539428 https://bugzilla.redhat.com/show_bug.cgi?id=538458 https://bugzilla.redhat.com/show_bug.cgi?id=533723 https://bugzilla.redhat.com/show_bug.cgi?id=537823 https://bugzilla.redhat.com/show_bug.cgi?id=532382 https://bugzilla.redhat.com/show_bug.cgi?id=538326 https://bugzilla.redhat.com/show_bug.cgi?id=538361 https://bugzilla.redhat.com/show_bug.cgi?id=538451 Thomas Spura : 6 https://bugzilla.redhat.com/show_bug.cgi?id=521719 https://bugzilla.redhat.com/show_bug.cgi?id=533753 https://bugzilla.redhat.com/show_bug.cgi?id=540034 https://bugzilla.redhat.com/show_bug.cgi?id=508518 https://bugzilla.redhat.com/show_bug.cgi?id=532874 https://bugzilla.redhat.com/show_bug.cgi?id=533094 Lubomir Rintel : 5 https://bugzilla.redhat.com/show_bug.cgi?id=536683 https://bugzilla.redhat.com/show_bug.cgi?id=537452 https://bugzilla.redhat.com/show_bug.cgi?id=537454 https://bugzilla.redhat.com/show_bug.cgi?id=537585 https://bugzilla.redhat.com/show_bug.cgi?id=537652 Mamoru Tasaka : 5 https://bugzilla.redhat.com/show_bug.cgi?id=538303 https://bugzilla.redhat.com/show_bug.cgi?id=539442 https://bugzilla.redhat.com/show_bug.cgi?id=528108 https://bugzilla.redhat.com/show_bug.cgi?id=520637 https://bugzilla.redhat.com/show_bug.cgi?id=530288 Jochen Schmitt : 3 https://bugzilla.redhat.com/show_bug.cgi?id=538558 https://bugzilla.redhat.com/show_bug.cgi?id=534021 https://bugzilla.redhat.com/show_bug.cgi?id=537066 Andrew Colin Kissa : 2 https://bugzilla.redhat.com/show_bug.cgi?id=528473 https://bugzilla.redhat.com/show_bug.cgi?id=528476 D Haley : 2 https://bugzilla.redhat.com/show_bug.cgi?id=533744 https://bugzilla.redhat.com/show_bug.cgi?id=532203 Dennis Gilmore : 2 https://bugzilla.redhat.com/show_bug.cgi?id=531541 https://bugzilla.redhat.com/show_bug.cgi?id=522272 Guido Grazioli : 2 https://bugzilla.redhat.com/show_bug.cgi?id=533520 https://bugzilla.redhat.com/show_bug.cgi?id=516343 Jason Tibbitts : 2 https://bugzilla.redhat.com/show_bug.cgi?id=515053 https://bugzilla.redhat.com/show_bug.cgi?id=462458 Luya Tshimbalanga : 2 https://bugzilla.redhat.com/show_bug.cgi?id=479527 https://bugzilla.redhat.com/show_bug.cgi?id=531773 Michael Schwendt : 2 https://bugzilla.redhat.com/show_bug.cgi?id=533803 https://bugzilla.redhat.com/show_bug.cgi?id=527241 Peter Lemenkov : 2 https://bugzilla.redhat.com/show_bug.cgi?id=527706 https://bugzilla.redhat.com/show_bug.cgi?id=533877 Sandro Mathys : 2 https://bugzilla.redhat.com/show_bug.cgi?id=491088 https://bugzilla.redhat.com/show_bug.cgi?id=494292 Steve Traylen : 2 https://bugzilla.redhat.com/show_bug.cgi?id=534061 https://bugzilla.redhat.com/show_bug.cgi?id=531255 Bryan O'Sullivan : 1 https://bugzilla.redhat.com/show_bug.cgi?id=530688 Christof Damian : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529542 David Nalley : 1 https://bugzilla.redhat.com/show_bug.cgi?id=481527 David Timms : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539837 Dominic Hopf : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533302 Jan Klepek : 1 https://bugzilla.redhat.com/show_bug.cgi?id=503336 Jaroslav Reznik : 1 https://bugzilla.redhat.com/show_bug.cgi?id=529517 Jon Ciesla : 1 https://bugzilla.redhat.com/show_bug.cgi?id=424841 Matthew Kent : 1 https://bugzilla.redhat.com/show_bug.cgi?id=539606 Mattias Ellert : 1 https://bugzilla.redhat.com/show_bug.cgi?id=531051 Michal Ingeli : 1 https://bugzilla.redhat.com/show_bug.cgi?id=532205 Michal Schmidt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=507083 Orcan 'oget' Ogetbil : 1 https://bugzilla.redhat.com/show_bug.cgi?id=498218 Paul Howarth : 1 https://bugzilla.redhat.com/show_bug.cgi?id=533721 Ralf Corsepius : 1
Re: abrt and bugzilla
Am Freitag, den 20.11.2009, 23:05 + schrieb Colin Walters: On Fri, Nov 20, 2009 at 10:52 PM, Kevin Kofler kevin.kof...@chello.at wrote: Colin Walters wrote: In an anonymous crash system, there should be a promote to bugzilla link, where people could comment. And how would you track down the original submitter if you need further information from him? You don't; the submitter of course should get a link to their crash report, and can perform the bugzilla promotion on their own if they have more to add. From my experience they don't have anything to add, not even a small comment on what they were doing when the application crashed. This should be mandatory in abrt. I have many reports that even lack debuginfo and even if I tell users how to install it manually, I don't get a response. From now on I will set all these bugs to NEEDINFO REPORTER and if I don't hear back from them within 4 weeks, close their reports. I'm sure this is not how it's supposed to work because it's not fruitful and nether the maintainers nor the reporters are happy. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091123 changes
Compose started at Mon Nov 23 08:15:13 UTC 2009 New package Vuurmuur Firewall manager built on top of iptables New package ndisc6 IPv6 diagnostic tools Updated Packages: abrt-1.0.0-1.fc13 - * Fri Nov 20 2009 Jiri Moskovcak jmosk...@redhat.com 1.0.0-1 - new version - comment input wraps words rhbz#531276 - fixed hiding password dialog rhbz#529583 - easier kerneloops reporting rhbz#528395 - made menu entry translatable rhbz#536878 (jmosk...@redhat.com) - GUI: don't read the g-k every time we want to use the setting (jmosk...@redhat.com) - GUI: survive if g-k access is denied rhbz#534171 (jmosk...@redhat.com) - include more info into oops (we were losing the stack dump) (vda.li...@googlemail.com) - make BZ insert small text attachments inline; move text file detection code (vda.li...@googlemail.com) - GUI: fixed text wrapping in comment field rhbz#531276 (jmosk...@redhat.com) - GUI: added cancel to send dialog rhbz#537238 (jmosk...@redhat.com) - include abrt version in bug descriptions (vda.li...@googlemail.com) - ccpp hook: implemented ReadonlyLocalDebugInfoDirs directive (vda.li...@googlemail.com) - GUI: added window icon rhbz#537240 (jmosk...@redhat.com) - add support for \ escaping in config file (vda.li...@googlemail.com) - add experimental saving of /var/log/Xorg*.log for X crashes (vda.li...@googlemail.com) - APPLET: changed icon from default gtk-warning to abrt specific, add animation (jmosk...@redhat.com) - don't show icon on abrtd start/stop rhbz#537630 (jmosk...@redhat.com) - /var/cache/abrt permissions 1775 - 0775 in spec file (kk...@redhat.com) - Daemon properly checks /var/cache/abrt attributes (kk...@redhat.com) - abrt user group; used by abrt-pyhook-helper (kk...@redhat.com) - pyhook-helper: uid taken from system instead of command line (kk...@redhat.com) - KerneloopsSysLog: fix breakage in code which detects abrt marker (vda.li...@googlemail.com) - GUI: added support for backtrace rating (jmosk...@redhat.com) - InformAllUsers support. enabled by default for Kerneloops. Tested wuth CCpp. (vda.li...@googlemail.com) - abrtd: call res_init() if /etc/resolv.conf or friends were changed rhbz#533589 (vda.li...@googlemail.com) - supress errors in python hook to not colide with the running script (jmosk...@redhat.com) aimage-3.2.3-1.fc13 --- * Sun Nov 22 2009 Nicolas Chauvet kwiz...@fedoraproject.org - 3.2.3-1 - Update to 3.2.3 - Remove upstreamed patch apanov-heuristica-fonts-0.2-5.fc13 -- * Sun Nov 22 2009 Nicolas Mailhot nicolas.mailhot at laposte.net - 1:0.2-5 — remove evil duplicate TTF files autofs-5.0.5-8.fc13 --- * Mon Nov 23 2009 Ian Kent ik...@redhat.com - 1:5.0.5-8 - fix timeout in connect_nb(). banshee-1.5.2-1.fc13 * Mon Nov 23 2009 Michel Salim sali...@fedoraproject.org - 1.5.2-1 - Update to final 1.5.2 release cherokee-0.99.29-1.fc13 --- * Sun Nov 22 2009 Lorenzo Villani lvill...@binaryhelix.net - 0.99.29-1 - 0.99.29 dnsmasq-2.51-2.fc13 --- * Sun Nov 22 2009 Itamar Reis Peixoto ita...@ispbrasil.com.br - 2.51-2 - fix bz 512664 eclipse-mylyn-3.3.0-4.fc13 -- * Sun Nov 22 2009 Alexander Kurtakov akurt...@redhat.com 3.3.0-4 - Fix build with newer common-codec. eclipse-subclipse-1.6.5-3.fc13 -- * Sun Nov 22 2009 Alexander Kurtakov akurt...@redhat.com 1.6.5-2 - Do not pass non-existing folders to pdebuild -o. - Switch to using %global instead of %define. * Sun Nov 22 2009 Alexander Kurtakov akurt...@redhat.com 1.6.5-3 - Fix typo. emelfm2-0.7.0-1.fc13 * Sun Nov 22 2009 Christoph Wickert cwick...@fedoraproject.org - 0.7.0-1 - Update to 0.7.0 fontpackages-1.34-1.fc13 gnome-applet-alarm-clock-0.2.6-1.fc13 - * Mon Nov 23 2009 Christoph Wickert cwick...@fedoraproject.org - 0.2.6-1 - Update to 0.2.6 gstreamermm-0.10.5.2-1.fc12 --- * Sat Nov 07 2009 Denis Leroy de...@poolshark.org - 0.10.5.2-1 - Update to 0.10.5.2 - Fix devhelp doc setup gtk-rezlooks-engine-0.6-10.fc13 --- * Sun Nov 22 2009 Mads Villadsen m...@krakoa.dk - 0.6-10 - Updated source location for the main engine - Do not own /usr/share/themes. Fixes bug #534101. gwibber-2.0.0-2.478bzr.fc13 --- * Sun Nov 22 2009 Ian Weller i...@ianweller.org - 1:2.0.0-2.478bzr - Add Requires: python-pycurl ipod-sharp-0.8.5-1.fc13 --- * Mon Nov 23 2009 Michel Salim sali...@fedoraproject.org - 0.8.5-1 - Update to 0.8.5 kdevplatform-0.9.95-0.6.20091015svn1035382.fc13 --- * Sun Nov 22 2009 Rex Dieter rdie...@fedoraproject.org 0.9.95-0.6.20091015svn1035382 - rebuild (fc13+, qt-4.6.0-rc1) klatexformula-3.1.2-1.fc13 -- * Sun Nov 22 2009 Alexey Kurov nuc...@fedoraproject.org
Re: abrt and bugzilla
- Original Message - From: Christoph Wickert christoph.wick...@googlemail.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Sent: Monday, November 23, 2009 7:25 AM Subject: Re: abrt and bugzilla Am Freitag, den 20.11.2009, 23:05 + schrieb Colin Walters: On Fri, Nov 20, 2009 at 10:52 PM, Kevin Kofler kevin.kof...@chello.at wrote: Colin Walters wrote: In an anonymous crash system, there should be a promote to bugzilla link, where people could comment. And how would you track down the original submitter if you need further information from him? You don't; the submitter of course should get a link to their crash report, and can perform the bugzilla promotion on their own if they have more to add. From my experience they don't have anything to add, not even a small comment on what they were doing when the application crashed. This should be mandatory in abrt. I have many reports that even lack debuginfo and even if I tell users how to install it manually, I don't get a response. From now on I will set all these bugs to NEEDINFO REPORTER and if I don't hear back from them within 4 weeks, close their reports. I'm sure this is not how it's supposed to work because it's not fruitful and nether the maintainers nor the reporters are happy. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list well, abrt just pops up and sends a report without user control, the user maybe doing nothing and a app crashes and a report is generated. If you can't solve the problem from the report generated then remove the automatic bug reporting app and save everybody headaches. I upgraded my system for test and probably the reports that are generated are because of conflicts from old packages with packages in f12 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Am Montag, den 23.11.2009, 13:28 + schrieb Rawhide Report: nimbus-0.1.4-2.fc13 --- * Sun Nov 22 2009 Christoph Wickert cwick...@fedoraproject.org - 0.1.4-1 - Update to 0.1.4 * Sun Nov 22 2009 Christoph Wickert cwick...@fedoraproject.org - 0.1.4-2 - Fix srciptlets of nimbus-icon-theme * Fri Nov 13 2009 Christoph Wickert cwick...@fedoraproject.org - 0.0.17-8.1 - Remove reference to non existant notification engine (#537161) Can this be fixed please? Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Am Montag, den 23.11.2009, 13:28 + schrieb Rawhide Report: nimbus-0.1.4-2.fc13 --- * Sun Nov 22 2009 Christoph Wickert cwick...@fedoraproject.org - 0.1.4-1 - Update to 0.1.4 * Sun Nov 22 2009 Christoph Wickert cwick...@fedoraproject.org - 0.1.4-2 - Fix srciptlets of nimbus-icon-theme * Fri Nov 13 2009 Christoph Wickert cwick...@fedoraproject.org - 0.0.17-8.1 - Remove reference to non existant notification engine (#537161) Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. BTW: Is there a place where I can look at the rawhide report script? Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, Nov 23, 2009 at 03:04:49PM +0100, Christoph Wickert wrote: Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. BTW: Is there a place where I can look at the rawhide report script? https://fedorahosted.org/rel-eng/browser or git clone git://git.fedorahosted.org/git/releng josh -- 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
Kevin Kofler kevin.kof...@chello.at writes: I never tick those boxes. I'd like to know how to get rid of them entirely. Upgrade to F12 (with the latest PackageKit update), there's no such checkbox in F12's PolicyKit. This is good. Also we should remember that user entering root password in user's session makes the user account practically equivalent to root (it can be seen as a protection against incidental damage, but not against a real attack). The only secure way has to use a fully trusted path from the person to the root process - e.g. logging as root (or root-equivalent) initially, with a physically secured console (some sysrq-k or ctrl-alt-del combo which cannot be remapped or blocked by non-root etc). E.g. using su or in most cases sudo etc. makes the non-root account equivalent to root. This can be, of course, deemed secure as long as we accept and understand this equivalency. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-11-18 x86_64
On Wed, Nov 18, 2009 at 10:33:26PM -0600, Matt Domsch wrote: Fedora Rawhide-in-Mock Build Results for x86_64 using the rawhide tree as of 2009-11-15. All packages were built on systems running Fedora 12. All failed builds were retried to avoid single or transient build failures. I'm going to start putting this text in the initial comments for any bug automatically filed by the FTBFS runs. Hopefully this helps explain the process which is described also at http://fedoraproject.org/wiki/FTBFS . If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the Depends on line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Right-click for wacom driver?
On Sun, 2009-11-22 at 15:25 -0800, Luya Tshimbalanga wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While working on Flash development in Windows XP TabletPC, I noticed the right-click is done by pressing the stylus for few second and icon will display the right-click mouse delay. I wonder if the new xorg-x11-drv-wacom can do similar action for stylus that don't have eraser action. I am not sure if the current linuxwacom can do similar action. If so, how can it be done? In related news, I have a tablet PC where the button on the stylus is right-click under Windows, but appears to be Erase under X, meaning I don't have any way to right-click. Worth changing the default? Alternatively, is Gnome getting a UI and gconf persistence for input settings any time soon? - 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?
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 :-) I know this is non-obvious, but: BadIDChoice or BadImplementation X errors are _always_ bugs in libX11 or the server itself, respectively. Please reassign BadIDChoice bugs to libX11. - 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: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, 23 Nov 2009 15:04:49 +0100, Christoph wrote: Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. Well, somebody could still apply my patch attached to #7. It's a year old and still without a reply. It would print the missing changelog entries, which is what the ticket is about. | repodiff misses changelog entries (corner-case) | http://yum.baseurl.org/ticket/7 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, 23 Nov 2009, Michael Schwendt wrote: On Mon, 23 Nov 2009 15:04:49 +0100, Christoph wrote: Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. Well, somebody could still apply my patch attached to #7. It's a year old and still without a reply. It would print the missing changelog entries, which is what the ticket is about. | repodiff misses changelog entries (corner-case) | http://yum.baseurl.org/ticket/7 I've replied a bunch of times and I offered you access to commit it yourself. You never responded. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
Jiri Moskovcak wrote: Thx, btw, I thought there was a plan to unite the dbus interfaces for kwallet and g-keyring. AFAIK, that hasn't been implemented yet. :-( Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Mon, 2009-11-23 at 16:58 +0100, Kevin Kofler wrote: Jiri Moskovcak wrote: Thx, btw, I thought there was a plan to unite the dbus interfaces for kwallet and g-keyring. AFAIK, that hasn't been implemented yet. :-( Kevin Kofler I believe the gnome-keyring implementation lives here: http://git.gnome.org/cgit/gnome-keyring/log/?h=dbus-api -- 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 Mon, Nov 23, 2009 at 12:01 AM, repo-font-audit nicolas.mail...@gmail.com wrote: Dear packager, [snip] To stop receiving this message, you need to: 1. drop the font files or fix their packaging; 2. relay the fonts issues to the fonts upstream to get them revised; 3. work with the code upstream to improve the way it accesses font files (usually by making it use fontconfig through a higher-level text library such as pango, pango-cairo, harfbuzz, or QT) I maintain multiple packages that use core fonts. I do not have the expertise to migrate those packages, all of which are large and complex, to a new font system. I have neither the time nor the interest to gain that expertise. The upstreams, save one, have expressed 0 interest in doing that work themselves. The one that has expressed interest, XEmacs, currently has a half-baked fontconfig/Xft implementation that is stalled because the programmers that started it went on to other things without finishing it. So it appears to me that this message is really saying: 1) I'm going to nag you forever about a problem you can't fix. 2) There is no way to make me stop nagging you. I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. -- Jerry James, who thought he was doing the Fedora community a favor when he rescued gcl from the bit bin http://www.jamezone.org/ -- 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 Monday, 23 November 2009 at 17:51, Jerry James wrote: [...] I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. +1. 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: [RFA] Your gnu-free-fonts package did not pass QA
repo-font-audit wrote: Dear packager, At 20091122T202901Z, your “gnu-free-fonts” package failed one or more of the tests I was performing on the “fedora-devel” repository located at: http://koji.fedoraproject.org/static-repos/dist-f13-build-current/x86_64/ There are three different reasons that may cause this message: 1. your package is including one or more font files, but not packaging them properly; 2. your package is including one or more font files, and I've found issues in some of them; 3. your package is not shipping any font file, but the way it accesses fonts in other packages is not satisfying. To stop receiving this message, you need to: 1. drop the font files or fix their packaging; 2. relay the fonts issues to the fonts upstream to get them revised; 3. work with the code upstream to improve the way it accesses font files (usually by making it use fontconfig through a higher-level text library such as pango, pango-cairo, harfbuzz, or QT) You can self-check your packages at any time by: 1. installing createrepo and fontpackages-tools: # yum install createrepo fontpackages-tools 2. putting your packages and any font package they depends on in a test directory 3. indexing this directory with createrepo: $ createrepo path-to-test-directory 4. running repo-font-audit: $ repo-font-audit test file://absolute-path-to-test-directory A summary of the issues I detected is appended here. For your convenience a more comprehensive analysis is also attached to this message. Errors, warnings and suggestions: P# t5 t13 t17 t19 t20 1 4 1444 2 4 1341 3 4 1‧34 Total 12 3711 9 P# Maintainer SRPMRPM EVR Arch 1 limbgnu-free-fonts gnu-free-mono-fonts 0:20090104-11.fc12 noarch 2 limbgnu-free-fonts gnu-free-sans-fonts 0:20090104-11.fc12 noarch 3 limbgnu-free-fonts gnu-free-serif-fonts 0:20090104-11.fc12 noarch Test explanation: t5. Error: font faces duplicated by different packages ☛ Packager task, eventual upstream task Several packages duplicate font files with the same face name. This needlessly wastes resources infrastructure and user side and makes font maintenance problematic: 1. Very often an upstream that copied some fonts will forget to keep them up to date, and the duplication will result in the distribution of old buggy data. 2. Shipping the same font in different formats is also problematic: different font formats have different features, and are processed by different font libraries. It is almost impossible to create a font in multiple formats that will all behave the same. Users hate fonts that do not behave consistently everywhere. 3. Most of our applications use fontconfig to access fonts, and fontconfig uses font names to identify files. Naming collisions make font selection unreliable. So even genuine forks with different features from the original are a problem if not renamed. A repository should always include only one version of a font face. This test can not discriminate between packages and identity the correct owner of the font face. His maintainer will be blamed with others. If you're not him it is therefore unfriendly not to fix this error as soon as you can. It is always possible to reuse a font file packaged separately by adding a dependency on the other package providing it, and accessing the font through fontconfig. If an application can not use fontconfig today this is a serious bug that should be reported to the application upstream. Please ask it to add fontconfig support to their code (usually, via a higher-level library such as pango-cairo). However it can workarounded by the packager with symlinks (that will need maintenance). If an application can not use a modern font format and forces the re-packaging in an older format of an exiting font this is an application bug that should be reported to the application upstream. In that case these is no good solution possible baring the fixing of the application. t13. Warning: bad font naming ☛ Font upstream task, with packager workarounds The font naming declared by one or more files in the package is not a canonical WWS¹ naming or has some other naming problem. As noted by Adobe² the W3C CSS font family model used in WPF/WWS is less than ideal, but it is a standard and applications expect it. This script attempted to apply some heuristics to fix this naming, and computed different values than those in the font files. That means some of those files are using non-standard, fuzzy, self-conflicting, confusing names. A correct naming: 1. only includes “Width”, “Weight”, “Slant” qualifiers in its style name; 2. does not declare more than one of each; 3. declares them using the canonical keywords defined in the
Re: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, 23 Nov 2009 10:56:58 -0500 (EST), Seth wrote: On Mon, 23 Nov 2009, Michael Schwendt wrote: On Mon, 23 Nov 2009 15:04:49 +0100, Christoph wrote: Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. Well, somebody could still apply my patch attached to #7. It's a year old and still without a reply. It would print the missing changelog entries, which is what the ticket is about. | repodiff misses changelog entries (corner-case) | http://yum.baseurl.org/ticket/7 I've replied a bunch of times and I offered you access to commit it yourself. You never responded. Do I need to repeat myself again and again that [and why] I don't want to maintain repoclosure? I've told you that at least once, and we have never talked specifically about commit access to repodiff. Not a year ago, not in tickets #7 or #6, and not recently either. Perhaps with a comment (in Oct 2009, months later) such as https://bugzilla.redhat.com/521621#c1 in the context of repoclosure (!) again, you meant to cover repodiff, too. If that's true, you haven't made that clear. I realise that both repoclosure and repodiff belong into yum-utils, but hey, I have not asked for commit access to either one. How hard can it be to accept a patch or reject it with a brief comment? Btw: The comment on #6 (not by you, but by jlaska, was mostly negative even, which is quite the opposite of offering commit access to that tool. The comment claimed my tested patch would be wrong - not true, it is tons better than the broken reverse'n'sort implementation in createrepo+repodiff that just doesn't work as demonstrated by the rawhide report for a long time and even broke repoview. Compare that with the old Fedora Extras build report which still runs and runs and runs at RPM Fusion without such errors). -- 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
James Morris (jmor...@namei.org) said: MAC policy can be updated without administrative privilege, breaking our MAC model in a fundamental way. I'm fairly sure that's wrong as well. Installation of another policy does not override the current one. What about when the system is rebooted? One scenario here is where the admin has made local modifications, which are then discarded by an upgrade of the policy. It should not be possible. Your complaint appeared to be that someone could switch from targeted to minimal (or similar) by simply installing the other package. It *does not work that way*, and it never has. If you're saying that an upgrade to a later targeted policy might break the local customizations, doesn't that mean the targeted policy maintainer made a mistake? Bill -- 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 17:51, schrieb Jerry James: I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. +1 Also see https://bugzilla.redhat.com/show_bug.cgi?id=507132 We subsequently removed the -tests subpackage because PHP Unit testing actually doesn't integrate well with fontconfig ;) Felix -- 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, Nov 23, 2009 at 9:37 AM, Krzysztof Halasa k...@pm.waw.pl wrote: Kevin Kofler kevin.kof...@chello.at writes: I never tick those boxes. I'd like to know how to get rid of them entirely. Upgrade to F12 (with the latest PackageKit update), there's no such checkbox in F12's PolicyKit. This is good. Also we should remember that user entering root password in user's session makes the user account practically equivalent to root (it can be seen as a protection against incidental damage, but not against a real attack). The only secure way has to use a fully trusted path from the person to the root process - e.g. logging as root (or root-equivalent) initially, with a physically secured console (some sysrq-k or ctrl-alt-del combo which cannot be remapped or blocked by non-root etc). E.g. using su or in most cases sudo etc. makes the non-root account equivalent to root. This can be, of course, deemed secure as long as we accept and understand this equivalency. There are many kinds of security threat out there. For example, a few dishonest people within the fedora project could conspire to backdoor the heck out of Fedora with a reasonable chance of not getting caught. Does this fact mean that we should not bother with signing packages or other security measures? Likewise, someone could load up some kind of X sniffer that intercepts the root password when its typed in. Someone could also break into your house and take apart your computer. Yet in many environments these threats are insignificant compared to a co-worker or family member casually twiddling around with the machine. I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Surely this would be preferable to reducing the security against common casual threats. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Hi, With a little delay here are the font audit results for Fedora 12 and 2009-11-22 fedora-devel. I think I've taken into account all the feedback I received since last run. More feedback is of course welcome (except for the file size computation, I know it's broken, was not worth re-doing a 7h test run to fix it). Seeing some numbers go down would be nice. Individual packagers should have received their personalized notification some hours ago (some in duplicate, the first relay host I used blacklisted me as a spammer sometime in the middle of the run so I had to restart everything, sorry about that, will try to improve). Some people asked me why I didn't go the bugzilla route: look at the numbers, there's no way I can write a script smart enough to manage hundreds of bugs with different states. And doing it manually alone would be a nightmare. Special mention goes to jussilehtola for xine-ui: not only he managed to add 27 font files not packaged according to Fedora guidelines during the F-12 cycle, but 14 are copies of the same font. Regards, -- 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: [RFA] Font audit results for Fedora 12 (final)
(sorry, this one is for devel) -- 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
[RFA] Font package differences between Fedora 11 and Fedora 12
B. Font package changes: = GraphicsMagick-perl.rpm (GraphicsMagick.src.rpm, ixs) ⇒ GraphicsMagick.src.rpm, ixs + ArtBrush, Medium, TrueType /usr/share/doc/GraphicsMagick-perl-1.3.7/demo/Generic.ttf − ArtBrush, Medium, TrueType /usr/share/doc/GraphicsMagick-perl-1.1.14/demo/Generic.ttf = ImageMagick-perl.rpm (ImageMagick.src.rpm, jwrdegoede) ⇒ ImageMagick.src.rpm, jwrdegoede + Tuffy, Regular, TrueType /usr/share/doc/ImageMagick-perl-6.5.4.7/demo/Generic.ttf − Tuffy, Regular, TrueType /usr/share/doc/ImageMagick-perl-6.5.1.2/demo/Generic.ttf + adf-accanthis-2-fonts.rpm (adf-accanthis-fonts.src.rpm, nim, M) + Accanthis ADF Std No2, Bold, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-Bold.otf + Accanthis ADF Std No2, Bold Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-BoldItalic.otf + Accanthis ADF Std No2, Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-Italic.otf + Accanthis ADF Std No2, Regular, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo2-Regular.otf + adf-accanthis-3-fonts.rpm (adf-accanthis-fonts.src.rpm, nim, M) + Accanthis ADF Std No3, Bold, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-Bold.otf + Accanthis ADF Std No3, Bold Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-BoldItalic.otf + Accanthis ADF Std No3, Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-Italic.otf + Accanthis ADF Std No3, Regular, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStdNo3-Regular.otf + adf-accanthis-fonts.rpm (adf-accanthis-fonts.src.rpm, nim, M) + Accanthis ADF Std, Bold, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-Bold.otf + Accanthis ADF Std, Bold Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-BoldItalic.otf + Accanthis ADF Std, Italic, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-Italic.otf + Accanthis ADF Std, Regular, CFF /usr/share/fonts/adf-accanthis/AccanthisADFStd-Regular.otf + adf-tribun-fonts.rpm (adf-tribun-fonts.src.rpm, nim, M) + Tribun ADF Std Cond, Bold, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-CondBold.ttf + Tribun ADF Std Cond, Bold Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-CondBoldItalic.ttf + Tribun ADF Std Cond, Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-CondItalic.ttf + Tribun ADF Std Cond, Regular, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Cond.ttf + Tribun ADF Std Med, Bold, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-MedBold.ttf + Tribun ADF Std Med, Bold Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-MedBoldItalic.ttf + Tribun ADF Std Med, Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-MedItalic.ttf + Tribun ADF Std Med, Medium, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Med.ttf + Tribun ADF Std, Bold, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Bold.ttf + Tribun ADF Std, Bold Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-BoldItalic.ttf + Tribun ADF Std, Italic, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Italic.ttf + Tribun ADF Std, Regular, TrueType /usr/share/fonts/adf-tribun/TribunADFStd-Regular.ttf + apa-new-athena-unicode-fonts.rpm (apa-new-athena-unicode-fonts.src.rpm, ankursinha, M) + New Athena Unicode, Regular, TrueType /usr/share/fonts/apa-new-athena-unicode/newathu.ttf = apanov-edrip-fonts.rpm (apanov-edrip-fonts.src.rpm, nim, M) ⇒ apanov-edrip-fonts.src.rpm, nim, M + Edrip, Bold Italic, TrueType /usr/share/fonts/apanov-edrip/Edrip-BoldItalic.ttf − Edrip, BoldItalic, TrueType /usr/share/fonts/apanov-edrip/Edrip-BoldItalic.ttf = apanov-heuristica-fonts.rpm (apanov-heuristica-fonts.src.rpm, nim, M) ⇒ apanov-heuristica-fonts.src.rpm, nim, M + Heuristica, Bold Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf − Heuristica, BoldItalic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf + bitmap-cjk-fonts.rpm (bitmap-fonts.src.rpm, pnemade, M) + Fangsong ti, Regular, PCF /usr/share/fonts/bitmap/fangsongti16.pcf + Fangsong ti, Regular, PCF /usr/share/fonts/bitmap/fangsongti24.pcf = bitmap-fonts.rpm (bitmap-fonts.src.rpm, pnemade) ⇒ bitmap-fonts.src.rpm, pnemade, M + Console, Regular, PCF /usr/share/fonts/bitmap/console8x16.pcf − Console, Regular, PCF /usr/share/fonts/bitmap-fonts/console8x16.pcf + Fixed, Regular, PCF /usr/share/fonts/bitmap/console9x15.pcf − Fixed, Regular, PCF /usr/share/fonts/bitmap-fonts/console9x15.pcf + LucidaTypewriter, Sans, PCF /usr/share/fonts/bitmap/lutRS08.pcf + LucidaTypewriter, Sans, PCF /usr/share/fonts/bitmap/lutRS10.pcf + LucidaTypewriter, Sans, PCF /usr/share/fonts/bitmap/lutRS12.pcf + LucidaTypewriter, Sans, PCF
[RFA] Font test result differences between Fedora 11 and Fedora 12
A. Test result changes: P# t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 t17 t18 1‧‧ ‧ ‧ ‧ ‧‧ 5‧‧‧‧‧‧‧ ‧‧‧ 2‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 3‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧‧‧ 41‧ 1 ‧ ‧ 1‧ ‧‧‧-2 1‧11 ‧11 5‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 6‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧11 7‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ 11‧ 8‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ 11‧ 9‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 10 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧2‧‧‧ ‧2‧ 11 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 12 ‧‧ ‧ -1 ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 13 -5 ‧ -5 ‧ ‧ -5 ‧ -1 -5 ‧‧-5 ‧-5 -5 -4 -5 -5 14 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 15 ‧‧ ‧ ‧ ‧ ‧‧ ‧4‧‧‧‧44 ‧3‧ 16 -1 ‧ -1 ‧ ‧ ‧‧ ‧‧‧1-1 ‧-1 -1 ‧-1 ‧ 17 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 18 -1 ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 19 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧1‧ ‧‧‧ 20 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧1‧ ‧‧‧ 21 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧-1 ‧‧‧ ‧‧-4 22 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧-4 23 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧-4 24 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 25 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 26 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 27 ‧‧ ‧ ‧ ‧ ‧‧ -1 ‧‧‧‧‧‧‧ 1‧‧ 28 ‧‧ ‧ ‧ ‧ ‧‧ ‧2‧‧‧‧‧‧ ‧2‧ 29 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 30 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 31 ‧‧ ‧ ‧ -1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 32 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ ‧‧1 33 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 34 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧1‧ 35 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 36 ‧‧ ‧ ‧ ‧ -4 ‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 37 ‧‧ ‧ ‧ 1 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 38 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧3‧‧‧‧ ‧‧‧ 39 ‧‧ 27 ‧ ‧ ‧7 27 27 ‧‧27 20 27 27 ‧27 ‧ 40 1‧ 1 ‧ ‧ 1‧ 1‧‧‧‧‧11 11‧ 41 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1‧‧‧ ‧‧‧ 42 -2 -1 -2 ‧ ‧ -1 ‧ ‧‧‧‧-2 -2 -2 -2 ‧-2 -2 43 ‧1 ‧ ‧ ‧ 1‧ ‧‧‧‧22‧‧ ‧2‧ 44 ‧‧ 1 ‧ ‧ ‧‧ ‧‧‧‧1‧11 ‧1‧ 45 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧3‧‧‧‧ ‧‧‧ 46 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ -2 -2 ‧ 47 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧‧‧‧‧ 22‧ 48 ‧‧ ‧ ‧ ‧ ‧‧ -1 ‧‧‧‧‧‧‧ ‧‧‧ 49 ‧‧ ‧ ‧ ‧ ‧‧ -15 ‧‧‧‧‧‧‧ ‧‧‧ 50 ‧‧ ‧ ‧ -3 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 51 ‧‧ ‧ ‧ 2 ‧‧ ‧‧‧‧‧‧‧‧ ‧‧‧ 52 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧4‧‧‧ ‧4‧ 53 ‧‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧4‧‧‧ ‧4
[RFA] Font test result differences between Fedora 12 and 2009-11-22 devel
A. Test result changes: P# t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 1‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 2‧ ‧ ‧ ‧ ‧ ‧ ‧ -10 ‧ ‧‧‧‧‧ 35 ‧ 5 ‧ 5 1 5 ‧5 55455 4‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 5‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 6‧ ‧ ‧ -1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 75 -1 -1 ‧ 1 ‧ -1 ‧-1 -1 -1 ‧-1 -6 8‧ ‧ ‧ ‧ 4 ‧ ‧ ‧‧ ‧‧‧‧‧ 9‧ ‧ ‧ ‧ 1 ‧ ‧ ‧‧ ‧‧‧‧‧ 10 ‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 11 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧-1 ‧‧‧‧‧ 12 ‧ ‧ ‧ ‧ -1 ‧ ‧ ‧‧ ‧‧‧‧‧ 13 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧11‧ 14 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 15 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 16 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧11‧ 17 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧11‧ 18 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧1‧ 19 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧4 ‧‧‧4‧ 20 -1 ‧ -1 ‧ -1 ‧ ‧ ‧-1 ‧-1 ‧-1 ‧ 21 ‧ ‧ ‧ ‧ 1 1 ‧ ‧‧ ‧‧‧‧‧ 22 ‧ ‧ ‧ 1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 23 ‧ ‧ ‧ ‧ ‧ ‧ ‧ -2 ‧ ‧‧‧‧‧ 24 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧25 25 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧‧‧ 26 ‧ ‧ ‧ ‧ 1 ‧ ‧ ‧‧ ‧‧‧‧‧ 27 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 28 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧1 ‧‧‧1‧ 29 ‧ 2 2 ‧ 1 ‧ 2 ‧2 2212‧ 30 ‧ ‧ ‧ -1 ‧ ‧ ‧ ‧‧ ‧‧‧‧‧ 31 ‧ ‧ ‧ ‧ ‧ ‧ ‧ ‧‧ ‧‧‧‧1 Balance 9 1 5 2 12 2 6 -12 15 65818 25 P# Maintainer RPM SRPM 1 adsllc drehatlas-xaporho-fonts drehatlas-xaporho-fonts 2 akahlphp-ZendFramework php-ZendFramework-tests 3 awjb koffice koffice-core 4 chkr xskat xskat 5 dougslandzbar zbar 6 hedayat rcssmonitor rcssmonitor 7 icon python-reportlab python-reportlab 8 jnovytexlive-texmf texlive-texmf-fonts 9 lyosnorezel darkgarden-fonts darkgarden-fonts 10 nbecker libotflibotf 11 nim apanov-heuristica-fonts apanov-heuristica-fonts 12 nim dejavu-fonts dejavu-sans-fonts 13 ozamosi gdouros-aegean-fonts gdouros-aegean-fonts 14 ozamosi gdouros-aegyptus-fontsgdouros-aegyptus-fonts 15 ozamosi gdouros-akkadian-fontsgdouros-akkadian-fonts 16 ozamosi gdouros-alexander-fonts gdouros-alexander-fonts 17 ozamosi gdouros-analecta-fontsgdouros-analecta-fonts 18 ozamosi gdouros-musica-fonts gdouros-musica-fonts 19 ozamosi msimonson-anonymouspro-fonts msimonson-anonymouspro-fonts 20 phuang scim scim-doc 21 rdieter lyx lyx-cmex10-fonts 22 roma xpaintxpaint 23 s4504kr stellariumstellarium 24 stevetuxpaint tuxpaint 25 tagohsazanami-fontssazanami-gothic-fonts 26 tagohvlgothic-fontsvlgothic-fonts 27 tk009ns-bola-fonts ns-bola-fonts 28 tk009ns-tiza-chalk-fonts ns-tiza-chalk-fonts 29 wart wormuxwormux-data 30 xgl-maintxorg-x11-apps xorg-x11-apps 31 xulchris pygamepygame t1. Error: fonts in arch packages t2. Warning: bad font naming t3. Warning: fonts in packages that do not respect font naming conventions t4. Warning: core fonts use t5. Error: font faces duplicated by different packages t6. Error: exact font duplication t7. Error: packages that mix different font families t8. Warning: font linking t9. Warning: fonts that do not pass fontlint sanity checks t10. Error: fonts in packages that contain non-font data t11. Error: fonts deployed outside /usr/share/fonts t12. Suggestion: fonts with partial unicode block coverage t13. Suggestion: fonts with partial script coverage t14. Error: rpmlint signature.asc Description: Ceci est une partie de message
[RFA] Font package differences between Fedora 12 and 2009-11-22 Fedora devel
B. Font package changes: = apanov-heuristica-fonts.rpm (apanov-heuristica-fonts.src.rpm, nim, M) ⇒ apanov-heuristica-fonts.src.rpm, nim, M − Heuristica, Bold, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Bold.otf + Heuristica, Bold, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Bold.ttf − Heuristica, Bold Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.otf + Heuristica, Bold Italic, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-BoldItalic.ttf − Heuristica, Italic, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Italic.otf + Heuristica, Italic, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Italic.ttf − Heuristica, Regular, CFF /usr/share/fonts/apanov-heuristica/Heuristica-Regular.otf + Heuristica, Regular, TrueType /usr/share/fonts/apanov-heuristica/Heuristica-Regular.ttf + drehatlas-xaporho-fonts.rpm (drehatlas-xaporho-fonts.src.rpm, adsllc, M) + Xaporho, Regular, CFF /usr/share/fonts/drehatlas-xaporho/Xaporho.otf + gdouros-aegean-fonts.rpm (gdouros-aegean-fonts.src.rpm, ozamosi, M) + Aegean, Regular, TrueType /usr/share/fonts/gdouros-aegean/Aegean.otf + gdouros-aegyptus-fonts.rpm (gdouros-aegyptus-fonts.src.rpm, ozamosi, M) + Aegyptus, Regular, TrueType /usr/share/fonts/gdouros-aegyptus/Aegyptus.otf + gdouros-akkadian-fonts.rpm (gdouros-akkadian-fonts.src.rpm, ozamosi, M) + Akkadian, Regular, TrueType /usr/share/fonts/gdouros-akkadian/Akkadian.otf + gdouros-alexander-fonts.rpm (gdouros-alexander-fonts.src.rpm, ozamosi, M) + Alexander, Regular, TrueType /usr/share/fonts/gdouros-alexander/Alexander.otf + gdouros-analecta-fonts.rpm (gdouros-analecta-fonts.src.rpm, ozamosi, M) + Analecta, Regular, TrueType /usr/share/fonts/gdouros-analecta/Analecta.otf + gdouros-musica-fonts.rpm (gdouros-musica-fonts.src.rpm, ozamosi, M) + Musica, Regular, TrueType /usr/share/fonts/gdouros-musica/Musica.otf + koffice-core.rpm (koffice.src.rpm, awjb) + Arev Sans, Bold, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevBd.ttf + Arev Sans, Bold Oblique, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevBI.ttf + Arev Sans, Oblique, TrueType /usr/share/kde4/apps/formulashape/fonts/ArevIt.ttf + Arev Sans, Regular, TrueType /usr/share/kde4/apps/formulashape/fonts/Arev.ttf + cmex10, Regular, TrueType /usr/share/kde4/apps/formulashape/fonts/cmex10.ttf + msimonson-anonymouspro-fonts.rpm (msimonson-anonymouspro-fonts.src.rpm, ozamosi, M) + Anonymous Pro, Bold, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro B.ttf + Anonymous Pro, Bold Italic, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro BI.ttf + Anonymous Pro, Italic, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro I.ttf + Anonymous Pro, Regular, TrueType /usr/share/fonts/msimonson-anonymouspro/Anonymous Pro.ttf + ns-bola-fonts.rpm (ns-bola-fonts.src.rpm, tk009, M) + Bola, Regular, TrueType /usr/share/fonts/ns-bola/bola.ttf + ns-tiza-chalk-fonts.rpm (ns-tiza-chalk-fonts.src.rpm, tk009, M) + Tiza, Regular, TrueType /usr/share/fonts/ns-tiza-chalk/tiza_chalk.ttf = python-reportlab.rpm (python-reportlab.src.rpm, icon) ⇒ python-reportlab.src.rpm, icon + Bitstream Vera Sans, Bold, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraBd.ttf − Bitstream Vera Sans, Bold, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBd.ttf + Bitstream Vera Sans, Bold Oblique, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraBI.ttf − Bitstream Vera Sans, Bold Oblique, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraBI.ttf + Bitstream Vera Sans, Oblique, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/VeraIt.ttf − Bitstream Vera Sans, Oblique, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/VeraIt.ttf + Bitstream Vera Sans, Roman, TrueType /usr/lib64/python2.6/site-packages/reportlab/fonts/Vera.ttf − Bitstream Vera Sans, Roman, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/Vera.ttf + Dark Garden, Regular, Type 1 /usr/lib64/python2.6/site-packages/reportlab/fonts/DarkGardenMK.pfb − LettErrorRobot, Chrome, Type 1 /usr/lib/python2.6/site-packages/reportlab/fonts/LeERC___.PFB − Rina, Regular, TrueType /usr/lib/python2.6/site-packages/reportlab/fonts/rina.ttf — scim-doc.rpm (scim.src.rpm , phuang) − FreeSans, Medium, TrueType /usr/share/doc/scim-doc-1.4.9/html/FreeSans.ttf = tuxpaint.rpm (tuxpaint.src.rpm, steve) ⇒ tuxpaint.src.rpm, steve + DejaVu Sans, Book, TrueType /usr/share/tuxpaint/fonts/default_font.ttf − DejaVu Sans, Condensed, TrueType /usr/share/tuxpaint/fonts/default_font.ttf + SubsetForTuxPaint, , TrueType /usr/share/tuxpaint/fonts/locale/zh_TW.ttf −
Re: [RFA] Font audit results for Fedora 12 (final)
What does this mean? I received one for libotf. Neither libotf, nor libotf-devel seem to ship any fonts. -- 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 Mon, Nov 23, 2009 at 11:54 AM, Dominik 'Rathann' Mierzejewski wrote: On Monday, 23 November 2009 at 17:51, Jerry James wrote: [...] I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. +1. Nicholas, I know you love to write scripts that send mass emails, but don't you think this is too much? Orcan -- 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 lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package 2) There is no way to make me stop nagging you. This is true I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. This won't make the problem go away. You may not care about it, but as long as I'll continue to find users pleas for help because of crappy core font use whenever I enter fedora fonts in Google, I'll continue to care. Stop the Internet from filling with those and I'll stop the mails. (see, I can be unreasonable too) -- 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: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 13:44 -0500, Orcan Ogetbil a écrit : On Mon, Nov 23, 2009 at 11:54 AM, Dominik 'Rathann' Mierzejewski wrote: On Monday, 23 November 2009 at 17:51, Jerry James wrote: [...] I want a switch that says, Yes, I know this application uses core fonts. It isn't going to change. Shut up, please. +1. Nicholas, I know you love to write scripts that send mass emails, but don't you think this is too much? FYI I hate it. Only did it because I found no other way to move things forward. Feel free to propose and implement a better way so I can stop mine. -- 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: [RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Nicolas Mailhot wrote: Hi, With a little delay here are the font audit results for Fedora 12 and snip Special mention goes to jussilehtola for xine-ui: not only he managed to add 27 font files not packaged according to Fedora guidelines during the F-12 cycle, but 14 are copies of the same font. snip Regards, I question the taste of this remark. Was it really necessary to bring this up in such a public forum? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your gnu-free-fonts package did not pass QA
Le lundi 23 novembre 2009 à 11:06 -0600, Jon Ciesla a écrit : I understand some of the others, but, Nicholas, did we not just finish converting this from freefont to gnu-free-fonts and bringing it into compliance with the guidelines in time for F-11? Well, in fact the test 5 you listed here is a direct consequence of not splitting biolinum in a sub-package as demanded by last year's guidelines. The rest is mostly stuff that needs relaying upstream (because most long font creators do not have the resources to detect those problems themselves, for example a lot of them do not run Linux at all so if their font does not play well with fontconfig they'll only find it out if their friendly Fedora packager tells them so) It is even clearly marked in the message this is stuff that needs upstream handling. -- 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: jack2
On Thu, 2009-11-05 at 15:39 +0100, Rudolf Kastl wrote: 2009/11/5 Andy Shevchenko andy.shevche...@gmail.com: Hello. Nowadays the jack project has two branches - old jack (1) branch with version 0.116.2 and new one called jack2 version 1.9.3. I'd like to gather opinions and suggestions about applying new version for F13. Please, share your thoughts! The new jack handles device reservation, so it interacts with pulseaudio much better. (BTW, that seems to work just fine in fc12, jack2 takes and releases the soundcard properly - for fc12 I was using a wrapper perl script for the same purpose) Waiting for a while already to see it appear atleast in rawhide (now rawhide f13) sometime soon. Jack2 can also run jack clients in parallel (ie: at the same time) when the connection graph between applications allows for that. As it spawns multiple threads for that it can use multiple cores if available. Big win in most current computers (but no problem in single core processors either). Jack2 has been the default in Planet CCRMA for a long time, no major issues I know of. I have been using it myself for my realtime audio performance work. As Orcan suggests, an alternatives system for jack would be great as it would give choice to users. It would also be great if we could better coordinate rt priority settings for jack to better interact with rt patched kernels and the rtirq (or equivalent) script, see this post for my try at summarizing current state: http://ccrma-mail.stanford.edu/pipermail/planetccrma/2009-November/016161.html -- Fernando -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
take me off list
I am no longer using fedora. Please take me off mailing list. Thank You. -- 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 01:24 PM, Gregory Maxwell wrote: I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Wait, you're arguing for this *instead* of finer-grained elevations of privilege governed by policy files which can be locally overridden safely? Surely this would be preferable to reducing the security against common casual threats. I think you've characterized things backwards here. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Font audit results for Fedora 12 and 2009-11-22 fedora-devel
Le lundi 23 novembre 2009 à 12:54 -0600, Jon Ciesla a écrit : I question the taste of this remark. Was it really necessary to bring this up in such a public forum? I guess this just reflect frustration in seing xine-ui adding new copies of the same fonts months after months even though it is explicitely demanded not to in packaging guidelines and it was pointed multiple times whenever the script result were posted to this list this past year. You're right I should not have posted it this way. -- 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: [RFA] Font audit results for Fedora 12 (final)
Le lundi 23 novembre 2009 à 13:43 -0500, Neal Becker a écrit : What does this mean? I received one for libotf. Neither libotf, nor libotf-devel seem to ship any fonts. As explained in the text of the message you're received libotf attempts to access fonts through the core fonts backend which is bad -- 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: [RFA] Your [PACKAGE_NAME] did not pass QA
On Mon, 23 Nov 2009 19:50:19 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: FYI I hate it. Only did it because I found no other way to move things forward. Maybe it is time to go for the extreme and help people convert there specs to fulfill the guidelines Na the thought is to crazy... - Andreas -- Andreas Bierfert, M.Sc.| http://awbsworld.de | GPG: C58CF1CB andreas.bierf...@lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 6897 1721738| cell: +49 170 9665206| mail preferred signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Who handles lidclose at login screen?
What is responsible for suspending a laptop when the lid is closed and it is at the login screen? Running kdm and the machine does not suspend. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Core fonts are not going away, are they? Then why the hate for legacy packages using a legacy interface? -- 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: Who handles lidclose at login screen?
Orion Poplawski (or...@cora.nwra.com) said: What is responsible for suspending a laptop when the lid is closed and it is at the login screen? Running kdm and the machine does not suspend. In principle, whatever handles it in your session. gnome-power-manager runs as part of the gdm session, so the KDE equivalent should be running under kdm. There is no session - I'm at the login screen. With GDM, the login manager is running as part of a session for the 'gdm' user, using the normal gnome session tools. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: jack2
On Sat, Nov 21, 2009 at 04:23:23PM -0500, Orcan Ogetbil wrote: On Thu, Nov 5, 2009 at 9:23 AM, Andy Shevchenko wrote: Hello. Nowadays the jack project has two branches - old jack (1) branch with version 0.116.2 and new one called jack2 version 1.9.3. I'd like to gather opinions and suggestions about applying new version for F13. Please, share your thoughts! Thank you. It would be really good to have jack2. But I'm not sure if we can dump jack1 yet. Mut the upstream doesn't look like they will abandon jack1 soon. My proposal is to use alternatives for parallel installation, the way java does. Then the user can switch between jack1 and jack2 as he wants. Is it okay with everyone if I write a specfile for jack2 that uses alternatives? alternatives sounds like the wrong technology to use here. If jack is being invoked by the user for their session and different users can choose to use jack or jack2 or pulseaudio or another sound server then you should be looking at environment-modules instead: http://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules -Toshio pgpAZ0bsrRCoP.pgp Description: 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 lundi 23 novembre 2009 à 13:48 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Core fonts are not going away, are they? The infra no, the fonts (or at least part of them) yes Then why the hate for legacy packages using a legacy interface? The interface is legacy because it didn't work well, and we do not have users sophisticated enough to undestand their font problems are caused by their wandering in the legacy minefield land some packagers recklessly expose. -- 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: Who handles lidclose at login screen?
On Mon, Nov 23, 2009 at 12:44:08PM -0700, Orion Poplawski wrote: On 11/23/2009 12:43 PM, Matthew Garrett wrote: In principle, whatever handles it in your session. gnome-power-manager runs as part of the gdm session, so the KDE equivalent should be running under kdm. There is no session - I'm at the login screen. The login screen is a session, just not a user one. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/19/2009 05:28 PM, Ralf Ertzinger wrote: Not necessarily relevant, but a win for Linux (Microsoft never figured out how to make this work :). Rather MS did no longer want to take the blame for driver authors who did not anticipate that more than 4GB RAM in a 32 bit system and decided to cut rather than fight. The 32 bit server versions (which need approved drivers) have no trouble with more RAM. That is the charitable explanation---more cynical analysis points out that the functionality is there, but is disabled by a licensing check: http://www.geoffchappell.com/viewer.htm?doc=notes/windows/license/memory.htm przemek klosowski -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Who handles lidclose at login screen?
Orion Poplawski wrote: On 11/23/2009 12:43 PM, Matthew Garrett wrote: On Mon, Nov 23, 2009 at 12:26:41PM -0700, Orion Poplawski wrote: What is responsible for suspending a laptop when the lid is closed and it is at the login screen? Running kdm and the machine does not suspend. In principle, whatever handles it in your session. gnome-power-manager runs as part of the gdm session, so the KDE equivalent should be running under kdm. There is no session - I'm at the login screen. Right, kdm doesn't support powersaving on login screen (yet). -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
livecds in the future
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.) the current livecd isos need to continue (yes i know the size sux, but not everyone has highspeed internet thats why they are downloading the livecd and not the dvd) I say if you want to offer more choice, that is great, but do not shoot yourself in the foot yet, for f13 we can always try a liveusb image as well as the livecd iso if someone is willing to help release engineering make this happen so much the better for all of us if the people wanting a localized spin step up and do and maintain one for your locale. -- Ben Williams Windows-Linux Specialist 460 McBryde Hall Blacksburg VA 24061-0123 540 231-2739 -- 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 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? if the people wanting a localized spin step up and do and maintain one for your locale. Would you volunteer to maintain a Live CD Spin? Rahul -- 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
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! -- 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: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
On Mon, 2009-11-23 at 17:31 +0800, Liang Suilong wrote: After updating the package, compiz crashed and glxgears can not run. However, KMS and plymouth can still run well. Here is dmesg message that I grabbed: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! But I reboot with kernel-2.6.31.5-127. All the thing return to normal. My desktop is running on Fedora 12 x86_64. My graphic card is HD3650. can you check if this is still the case with 145, and make sure you're also running updated mesa packages from koji? -- 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: Old/compat package naming
On Fri, Nov 20, 2009 at 05:34:40PM +0100, Lubomir Rintel wrote: Hi, Alexander pointed out that I was suggesting a wrong name for Saxon 9 package [1]. In fact there's a couple of packages in repositories now that violate the naming policy [2] in the very same way. Apart from wondering what does Devrim think about renaming the existing saxon package, I'm wondering what do others (especially the maintainers of those other packages) think about renaming their packages? [1] https://bugzilla.redhat.com/show_bug.cgi?id=532664#c7 [2] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name The affected packages are these: antlr 2.7.7-5.fc11 antlr3 3.1.1-7.fc11 automake1.11-2.fc11 automake17 1.7.9-12 glib1:1.2.10-32.fc11 glib2 2.20.5-1.fc11 gtk+1:1.2.10-68.fc11 gtk22.16.6-2.fc11 gtksourceview 1:1.8.5-6.fc11 gtksourceview2 2.6.2-1.fc11 junit 3.8.2-5.4.fc11 junit4 4.5-4.1.fc11 I'm pretty sure this is an incorrect reading of the Guidelines. The Guideline itself says: For many reasons, it is sometimes advantageous to keep multiple versions of a package in Fedora to be installed simultaneously. When doing so, the package name should reflect this fact. One package should use the base name with no versions and all other addons should note their version in the name. There's no reason in there that the older package must have the versioning and the newer package is bare. I'm pretty sure that that was a specific discussion point when we worded the Guidelines like that as well. -Toshio pgpgbN4R4Tvcs.pgp Description: PGP 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 Mon, 2009-11-23 at 07:37 -0600, Otto Haliburton wrote: well, abrt just pops up and sends a report without user control, the user um, no it doesn't. it never sends a report unless you explicitly agree to do it. -- 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
On Mon, Nov 23, 2009 at 09:00:22PM +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 13:48 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Core fonts are not going away, are they? The infra no, the fonts (or at least part of them) yes Then why the hate for legacy packages using a legacy interface? The interface is legacy because it didn't work well, and we do not have users sophisticated enough to undestand their font problems are caused by their wandering in the legacy minefield land some packagers recklessly expose. As notting reminded me yesterday, we do not keep software out of Fedora solely because it is crap. So, although it would be nice to port code that uses core fonts to use fontconfig, it could be counter productive to list them along with other problems discovered in font packages that we can and should fix at the packaging level. You run the risk of getting the script/email that's making these updates ignored even when it's reporting genuine, fixable problems. -Toshio pgpV2QymXjIAw.pgp Description: 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
On Mon, 2009-11-23 at 19:48 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Maintainers do not equal developers. I am a package maintainer, yet my coding skills extend to copying and pasting things from Google results. usually incorrectly. You cannot assume that all the people to whom you are sending these mails have the capability to fix code problems, that is not a valid assumption. -- 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
On 11/23/2009 09:00 PM, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 13:48 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhotnicolas.mail...@laposte.net said: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Core fonts are not going away, are they? The infra no, the fonts (or at least part of them) yes a) Who do you think you are to decide so? b) Any pressing _technical_ need to do so? Ralf -- 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 lundi 23 novembre 2009 à 13:09 -0800, Toshio Kuratomi a écrit : As notting reminded me yesterday, we do not keep software out of Fedora solely because it is crap. So, although it would be nice to port code that uses core fonts to use fontconfig, it could be counter productive to list them along with other problems discovered in font packages that we can and should fix at the packaging level. You run the risk of getting the script/email that's making these updates ignored even when it's reporting genuine, fixable problems. I'll do the same offer I made a few years ago. Any of those who package bits that use core fonts step up to write packaging guidelines for core fonts, to do the merge reviews on the associated packages, and generally speaking to become the core fonts guy (or gal) in Fedora, can ask me to whitelist all the core font packages he wants or even to shut down this test completely. If no one is ready to do that, and is happy to continue to have me do this part because its fonts and by default the fonts sig does fonts, should be happy it costs him only a few annoying mails that state I don't like it one bit. -- 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: [RFA] Your [PACKAGE_NAME] did not pass QA
Le lundi 23 novembre 2009 à 13:13 -0800, Adam Williamson a écrit : On Mon, 2009-11-23 at 19:48 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Maintainers do not equal developers. I am a package maintainer, yet my coding skills extend to copying and pasting things from Google results. usually incorrectly. You cannot assume that all the people to whom you are sending these mails have the capability to fix code problems, that is not a valid assumption. I don't assume they have the capability to fix code problems. I assume they're ready to do their maintainer work and nag upstream till it does. Or are ready to drop the package if it costs them more than it's worth. -- 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: livecds in the future
On Mon, 2009-11-23 at 15:51 -0500, 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.) the current livecd isos need to continue (yes i know the size sux, but not everyone has highspeed internet thats why they are downloading the livecd and not the dvd) I say if you want to offer more choice, that is great, but do not shoot yourself in the foot yet, for f13 we can always try a liveusb image as well as the livecd iso if someone is willing to help release engineering make this happen so much the better for all of us if the people wanting a localized spin step up and do and maintain one for your locale. -- Ben Williams Windows-Linux Specialist 460 McBryde Hall Blacksburg VA 24061-0123 540 231-2739 Given the amount of bandwidth it takes to keep a Fedora install up to date, the jump from 700M to 1.4G is not that big, and on par with the other bandwidth requirements of Fedora. For the really network starved, there is netinst.iso where you start with 200M~ and only download the specific packages you wish to install, minimally about 200 packages. -- 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: PackageKit policy: background and plans
Gregory Maxwell gmaxw...@gmail.com writes: There are many kinds of security threat out there. For example, a few dishonest people within the fedora project could conspire to backdoor the heck out of Fedora with a reasonable chance of not getting caught. Does this fact mean that we should not bother with signing packages or other security measures? I didn't suggest anything like that, did I? Surely this would be preferable to reducing the security against common casual threats. I'm not talking about reducing security. su, sudo are already suid root (on most systems at least, especially su). Yes, this is, or at least may be, a security risk. Admin entering root's password in insecure session to install software is another security risk. That obviously doesn't mean I want non-root users to install system software at will. I just say that when it comes to entering the root password (and/or installing system software), it should be done in a secure manner, preferably not from within user X session (unless the risk = the fact of user = root equivalency is explicitly and specifically understood and accepted). -- Krzysztof Halasa -- 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 nicolas.mail...@laposte.net writes: I don't assume they have the capability to fix code problems. I assume they're ready to do their maintainer work and nag upstream till it does. Or are ready to drop the package if it costs them more than it's worth. You are assuming that upstream will agree that it's a problem. I don't have a horse in this race, since none of my packages contain any fonts. I will note though that my own response would involve procmail'ing these complaints to /dev/null. regards, tom lane -- 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 Mon, 2009-11-23 at 22:29 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 13:13 -0800, Adam Williamson a écrit : On Mon, 2009-11-23 at 19:48 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Maintainers do not equal developers. I am a package maintainer, yet my coding skills extend to copying and pasting things from Google results. usually incorrectly. You cannot assume that all the people to whom you are sending these mails have the capability to fix code problems, that is not a valid assumption. I don't assume they have the capability to fix code problems. I assume they're ready to do their maintainer work and nag upstream till it does. Or are ready to drop the package if it costs them more than it's worth. 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. -- 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
For the really network starved, there is netinst.iso where you start with 200M~ and only download the specific packages you wish to install, minimally about 200 packages. I think Ben is talking about /users/ with poor network access, the ones who come on IRC asking for help because they have trouble installing with the LiveCD. Not sure the netinst.iso would fit their needs... -- Mathieu Bridon (bochecha) -- 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, 23 Nov 2009, Bill Nottingham wrote: One scenario here is where the admin has made local modifications, which are then discarded by an upgrade of the policy. It should not be possible. Your complaint appeared to be that someone could switch from targeted to minimal (or similar) by simply installing the other package. It *does not work that way*, and it never has. If you're saying that an upgrade to a later targeted policy might break the local customizations, doesn't that mean the targeted policy maintainer made a mistake? 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. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: example content
ma, 2009-11-23 kello 20:21 +0100, Mathieu Bridon (bochecha) kirjoitti: To be truely useful for ambassadords, we'd need a localized version :) Which means we'll have to regenerate the ISO anyway with our own kickstart. I'm actually hoping that if or when the desktop spin starts targeting USB sticks, the current language support groups (whatever they'll be if the YumLangPackPlugin feature is implemented) could be added to the spin in their entirety. For example the Finnish spell checking/hyphenation/grammar checking libraries and tools are currently missing from the desktop live-CD - I understand the space constraints. -- Ville-Pekka Vainio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Security testing: need for a security policy, and a security-critical package process
Hi, everyone. I'm sending this email as a result of a discussion in the Fedora QA meeting this morning. You can find a log of the meeting here: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-23/fedora-meeting.2009-11-23-16.00.log.html the discussion takes place from 16:14:09 onwards. We discussed the recent PackageKit kerfuffle from a QA perspective, which means we talked about how we could have meaningful security testing. We came to some basic conclusions about this which require co-ordination with the security and development groups. We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground. So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change. It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try. Focussing on the relatively simple issues for now, we believe it would be reasonably simple to generate a list of all packages in the distribution that attempt privilege escalation. We believe this would be a list of packages that contain suid binaries, that invoke su, sudo or consolehelper, or that contain PolicyKit policies. This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. Will Woods has indicated he is prepared to help work on the tools necessary to generate the security-sensitive package list. The QA group as a whole is happy to contribute what input we can to any discussion of a general security policy. Mostly, we wanted to make it clear that we believe security testing would be of benefit to the distribution, but these things need to be in place before any meaningful such testing could be done. -- 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 Mon, 2009-11-23 at 22:56 +0100, Mathieu Bridon (bochecha) wrote: For the really network starved, there is netinst.iso where you start with 200M~ and only download the specific packages you wish to install, minimally about 200 packages. I think Ben is talking about /users/ with poor network access, the ones who come on IRC asking for help because they have trouble installing with the LiveCD. Not sure the netinst.iso would fit their needs... -- Mathieu Bridon (bochecha) The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? -- 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: livecds in the future
On 11/24/2009 03:39 AM, Jesse Keating wrote: The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? Perhaps net installation can be promoted as a spin and given appropriate amount of attention in http://spins.fedoraproject.org Rahul -- 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 03:37:42 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 11/24/2009 03:39 AM, Jesse Keating wrote: The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? Perhaps net installation can be promoted as a spin and given appropriate amount of attention in http://spins.fedoraproject.org That was actually a topic in the Spins SIG meeting today. Kevin Frenzi is going to ask some people (releng, design team) about this. We didn't think it should actually be a spin as such, but think that looking at promoting it as a download option similar to the install CD and DVD is worthwhile. -- 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, 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. We could possibly do this even now inside PackageKit by always downloading the filelists data, and looking for a .desktop file. It'd be even better if we could get at the data inside the .desktop file, but that's not necessary for this. That leaves aside the packagekit-command-not-found feature for unix binaries, but that's more of a technical use case. -- 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, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software. -- 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: abrt and bugzilla
-Original Message- From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list- boun...@redhat.com] On Behalf Of Adam Williamson Sent: Monday, November 23, 2009 15:06 To: Development discussions related to Fedora Subject: Re: abrt and bugzilla On Mon, 2009-11-23 at 07:37 -0600, Otto Haliburton wrote: well, abrt just pops up and sends a report without user control, the user um, no it doesn't. it never sends a report unless you explicitly agree to do it. Why would you not agree to it, it is a unsolicited report, but it is better to send it in to see if it can be fixed. I am tired of everyone who works on these things trying to find fault in those who report the flaws rather than look for the solution to sending a million reports that nobody can use to fix the problem. -- 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
Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
- 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. -- 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
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? *IF* netinst.iso works the first time (no hardware failure, no user error, no user misunderstanding, no power failure, no ISP failure, no phoneline failure, no installer bug, no kernel bug, no X11 bug, ...), and *IF* the netinst.iso is used only once (only one machine, user doesn't change his mind, ...), then the 200MB netinst.iso (plus needed packages) does involve less downloading than a 700MB LiveCD. However, not so long ago my network connection was 150KB/s DSL, and I much preferred to download an entire 700MB CD (1.5 hrs) before installation instead of using netinst.iso. By experience, waiting for the entire CD was faster on average. Something would go wrong during the first install attempt, and I would have to start over. Or, I would install again on a different partition in order to compare two setups. Or, I would give the CD to a friend. The 700MB CD was a cache of time, and paid for itself after only *two* uses. -- -- 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, Nov 23, 2009 at 2:13 PM, Peter Jones pjo...@redhat.com wrote: On 11/23/2009 01:24 PM, Gregory Maxwell wrote: I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Wait, you're arguing for this *instead* of finer-grained elevations of privilege governed by policy files which can be locally overridden safely? I'm arguing for a secure way for users to obtain authoization to perform administrative operations instead of elevating them by default, and expecting the computer operator to go and hunt down the moving target of security holes in every new version of Fedora. This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. Obviously this kind of one-off permission granting isn't reasonable in a large environment, but large environments are the place where customize the policy is a workable answer especially when the systems is secure by default and customization can be applied selectively at the greatest pain points. This is a point I think people miss when advancing the position that it's only to be less secure for convince sake as you can customize your way out of a security hole: Customization has a non-trivial cost. If it didn't we'd all run build our systems from scratch rather than using distributions. To customize you must learn, understand, and track changes from version to version. If you're only customizing to make your systems easier the customization trade-off is easy to balance: When something annoys you, you learn about and then customize only that. But when you need to customize to get the expected security behaviour you must carefully evaluate all the security properties because insecurity is largely invisible until its too late. Surely this would be preferable to reducing the security against common casual threats. I think you've characterized things backwards here. Perhaps. I know that in my environment someone running software on my account to sniff the credentials is less likely than someone sitting at my computer and twiddling knobs while I walk away (but not long enough to get away with rebooting the system). If they could sit at my account they could start up such a sniffer, but the sort of people who would screw with my systems probably wouldn't. On Mon, Nov 23, 2009 at 4:40 PM, Krzysztof Halasa k...@pm.waw.pl wrote: I'm not talking about reducing security. su, sudo are already suid root (on most systems at least, especially su). Yes, this is, or at least may be, a security risk. Admin entering root's password in insecure session to install software is another security risk. That obviously doesn't mean I want non-root users to install system software at will. Though this isn't necessary. A facility to obtain elevated authority could be provided which eliminates this risk. I just say that when it comes to entering the root password (and/or installing system software), it should be done in a secure manner, preferably not from within user X session (unless the risk = the fact of user = root equivalency is explicitly and specifically understood and accepted). Sorry— I thought you were taking the further position that because entering the password is also a risk, that it's okay to simply give subsets of privileged to users. You're correct. It's a risk which should and can be eliminated. -- 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, 2009-11-23 at 14:57 -0800, John Reiser wrote: The netinst.iso would involve less downloaded content than the 700M live image. How would it not fit their needs? *IF* netinst.iso works the first time (no hardware failure, no user error, no user misunderstanding, no power failure, no ISP failure, no phoneline failure, no installer bug, no kernel bug, no X11 bug, ...), and *IF* the netinst.iso is used only once (only one machine, user doesn't change his mind, ...), then the 200MB netinst.iso (plus needed packages) does involve less downloading than a 700MB LiveCD. However, not so long ago my network connection was 150KB/s DSL, and I much preferred to download an entire 700MB CD (1.5 hrs) before installation instead of using netinst.iso. By experience, waiting for the entire CD was faster on average. Something would go wrong during the first install attempt, and I would have to start over. Or, I would install again on a different partition in order to compare two setups. Or, I would give the CD to a friend. The 700MB CD was a cache of time, and paid for itself after only *two* uses. -- And to wait for a 1.4G live image, you'd have to wait another 1.5 hours. When you're already waiting 1.5 hours, waiting 3 doesn't seem outrageous. -- 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: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
On Mon, 2009-11-23 at 13:03 -0800, Adam Williamson wrote: On Mon, 2009-11-23 at 17:31 +0800, Liang Suilong wrote: After updating the package, compiz crashed and glxgears can not run. However, KMS and plymouth can still run well. Here is dmesg message that I grabbed: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! But I reboot with kernel-2.6.31.5-127. All the thing return to normal. My desktop is running on Fedora 12 x86_64. My graphic card is HD3650. can you check if this is still the case with 145, and make sure you're also running updated mesa packages from koji? -145 should fix this, a patch went in upstream that we didn't want in F-12, I had to remember to revert it. I should push out a new mesa before we can ship that fix. Dave. -- 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, 23 Nov 2009, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. And this is why spot's list is useful. A family computer and a university computer lab have a lot in common but where they diverge we should start with err toward MORE restrictive and allow configuration by the local admin/owner to LESS restrictive. Otherwise we open ourselves up to a less-secure-by-default posture in an average install. We've been in that position in the past and it is not a favorable place to be. -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 Mon, 23 Nov 2009, 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. We could possibly do this even
now inside PackageKit by always downloading the filelists data, and
looking for a .desktop file. It'd be even better if we could get at
the data inside the .desktop file, but that's not necessary for this.
That leaves aside the packagekit-command-not-found feature for unix
binaries, but that's more of a technical use case.
Or - you could more easily generate the 'which pkgs have .desktop files'
and propagate that into a package Provides.
since yum can install by provides - that takes care of that need.
example:
Provides: App('foo')
-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 Mon, 2009-11-23 at 17:55 -0500, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. Sure, I don't disagree, but I think we can take spots list and use it for the 'guest account'. Then you start picking things off the list as you move up the stack to 'university computer lab user (is that really much different from guest?)', to 'non-admin user', to 'admin user'. -- 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: PackageKit policy: background and plans
On Mon, 2009-11-23 at 18:06 -0500, Gregory Maxwell wrote: This isn't mutually exclusive with finer-grained elevations but would allow finer grained elevations to stay out of the default install: When additional privileged is needed, the system prompts you to authenticate via a secure prompt. At that point if you have the required credentials you could authorize the activity and, optionally, permit that account to perform the same operation in the future. This is precisely the dialog that has been removed from F12 and is not planned to be returned. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) 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 Mon, Nov 23, 2009 at 05:55:15PM -0500, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. This is debatable. I certainly don't want a regular user at my family computer to be able to do anything they couldn't also do at a university computer. I don't want to worry about my ISP cutting off my internet access because one of my family members have enough permissions to get a trojan or virus installed on the system, for instance. The option to give other family members that much leeway as part of making things convenient for them to do other things can be a nice thing, but turning it on by default, even when it's possibly the most convenient approach, should be approached cautiously. Linux has several foundational features like being multiuser, designed with a security model that mitigates risk, and integrated into the network. When we touch these areas, we need to make sure that we're not compromising the foundations at the same time. -Toshio pgpGXp6oJV7Fc.pgp Description: PGP signature -- 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, 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? Thanks! -- 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 11/23/2009 10:55 PM, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. I do believe we need to start securing from the (@)base level then gradually build service/users roles on top of that which will fit the intended spins service/audience. This means we would change the current default partition layout to a more secure seperated partition one. Disable dhcp. Disable ipv6. no running service etc.. Give us a solid secure base to work on then each spin or groups of spins that have the same target audience would build on top of that base and adjust and adapt according to it's intended audience and document why and how their security modules is different from the base one. Good example is that all the *DE could reach a consciousness on how the desktop home, desktop laptop/notebook and workstation security models should be and how they differentiate from the base security model and each other based on their function and roles. Same goes for server spins. When we have reach consciousness about what the base secure model should be, QA can create test cases ( or automate ) that fit that then gradually extend test cases to meet each defined security model desktop vs workstation vs server etc.. JBG -- 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
Once upon a time, Adam Williamson awill...@redhat.com said: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. IMHO that's a backwards way of approaching security. You will never be able to define everything somebody should _not_ be able to do. You should always take the approach of defining what somebody _should_ be able to do. Focussing on the relatively simple issues for now, we believe it would be reasonably simple to generate a list of all packages in the distribution that attempt privilege escalation. We believe this would be a list of packages that contain suid binaries, that invoke su, sudo or consolehelper, or that contain PolicyKit policies. During the recent discussion, somebody mentioned there are also ways to trigger events through dbus (I haven't looked down that path myself so I'm not sure of the details). -- 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: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote: Otherwise we open ourselves up to a less-secure-by-default posture in an average install. We've been in that position in the past and it is not a favorable place to be. We should just avoid to sink tons of QA resources in verifying that a theoretical 'unprivileged user' can do nothing, when that role is not something anybody would want to use anyway (because it can do nothing) and is not the role that most users will actually end up with in a typical desktop install. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
