question about nautilius actions
Hi, I wrote a small program, that works as frontend for filesystem defragmentation tools (ext4, xfs and btrfs) https://bugzilla.redhat.com/attachment.cgi?id=464699action=edit I want to execute it from nautilius context menu - unfortunately nautilius-actions-config-tool seems to be busted on rawhide, so I tried nautilius-actions-new -l Defrag -e -x /home/michal/bin/defrag.py -p -d -o -f -d and now I can't run nautilius :) (this can also be caused by the last update, I did in the meantime - after reboot some things in Gnome do not work as expected) In short, I would like to add to the context menu two actions - one for defraging file/dir and one fo checking fragmentation - as presented below Filesystem defragmentation defrag -d -o /mnt/dir http://i56.tinypic.com/e89v1x.png Informations about filesystem fragmentation defrag -o /mnt/dir http://i53.tinypic.com/231m48.png How to do something like this and don't break things? -- Best regards, Michal Sent from my iToaster -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtk3 in rawhide
Dne 3.12.2010 23:19, Adam Williamson napsal(a): sigh. typo. I meant Evince not Zarafa. If you're wondering how I can possibly screw that up, I tested Evince by loading the Zarafa user manual. =) Hmm, apparently there are not that many bugs against evince. So, that's just my personal curse that whenever I run evince I get bugs like https://bugzilla.redhat.com/show_bug.cgi?id=657609 or https://bugzilla.redhat.com/show_bug.cgi?id=659937 Oh well. I should pray more, I suppose. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for comment: Potential change to dist-git branch structure
Dne 4.12.2010 06:33, Garrett Holmstrom napsal(a): Why tie branch names down to specific releases? While that scheme makes it easy for fedpkg to guess what release to attempt to build against when one only cares about one release, it makes little sense to call a branch f14-rh123456 when in reality that branch will merge into f13 as well as f14. +1 Why not just get out of all this silly business and leave branches to be whatever we want them to be as God^H^H^HLinus intended them to be? Really, branch rhbz1234567 doesn't have to have any relation to any particular distribution (we usually don't clone Fedora bugs to all distros where they happen, and that's The Right Thing). Related issue I have with the Fedora git repositories is that one cannot remove any branch once it is created. After I have created in bitlbee repo two topic branches, only to find out that I cannot remove them after the merge. I can understand need for documenting development of the distribution, but cannot we lock just SOME branches (probably master + f* ones)? In this situation, I have moved my topical branches to gitorious, where I can do whatever I want to do with them. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for comment: Potential change to dist-git branch structure
On 12/04/2010 12:19 PM, Matej Cepl wrote: Related issue I have with the Fedora git repositories is that one cannot remove any branch once it is created. After I have created in bitlbee repo two topic branches, only to find out that I cannot remove them after the merge. I can understand need for documenting development of the distribution, but cannot we lock just SOME branches (probably master + f* ones)? In this situation, I have moved my topical branches to gitorious, where I can do whatever I want to do with them. I think it makes sense to disallow removing official branches (f13, f14, master) to make sure people don't change the history of branches which are used for release builds. On the other hand, for topic branches and personal branches I would very much like to be able to do non fast-forward pushes and to be able to delete them. With git it's common to create branches for preparing a feature and merge them into the official branch once the feature is ready. Allowing non fast-forward pushes in unofficial branches would make it much easier to prepare a perfect history before merging it into the official branches. -- Regards, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
I see [1] the libical is not orphaned yet, neither in devel, nor in F14, as I only can add myself to the package, but not take ownership as with other orphaned packages. I think what happens is when the owner orphans a package one of the co-maintainers automatically get promoted. Cheers, Debarshi -- The camera is to the brush what Java is to assembly. -- Sougata Santra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101204 changes
Compose started at Sat Dec 4 08:15:03 UTC 2010 Broken deps for x86_64 -- balsa-2.4.9-1.fc15.x86_64 requires libesmtp.so.5()(64bit) 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) 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) 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-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 ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) 6:kdelibs-4.5.85-1.fc15.i686 requires oxygen-icon-theme = 0:4.5.85 6:kdelibs-4.5.85-1.fc15.x86_64 requires oxygen-icon-theme = 0:4.5.85 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 mars-sim-2.84-6.fc14.noarch requires commons-collections moblin-panel-media-0.0.8-0.2.fc13.x86_64 requires libmoblin-panel.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libmoblin-panel.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.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) pcmanx-gtk2-0.3.9-6.20100618svn.fc14.i686 requires libnotify.so.1 pcmanx-gtk2-0.3.9-6.20100618svn.fc14.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
Re: Unresponsive maintainer for libical
On Sat, Dec 4, 2010 at 11:02 AM, Debarshi Ray debarshi@gmail.com wrote: I see [1] the libical is not orphaned yet, neither in devel, nor in F14, as I only can add myself to the package, but not take ownership as with other orphaned packages. I think what happens is when the owner orphans a package one of the co-maintainers automatically get promoted. Not in my experience. It remains orphaned until someone explicitly takes it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
OO updates - no presto support?
Hello all, I've noticed that since the release of F14 a fairly large [1] number of OO updates came down the wire - non of them in deltarpm/presto form (read: a 100MB download per release). Is it bug or intended behavior? If its a bug, wouldn't it be wise to hold off on releasing non-security-fixes until its resolved? FWIW, I'm on Fedora 14, x86_64. - Gilboa [1] $ cat /var/log/yum.log | grep openoffice.org-core | grep fc14 Nov 09 11:12:38 Updated: 1:openoffice.org-core-3.3.0-13.3.fc14.x86_64 Nov 21 13:35:30 Updated: 1:openoffice.org-core-3.3.0-14.1.fc14.x86_64 Nov 24 09:18:57 Updated: 1:openoffice.org-core-3.3.0-15.2.fc14.x86_64 Dec 04 14:02:43 Updated: 1:openoffice.org-core-3.3.0-17.2.fc14.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OO updates - no presto support?
On 12/04/2010 06:54 PM, Gilboa Davara wrote: Hello all, I've noticed that since the release of F14 a fairly large [1] number of OO updates came down the wire - non of them in deltarpm/presto form (read: a 100MB download per release). Is it bug or intended behavior? If its a bug, wouldn't it be wise to hold off on releasing non-security-fixes until its resolved? FWIW, I'm on Fedora 14, x86_64. It is a bug. Refer to http://lists.fedoraproject.org/pipermail/users/2010-November/387625.html Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for comment: Potential change to dist-git branch structure
- Jesse Keating jkeat...@redhat.com wrote: I'm working on fixing a few long standing bugs in fedpkg that have to do with our branch structure (https://bugzilla.redhat.com/show_bug.cgi?id=619979 and https://bugzilla.redhat.com/show_bug.cgi?id=622592). This has me examining our branch structure again and trying to remember why exactly I chose it (obviously I did a poor job of documenting that...). The original thought was to have top level branches that are named after distribution releases, eg f14, f15, el5. Then we would force branches of those branches use a naming structure of f14/topic. The reason was so that our tooling could look at the name of the branch and easily work back to the f14 part. This would work even if it was f14/user/fred/topic/mybranch or other such craziness. When I went to test this, I realized that git won't allow you to have both f14 and f14/topic as branches, because of the way the git metadata works on the filesystem. When I encountered this, I made f14/master become the top level branch, and then f14/somethingelse could coexist. Unfortunately I also wanted to keep things easy for users and tried to maintain tooling that would allow you to just say f14. This didn't get enough real world testing and in hindsight was a bad idea. Things go wrong quickly in git if your local branch name doesn't match the remote branch name. When thinking about the above, and the two bugs I'm working on, I realized that we don't have any real strong need to be using / as a delineator. It makes some code easier, but makes other things more complex and difficult. So what if we changed it? What I'm thinking about now is switching from / to - as a delineator. This would improve a couple things. First, we could achieve upstream top level branch names that are short and simple: f14, f15, master. I'm all for this change. I believe the majority of users will have an outcome with f14/f13-kind of branches. We can have branches that build upon those names: f14-rebase, f15-cve223, f15-user-jkeating-private. We could keep the simple fedpkg tooling that allows users to just type f14 and the like to reference a branch, and now the local branch will match the name of the remote branch. As for the first two bugs I mentioned, it doesn't directly help them. However I would feel better about telling people that their local branches must follow a naming scheme of release-something and then we could easily guess what release the local branch is for if it isn't tracking a remote branch. However the bug about what to do if there are no remote branches is really not touched by any of this, it just got me thinking about branches :) What kind of user impact would this have? My hope is that the impact would be minimal. Git allows branch renames, and can successfully rename f14/master to f14. All the history is renamed. We should be able to do this without an outage of the git server. The ACL system will need a slight tweaking, and a regeneration of the ACLs but that is fairly quick and minor to accomplish. However there will be some issues client side. We will not be able to make use of git's symbolic-ref feature of aliasing a branch. We cannot make f14/master an alias for f14, again because of the filesystem layout issues. These issues rear their head once again when a client does a pull of an already checked out repo that had branches. Because there was already a f14/master, when the client sees a new branch just named f14 it will fail to create it. Git has a command that will fix this git remote prune origin. That will remove the local reference to f14/master and a subsequent pull sees the creation of the f14 branch happen successfully. However, if a user had a local branch of f14 or f14/master they will be left with mismatched .git/config entries. In this case it's easiest to delete the local branch (git branch -d f14) and check it out again. If there are changes on the branch one can fix the config to point it to the right upstream location. Also we would need to get a new fedpkg into the hands of all the developers that handles the new branchnames. We could do a build that handles both the oldnames and the new and have it out and available for a reasonable period of time before we make the switch. Would it make sense to add functionality to fedpkg which checks if there exists configuration for remote branch tracking (i.e. local f14 tracks remote f14/master), and if that's the case, print a warning (e.g. that it's recommended to delete the local branch and recreate/check it out again)? This won't help much for the git pull problem, but it may prevent some users from running into that problem in the first place, because they saw the warning earlier when switching branch or doing some other fedpkg operation. --Severin So, some pain, for some pretty good gain. This time
Taking ownership of orphaned+retired impressive
Package impressive used to be available for F13 but is orphaned; it got marked retired for F14 and rawhide (master) because of maintainer inactivity. I took over ownership for F13, see: https://admin.fedoraproject.org/pkgdb/acls/name/impressive I fedpkg-cloned it, synced with upstream and ran scratch builds for f13, f14, rawhide, epel6, all successful. I'll further cleanup the spec file and go through the rereview and SCM change process as the wiki suggests. Just so that you know :) Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mpfr soname bump in rawhide
Ralf Corsepius wrote: To prevent overzealous maintainers, who believe to understand what they are doing but actually don't, from doing harm to packages. Trust me, after I'm done yelling at them, they won't do that ever again. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for comment: Potential change to dist-git branch structure
On Fri, Dec 03, 2010 at 16:34:05 -0800, Jesse Keating jkeat...@redhat.com wrote: f14/user/fred/topic/mybranch or other such craziness. When I went to test this, I realized that git won't allow you to have both f14 and f14/topic as branches, because of the way the git metadata works on Does there need to be some sort of check for / in maintainer created branch names to prevent problems? My hope is that the impact would be minimal. Git allows branch renames, and can successfully rename f14/master to f14. All the history is renamed. We should be able to do this without an outage of the git server. Is this going to break things for people that having set up origin tracking for multiple releases in the same repo? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: issues with duplicate entries in /etc/mtab
On Fri, Dec 03, 2010 at 14:06:53 +0100, Michal Schmidt mschm...@redhat.com wrote: On Fri, 3 Dec 2010 11:59:25 +0100 Rudolf Kastl wrote: As you can see with a current rawhide install you might end up with filesystems that have multible entries in mtab: http://fpaste.org/Z7Ne/ df also outputs the filesystems redundantly. If the system is to be changed and mtab is going to be removed all the tools writing to and reading from it have to be looked at as well i guess. I am not sure if the right people are already aware of the issue. Lennart wants mtab to be a symlink to /proc/mounts: https://bugzilla.redhat.com/show_bug.cgi?id=655571 I have a bug filed about this as well. I started from the warning message about the link rather than df output. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14 OOo deltarpms not being generated on releng2
I'm not sure if there's a better list for this to go to, but there seems to be a problem generating deltarpms for F14 OOo (and a few other packages) on releng2. Specifically, the updates-updates deltarpms aren't being generated, while the GA-updates deltarpms are. When I checked the mash.out log for the 101202.1757 push, there are loads of error messages following the form of: Error genDeltaRPM for openoffice.org-langpack-pt_PT: exitcode was 256 - Reported Error: bad cpio archive The problem is that this error normally comes up when one of the rpms is corrupt, but manually running deltarpm between an rpm from the 101201.1909 push and the update from the 101202.1757 push results in a proper drpm and no errors. As far as I can see, this only affected the openoffice.org* and autocorr* packages in the 101202 push, and the rest of the packages in the push had all the proper deltarpms generated. I'm not sure where to go from here. Any ideas on how to track this down? Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora as semantic desktop (nautilus and tracker integration) ?
https://bugzilla.redhat.com/show_bug.cgi?id=501227 I'm writing to devel list just if anybody can say will there be any chance to get nautilus and tracker integration working? Is this on anybody's radar? Thanks, Valent. -- pratite me na twitteru - www.twitter.com/valentt blog: http://kernelreloaded.blog385.com linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 OOo deltarpms not being generated on releng2
On Sat, 04 Dec 2010 20:50:11 +0200 Jonathan Dieter jdie...@lesbg.com wrote: ...snip... As far as I can see, this only affected the openoffice.org* and autocorr* packages in the 101202 push, and the rest of the packages in the push had all the proper deltarpms generated. I'm not sure where to go from here. Any ideas on how to track this down? FYI, I talked with Jonathan on irc and we added some debugging to the deltarpms/createrepo code. Hopefully that will show us more where the issue is so we can solve it. Jonathan kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 659941] New: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=659941 Summary: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) Product: Fedora Version: 14 Platform: x86_64 OS/Version: Unspecified Status: NEW Status Whiteboard: abrt_hash:66dfb52ef7c63f08670b911cea77f3b3f2195bd1 Severity: medium Priority: low Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: robe...@latnet.lv QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/perl /usr/bin/padre component: perl-Padre crash_function: wxControlContainer::SetLastFocus executable: /usr/bin/perl kernel: 2.6.35.6-48.fc14.x86_64 package: perl-Padre-0.64-1.fc14 rating: 4 reason: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1291457614 uid: 500 comment - It is worh noting that the library is installed as seen by yum provides */libwx_gtk2u_aui* : wxGTK-2.8.11-2.fc14.x86_64 : GTK2 port of the wxWidgets GUI library Repo: installed Matched from: Filename: /usr/lib64/libwx_gtk2u_aui-2.8.so.0.7.0 Filename: /usr/lib64/libwx_gtk2u_aui-2.8.so.0 I hope this is easy to solve. Many thanks Roberts How to reproduce - 1. Fedora was upgraded from 13 to 14 2. Start Padre (perl-ide) - get crash with dialog box complaining that libwx_gtk2u_aui-2.8.so: cannot open shared object file: No such file or directory 3. After a few seconds the dialog box disappears 4. Sometimes the IDE window appears, but crashes when you try to do something with it -- 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
[Bug 659941] [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
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=659941 --- Comment #1 from Roberts Klotins robe...@latnet.lv 2010-12-04 05:21:17 EST --- Created attachment 464722 -- https://bugzilla.redhat.com/attachment.cgi?id=464722 File: backtrace -- 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
[Bug 659996] New: perl-Net-Patricia 1.19 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Net-Patricia 1.19 is available https://bugzilla.redhat.com/show_bug.cgi?id=659996 Summary: perl-Net-Patricia 1.19 is available Product: Fedora Version: 14 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: medium Priority: low Component: perl-Net-Patricia AssignedTo: or...@cora.nwra.com ReportedBy: phil...@redfish-solutions.com QAContact: extras...@fedoraproject.org CC: or...@cora.nwra.com, fedora-perl-devel-l...@redhat.com, phil...@redfish-solutions.com Classification: Fedora Description of problem: Upstream release of 1.19 on CPAN. Version-Release number of selected component (if applicable): Currently 1.18_81 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- 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
[Bug 659996] perl-Net-Patricia 1.19 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=659996 --- Comment #1 from Fedora Update System upda...@fedoraproject.org 2010-12-04 15:32:01 EST --- perl-Net-Patricia-1.19-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/perl-Net-Patricia-1.19-1.fc13 -- 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
[Bug 659996] perl-Net-Patricia 1.19 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=659996 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2010-12-04 15:33:07 EST --- perl-Net-Patricia-1.19-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Net-Patricia-1.19-1.fc14 -- 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
[Bug 657015] perl-Sub-WrapPackages should not provide local override perl(lib)
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=657015 --- Comment #8 from Fedora Update System upda...@fedoraproject.org 2010-12-04 19:35:13 EST --- perl-Sub-WrapPackages-2.0-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 657015] perl-Sub-WrapPackages should not provide local override perl(lib)
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=657015 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Sub-WrapPackages-2.0-4 ||.fc14 Resolution||ERRATA Last Closed||2010-12-04 19:35:17 -- 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
[Bug 657015] perl-Sub-WrapPackages should not provide local override perl(lib)
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=657015 --- Comment #9 from Fedora Update System upda...@fedoraproject.org 2010-12-04 19:38:10 EST --- perl-Sub-WrapPackages-1.31-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 657015] perl-Sub-WrapPackages should not provide local override perl(lib)
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=657015 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Sub-WrapPackages-2.0-4 |perl-Sub-WrapPackages-1.31- |.fc14 |3.fc13 -- 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
网通最新推出4000号码号段，多达百万号 码供您选择：预存话费即可开通
400企业热线 400电话 400企业热线通 大连40 --- 提升企业形象，完善公司销售、客服水平，提升业绩 来电咨询赠送网络传真试用账户（可发送20-30份传真） 网通最新推出4000号码号段，多达百万号码供您选择 您想对外公布一个统一的号码吗？ 您想来电即刻弹出客户资料吗？ 您想记录、监控公司来去电吗？ 您想不错过任何来电、商机吗？ 您想分支机构之间免费通话吗？ 您想群发短信、语音、传真吗？ 您想花300元就拥有自己的网站？ 不 要 犹 豫 抢 占 先 机 访问网站 发邮件给我 400电话是全国唯一的一个企业热线电话，转移呼叫到现有的固话、手机和小灵通上，不需要额外安装电话，有效地提高您公司的企业形象，提升企业的销售和服务水平，可以转移呼叫到20部电话上，同时接听，保证企业不占线。 中小企业的福音，400电话业务=形象+实力+服务+利润 400 号码业务好！好在哪里？ 全国统一接入，无须拨打区号！ 客户省！无需支付长途费用，客户呼叫企业，只需支付市话费用，极大降低了企业客户沟通成本！ 企业省！“ 400 企业热线通”相比传统800 业务，低廉的呼入资费，便宜，实惠！ 无月租！无开户费！可转接20部电话！ 提升企业形象，立竿见影 在一般人眼中，有400全国统一号码的企业，都是大企业，申请一个400号码，用在宣传页、名片、广告中可以大大提升企业形象，而花费却非常小。 同样刊登广告，效果提高50% 设想：如果贵公司与竞争对手同时在某一媒体刊登广告，而贵公司的联系电话是免区号接入统一号：400-716-6007，会是什么效果？客户肯定先拨贵公司的电话！ 全国统一号码，搬家不换号，业务不流失 只要将400号码与贵公司原有的固话或手机号绑定即可，如果贵公司搬家，只要将新的固话或手机号与400号码重新绑定即可，号码终生不换，业务绝不流失！ 免选号费、无开户费、无月租，开通方便快捷； 大连讯驰信息技术有限公司 全国客户服务热线：4007166007 电话：0411-62259990、62259991、39629880、39629881 网址：WWW.DLVOIP.COM.CN WWW.CRC400.COM 销售人员：付永辉 手机：13998669845 邮箱：13998669...@163.com MSN:fyh...@hotmail.com 诚征代理 共创大业 发达市场经济国家90%的企业都配置400客服热线，400客服热线已经成为企业生存、发展的必备工具！ 1、开通说明 开通时间：2小时-2天（特殊号码待定）； 受理材料：业务受理协议、营业执照复印件（加盖公章）、经办人身份证复印件； 免开户费、月租费、选号费，只需预存话费即可开通； 2、增值功能 欢迎词（彩铃）：“您好！欢迎致电**公司，请稍后，正在为你转接客服！”； 录音：可以对所有通过400电话拨入的电话自动录音； 智能语音导航（IVR）:“业务咨询，请按1；业务办理，请按2；投诉建议，请按3……”； 通话详单查询（已接来电、未接来电都可查询）； 其他附加功能（黑、白名单；条形码防伪等等）； 4006电话开通政策 预交600元，系统存600元；接听0.3元 /分钟； 预交1000元 ，赠送500元；接听0.2元 /分钟； 预存1500元，赠送1500元；接听0.15元 /分钟； 无月租、无开户费、无选号费、预存话费即可开通哦 讯驰网络电话 WWW.UBIQUE.CN 话费低廉,包月、计时多种套餐供您选择 网内通话免费,不分地域，只要安装了网络电话，内部通话都是免费的 国内包月网络电话，包月限时，话费最低5分5每分钟 网络传真 上网就能发传真 节约耗材 直达目标客户的营销 性价比最好的营销方式 一套传真系统顶十个业务人员，产品信息直达意向客户，高效率，高效果 群发短信 100%发送，不扣量 时间快，媲美手机直接发送 可接收 帮助筛选手机号码，空号全排除 400企业热线 www.crc400.com 提升企业形象 增加企业客户 号码全国唯一，不用加拨区号 企业终身可用的号码，搬家直接更换转移呼叫号码就可以，省却了来回换号之苦，全国各地都可以转移哦。 企业小型呼叫中心建设 呼入、呼出电话全程录音，方便备档、查询；工作监督；新人培训；客户问题总结；商机备案，好处多多！！ 话务耳麦：专业呼叫中心必选 电脑终端机：共享一台主机，节省电脑投资 结合网络电话，话费更节省，全程监督，过程可控，话务营销更有效率、更有效果 300元拥有自己的网站 自助式建站 会QQ空间就会建站 建站方便又快捷 功能强大，登陆www.5d1.cc体验吧 上网小卫士 家庭：保护孩子上网，监督孩子用电脑； 公司：监控员工使用电脑情况，限制上网，保护公司机密，提高办公效率，您最佳的电脑管理伴侣 功能一：不良信息过滤 功能二：游戏控制功能 功能三：聊天控制功能 功能四：上网时间控制 功能五：定时截屏功能 功能六：日志记录功能 功能七：远程监控功能 -- 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 519395] cleanup patch: use better buildroot, nicer find coomands
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=519395 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(ka...@ucw.cz) | Last Closed||2010-12-05 01:33:20 --- Comment #11 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-05 01:33:20 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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
[Bug 511770] FTBFS perl-SVN-Mirror-0.75-2.fc11
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=511770 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||WONTFIX Flag|needinfo?(ft...@fedoraproje | |ct.org) | Last Closed||2010-12-05 01:42:46 --- Comment #14 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-05 01:42:46 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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
[Bug 510466] backtrace in cssh
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=510466 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(azeli...@redhat.c | |om) | Last Closed||2010-12-05 01:44:05 --- Comment #3 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-05 01:44:05 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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
[Bug 438244] No cpanget man page
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=438244 Bug Zapper tri...@lists.fedoraproject.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Flag|needinfo?(j...@kamens.brookl | |ine.ma.us) | Last Closed||2010-12-05 02:12:44 --- Comment #5 from Bug Zapper tri...@lists.fedoraproject.org 2010-12-05 02:12:44 EST --- Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. -- 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
