Re: Bad coding practices in Fedora packages
On 01/03/2012 05:21 PM, Sérgio Basto wrote: On Tue, 2012-01-03 at 11:15 -0500, Genes MailLists wrote: On 01/03/2012 09:16 AM, Denys Vlasenko wrote: # cat /proc/meminfo/tmp/1; killall tracker-store; sleep 1; cat /proc/meminfo/tmp/2; cat /tmp/1 /tmp/2 | grep MemFree MemFree: 1940372 kB MemFree: 1963860 kB As you see, killing it on my machine freed over 23 megs worth of pages. As far as I know tracker is a feature of Gnome 3 - there may be a way to turn it off tho it may need a gnome registry tweak ... yeah other day this tracker or other from gnome , note that I use KDE , begins track down my external hdd via NAS , which have 1 Tera , IIRC . I notice because can't unmount my smbfs . rpm -ql tracker /etc/xdg/autostart/tracker-miner-flickr.desktop /etc/xdg/autostart/tracker-miner-fs.desktop /etc/xdg/autostart/tracker-store.desktop I agree, at least for non-gnome users , tracker shouldn't be in autostart. https://bugzilla.redhat.com/show_bug.cgi?id=771601 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Thanks for the pointers. By running this command, I have signed up for iwhd-related notifications in F-16 and rawhide: ssh fedorapeople.org autoqa-optin iwhd devel F-16 With this command you will subscribe for rpmlint and rpmguard test results for every new build [1]. Depcheck and upgradepath test results should be posted as comments into Bodhi for all proposed updates, you don't need to do anything about that. [1] http://jlaska.wordpress.com/2010/06/01/fedora-package-maintainers-want-test-results/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad coding practices in Fedora packages
On Tue, Jan 03, 2012 at 05:47:11PM +0100, Tomasz Torcz wrote: Also, 30 GiB in .cache/tracker is a bit extreme when rest of my ~ is 4 GiB. Tracker should only index a few standard directories ($HOME without subdirectories, ~/Documents, etc). What does it index on your machine? Is that the default F16 config? -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
On Wed, Jan 4, 2012 at 1:35 AM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-01-04 at 09:52 +0900, Joel Rees wrote: I think the error here is less in the coding in packages than in the design of the default system specifications, specifically the package selection. The errors gnome has committed would seem to be off-topic here, unless the Fedora community still needs more evidence of how far gnome has gone evil, or still needs more fuel for the debate about whether/when/where said evil should be considered necessary. The Fedora community should be able to decide which packages to group together for which installs. The desktop team decides what packages go into the desktop spin, and that's the same group of people as maintain GNOME, and many of them are upstream GNOME developers. Their stated position on tracker - it's been brought up on the desktop list before, see https://lists.fedoraproject.org/pipermail/desktop/2011-September/007377.html - is: Yeah, tracker is a required dependency of gnome-documents now. As Bastien says, we should try to identify and fix possible bugs and resource issues upstream. i.e., Tracker is now part of GNOME and they don't intend to disable it by default, but its default configuration could be adjusted (there was some discussion in the thread of doing this), and resource consumption bugs should be reported upstream and fixed. If the Gnome decision is for tracker to be there by default then that is a Gnome dev decision, and Gnome users can switch it off if they know how to and want to do so - but why was the decision made to set it up and running for other desktops? Give KDE and XFCE and LXDE users the choice if they want it but surely the default there should be off and not on? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
On Wed, Jan 04, 2012 at 03:09:07PM +0900, Joel Rees wrote: I suppose I have to go to the gnome lists and raise Cain about this kind of fundamental mis-engineering? If you want bugs to be fixed, then please file bugreports. Tracker should NOT have a noticeable impact on performance (in the default config). Of course it'll have some measurable impact, but if you can notice the impact in the default configuration, then something is wrong. From what I understood (before GNOME 3.0), tracker was changed so the performance impact is not noticeable. E.g. I have tracker running but I don't notice the impact of it. I do not have an SSD. I think I missed that other thread about misusing the kernel, so have to read up on what was said there. PS: Didn't know the term raise Cain, but if you mean: To be 'raising Cain' is to be causing trouble or creating an uproar. Don't do above @ GNOME, would only cause you to be banned. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rebuild for GCC-4.7
starting immediatly there is going to be a mass rebuild of rawhide for gcc-4.7 that landed yesterday. as approved by FESCo (https://fedorahosted.org/fesco/ticket/739) packagers will have just over a week, until Thursday Jan 12 to build packages themselves. After that date releng will kick off an automated mass rebuild of everything else. So please get building as Fedora 17 branching is less than 5 weeks away. we need all built by then Thanks Releng ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuild for GCC-4.7
On Wed, Jan 4, 2012 at 11:27 AM, Dennis Gilmore den...@ausil.us wrote: starting immediatly there is going to be a mass rebuild of rawhide for gcc-4.7 that landed yesterday. as approved by FESCo (https://fedorahosted.org/fesco/ticket/739) packagers will have just over a week, until Thursday Jan 12 to build packages themselves. After that date releng will kick off an automated mass rebuild of everything else. So please get building as Fedora 17 branching is less than 5 weeks away. we need all built by then I assume this is only required for packages that use gcc? So any other packages (perl, python, java, etc.) are excluded from this, correct? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning: mod_evasive
I just orphaned mod_evasive. I believe Jan Ondrej is going to pick it up. https://bugzilla.redhat.com/show_bug.cgi?id=739171 Best regards, -- Konstantin Ryabitsev Systems Administrator The Linux Foundation Montréal, Québec signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg --dist=el5 srpm, mockbuild fails with MD5 sum mismatch
Attempting to build an srpm or do a local mockbuild using fedpkg on an EL6 buildhost fails with EL5 chroot: DEBUG util.py:257: error: unpacking of archive failed on file /builddir/build/SOURCES/0001-10244-Restore-Mongrel-XMLRPC-functionality.patch;4f04a4a9: cpio: MD5 sum mismatch I had to build the SRPM manually using rpmbuild-md5: rpmbuild-md5 -bs puppet.spec and then submit that to mock: mock -r epel-5-x86_64 puppet-2.6.12-1.1.el6.src.rpm Shouldn't fedpkg be calling rpmbuild-md5 -bs when targeting an older dist like EL5? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg --dist=el5 srpm, mockbuild fails with MD5 sum mismatch
On Wed, Jan 4, 2012 at 12:32 PM, Chuck Anderson c...@wpi.edu wrote: Shouldn't fedpkg be calling rpmbuild-md5 -bs when targeting an older dist like EL5? fedpkg's --help text for local or srpm describes an --md5 option, and that's what I use when building for EL5. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need some advice on best packaging practices for a tricky package?
Hi, I've produced a pair of specfiles that I'm aiming to get into Fedora that take the standard Fedora binutils and gcc SRPM sources and patches and produce a series of cross-compilation binutils and gcc RPMs for all the Linux kernel arches that I can manage to get working. The inclusion request BZs can be found here: cross-binutils: https://bugzilla.redhat.com/show_bug.cgi?id=761619 cross-gcc: https://bugzilla.redhat.com/show_bug.cgi?id=766166 However, there are a number of warnings that rpmlint produces that I'd like some advice on. For cross-binutils: (1) As each set of cross-binutils manual pages is the same as every other set (and the core set come to that), I've stuffed the base manual pages in their own RPM and put symlinks to them from the individual arch RPMs. However, this results in lots of dangling-relative-symlink warnings, even though the targets are in another RPM passed to rpmlint. Can I make rpmlint ignore these? (2) The manual pages and translation files RPM gets the warning no-binary - which is true. Is there any way to make the spec file produce a noarch RPM at the same time as a bunch of binary RPMs? (3) The binutils installation installs some hard links and these cause rpmlint to issue cross-directory-hard-link warnings. For instance the following are hardlinked together: /usr/cross/alpha-linux-gnu/bin/ar /usr/bin/alpha-linux-gnu-ar Should I manually turn the hardlinked variants into copies? Or symlink between them? (4) The binutils installer would like to create /usr/target/. I'm creating /usr/cross/target/ to group all the stuff together into one dir under /usr. However, rpmlint likes neither of these and gives a non-standard-dir-in-usr warning. Should I put the stuff somewhere else? /usr/lib/ or /usr/libexec/ perhaps? I've tried to persuade the cross-gcc to use the things in /usr/bin/, but it really doesn't want to do that. (5) The binutils installer creates a supplementary target-ld.bfd that's a hardlink to target-ld. It doesn't, however, supply a manual page for this. Is there a way to tell rpmlint that this is correct? Or should I just discard the ld.bfd entirely? What is it for, anyway? I could even link the manual page, I suppose. And for cross-gcc: (6) I see devel-file-in-non-devel-package warnings for bits of gcc's internal workings (such as libgcc.a). These are required by gcc to be able to work at all, so can't sensibly be split into a separate package. Is there a way to tell rpmlint that these belong here? (7) The common manpage and translation RPM triggers a no-binary warning as for cross-binutils. (8) The package installs gpl.7.gz and similar common-looking manpages in man7. Is this a bad idea, just in case there's a conflict with another package wanting to do the same? Is there/ should there be a common GPL licence text RPM with these files in it that RPMs can be made dependent on? Thanks, David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On 2012-01-03 16:07, Jan Kratochvil wrote: If you never do a build in Rawhide - your latest build is the F16 one - Rawhide automatically inherits the F16 (or older) builds. I find it useful. Me too, but beware, sometimes the inheritance is explicitly disabled. http://lists.fedoraproject.org/pipermail/devel/2011-January/147592.html Once you do a first Rawhide build I do not know how to revert it. In my experience inheritance starts to work again after the next release. So if you built for f17 rawhide, when rawhide becomes f18 it starts to pull in f17 stuff again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some advice on best packaging practices for a tricky package?
On Wed, Jan 4, 2012 at 2:14 PM, David Howells dhowe...@redhat.com wrote:
Hi,
I've produced a pair of specfiles that I'm aiming to get into Fedora that take
the standard Fedora binutils and gcc SRPM sources and patches and produce a
series of cross-compilation binutils and gcc RPMs for all the Linux kernel
arches that I can manage to get working.
The inclusion request BZs can be found here:
cross-binutils: https://bugzilla.redhat.com/show_bug.cgi?id=761619
cross-gcc: https://bugzilla.redhat.com/show_bug.cgi?id=766166
However, there are a number of warnings that rpmlint produces that I'd like
some advice on. For cross-binutils:
(1) As each set of cross-binutils manual pages is the same as every other set
(and the core set come to that), I've stuffed the base manual pages in
their own RPM and put symlinks to them from the individual arch RPMs.
However, this results in lots of dangling-relative-symlink warnings,
even though the targets are in another RPM passed to rpmlint.
Can I make rpmlint ignore these?
Probably not, but zero rpmlint output isn't required, although one
should do as much as possible to fix the problems.
(2) The manual pages and translation files RPM gets the warning no-binary -
which is true.
Is there any way to make the spec file produce a noarch RPM at the same
time as a bunch of binary RPMs?
Within any sub-package you can specify BuildArch: noarch since the
same package can be installed regardless of arch.
%package doc
Summary: Documentation and man pages for %{name}
BuildArch: noarch
Requires: %{name} = %{version}-%{release}
%description
...
or something like that.
(4) The binutils installer would like to create /usr/target/. I'm creating
/usr/cross/target/ to group all the stuff together into one dir under
/usr. However, rpmlint likes neither of these and gives a
non-standard-dir-in-usr warning.
Should I put the stuff somewhere else? /usr/lib/ or /usr/libexec/
perhaps? I've tried to persuade the cross-gcc to use the things in
/usr/bin/, but it really doesn't want to do that.
Not sure here. Maybe they should be /usr/lib/target. I as /usr/lib
and not /usr/lib{,64} because lib64 I would think should be only for
x86_64 libraries.
(5) The binutils installer creates a supplementary target-ld.bfd that's a
hardlink to target-ld. It doesn't, however, supply a manual page for
this.
Is there a way to tell rpmlint that this is correct? Or should I just
discard the ld.bfd entirely? What is it for, anyway? I could even link
the manual page, I suppose.
If you want to keep them then symlinking the man pages would work.
And for cross-gcc:
(7) The common manpage and translation RPM triggers a no-binary warning as
for cross-binutils.
Same as #2 above.
(8) The package installs gpl.7.gz and similar common-looking manpages in
man7.
Is this a bad idea, just in case there's a conflict with another package
wanting to do the same?
Is there/ should there be a common GPL licence text RPM with these files
in it that RPMs can be made dependent on?
You'll have to take a look and see what's in them. You can run man and
add the path to the file (it doesn't have to be installed) to see what
they contain.
man /path/to/gpl.7.gz
I quick check didn't find any other packages providing gpl.7
# repoquery --whatprovides /usr/share/man/man7/gpl.7*
no output
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Wed, Jan 04, 2012 at 10:22:21PM +0200, Ville Skyttä wrote: On 2012-01-03 16:07, Jan Kratochvil wrote: If you never do a build in Rawhide - your latest build is the F16 one - Rawhide automatically inherits the F16 (or older) builds. I find it useful. Me too, but beware, sometimes the inheritance is explicitly disabled. http://lists.fedoraproject.org/pipermail/devel/2011-January/147592.html Dennis has talked about explicitly disabling inheritance at a certain point in the cycle (maybe even when we branch) so that this is more predictable but I don't think it's gotten out of the thinking about it stage. -Toshio pgpJMuWe6oE4z.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
On Wed, 2012-01-04 at 13:14 +, mike cloaked wrote: If the Gnome decision is for tracker to be there by default then that is a Gnome dev decision, and Gnome users can switch it off if they know how to and want to do so - but why was the decision made to set it up and running for other desktops? Give KDE and XFCE and LXDE users the choice if they want it but surely the default there should be off and not on? KDE, Xfce and LXDE SIGs could certainly choose to configure the KDE, Xfce and LXDE spins such that tracker is disabled or not included. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
Am 04.01.2012 22:02, schrieb Adam Williamson: On Wed, 2012-01-04 at 13:14 +, mike cloaked wrote: If the Gnome decision is for tracker to be there by default then that is a Gnome dev decision, and Gnome users can switch it off if they know how to and want to do so - but why was the decision made to set it up and running for other desktops? Give KDE and XFCE and LXDE users the choice if they want it but surely the default there should be off and not on? KDE, Xfce and LXDE SIGs could certainly choose to configure the KDE, Xfce and LXDE spins such that tracker is disabled or not included. One good way to disable tracker for non Gnome desktops could be to change the OnlyShowIn=GNOME;KDE;XFCE; line of the tracker-desktop-files to OnlyShowIn=GNOME; or did I missunderstood the OnlyShowIn directive? Regards, Heiko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some advice on best packaging practices for a tricky package?
David Howells wrote: (1) As each set of cross-binutils manual pages is the same as every other set (and the core set come to that), I've stuffed the base manual pages in their own RPM and put symlinks to them from the individual arch RPMs. However, this results in lots of dangling-relative-symlink warnings, even though the targets are in another RPM passed to rpmlint. Can I make rpmlint ignore these? Just ignore rpmlint there. :-) If you have proper Requires in place to ensure the symlink targets will actually be installed, it's fine. (2) The manual pages and translation files RPM gets the warning no-binary - which is true. Is there any way to make the spec file produce a noarch RPM at the same time as a bunch of binary RPMs? Yes, it's called noarch subpackages and has been supported in Fedora for a while. Just declare the subpackage as: BuildArch: noarch Note that the main package MUST be arch-specific if you have any arch- specific subpackages, you cannot have arch-specific subpackages of a noarch package, only noarch subpackages of an arch-specific package. (3) The binutils installation installs some hard links and these cause rpmlint to issue cross-directory-hard-link warnings. For instance the following are hardlinked together: /usr/cross/alpha-linux-gnu/bin/ar /usr/bin/alpha-linux-gnu-ar Should I manually turn the hardlinked variants into copies? Or symlink between them? There too I think you can ignore rpmlint's warning. (4) The binutils installer would like to create /usr/target/. I'm creating /usr/cross/target/ to group all the stuff together into one dir under /usr. However, rpmlint likes neither of these and gives a non-standard-dir-in-usr warning. Should I put the stuff somewhere else? /usr/lib/ or /usr/libexec/ perhaps? I've tried to persuade the cross-gcc to use the things in /usr/bin/, but it really doesn't want to do that. /usr/target is the standard location for cross toolchains, and cross toolchains (and ONLY cross toolchains) are allowed to use such a location (though IIRC it never got officially codified in our guidelines because the cross-compiler guidelines never got formalized; but de facto, the existing cross compiler packages already use this). /usr/cross/target is entirely non-standard and IMHO a bad idea. (5) The binutils installer creates a supplementary target-ld.bfd that's a hardlink to target-ld. It doesn't, however, supply a manual page for this. Is there a way to tell rpmlint that this is correct? Or should I just discard the ld.bfd entirely? What is it for, anyway? I could even link the manual page, I suppose. There is no requirement that binaries have manpages in Fedora. Though in this case, just link the manpage. The purpose of ld.bfd is that this is always the regular BFD-based GNU ld whereas just ld can be e.g. gold. And for cross-gcc: (6) I see devel-file-in-non-devel-package warnings for bits of gcc's internal workings (such as libgcc.a). These are required by gcc to be able to work at all, so can't sensibly be split into a separate package. Is there a way to tell rpmlint that these belong here? Again, ignore rpmlint. Compilers are explicitly allowed to ship devel files. (7) The common manpage and translation RPM triggers a no-binary warning as for cross-binutils. See (2). (8) The package installs gpl.7.gz and similar common-looking manpages in man7. Is this a bad idea, just in case there's a conflict with another package wanting to do the same? Yes. Don't package this. We don't normally ship licenses as manpages. See the next paragraph for what to do instead. Is there/ should there be a common GPL licence text RPM with these files in it that RPMs can be made dependent on? Ship the license with %doc COPYING, in a package which is required by all the other subpackages. (If given only a file name without a path, %doc automatically creates a unique path for the package to ship the text file in.) For legal reasons, every package MUST carry its license in at least one subpackage, and ALL subpackages must either carry the license or Require one of the subpackages which do. A common license package for the whole distribution (like Debian does it) does NOT comply with the GPL. The packages are not necessarily distributed as part of the distribution, and the GPL explicitly requires every GPLed package to carry a copy of the GPL, no matter whether the distribution already has one. In short, there's no requirement that you have zero rpmlint output, and it's normal that you have some bogus complaints for a cross-compilation toolchain, which is always a special case. But as I mentioned above, there are a few things you need to fix. Kevin Kofler --
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Jan Kratochvil wrote: Once you do a first Rawhide build I do not know how to revert it. Untag all the Rawhide builds with koji untag-pkg f17 NVR. Be warned that rel-eng is going to yell at you if you do this without ensuring that the EVR inherited from F16 is newer. FESCo decided that EVRs are not supposed to go backwards, even in Rawhide (which I think is a quite silly policy for Rawhide, but that's what that time's FESCo decided and hasn't been overturned since). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On 12/31/2011 12:56 PM, Jakub Jelinek wrote: Hi! As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed a test mass rebuild of rawhide (December 23th package list) using gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the list packages that fail for non-gcc related reasons. What can packagers do now to minimize the number of FTBS later? I noticed we have aa package in koji/rwhide that we can work with. How should we proceed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad package selection practices in Fedora packages
On Wed, Jan 4, 2012 at 10:40 PM, Olav Vitters o...@vitters.nl wrote: On Wed, Jan 04, 2012 at 03:09:07PM +0900, Joel Rees wrote: I suppose I have to go to the gnome lists and raise Cain about this kind of fundamental mis-engineering? If you want bugs to be fixed, then please file bugreports. I'm wondering if I'm the only one who sees the problems here. I suppose I'm going to have to register over there, get on the list, file the bug, and start teaching them the meaning of problem complexity, which they will initially see as rabble-rousing from an outsider. (Much as I'm sure my first post is seen here.) More time I don't have, especially if I take the time to avoid looking like a troll. Tracker should NOT have a noticeable impact on performance (in the default config). They keep saying that. They are wrong. They don't seem to understand some fundamental problems in the tech, which is demonstrated by their default setup. Of course it'll have some measurable impact, but if you can notice the impact in the default configuration, then something is wrong. How many cores, how much RAM, how fast are your CPUs, how much extra disk space before there is no measurable impact? What does this do to the low-power machines that we should all be switching to for our primary workstations? How does this scale across the network when you have, say, just 40 thin clients and a primary file/workload server in a classroom setting, for an easy example? And what does it do to security? Why is there a tracker-flickr that has to be turned off, and what was the user that tracker-flickr was running as? And what was it reporting back to who-knows-where through that social network? Who let that run that way and why? From what I understood (before GNOME 3.0), tracker was changed so the performance impact is not noticeable. E.g. I have tracker running but I don't notice the impact of it. I do not have an SSD. I think I missed that other thread about misusing the kernel, so have to read up on what was said there. What has been said has been missing the point. The sort of desktop search that they are trying to enable falls into a class of problem which must be solved by programs that, when you class them as mathematical languages, are known as an unrestricted grammars. Unrestricted grammars will sometimes go into serious recursion thrashing, trying different branches of solutions and throwing them away. That's the way they work. You avoid that somewhat in thjis case by pre-searching the file system, and that pre-search was what killed the overall system response time for the first several hours (days in some cases) after a new install. But the pre-search was searching things it should not have been searching (which is part of the reason for the huge startup load). By default, each user should have his own database, and nothing outside that user's own file (sub)system should be in it. By default, that database should not be built until the first time the user goes to use the thing, and should only be built for the parts that are being searched. But those defaults conflict with the desire to make search results available without wait the first time the user wants to search. They have not dealt properly with those sorts of conflicting definitions in the design. And then there are those programmers who think that this will be a cool way to finally get a handle on their source code. No. That does not work. Not if you expect to use the machine for any other job, not if you expect to develop code on the same machine. Even when the indexing operation doesn't clash with a running build, indexing all those source files would be a huge burden on however many cores you have. If you want to have /usr/share indexed, it should be a separate index, owned by a man user. (Don't get me started on ACLs and capabilities. Not today, not in this thread.) No one should ever want to use this desktop search function to index /bin or /usr/bin, much less /sbin or /usr/sbin. (And there's another tangent I want to avoid for now.) In fact, there is very little outside /home that should ever be indexed. Backup file systems, maybe, but the indexes in those cases should look quite a bit different. The locate databases should be sufficient for those. PS: Didn't know the term raise Cain, but if you mean: To be 'raising Cain' is to be causing trouble or creating an uproar. Cain was a rebel and a rule breaker. Caused his parents a lot of grief. Raising Cain is often used as an idiom for causing trouble, but the proper use of the expression is the converse, the various ways his parents tried to teach him the error of his ways (which Cain, of course, considered a lot of trouble). Don't do above @ GNOME, would only cause you to be banned. If I allocate the time for it, I'll be sure to do so carefully, and try not to sound as much like a stupid know-it-all as I'm sounding here. I'm posting here, using language that is more blunt than I
unwanted devel-dependencies (currently perl)
why in the world introducing updates the installation of devel-packages? yum remove mod_perl-devel-2.0.5-1.fc15.x86_64 would remove mod_perl and all it's dependencies yum remove httpd-devel would remove mod_perl and all it's dependencies yum remove apr-util-devel would remove httpd-devel what is normally not a problem but with the cross-dependency - see above ___ all few months there are introduced unneeded devel-dependencies with updates which will be fixed sometimes later, but that causes everytime work to try what of them you can remove currently i would suggest here more care to the maintainers normally a installation should not need a single devel-package signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unwanted devel-dependencies (currently perl)
On 2012-01-05 03:25, Reindl Harald wrote: why in the world introducing updates the installation of devel-packages? Packaging bugs, in this case https://bugzilla.redhat.com/748362 . Looks like I didn't end up in Cc for that bug so I've missed the mail for comment 4, but I'll look into pushing the update later today. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 430072] xdg-open should call mimeopen with -L option
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=430072 --- Comment #25 from Petr Pisar ppi...@redhat.com 2012-01-04 03:31:38 EST --- perl-File-MimeInfo upstream has decided to follow symlinks by default since version 0.16. -- 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 770260] Update perl-DateTime-Format-W3CDTF to version 0.06 from CPAN
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=770260 --- Comment #4 from Petr Šabata psab...@redhat.com 2012-01-04 04:04:51 EST --- (In reply to comment #3) rewriting a package is not the way I understand but I was under the chicken or the egg dead line. How do you officially trigger a regular update for a Perl package? By regular update I meant just changing the existing package (and pushing the changes or possibly sending the package maintainer a spec patch), keeping changelog and such. The package is now in Rawhide. Let me know if you need it in stable Fedora releases and which. -- 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 771781] New: Numerous Use of qw(...) as parentheses is deprecated messages
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Numerous Use of qw(...) as parentheses is deprecated messages
https://bugzilla.redhat.com/show_bug.cgi?id=771781
Summary: Numerous Use of qw(...) as parentheses is deprecated
messages
Product: Fedora
Version: 16
Platform: Unspecified
OS/Version: Linux
Status: NEW
Severity: medium
Priority: unspecified
Component: perl-IPTables-ChainMgr
AssignedTo: m...@redhat.com
ReportedBy: fr...@crawford.emu.id.au
QAContact: extras...@fedoraproject.org
CC: m...@redhat.com, fedora-perl-devel-l...@redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
Due to a change in perl syntax for Perl 5.14 and onwards, the use of qw(...) in
specific contexts is now disallowed. This generates lots of messages of the
form:
Use of qw(...) as parentheses is deprecated at
/usr/share/perl5/vendor_perl/IPTables/ChainMgr.pm line 158.
Version-Release number of selected component (if applicable):
perl-IPTables-ChainMgr-0.9-8.fc16.noarch
perl-5.14.2-191.fc16.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Found from psad -S but possible from any use of routine.
2.
3.
Actual results:
Numerous messages about deprecated feature.
Expected results:
No deprecated messages
Additional info:
Reading some of the perl list this only occurs in statements of the form:
for my $var qw(...) { ... }
and is fixed by the addition of (), i.e.
for my $var (qw(...)) { ... }
--
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 DBIx-DBSchema-0.40.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-DBIx-DBSchema: 2b4be96f6c8301b811c3e6edd35c1aa9 DBIx-DBSchema-0.40.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-DBIx-DBSchema] Upstream update. Modernize specfile.
commit f161883ed33067e1f3be27c5343524494bcfdc5b
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 5 07:49:20 2012 +0100
Upstream update.
Modernize specfile.
.gitignore |2 +-
perl-DBIx-DBSchema.spec | 14 ++
sources |2 +-
3 files changed, 8 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ad4be42..aee816a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-DBIx-DBSchema-0.39.tar.gz
+/DBIx-DBSchema-0.40.tar.gz
diff --git a/perl-DBIx-DBSchema.spec b/perl-DBIx-DBSchema.spec
index be36c51..ae4c641 100644
--- a/perl-DBIx-DBSchema.spec
+++ b/perl-DBIx-DBSchema.spec
@@ -1,13 +1,12 @@
Name: perl-DBIx-DBSchema
-Version:0.39
-Release:4%{?dist}
+Version:0.40
+Release:1%{?dist}
Summary:Database-independent schema objects
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DBIx-DBSchema/
Source0:
http://www.cpan.org/authors/id/I/IV/IVAN/DBIx-DBSchema-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
@@ -41,7 +40,6 @@ make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
@@ -52,10 +50,6 @@ chmod -R u+w $RPM_BUILD_ROOT/*
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
%defattr(-,root,root,-)
%doc Changes README
@@ -64,6 +58,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Jan 05 2012 Ralf Corsépius corse...@fedoraproject.org - 0.40-1
+- Upstream update.
+- Modernize specfile.
+
* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.39-4
- Perl mass rebuild
diff --git a/sources b/sources
index 674a280..1f8be22 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-532a5cfa5bac9f947ef9b960b915a88f DBIx-DBSchema-0.39.tar.gz
+2b4be96f6c8301b811c3e6edd35c1aa9 DBIx-DBSchema-0.40.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
File IPC-Run3-0.045.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-IPC-Run3: e8913c03a8a6c6297a6e622d656e343a IPC-Run3-0.045.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-IPC-Run3] Upstream update. Modernize spec file.
commit 1ea3c26a801817220e7b964035895b2ffb81f4c0
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Jan 5 07:54:39 2012 +0100
Upstream update.
Modernize spec file.
.gitignore |2 +-
perl-IPC-Run3.spec | 14 ++
sources|2 +-
3 files changed, 8 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1944fab..07cec6f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-IPC-Run3-0.044.tar.gz
+/IPC-Run3-0.045.tar.gz
diff --git a/perl-IPC-Run3.spec b/perl-IPC-Run3.spec
index d11c097..2ca375f 100644
--- a/perl-IPC-Run3.spec
+++ b/perl-IPC-Run3.spec
@@ -1,12 +1,11 @@
Name: perl-IPC-Run3
-Version:0.044
-Release:4%{?dist}
+Version:0.045
+Release:1%{?dist}
Summary:Run a subprocess in batch mode
License:(GPL+ or Artistic) or BSD
Group: Development/Libraries
URL:http://search.cpan.org/dist/IPC-Run3/
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/IPC-Run3-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More) = 0.31
@@ -32,8 +31,6 @@ find -type f -exec chmod -x {} \;
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -44,9 +41,6 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
@@ -54,6 +48,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Jan 05 2012 Ralf Corsépius corse...@fedoraproject.org - 0.045-1
+- Upstream update.
+- Modernize spec file.
+
* Mon Jun 20 2011 Marcela Mašláňová mmasl...@redhat.com - 0.044-4
- Perl mass rebuild
diff --git a/sources b/sources
index 03d508a..77c40e6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7df73a65d9efc7b9e7eb04075ff1fd8f IPC-Run3-0.044.tar.gz
+e8913c03a8a6c6297a6e622d656e343a IPC-Run3-0.045.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-DBIx-DBSchema/f16] Upstream update. Modernize specfile.
Summary of changes: f161883... Upstream update. Modernize specfile. (*) (*) This commit already existed in another branch; no separate mail sent -- 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-IPC-Run3/f16] Upstream update. Modernize spec file.
Summary of changes: 1ea3c26... Upstream update. Modernize spec file. (*) (*) This commit already existed in another branch; no separate mail sent -- 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-DBIx-DBSchema/f15] (3 commits) ...Merge cleanup.
Summary of changes: 0ed2cfd... Perl mass rebuild (*) f161883... Upstream update. Modernize specfile. (*) d085461... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- 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-DBIx-DBSchema/f15: 3/3] Merge cleanup.
commit d085461fb04f028c105b38d74ee47c2aead942e9 Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Jan 5 08:00:10 2012 +0100 Merge cleanup. perl-DBIx-DBSchema.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-DBIx-DBSchema.spec b/perl-DBIx-DBSchema.spec index ae4c641..503b6f8 100644 --- a/perl-DBIx-DBSchema.spec +++ b/perl-DBIx-DBSchema.spec @@ -62,9 +62,6 @@ make test - Upstream update. - Modernize specfile. -* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.39-4 -- Perl mass rebuild - * Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.39-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild -- 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-IPC-Run3/f15: 3/3] Merge cleanup.
commit 2d6029cdda5e360b5eee5b0bc2c6076080821551 Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Jan 5 08:02:07 2012 +0100 Merge cleanup. perl-IPC-Run3.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-IPC-Run3.spec b/perl-IPC-Run3.spec index 2ca375f..29510cf 100644 --- a/perl-IPC-Run3.spec +++ b/perl-IPC-Run3.spec @@ -52,9 +52,6 @@ make test - Upstream update. - Modernize spec file. -* Mon Jun 20 2011 Marcela Mašláňová mmasl...@redhat.com - 0.044-4 -- Perl mass rebuild - * Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.044-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild -- 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
[389-devel] Please review: bak2db gets stuck in infinite loop
https://fedorahosted.org/389/ticket/4 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Rebuild for GCC-4.7
starting immediatly there is going to be a mass rebuild of rawhide for gcc-4.7 that landed yesterday. as approved by FESCo (https://fedorahosted.org/fesco/ticket/739) packagers will have just over a week, until Thursday Jan 12 to build packages themselves. After that date releng will kick off an automated mass rebuild of everything else. So please get building as Fedora 17 branching is less than 5 weeks away. we need all built by then Thanks Releng ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
