Re: PackageKit policy: background and plans
On Thu, 19 Nov 2009, Conrad Meyer wrote: I think it's fair to say that having this happen as root would generally be worse than it happening as an unprivileged user. For the latter, the attacker would need to also then succeed with a local privilege escalation attack to the same effect. On the contrary. On the typical single user system, it's just as bad if an attacker can steal / delete / modify the user's files as it is if the attacker can modify / delete system files. Privilege escalation isn't needed to delete everything the single user cares about. Note that I said generally. In the specific case where the attacker only wants access to the user's files, can exploit an existing vulnerability to do so, and can also get the data back out without further privilege (if they want the data), then yes, it's game over at that point. There are many possible scenarios where an attacker would want more privileged access to the system, e.g. install rootkits/firmware kits, modify firewall settings, run network services, attack other systems, evade detection etc. IOW, the current landscape of windows malware, data-stealing worms, botnets and so on. Getting root access is much more valuable in the general case. There are also the separate issues, as I mentioned subsequently, of increasing the attack surface, breaking the MAC model, and executing at full system privilege (also, without further authorization). I think we're throwing away a lot of well-established security benefit in moving away from the simple model of using a root/wheel account (or sudo) for admin and a separate user account for everything else. - 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: Head-up - new firefox in rawhide
On 11/20/2009 09:21 AM, Peter Robinson wrote: 2009/11/18 Martin Stranskystran...@redhat.com: Hi, a new firefox (3.6 beta 2) just hit rawhide (a.k.a f13). There are some changes which affect everyone who builds with xulrunner-devel-unstable package. Mozilla decided to merge all include directories to one (mozbz#398573) and stop shipping stable/unstable packages. So all headers/libraries are merged to one big xulrunner-devel package (with respective pkgconfig files) and xulrunner-devel-unstable has been removed. Is this the same with the -python and -python-devel pacakges? I'm not sure what's going on with python interface but it looks removed from 3.6. I'm still investigating it... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On 11/20/2009 02:21 AM, Rudolf Kastl wrote: there are also inconsistencies between gui clickery and shell usage... simple example: click shutdown in gnome just does it in f12 Yeah, you can do that in F11 as well :( I agree, this needs protecting with a root password too. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
2009/11/20 Orcan Ogetbil oget.fed...@gmail.com: On Thu, Nov 19, 2009 at 10:21 PM, Stu Tomlinson wrote: On Thu, Nov 19, 2009 at 22:01, Orcan Ogetbil wrote: On Wed, Nov 18, 2009 at 12:57 AM, Toshio Kuratomi wrote: There's many things that need to be changed in rpm but IMHO this isn't one of them. RPM produces predictable versioning. Hacking it up with special cases will lead nowhere but pain. Suppose we hack the RPM, such that right before RPM does the EVR check when updating a package, it will take the Release string and does a 's...@.fc\([0-9]\)@.f\1@' for both the old and the new package? Can you give me an example where this might lead to a problem? Which part of Hacking it up with special cases will lead nowhere but pain. confused you? The part where an obvious hack would not cause a confusion confused me. It's a hack. It's Fedora-specific, so doesn't belong in RPM (or anything else). And RPM will no longer produce predictable versioning. My proposed hack's outcome is quite predictable. But version comparison behaviour will cease to be consistent across distributions. -- Mat Booth -- 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/20/2009 09:02 AM, Nicu Buculei wrote: On 11/19/2009 08:14 PM, Jesse Keating wrote: On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote: You must not confuse moblin with netbooks, nettops or with i386/32bit machines in general. The moblin desktop is addressing a completely different audience. Oh? That's not what I got from http://fedoraproject.org/wiki/Features/FedoraMoblin Moblin is not about hardware, you can run it on a powerful 64 bit desktop, while my netbook is perfectly able to run a normal GNOME desktop. Moblin is about users, made for those with a small set of basic needs, which in many cases are people using netbooks or less powerful hardware, but there are a lot of other user cases for such hardware, beyond Moblin. Exactly. As I tried to express several times before in this thread: Moblin is addressing and entirely different use-case. Whether this use-case of interest in individual situations is a different question - To some it might be interesting, to me, it is not. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
libmpcdec vs. Musepack SV8
http://www.musepack.net/index.php?pg=src http://files.musepack.net/source/musepack_src_r435.tar.gz It seems we only have the old libmpcdec 1.2.6 in Fedora, which can decode SV7 but not SV8. Is the new set of libs and tools (from March 2009) hidden somewhere? Or are there new legal problems? -- 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?
You must not confuse moblin with netbooks, nettops or with i386/32bit machines in general. The moblin desktop is addressing a completely different audience. Oh? That's not what I got from http://fedoraproject.org/wiki/Features/FedoraMoblin It's what I get from this web-page and what I got from testing the original Moblin desktop. No the Moblin 2.0 and 2.1 releases target NetBooks and Nettop devices solely. A later release of Moblin 2.1 will also be targeted for MID and Phone devices but will be using a slight different interface to the current Moblin with the same underlying tech. IMO, they are targetting MID devices, competing with Android, Smart phones and similar. Not at the moment they're not/ That's a completely different audience as I am talking about: People using netbooks, nettops and old i386s as inexpensive, secondary machine for everyday, low end desktop usage, such as browsing the web, word processing, presentations, photo browsing etc. They are targeting Netbooks for the online type of device. They are targeted at web browsing, Social Networking, Media (Audio/Video/Photos) and Instant messaging running on small inexpensive netbook devices. They will do presentations and word processing quite happily as well as it based on gtk and clutter so all the usual gnome apps will run but that's not the main target. Peter -- 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/20/2009 11:20 AM, Ralf Corsepius wrote: Users of the Fedora Moblin Spin would have a much better user experience on their NetBook, NetTop and other small devices That's what the marketing department wants it to be. Meh. You said the target of the spin is not netbooks but it clearly is. You violently don't want to understand. Actually I disagree. The moblin stuff is a different use-case, primarily addressing the very low end of HW, which is competing with SmartPhones, the XOs and the like. Actually its not targeting very low end hardware at all. It uses clutter and the whole interface is rendered in OpenGL. You need a card that can do that and the XO and other very low end hardware won't cut it. I am talking about is people using netbook/nettops as secondary desktops for normal usage. That is one use case of a Netbook/Nettop device. The other use case is people that want to use it as a social and communications device to keep in touch with friends, listen to music, check email and update facebook. Both are very valid use cases and both are very popular just because the Moblin user interface doesn't suit you it doesn't mean its not a valid use case and one that lots of people want to use. The fact there's been nearly 10K downloads of the beta live images prove that. Reality speaks a different language: * People are using their everyday desktop even on low end machines and do not want to fiddle around with custom netbooks desktops. * People consider their low end machine's performance sufficient for such use-cases. I am not sure why I should accept your version of reality over any other. Any references to back up your claims? It's what I am using netbooks for, everybody around me uses netbooks for, what newpapers tell and what I can buy in stores. The mass of Atom based machines you can buy around here either have Win XP preinstalled or meanwhile occasionally come with Win7. Maybe where you live but Linux still makes up a large portion of the netbook market. With a decent interface like Moblin that I believe will improve. It doesn't fit everyones use case but the fact is that a large percentage of the public only use their computer for Web browsing, Music, photos, Instant Messaging, email and Social Networking and Moblin fits that perfectly. Linux based netbooks/nettops can hardly be found in stores anywhere. The essentially the same rationale/reason why netbooks/nettops with WinXP have been a huge success and why netbooks with custom desktops were a failure. Actually, netbooks represent one of the highest market shares for Linux on the client side and nany of them are running custom desktops http://www.desktoplinux.com/news/NS5114054156.html Well you'll likely find a static proving anything. All I can say, my netbook easily outperforms many older desktops and is quite suiteable for everyday office- and home use-cases, using an ordinary Fedora setup. I don't have any use for Moblin and consider Moblin to be a waste of resources. To you it might be, I'm well aware of your opinions but yours is not the only opinion and if you look at the netbook manufacturers you'll see that they're all announcing Moblin devices. Hell Dell is even shipping it in Beta to get it out there. So just because it doesn't fit your taste it doesn't mean its wrong. Ultimately its another option like GNOME or KDE or LXDE or enlightenment. Peter -- 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/20/2009 11:58 AM, Peter Robinson wrote: IMO, they are targetting MID devices, competing with Android, Smart phones and similar. Not at the moment they're not/ Then please explain what they are targetting. So far, all of Moblin I have seen was them trying to turn a multi-user environment/desktop into a single-user, Smart-phone/Kiosk-like desktop. That's a completely different audience as I am talking about: People using netbooks, nettops and old i386s as inexpensive, secondary machine for everyday, low end desktop usage, such as browsing the web, word processing, presentations, photo browsing etc. They are targeting Netbooks for the online type of device. What is this? UTMS, WLAN, LAN, Bluetooth etc.? How is this kind of device different from an ordinary desktop with UTMS, WLAN, LAN, Bluetooth ...? They are targeted at web browsing, Social Networking, Media (Audio/Video/Photos) and Instant messaging running on small inexpensive netbook devices. They will do presentations and word processing quite happily as well as it based on gtk and clutter so all the usual gnome apps will run but that's not the main target. In my understanding this is exactly the same target audience as all other desktop installations address - So, why does it exist? Getting rid of the multi-user overhead, turning Linux into Windows? Catering the the Telcos to address the TelCos' audiences? This would be the Smartphone/Android etc. audience. Ralf -- 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?
Kevin Kofler kevin.kof...@chello.at writes: This is, sadly, intentional. I and others have been complaining about this for months, we got ignored, all in the names of making things work for people who are not smart enough to figure out whether their computer is 64- bit or not. The argument that almost all new non-netbook machines are 64-bit anyway also got ignored. If only the 32-bit version was smart enough to install a 64-bit kernel when appropriate, this would not be such a disaster. Running a 32-bit kernel with 4GB of memory is asking for trouble, and machines with 4GB are probably as common as netbooks. 32-bit or 64-bit userland doesn't make such a difference. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
abrt and bugzilla
Firstly, I'd like to say I think abrt is fantastic. Call what follows a nit-pick. It's just a pretty in-your-face nit. After installing F12, after a short while I got presented with a couple of SELinux errors. This is nothing unusual in a new Fedora release, but this time it asked me for my bugzilla login details and offered to submit the bug automatically for me. Fantastic! The lazy person in me who wants to do the right thing truly appreciates this. Turns out I wasn't the first person report them, so it added me to the CC list. There are, however, still 2 significant problems with this. Firstly it needed a BZ login. I happen to have one, and I use it often enough that I don't need a password reset every time. However, I'll bet I'm in the minority of Fedora users[1]. To get useful bug reports from the unwashed masses we need anonymous submission, or at least submission which doesn't require any kind of account creation or authentication. Secondly, I'm now being subjected to bugzilla spam every time anybody else does the right thing. I have received 24 bugzilla spams in the last 12 hours telling me that other people have been added to the CC list. This information is interesting to people who want to know how to prioritise bugs, but it's not interesting to me, the submitter. I can remove myself from the CC list, but the lazy person in me whispers it might just be easier not to submit bugs. If you've used Windows, you'll be familiar with the Windows send bug report dialog. I've once seen it additionally give me useful information. After submission it told me a fix was available and sent me to a web page which told me where to get an updated third-party driver. That's what I really want to know: can I fix it? So, turning that into some feature requests: 1. Can Fedora enable anonymous/unauthenticated bug submission. 2. Can abrt not add duplicate reports to the CC list. 3. Can abrt/Fedora please ensure that original abrt reporters don't get email either. 4. Can abrt/Fedora track abrt submitted BZs and report only when there's a fix available. 5. Can abrt give me a list of submitted BZs so I can browse them if I want to? I suspect much of this would require infrastructure changes, so it would extend beyond abrt. However, I think this is the last mile required to get bug reports from absolutely everybody. Thanks again, Matt [1] As is everybody on this list! I know you all have BZ accounts, and know the passwords. -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- 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 Fri, Nov 20, 2009 at 11:14 AM, Ralf Corsepius rc040...@freenet.de wrote: On 11/20/2009 11:58 AM, Peter Robinson wrote: IMO, they are targetting MID devices, competing with Android, Smart phones and similar. Not at the moment they're not/ Then please explain what they are targetting. Netbooks. So far, all of Moblin I have seen was them trying to turn a multi-user environment/desktop into a single-user, Smart-phone/Kiosk-like desktop. That's a completely different audience as I am talking about: People using netbooks, nettops and old i386s as inexpensive, secondary machine for everyday, low end desktop usage, such as browsing the web, word processing, presentations, photo browsing etc. They are targeting Netbooks for the online type of device. What is this? UTMS, WLAN, LAN, Bluetooth etc.? How is this kind of device different from an ordinary desktop with UTMS, WLAN, LAN, Bluetooth ...? Its not but its a move away from the traditional start menu style of interface to one with Social networking and other communications at its core. Like Sugar is a move away from a standard desktop for education. It doesn't suit everyone one but it doesn't mean its wrong. And for the target market its targeting it works very well. They are targeted at web browsing, Social Networking, Media (Audio/Video/Photos) and Instant messaging running on small inexpensive netbook devices. They will do presentations and word processing quite happily as well as it based on gtk and clutter so all the usual gnome apps will run but that's not the main target. In my understanding this is exactly the same target audience as all other desktop installations address - So, why does it exist? Why do both gnome and kde and other desktop environments exist. They all achieve the same thing so why have more that one? The target is more the online market than a standard desktop market. Ones that use web based apps and the likes of twitter and itunes more than they do a word processor or spreadsheet. Getting rid of the multi-user overhead, turning Linux into Windows? You can run it multi user just fine. I do so myself. Catering the the Telcos to address the TelCos' audiences? This would be the Smartphone/Android etc. audience. No. A netbook isn't a smart phone you can't put it in your pocket. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FC11 packages 'newer' than FC12
I've been trying to fix libotf, but make tag is doing something really strange. Here is my previous post: Something seems strange here with libotf. I want to push 0.9.9-3 for F12. I went into my F-12 subdir and did the usual make tag build ERROR: Tag libotf-0_9_9-3_fc12 has been already created. OK, I bumped the tag. cvs tag -c libotf-0_9_9-3_fc12_1 ERROR: Tag libotf-0_9_9-3_fc12_1 has been already created. That's strange. OK, bump tag again: cvs tag -c libotf-0_9_9-3_fc12_2 ERROR: Tag libotf-0_9_9-3_fc12_2 has been already created. Now I'm really confused. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Friday 20 November 2009 12:29:34 Neal Becker wrote: I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. From what I know it works correctly in KDE, even we have several KDE related bugreports reported by Abrt. There are even plans for full KDE support and replacing Dr. Konqui. Jaroslav -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Fri, Nov 20, 2009 at 12:23:33PM +0100, Benny Amorsen wrote: Kevin Kofler kevin.kof...@chello.at writes: This is, sadly, intentional. I and others have been complaining about this for months, we got ignored, all in the names of making things work for people who are not smart enough to figure out whether their computer is 64- bit or not. The argument that almost all new non-netbook machines are 64-bit anyway also got ignored. If only the 32-bit version was smart enough to install a 64-bit kernel when appropriate, this would not be such a disaster. Running a 32-bit kernel with 4GB of memory is asking for trouble, and machines with 4GB are probably as common as netbooks. Like in this failed F11 feature? https://fedoraproject.org/w/index.php?title=Features/ArchitectureSupportdiff=86872oldid=82905 -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Friday 20 November 2009 13:11:49 Jiri Moskovcak wrote: On 11/20/2009 01:08 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 11/20/2009 12:54 PM, Neal Becker wrote: Jaroslav Reznik wrote: On Friday 20 November 2009 12:29:34 Neal Becker wrote: I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. From what I know it works correctly in KDE, even we have several KDE related bugreports reported by Abrt. There are even plans for full KDE support and replacing Dr. Konqui. Jaroslav Doesn't work here at all. When I just tried to send a kernel bug report, it told me some settings weren't correct, and when I clicked on bugzilla and filled in username and password, I got: abrt-gui Our job for UUID 725650339 is done. Traceback (most recent call last): File /usr/share/abrt/CCReporterDialog.py, line 113, in on_config_plugin_clicked plugin.save_settings() File /usr/share/abrt/ABRTPlugin.py, line 100, in save_settings self.Settings.save(str(self.Name)) File /usr/share/abrt/ABRTPlugin.py, line 51, in save self.conf.save(name, self) File /usr/share/abrt/ConfBackend.py, line 68, in save True) gnomekeyring.DeniedError ABRt dies trying to save/load you stored password if you gnome-keyring authentication fails, this should be fixed in next update (abrt will survive the g-k denial, but forget the password when you close it) which I'm about to do right now. Jirka On kde, we shouldn't be using gnomekeyring, I would think. Yes, I'm planning to write another config backend for kwalet, but didn't find any usable API reference so far :( Have you tried that Python keyring library I sent you? It looks like there's support for both G-K and KWallet with same API. But in any case, feel free to ask anyone of us (KDE team) for help... J. p.s: but according to the error you're seeing you have g-k running, just the authentication failed. -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal skvi...@fedoraproject.org writes: If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On 11/20/2009 01:15 PM, Jaroslav Reznik wrote: On Friday 20 November 2009 13:11:49 Jiri Moskovcak wrote: On 11/20/2009 01:08 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 11/20/2009 12:54 PM, Neal Becker wrote: Jaroslav Reznik wrote: On Friday 20 November 2009 12:29:34 Neal Becker wrote: I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. From what I know it works correctly in KDE, even we have several KDE related bugreports reported by Abrt. There are even plans for full KDE support and replacing Dr. Konqui. Jaroslav Doesn't work here at all. When I just tried to send a kernel bug report, it told me some settings weren't correct, and when I clicked on bugzilla and filled in username and password, I got: abrt-gui Our job for UUID 725650339 is done. Traceback (most recent call last): File /usr/share/abrt/CCReporterDialog.py, line 113, in on_config_plugin_clicked plugin.save_settings() File /usr/share/abrt/ABRTPlugin.py, line 100, in save_settings self.Settings.save(str(self.Name)) File /usr/share/abrt/ABRTPlugin.py, line 51, in save self.conf.save(name, self) File /usr/share/abrt/ConfBackend.py, line 68, in save True) gnomekeyring.DeniedError ABRt dies trying to save/load you stored password if you gnome-keyring authentication fails, this should be fixed in next update (abrt will survive the g-k denial, but forget the password when you close it) which I'm about to do right now. Jirka On kde, we shouldn't be using gnomekeyring, I would think. Yes, I'm planning to write another config backend for kwalet, but didn't find any usable API reference so far :( Have you tried that Python keyring library I sent you? It looks like there's support for both G-K and KWallet with same API. But in any case, feel free to ask anyone of us (KDE team) for help... I must have lost it somewhere in my mailbox :-/ Thanks for reminding me, seems like kwalet and g-k use the same dbus interface, will add support for this soon. Thanks, J J. p.s: but according to the error you're seeing you have g-k running, just the authentication failed. attachment: jmoskovc.vcf-- 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 King InuYasha wrote: Except, that could be false advertising. In most cases, where CPU computation is not used heavily, 64-bit is actually SLOWER than the 32-bit counterpart. Optimizations are narrowing the gap, but it still remains true. On ppc versus PPC64, sparc vs. sparc64, and possibly other architectures that may be true, however on x86 vs. x86_64 arch as a whole it is not generally the case, in particular because the x86_64 arch has double the number of available registers for gcc to play with. Whenever I have done any performance testing comparisons between x86 and x86_64, all I/O bound processes tend to come out with very similar results, however the more CPU bound a task is, the more likely the app is to have up to a 30% performance gain depending on various factors. gcc for example tends to build much faster on x86_64 than on x86. The only cases where I've personally seen an x86_64 built application perform poorly compared to the i386 built version of the app on the same system, when investigated - turned out to be that the source code of the application had x86 specific assembly language which got used on the x86 build, and much slower C fallbacks when used on x86_64 (and other arches). There probably aren't a lot of packages in the distribution that contain x86-only hand crafted assembler which end up using C fallbacks on x86_64, but it is one possibility. What applications are you aware of which run slower on x86_64 than on x86 on the same system? It would be interesting to investigate whichever ones you've discovered to find out why they are slower as it shouldn't generally occur, although I'd suspect it would be a case of fast path x86 specific optimizations with a slow path for non-x86 as mentioned above. Just curious what you may have observed differs. - -- Mike A. Harris Website: http://mharris.ca Google Wave: mike.andrew.harris - at - googlewave.com https://identi.ca/mharris | https://twitter.com/mikeaharris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLBopw4RNf2rTIeUARAsDyAJ9vLCngIPvtALZXvzaeeN4y30cRtgCcDIXx 9zgCcX+8xCtl4jiCLmVJSOI= =ss6n -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
disallow broken push to updates?
Wouldn't it be a good idea to disallow a push to updates that has broken deps? -- 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?
Mike A. Harris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 King InuYasha wrote: Except, that could be false advertising. In most cases, where CPU computation is not used heavily, 64-bit is actually SLOWER than the 32-bit counterpart. Optimizations are narrowing the gap, but it still remains true. On ppc versus PPC64, sparc vs. sparc64, and possibly other architectures that may be true, however on x86 vs. x86_64 arch as a whole it is not generally the case, in particular because the x86_64 arch has double the number of available registers for gcc to play with. Also, x86_64 has a much better ABI: args get passed in registers, not on the stack. What applications are you aware of which run slower on x86_64 than on x86 on the same system? There used to be Java slowdowns, but this was fixed with the compressed OOPs option. Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: disallow broken push to updates?
On Fri, Nov 20, 2009 at 07:26:27AM -0500, Neal Becker wrote: Wouldn't it be a good idea to disallow a push to updates that has broken deps? Yes, it would. It's been discussed numerous times on this list an others. Summary: Needs hard thinking and people actually working on it. Not trivial. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: disallow broken push to updates?
2009/11/20 Neal Becker ndbeck...@gmail.com: Wouldn't it be a good idea to disallow a push to updates that has broken deps? If the special case is kde-plasma-smooth-tasks. It is not in updates yet. The needed deps are in updates-testing. -- LG Thomas Dubium sapientiae initium -- 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 Fri, Nov 20, 2009 at 12:26 AM, Conrad Meyer ceme...@u.washington.edu wrote: On the contrary. On the typical single user system, it's just as bad if an attacker can steal / delete / modify the user's files as it is if the attacker can modify / delete system files. Privilege escalation isn't needed to delete everything the single user cares about. Not quite. For example, it's much easier to fix a system which has only had a user account compromised, since if you actually trust that its only the user account you can skip the full reinstall. This is also assuming a strictly single user system. With features like fast user switching it wouldn't be inadvisable or especially inconvenient to operate business and pleasure activities from separate accounts. I don't know anyone that does this today, but as it becomes easier to do so and if the systems don't continue to go down the route of giving the local accounts root access then it may be a practice which becomes common. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Thu, Nov 19, 2009 at 11:52:42PM -0500, Orcan Ogetbil wrote: It's a hack. It's Fedora-specific, so doesn't belong in RPM (or anything else). And RPM will no longer produce predictable versioning. My proposed hack's outcome is quite predictable. I just faced this same attitude in upstrea, python community and lost. But they aren't all Unix users so I can forgive them. When people are using predictable they aren't just refering to being able to look up the rules surrounding sorting of versions in Fedora 13 and above's version of rpm; we are really saying that sorting should obey the rules of rpm in all distributions. And to some extent, to sorting done by dpkg and other unix package managers and Unix tools like /usr/bin/sort or even ls with LANG=C -Toshio pgpgG8CZ5z0Mf.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: where did window properties go?
Jesse Keating wrote: You're making the assumption that the change was made to save space. It wasn't. I can't find the original thread right now, but it's part of a cleanup on configuration tools. Upstream felt it no longer necessary to expose this Wow. Did they get any estimates on the % of users that set this option before coming to that decision? IMHO the only advantage an overlapping window manager has over say a tiling window manager is in conjunction with sloppy focus. cheers, Pádraig. -- 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 Fri, Nov 20, 2009 at 04:09:15PM +1100, James Morris wrote: Many users limit their use of the root account to essential system maintenance, and run general purpose applications as a regular unprivileged user. I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. -- 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: abrt and bugzilla
On 11/20/2009 03:28 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 11/20/2009 01:15 PM, Jaroslav Reznik wrote: On Friday 20 November 2009 13:11:49 Jiri Moskovcak wrote: On 11/20/2009 01:08 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 11/20/2009 12:54 PM, Neal Becker wrote: Jaroslav Reznik wrote: On Friday 20 November 2009 12:29:34 Neal Becker wrote: I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. From what I know it works correctly in KDE, even we have several KDE related bugreports reported by Abrt. There are even plans for full KDE support and replacing Dr. Konqui. Jaroslav Doesn't work here at all. When I just tried to send a kernel bug report, it told me some settings weren't correct, and when I clicked on bugzilla and filled in username and password, I got: abrt-gui Our job for UUID 725650339 is done. Traceback (most recent call last): File /usr/share/abrt/CCReporterDialog.py, line 113, in on_config_plugin_clicked plugin.save_settings() File /usr/share/abrt/ABRTPlugin.py, line 100, in save_settings self.Settings.save(str(self.Name)) File /usr/share/abrt/ABRTPlugin.py, line 51, in save self.conf.save(name, self) File /usr/share/abrt/ConfBackend.py, line 68, in save True) gnomekeyring.DeniedError ABRt dies trying to save/load you stored password if you gnome-keyring authentication fails, this should be fixed in next update (abrt will survive the g-k denial, but forget the password when you close it) which I'm about to do right now. Jirka On kde, we shouldn't be using gnomekeyring, I would think. Yes, I'm planning to write another config backend for kwalet, but didn't find any usable API reference so far :( Have you tried that Python keyring library I sent you? It looks like there's support for both G-K and KWallet with same API. But in any case, feel free to ask anyone of us (KDE team) for help... I must have lost it somewhere in my mailbox :-/ Thanks for reminding me, seems like kwalet and g-k use the same dbus interface, will add support for this soon. Thanks, J J. p.s: but according to the error you're seeing you have g-k running, just the authentication failed. What's strange too is I tried manually editing /etc/abrt/plugins/Bugzilla.conf, and filled in Login and Password, and it still says it's not configured write and prompts me, then hangs forever with the previous error if I try to fill it in with the gui. If you change the config file, you need to restart abrt daemon: $ service abrtd restart J. attachment: jmoskovc.vcf-- 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 Fri, Nov 20, 2009 at 9:34 AM, Matthew Garrett m...@redhat.com wrote: On Fri, Nov 20, 2009 at 04:09:15PM +1100, James Morris wrote: Many users limit their use of the root account to essential system maintenance, and run general purpose applications as a regular unprivileged user. I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. I do! And I tell everyone else too, so they learn/understand the difference between 'god' and a 'mere mortal user' (ie. root and anyone else). If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. ... snip ... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about tagging
On Thu, Nov 19, 2009 at 08:50:06PM -0800, Jesse Keating wrote: On Fri, 2009-11-20 at 00:50 +0100, Kevin Kofler wrote: And why can't all this be done with s/git/SVN/? All we really need apart from what CVS already provides is atomic commit IDs, to make the maintainers would not tag themselves part easily implementable. I don't see why SVN revision IDs wouldn't be as good as git hashsums for that. In fact, in principle, it could even be done with CVS, but instead of tagging a single revision ID, the build system would have to tag the revision ID it checked out for each file. Having atomic commits just allows dragging around just one revision ID instead of a set of IDs. With sufficient hackery it could be done with either svn or cvs, Kevin'spoint is that svn would require less new hackery than git. I believe he's right about that as svn provides whoe-tree changesets without adding all of the vastly different semantics that git does. OTOH, nobody who hasshown up to do work has shown interest in a centrally managed scm, only dvcs and just as you point out, really it's who's interested in doing the work that matters. Although I will say that the reason that we didn't switch to a different scm years ago was not that no one wanted to do the work but that no one wanted to step on enough people's toes while doing the work. -Toshio pgprwUXCiHr0Q.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: allow adding repos in preupdate?
On Fri, Nov 20, 2009 at 06:46:59AM -0500, Neal Becker wrote: I'd like to add my favorite repo. Possible? I thought preupgrade already took whatever repos you have enabled in yum. Do you want it to have UI for selecting repositories? Or something else? -Toshio pgpxlKePkYGCm.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No fuse module in Koji builds?
On Wednesday 18 November 2009 11:25:15 am Richard W.M. Jones wrote: A package I'm building has an (optional) test which does a local non-root fuse mount in order to run some tests. In Koji this gives the error: fuse: device not found, try 'modprobe fuse' first So I have a couple of questions about this: I think in RHEL 5.4 the fuse module was added to the kernel -- are the Koji builders now based on the RHEL 5.4 kernel? If they are or will be, will local non-root fuse mounts be permitted during builds? As far as I'm aware there are no security issues with doing this, although possibly there may be unexpected interactions with Koji/mock if a build doesn't properly umount fuse mountpoints. The builders are running RHEL 5.4, doing any kind of mount is not permitted during the build. network access is not allowed also. You will likely have weird incompatability issues if we do allow it. since the build hosts run EL-5 and the chroot could be something wildly different. its not a tested or supported thing. for one mock chroot only has a minimal /dev file system its not likely going to be something we will work on or allow, the same as calling rpm in the chroot is not allowed. Dennis signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, Nov 20, 2009 at 09:38:43AM -0500, Fulko Hew wrote: I do! And I tell everyone else too, so they learn/understand the difference between 'god' and a 'mere mortal user' (ie. root and anyone else). Actually, thinking about it, even this isn't sufficient. An attacker could change the ctrl+alt+F* bindings and use them to pop up a full-screen window that looks like the console. So you'd also need to set up securetty to ensure that root can only log in on real consoles. I really don't see this being a security issue in the common single-user case. -- 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: Local users get to play root?
Benny Amorsen (benny+use...@amorsen.dk) said: If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON. It's not a blanket prohibition. (See also opensshd, rsyslog, etc.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
Rudolf Kastl (che...@gmail.com) said: there are also inconsistencies between gui clickery and shell usage... simple example: click shutdown in gnome just does it in f12 issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty broken to me. It's a usermode bug in that there's not a wrapper for shutdown (as opposed to halt/poweroff/reboot.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
Am Freitag, den 20.11.2009, 11:24 + schrieb Matthew Booth: To get useful bug reports from the unwashed masses we need anonymous submission, or at least submission which doesn't require any kind of account creation or authentication. I disagree. As the maintainer, I need to be able to ask people for details, clarification, feedback etc. This is impossible for anonymous submissions and I doubt it will be possible with submissions that don't require an kind of authentication. So, turning that into some feature requests: 1. Can Fedora enable anonymous/unauthenticated bug submission. Please don't see above. 2. Can abrt not add duplicate reports to the CC list. Per user setting in bugzilla. As a maintainer I'd like to be informed about new people CC'ing to a bug because it gives me feedback how many users are affected. 3. Can abrt/Fedora please ensure that original abrt reporters don't get email either. Makes sense to me. 4. Can abrt/Fedora track abrt submitted BZs and report only when there's a fix available. Why that? We will loose lots of useful input. Everybody will just sit and wait for a fix instead of actively working on it by providing details and feedback. 5. Can abrt give me a list of submitted BZs so I can browse them if I want to? Makes sense. Two more features I'd like to see: * Don't subscribe people to bugs that are closed duplicate. Subscribe them to the original bug report. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=538783 * Limit the number of reports for a particular crash or even ignore certain crashes. This would have helped us with the LXDE spin, where a crashed application was respawned by the the session manager and the permanent crashes made abrt using all CPU and filling up the live OS overlay with crash reports. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=539551 Thanks for everybody who works on abrt. It's a great tool that surely will improve the overall quality of the code. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FYI: packageDB URL changes coming up
This is a heads up for people using the PackageDB in scripts. The plan is to have the 0.5.x PackageDB deployed in infrastructure no later than Fedora 13 Alpha (currently penciled in as 2010-02-09). This release will include major changes in the URL structure and a few removals of unused methods. More major changes are planned for 0.6.x. The best thing that you can do to fix your code is to port it to use python-fedora. If the methods you use are not exposed in python-fedora, either submit your code as an additional method to python-fedora or file a bug requesting the API be added[1]_. python-fedora API will go through a visible deprecation cycle with warnings being issued by the code itself when a method is going away. We'll make compatibility calls (which may be slower but will preserve the API) whenever possible. Neither of these are guaranteed to be available when targeting the PackageDB URLs directly. As the codebase stabilises, we'll get a test server running on https://admin.stg.fedoraproject.org/pkgdb/ if people want to try out the new features. .. _[1]: https://fedorahosted.org/python-fedora/ Login with your FAS username and password. Then click on file a new ticket. Feel free to assign it to me (my fas name is toshio) pgpbYATE6maD9.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
James Morris (jmor...@namei.org) said: - The local session can now install any signed packages from the Fedora repos: - I think this includes old versions of packages (correct?) Incorrect. 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. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Old/compat package naming
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 Regards, Lubo -- Flash is the Web2.0 version of blink and animated gifs. -- Stephen Smoogen -- 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 04:29 AM, Neal Becker wrote: I can't seem to get abrt to work at all. I suspect it's stuck on trying to get bz username password. I suspect it doesn't work correctly with kde. Yeah, gnome-keyring and KDE don't play together nicely at times. Try removing ~/.gnome2/keyrings and logging back in. Worked for me. Will destroy any nm-applet wireless passwords if you are using that. -- 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: Old/compat package naming
Lubomir Rintel (lkund...@v3.sk) said: glib1:1.2.10-32.fc11 glib2 2.20.5-1.fc11 gtk+1:1.2.10-68.fc11 gtk22.16.6-2.fc11 Given the history of these, this sounds like way more work to change than it's worth. (They'd certainly have to still provide 'glib2' and 'gtk2' for many years in the future.) Bill -- 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 05:01 AM, Paul Howarth wrote: FWIW, you could configure this for your own account by editing your bugzilla email preferences to not send you mail when the Cc: list changes. I did this long ago - I'm tempted to say it should be the default. -- 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: PackageKit policy: background and plans
On Fri, 2009-11-20 at 11:50 -0430, Robert Marcano wrote: On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. Though that only helps from the command line if you use gpk-install-package-name rather than yum. Probably not too many people do that :-) - Owen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
brp-python-bytecompile
I'm looking into the build failures Matt identified. With my shiny new Rawhide VM, I'm seeing this output on a local build of a package with no python sources: [ ... successful build messages ...] + /usr/lib/rpm/brp-python-bytecompile Bytecompiling .py files below [BUILDROOT]/usr/lib*/python*/ using /usr/bin/python* Usage: /usr/bin/python-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] Usage: /usr/bin/python-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] + /usr/lib/rpm/redhat/brp-python-hardlink [ ... successful build messages ...] The rpm build is completing, so I'm not worried about this particular package. Is this going to cause problems with packages that do have python sources, or is this just because nothing matches /usr/lib*/python*/ in the build root? It looks like python_binary = /usr/bin/python*, which can match any of these: /usr/bin/python /usr/bin/python-config /usr/bin/python2 /usr/bin/python2.6 /usr/bin/python2.6-config Regards, -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Owen Taylor wrote: On Fri, 2009-11-20 at 11:50 -0430, Robert Marcano wrote: On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. Though that only helps from the command line if you use gpk-install-package-name rather than yum. Probably not too many people do that :-) if you install from the command line using yum and you're worried about the install obliterating your X session I would recommend using screen. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091120 changes
Compose started at Fri Nov 20 08:15:09 UTC 2009 New package fvkbd Free Virtual Keyboard New package gdouros-alexander-fonts A Greek typeface inspired by Alexander Wilson New package gdouros-analecta-fonts An ecclesiastic scripts font New package hunspell-ht Haitian Creole hunspell dictionaries New package kde-plasma-smooth-tasks KDE taskbar replacement with window peeking ability New package perl-CPAN-Checksums Write a CHECKSUMS file for a directory as on CPAN New package perl-Devel-Refactor Perl extension for refactoring Perl code New package perl-LWP-Online Module for accessing web by proccess New package xorg-x11-drv-wacom Xorg X11 wacom input driver Updated Packages: GMT-4.5.1-3.fc13 * Thu Nov 19 2009 Orion Poplawski or...@cora.nwra.com 4.5.1-2 - Rebuild for netcdf 4.1.0 - Don't make GMT-common depend on GMT - Remove BR GMT-coastlines, disable check for bootstrap * Thu Nov 19 2009 Orion Poplawski or...@cora.nwra.com 4.5.1-3 - Re-enable check GMT-coastlines-2.0.1-2.fc13 --- * Thu Nov 19 2009 Orion Poplawski or...@cora.nwra.com 2.0.1-2 - Require GMT-common instead for directory ownership PyQt4-4.6.1-2.fc13.1 * Thu Nov 19 2009 Rex Dieter rdie...@fedoraproject.org - 4.6.1-2.1 - rebuild (for qt-4.6.0-rc1, f13+) PyQwt-5.2.0-3.fc13.1 * Thu Nov 19 2009 Rex Dieter rdie...@fedoraproject.org - 5.2.0-3.1 - rebuild (for qt-4.6.0-rc1, f13+) R-lmtest-0.9-25.fc13 * Thu Nov 19 2009 Orion Poplawski or...@cora.nwra.com 0.9-25 - Update to 0.9-25 - Update spec for R 2.10.0 (fixes FTBFS bug #538867) R-mvtnorm-0.9-8.1.fc13 -- * Thu Nov 19 2009 Orion Poplawski or...@cora.nwra.com - 0.9-8.1 - Update to 0.9-8 - Update spec for R 2.10.0 (fixes FTBFS bug #539041) R-systemfit-1.1-2.fc13 -- * Thu Nov 19 2009 Orion Poplawski or...@cora.nwra.com - 1.1-2 - Update spec for R 2.10.0 (fixes FTBFS bug #538892) arm-gp2x-linux-binutils-2.16.1-8.fc13 - * Thu Nov 19 2009 Hans de Goede hdego...@redhat.com 2.16.1-8 - Fix buffer overflows in ar (#538869) ballbuster-1.0-10.fc13 -- * Thu Nov 19 2009 Hans de Goede hdego...@redhat.com 1.0-10 - Fix FTBFS, BuildRequire ClanLib1-devel (#538930) banner-1.3.2-1.fc12 --- * Thu Nov 19 2009 Oliver Falk oli...@linux-kernel.at - 1.3.2-1 - Update berusky-1.1-13.fc13 --- * Thu Nov 19 2009 Martin Stransky stran...@redhat.com 1.1-13 - fixed dirs (#473628) berusky-data-1.0-7.fc13 --- * Thu Nov 19 2009 Martin Stransky stran...@redhat.com 1.0-7 - fixed licence #473628 bluefish-1.0.7-9.fc13 - * Thu Nov 19 2009 Paul Howarth p...@city-fan.org - 1.0.7-9 - Buildreq gnome-mime-data, not pulled in by gnome-vfs2 since 2.24.1-8 - Buildreq enchant-devel = 1.4.2, needed for enchant_dict_add - Make %files list more explicit blueman-1.21-2.fc12 --- * Thu Nov 12 2009 Juan Rodriguez nus...@fedoraproject.org - 1.21-2 - Fixes segfault - Removes notification-daemon requirement - Disables HAL and enabled PolKit1 for Fedora 12 * Sun Oct 18 2009 Juan Rodriguez nus...@gmail.com - 1.21-1 - Bumping to the latest Blueman. botan-1.8.8-2.fc13 -- * Thu Nov 19 2009 Thomas Moschny thomas.mosc...@gmx.de - 1.8.8-2 - Add patch from upstream to build with binutils-2.20.51.0.2. Fixes bz 538949 (ftbfs). * Thu Nov 05 2009 Thomas Moschny thomas.mosc...@gmx.de - 1.8.8-1 - Update to 1.8.8, a bugfix release. bugzilla-3.4.4-1.fc13 - * Thu Nov 19 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 3.4.4-1 - Update to 3.4.4 (CVE-2009-3386) ccid-1.3.11-1.fc13 -- * Thu Nov 19 2009 Kalev Lember ka...@smartlink.ee - 1.3.11-1 - Updated to ccid 1.3.11 - Removed iso-8859-1 to utf-8 conversion as the files are in utf-8 now cups-1.4.2-7.fc13 - * Thu Nov 19 2009 Tim Waugh twa...@redhat.com 1:1.4.2-7 - Applied patch to fix CVE-2009-3553 (bug #530111, STR #3200). * Tue Nov 17 2009 Tim Waugh twa...@redhat.com 1:1.4.2-6 - Fixed display of current driver (bug #537182, STR #3418). - Fixed out-of-memory handling when loading jobs (bug #538054, STR #3407). cvc3-2.2-1.fc13 --- * Thu Nov 19 2009 Jerry James loganje...@gmail.com - 2.2-1 - Update to 2.2 - Drop upstreamed patches (gcc4 and java) dracut-002-25.git44a6a0d9.fc13 -- * Thu Nov 19 2009 Harald Hoyer har...@redhat.com 002-25 - add more requirements for dracut-fips (bug #539257) fedora-package-config-smart-12.89-20 * Thu Nov 19 2009 Axel Thimm axel.th...@atrpms.net - 12.89-20 - Update to F13 rawhide. fedora-setup-keyboard-0.4-4.fc13 * Fri Nov 20 2009 Peter Hutterer peter.hutte...@redhat.com 0.4-4 - rhpl was replaced by
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Frank Ch. Eigler wrote: otaylor wrote: This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. To what extent are yum/rpm/packagekit transactions databasey enough so that they can actually be undone if the machine or process crashes midstream? not enough. We can sometimes recover - it really depends on where it died :( -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On 09-11-20 07:06:34, Jiri Moskovcak wrote: On 11/20/2009 12:24 PM, Matthew Booth wrote: ... 5. Can abrt give me a list of submitted BZs so I can browse them if I want to? This is in our TODO: ABRT should find possible duplicates and offer the reporter to browse them and manually mark them as a duplicate. ... Like Debian's reportbug command? It's probably worth a look. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Fri, Nov 20, 2009 at 08:48:56 -0500, Simo Sorce sso...@redhat.com wrote: On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote: On 11/20/2009 02:21 AM, Rudolf Kastl wrote: there are also inconsistencies between gui clickery and shell usage... simple example: click shutdown in gnome just does it in f12 Yeah, you can do that in F11 as well :( I agree, this needs protecting with a root password too. Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button. I disagree. I don't want guests accidentally shutting down machines. If they have to hit the power button it makes it a bit harder to do by mistake. It isn't a huge deal, but I'd definitely prefer that the shutdown/restart GUI stuff not work unless your authenticated as root. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On Fri, 2009-11-20 at 12:23 -0600, Bruno Wolff III wrote: On Fri, Nov 20, 2009 at 08:48:56 -0500, Simo Sorce sso...@redhat.com wrote: On Fri, 2009-11-20 at 03:42 -0500, Jeff Garzik wrote: On 11/20/2009 02:21 AM, Rudolf Kastl wrote: there are also inconsistencies between gui clickery and shell usage... simple example: click shutdown in gnome just does it in f12 Yeah, you can do that in F11 as well :( I agree, this needs protecting with a root password too. Jeff this is silly. Shutdown in console by default is perfectly fine, otherwise the user can simply push the power button. I disagree. I don't want guests accidentally shutting down machines. If they have to hit the power button it makes it a bit harder to do by mistake. It isn't a huge deal, but I'd definitely prefer that the shutdown/restart GUI stuff not work unless your authenticated as root. I understand your point, but this is really splitting hairs. In this case I think the default is fine because it is not a security issue (if you have console access). If you still don't like it you should change the default. Now, I know that changing PolicyKit related defaults is not easy at the moment. But that's an issue of man hours, finding someone willing to build a desktop tool that allows you to easily see current policies and create local ones on the fly. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Fri, 2009-11-20 at 11:24 +, Matthew Booth wrote: Firstly, I'd like to say I think abrt is fantastic. Call what follows a nit-pick. It's just a pretty in-your-face nit. After installing F12, after a short while I got presented with a couple of SELinux errors. This is nothing unusual in a new Fedora release, but this time it asked me for my bugzilla login details and offered to submit the bug automatically for me. Fantastic! The lazy person in me who wants to do the right thing truly appreciates this. Turns out I wasn't the first person report them, so it added me to the CC list. If these were selinux reports, you were not actually using abrt. You were using the enhanced features of setroubleshoot, which can now submit problems to Bugzilla. All your points happen to be valid, however, and applicable to both. Which is handy =) -- 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: Local users get to play root?
On Fri, 2009-11-20 at 10:50 -0500, Bill Nottingham wrote: Benny Amorsen (benny+use...@amorsen.dk) said: If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON. It's not a blanket prohibition. (See also opensshd, rsyslog, etc.) Additionally, I believe it applies only to daemons which are configured to be remote-accessible by default. I don't believe cronie is. -- 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: brp-python-bytecompile
On Fri, 2009-11-20 at 09:53 -0700, Jerry James wrote: I'm looking into the build failures Matt identified. With my shiny new Rawhide VM, I'm seeing this output on a local build of a package with no python sources: [ ... successful build messages ...] + /usr/lib/rpm/brp-python-bytecompile Bytecompiling .py files below [BUILDROOT]/usr/lib*/python*/ using /usr/bin/python* Usage: /usr/bin/python-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] Usage: /usr/bin/python-config [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] + /usr/lib/rpm/redhat/brp-python-hardlink [ ... successful build messages ...] The rpm build is completing, so I'm not worried about this particular package. Is this going to cause problems with packages that do have python sources, or is this just because nothing matches /usr/lib*/python*/ in the build root? It looks like python_binary = /usr/bin/python*, which can match any of these: /usr/bin/python /usr/bin/python-config /usr/bin/python2 /usr/bin/python2.6 /usr/bin/python2.6-config Sorry; looks like my fault. I updated /usr/lib/rpm/brp-python-bytecompile to better cope with the python 2 vs python 3 split; this was in: https://bugzilla.redhat.com/show_bug.cgi?id=531117 From my reading, what's happening is that I coded it with the (incorrect) assumption that files exist which match $RPM_BUILD_ROOT/usr/lib*/python*/ When at least one such file exists, I believe the shell expands the glob and thus we iterate over the library subdirectories, byte-compiling all .py files in them with the appropriate version of python. When no such directory exists, the shell fails to expand it, and retains it as the text string: your_build_root/usr/lib*/python*/ and thus one iteration of that loop happens, and we get the two error messages. So I believe this is harmless but messy. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=539635 Sorry for any confusion. Dave -- 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 06:39 PM, Kevin Kofler wrote: Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and using the 32-bit version is suboptimal. how can this be checked from within a web browser? Trusted Java applet? -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle -- 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?
Benny Amorsen wrote: Kevin Kofler kevin.kof...@chello.at writes: If we don't want to live in the past, we should go away from 32-bit, not from CDs. ;-) Doubling the download size for everyone is a bad solution. An extra kernel shouldn't be that big a problem. But it doesn't really solve the issue, as your userland will still be suboptimal. 64-bit is not just about the kernel. 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 Sat, Nov 21, 2009 at 12:32 AM, Kevin Kofler kevin.kof...@chello.at wrote: Colin Walters wrote: 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. My experience is that fireforget reporting is rarely useful, especially if it comes from an automated tool where users rarely think of filling in ANY information other than the autogenerated stuff. We MUST be able to contact the reporter for more information. If they're not willing to answer needinfo requests, the report is basically useless. 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). -- 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?
Benny Amorsen wrote: Kevin Kofler kevin.kof...@chello.at writes: (and not really implementable for the live images) Why not? It should be reasonably easy to handle that in the boot loader. 1. Needs GRUB hackery to support transparently. (For the DVD, Anaconda can detect the architecture and install a kernel accordingly, but for a live CD, we don't have any such support.) 2. Not enough room on a CD for the extra kernel. And it doesn't solve the real issue anyway. Kevin Kofler -- 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 Fri, 20 Nov 2009, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. This is how I started doing things in 1993, although I changed to sudo a few years back. - The local session has a new means to execute in a high privilege context, i.e. that which is required to install the system itself. This is a problem alone -- everything which runs in this context is now a prime attack target. I don't think I'd agree with that. The common case for F10 and F11 will be for people to have installed a package once with the root password and then ticked the Remember authentication box. At that point, we have the same security exposure as we do with F12 (again, concentrating on the single-user machine case). I never tick those boxes. I'd like to know how to get rid of them entirely. I definitely agree that there's a whole range of cases where this isn't the behaviour you want. But for the vast majority of our users, I don't think there's a real security issue here. Are we moving toward a model where the user and the administrator are no longer really separated? Things seem to be regressing according to whatever use-case some desktop developer thinks is important at the time. - 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: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Bill Nottingham wrote: 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. -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-XML-LibXSLT/devel .cvsignore, 1.7, 1.8 perl-XML-LibXSLT.spec, 1.20, 1.21 sources, 1.7, 1.8 perl-XML-LibXSLT-refcount.patch, 1.1, NONE
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-XML-LibXSLT/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv2712
Modified Files:
.cvsignore perl-XML-LibXSLT.spec sources
Removed Files:
perl-XML-LibXSLT-refcount.patch
Log Message:
* Fri Nov 20 2009 Marcela Mašláňová mmasl...@redhat.com - 1:1.70-1
- update to fix 539102
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-XML-LibXSLT/devel/.cvsignore,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- .cvsignore 20 Dec 2008 17:05:02 - 1.7
+++ .cvsignore 20 Nov 2009 08:35:26 - 1.8
@@ -1 +1 @@
-XML-LibXSLT-1.68.tar.gz
+XML-LibXSLT-1.70.tar.gz
Index: perl-XML-LibXSLT.spec
===
RCS file: /cvs/pkgs/rpms/perl-XML-LibXSLT/devel/perl-XML-LibXSLT.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- perl-XML-LibXSLT.spec 26 Jul 2009 17:35:45 - 1.20
+++ perl-XML-LibXSLT.spec 20 Nov 2009 08:35:27 - 1.21
@@ -3,8 +3,8 @@
Name: perl-XML-LibXSLT
# NOTE: also update perl-XML-LibXML to a compatible version. See below why.
-Version: 1.68
-Release: 4%{?dist}
+Version: 1.70
+Release: 1%{?dist}
Summary: Perl module for interfacing to GNOME's libxslt
@@ -17,9 +17,6 @@ BuildRequires:perl(ExtUtils::MakeMaker)
BuildRequires: libxslt-devel = 1.1.18, gdbm-devel
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-# http://rt.cpan.org/Public/Bug/Display.html?id=40844 , #490781
-Patch0:perl-XML-LibXSLT-refcount.patch
-
# the package shares code with perl-XML-LibXML, we have to require a
compatible version
# see https://bugzilla.redhat.com/show_bug.cgi?id=469480
BuildRequires: perl(XML::LibXML) = 1.67
@@ -31,7 +28,6 @@ that you can find at http://www.xmlsoft.
%prep
%setup -q -n XML-LibXSLT-%{version}
-%patch0 -p1 -b .refcount
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
@@ -60,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Fri Nov 20 2009 Marcela Mašláňová mmasl...@redhat.com - 1:1.70-1
+- update to fix 539102
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.68-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-XML-LibXSLT/devel/sources,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- sources 20 Dec 2008 17:05:02 - 1.7
+++ sources 20 Nov 2009 08:35:27 - 1.8
@@ -1 +1 @@
-23265ad14469b3eede5833f205198a6f XML-LibXSLT-1.68.tar.gz
+c63a7913999de076e5c911810f69b392 XML-LibXSLT-1.70.tar.gz
--- perl-XML-LibXSLT-refcount.patch DELETED ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-PPIx-EditorTools/devel .cvsignore, 1.2, 1.3 perl-PPIx-EditorTools.spec, 1.1, 1.2 sources, 1.2, 1.3
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-PPIx-EditorTools/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16840
Modified Files:
.cvsignore perl-PPIx-EditorTools.spec sources
Log Message:
* Fri Nov 20 2009 Marcela Mašláňová mmasl...@redhat.com 0.09-1
- update
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-PPIx-EditorTools/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 18 Aug 2009 06:03:26 - 1.2
+++ .cvsignore 20 Nov 2009 09:17:25 - 1.3
@@ -1 +1 @@
-PPIx-EditorTools-0.07.tar.gz
+PPIx-EditorTools-0.09.tar.gz
Index: perl-PPIx-EditorTools.spec
===
RCS file:
/cvs/pkgs/rpms/perl-PPIx-EditorTools/devel/perl-PPIx-EditorTools.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-PPIx-EditorTools.spec 18 Aug 2009 06:03:26 - 1.1
+++ perl-PPIx-EditorTools.spec 20 Nov 2009 09:17:25 - 1.2
@@ -1,5 +1,5 @@
Name: perl-PPIx-EditorTools
-Version:0.07
+Version:0.09
Release:1%{?dist}
Summary:Utility methods and base class for manipulating Perl via PPI
License:GPL+ or Artistic
@@ -49,5 +49,8 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Nov 20 2009 Marcela Mašláňová mmasl...@redhat.com 0.09-1
+- update
+
* Fri Aug 14 2009 Marcela Mašláňová mmasl...@redhat.com 0.07-1
- Specfile autogenerated by cpanspec 1.78.
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-PPIx-EditorTools/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 18 Aug 2009 06:03:27 - 1.2
+++ sources 20 Nov 2009 09:17:25 - 1.3
@@ -1 +1 @@
-bb0efaf7c203881c390857e0ccd6da88 PPIx-EditorTools-0.07.tar.gz
+70a81ebc7fd7ae573a40e83e36f9c38f PPIx-EditorTools-0.09.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Authen-Simple/devel import.log, NONE, 1.1 perl-Authen-Simple.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-Authen-Simple/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31687/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Authen-Simple.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Authen-Simple-0_4-1_fc12:HEAD:perl-Authen-Simple-0.4-1.fc12.src.rpm:1258763169
--- NEW FILE perl-Authen-Simple.spec ---
Name: perl-Authen-Simple
Version:0.4
Release:1%{?dist}
Summary:Simple Authentication
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Authen-Simple/
Source0:
http://www.cpan.org/authors/id/C/CH/CHANSEN/Authen-Simple-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Class::Accessor::Fast)
BuildRequires: perl(Class::Data::Inheritable)
BuildRequires: perl(Crypt::PasswdMD5)
BuildRequires: perl(Digest::SHA)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Params::Validate)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Simple and consistent framework for authentication.
%prep
%setup -q -n Authen-Simple-%{version}
%build
%{__perl} Build.PL installdirs=vendor
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Wed Oct 07 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.4-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Authen-Simple/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 20 Nov 2009 22:39:11 - 1.1
+++ .cvsignore 21 Nov 2009 00:26:33 - 1.2
@@ -0,0 +1 @@
+Authen-Simple-0.4.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Authen-Simple/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Nov 2009 22:39:11 - 1.1
+++ sources 21 Nov 2009 00:26:34 - 1.2
@@ -0,0 +1 @@
+ca2ebc687e9282c92f488fa79e3e8723 Authen-Simple-0.4.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-SuperForm/F-12 import.log, NONE, 1.1 perl-CGI-Application-Plugin-SuperForm.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-SuperForm/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1423/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-SuperForm.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-SuperForm-0_4-2_fc12:F-12:perl-CGI-Application-Plugin-SuperForm-0.4-2.fc12.src.rpm:1258763437
--- NEW FILE perl-CGI-Application-Plugin-SuperForm.spec ---
Name: perl-CGI-Application-Plugin-SuperForm
Version:0.4
Release:2%{?dist}
Summary:Create sticky forms with HTML::SuperForm
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-SuperForm/
Source0:
http://www.cpan.org/authors/id/V/VA/VANAMBURG/CGI-Application-Plugin-SuperForm-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTML::SuperForm)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Create sticky HTML forms in CGI::Application run modes using HTML::SuperForm.
%prep
%setup -q -n CGI-Application-Plugin-SuperForm-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes EXAMPLES README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Fri Sep 18 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.4-2
- add perl(Test::More) and perl(Test::Pod) to BuildRequires
* Fri Sep 18 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.4-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-SuperForm/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 20 Nov 2009 22:40:39 - 1.1
+++ .cvsignore 21 Nov 2009 00:31:16 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-SuperForm-0.4.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-SuperForm/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Nov 2009 22:40:39 - 1.1
+++ sources 21 Nov 2009 00:31:16 - 1.2
@@ -0,0 +1 @@
+604e2c3a04c5311003561bc8fd4a03ba CGI-Application-Plugin-SuperForm-0.4.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-SuperForm/F-11 import.log, NONE, 1.1 perl-CGI-Application-Plugin-SuperForm.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-SuperForm/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1941/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-SuperForm.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-SuperForm-0_4-2_fc12:F-11:perl-CGI-Application-Plugin-SuperForm-0.4-2.fc12.src.rpm:1258763519
--- NEW FILE perl-CGI-Application-Plugin-SuperForm.spec ---
Name: perl-CGI-Application-Plugin-SuperForm
Version:0.4
Release:2%{?dist}
Summary:Create sticky forms with HTML::SuperForm
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-SuperForm/
Source0:
http://www.cpan.org/authors/id/V/VA/VANAMBURG/CGI-Application-Plugin-SuperForm-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTML::SuperForm)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Create sticky HTML forms in CGI::Application run modes using HTML::SuperForm.
%prep
%setup -q -n CGI-Application-Plugin-SuperForm-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes EXAMPLES README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Fri Sep 18 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.4-2
- add perl(Test::More) and perl(Test::Pod) to BuildRequires
* Fri Sep 18 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.4-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-SuperForm/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 20 Nov 2009 22:40:39 - 1.1
+++ .cvsignore 21 Nov 2009 00:32:19 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-SuperForm-0.4.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-SuperForm/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 20 Nov 2009 22:40:39 - 1.1
+++ sources 21 Nov 2009 00:32:19 - 1.2
@@ -0,0 +1 @@
+604e2c3a04c5311003561bc8fd4a03ba CGI-Application-Plugin-SuperForm-0.4.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
