Re: HEADS UP! Ohloh Fedora repositories
Hello! 2010/12/14 Mat Booth fed...@matbooth.co.uk: Sorry for the threadcromancy, but I just checked my Ohloh profile today and it hasn't registered any of my commits since we switched from CVS to Git. Is Ohloh still crushed under the weight of our mighty distro? Yes, it still suffers from its architectural shortcomings. This is a known issue, and new Ohloh team is working on it. Unfortunately it seems that they have a lot of other (more urgent) tasks, so I wouldn't expect resolution of this problem in the nearest future. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RetraceServer security [Re: abrt wishlist]
On 12/14/2010 03:51 AM, Jan Kratochvil wrote: On Thu, 09 Dec 2010 17:10:49 +0100, David Malcolm wrote: Another gratuitous me too, see: https://fedoraproject.org/wiki/Talk:Features/RetraceServer Detailed description: [...] User sends the coredump [...] Do you intend to make it default for Fedora? - not decided yet, but I'm thinking about something user friendly like dialog saying: How do you want to generate the backtrace? 1. Locally (will download XY MB of debuginfo and you need gdb and etc..) 2. I want to use the RS (WARNING!!: will upload the core file which may contain a sensitive data, but provides a better backtrace) 3. I need to ask my older brother, so cancel the reporting ... So far I thought it is not acceptable and in many cases my request in BZ for a core dump was refused by a user due to security concerns. - some people won't send it some will.. When I can't reproduce the bug and user doesn't want to send me the core, then sorry - CLOSED INSUFF_INFO what else can you do? OTOH the system binaries are already provided by the Fedora project and if the retrace server infrastructure has the same security as Koji servers the security level stays the same. - exactly if we want to get user's private data there is many easier ways then to build a server and write a special app for it... But the core definitely won't be uploaded without making sure that user understands what he is about to upload, as we don't want to get under the same critic as one of the well known operating system developer :) Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Nonreponsive maintainer for atop: Kairo Francisco de Araujo
Hello all, Following the nonresponsive package maintainers policy, a new version of atop has been released a couple of months ago but never made it into Fedora, bug report filed (+patch, [1]) 3 weeks ago. Other open bug listed below. [2,3] - Gilboa [1] https://bugzilla.redhat.com/show_bug.cgi?id=657207 [2] https://bugzilla.redhat.com/show_bug.cgi?id=609124 [3] https://bugzilla.redhat.com/show_bug.cgi?id=659629 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help with build failure
gia...@gmail.com wrote, at 12/14/2010 06:50 AM +9:00: Hi all, I'm trying to fix the F15 build failure for gpointing-device-settings reported here: https://bugzilla.redhat.com/show_bug.cgi?id=660864 and I'd need some help to understand what's going on. The main issue was related to a newer gtk version, this one is now fixed. The other one is trickier (at least for me), as the package which is building fine in mock for F14, fails with something like: /usr/bin/ld: .libs/libpointing_device_la-gsd-pointing-device-plugin.o: relocation R_386_GOTOFF against undefined symbol `gsd_mouse_extension_plugin_class_finalize' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status scratch build here: http://koji.fedoraproject.org/koji/getfile?taskID=2661197name=build.log Can anyone help me fix it? This is due to this change in gnome-settings-daemon: http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=0dda56c4462e070 It seems at least you have to define gsd_mouse_extension_plugin_class_finalize(GsdMouseExtensionPluginClass *klass) in modules/gnome-settings-daemon-plugins/gsd-pointing-device-plugin.c Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101214 changes
Compose started at Tue Dec 14 08:15:05 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) esmtp-1.0-6.fc12.x86_64 requires libesmtp.so.5()(64bit) f-spot-0.8.0-5.fc15.x86_64 requires mono(FlickrNet) = 0:2.2.0.0 gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) 1:gnome-bluetooth-moblin-2.91.2-1.fc15.x86_64 requires libmoblin-panel.so.0()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-phone-manager-0.65-8.fc14.x86_64 requires libgnokii.so.5()(64bit) gnome-phone-manager-telepathy-0.65-8.fc14.x86_64 requires libgnokii.so.5()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 moblin-panel-media-0.0.8-0.2.fc13.x86_64 requires libmoblin-panel.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit) padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires libnotify.so.1()(64bit) pidgin-gfire-0.9.2-2.fc15.x86_64 requires libnotify.so.1()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-backend-tools-1.2.74-2.fc15.noarch requires spacewalk-admin = 0:0.1.1-0 sunbird-1.0-0.33.b2pre.fc15.x86_64 requires libnotify.so.1()(64bit) valide-0.7.0-7.20100923bzr557.fc15.i686 requires libvala-0.10.so.0 valide-0.7.0-7.20100923bzr557.fc15.x86_64 requires libvala-0.10.so.0()(64bit) Broken deps for i386 -- beagle-0.3.9-19.fc14.i686 requires libmono.so.0 beagle-0.3.9-19.fc14.i686 requires libmono.so.0(VER_1) cpm-0.23-0.3.beta.fc12.i686 requires libdotconf-1.0.so.0 db4o-7.4-2.fc13.i686 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch
Re: noexec on /dev/shm
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote: the MS_NOEXEC flags is in private systemd fstab, see systemd/src/mount-setup.c: You're not kidding. Could the author of this code (I'm guessing... Lennart?) please explain this extremely bright idea of hard-coding what should be admin-configurable? That's not a very constructive wording. Filing a bug showing your use-case would be helpful. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Mon, Dec 13, 2010 at 09:47:49AM -0600, Garrett Holmstrom wrote: If systemd is going to ignore fstab entries, could we please have the fstab file on newly-installed systems replace the entries that would be ignored with commentary that explains which filesystems will be ignored? That said, this should really be configurable without recompiling the init system. Amen to that. It's crazy to have these things hard-coded into a C program. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500: On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote: the MS_NOEXEC flags is in private systemd fstab, see systemd/src/mount-setup.c: You're not kidding. Could the author of this code (I'm guessing... Lennart?) please explain this extremely bright idea of hard-coding what should be admin-configurable? That's not a very constructive wording. Filing a bug showing your use-case would be helpful. Changing the semantics of /etc/fstab without any consultation with fedora-devel or even notification of Fedora that something so long-standing is changing is hardly constructive either. I can happily live with systemd is a new, better init system without knowing the details. I consider systemd replaces 15% of /etc and changes semantics of another 5% without discussing the details in advance unacceptable for the distribution as a whole, although this decision is of course FESCo's. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: noexec on /dev/shm
I will be away from 14 December 2010 to 7 January 2011. For Translate.org.za and ANLoc queries, please contact the office: +2712 460 1095 or info AT translate.org.za. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote: Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500: On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote: the MS_NOEXEC flags is in private systemd fstab, see systemd/src/mount-setup.c: You're not kidding. Could the author of this code (I'm guessing... Lennart?) please explain this extremely bright idea of hard-coding what should be admin-configurable? That's not a very constructive wording. Filing a bug showing your use-case would be helpful. Changing the semantics of /etc/fstab without any consultation with fedora-devel or even notification of Fedora that something so long-standing is changing is hardly constructive either. I can happily live with systemd is a new, better init system without knowing the details. I consider systemd replaces 15% of /etc and changes semantics of another 5% without discussing the details in advance unacceptable for the distribution as a whole, although this decision is of course FESCo's. Mirek Let's keep discussion calm and technical. “Systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the host name or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys or /proc.” We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? I can see that it may look like taking power from admin, but has anyone ever changed how devpts is mounted? Really? Being able to change for the sake of ability is not always sane. There are things which we can change, and some things which shouldn't be touched by admin. And I'm not proposing dumbing down admin. Back when I run Slackware I rewrote part of the initscripts to suit me. But really, admin should worry about important things, better leave boring (and identical across distros) parts to someone else. Original problem could be solved by configuring some scratch tmpfs in /mnt/scratch or somewhere else. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt wishlist
- Separating machine-generated content from human-generated content is valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain. Good point. ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red warning sign for every unreported crash, green you did good thing sign for reported ones. The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting. It aslo makes sense to allow sending mostly machine-generated, few click crash reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/14/2010 02:24 PM, Tomasz Torcz wrote: On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote: Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500: On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote: the MS_NOEXEC flags is in private systemd fstab, see systemd/src/mount-setup.c: You're not kidding. Could the author of this code (I'm guessing... Lennart?) please explain this extremely bright idea of hard-coding what should be admin-configurable? That's not a very constructive wording. Filing a bug showing your use-case would be helpful. Changing the semantics of /etc/fstab without any consultation with fedora-devel or even notification of Fedora that something so long-standing is changing is hardly constructive either. I can happily live with systemd is a new, better init system without knowing the details. I consider systemd replaces 15% of /etc and changes semantics of another 5% without discussing the details in advance unacceptable for the distribution as a whole, although this decision is of course FESCo's. Mirek Let's keep discussion calm and technical. “Systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the host name or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys or /proc.” We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? I can see that it may look like taking power from admin, but has anyone ever changed how devpts is mounted? Really? Being able to change for the sake of ability is not always sane. There are things which we can change, and some things which shouldn't be touched by admin. And I'm not proposing dumbing down admin. Back when I run Slackware I rewrote part of the initscripts to suit me. But really, admin should worry about important things, better leave boring (and identical across distros) parts to someone else. Original problem could be solved by configuring some scratch tmpfs in /mnt/scratch or somewhere else. The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Usually such change would be discussed before on list and it would be feature for new Fedora. It's not even mentioned on Systemd Feature page. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Safest way to go from x86 to x86_64
Hi, My main box decided to snuff it last week (motherboard and processor decided to fry). My erstwhile friend in the computer shop I use has said that he has a nice 64 bit processor and motherboard going for a small amount of money. The problem I have is that if I go the 64 bit route then I'll need to install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of memory). Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? If I was using f14, I'd just trash the drive and then install, but I've got things how I want them under rawhide. I've not done this before, so advice before I do it would be appreciated. TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Once upon a time, Tomasz Torcz to...@pipebreaker.pl said: We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? What is the advantage to making some mounts not listed in the file with all the other mounts? It isn't like /etc/fstab is a hundred lines or anything; it is a standard config file that predates Linux. All mounts are listed there until systemd decided to override it (without any warning or documentation). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retired package by mistake - undo?
Hello all, While the click-frenzy required to take ownership over spring and its sub packages I mistakably retired spring-maps-default / devel and spring-install / devel. I tried to unretire them both, but failed. Admins, help? - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retired package by mistake - undo?
GD == Gilboa Davara gilb...@gmail.com writes: GD Hello all, While the click-frenzy required to take ownership over GD spring and its sub packages I mistakably retired spring-maps-default GD / devel and spring-install / devel. I tried to unretire them both, GD but failed. You've found one of the worst ways to reach an admin, of course, but I happened to notice your message. I unretired spring-maps-default. I can find no packages named spring-maps-devel, spring-install or spring-devel in pkgdb. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retired package by mistake - undo?
OK, I found spring-installer and unretired it as well. You should log into pkgdb and claim both packages as they're currently orphaned. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt wishlist
On 12/14/2010 02:54 PM, Karel Klic wrote: - Separating machine-generated content from human-generated content is valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain. Good point. ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red warning sign for every unreported crash, green you did good thing sign for reported ones. The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting. - btw, we tried that with making the howto field mandatory and I already saw some reports saying I don't have a damn clue how to reproduce it, but this stupid ABRT thing won't let me continue :)) It aslo makes sense to allow sending mostly machine-generated, few click crash reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now. Karel The problem is, that with ABRT we probably get more people involved in reporting bugs - which I think is great (would be a nice statistic to see if/how the number of new accounts has grown since ABRT) but unlike the older reporters with a good habits these new reporters won't create a good report using neither bz or ABRT... so yes, we need to change the UI to treat the reporters as they (the reporter rookies) deserve.. ABRT GUI should be more like Assisted Bug Reporting for Dummies :)) - ABRD :) J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retired package by mistake - undo?
On Tue, 2010-12-14 at 08:19 -0600, Jason L Tibbitts III wrote: OK, I found spring-installer and unretired it as well. You should log into pkgdb and claim both packages as they're currently orphaned. - J Thanks! - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A GUI tool for Fedora Packagers
On 14 December 2010 03:46, Chris Aniszczyk (zx) z...@redhat.com wrote: The Eclipse team within Red Hat has already developed something called the Eclipse Fedora Packager: http://lists.fedoraproject.org/pipermail/devel/2010-October/144570.html http://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide It's still in beta but essentially does what you describe. At the moment, it integrates within the Eclipse IDE but can be modified to be more standalone if desired. Cheers, I have been using eclipse-fedorapackager for a while now and it works quite well, thanks for the effort that has gone into it. My life revolves around Eclipse at my day job so using this plug-in wasn't a leap, but I've found that many people who aren't developers find Eclipse quite an overly large and intimidating product so maybe a little RCP app would be quite neat for people who don't need a full blown IDE. :-) -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Marcela Mašláňová píše v Út 14. 12. 2010 v 14:55 +0100: On 12/14/2010 02:24 PM, Tomasz Torcz wrote: On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote: Changing the semantics of /etc/fstab without any consultation with fedora-devel or even notification of Fedora that something so long-standing is changing is hardly constructive either. I can happily live with systemd is a new, better init system without knowing the details. I consider systemd replaces 15% of /etc and changes semantics of another 5% without discussing the details in advance unacceptable for the distribution as a whole, although this decision is of course FESCo's. Mirek Let's keep discussion calm and technical. “Systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the host name or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys or /proc.” We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? I can see that it may look like taking power from admin, but has anyone ever changed how devpts is mounted? Really? Being able to change for the sake of ability is not always sane. There are things which we can change, and some things which shouldn't be touched by admin. And I'm not proposing dumbing down admin. Back when I run Slackware I rewrote part of the initscripts to suit me. But really, admin should worry about important things, better leave boring (and identical across distros) parts to someone else. Original problem could be solved by configuring some scratch tmpfs in /mnt/scratch or somewhere else. The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Usually such change would be discussed before on list and it would be feature for new Fedora. It's not even mentioned on Systemd Feature page. +1 This is (was?) UNIX. No single person knows about all the creative and important ways that users have configured the system to suit their needs. Dropping system-wide features should be a conscious decision, not something we accidentally discover several months later when user complaints start to come in. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote: We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? The issue here isn't that the reporter wanted to mount them somewhere else, but he wanted to set the default mount options to something else (or in fact to set them back to how they are now -- systemd has decided to use some other mount options entirely without consulting anyone else). I think it's very reasonable to want to edit /etc/fstab to change the default mount options of these filesystems. Suppose that /dev/shm defaults to allowing suid and exec. At some point in the future a security problem is found which can be worked around by temporarily setting nosuid on /dev/shm (while the real issue is fixed). An administrator can't do that without recompiling systemd. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote: Hi, My main box decided to snuff it last week (motherboard and processor decided to fry). My erstwhile friend in the computer shop I use has said that he has a nice 64 bit processor and motherboard going for a small amount of money. The problem I have is that if I go the 64 bit route then I'll need to install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of memory). Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? If I was using f14, I'd just trash the drive and then install, but I've got things how I want them under rawhide. Not really. I would definitely suggest that you reinstall. I've been using x86-64 machines routinely for 6 years now, and they are better in every way than i386. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
tis 2010-12-07 klockan 19:20 -0500 skrev Doug Ledford: For non-boot devices, loopback works. You only need the hardware if you are testing boot time capabilities (which, admittedly, is the far more important aspect of testing for this package). And if you don't have spare systems with more than one drive to play around with then kvm virtualization comes to the rescue when testing pretty much any md or dm issue, possibly even including multipath. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
Hi, On 14 December 2010 14:27, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote: Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? If I was using f14, I'd just trash the drive and then install, but I've got things how I want them under rawhide. Not really. I would definitely suggest that you reinstall. I thought that would be the case - just wanted to check to ensure it's not something I can do another way. Okay, let's try another. Is there a way to grab a list of the packages installed and use a network installer to do the job based on the list? TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
On Tue, 2010-12-14 at 14:35 +, Paul Johnson wrote: Hi, On 14 December 2010 14:27, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote: Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? If I was using f14, I'd just trash the drive and then install, but I've got things how I want them under rawhide. Not really. I would definitely suggest that you reinstall. I thought that would be the case - just wanted to check to ensure it's not something I can do another way. Okay, let's try another. Is there a way to grab a list of the packages installed and use a network installer to do the job based on the list? sure - kickstart does just that. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
On Tue, Dec 14, 2010 at 02:35:24PM +, Paul Johnson wrote:
Hi,
On 14 December 2010 14:27, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
Is there a safe way to install the x86_64 system over the 32 bit version
and
then clean off the 32 bit stuff that is no longer needed? If I was using
f14, I'd just trash the drive and then install, but I've got things how I
want them under rawhide.
Not really. I would definitely suggest that you reinstall.
I thought that would be the case - just wanted to check to ensure it's not
something I can do another way.
Okay, let's try another. Is there a way to grab a list of the packages
installed and use a network installer to do the job based on the list?
I guess you can do:
rpm -qa --qf '%{name}\n' kickstart
and try to construct a kickstart file out of that ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
ons 2010-12-08 klockan 11:41 + skrev Peter Robinson: It was my understanding that abrt was suppose to block on backtraces without debuginfo but I still regularly get bugs with little or no decent info. True. I accidently filed a such abrt report some time ago. I assumed it would fetch the needed debug info as I am used to but for some reason it did not. What's worse is often they are the first report and abrt de-dupes against that report and still doesn't automatically either update the backtrace with a complete one from other reports or attach a new one. Yes, that slowed down processing of the above bug quite a lot. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: End of life in bugzilla, how to reopen?
tis 2010-12-07 klockan 20:53 +0100 skrev Andreas Tunek: Shouldn't the end of life message reflect that then? It should tell me to contact a bug zapper to move the bug report. I think the reporter can move the bug report as well. At least I have a memory of doing so on some of the bugs I have filed earlier. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
tis 2010-12-07 klockan 10:20 -0800 skrev Jesse Keating: While I'm looking into the git setup and ACLs and all this, I have a question. Is anybody seeing any real value of having different commit ACLs per Fedora branch? I've seen some argument for EPEL vs Fedora, but is there real value in ACLs for f13, f14, devel, etc...? Can't see any. The only use I see is to allow people to indicate retirement and show a record of I did maintain in earlier Fedora releases but no longer, but that info is much better displayed by other means than the acl memberships. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 14 Dec 2010, Tomasz Torcz wrote: We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? Because the system is meant to be changable by people. What if 20 years ago people had harcoded /usr and /var because they knew best? Things change over time and the unix philosphy is to allow that. The other thing is that options where possible should be in human readable format to make understanding and changing it easier. /etc/fstab sure beats some hardcoded binary. You are reversing the logic. Keep the system flexible and transparent. The less we put hardcoded inside the kernel, initrd, pivot root, dracut, linuxrc or systemd the better. It is easier to change a config line then to recompile software. Don't assume you can speak for everyone with your use cases. Original problem could be solved by configuring some scratch tmpfs in /mnt/scratch or somewhere else. the original problem i think was more I dont understand why my fstab seems to be acting up. The fstab file itself provides valuable documentation of implicit values. Even if I never change it, I use it. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Affix-Infix2Postfix] - 661697 rebuild for fixing problems with vendorach/lib
commit 784c308f8216f1335a1aac53cb4f4b47dafdd566
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 17:04:42 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Affix-Infix2Postfix.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Affix-Infix2Postfix.spec b/perl-Affix-Infix2Postfix.spec
index 2f5c3b5..d886279 100644
--- a/perl-Affix-Infix2Postfix.spec
+++ b/perl-Affix-Infix2Postfix.spec
@@ -1,6 +1,6 @@
Name: perl-Affix-Infix2Postfix
Version:0.03
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Perl extension for converting from infix notation to postfix
notation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-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
[perl-Algorithm-Annotate] - 661697 rebuild for fixing problems with vendorach/lib
commit fb677232a6c9fb67b9a19f36dbca83021eec4bac
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 17:09:38 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Algorithm-Annotate.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-Annotate.spec b/perl-Algorithm-Annotate.spec
index 7d3241d..a79176b 100644
--- a/perl-Algorithm-Annotate.spec
+++ b/perl-Algorithm-Annotate.spec
@@ -1,6 +1,6 @@
Name: perl-Algorithm-Annotate
Version:0.10
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Represent a series of changes in annotate form
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.10-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.10-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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: abrt wishlist
On 12/14/2010 05:14 PM, Jaroslav Reznik wrote: On Tuesday, December 14, 2010 03:19:32 pm Jiri Moskovcak wrote: On 12/14/2010 02:54 PM, Karel Klic wrote: - Separating machine-generated content from human-generated content is valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain. Good point. ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red warning sign for every unreported crash, green you did good thing sign for reported ones. The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting. - btw, we tried that with making the howto field mandatory and I already saw some reports saying I don't have a damn clue how to reproduce it, but this stupid ABRT thing won't let me continue :)) Educate people that such bug report is just useless as usually it is. How? Maybe I just don't understand, but if there is a way how to autodetect that the user input is useless then we'll add it, but analyse the text and try to guess if it's useless or not is really not trivial... J. R. It aslo makes sense to allow sending mostly machine-generated, few click crash reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now. Karel The problem is, that with ABRT we probably get more people involved in reporting bugs - which I think is great (would be a nice statistic to see if/how the number of new accounts has grown since ABRT) but unlike the older reporters with a good habits these new reporters won't create a good report using neither bz or ABRT... so yes, we need to change the UI to treat the reporters as they (the reporter rookies) deserve.. ABRT GUI should be more like Assisted Bug Reporting for Dummies :)) - ABRD :) J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
On Tue, 2010-12-14 at 14:07 +, Paul Johnson wrote: Hi, My main box decided to snuff it last week (motherboard and processor decided to fry). My erstwhile friend in the computer shop I use has said that he has a nice 64 bit processor and motherboard going for a small amount of money. The problem I have is that if I go the 64 bit route then I'll need to install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of memory). Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? I did that to my Fedora 11 system in October 2009. It took a significant amount of manual work and scripting and I hit a number of minor issues. I'm not sure I would call the procedure safe, but it did work. The procedure was like this: - Change /etc/rpm/platform to x86_64-redhat-linux and put %_transaction_color 3 in /etc/rpm/macros . - Install the x86_64 kernel and boot to it. - Install the x86_64 version of rpm. - Construct a yum script with install lines for the x86_64 versions of all installed packages. Repeatedly try to run the script and add erase lines for any i?86 packages that cause file conflicts until it succeeds. - Watch the output. When scriptlets fail, fix things manually. - Remove all unneeded i?86 packages. I needed to keep a few proprietary packages that are only available for i?86, so I used a script to walk the dependencies and figure out which i?86 packages could be removed. YMMV with rawhide. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Problem using winsync API
On 12/13/2010 12:45 AM, Carsten Grzemba wrote: I found the reason: In winsync-plugin.h in the plugin config is defined a dependenciy for multi-master plugin. This seems to be wrong, because a Winsync plugin must already be registered when the multi-master plugin starts. I.e. the dependency should be reversed. The multi-master Plugin depends on the Winsync plugin. I have removed nsslapd-plugin-depends-on-named: Multimaster Replication Plugin from the plugin configuration, and instead added the Multimaster Plugin config nsslapd-plugin-depends-on-named: test Winsync API Then, the Winsync plugin is loaded also if start / restart the directory server. Can you review this? Could you supply your plug-in code? You need to be calling slapi_apib_register() to register your API in your plug-in's init() function. I'm curious to see if you are doing this in the init() callback, or in the start() callback. -NGK Regards - Ursprüngliche Nachricht - Von: Rich Megginsonrmegg...@redhat.com Datum: Samstag, 11. Dezember 2010, 0:59 Betreff: Re: [389-devel] Problem using winsync API An: 389-de...@lists.fedoraproject.org On 12/08/2010 05:17 AM, Carsten Grzemba wrote: - Ursprüngliche Nachricht - Von: Carsten Grzembagrze...@contac-dt.de Datum: Mittwoch, 8. Dezember 2010, 11:16 Betreff: [389-devel] Problem using winsync API An: 389 Directory server developer discussion.389-de...@lists.fedoraproject.org I try to use the Winsync API. The _winsync_plugin_init and _winsync_plugin_start functions are called, but apparently not correctly registered. If the actual functions should be called, nothing happens. Debbuging shows the pointer thefunc in windows_private.c functions is NIL. it works only after the creation of an winsync replication agreement. After restart the directoryserver only _winsync_plugin_init and _winsync_plugin_start are called. So is there still a problem? Does anyone know why this is? Thanks Carsten -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: noexec on /dev/shm
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote: I think it's very reasonable to want to edit /etc/fstab to change the default mount options of these filesystems. Suppose that /dev/shm defaults to allowing suid and exec. At some point in the future a security problem is found which can be worked around by temporarily setting nosuid on /dev/shm (while the real issue is fixed). An administrator can't do that without recompiling systemd. I'm not sure there's a win in having systemd do magic rather than just using fstab -- reminds me of IRIX and its auto-mounting of some but not all swap partitions. (Yay newbie admin confusion!) But if there's a good technical reason, it still seems reasonable to let /etc/fstab override the defaults. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Marcela Mašláňová (mmasl...@redhat.com) said: That's not a very constructive wording. Filing a bug showing your use-case would be helpful. I'd like to restate this point. It's rather disappointing that so many people have decided to skip over this, and prefer to instead complain, insinuate, and argue on list rather than starting with this simple, more likely to be productive, action. The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get mounted. When this was done in rc.sysinit, every change to how it mounted /proc wasn't discussed on the devel list. When we switched to having dracut be the primary way that API filesystems are mounted, that wasn't put up to a FESCo vote. And it's also not fair to say that 'Fedora developers' aren't involved; heck, there's at least 10 of them on the systemd mailing list, by a quick count. If you mean, it wasn't posted to devel@, or it wasn't brought to FESCo, well, we don't review every change to upstream packages in this way... if we did, we'd be drowned in minutiae. I mean, I could have brought the addition on how to add multiple IPv4 addresses to interfaces to FESCo for discussion and vote, but I've got better things to do with my time. In any case, I'm pretty sure it's not even intentional. systemd has two areas of mounting: - systemd mounts API filesystems without them needing to be in /etc/fstab. This is for a variety of reasons - having every system installer have to write /proc, /sys, and so on is pretty wasteful. It also can give inexperienced admins the idea that it's configuration that can be changed - they then rename the mount point from /proc to /processes and *kaboom*. - systemd mounts system filesystems from /etc/fstab. This includes mount options, etc., and (I'd think) would be fairly uncontroversial. The first of these happens before the second (as you obviously need /proc, /sys, etc. very early), however systemd already has /lib/systemd/system/systemd-remount-api-vfs.service: ... [Unit] Description=Remount API VFS ... ExecStart=/lib/systemd/systemd-remount-api-vfs ... And if you look at that code: /* Goes through /etc/fstab and remounts all API file systems, applying * options that are in /etc/fstab that systemd might not have * respected */ So, it just looks like an ordinary bug. File it, we can get it fixed, and we can all live happily ever after. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 662811] perl-CSS-DOM-0.14 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=662811 Ville Skyttä ville.sky...@iki.fi changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||0.14-1 Resolution||RAWHIDE Last Closed||2010-12-14 12:08:37 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500: The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get mounted. When this was done in rc.sysinit, every change to how it mounted /proc wasn't discussed on the devel list. When we switched to having dracut be the primary way that API filesystems are mounted, that wasn't put up to a FESCo vote. The practical difference is that nothing broke at that time, whereas systemd tends to break thinks that users use. (I won't buy dismissing it as mere bugs - adding NOEXEC could hardly have been a typo.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 663069] Wrong charset in graph.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=663069 Vojtech Vitek vvi...@redhat.com changed: What|Removed |Added Version|6.3 |el6 Component|zip |rt3 CC||fedora-perl-devel-l...@redh ||at.com, mma...@redhat.com, ||trem...@tremble.org.uk, ||xav...@bachelot.org AssignedTo|vvi...@redhat.com |xav...@bachelot.org QAContact|qe-baseos-a...@redhat.com |extras...@fedoraproject.org Target Milestone|rc |--- Product|Red Hat Enterprise Linux 6 |Fedora EPEL -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 12/14/10 9:22 AM, Miloslav Trmač wrote: Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500: The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get mounted. When this was done in rc.sysinit, every change to how it mounted /proc wasn't discussed on the devel list. When we switched to having dracut be the primary way that API filesystems are mounted, that wasn't put up to a FESCo vote. The practical difference is that nothing broke at that time, whereas systemd tends to break thinks that users use. (I won't buy dismissing it as mere bugs - adding NOEXEC could hardly have been a typo.) Mirek Perhaps you missed the part where the bug was that the fs doesn't get remounted with the perms from fstab as by design. That's the bug. Lets have a little less chest pounding and a little more constructive discussion, mkay? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Please review: [Bug 182507] clear-password mod from replica is discarded before changelogged
Hi Andrey, Andrey Ivanov wrote: Hi Noriko, i've read the changelog encryption design document. Indeed, it's a sound idea to make AD-389 replication more robust. I have two questions about it: * if i understand correctly you say that the server needs a certificate in order to generate the symmetric key. Is this key generated only once? That is correct. If a wrapped symmetric key is not found in cn=changelog5,cn=config, the key is generated. I mean, if we change the expired server certificate it won't trigger the symmetric key regeneration? That's tricky. If your changelog DB contains 2 sets of encrypted value -- one is encrypted with the expired cert, the other with the new cert, it'd be hard to recover old ones. Automation makes it happen easier... * The replication changelog that contains the mixed entries (cleartext, encrypted 3DES, encrypted AES etc) - is it still readable by the server? I don't think so. We should avoid it, too. Does each changelog entry contain a flag that describes whether the entry is cleartext/AES/3DES? Can the server detect in any other way whether the changelog entry is encrypted and if yes with what type of cypher? The answer is no. Each value has no info about the type -- cleartext/AES/3DES. Thanks for the questions, Andrey! --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Broken dependencies: rt3
rt3 has broken dependencies in the epel-6 tree: On x86_64: perl-RT-Test-3.8.8-2.el6.noarch requires perl(Test::Email) On i386: perl-RT-Test-3.8.8-2.el6.noarch requires perl(Test::Email) On ppc64: perl-RT-Test-3.8.8-2.el6.noarch requires perl(Test::Email) Please resolve this as soon as possible. -- 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
File MLDBM-2.04.tar.gz uploaded to lookaside cache by steve
A file has been added to the lookaside cache for perl-MLDBM: b2793c419136fc11082e1ed1b564aeff MLDBM-2.04.tar.gz -- 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
Once upon a time, Bill Nottingham nott...@redhat.com said: having every system installer have to write /proc, /sys, and so on is pretty wasteful. I've seen this said at least a couple of times. In what way is it wasteful? On most systems, /etc/fstab is going to be less than one filesystem block anyway, so there is absolutely zero waste going on. If waste of a few dozen bytes is now an issue, /etc/fstab is hardly the place to start. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Jesse Keating píše v Út 14. 12. 2010 v 09:47 -0800: On 12/14/10 9:22 AM, Miloslav Trmač wrote: Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500: The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get mounted. When this was done in rc.sysinit, every change to how it mounted /proc wasn't discussed on the devel list. When we switched to having dracut be the primary way that API filesystems are mounted, that wasn't put up to a FESCo vote. The practical difference is that nothing broke at that time, whereas systemd tends to break thinks that users use. (I won't buy dismissing it as mere bugs - adding NOEXEC could hardly have been a typo.) Perhaps you missed the part where the bug was that the fs doesn't get remounted with the perms from fstab as by design. That's the bug. So the design was to 1) change the setting in the C reimplementation 2) add a new facility that will revert the setting to its original value ? Is it really surprising that I'd like more discussion of the systemd design in advance? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-AnyEvent
perl-AnyEvent has broken dependencies in the epel-6 tree: On x86_64: perl-AnyEvent-5.27-1.el6.noarch requires perl(Event::Lib) perl-AnyEvent-5.27-1.el6.noarch requires perl(IO::Async::Handle) On i386: perl-AnyEvent-5.27-1.el6.noarch requires perl(Event::Lib) perl-AnyEvent-5.27-1.el6.noarch requires perl(IO::Async::Handle) On ppc64: perl-AnyEvent-5.27-1.el6.noarch requires perl(Event::Lib) perl-AnyEvent-5.27-1.el6.noarch requires perl(IO::Async::Handle) Please resolve this as soon as possible. -- 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-MLDBM] Update to 2.04. Fix find option order. Use fixperms macro instead of our own chmod incantation. Upda
commit 6823491fc52c52cd1ff5e2257e46079e4428f37d
Author: Steven Pritchard steven.pritch...@gmail.com
Date: Tue Dec 14 12:37:31 2010 -0600
Update to 2.04.
Fix find option order.
Use fixperms macro instead of our own chmod incantation.
Update Source0 URL.
Minor cosmetic changes to resemble cpanspec output.
BR Module::Build and build with that.
BR Test::More.
.gitignore |1 +
perl-MLDBM.spec | 52 +++-
sources |2 +-
3 files changed, 29 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e688f60..efe2de9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
MLDBM-2.01.tar.gz
+/MLDBM-2.04.tar.gz
diff --git a/perl-MLDBM.spec b/perl-MLDBM.spec
index 4dee830..149fd03 100644
--- a/perl-MLDBM.spec
+++ b/perl-MLDBM.spec
@@ -1,59 +1,61 @@
Name: perl-MLDBM
-Version:2.01
-Release:10%{?dist}
+Version:2.04
+Release:1%{?dist}
Summary:Store multi-level hash structure in single level tied hash
-
-Group: Development/Libraries
License:GPL+ or Artistic
+Group: Development/Libraries
URL:http://search.cpan.org/dist/MLDBM/
-Source0:
http://www.cpan.org/authors/id/C/CH/CHAMAS/MLDBM-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/MLDBM-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(FreezeThaw)
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
-This module can serve as a transparent interface to any TIEHASH package that is
-required to store arbitrary perl data, including nested references. Thus, this
-module can be used for storing references and other arbitrary data within DBM
-databases.
-
+This module can serve as a transparent interface to any TIEHASH package
+that is required to store arbitrary perl data, including nested references.
+Thus, this module can be used for storing references and other arbitrary
+data within DBM databases.
%prep
%setup -q -n MLDBM-%{version}
-
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
-
+%{__perl} Build.PL installdirs=vendor
+./Build
%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 -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-%check
-make test
+%{_fixperms} $RPM_BUILD_ROOT/*
+%check
+./Build test
%clean
rm -rf $RPM_BUILD_ROOT
-
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
-%{_mandir}/man3/*.3pm*
-
+%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Steven Pritchard st...@kspei.com 2.04-1
+- Update to 2.04.
+- Fix find option order.
+- Use fixperms macro instead of our own chmod incantation.
+- Update Source0 URL.
+- Minor cosmetic changes to resemble cpanspec output.
+- BR Module::Build and build with that.
+- BR Test::More.
+
* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 2.01-10
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 6cbedf4..6426bfb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-99550ae2cffbc0bb3eb0358631077c10 MLDBM-2.01.tar.gz
+b2793c419136fc11082e1ed1b564aeff MLDBM-2.04.tar.gz
--
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: Safest way to go from x86 to x86_64
On 12/14/10 6:46 AM, Richard W.M. Jones wrote:
On Tue, Dec 14, 2010 at 02:35:24PM +, Paul Johnson wrote:
Hi,
On 14 December 2010 14:27, Richard W.M. Jonesrjo...@redhat.com wrote:
On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
Is there a safe way to install the x86_64 system over the 32 bit version
and
then clean off the 32 bit stuff that is no longer needed? If I was using
f14, I'd just trash the drive and then install, but I've got things how I
want them under rawhide.
Not really. I would definitely suggest that you reinstall.
I thought that would be the case - just wanted to check to ensure it's not
something I can do another way.
Okay, let's try another. Is there a way to grab a list of the packages
installed and use a network installer to do the job based on the list?
I guess you can do:
rpm -qa --qf '%{name}\n' kickstart
and try to construct a kickstart file out of that ...
Rich.
Also, use rpm -Va to get a list of config files that have been modified.
Unfortunately, there's no way to detect additional files (in /etc, etc) that
aren't owned by a package but represent additional configuration state you
might want to bring over.
I usually make a copy of config files (cp -p $file $file.orig) before I edit
them the first time... then just do locate .orig to find them all.
-Philip
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Chris Adams (cmad...@hiwaay.net) said: I've seen this said at least a couple of times. In what way is it wasteful? On most systems, /etc/fstab is going to be less than one filesystem block anyway, so there is absolutely zero waste going on. If waste of a few dozen bytes is now an issue, /etc/fstab is hardly the place to start. The waste is the code in anaconda that's required to write this on every install. Then, if new filesystems are added between releases, you need to 1) patch anaconda 2) have truly gross %post scripts to edit /etc/fstab, or 3) you write code that just hardcodes the mount anyway. And again, listing things like /sys in fstab can just give the uninitiated the idea that it's something they can change... it's *not* a configuration setting. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Safest way to go from x86 to x86_64
On Tue, 2010-12-14 at 10:47 -0800, Philip Prindeville wrote:
On 12/14/10 6:46 AM, Richard W.M. Jones wrote:
On Tue, Dec 14, 2010 at 02:35:24PM +, Paul Johnson wrote:
Hi,
On 14 December 2010 14:27, Richard W.M. Jonesrjo...@redhat.com wrote:
On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
Is there a safe way to install the x86_64 system over the 32 bit version
and
then clean off the 32 bit stuff that is no longer needed? If I was using
f14, I'd just trash the drive and then install, but I've got things how I
want them under rawhide.
Not really. I would definitely suggest that you reinstall.
I thought that would be the case - just wanted to check to ensure it's not
something I can do another way.
Okay, let's try another. Is there a way to grab a list of the packages
installed and use a network installer to do the job based on the list?
I guess you can do:
rpm -qa --qf '%{name}\n' kickstart
and try to construct a kickstart file out of that ...
Rich.
Also, use rpm -Va to get a list of config files that have been modified.
Unfortunately, there's no way to detect additional files (in /etc, etc) that
aren't owned by a package but represent additional configuration state you
might want to bring over.
I usually make a copy of config files (cp -p $file $file.orig) before I edit
them the first time... then just do locate .orig to find them all.
Sure you can:
for file in `find /etc`
do
rpm -qf $file /dev/null
if [ $? != 0 ]; then
echo $file unowned
fi
done
-sv
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Miloslav Trmač (m...@volny.cz) said: So the design was to 1) change the setting in the C reimplementation The design was to pick a default... it's actually been that way since the initial implementation and that *is* the default on some other distributions. It probably should be relnoted, sure. 2) add a new facility that will revert the setting to its original value No, the facility is intended to apply fstab settings to any early mounted filesystem, including filesystems mounted in initramfs, etc. This is actually something that didn't exist before - for example, in earlier Fedora releases, for some filesystems you were stuck with whatever options rc.sysinit or dracut mounted them with, regardless of what's in /etc/fstab. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-12-15)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:30UTC (12:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #508 improve the general standard of packagers/maintainers in the distribution. https://fedorahosted.org/fesco/ticket/508 #515 Investigate a features repo for stable releases https://fedorahosted.org/fesco/ticket/515 #516 Updates policy adjustments/changes https://fedorahosted.org/fesco/ticket/516 #517 Updates Metrics https://fedorahosted.org/fesco/ticket/517 = New business = #518 Abrt https://fedorahosted.org/fesco/ticket/518 #521 Reconsider RemoveSUID feature https://fedorahosted.org/fesco/ticket/521 #522 F15Feature: GCC46 - http://fedoraproject.org/wiki/Features/GCC46 https://fedorahosted.org/fesco/ticket/522 #523 F15Feature: XenPvopsDom0 - http://fedoraproject.org/wiki/Features/XenPvopsDom0 https://fedorahosted.org/fesco/ticket/523 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 2010-12-14 at 13:48 -0500, Bill Nottingham wrote: And again, listing things like /sys in fstab can just give the uninitiated the idea that it's something they can change... it's *not* a configuration setting. But I want to mount my /sys over nfs! What do you mean, it's not going to work? Make it! -- 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: noexec on /dev/shm
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote: On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote: We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? The issue here isn't that the reporter wanted to mount them somewhere else, but he wanted to set the default mount options to something else (or in fact to set them back to how they are now -- systemd has decided to use some other mount options entirely without consulting anyone else). I think it's very reasonable to want to edit /etc/fstab to change the default mount options of these filesystems. Suppose that /dev/shm defaults to allowing suid and exec. At some point in the future a security problem is found which can be worked around by temporarily setting nosuid on /dev/shm (while the real issue is fixed). An administrator can't do that without recompiling systemd. Of course administrator can temporary override: mount /dev/shm -o remount, nosuid Or even have it stick after reboot, by droping in /etc/systemd/system/ following unit definition¹: -- [Unit] Description=Temporary workaround for CVE-x DefaultDependencies=false WantedBy=local-fs.target [Service] ExecStart=/bin/mount /dev/shm -o remount, nosuid Type=oneshot -- While I agree that hidden mounts are bad idea, they're still visible in systemctl -t mount and findmnt output. ¹ created ad-hoc to show idea, not tested -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 14 Dec 2010, Tomasz Torcz wrote: Of course administrator can temporary override: mount /dev/shm -o remount, nosuid Or even have it stick after reboot, by droping in /etc/systemd/system/ following unit definition¹: No. You either follow what is in /etc/fstab, or you disallow it from /etc/fstab. You do not ignore /etc/fstab. And if for some bad reason you do decided to ignore /etc/fstab, this should clearly cause log entries, and there should be a clear man page section for the man page in man fstab explaining this. Yes, documentation is not sexy. No source code is not documentation Paul (yes, bitter by the horrors of 10 years of iproute2) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 14 Dec 2010, Bill Nottingham wrote: It probably should be relnoted, sure. A relnote is not a substitute for proper documentation, logging and man pages. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 2010-12-14 at 17:54 -0500, Paul Wouters wrote: On Tue, 14 Dec 2010, Tomasz Torcz wrote: Of course administrator can temporary override: mount /dev/shm -o remount, nosuid Or even have it stick after reboot, by droping in /etc/systemd/system/ following unit definition¹: No. You either follow what is in /etc/fstab, or you disallow it from /etc/fstab. You do not ignore /etc/fstab. You appear to have missed the bit where Bill explained, twice, that systemd is not actually designed to ignore /etc/fstab, and this is just a bug. -- 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: noexec on /dev/shm
On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote: Thanks, Bill, for replying in so much detail. Here are a few other points: - systemd mounts API filesystems without them needing to be in /etc/fstab. This is for a variety of reasons - having every system installer have to write /proc, /sys, and so on is pretty wasteful. It also can give inexperienced admins the idea that it's configuration that can be changed - they then rename the mount point from /proc to /processes and *kaboom*. The main reason we mount /sys and /proc and friends in C code this early is that we simply need them ourselves. To do what systemd does, it must be able to rely that it can read process data from /proc, or device information from /sys, or cgroup information from /sys/fs/cgroup. There is simply no way around this, and just to make a point, Upstart mounts some of those FS too, in C code (however not /dev/shm), there's very little effective difference here, and if people whine and say things have never een done this way, you a are breaking UNIX, then I can only reply, that that's simply wrong. Having said all this I actually believe that there is very little point in listing API file systems like these in /etc/fstab. They are after all API, hence only relevant for application code, not really useful for direct interaction or even reconfiguation by the user. Or in other words: While it definitely makes sense to ount /dev/sda5 to whatever mount point the user chooses, the mount point and options for the API file systems are pretty much an implementation detail for the OS, and there should never be a need to change them. 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. That said, because we anticipated that there are some valid uses to change the settings of these mount points (e.g. change size= for tmpfs) we actually do apply the options from /etc/fstab, if the file system is listed there. So if you really really want to misuse /dev/shm, you may. Apparently this particular feature was broken (see Bill's comments), and hence please file a bug about this. So, in the long run, I believe /etc/fstab should only list real disk and network file systems, and all the API file systems should not be visible there. The list of API file systems mounted and the list of API file systems configured in this file usually has been differing anyway, and hence I would simply not list them by default there anymore at all. You could even say that this brings /etc/fstab back to its traditional roots, since the glut of virtual API file systems is actually a very recent change in history, and for the longest time /proc was really the only one ever used. So, Unix-Lovers, please say thank you, we are bringing back to you a piece of good old Unix/Linux, that has long been taken away from you, by evil Unix-haters! [ and again, not listing by default by no means means that you couldnt list them there if you wanted to to or that your options would be ignored by design -- as soon as the aforementioned bug is fixed ] (Sorry for no responding more timely. i have been (and still am) backpacking through India, and my access to the Internet has been only sporadic and slow) 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 12/14/2010 21:28, Lennart Poettering wrote: On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote: Thanks, Bill, for replying in so much detail. Here are a few other points: - systemd mounts API filesystems without them needing to be in /etc/fstab. This is for a variety of reasons - having every system installer have to write /proc, /sys, and so on is pretty wasteful. It also can give inexperienced admins the idea that it's configuration that can be changed - they then rename the mount point from /proc to /processes and *kaboom*. The main reason we mount /sys and /proc and friends in C code this early is that we simply need them ourselves. To do what systemd does, it must be able to rely that it can read process data from /proc, or device information from /sys, or cgroup information from /sys/fs/cgroup. There is simply no way around this, and just to make a point, Upstart mounts some of those FS too, in C code (however not /dev/shm), there's very little effective difference here, and if people whine and say things have never een done this way, you a are breaking UNIX, then I can only reply, that that's simply wrong. Having said all this I actually believe that there is very little point in listing API file systems like these in /etc/fstab. They are after all API, hence only relevant for application code, not really useful for direct interaction or even reconfiguation by the user. Or in other words: While it definitely makes sense to ount /dev/sda5 to whatever mount point the user chooses, the mount point and options for the API file systems are pretty much an implementation detail for the OS, and there should never be a need to change them. 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. That said, because we anticipated that there are some valid uses to change the settings of these mount points (e.g. change size= for tmpfs) we actually do apply the options from /etc/fstab, if the file system is listed there. So if you really really want to misuse /dev/shm, you may. Apparently this particular feature was broken (see Bill's comments), and hence please file a bug about this. I'm fine with that as long as it is documented, particularly in the fstab man page and as commentary in /etc/fstab on newly-installed systems so people who read it and notice missing filesystems don't panic. Thanks for explaining your thought process. It sounds like /tmp would be a better location to remove noexec from than /dev/shm if one needs memory-backed storage for things and doesn't want to create a new filesystem for that purpose. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote: The project is a database system that creates and dlopen()s plugins on-the-fly, for better performance on [long-running] queries. We like the speed of creat+write+close+open+read+mmap on /dev/shm. If /dev/shm and /tmp both become off limits, then what is the recommended replacement location? The API for /dev/shm is shm_open(). Unless you are using that API you shouldn't really touch /dev/shm. What's wrong with /tmp for your use cases? 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 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. The claim The API for /dev/shm is shm_open() is incorrect. Very early in the history of shm [late 1970's at the Columbus, Ohio, USA branch of Bell Telephone Laboratories], then shm_open, shmget, etc., were the only means of access; the objects had names that were 32-bit binary integers. In fact, when shm became more widely used then there were denial-of-service attacks based on the premise that enumerating objects in shm required 2**32 exhaustive search via shmget. As soon as /dev/shm was integrated into the filesystem, then creat, open, read, write, close, lseek, execve, etc. (any filesystem API) became additional access paths. This integration began appearing by about the mid 1980's, around 25 years ago, and since then applications have been using /dev/shm via ordinary files system APIs in addition to shmget etc. Why? Because *fast* operations on small numbers of small-to-medium-sized files can be a big advantage for performance. /tmp often is much slower because /tmp often is a harddrive: the need for space in /tmp often exceeds the size of physical RAM. Also, mounting /tmp as tmpfs can meet resistance because tmpfs does not support all features that applications expect. A ramdisk might be used, except that early ramdisks allowed at most a few megabytes (comparable to the capacity of a floppy disk), which is not large enough to support typical simultaneous usage. Applications also cannot rely on ramdisks because superuser privileges usually are required to access a ramdisk. In many cases ramdisks have been replaced by: /dev/shm !! I have applications which use /dev/shm via file system APIs, including execve() and dlopen(). Both of those fail when /dev/shm has MS_NOEXEC. One group of applications generates database plugins on-the-fly in a just-in-time fashion. Of course non-interactive performance increases in the usual way that substituting compiled code for interpreted often gives a speedup of 8X or more. Interactive response also improves, because small files in /dev/shm do not contend with operations in /tmp which can require slow sync() or large transfers. In some cases even /dev/shm is slower than desirable. I have requested dlopen() from memory: http://sourceware.org/bugzilla/show_bug.cgi?id=11767 . Meanwhile, /dev/shm is the only choice which is present always and sufficiently fast. It is just not true that file system APIs are a misuse of /dev/shm. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 14.12.10 13:53, Miloslav Trmač (m...@volny.cz) wrote: Changing the semantics of /etc/fstab without any consultation with fedora-devel or even notification of Fedora that something so long-standing is changing is hardly constructive either. I can happily live with systemd is a new, better init system without knowing the details. I consider systemd replaces 15% of /etc and changes semantics of another 5% without discussing the details in advance unacceptable for the distribution as a whole, although this decision is of course FESCo's. All these things are actually discussed very much on IRC, and systemd upstream mailing lists and similar places. Quite a few people from various distirbutions have been involved and whenever we feel it really is necessary to inroduce a configuration file for something we don't take this decision lightly, and involve a lot of people so that we come to a soltuion that people from all distributions can live with. Also, in every case where we actually introduced a new configuration file we carefully made sure to provide compatibility to the previous per-distribution configuration files. For example: every distro placed system-wide locale settings in a different configuration files. After doing a survey we felt that it was most appropriate to unify this in a new configuration file /etc/locale.conf instead of declaring any of the existing solutions the new standard for systemd-based systems. However, if systemd is built on Fedora we actually do fall back to /etc/sysconfig/i18n, to provide a sane upgrade path. I guess what I want to say is that all of this is openly discussed with input from a lot of people. Yes, we don't have discussed this on fedora-devel, but a) I am pretty sure that the subscribers of this ML wouldn't like the amount of traffic this would generate and b) this is not really fedora-specific, but something to discuss with other distros too, and c) I haven't really experienced fedora-devel as a great place to discuss technical things with constructive input, but mostly as a place where people (not all, but definitely too many) are negative-by-default and like implying that we 1) want to destroy Unix/Linux, 2) are idiots or 3) would decide everything behind closed doors. Or, to turn this around: if you want to have a say, if you want to influence systemd's design, then join devlopment upstream, or otherwise become involved. Just standing on the sidelines and expecting that we will ask you personally for your kind comments, is not going to happen. The duty to involve yourself is on you! 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 Tue, 14.12.10 08:08, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Tomasz Torcz to...@pipebreaker.pl said: We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need to mount sysfs somewhere else than /sys. Or /dev with mode other than 755? Those all directories are mounted _identically_ on every Linux distribution down here. Why pollute fstab with repeated lines on million machines? What is the advantage to making some mounts not listed in the file with all the other mounts? It isn't like /etc/fstab is a hundred lines or anything; it is a standard config file that predates Linux. All mounts are listed there until systemd decided to override it (without any warning or documentation). Well, what would be the advantage of listing it? Confusing the admin with lines that are an implementation detail of the OS? Or giving the admin the suggestion to maybe change the mount point of procfs to /waldo and see how everyting breaks? Also, the list in /etc/fstab never was complete anyway. It never listed /selinux, neither /sys/fs/cgroup (or its predecessor /cgroup), or /sys/kernel/security, or /dev/hugepages, or /dev/mqueue, or binfmt_misc, or /sys/kernel/debug, or the rpc_pipefs, or the fuse connections fs. (Also, this discussion is premature anyway, since I have not asked the Anaconda team to drop the default procfs/sysfs lines from fstab, and won't do so before F16). 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 Tue, 14.12.10 17:54, Paul Wouters (p...@xelerance.com) wrote: On Tue, 14 Dec 2010, Tomasz Torcz wrote: Of course administrator can temporary override: mount /dev/shm -o remount, nosuid Or even have it stick after reboot, by droping in /etc/systemd/system/ following unit definition¹: No. You either follow what is in /etc/fstab, or you disallow it from /etc/fstab. You do not ignore /etc/fstab. And if for some bad reason you do decided to ignore /etc/fstab, this should clearly cause log entries, and there should be a clear man page section for the man page in man fstab explaining this. Yes, documentation is not sexy. No source code is not documentation systemd documentation is actually pretty good and mostly comprehensive. Humble as I am I would even say that it is vastly superior to the majority of all open source projects. If you want to criticise us on something, pick something else, please. Yes, reading documentation is not sexy, but just bitching isn't reading documentation. 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 12/14/2010 09:37 PM, Lennart Poettering wrote: On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote: The project is a database system that creates and dlopen()s plugins on-the-fly, for better performance on [long-running] queries. We like the speed of creat+write+close+open+read+mmap on /dev/shm. If /dev/shm and /tmp both become off limits, then what is the recommended replacement location? The API for /dev/shm is shm_open(). Unless you are using that API you shouldn't really touch /dev/shm. What's wrong with /tmp for your use cases? As I wrote another place under this topic (at http://lists.fedoraproject.org/pipermail/devel/2010-December/147159.html which crossed in the posting mail), some applications prefer to avoid /tmp for such purposes because /tmp often is too slow: a real harddrive (needs capacity larger than RAM) with a heavy-weight file system (to provide full-featured ACLs, etc.) which often suffers contention. Also, the claim The API for /dev/shm is shm_open() is incorrect. See the other message for the history. When something is in the file system, then by default the file system APIs (including creat, open, read, write, close, execve, dlopen, ...) are legitimate uses. (Originally [System V] shared memory was *not* in the file system, and this caused problems.) -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, 14.12.10 18:22, Miloslav Trmač (m...@volny.cz) wrote: Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500: The problem is not the technical solution. Problem is that changes of such important thing like /etc/fstab are decided without Fedora developers. Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get mounted. When this was done in rc.sysinit, every change to how it mounted /proc wasn't discussed on the devel list. When we switched to having dracut be the primary way that API filesystems are mounted, that wasn't put up to a FESCo vote. The practical difference is that nothing broke at that time, whereas systemd tends to break thinks that users use. (I won't buy dismissing it as mere bugs - adding NOEXEC could hardly have been a typo.) Mirek tends to break? On what is that founded? Have you filed bugs? 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 Tue, 14.12.10 22:19, John Reiser (jrei...@bitwagon.com) wrote: Also, the claim The API for /dev/shm is shm_open() is incorrect. See the other message for the history. When something is in the file system, then by default the file system APIs (including creat, open, read, write, close, execve, dlopen, ...) are legitimate uses. (Originally [System V] shared memory was *not* in the file system, and this caused problems.) Don't conflate SysV and POSIX shared memory. They are completely orthogonal. SysV shared memory does not appear in /dev/shm. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 660800] FTBFS perl-CGI-Application-Dispatch-2.17-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660800 Emmanuel Seyman emmanuel.sey...@club-internet.fr changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2010-12-14 04:30:34 --- Comment #7 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2010-12-14 04:30:34 EST --- Fixed in Rawhide. http://koji.fedoraproject.org/koji/buildinfo?buildID=209114 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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-CGI-Application-Plugin-CAPTCHA] Add perl(CGI) to BuildRequires
commit e5cae8fedc9a112bc0723f93c50290cd2e0ac5c3
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Tue Dec 14 11:18:43 2010 +0100
Add perl(CGI) to BuildRequires
perl-CGI-Application-Plugin-CAPTCHA.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Application-Plugin-CAPTCHA.spec
b/perl-CGI-Application-Plugin-CAPTCHA.spec
index f044769..a73dff3 100644
--- a/perl-CGI-Application-Plugin-CAPTCHA.spec
+++ b/perl-CGI-Application-Plugin-CAPTCHA.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Application-Plugin-CAPTCHA
Version:0.01
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Easily create, use, and verify CAPTCHAs in
CGI::Application-based web apps
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,6 +8,7 @@ URL:
http://search.cpan.org/dist/CGI-Application-Plugin-CAPTCHA/
Source0:
http://www.cpan.org/authors/id/C/CR/CROMEDOME/CGI-Application-Plugin-CAPTCHA-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(CGI)
BuildRequires: perl(CGI::Application)
BuildRequires: perl(Data::Random)
BuildRequires: perl(GD::SecurityImage)
@@ -53,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.01-3
+- Add perl(CGI) to BuildRequires (#660787).
+
* Sat Sep 04 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.01-2
- Add missing BuildRequires
--
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
[Bug 660787] FTBFS perl-CGI-Application-Plugin-CAPTCHA-0.01-2.fc15
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660787 Emmanuel Seyman emmanuel.sey...@club-internet.fr changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2010-12-14 05:25:57 --- Comment #7 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2010-12-14 05:25:57 EST --- Fixed in Rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=2662834 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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-CGI-Application-Plugin-LogDispatch] Add perl(CGI) to BuildRequires
commit 2167f63b532de84f2bc54758bcc45696c6342eed
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Tue Dec 14 11:32:20 2010 +0100
Add perl(CGI) to BuildRequires
perl-CGI-Application-Plugin-LogDispatch.spec |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Application-Plugin-LogDispatch.spec
b/perl-CGI-Application-Plugin-LogDispatch.spec
index 40f4e82..97a4ef7 100644
--- a/perl-CGI-Application-Plugin-LogDispatch.spec
+++ b/perl-CGI-Application-Plugin-LogDispatch.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Application-Plugin-LogDispatch
Version:1.02
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Add Log::Dispatch support to CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,6 +8,7 @@ URL:
http://search.cpan.org/dist/CGI-Application-Plugin-LogDispatch/
Source0:
http://www.cpan.org/authors/id/C/CE/CEESHEK/CGI-Application-Plugin-LogDispatch-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(CGI)
BuildRequires: perl(CGI::Application)
BuildRequires: perl(Log::Dispatch) = 0.21
BuildRequires: perl(Module::Build)
@@ -18,6 +19,8 @@ BuildRequires: perl(Test::Pod)
Requires: perl(Sub::WrapPackages)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+%{?perl_default_filter}
+
%description
CGI::Application::Plugin::LogDispatch adds logging support to your
CGI::Application modules by providing a Log::Dispatch dispatcher object
@@ -51,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.02-5
+- Add perl(CGI) to BuildRequires (#660821).
+- Add perl default filter
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.02-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
[Bug 660821] FTBFS perl-CGI-Application-Plugin-LogDispatch-1.02-4.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660821 Emmanuel Seyman emmanuel.sey...@club-internet.fr changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2010-12-14 05:50:47 --- Comment #7 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2010-12-14 05:50:47 EST --- Fixed in Rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=2662849 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 IO-All-0.41.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-IO-All: 12b2594079a6c98dc47a604f1cc2c716 IO-All-0.41.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
[perl-IO-All] - Update to 0.41 (Fix FTBFS: BZ 660953). - Remove requires-filter. - Remove R:/BR: perl(Spiffy).
commit 064930329cfcdd09de0075e6aa6e987b6b0c1ab4
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Tue Dec 14 12:45:04 2010 +0100
- Update to 0.41 (Fix FTBFS: BZ 660953).
- Remove requires-filter.
- Remove R:/BR: perl(Spiffy).
.gitignore|1 +
IO-All-filter-requires.sh |3 ---
perl-IO-All.spec | 20
sources |2 +-
4 files changed, 10 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e6f26a9..6b8d5e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
IO-All-0.39.tar.gz
+/IO-All-0.41.tar.gz
diff --git a/perl-IO-All.spec b/perl-IO-All.spec
index e24f2ec..171dddf 100644
--- a/perl-IO-All.spec
+++ b/perl-IO-All.spec
@@ -1,6 +1,6 @@
Name: perl-IO-All
-Version:0.39
-Release:6%{?dist}
+Version:0.41
+Release:1%{?dist}
Summary:IO::All Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -12,15 +12,9 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::ReadBackwards)
BuildRequires: perl(IO::String)
BuildRequires: perl(MLDBM)
-BuildRequires: perl(Spiffy) = 0.21
BuildRequires: perl(Test::More)
-Requires: perl(Spiffy) = 0.21
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Source98: IO-All-filter-requires.sh
-%global real_perl_requires %{__perl_requires}
-%define __perl_requires %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u}
-n)-filter-requires
-
%description
The IO::All object is a proxy for IO::File, IO::Dir, IO::Socket,
IO::String, Tie::File, File::Spec, File::Path and File::ReadBackwards; as
@@ -34,9 +28,6 @@ manipulation functions.
find -type f -perm +100 -name '*.pm' -exec chmod a-x {} \;
-sed -e 's,@@PERL_REQ@@,%{real_perl_requires},' %{SOURCE98} %{__perl_requires}
-chmod +x %{__perl_requires}
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -55,7 +46,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
make test
%clean
-rm -rf $RPM_BUILD_ROOT %{__perl_requires}
+rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
@@ -64,6 +55,11 @@ rm -rf $RPM_BUILD_ROOT %{__perl_requires}
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Ralf Corsépius corse...@fedoraproject.org - 0.41-1
+- Update to 0.41 (Fix FTBFS: BZ 660953).
+- Remove requires-filter.
+- Remove R:/BR: perl(Spiffy).
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.39-6
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index b790e8b..ea59240 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4c8a8a765b7b49cd446b238e7283ebbb IO-All-0.39.tar.gz
+12b2594079a6c98dc47a604f1cc2c716 IO-All-0.41.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
[perl-accessors] - rebuild for fixing problems with vendorach/lib
commit 1751de2448885ee39e471fd00d230cc93334d752
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 16:20:23 2010 +0100
- rebuild for fixing problems with vendorach/lib
perl-accessors.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-accessors.spec b/perl-accessors.spec
index c71b8cc..3985bd8 100644
--- a/perl-accessors.spec
+++ b/perl-accessors.spec
@@ -1,6 +1,6 @@
Name: perl-accessors
Version:1.01
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Create accessor methods in caller's package
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.01-5
+- rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 1.01-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
[Bug 660953] FTBFS perl-IO-All-0.39-6.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=660953 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|NEW |CLOSED CC||rc040...@freenet.de Resolution||RAWHIDE Last Closed||2010-12-14 10:45:05 --- Comment #7 from Ralf Corsepius rc040...@freenet.de 2010-12-14 10:45:05 EST --- Bug was known to upstream and was already fixed in newer upstream releases. Fixed in perl-IO-All-0.41-1.fc15. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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-Ace] - rebuild for fixing problems with vendorach/lib
commit 8684a4d94cc9d208483173a03fbcf9dd26694c3b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 16:26:05 2010 +0100
- rebuild for fixing problems with vendorach/lib
perl-Ace.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Ace.spec b/perl-Ace.spec
index 20854fd..cb51e66 100644
--- a/perl-Ace.spec
+++ b/perl-Ace.spec
@@ -1,6 +1,6 @@
Name: perl-Ace
Version:1.92
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Perl module for interfacing with ACE bioinformatics databases
License:GPL+ or Artistic
Group: Development/Libraries
@@ -73,6 +73,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.92-6
+- rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 1.92-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-Acme-PlayCode] - 661697 rebuild for fixing problems with vendorach/lib
commit ea982ba8f7608bf13c790fde27e6ce486385e8d0
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 16:59:01 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Acme-PlayCode.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Acme-PlayCode.spec b/perl-Acme-PlayCode.spec
index 6f4540e..deeb1e2 100644
--- a/perl-Acme-PlayCode.spec
+++ b/perl-Acme-PlayCode.spec
@@ -1,6 +1,6 @@
Name: perl-Acme-PlayCode
Version:0.12
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Play code to win
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.12-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Tue May 25 2010 Petr Pisar ppi...@redhat.com - 0.12-2
- 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-Algorithm-C3] - 661697 rebuild for fixing problems with vendorach/lib
commit d68732479b729e40590cba803223be92d589a0b6
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:02:19 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Algorithm-C3.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-C3.spec b/perl-Algorithm-C3.spec
index 3312a01..62abef7 100644
--- a/perl-Algorithm-C3.spec
+++ b/perl-Algorithm-C3.spec
@@ -1,6 +1,6 @@
Name: perl-Algorithm-C3
Version:0.08
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Module for merging hierarchies using the C3 algorithm
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-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-Algorithm-CurveFit] - 661697 rebuild for fixing problems with vendorach/lib
commit 28497e12135a4f7f0b9ad6cdde9e8df94a11221e
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:12:59 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Algorithm-CurveFit.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-CurveFit.spec b/perl-Algorithm-CurveFit.spec
index 64c819a..8480f29 100644
--- a/perl-Algorithm-CurveFit.spec
+++ b/perl-Algorithm-CurveFit.spec
@@ -1,6 +1,6 @@
Name: perl-Algorithm-CurveFit
Version:1.05
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Nonlinear Least Squares Curve Fitting
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.05-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Aug 6 2010 Marcela Mašláňová mmasl...@redhat.com - 1.05-1
- 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-Algorithm-Dependency] - 661697 rebuild for fixing problems with vendorach/lib
commit eb5abca062b3fa1e5ab3c4578e233b9a0c858380
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:18:05 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Algorithm-Dependency.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-Dependency.spec b/perl-Algorithm-Dependency.spec
index 657c28d..51c140e 100644
--- a/perl-Algorithm-Dependency.spec
+++ b/perl-Algorithm-Dependency.spec
@@ -1,6 +1,6 @@
Name: perl-Algorithm-Dependency
Version: 1.110
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: Algorithmic framework for implementing dependency trees
License: GPL+ or Artistic
Group: Development/Libraries
@@ -53,6 +53,9 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.110-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Tue May 25 2010 Ralf Corsépius corse...@fedoraproject.org - 1.110-5
- Reactivate pmv test.
--
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-Algorithm-Diff] - 661697 rebuild for fixing problems with vendorach/lib
commit 5b1804e38d9882048312953b0c6109b44de7fc1a
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:23:31 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Algorithm-Diff.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-Diff.spec b/perl-Algorithm-Diff.spec
index 8dc2d66..85937c0 100644
--- a/perl-Algorithm-Diff.spec
+++ b/perl-Algorithm-Diff.spec
@@ -1,6 +1,6 @@
Name: perl-Algorithm-Diff
Version:1.1902
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Algorithm::Diff Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.1902-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 1.1902-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
[perl-Algorithm-IncludeExclude] - 661697 rebuild for fixing problems with vendorach/lib
commit 02baf3054450f58641dc58a4329992f924767e93
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:29:39 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Algorithm-IncludeExclude.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-IncludeExclude.spec
b/perl-Algorithm-IncludeExclude.spec
index 820b3e3..07c6b00 100644
--- a/perl-Algorithm-IncludeExclude.spec
+++ b/perl-Algorithm-IncludeExclude.spec
@@ -1,6 +1,6 @@
Name: perl-Algorithm-IncludeExclude
Version:0.01
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Build and evaluate include/exclude lists
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.01-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.01-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-aliased] - 661697 rebuild for fixing problems with vendorach/lib
commit c6fa55d6a82678b2457a82753cc9dcc145f41a58
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:44:52 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-aliased.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-aliased.spec b/perl-aliased.spec
index 073bd92..5456863 100644
--- a/perl-aliased.spec
+++ b/perl-aliased.spec
@@ -1,6 +1,6 @@
Name: perl-aliased
Version:0.30
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Use shorter versions of class names
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.30-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.30-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-Alien-SeleniumRC] - 661697 rebuild for fixing problems with vendorach/lib
commit 0ed503aeda0d1c504c45062e8f1555299b11c2fc
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:49:56 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Alien-SeleniumRC.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Alien-SeleniumRC.spec b/perl-Alien-SeleniumRC.spec
index 8d4ac13..4e68f2e 100644
--- a/perl-Alien-SeleniumRC.spec
+++ b/perl-Alien-SeleniumRC.spec
@@ -1,6 +1,6 @@
Name: perl-Alien-SeleniumRC
Version:1.03
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Packages the Selenium Remote Control server
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.03-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun May 23 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 1.03-3
- Remove selenium-server.jar from the archive
- Remove test on the internal selenium-server
--
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-Alien-wxWidgets] - 661697 rebuild for fixing problems with vendorach/lib
commit abc0b9bf0c1e9412242184b961b7c8537afa4dbf
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 22:55:47 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Alien-wxWidgets.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Alien-wxWidgets.spec b/perl-Alien-wxWidgets.spec
index 69b3b90..e87e8e4 100644
--- a/perl-Alien-wxWidgets.spec
+++ b/perl-Alien-wxWidgets.spec
@@ -1,6 +1,6 @@
Name: perl-Alien-wxWidgets
Version:0.51
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Building, finding and using wxWidgets binaries
Group: Development/Libraries
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.51-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Wed Jul 14 2010 Dan Horák d...@danny.cz - 0.51-2
- 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-AnyData] - 661697 rebuild for fixing problems with vendorach/lib
commit 6d9190038bf7e3f7412d375cc683f5c7bdae4a81
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 23:02:32 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-AnyData.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyData.spec b/perl-AnyData.spec
index ff8f067..fe473ba 100644
--- a/perl-AnyData.spec
+++ b/perl-AnyData.spec
@@ -1,6 +1,6 @@
Name: perl-AnyData
Version:0.10
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Easy access to data in many formats
Group: Development/Libraries
License:GPL+ or Artistic
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.10-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.10-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
[perl-AnyEvent] - 661697 rebuild for fixing problems with vendorach/lib
commit 5081598361c0eec4763f355b987b614b8bddd6ac
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 23:07:28 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-AnyEvent.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent.spec b/perl-AnyEvent.spec
index 6903f69..6d8eec9 100644
--- a/perl-AnyEvent.spec
+++ b/perl-AnyEvent.spec
@@ -2,7 +2,7 @@
Name: perl-AnyEvent
Version:5.27
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Framework for multiple event loops
Group: Development/Libraries
@@ -82,6 +82,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 5.27-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun Aug 22 2010 Nicolas Chauvet kwiz...@gmail.com - 5.27-1
- Update to 5.271 (rpm version : 5.27)
--
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 Config-Properties-1.71.tar.gz uploaded to lookaside cache by xavierb
A file has been added to the lookaside cache for perl-Config-Properties: b8b8457f3b07f5e4b342353fed43f93b Config-Properties-1.71.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
[perl-Config-Properties] Update to 1.71
commit a0f93ea27c5e1c67820f02dd078845cf4f632d41
Author: Xavier Bachelot xav...@bachelot.org
Date: Tue Dec 14 23:10:18 2010 +0100
Update to 1.71
perl-Config-Properties.spec | 10 +++---
sources |2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/perl-Config-Properties.spec b/perl-Config-Properties.spec
index cc610f2..3b0f6fb 100644
--- a/perl-Config-Properties.spec
+++ b/perl-Config-Properties.spec
@@ -1,11 +1,11 @@
Name: perl-Config-Properties
-Version:1.70
-Release:5%{?dist}
+Version:1.71
+Release:1%{?dist}
Summary:Read and write property files
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Config-Properties/
-Source0:
http://www.cpan.org/modules/by-module/Config/Config-Properties-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SA/SALVA/Config-Properties-%{version}.tar.gz
Patch1: perl-Config-Properties-1.70-always_test_PODs.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
@@ -58,6 +58,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Xavier Bachelot xav...@bachelot.org 1.71-1
+- Update to 1.71.
+- Update Source0 URL.
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.70-5
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 64a55a9..b71dd97 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7fa65789562f3b9833a82ebc052b0a7a Config-Properties-1.70.tar.gz
+b8b8457f3b07f5e4b342353fed43f93b Config-Properties-1.71.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
[perl-AnyEvent-AIO] - 661697 rebuild for fixing problems with vendorach/lib
commit 9cd43fb731e2b5a1e6aa07dda72d1f8c6fc66c55
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 23:12:43 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-AnyEvent-AIO.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent-AIO.spec b/perl-AnyEvent-AIO.spec
index 2c28e52..114fb31 100644
--- a/perl-AnyEvent-AIO.spec
+++ b/perl-AnyEvent-AIO.spec
@@ -1,6 +1,6 @@
Name: perl-AnyEvent-AIO
Version:1.1
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Truly asynchronous file and directrory I/O
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.1-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 1.1-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-AnyEvent-BDB] - 661697 rebuild for fixing problems with vendorach/lib
commit 4ef6bde91a086ad643dec414cc228dbb408c72e0
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 23:18:23 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-AnyEvent-BDB.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent-BDB.spec b/perl-AnyEvent-BDB.spec
index d8a1a8c..b7286aa 100644
--- a/perl-AnyEvent-BDB.spec
+++ b/perl-AnyEvent-BDB.spec
@@ -1,6 +1,6 @@
Name: perl-AnyEvent-BDB
Version:1.1
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Truly asynchronous Berkeley DB access
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 1.1-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 1.1-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
File HTML-StripScripts-1.05.tar.gz uploaded to lookaside cache by xavierb
A file has been added to the lookaside cache for perl-HTML-StripScripts: e8c51fbfda69efaf94c2937084d2458f HTML-StripScripts-1.05.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
[perl-HTML-StripScripts] Update to 1.05
commit fcd3c8b37e6a0b63c45cd35da791c04dbefe7659
Author: Xavier Bachelot xav...@bachelot.org
Date: Tue Dec 14 23:21:08 2010 +0100
Update to 1.05
.gitignore |1 +
perl-HTML-StripScripts.spec | 10 +++---
sources |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 02a7fd0..2c0b789 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
HTML-StripScripts-1.04.tar.gz
+/HTML-StripScripts-1.05.tar.gz
diff --git a/perl-HTML-StripScripts.spec b/perl-HTML-StripScripts.spec
index 8206dbb..ff5973c 100644
--- a/perl-HTML-StripScripts.spec
+++ b/perl-HTML-StripScripts.spec
@@ -1,11 +1,11 @@
Name: perl-HTML-StripScripts
-Version:1.04
-Release:5%{?dist}
+Version:1.05
+Release:1%{?dist}
Summary:Strip scripting constructs out of HTML
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTML-StripScripts/
-Source0:
http://www.cpan.org/modules/by-module/HTML/HTML-StripScripts-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DRTECH/HTML-StripScripts-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -50,6 +50,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Xavier Bachelot xav...@bachelot.org 1.05-1
+- Update to 1.05.
+- Update Source0 URL.
+
* Sun Dec 12 2010 Iain Arnell iarn...@gmail.com 1.04-5
- doesn't require perl(Test::More)
diff --git a/sources b/sources
index 0590fce..877fe0b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-aecd01e273bddbf60dca2a923163826d HTML-StripScripts-1.04.tar.gz
+e8c51fbfda69efaf94c2937084d2458f HTML-StripScripts-1.05.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
[perl-AnyEvent-XMPP] - 661697 rebuild for fixing problems with vendorach/lib
commit 397553e9a75871d1c7b79f42f048ab5d9cee3c9d
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 23:29:03 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-AnyEvent-XMPP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent-XMPP.spec b/perl-AnyEvent-XMPP.spec
index 956214e..a812e81 100644
--- a/perl-AnyEvent-XMPP.spec
+++ b/perl-AnyEvent-XMPP.spec
@@ -1,6 +1,6 @@
Name: perl-AnyEvent-XMPP
Version:0.51
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Implementation of the XMPP Protocol
License:GPL+ or Artistic
Group: Development/Libraries
@@ -105,6 +105,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.51-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Apr 29 2010 Marcela Maslanova mmasl...@redhat.com - 0.51-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-Any-Moose] - 661697 rebuild for fixing problems with vendorach/lib
commit 3f83408a89dd19d563a29de3eb7f5e8a7caf4084
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Dec 14 23:34:33 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Any-Moose.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Any-Moose.spec b/perl-Any-Moose.spec
index 26dde87..bebcc00 100644
--- a/perl-Any-Moose.spec
+++ b/perl-Any-Moose.spec
@@ -1,7 +1,7 @@
Name: perl-Any-Moose
Summary:Use Moose or Mouse automagically
Version:0.13
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/S/SA/SARTAK/Any-Moose-%{version}.tar.gz
@@ -58,6 +58,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Tue Dec 14 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun Jun 27 2010 Iain Arnell iarn...@gmail.com 0.13-1
- update to latest upstream
--
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 HTML-StripScripts-Parser-1.03.tar.gz uploaded to lookaside cache by xavierb
A file has been added to the lookaside cache for perl-HTML-StripScripts-Parser: b4c169034be56590a53f8835529627ba HTML-StripScripts-Parser-1.03.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
