Re: /etc/mtab
On Wed, Dec 22, 2010 at 10:38:21PM -0500, Bernie Innocenti wrote: What's preventing us from symlinking /etc/mtab to /proc/mounts and get rid of confusing situations when mtab gets out of sync with the kernel? It is not possible to set the files ystem in /proc/mounts as it is possible with /etc/mtab. This breaks the usage of mount helper tools like mount.crypt from pam_mount that allows to mount and umount encrypted partitions using mount. To get umount.crypt called when umount of an encrypted file system is run, crypt needs to be written in the file system column in /etc/mtab. Regards Till pgpKLb6jpxQ4s.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/mtab
On Wed, 22.12.10 22:38, Bernie Innocenti (ber...@codewiz.org) wrote: What's preventing us from symlinking /etc/mtab to /proc/mounts and get rid of confusing situations when mtab gets out of sync with the kernel? Some of the mount options that /bin/mount uses currently are seen by userspace only and cannot be attached to the mount point in-kernel. The effect of that is that if you symlink /etc/mtab to /proc/mounts these options get silently dropped after mount, and while they might have effect at mount time, afterwards (i.e. umount time) they will have zero effect. An example of such an option is user and users. It is definitely planned to get rid of /etc/mtab, but before that happens the kernel must either learn to store userspace mount options along kernel mount options for each mount point in some way (Miklos Szeredi has been working on this IIRC), or /bin/mount must learn to store these options somewhere in userspace (for example /dev/.mount or so), and then augment its output with these options. (Karel Zak has been thinking about adding this). Sooner or laer we will definitely make /etc/mtab a symlink, which should take us one definite step nearer to supporting r/o root by default. In fact, in systemd we already warn during boot if /etc/mtab is not a symlink, and we do not longer clear that file on bootup, all to put a tiny bit of pressure on the folks involved to fix this properly once and for all, in the F15 timeframe... I tried running my system for a few months this way. The only regressions I'm seeing are: 1) the Gnome Disk Mounter panel applet seems to get confused. After a loopback mount gets unmounted, there's still an icon to remount the device. (the loopback device is correctly cleaned up at umount time). Loop devices use userspace-only mount options too, afair. 2) on boot, the system tries to remount /sys even though it's already mounted, thus spitting this harmless error: Remounting root filesystem in read-write mode: [ OK ] mount: according to mtab, /dev/sda1 is already mounted on / Mounting local filesystems: mount: sysfs already mounted or /sys busy mount: according to mtab, /sys is already mounted on /sys [FAILED] Enabling /etc/fstab swaps: [ OK ] This problem is gone on F15/Rawhide anyway, since systemd mounts this dir. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora java png parser issue
Hi all, Please see this bug https://bugzilla.redhat.com/show_bug.cgi?id=665355 Fedora java distribution cannot read some PNG images which work fine in * Windows java 1.6 * Linux image viewers * browsers * identify a.png works: PNG 16x16 16x16+0+0 8-bit DirectClass 1.38KB 0.000u 0:00.000 (more info and code to reproduce in bug). Do you have any suggestion for workarounds or fix? (besides re-generating all pngs somehow) Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/mtab
On Thu, 2010-12-23 at 12:12 +0100, Lennart Poettering wrote: On Wed, 22.12.10 22:38, Bernie Innocenti (ber...@codewiz.org) wrote: What's preventing us from symlinking /etc/mtab to /proc/mounts and get rid of confusing situations when mtab gets out of sync with the kernel? Some of the mount options that /bin/mount uses currently are seen by userspace only and cannot be attached to the mount point in-kernel. The effect of that is that if you symlink /etc/mtab to /proc/mounts these options get silently dropped after mount, and while they might have effect at mount time, afterwards (i.e. umount time) they will have zero effect. An example of such an option is user and users. It is definitely planned to get rid of /etc/mtab, but before that happens the kernel must either learn to store userspace mount options along kernel mount options for each mount point in some way (Miklos Szeredi has been working on this IIRC), or /bin/mount must learn to store these options somewhere in userspace (for example /dev/.mount or so), and then augment its output with these options. (Karel Zak has been thinking about adding this). And lets not forget the need for a pseudo mount option that can be used by the user space tools to ignore certain mounts, such as autofs mounts. Sooner or laer we will definitely make /etc/mtab a symlink, which should take us one definite step nearer to supporting r/o root by default. In fact, in systemd we already warn during boot if /etc/mtab is not a symlink, and we do not longer clear that file on bootup, all to put a tiny bit of pressure on the folks involved to fix this properly once and for all, in the F15 timeframe... I tried running my system for a few months this way. The only regressions I'm seeing are: 1) the Gnome Disk Mounter panel applet seems to get confused. After a loopback mount gets unmounted, there's still an icon to remount the device. (the loopback device is correctly cleaned up at umount time). Loop devices use userspace-only mount options too, afair. 2) on boot, the system tries to remount /sys even though it's already mounted, thus spitting this harmless error: Remounting root filesystem in read-write mode: [ OK ] mount: according to mtab, /dev/sda1 is already mounted on / Mounting local filesystems: mount: sysfs already mounted or /sys busy mount: according to mtab, /sys is already mounted on /sys [FAILED] Enabling /etc/fstab swaps: [ OK ] This problem is gone on F15/Rawhide anyway, since systemd mounts this dir. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package-specific test case and critical path test case project: drafts for review
On Tue, 2010-12-21 at 17:11 +, Adam Williamson wrote: Hi, everyone. So, in the recent debate about the update process it again became clear that we were lacking a good process for providing package-specific test instructions, and particularly specific instructions for testing critical path functions. I've been working on a process for this, and now have two draft Wiki pages up for review which together describe it: https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_test_case_creation https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_package_test_plan_creation I've now converted one package's set of test cases to the proposed new system to serve as an illustration. I used the Radeon driver, xorg-x11-drv-ati . This was a good example as there's a lot of them, and they split neatly into critpath, core and extended to illustrate the optional advanced categorization system. So, see: https://fedoraproject.org/wiki/Category:Package_xorg-x11-drv-ati_test_cases and note that one of the test cases is also in: https://fedoraproject.org/wiki/Category:Critical_path_test_cases you can also see at https://fedoraproject.org/wiki/Category:Test_Cases how this tracks back to that overall category - no test cases are in it directly, it's all hierarchical. thanks! I'm planning to work on a mockup for the f-e-k and bodhi integration this afternoon to show how we envision this all being used to kick ass, I think that'll make it clearer. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora java png parser issue
On 23 December 2010 12:01, Marius Andreiana marius.andreia...@gmail.com wrote: Hi all, Please see this bug https://bugzilla.redhat.com/show_bug.cgi?id=665355 Fedora java distribution cannot read some PNG images which work fine in * Windows java 1.6 * Linux image viewers * browsers * identify a.png works: PNG 16x16 16x16+0+0 8-bit DirectClass 1.38KB 0.000u 0:00.000 (more info and code to reproduce in bug). Do you have any suggestion for workarounds or fix? (besides re-generating all pngs somehow) Thanks You might get more response from the java-devel list. I will forward this message to that list. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package-specific test case and critical path test case project: drafts for review
On Thu, 2010-12-23 at 14:35 +, Adam Williamson wrote: thanks! I'm planning to work on a mockup for the f-e-k and bodhi integration this afternoon to show how we envision this all being used to kick ass, I think that'll make it clearer. Bodhi mockup post: http://www.happyassassin.net/2010/12/23/package-specific-test-case-project-news-and-a-mockup/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora java png parser issue
On 12/23/2010 03:01 PM, Mat Booth wrote: On 23 December 2010 12:01, Marius Andreianamarius.andreia...@gmail.com wrote: Hi all, Please see this bug https://bugzilla.redhat.com/show_bug.cgi?id=665355 Fedora java distribution cannot read some PNG images which work fine in * Windows java 1.6 * Linux image viewers * browsers * identify a.png works: PNG 16x16 16x16+0+0 8-bit DirectClass 1.38KB 0.000u 0:00.000 (more info and code to reproduce in bug). Do you have any suggestion for workarounds or fix? (besides re-generating all pngs somehow) You might get more response from the java-devel list. I will forward this message to that list. I assure you that the Red Hat Java team is listening. :-) Right now I have no idea what the problem might be. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Taking ownership of netbeans and its dependencies
Hi, I would like to take ownership of the following orphaned packages: appframework beansbinding bindex freemarker ini4j javahelp2 jemmy netbeans netbeans-javaparser netbeans-platform netbeans-resolver netbeans-svnclientadapter swingx Comaintainers are welcome! Cheers, Omair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
Hello, as discussed some time ago, I worked on the proof of concept implementation of firewalld. FirewallD is a service daemon with a D-BUS interface that provides a dynamic managed firewall. For more information on firewalld, please have a look at: https://fedoraproject.org/wiki/FirewallD/ About this version: This is mostly the proof of concept implementation with some changes and is feature complete for F-15 as a firewalld preview version. It will not be enabled per default and will also not get installed per default. The system-config-firewall with static firewall model will still be the default firewall solution for Fedora 15. What this firewalld version can do: - It supports most of the firewall features system-config-firewall had, but there are three limitations: 1) custom firewall rule files (iptables save format) are not supported and most likely will never be, but there is support for custom rules (limited functionality). 2) sysctl changes for ip_forward are not done, yet. 3) There are no permanent firewall settings, this means that all settings are lost after a service restart or reboot. Permanent firewall settings will be added later on. - The firewall daemon manages the firewall dynamically. This means that changes are done without recreating the whole firewall. Also there is no need to reload all firewall modules anymore. Firewall helpers are loaded and unloaded if needed. - A simple tray applet (firewall-applet) shows the status of the public firewall and is makes it simple to enable and disable firewall services. The applet does not show firewall configuration settings done with the libvirt interface. - firewall-cmd is the command line client that makes it possible to enable, disable, query and list firewall features. firewall-cmd is also not able to show firewall settings of the libvirt interface. - There is an rule and chain interface for libvirt, but the PolicyKit policy is not in place, yet. What this version can not do (future features): - firewall-config, the firewall configuration utility, is not functional - System vs. User/Session configuration - Zone support - NetworkManager firewall rule support firewalld made it into a fedorahosted repo at: git://git.fedorahosted.org/git/firewalld.git The fedoraproject wiki page at https://fedoraproject.org/wiki/FirewallD/ exists and will get more updates soon. The feature request page for Fedora 15 is also up to date: https://fedoraproject.org/wiki/Features/DynamicFirewall#How_To_Test For test packages, please have a look at http://twoerner.fedorapeople.org/firewalld/ firewalld has a requirement for system-config-firewall-1.2.28. This version has checks for an active firewalld in the tools. Please have a look at http://koji.fedoraproject.org/koji/buildinfo?buildID=211013 for the Fedora 15 packages of this version. It is usable on fedora versions 15. How To Test - Install firewalld and firewall-applet - Start the firewalld service - Start the tray applet firewall-applet - Use firewall-cmd to enable for example ssh: firewall-cmd --enable --service=ssh - Enable samba for 10 seconds: firewall-cmd --enable --service=samba --timeout=10 - Enable ipp-client: firewall-cmd --enable --service=ipp-client - Disable ipp-client: firewall-cmd --disable --service=ipp-client - To restore your static firewall with lokkit again simply use: lokkit --enabled You can also use the D-BUS interface directly. This is required for libvirt (and later on also NetworkManager). The D-BUS interface documentation is work in progress and will be added later on. Comments and additional information is highly welcome. Thanks in advance, Thomas -- Thomas Woerner Software EngineerPhone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner twoer...@redhat.com D-70178 StuttgartWeb : http://www.redhat.de/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-XML-TreeBuilder] - 661697 rebuild for fixing problems with vendorach/lib
commit 6f4a5acf3d49b37768181f3246507ccca2668661
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 17:23:10 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-TreeBuilder.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-TreeBuilder.spec b/perl-XML-TreeBuilder.spec
index 80838a5..f53fd80 100644
--- a/perl-XML-TreeBuilder.spec
+++ b/perl-XML-TreeBuilder.spec
@@ -1,7 +1,7 @@
Summary: Parser that builds a tree of XML::Element objects
Name: perl-XML-TreeBuilder
Version: 4.0
-Release: 1%{?dist}
+Release: 2%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/XML-TreeBuilder/
@@ -47,6 +47,9 @@ find $RPM_BUILD_ROOT -name .packlist -exec %{__rm} {} \;
%{perl_vendorlib}/XML/
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 4.0-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Dec 02 2010 Jeff Fearn jfe...@redhat.com - 4.0-1
- New upstream
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-Writer] - 661697 rebuild for fixing problems with vendorach/lib
commit 3d47931927ac4bb4cda2ceac14e5371402a5cb43
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 17:39:30 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-Writer.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-Writer.spec b/perl-XML-Writer.spec
index b496619..ea79a56 100644
--- a/perl-XML-Writer.spec
+++ b/perl-XML-Writer.spec
@@ -1,6 +1,6 @@
Name: perl-XML-Writer
Version:0.606
-Release:6%{?dist}
+Release:7%{?dist}
Summary:A simple Perl module for writing XML documents
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.606-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.606-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora java png parser issue
* Andrew Haley a...@redhat.com [2010-12-23 10:58]: On 12/23/2010 03:01 PM, Mat Booth wrote: On 23 December 2010 12:01, Marius Andreianamarius.andreia...@gmail.com wrote: Hi all, Please see this bug https://bugzilla.redhat.com/show_bug.cgi?id=665355 Fedora java distribution cannot read some PNG images which work fine in * Windows java 1.6 * Linux image viewers * browsers * identify a.png works: PNG 16x16 16x16+0+0 8-bit DirectClass 1.38KB 0.000u 0:00.000 (more info and code to reproduce in bug). Do you have any suggestion for workarounds or fix? (besides re-generating all pngs somehow) You might get more response from the java-devel list. I will forward this message to that list. I assure you that the Red Hat Java team is listening. :-) Right now I have no idea what the problem might be. I am looking into this now. Cheers, Deepak Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Help identifying bugzilla component
Can anyone help finding which component is right for: https://bugzilla.redhat.com/show_bug.cgi?id=665413 thanks in advance G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/22/2010 12:56 PM, Casey Dahlin wrote: On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote: This is from Paul Davis, the main architect of Jack (I forwarded him your post): this isn't exactly correct. in /dev/shm on linux we have: (a) unix-domain sockets for non-RT communication with the server Perhaps these could become abstract domain sockets. Could you explain a bit perhaps? I'm not familiar with them... (or maybe you have a url I could surf to?) Anyway, the main concern re: the subject of this thread is: (b) FIFOs for RT wakeups (this could use semaphores now) we do care about the performance of (b) These have to be very fast as they are used for waking up the next client in the round robbin transfer of control between jackd and its clients (and that's why they are in /dev/shm). -- Fernando -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-Parser-Syck] - 661697 rebuild for fixing problems with vendorach/lib
commit b72caeba77157219b33e5b69fa34af553e5b56e1
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 18:14:07 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-YAML-Parser-Syck.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-YAML-Parser-Syck.spec b/perl-YAML-Parser-Syck.spec
index 02db5d8..35e160e 100644
--- a/perl-YAML-Parser-Syck.spec
+++ b/perl-YAML-Parser-Syck.spec
@@ -1,6 +1,6 @@
Name: perl-YAML-Parser-Syck
Version:0.01
-Release:15%{?dist}
+Release:16%{?dist}
Summary:Perl Wrapper for the YAML Parser Extension: libsyck
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.01-16
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.01-15
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: noexec on /dev/shm
On Thu, 2010-12-23 at 09:11 -0800, Fernando Lopez-Lezcano wrote: On 12/22/2010 12:56 PM, Casey Dahlin wrote: On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote: (a) unix-domain sockets for non-RT communication with the server Perhaps these could become abstract domain sockets. Could you explain a bit perhaps? I'm not familiar with them... (or maybe you have a url I could surf to?) See the unix(7) man page. In /proc/net/unix, the abstract-namespace sockets are listed starting with an @ sign. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [packager interface suggestion] Adding packages to buildroot directly from updates-testing
On Thu, 23 Dec 2010 01:31:18 +0100
Henrik Nordström hen...@henriknordstrom.net wrote:
tis 2010-12-21 klockan 09:50 -0700 skrev Kevin Fenzi:
Basically it's changing spec files BuildRequires to suit our build
setup and not for 'the version this package needs to build'.
True. And it's use should be limited to the release branches of a
package, not master/rawhide.
Which would make it even more confusing and also cause divergence
between branches, which some maintainers dislike, or adding
conditionals.
Imho it adds value in the stable branch, as any lower version than
indicated is not aceptabe for packaging in that branch.
Yes, but thats just for our internal use, right?
People who take our src.rpm and try and rebuild for rhel or somewhere
else will get confused by it.
Or if you want to go fancy about it then use
%if 0%{fedora} = 14
BuildRequires: foo-devel = 1.1.0
%else
BuildRequires: foo-devel
%endif
Which just looks weird and adds complexity. ;)
This way you can add your override and use it to build what you
want, but you will be nagged every day to check and remove the
override if you no longer need it.
The main thing I have against overrides is that they affect a lot more
than just a single build.
Sure, they affect anything that pulls them into the buildroot. However,
if you are building package B which requires package A, you may well
want anything else that uses A to also use the new version.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAPE-Regex] - 661697 rebuild for fixing problems with vendorach/lib
commit a8310a59c2ede3a21d9603c77239ba1b7c954939
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 18:19:38 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-YAPE-Regex.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-YAPE-Regex.spec b/perl-YAPE-Regex.spec
index 61e74d8..90bc6ee 100644
--- a/perl-YAPE-Regex.spec
+++ b/perl-YAPE-Regex.spec
@@ -1,6 +1,6 @@
Name: perl-YAPE-Regex
Version:3.04
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Yet Another Parser/Extractor for Regular Expressions
# see https://rt.cpan.org/Public/Bug/Display.html?id=58040
License:GPL+ or Artistic
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 3.04-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Wed Jun 02 2010 Iain Arnell 3.04-1
- Specfile autogenerated by cpanspec 1.78.
- include license information
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: noexec on /dev/shm
On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano na...@ccrma.stanford.edu wrote: On 12/20/2010 02:17 PM, Adam Jackson wrote: On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote: I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages: Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). /tmp is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack. This is right and wrong. Right! Thanks very much for looking at this in such detail (I presume you looked at the 1.9.6 code base?). JACK uses /dev/shm for two purposes on Linux [1]. The first is as the definition of what its configure script calls HOST_DEFAULT_TMP_DIR. This path is only used as a name to which to attach the jack sockets. The extent to which this will _ever_ touch the disk, even on a journaled filesystem, is: - eventually, the inode for that socket and the dnode for the containing directory will have to be written to the disk, once. - under memory pressure the vfs may decide to throw away the inode cache for that socket, which would then have to be re-read from disk for subsequent connecting JACK clients. In other words, these are setup costs, not maintenance costs. This may cause glitches in a realtime scenario to the extent that clients are created and destroyed, but in general I submit that the cost of exec() of those new clients is going to dwarf the cost of the inode cache miss for the JACK socket. [2] My experience (caveat: a long time ago, maybe everything has changed internally in both jack and the kernel and that has invalidated my experience cache :-) was that using /tmp would lead to constant - not all the time, but very frequent and not correlated with client connection/disconnection - xruns (glitches in the audio), using /dev/shm would fix that immediately. That was why things were moved over to /dev/shm if I remember correctly. Well /tmp should be mounted tmpfs anyway (I have been doing this for years and it is working just fine). tmp isn't a persistent storage so it makes a lot of sense, and it is *not* a dumping ground for giant files (apps that try to do that are just broken). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
drago01 píše v Čt 23. 12. 2010 v 18:26 +0100: Well /tmp should be mounted tmpfs anyway (I have been doing this for years and it is working just fine). tmp isn't a persistent storage so it makes a lot of sense, and it is *not* a dumping ground for giant files (apps that try to do that are just broken). Is there any specific reason to consider applications that store great files to /tmp broken? In fact, historically the purpose of /tmp is _exactly_ the opposite. For example, sort(1) can be used to sort very large files. Small inputs are kept and stored in memory, large inputs use temporary files in /tmp. The _whole point_ of using /tmp in this case is that it can be stored larger data than what the virtual memory subsystem (or, perhaps, the address space) can handle. If /tmp becomes tmpfs, this useful property of /tmp disappears. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/mtab
On Thu, Dec 23, 2010 at 12:12:12PM +0100, Lennart Poettering wrote:
On Wed, 22.12.10 22:38, Bernie Innocenti (ber...@codewiz.org) wrote:
It is definitely planned to get rid of /etc/mtab, but before that
happens the kernel must either learn to store userspace mount options
along kernel mount options for each mount point in some way (Miklos
Szeredi has been working on this IIRC), or /bin/mount must learn to
It seems kernel will never be so promiscuous to care about arbitrary
userspace mount options.
Miklos wants to store fsuid (uid of the task doing the mount(2) syscall)
to VFS and make it accessible in /proc/self/{mounts,mountinfo}. This
will resolve our problem with user= mount option.
The others userspace (FS specific) mount options have to be managed
by filesystem drives, we shouldn't expect any generic solution by
VFS. The other solution is to store these options somewhere in
userspace (see below).
store these options somewhere in userspace (for example /dev/.mount or
so), and then augment its output with these options. (Karel Zak has been
thinking about adding this).
Yes, mount(8) in F15 will store arbitrary userspace mount options to
/dev/.mount/utab if a regular /etc/mtab does not exist. This feature
is implemented in incoming libmount.
In F16 the whole mount(8) (and some mount.type helpers) will be
based on libmount. Now we use the library for findmnt(8) only.
Sooner or laer we will definitely make /etc/mtab a symlink, which should
take us one definite step nearer to supporting r/o root by default.
In fact, in systemd we already warn during boot if /etc/mtab is not a
symlink, and we do not longer clear that file on bootup, all to put a
tiny bit of pressure on the folks involved to fix this properly once and
for all, in the F15 timeframe...
Thanks :-)
1) the Gnome Disk Mounter panel applet seems to get confused. After a
loopback mount gets unmounted, there's still an icon to remount the
device. (the loopback device is correctly cleaned up at umount time).
Loop devices use userspace-only mount options too, afair.
mount(8) in F15 will use auto-clear flag for loopdevs, the loop=
option will be unnecessary in mtab.
Karel
--
Karel Zak k...@redhat.com
http://karelzak.blogspot.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora java png parser issue
* Marius Andreiana marius.andreia...@gmail.com [2010-12-23 07:01]: Hi all, Please see this bug https://bugzilla.redhat.com/show_bug.cgi?id=665355 Fedora java distribution cannot read some PNG images which work fine in * Windows java 1.6 * Linux image viewers * browsers * identify a.png works: PNG 16x16 16x16+0+0 8-bit DirectClass 1.38KB 0.000u 0:00.000 (more info and code to reproduce in bug). Do you have any suggestion for workarounds or fix? (besides re-generating all pngs somehow) Hi, I have identified the problem. It is already fixed upstream in OpenJDK7. I have requested a backport to openjdk6 and to icedtea6 (the latter so that it can go in Fedora sooner): http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-December/011573.html If you are comfortable with building IcedTea (http://icedtea.classpath.org/wiki/Main_Page#Quick_start_.26_Building), or the java-1.6.0-openjdk RPM, you can apply the above patch and do so and it should resolve the issue. Outside of a new JDK build, your only option unfortunately is to fix the iTXt chunks in the pngs and regenerate them. Cheers, Deepak Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 14.12.10 21:11, Nicholas Miell (nmi...@gmail.com) wrote: On 12/14/2010 07:28 PM, Lennart Poettering wrote: In order to make things secure we minimize what is allowd on the various API file systems we mount. That includes that we set noexec and similar options for the file systems involved. The interface how to access /dev/shm is called shm_open(), and given that this is how it is there is very little reason to allow people to execute binaries from them. Of course, this is a very recent change, and at this point while we assume that this will not break any valid use of this directory, we cannot be sure about this, so we'd be very interested to learn why exactly you want the noexec to be dropped. What is your application that needs that? If there is a point in dropping the noexec, we'll definitely be willing to do so, but if the only reason would be I always misused /dev/shm as a scratch space, then we won't be very convinced. The API fom /dev/shm is shm_open(), and if you place other stuff in there, then you are misusing it and actually creating all kinds of namespacing problems (since /dev/shm is actually an all-user shared namespace), and we aren't particularly keen to support such misuses by default. shm_open() takes the standard mode flags, and mmap() with PROT_EXEC on a +x fd returned by shm_open() is a legitimate operation that is required by POSIX. This is a perfectly reasonable thing to do on a SELinux-enabled system which requires e.g. a JIT to write generated code to the writable mapping and execute that code from the executable mapping of the same shared memory object. These are good and valid points. I have now dropped noexec from the default flags for /dev/shm. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, 16.12.10 22:02, Miloslav Trmač (m...@volny.cz) wrote: Casey Dahlin píše v Čt 16. 12. 2010 v 15:50 -0500: On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote: Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Mirek Measurable != significant. Great programmers and architects have an instinct for something called defect avoidance. You can't measure it, since the unit would be number of bugs/bug-related outages and problems which never happened. Depending on your instincts on what that value might be, cleaner could be the single most important thing to improve in the entire distro. The trouble is that we can't all agree on the immeasurable benefits (but we can probably agree on the existence of the measurable costs), which is why the monster threads about systemd arrive so regularly. Do they? I guess as long as they are only about whether to set noexec on /dev/shm by default then we did quite a few things right, didn't we? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tmpfs != /dev/shm (was Re: noexec on /dev/shm)
On Wed, 15.12.10 08:44, John Reiser (jrei...@bitwagon.com) wrote: I don't think there's a particularly good reason to use that filesystem for other uses. Just mount another tmpfs elsewhere. mount() requires CAP_SYS_ADMIN and therefore an application cannot rely on performing mounts. A major point of this thread is that an application wants to rely on using a file system that is present on all boxes, can be accessed without special permissions or capabilities, and offers very fast performance for small numbers of small-to-medium-sized files. /dev/shm was the best choice until systemd in Fedora 15 rawhide mounted /dev/shm with MS_NOEXEC. Even the preview edition of Ubuntu 11.04 omits the MS_NOEXEC. The appropriate place for this is /tmp. /dev/shm always has been an implementation detail of shm_open(), and accessing it directly makes only sense for admins and low-level system tools that are used to manage shared memory areas. But it is not a generic place to dump arbitrary stuff. The FHS does not offer file systems for all thinkable uses. However, most distributions have subsequently updated its semantics, and depending on your application you might find a more suitable place to place your files. For example, /var/run sounds like it is something you might want to use (if your code is privileged at least), and on more recent distros (including F15) it is actually a tmpfs. Its purpose is that it is used for small files, sockets, fifos that are used for communication between processes and life-cycle management. Newer versions of the XDG basedir spec also specify $XDG_RUNTIME_DIR which offers similar semantics for unprivileged code and whose lifetime is strictly bound to the user being logged in. This is first properly implemented in systemd, and hence will be available properly in F15, too. It too is tmpfs (since it is actually located beneath /var/run). So, in summary: there are places which might be more appropriate for your small files, but /dev/shm is not a good place for it, and never has been. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). /tmp is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack. to be frank I don't really buy this. A FIFO or socket in /tmp should be fine as long as it is opened with O_NOATIME. The data in the fifo buffers or the socket buffers never ever touches the disk and hence it is irrelevant whether it is tmpfs or a real disk. I raise this issue because The API for /dev/shm is shm_open() statement above means to me that in the future there will be no file api access to a ram mounted filesystem in Fedora (I understand that this is my own conclusion, but I can't see any other given the wording of the statement above). Before someone implements that idea, please consider the needs of a filesystem in ram for such uses as those mentioned in this thread (and that is supported by the Fedora distribution by default). Just in case... This too appears to be a good usecase for XDG_RUNTIME_DIR btw. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Mon, 20.12.10 17:26, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: In other words, these are setup costs, not maintenance costs. This may cause glitches in a realtime scenario to the extent that clients are created and destroyed, but in general I submit that the cost of exec() of those new clients is going to dwarf the cost of the inode cache miss for the JACK socket. [2] My experience (caveat: a long time ago, maybe everything has changed internally in both jack and the kernel and that has invalidated my experience cache :-) was that using /tmp would lead to constant - not all the time, but very frequent and not correlated with client connection/disconnection - xruns (glitches in the audio), using /dev/shm would fix that immediately. That was why things were moved over to /dev/shm if I remember correctly. Smells like something related to atime updating. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Mon, 20.12.10 19:16, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: this isn't exactly correct. in /dev/shm on linux we have: (a) unix-domain sockets for non-RT communication with the server (b) FIFOs for RT wakeups (this could use semaphores now) If this uses O_NOATIME it shouldnt matter whether the backing fs is tmpfs or real disk. (c) shared memory created via either the sysv or posix shm API As mentioned by other people too: sysv shm is not placed in /dev/shm. It lives in an independent non-fs namespace. we don't care about the unix domain sockets' performance characteristics, but its convenient to have them in a known location that happens to be close to where (b) is located. we do care about the performance of (b) If O_NOATIME is not the answer to your questions, then you could even pass the fifo fd via the unix socket and have it completely independent of any real fs. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora java png parser issue
On Thu, Dec 23, 2010 at 10:42 PM, Deepak Bhole dbh...@redhat.com wrote: Hi, I have identified the problem. Thanks Deepak for the quick and thorough investigation! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
On Mon, 06.12.10 12:30, Bill Nottingham (nott...@redhat.com) wrote: Michał Piotrowski (mkkp...@gmail.com) said: If systemd will allow us to do that, sure. What's the point here? For example, this doesn't cut down on the number of listening ports, obviously, nor on the requirements for root passwords and potential root login. And if it's started in parallel, I doubt it's a huge drain on resources. For a fast and efficient boot-up two things are crucial: * To start less. * And to start more in parallel. http://0pointer.de/blog/projects/systemd.html IMO start less philosophy is a good thing. Yes. However, I'm leery of adding too many drastic changes that don't have upstream buy-in yet. What's upstream openssh's opinion on socket activation? There's no need to patch ssh. It can do inetd-style socket activation just fine, and has been supporting that upstream since basically its inception. From that I would deduce that upstream is fine with it. systemd supports inetd-style activation too just fine. MacOS X has been installing sshd by default with socket activation enabled, and if they can do that I think we can do that on Fedora, too. (There are cases where socket-activated ssh is not useful, and you want the real-deal with sshd listening itself, but that shouldn't stop us from installing sshd socket-activated by default, since it is easy to switch back to the traditional way.) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Help identifying bugzilla component
On Thu, 23 Dec 2010 18:08:14 +0100, gia...@gmail.com gia...@gmail.com wrote: Can anyone help finding which component is right for: https://bugzilla.redhat.com/show_bug.cgi?id=665413 thanks in advance xorg-x11-drv-synaptics bug, I've reassigned to me. this bug is still present upstream, so if you could file a bug upstream, that'd be much appreciated. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Version-Requirements] - 661697 rebuild for fixing problems with vendorach/lib
commit af55fc5af04e942f8b6f8d4aee76d4e32457fbe7
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:25:30 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Version-Requirements.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Version-Requirements.spec b/perl-Version-Requirements.spec
index f84f46d..eb0f207 100644
--- a/perl-Version-Requirements.spec
+++ b/perl-Version-Requirements.spec
@@ -1,6 +1,6 @@
Name: perl-Version-Requirements
Version:0.101020
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Set of version requirements for a CPAN dist
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.101020-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.101020-2
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Want] - 661697 rebuild for fixing problems with vendorach/lib
commit e24d424207d3b440f83a977a7319107f0df4875c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:31:20 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Want.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Want.spec b/perl-Want.spec
index ff816ec..6de58d2 100644
--- a/perl-Want.spec
+++ b/perl-Want.spec
@@ -1,6 +1,6 @@
Name: perl-Want
Version: 0.18
-Release: 6%{?dist}
+Release: 7%{?dist}
Summary: Perl module implementing a generalisation of wantarray
License: GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.18-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.18-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WebService-Validator-CSS-W3C] - 661697 rebuild for fixing problems with vendorach/lib
commit d1394f804dd92816ae106674688c2fbba5ac9c18
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:36:29 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WebService-Validator-CSS-W3C.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WebService-Validator-CSS-W3C.spec
b/perl-WebService-Validator-CSS-W3C.spec
index aabec2d..02d3d70 100644
--- a/perl-WebService-Validator-CSS-W3C.spec
+++ b/perl-WebService-Validator-CSS-W3C.spec
@@ -1,6 +1,6 @@
Name: perl-WebService-Validator-CSS-W3C
Version:0.2
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Interface to the W3C CSS Validator
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.2-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.2-5
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WebService-Validator-HTML-W3C] - 661697 rebuild for fixing problems with vendorach/lib
commit 089e34341b8bbfcce727a0e9194bec7c822e926b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:42:15 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WebService-Validator-HTML-W3C.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WebService-Validator-HTML-W3C.spec
b/perl-WebService-Validator-HTML-W3C.spec
index cbd7dd8..f2426d0 100644
--- a/perl-WebService-Validator-HTML-W3C.spec
+++ b/perl-WebService-Validator-HTML-W3C.spec
@@ -1,6 +1,6 @@
Name: perl-WebService-Validator-HTML-W3C
Version:0.26
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Access the W3Cs online HTML validator
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.26-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Wed Sep 22 2010 Petr Pisar ppi...@redhat.com - 0.26-2
- Test PODs
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Workflow] - 661697 rebuild for fixing problems with vendorach/lib
commit 85a36fea19f5ec56ac9a341fef8cdf65a5f586c0
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:47:11 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Workflow.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Workflow.spec b/perl-Workflow.spec
index 37ac0d2..eebc948 100644
--- a/perl-Workflow.spec
+++ b/perl-Workflow.spec
@@ -1,6 +1,6 @@
Name: perl-Workflow
Version:1.32
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Simple, flexible system to implement workflows
License:GPL+ or Artistic
Group: Development/Libraries
@@ -98,6 +98,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 1.32-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.32-4
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WWW-Babelfish] - 661697 rebuild for fixing problems with vendorach/lib
commit 4678dba7db19f5e0ff27ca2b182e3abae0018cb9
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:53:18 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WWW-Babelfish.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WWW-Babelfish.spec b/perl-WWW-Babelfish.spec
index 0cc64f7..4be0037 100644
--- a/perl-WWW-Babelfish.spec
+++ b/perl-WWW-Babelfish.spec
@@ -1,6 +1,6 @@
Name: perl-WWW-Babelfish
Version:0.16
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Perl extension for translation via Babelfish or Google
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.16-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.16-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WWW-Bugzilla] - 661697 rebuild for fixing problems with vendorach/lib
commit f11b58cd2e71c62d56f3aa74ffaddf08aa2f1328
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 13:59:00 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WWW-Bugzilla.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WWW-Bugzilla.spec b/perl-WWW-Bugzilla.spec
index 7d886ea..36511fa 100644
--- a/perl-WWW-Bugzilla.spec
+++ b/perl-WWW-Bugzilla.spec
@@ -6,7 +6,7 @@
Name: perl-WWW-Bugzilla
Version:0.9
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Handles submission/update of bugzilla bugs via WWW::Mechanize
Group: Development/Libraries
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.9-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.9-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WWW-Mechanize-GZip] - 661697 rebuild for fixing problems with vendorach/lib
commit 3f9cfdfb8dd2fd55b40f054d20d29483c081f3ad
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 14:04:39 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WWW-Mechanize-GZip.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WWW-Mechanize-GZip.spec b/perl-WWW-Mechanize-GZip.spec
index d0550a2..a8b2b75 100644
--- a/perl-WWW-Mechanize-GZip.spec
+++ b/perl-WWW-Mechanize-GZip.spec
@@ -1,6 +1,6 @@
Name: perl-WWW-Mechanize-GZip
Version:0.12
-Release:3%{?dist}
+Release:4%{?dist}
# lib/WWW/Mechanize/GZip.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
@@ -63,6 +63,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.12-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.12-3
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WWW-Mechanize-TreeBuilder] - 661697 rebuild for fixing problems with vendorach/lib
commit e6bc546caea2fde5b8bbe3ddaba182b50b60324e
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 14:10:31 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WWW-Mechanize-TreeBuilder.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WWW-Mechanize-TreeBuilder.spec
b/perl-WWW-Mechanize-TreeBuilder.spec
index 247e3e1..520b18a 100644
--- a/perl-WWW-Mechanize-TreeBuilder.spec
+++ b/perl-WWW-Mechanize-TreeBuilder.spec
@@ -1,6 +1,6 @@
Name: perl-WWW-Mechanize-TreeBuilder
Version:1.10003
-Release:1%{?dist}
+Release:2%{?dist}
Summary:WWW::Mechanize::TreeBuilder Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 1.10003-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat Sep 25 2010 Iain Arnell iarn...@gmail.com 1.10003-1
- update to latest upstream
- clean up spec for modern rpmbuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-WWW-Myspace] - 661697 rebuild for fixing problems with vendorach/lib
commit f6a68978abac2f466f5de28ab11846b542b5fdf9
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 14:15:47 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-WWW-Myspace.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-WWW-Myspace.spec b/perl-WWW-Myspace.spec
index 8009209..e9b03d1 100644
--- a/perl-WWW-Myspace.spec
+++ b/perl-WWW-Myspace.spec
@@ -12,7 +12,7 @@
Name: perl-WWW-Myspace
Version: 0.60
-Release: 6%{?dist}
+Release: 7%{?dist}
Summary: Access your myspace.com profile in Perl!
Group:Development/Libraries
@@ -96,6 +96,9 @@ rm -rf %{buildroot}
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.60-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.60-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-Atom] - 661697 rebuild for fixing problems with vendorach/lib
commit 65e93032cb0e4370b2a41cd2ab29d84f699728d5
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 14:54:00 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-Atom.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-Atom.spec b/perl-XML-Atom.spec
index 193f35a..f56db7d 100644
--- a/perl-XML-Atom.spec
+++ b/perl-XML-Atom.spec
@@ -1,6 +1,6 @@
Name: perl-XML-Atom
Version:0.37
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Atom feed and API implementation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.37-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.37-2
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-DOM] - 661697 rebuild for fixing problems with vendorach/lib
commit 7b107e499aa1af4ad156880812306e07a40b6dee
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 15:05:16 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-DOM.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-DOM.spec b/perl-XML-DOM.spec
index 978b882..f228de0 100644
--- a/perl-XML-DOM.spec
+++ b/perl-XML-DOM.spec
@@ -1,6 +1,6 @@
Name: perl-XML-DOM
Version:1.44
-Release:8%{?dist}
+Release:9%{?dist}
Summary:DOM extension to XML::Parser
Group: Development/Libraries
@@ -65,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 1.44-9
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.44-8
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-DOM-XPath] - 661697 rebuild for fixing problems with vendorach/lib
commit 9307183d75e838bd857f16b89ec904d5143e8c92
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 15:10:40 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-DOM-XPath.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-DOM-XPath.spec b/perl-XML-DOM-XPath.spec
index bdf05c5..4b1633f 100644
--- a/perl-XML-DOM-XPath.spec
+++ b/perl-XML-DOM-XPath.spec
@@ -1,6 +1,6 @@
Name: perl-XML-DOM-XPath
Version:0.14
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Perl extension to add XPath support to XML::DOM, using
XML::XPath engine
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.14-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.14-5
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Wx] - 661697 rebuild for fixing problems with vendorach/lib
commit 2b5fb7b418bbed03a274daf7698763be37dbed2b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 14:33:02 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Wx.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Wx.spec b/perl-Wx.spec
index 5dda54c..c2f7b1f 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -6,7 +6,7 @@
Name: perl-Wx
Version:0.92
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -96,6 +96,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.92-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Wed Jul 14 2010 Dan Horák d...@danny.cz - 0.92-4
- rebuilt against wxGTK-2.8.11-2
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-XPath] - 661697 rebuild for fixing problems with vendorach/lib
commit ffe18815c4db0d5c5315ac179ded6dc4478ed76d
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 17:51:59 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-XPath.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index b310664..0d00e4f 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,6 +1,6 @@
Name: perl-XML-XPath
Version:1.13
-Release:12%{?dist}
+Release:13%{?dist}
Summary:XPath parser and evaluator for Perl
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 1.13-13
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 1.13-12
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-XPathEngine] - 661697 rebuild for fixing problems with vendorach/lib
commit 1f53198adab2fd003832aea1013ab50ef8e4cbbd
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 17:57:47 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-XPathEngine.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-XPathEngine.spec b/perl-XML-XPathEngine.spec
index fd73d1f..8fa437b 100644
--- a/perl-XML-XPathEngine.spec
+++ b/perl-XML-XPathEngine.spec
@@ -1,6 +1,6 @@
Name: perl-XML-XPathEngine
Version:0.12
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Re-usable XPath engine for DOM-like trees
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.12-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.12-4
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XXX] - 661697 rebuild for fixing problems with vendorach/lib
commit ed2e25b599de46376ef5d13566b9bb95e036e4db
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 18:08:28 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XXX.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XXX.spec b/perl-XXX.spec
index 4de288f..ee1fe23 100644
--- a/perl-XXX.spec
+++ b/perl-XXX.spec
@@ -1,6 +1,6 @@
Name: perl-XXX
Version:0.17
-Release:1%{?dist}
+Release:2%{?dist}
Summary:See Your Data in the Nude
License:GPL+ or Artistic
Group: Development/Libraries
@@ -60,6 +60,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.17-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Tue Sep 21 2010 Marcela Maslanova mmasl...@redhat.com - 0.17-1
- 633760 update
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-XQL] - 661697 rebuild for fixing problems with vendorach/lib
commit f1b7e65826e2856225301ebe6dad6dc2c031d181
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 23 18:02:50 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-XML-XQL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-XQL.spec b/perl-XML-XQL.spec
index 5c98307..35b43ef 100644
--- a/perl-XML-XQL.spec
+++ b/perl-XML-XQL.spec
@@ -1,6 +1,6 @@
Name: perl-XML-XQL
Version:0.68
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Perl module for querying XML tree structures with XQL
License:GPL+ or Artistic
Group: Development/Libraries
@@ -62,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT %{__perl_provides}
%{_mandir}/man3/XML::XQL*.3*
%changelog
+* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.68-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.68-10
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File ExtUtils-Depends-0.303.tar.gz uploaded to lookaside cache by steve
A file has been added to the lookaside cache for perl-ExtUtils-Depends: 2aaf6511d697c680368246fa1645beb6 ExtUtils-Depends-0.303.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
