Re: Koji build failure with coreutils-7.5
Todd Zullinger wrote:
I tried to build a git update into dist-f12-openssl earlier and had it
die in %doc with an error from cp¹:
cp: preserving times for
`/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks':
Function not implemented
Hi Todd,
This is because that latest version of coreutils tries to preserve
permissions on symlinks when it thinks that is possible.
It determines whether to try by testing at configure time for the
existence of the utimensat function. If it can compile and link
against that function, then the resulting executable will call it
and report any failure. The trouble is when you configure on a system
with recent libraries and headers, yet *run* with a kernel
that is old enough as to lack the syscall.
Normally in coreutils, I try not to pollute the tools with run-time
work-around code that will be obsolete in a few years, but this
time, it appears to be required, due to the distance between koji's
build and run-time environments.
The solution is probably something like this:
From 57d640722e04352a468cc595b0b94dbceaec4871 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 24 Aug 2009 08:21:47 +0200
Subject: [PATCH] cp: ignore obscure failure to preserve symlink time stamps,
when run on a kernel older than what was implied by headers and
libraries tested at configure time.
* src/copy.c (utimens_symlink): Ignore failure when errno == ENOSYS.
* NEWS (Bug fixes): Mention it.
Reported by Todd Zullinger and Kamil Dudka.
---
NEWS |6 ++
src/copy.c |8 +++-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/NEWS b/NEWS
index 2c744b1..c125b31 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU coreutils NEWS-*-
outline -*-
* Noteworthy changes in release ?.? (-??-??) [?]
+** Bug fixes
+
+ cp, mv now ignore failure to preserve a symlink time stamp, when it is
+ due to their running on a kernel older than what was implied by headers
+ and libraries tested at configure time.
+
* Noteworthy changes in release 7.5 (2009-08-20) [stable]
diff --git a/src/copy.c b/src/copy.c
index bf9230b..8fc4b68 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -124,7 +124,13 @@ static inline int
utimens_symlink (char const *file, struct timespec const *timespec)
{
#if HAVE_UTIMENSAT
- return utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ int err = utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ /* When configuring on a system with new headers and libraries, and
+ running on one with a kernel that is old enough to lack the syscall,
+ utimensat fails with ENOTSUP. Ignore that. */
+ if (err errno == ENOSYS)
+err = 0;
+ return err;
#else
/* Don't set errno=ENOTSUP here as we don't want
to output an error message for this case. */
--
1.6.4.378.g88f2f
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
On Fri, Aug 21, 2009 at 03:07:19PM +0200, Kevin Kofler wrote: Jindrich Novy wrote: Nope, it is intentional. It is needed to somehow distinguish the noarch and arch-dependent part. So package texlive-csplain contains the noarch bits and texlive-csplain.ARCH ships the binaries. Wouldn't texlive-csplain-libs or texlive-csplain-bin be more compliant to our guidelines? The .ARCH postfix is actually derived from the TL metadata dependencies but indeed it doesn't look so good. The '-libs' is not appropriate as only binaries which go to /usr/bin are packaged. I will switch to the '-bin' postfix in the next build. Jindrich Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
On Fri, Aug 21, 2009 at 04:21:35PM +0300, Jussi Lehtola wrote:
On Thu, 2009-08-20 at 17:10 +0200, Jindrich Novy wrote:
On Thu, Aug 20, 2009 at 04:48:49PM +0300, Jussi Lehtola wrote:
It seems your spec making program has some bugs, as some packages have
names such as texlive-csplain.ARCH, this probably shouldn't be..?
Nope, it is intentional. It is needed to somehow distinguish the
noarch and arch-dependent part. So package texlive-csplain contains
the noarch bits and texlive-csplain.ARCH ships the binaries.
Wouldn't it be better to have texlive-csplain%{_isa} shipping the arch
dependent bits and a texlive-csplain-common.noarch shipping the arch
independent stuff? That would be more in line with other packages.
Hmm, this is even better idea. It was not originally possible in the
first designed TL packaging scheme (noarch and binary bits were
created from one src.rpm what prevented arch/noarch package named in
the same way) but now it is actually possible because binaries are built
separately.
Thanks,
Jindrich
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On Sun, Aug 23, 2009 at 09:32:11PM -0700, Elio Maldonado wrote: You are right. By reading at Makefile.common it seems that make new-source nss-softokn-3.12.3.99.3-stripped.tar.bz2 would be the way to place them in the lookaside cache (after I do the cvs remove on them). You probably need to run it using the variable FILES: make new-source FILES=nss-softokn-3.12.3.99.3-stripped.tar.bz2 Regards Till pgpZEIjAOa4Yk.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/nss-softokn/devel nss-softokn-3.12.3.99.3-stripped.tar.bz2, NONE, 1.1
On Sun, 23 Aug 2009 21:32:11 -0700, Elio wrote: Conrad, You are right. By reading at Makefile.common it seems that make new-source nss-softokn-3.12.3.99.3-stripped.tar.bz2 would be the way to place them in the lookaside cache (after I do the cvs remove on them). The nss/nss-softokn packages likely would benefit from a careful review. Many enabled explicit Conflicts, many explicit Requires and Provides which are commented out. Provides with = version range. Even explicit Provides for SONAMEs (!). This is scary. Such lines in a spec file ask for comments in the spec file. Many /sbin/ldconfig /dev/null 2/dev/null calls in shell scriptlets (is there strange documentation somewhere that tells a packager to do it that way?). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Jim Meyering wrote: Todd Zullinger wrote: I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented Hi Todd, This is because that latest version of coreutils tries to preserve permissions on symlinks when it thinks that is possible. It determines whether to try by testing at configure time for the existence of the utimensat function. If it can compile and link against that function, then the resulting executable will call it and report any failure. The trouble is when you configure on a system with recent libraries and headers, yet *run* with a kernel that is old enough as to lack the syscall. By the way, to those who maintain koji, It is subtly dangerous to configure a package against headers and libraries that are not well-matched with the kernel. In this case, new headers/libraries suggest a function is available, as detected by a standard autoconf function-existence check. Yet only at run time do we detect (via surprising failure with ENOSYS) that the kernel is too old to support the function that we were led to believe would be available. Here, it wasn't that big a deal, but I can easily imagine this sort of mismatch leading to a more serious problem. It is fine to have a kernel *newer* than would be suggested by headers/libraries. Now you've seen why is risky to use one that is older. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
On 08/24/2009 03:11 AM, Jim Meyering wrote: Jim Meyering wrote: Todd Zullinger wrote: I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented Hi Todd, This is because that latest version of coreutils tries to preserve permissions on symlinks when it thinks that is possible. It determines whether to try by testing at configure time for the existence of the utimensat function. If it can compile and link against that function, then the resulting executable will call it and report any failure. The trouble is when you configure on a system with recent libraries and headers, yet *run* with a kernel that is old enough as to lack the syscall. By the way, to those who maintain koji, It is subtly dangerous to configure a package against headers and libraries that are not well-matched with the kernel. In this case, new headers/libraries suggest a function is available, as detected by a standard autoconf function-existence check. Yet only at run time do we detect (via surprising failure with ENOSYS) that the kernel is too old to support the function that we were led to believe would be available. Here, it wasn't that big a deal, but I can easily imagine this sort of mismatch leading to a more serious problem. It is fine to have a kernel *newer* than would be suggested by headers/libraries. Now you've seen why is risky to use one that is older. Unfortunately this is quite common for build machines... as it is easy to build any number of buildroots for any number of OS's. But since one cannot chroot into a new kernel, to build with new libraries/headers, the kernel remains inevitably older than that which the machine builds. The only other alternative I can think of is booting a virtual machine for each package build, which I imagine is probably too costly/painful to consider for koji... Outside of koji, speaking as a kernel developer, people DO boot older kernels on newer userlands -- particularly if they are having a problem with their hardware. So it is entirely possible that a run-time check for a newly-added syscall is the only way to make things work. :( That's what people had to do with sendfile(2) for a long time. I imagine most other newly-added Linux syscalls don't find their way into core daemons and utilities, so most people don't notice. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Jeff Garzik wrote:
On 08/24/2009 02:26 AM, Jim Meyering wrote:
+** Bug fixes
+
+ cp, mv now ignore failure to preserve a symlink time stamp, when it is
+ due to their running on a kernel older than what was implied by headers
+ and libraries tested at configure time.
+
Yeah, this will be easy to trigger for a while, unfortunately...
--- a/src/copy.c
+++ b/src/copy.c
@@ -124,7 +124,13 @@ static inline int
utimens_symlink (char const *file, struct timespec const *timespec)
{
#if HAVE_UTIMENSAT
- return utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ int err = utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ /* When configuring on a system with new headers and libraries, and
+ running on one with a kernel that is old enough to lack the syscall,
+ utimensat fails with ENOTSUP. Ignore that. */
+ if (err errno == ENOSYS)
+err = 0;
+ return err;
Seems like the comment (ENOTSUP) needs to be changed to match the code
(ENOSYS)?
Yes, indeed. Thanks, Jeff.
I've adjusted that patch to remove the comment mentioning
ENOTSUP in the #else block, too (removed the #else block, actually).
There are too many E{not-supported/not-available} codes.
ENOTSUP is what is returned by coreutils/gnulib's lgetfilecon
wrapper, yet some versions fail with errno==ENODATA, hence
the errno_unsupported function, which happens to work also with
xattr stuff. But not here, since this function fails with ENOSYS.
And I don't want to relax errno_unsupported to accept ENOSYS,
in case some legit utimensat fails with errno==ENODATA.
From 3f71bc0a318857d43c419b1fa2df28a7de610c1c Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 24 Aug 2009 08:21:47 +0200
Subject: [PATCH] cp: ignore obscure failure to preserve symlink time stamps,
when run on a kernel older than what was implied by headers and
libraries tested at configure time.
* src/copy.c (utimens_symlink): Ignore failure when errno == ENOSYS.
* NEWS (Bug fixes): Mention it.
Reported by Todd Zullinger and Kamil Dudka.
---
NEWS |6 ++
src/copy.c | 15 ++-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/NEWS b/NEWS
index 2c744b1..c125b31 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU coreutils NEWS-*-
outline -*-
* Noteworthy changes in release ?.? (-??-??) [?]
+** Bug fixes
+
+ cp, mv now ignore failure to preserve a symlink time stamp, when it is
+ due to their running on a kernel older than what was implied by headers
+ and libraries tested at configure time.
+
* Noteworthy changes in release 7.5 (2009-08-20) [stable]
diff --git a/src/copy.c b/src/copy.c
index bf9230b..b5cf64c 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -123,13 +123,18 @@ static char const *top_level_dst_name;
static inline int
utimens_symlink (char const *file, struct timespec const *timespec)
{
+ int err = 0;
+
#if HAVE_UTIMENSAT
- return utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
-#else
- /* Don't set errno=ENOTSUP here as we don't want
- to output an error message for this case. */
- return 0;
+ err = utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
+ /* When configuring on a system with new headers and libraries, and
+ running on one with a kernel that is old enough to lack the syscall,
+ utimensat fails with ENOSYS. Ignore that. */
+ if (err errno == ENOSYS)
+err = 0;
#endif
+
+ return err;
}
/* Perform the O(1) btrfs clone operation, if possible.
--
1.6.4.378.g88f2f
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
I agree with Jeff here. Sorry, Jim. I know life is too complicated to keep track of, but that's just how it is. A robustly-written application really needs to distinguish the build-time vs runtime dependencies it has. If you want to make an assumption at run time, then you really have to make sure that they way you were compiled encodes versions requirement that demand a platform where your assumptions are true. The libc stub/not-stub checks at build time do not give you this. When you link against a libc that provides a real definition for the foobar syscall, the foobar symbol has the same symbol version as the older libc that defined an ENOSYS stub for foobar. In fact, libc itself may very well be built so that it works on kernel vintages both with or without foobar, so that you cannot tell at link time whether foobar will return ENOSYS at runtime even when using the very same libc. The bottom line is that a properly portable program has to check for ENOSYS at runtime now if the function in question has ever existed in a libc capable of running on a kernel that does not support that system call. Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Jeff Garzik wrote: On 08/24/2009 03:11 AM, Jim Meyering wrote: Jim Meyering wrote: Todd Zullinger wrote: I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented Hi Todd, This is because that latest version of coreutils tries to preserve permissions on symlinks when it thinks that is possible. It determines whether to try by testing at configure time for the existence of the utimensat function. If it can compile and link against that function, then the resulting executable will call it and report any failure. The trouble is when you configure on a system with recent libraries and headers, yet *run* with a kernel that is old enough as to lack the syscall. By the way, to those who maintain koji, It is subtly dangerous to configure a package against headers and libraries that are not well-matched with the kernel. In this case, new headers/libraries suggest a function is available, as detected by a standard autoconf function-existence check. Yet only at run time do we detect (via surprising failure with ENOSYS) that the kernel is too old to support the function that we were led to believe would be available. Here, it wasn't that big a deal, but I can easily imagine this sort of mismatch leading to a more serious problem. It is fine to have a kernel *newer* than would be suggested by headers/libraries. Now you've seen why is risky to use one that is older. Unfortunately this is quite common for build machines... as it is easy to build any number of buildroots for any number of OS's. But since one cannot chroot into a new kernel, to build with new libraries/headers, the kernel remains inevitably older than that which the machine builds. The only other alternative I can think of is booting a virtual machine for each package build, which I imagine is probably too costly/painful to consider for koji... Actually, that sounds like the real solution: build packages for F11 in a VM running F11's base kernel, build packages for F10 in a VM running F10's base kernel, etc. coreutils/Fedora had similar hassles with the various *at functions, too (openat, fstatat, etc.), and I suspect we haven't seen the last of this sort of problem. But maybe it is infrequent enough not to deserve a real solution. Outside of koji, speaking as a kernel developer, people DO boot older kernels on newer userlands -- particularly if they are having a problem with their hardware. So it is entirely possible that a run-time check for a newly-added syscall is the only way to make things work. :( I'm afraid you're right. That's what people had to do with sendfile(2) for a long time. I imagine most other newly-added Linux syscalls don't find their way into core daemons and utilities, so most people don't notice. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Roland McGrath wrote: I agree with Jeff here. Sorry, Jim. I know life is too complicated to Heh, no need to feel sorry, Roland, unless its for the code pollution. It's fixed properly, now. And it's not even that ugly. keep track of, but that's just how it is. A robustly-written application really needs to distinguish the build-time vs runtime dependencies it has. ... The bottom line is that a properly portable program has to check for ENOSYS at runtime now if the function in question has ever existed in a libc capable of running on a kernel that does not support that system call. You should know well that we have to strike a balance here. There is a limit. Work-arounds like this are worthwhile only when the older kernels are in frequent-enough use that not applying the work-around would cause significant risk or discomfort. For example, if I were to make coreutils programs run flawlessly on 2.4.* or earlier kernels even when configured/built against modern headers and libraries, I suspect there would be significant performance degradation in a few key tools. If the degradation didn't impact maintainability, and were negligible when running on modern systems, then it might be ok. Unless someone can point out a flaw that causes real trouble, I'll continue making pragmatic compromises. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Jim Meyering píše v Po 24. 08. 2009 v 11:14 +0200: Roland McGrath wrote: I agree with Jeff here. Sorry, Jim. I know life is too complicated to Heh, no need to feel sorry, Roland, unless its for the code pollution. It's fixed properly, now. And it's not even that ugly. keep track of, but that's just how it is. A robustly-written application really needs to distinguish the build-time vs runtime dependencies it has. ... The bottom line is that a properly portable program has to check for ENOSYS at runtime now if the function in question has ever existed in a libc capable of running on a kernel that does not support that system call. You should know well that we have to strike a balance here. There is a limit. Work-arounds like this are worthwhile only when the older kernels are in frequent-enough use that not applying the work-around would cause significant risk or discomfort. For example, if I were to make coreutils programs run flawlessly on 2.4.* or earlier kernels even when configured/built against modern headers and libraries, I suspect there would be significant performance degradation in a few key tools. If the degradation didn't impact maintainability, and were negligible when running on modern systems, then it might be ok. AFAIK glibc has its minimum kernel requirement and it should be 2.6.18 (RHEL 5) now. In my opinion the rest of user space should expect this as the minimal version too. Unless someone can point out a flaw that causes real trouble, I'll continue making pragmatic compromises. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
On Mon, 24 Aug 2009 01:12:49 -0400, Todd wrote: I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented I _think_ this is due to contrib/hooks being a symlink. A nearly identical spec file worked when Tomas build git-1.6.4 in dist-f12-openssl just a few days ago, but that was with coreutils-7.4-6 in the buildroot. It works for me in mock. Perhaps the problem has something to do with the filesystem or mount options on the build system. Has anyone noticed similar problems? ¹ https://koji.fedoraproject.org/koji/getfile?taskID=1627434name=build.log Hits every package that includes a symlink via %doc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji build failure with coreutils-7.5
Michael Schwendt wrote: On Mon, 24 Aug 2009 01:12:49 -0400, Todd wrote: I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented. Has anyone noticed similar problems? ¹ https://koji.fedoraproject.org/koji/getfile?taskID=1627434name=build.log Hits every package that includes a symlink via %doc. Sorry for that, already solved by coreutils-7.5-2.fc12, now built in koji (and it should be already propagated in build repos as it is part of latest root.log in tasks) Greetings, Ondřej Vašík signature.asc Description: Toto je digitálně podepsaná část zprávy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
2009/8/23 Toshio Kuratomi a.bad...@gmail.com: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. Will all the functionality that Pkgdb offers[1] eventually be added to pages like https://admin.fedoraproject.org/community/?package=0x#package_maintenance so that the Pkgdb web front-end could be obsoleted? [1] Orphaning, co-maintainership applications, etc -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
network issues with kernel-2.6.29.6-217.2.8.fc11.i586
Hi all, I hope somebody can confirm this: The last days I had some trouble with my networking (both wireless and ethernet) in forms of high latency, strange arp behaviour etc. Today I could not even ping anything outside. The problem seemed to be that: 1. arp replys were ignored 2. if arp -s was used, anything else was ignored for the userspace That means: I pinged my nameserver, and tcpdump showed request and replys happily flowing around. But: ping did not get any packet. It reported 100% packet loss. That applies to any other userspace prog that uses a socket. I also had some wireless errors (iwlagn: microcode error) in my dmesg the days before. Currently I am using kernel-2.6.29.6-217.2.8.fc11.i586 and the problem arised after some minutes again. Looks like a buffer run full or somethign... Is there a workaround? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: network issues with kernel-2.6.29.6-217.2.8.fc11.i586
2009/8/24 Christoph Höger choe...@cs.tu-berlin.de: I hope somebody can confirm this: I also had some wireless errors (iwlagn: microcode error) in my dmesg the days before. I can confirm: iwlagn: Microcode SW error detected. Restarting 0x200. With 2.6.29.6-99.fc10.x86_64 04:00.0 Network controller: Intel Corporation PRO/Wireless 5300 AGN [Shiloh] Network Connection -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Sun, Aug 23, 2009 at 9:35 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. For the front-end to be end user suitable it should: * List applications rather than packages * Group them * Provide some kind of rating system to show best rated or most downloaded * Use the application icon if it has one * Make use of the packagekit browser plugin for installation But just letting the user search for random packages should not be the goal imho. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090824 changes
Compose started at Mon Aug 24 06:15:05 UTC 2009 New package ghc-tar Haskell tar library New package hyphen-as Assamese hyphenation rules New package php-ezc-AuthenticationDatabaseTiein Provides a Database filter for the Authentication component New package php-ezc-Feed This component handles parsing and creating RSS1, RSS2 and ATOM feeds Updated Packages: R-Biostrings-2.12.8-1.fc12 -- * Sun Aug 23 2009 pingou pin...@pingoured.fr 2.12.8-1 - Update to 2.12.8 abiword-2.7.9-1.fc12 * Sun Aug 23 2009 Marc Maurer u...@abisource.com - 1:2.7.9-1 - New upstream version bisho-0.11-2.fc12 - * Sun Aug 23 2009 Peter Robinson pbrobin...@gmail.com 0.11-2 - Add missing dep for new release * Wed Aug 12 2009 Peter Robinson pbrobin...@gmail.com 0.11-1 - New upstream 0.11 release control-center-2.27.90-5.fc12 - * Sun Aug 23 2009 Matthias Clasen mcla...@redhat.com 2.27.90-5 - Apply the patch... crm114-0-1.11.20090807.fc12 --- * Sun Aug 23 2009 Dominik Mierzejewski r...@greysector.net 0-1.11.20090807 - updated to 20090807 BlameThorstenAndJenny - dropped upstreamed patch hunks, rebased patch - updated source URL - license changed to GPLv3 - needs release note: .css files format has changed, they must be rebuilt e2fsprogs-1.41.9-1.fc12 --- * Sun Aug 23 2009 Eric Sandeen sand...@redhat.com 1.41.9-1 - New upstream release * Wed Aug 05 2009 Eric Sandeen sand...@redhat.com 1.41.8-6 - Fix filefrag in fallback case - Add e2freefrag e4defrag (experimental) entertainer-0.4.2-6.fc12 * Sun Aug 23 2009 Julian Aloofi julian at, fedoraproject.org 0.4.2-6 - Requires the whole pyclutter package now due to the cairo subpackage removal examiner-0.5-6.fc12 --- * Sun Aug 23 2009 Rakesh Pandit rak...@fedoraproject.org - 0.5-6 - Applied examiner-0.5-examiner_hashes_pl.patch #515452 fence-agents-3.0.2-1.fc12 - gl2ps-1.3.3-1.fc12 -- * Sun Aug 23 2009 Dominik Mierzejewski r...@greysector.net 1.3.3-1 - updated to 1.3.3 - removed calls to exit(3) - added a simple build system (Makefile) - dropped libtool dependency - 1.3.3 added a new symbol, so made it versioned - added examples to -devel docs * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.3.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild gnome-games-2.27.90-2.fc12 -- * Sun Aug 23 2009 Matthias Clasen mcla...@redhat.com 2.27.90-2 - Fix various issues in Mines gnome-screensaver-2.27.0-10.fc12 * Mon Aug 24 2009 Matthias Clasen mcla...@redhat.com 2.27.0-10 - Fix GtkBuilder conversion gourmet-0.15.0-2.fc12 - * Sun Aug 23 2009 Jef Spaleta jspaleta AT fedoraproject DOT org - 0.15.0-1 - Latest upstream release, major changes include plugin system for capabilities * Sun Aug 23 2009 Jef Spaleta jspaleta AT fedoraproject DOT org - 0.15.0-2 - Small buildrequires fix. gphoto2-2.4.7-1.fc12 * Mon Aug 24 2009 Jindrich Novy jn...@redhat.com 2.4.7-1 - update to 2.4.7 hatari-1.3.0-1.fc12 --- * Sat Aug 22 2009 Andrea Musuruane musur...@gmail.com 1.3.0-1 - updated to upstream 1.3.0 - disabled new upstream python UI - updated icon cache snippets - used upstream Mac OS X icons - preserved french man page timestamp kdebase-workspace-4.3.0-9.fc12 -- * Sun Aug 23 2009 Rex Dieter rdie...@fedoraproject.org - 4.3.0-9 - -akonadi: move plasma_engine_calendar here - drop Requires: kdm (F-12+) kdeedu-4.3.0-6.fc12 --- * Sun Aug 23 2009 Rex Dieter rdie...@fedoraproject.org 4.3.0-6 - -kstars-libs subpkg, make -kstars not multilib'd * Thu Aug 20 2009 Rex Dieter rdie...@fedoraproject.org. 4.3.0-5 - add Obsoletes to help multilib upgrades - -marble-libs: move marble plugins here kdelibs-4.3.0-7.fc12 * Sun Aug 23 2009 Rex Dieter rdie...@fedoraproject.org - 4.3.0-7 - buildsys_phonon patch (to be compatible with newer kde-qt.git qt builds) kile-2.1-0.3.b2.fc12 * Sun Aug 23 2009 Rex Dieter rdie...@fedoraproject.org - 2.1-0.3.b2 - kile-2.1b2 klavaro-1.2.4-1.fc12 * Sun Aug 23 2009 Mathieu Bridon boche...@fedoraproject.org - 1.2.3-1 - Update to 1.2.3 * Sun Aug 23 2009 Mathieu Bridon boche...@fedoraproject.org - 1.2.4-1 - Update to 1.2.4 ktorrent-3.2.3-2.fc12 - * Sun Aug 23 2009 Rex Dieter rdie...@fedoraproject.org - 3.2.3-2 - kde-plasma-ktorrent pkg (so main pkg doesn't pull in kdebase-workspace) - -libs to make multilib friendly libicns-0.7.0-3.fc12 * Sun Aug 23 2009 Andrea Musuruane musur...@gmail.com - 0.7.0-3 - Updated to new upstream 0.7.0 that was released without bumping the version mingw32-filesystem-53-1.fc12
Re: Koji build failure with coreutils-7.5
Jim, Jim Meyering wrote: The solution is probably something like this: Excellent, thanks for the quick reply and patch. (And thanks for getting the speedy build Ondřej.) -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Until you have the courage to lose sight of the shore, you will not know the terror of being forever lost at sea. -- Demotivators (www.despair.com) pgpXyGCwBjmgs.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
I honestly threw that Firefox AddOn together in order to scratch an itch that I had, I released it for general consumption because I was hoping someone else could benefit. I honestly never sat down and thought of user vs. developer implications of use or $other. -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On 08/24/2009 06:55 PM, Adam Miller wrote: I honestly threw that Firefox AddOn together in order to scratch an itch that I had, I released it for general consumption because I was hoping someone else could benefit. I honestly never sat down and thought of user vs. developer implications of use or $other. That's perfectly fine and very welcome. We are just taking the opportunity to discuss what should be the right approach going forward. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
2009/8/23 Björn Persson bj...@xn--rombobjrn-67a.se: Debayan Banerjee wrote: 2009/8/24 Björn Persson bj...@xn--rombobjrn-67a.se That's not all that quick. There ought to be a tool for this. Given a package name it should print the dependency tree for that package. It could have an option to suppress packages in the base set. Couldn't Yum be taught to answer that kind of queries? edos-rpmcheck http://www.edos-project.org/xwiki/bin/view/Main/debcheck_home Judging from the description on that page, that's not what I want. It says the program checks whether a package is installable. Yum can do that. I want to check whether a package drags in other packages unnecessarily. Björn Persson Maybe speak to Richard Jones: http://rwmj.wordpress.com/2009/03/25/size-of-rpm-dependencies-2/ -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
On 08/24/2009 07:44 PM, James Antill wrote: On Sun, 2009-08-23 at 20:58 +0200, Björn Persson wrote: Rahul Sundaram wrote: A quick way to actually check for such dependencies is to switch to another desktop environment, say Xfce, remove all the KDE packages and install one of the KDE apps. That's not all that quick. There ought to be a tool for this. Given a package name it should print the dependency tree for that package. It could have an option to suppress packages in the base set. Couldn't Yum be taught to answer that kind of queries? There is already: http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py ...obviously any random custom behaviour (like ignoring packages in @base) is possible, someone just has to write it. Is there a reason this tool is not part of yum-utils? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
On Mon, 24 Aug 2009, Rahul Sundaram wrote: On 08/24/2009 07:44 PM, James Antill wrote: On Sun, 2009-08-23 at 20:58 +0200, Björn Persson wrote: Rahul Sundaram wrote: A quick way to actually check for such dependencies is to switch to another desktop environment, say Xfce, remove all the KDE packages and install one of the KDE apps. That's not all that quick. There ought to be a tool for this. Given a package name it should print the dependency tree for that package. It could have an option to suppress packages in the base set. Couldn't Yum be taught to answer that kind of queries? There is already: http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py ...obviously any random custom behaviour (like ignoring packages in @base) is possible, someone just has to write it. Is there a reason this tool is not part of yum-utils? cleanup + merging it with other tools and other delays. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, 2009-08-24 at 14:36 +0200, drago01 wrote: On Sun, Aug 23, 2009 at 9:35 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. For the front-end to be end user suitable it should: * List applications rather than packages * Group them * Provide some kind of rating system to show best rated or most downloaded * Use the application icon if it has one * Make use of the packagekit browser plugin for installation But just letting the user search for random packages should not be the goal imho. Very good points. I very much agree that a list of applications is what we want here. Fedora Community is not really filling that niche, since is very much focused on the 'project' aspect of Fedora. In fact, I have been toying with the idea to make a 'Cool applications for Fedora' style page, using the PackageKit browser plugin. A very crude test of the idea can be seen here: http://people.redhat.com/mclasen/Screenshot-Applications%20for% 20Fedora.png This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 4:31 PM, Matthias Clasenmcla...@redhat.com wrote: On Mon, 2009-08-24 at 14:36 +0200, drago01 wrote: On Sun, Aug 23, 2009 at 9:35 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. For the front-end to be end user suitable it should: * List applications rather than packages * Group them * Provide some kind of rating system to show best rated or most downloaded * Use the application icon if it has one * Make use of the packagekit browser plugin for installation But just letting the user search for random packages should not be the goal imho. Very good points. I very much agree that a list of applications is what we want here. Fedora Community is not really filling that niche, since is very much focused on the 'project' aspect of Fedora. In fact, I have been toying with the idea to make a 'Cool applications for Fedora' style page, using the PackageKit browser plugin. A very crude test of the idea can be seen here: http://people.redhat.com/mclasen/Screenshot-Applications%20for% 20Fedora.png Yeah looks good but I would rather not show screenshots in this view (or atleast not different sized ones). A short description + icon should be enough. Have a show more link that contains a longer description + screenshots and a Install Now link. Pretty much like it is done in Apples Appstore This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Static? Doesn't scale (unless you would want to do it just for specific apps) Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. mockup links are dead. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, 2009-08-24 at 18:56 +0200, drago01 wrote: Yeah looks good but I would rather not show screenshots in this view (or atleast not different sized ones). A short description + icon should be enough. Have a show more link that contains a longer description + screenshots and a Install Now link. Pretty much like it is done in Apples Appstore Yeah, appstore is the right angle for this... This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Static? Doesn't scale (unless you would want to do it just for specific apps) My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. mockup links are dead. Unfortunately, yeah. I noticed that too. Not sure if I can do anything about that, though. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On 08/24/2009 07:31 AM, Matthias Clasen wrote: On Mon, 2009-08-24 at 14:36 +0200, drago01 wrote: On Sun, Aug 23, 2009 at 9:35 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 08/23/2009 10:50 AM, Rahul Sundaram wrote: Aren't we pitching Fedora Community interface as the end user facing thing, going forward? It seems some of these features will overlap or duplicate it. It's possible. The packagedb is going to be the backend for the Fedora Community Front end so it had to get written this summer so that work on the front-end can proceed. For the front-end to be end user suitable it should: * List applications rather than packages * Group them * Provide some kind of rating system to show best rated or most downloaded * Use the application icon if it has one * Make use of the packagekit browser plugin for installation But just letting the user search for random packages should not be the goal imho. Very good points. I very much agree that a list of applications is what we want here. Fedora Community is not really filling that niche, since is very much focused on the 'project' aspect of Fedora. In fact, I have been toying with the idea to make a 'Cool applications for Fedora' style page, using the PackageKit browser plugin. A very crude test of the idea can be seen here: http://people.redhat.com/mclasen/Screenshot-Applications%20for% 20Fedora.png This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. Looks like it has good potential. By F13 you might be able to back some of this with information in the PackageDB (or we could integrate the serverside with the packagedb). mbacovsk is working on adding screenshots, icons, and some heuristics to determine if something is an application or not. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 7:26 PM, Matthias Clasenmcla...@redhat.com wrote: [..] Static? Doesn't scale (unless you would want to do it just for specific apps) My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... Yeah but where does this top 10 come from? Wouldn't that end up list stuff that is installed by default anyway (+/- Oo.org ) ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Sat, 2009-08-22 at 12:04 -0700, Arjan van de Ven wrote: The Moblin OS uses Connman for everything networking. This is a different architecture than what Fedora does, where Fedora has /etc/sysconfig and other scripts that do part of the work etc. At first this looks like a minor change, but it's kinda fundamental. AIUI this isn't an entirely accurate characterization. When NetworkManager is in use on Fedora it takes over entirely; it ignores the settings in /etc/sysconfig/network-profiles and so forth, it uses its own configuration data only. For F12 it's growing a feature where it will 'assume' connections handled by the old-style scripts that are active when it starts up, and pass them off again when it shuts down, but still, while it's running, it is in charge of everything networking, as you describe for Connman. The difference is just that, on Fedora, you have the option of _not_ running NetworkManager at all, instead using the older system, if you choose. Others correct me if I'm wrong, but I think this is the case :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 9:26 AM, Matthias Clasenmcla...@redhat.com wrote: My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... What data would you use to rank apps in a top-10 sense? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Mon, Aug 24, 2009 at 7:36 PM, Adam Williamsonawill...@redhat.com wrote: On Sat, 2009-08-22 at 12:04 -0700, Arjan van de Ven wrote: The Moblin OS uses Connman for everything networking. This is a different architecture than what Fedora does, where Fedora has /etc/sysconfig and other scripts that do part of the work etc. At first this looks like a minor change, but it's kinda fundamental. AIUI this isn't an entirely accurate characterization. When NetworkManager is in use on Fedora it takes over entirely; it ignores the settings in /etc/sysconfig/network-profiles and so forth, it uses its own configuration data only. For F12 it's growing a feature where it will 'assume' connections handled by the old-style scripts that are active when it starts up, and pass them off again when it shuts down, but still, while it's running, it is in charge of everything networking, as you describe for Connman. The difference is just that, on Fedora, you have the option of _not_ running NetworkManager at all, instead using the older system, if you choose. Others correct me if I'm wrong, but I think this is the case :) You are wrong ;) NM does use so called system settings which are pretty much the legacy ifup scripts. It has its own keyfile based backend for this but currently we use the old format trough the redhat/fedora plugin. So when you create a connection by system-config-network nm would use it unless you remove the nm controlled bit. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 12:38 PM, Jeff Spaleta jspal...@gmail.com wrote: On Mon, Aug 24, 2009 at 9:26 AM, Matthias Clasenmcla...@redhat.com wrote: My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... What data would you use to rank apps in a top-10 sense? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Jeff, we could enable some sort of a user rating system (Most common thing to use is a star). Popular apps would get more ratings. We could get the top 10 that way, but I'm not sure what we'd use to prevent people from voting several times for their favorite apps. -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Sat, Aug 22, 2009 at 3:04 PM, Arjan van de Venar...@infradead.org wrote: Moblin and Fedora have rather different objectives. I'd be happy to work together on areas of joint interest, but I don't see the OSes as a whole converge, rather they will diverge even more than they already have. Do you see that as an inevitable consequence of the general purpose OS versus single-user mobile/embedded, or is it something where organizational or technological changes on one or both ends could turn the course towards divergence? I see a couple of different possible axes here: 1) Multi-user OS versus single-user mobile/embedded.: A *lot* of the stuff in the Fedora desktop stack both package wise and code wise is there to support multiple local users, like ConsoleKit and gdm (and to an extent PolicyKit), to how networking is setup in NetworkManager, etc. Clearly if we were to throw that out a lot of things would be significantly simpler and likely boot faster, but there's a large cost. 2) General purpose OS + release set versus targeted OS: Basically, do you block (or even slow) the release on a bug in say rsync or ocaml even if those things aren't dependencies of the UI or (any interesting) apps? 3) Backwards compatibility: The network scripts example you mentioned; remember that some things do depend on the way things work now, e.g. the virt-manager networking setup. There's also the system administrator training lost. 4) Minor infrastructural: The specbuilder example you gave is something I think Fedora would be interested in, but how applicable is it to the project? (I don't know, I'm asking) One thing that could answer a lot of my questions is; do you see Moblin as trending towards self-hosting from a developer perspective, or do you see it as depending on Linux distributions for that role? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Add Moblin Desktop group to comps
On Mon, 2009-08-24 at 13:55 -0400, Colin Walters wrote: 2) General purpose OS + release set versus targeted OS: Basically, do you block (or even slow) the release on a bug in say rsync or ocaml even if those things aren't dependencies of the UI or (any interesting) apps? This is touching on Critical Path. The direction I think we're going is that the release only cares about Critical Path and the accepted Features. We only block/slow the release for issues there, and everything else doesn't matter. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, 2009-08-24 at 10:31 -0400, Matthias Clasen wrote: http://people.redhat.com/mclasen/Screenshot-Applications%20for% 20Fedora.png Whoa, that link reliably crashes Evolution (probably due to the way it gets line-wrapped exactly after a %. Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=519068 -- Michel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, 2009-08-24 at 13:26 -0400, Matthias Clasen wrote: This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Static? Doesn't scale (unless you would want to do it just for specific apps) My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. How much of the work done on online-desktop will be carried forward to this? Regards, -- Michel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, 2009-08-24 at 16:31 -0400, Michel Salim wrote: On Mon, 2009-08-24 at 13:26 -0400, Matthias Clasen wrote: This obviously needs the helping hand of a web designer. For F12, this would probably be not much more than a static web page. Static? Doesn't scale (unless you would want to do it just for specific apps) My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... Rating and similar ideas described in http://www.fedoraproject.org/wiki/Features/ApplicationInstaller will come later. How much of the work done on online-desktop will be carried forward to this? The PackageKit browser plugin that is shown in that mockup is one piece that was initially developed for online-desktop. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 4:31 PM, Michel Salimmichael.silva...@gmail.com wrote: How much of the work done on online-desktop will be carried forward to this? In this context, the GNOME 3 shell will automatically track application usage data; more precisely, time spent with X focus in a window of the application, where application is defined as .desktop file. It's a bit away though. With nontrivial work this could be done for GNOME 2 as well (if someone was interested in porting the code, it lives in http://git.gnome.org/cgit/gnome-shell/tree/src/shell-app-monitor.c ). The current use of the data is just for shell-internal usage like sorting applications (in search results, session restart, etc.). If we wanted to use it as a basis for showing application popularity we'd need some way to opt-in to making your data public. My suggestion would be that we take the current Smolt screen in firstboot and turn it into a generic join Fedora Feedback page which turns on things like: * Smolt hardware profile * Sending of tracebacks to a crash collation server (for the love of all that is holy, not bugzilla) * Shell application usage data * Other stuff? In case anyone is feeling voyeuristic I've attached my current ~/.gnome2/shell/application_state file. application_state Description: Binary data -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On 08/25/2009 02:12 AM, Colin Walters wrote: My suggestion would be that we take the current Smolt screen in firstboot and turn it into a generic join Fedora Feedback page which turns on things like: * Smolt hardware profile * Sending of tracebacks to a crash collation server (for the love of all that is holy, not bugzilla) * Shell application usage data * Other stuff? fpaste, now a default package in Rawhide has a --sysinfo that collects a whole load of information that is commonly requested by people trying to help others in #fedora irc channel. Some of that available as part of a profile would be useful. Same output at http://fpaste.org/aU8r/ Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 5:04 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: fpaste, now a default package in Rawhide has a --sysinfo that collects a whole load of information that is commonly requested by people trying to help others in #fedora irc channel. Some of that available as part of a profile would be useful. Same output at http://fpaste.org/aU8r/ Yep, looks pretty useful. If we had a page in firstboot which turned on a cron script to HTTP POST that to a fedora infrastructure server, keyed off the smolt UUID on a weekly basis, I know I'd would opt in for sure, and I'm sure a lot of others would. The challenge here is to coherently explain to the user what's being sent, ensure privacy (you really don't want to send e.g. X window titles, and even process arguments can be sensitive). Also a challenge is that if you want to add something later you'd need some way to re-prompt the user which is kind of ugly. We should also probably restrict visibility of the data to aggregated only by default. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
Seth Vidal wrote: On Sun, 23 Aug 2009, Björn Persson wrote: I want to check whether a package drags in other packages unnecessarily. define unnecessarily? When you're forced to install package A to be able to install package E even though E doesn't use any of the functionality that A provides. For example, Michael Schwendt demonstrated that ktorrent pulls in qt-mysql, which in turn depends on mysql-libs. That's OK if Ktorrent can actually do something that results in queries to a MySQL database. Otherwise it drags in the MySQL client libraries unnecessarily – that is, I should be allowed to install Ktorrent without installing the MySQL client libraries. One likely cause is that package C, somewhere in the dependency chain between A and E, contains too many different functions. In that case C should probably be split into subpackages C1 and C2, where C1 depends on A but E depends on C2. Then E would no longer depend on A. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
On Mon, 24 Aug 2009, Björn Persson wrote: define unnecessarily? When you're forced to install package A to be able to install package E even though E doesn't use any of the functionality that A provides. For example, Michael Schwendt demonstrated that ktorrent pulls in qt-mysql, which in turn depends on mysql-libs. That's OK if Ktorrent can actually do something that results in queries to a MySQL database. Otherwise it drags in the MySQL client libraries unnecessarily – that is, I should be allowed to install Ktorrent without installing the MySQL client libraries. One likely cause is that package C, somewhere in the dependency chain between A and E, contains too many different functions. In that case C should probably be split into subpackages C1 and C2, where C1 depends on A but E depends on C2. Then E would no longer depend on A. So by 'unnecessary' you don't mean not required by the pkg's dependencies. you mean something else entirely. okay, that's fine - take that up with the pkg maintainer(s). -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
2009/8/24 Björn Persson bj...@xn--rombobjrn-67a.se: One likely cause is that package C, somewhere in the dependency chain between A and E, contains too many different functions. In that case C should probably be split into subpackages C1 and C2, where C1 depends on A but E depends on C2. Then E would no longer depend on A. I hope you understand that chasing down every single instance of this situation ultimately leads to a situation that is more easily duplicated by making the build process automatically split every library binary into its own subpackage. If we aren't willing to do that automatically, then why is it worth the time to have multiple individuals systematically chase them down? I'm wary that the sort of checking you want to do is a rabbit hole that will require significant continued human effort as codebases shift. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages
Hi, sali...@fedoraproject.org wrote: I am orphaning the following packages -- some of them because I no longer use them, some of them because of the packaging overhead. Mono (Banshee dependencies) ipod-sharp libipoddevice podsleuth I've taken these two. Best regards, Christian -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
James Antill wrote: There is already: http://james.fedorapeople.org/yum/commands/pkg-deps-tree-view.py ...obviously any random custom behaviour (like ignoring packages in @base) is possible, someone just has to write it. Well, that looks like a good start, but it definitely needs some way to avoid listing glibc, like, seven hundred times over. It would also be nice if I could use it on a newly built package that isn't available in the Yum repositories. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Rahul Sundaram wrote: A quick way to actually check for such dependencies is to switch to another desktop environment, say Xfce, remove all the KDE packages and install one of the KDE apps. It usually reveals dependencies which are rather silly. I have seen kde-settings, background packages and kdebase pull in odd dependencies on occasions. k3b, ktorrent, scribus et all are often used outside KDE. It's not like those dependencies bite. ;-) HDD space is cheap. I don't find it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- workspace drags in Akonadi (and thus MySQL, which is a hard requirement of Akonadi) and I'm not sure the current subpackage explosion (FYI, rdieter split out subpackages to break both the links in the offending chain: in upcoming updates, ktorrent no longer requires kdebase-workspace, only the kde-plasma-ktorrent subpackage does, and kdebase-workspace no longer requires akonadi, only the kdebase-workspace-akonadi subpackage does) are a step in the right direction (as they mean the default installations of both ktorrent and kdebase-workspace/Plasma will be missing features). I'd rather have unneccessary dependencies than useful features not installed by default. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeX Live 2009 for Fedora
Jindrich Novy wrote: The .ARCH postfix is actually derived from the TL metadata dependencies but indeed it doesn't look so good. The '-libs' is not appropriate as only binaries which go to /usr/bin are packaged. I will switch to the '-bin' postfix in the next build. Right, -bin seems to make most sense in this case. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
On 08/25/2009 03:37 AM, Kevin Kofler wrote: Rahul Sundaram wrote: A quick way to actually check for such dependencies is to switch to another desktop environment, say Xfce, remove all the KDE packages and install one of the KDE apps. It usually reveals dependencies which are rather silly. I have seen kde-settings, background packages and kdebase pull in odd dependencies on occasions. k3b, ktorrent, scribus et all are often used outside KDE. It's not like those dependencies bite. ;-) HDD space is cheap. Unneeded dependencies do bite. I have a net connection with a bandwidth cap at home. Packages that pulls in random silly dependencies are a big pain. I have sit through updates of them as well. There more often those packages get updated, the bigger the pain is. yum-presto is a life saver but the dependency bloat is not a ignorable problem at all. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gwenview - Re: Orphaning packages
Kevin Kofler wrote: It's not like those dependencies bite. ;-) HDD space is cheap. I don't find it scandalous that ktorrent drags in kdebase-workspace nor that kdebase- workspace drags in Akonadi (and thus MySQL, which is a hard requirement of Akonadi) and I'm not sure the current subpackage explosion (FYI, rdieter split out subpackages to break both the links in the offending chain: in upcoming updates, ktorrent no longer requires kdebase-workspace, only the kde-plasma-ktorrent subpackage does, and kdebase-workspace no longer requires akonadi, only the kdebase-workspace-akonadi subpackage does) are a step in the right direction (as they mean the default installations of both ktorrent and kdebase-workspace/Plasma will be missing features). I'd rather have unneccessary dependencies than useful features not installed by default. It would be nice if things could be set up such that kdebase-workspace-akonadi gets installed by default if both kdebase-workspace and akonadi are installed, but not if only one of them is installed. If RPM had a Suggests tag it would at least be possible to inform users that there is a related package available that they can install if they want to. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
2009/8/24 Björn Persson bj...@xn--rombobjrn-67a.se: On the other hand, not addressing such situations at all ultimately leads to a huge tangle where every single package depends on pretty much all of Fedora Everything. It's a matter of finding a good balance. Are you suggesting that things are out of balance now? What is an allowable amount of tangle? Aren't you making an assumption that we are out of balance? Define a prescriptive good enough threshold to meet. Make sure you include a cost function for the associated repository metadata increase and subpackage header for each subpackage you add. Splitting every library binary into its own subpackage might not always resolve the situation by the way. I have seen libraries that lump together all sorts of unrelated functions in a single .so file. Are you seriously suggesting expending the manpower at the distribution level to poke at which functional calls need to broken out into more libraries? One function per library! One library per subpackage! There are also libraries written in interpreted languages that aren't compiled into binaries, and in some cases the dependencies might not even be libraries at all. I'm fully aware of the difficulty with interpreted languages. And do you know which percent of those are explicit and which are auto-generated via a buildtime dependency generator? Explicit deps and provides are quite fragile..that's not going to change. The win is going to come from automating as much of the depchain in interpreted languages as possible instead of systematically trying to fix explicitly coded deps one package at a time. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Strange message from Bugzilla
When a review is granted, the mail always says $REVIEWER has granted $REVIEWER's request for fedora-review. Shouldn't the second $REVIEWER be $PACKAGER ? Regards, -- Michel ---BeginMessage--- Product: Fedora Version: rawhide Component: Package Review Michel Alexandre Salim michael.silva...@gmail.com has granted Michel Alexandre Salim michael.silva...@gmail.com's request for fedora-review: Bug 519009: Review Request: gnome-do-docklets - Docklets for gnome-do https://bugzilla.redhat.com/show_bug.cgi?id=519009 --- Additional Comments from Michel Alexandre Salim michael.silva...@gmail.com Not sure; on mine it seems to be off by only about 10% or so. Though today yum shows me progress percentages of thousands of percents for each download, heh. OK, everything else is fine -- APPROVED ---End Message--- signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Strange message from Bugzilla
MAS == Michel Alexandre Salim michael.silva...@gmail.com writes: MAS When a review is granted, the mail always says $REVIEWER has MAS granted $REVIEWER's request for fedora-review. Shouldn't the MAS second $REVIEWER be $PACKAGER ? That's just a by-product of the way we abuse bugzilla's flags for the review process. '?' is supposed to indicate the request and '+' the resolution, as with CVS requests. But for reviews we need three states (review not started, review in progress, approval), hence no flag, '?' and '+', respectively. When a flag goes from '?' to '+', bugzilla generates the message you mention. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
The broken perl in dist-f12 this weekend
Hello all, things has broken this weekend in dist-f12. They are fixed now. It was my fault; if you are wonder about details, read on. Around Jul 31, I have discovered that we are unintentionally building perl with -DDEBUGGING. I tried to fix that and built a production perl, i.e., without -DDEBUGGING; it was perl-5.10.0-78.fc12. But this has broken rawhide and I had to hastily untag that build from dist-f12. Unfortunately, I forgot to revert my change from the spec file, not even when we came to a conclusion that the switch from debugperl to production perl has to wait until early dist-f13. This Friday, Chris added the rpm macros to the perl package and rebuilt perl. Because of my mistake, the rebuilt perl-5.10.0-79.fc12 was suffering the same problem again: half of the binary module packages (about 150 of 287), stopped working. As explained above, this was my fault, Chris is innocent. :-) I discovered the problem today, untagged perl-5.10.0-79 immediately and rebuilt perl itself. At this moment, perl-5.10.0-80.fc12 has finally got to the koji repo and things should work again. Sorry for the inconvenience and confusion. Stepan -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr ownership updated
Package perl-Network-IPv4Addr in Fedora devel was orphaned by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr ownership updated
Package perl-Network-IPv4Addr in Fedora 9 was orphaned by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr (un)retirement
Package perl-Network-IPv4Addr in Fedora devel has been retired by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr (un)retirement
Package perl-Network-IPv4Addr in Fedora 9 has been retired by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr (un)retirement
Package perl-Network-IPv4Addr in Fedora 10 has been retired by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr ownership updated
Package perl-Network-IPv4Addr in Fedora EPEL 5 was orphaned by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr (un)retirement
Package perl-Network-IPv4Addr in Fedora EPEL 5 has been retired by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr ownership updated
Package perl-Network-IPv4Addr in Fedora 11 was orphaned by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[pkgdb] perl-Network-IPv4Addr (un)retirement
Package perl-Network-IPv4Addr in Fedora 11 has been retired by ausil To make changes to this package see: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Network-IPv4Addr -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Net-IPv4Addr/EL-4 perl-Net-IPv4Addr.spec,1.1,1.2
Author: ausil
Update of /cvs/pkgs/rpms/perl-Net-IPv4Addr/EL-4
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19753
Modified Files:
perl-Net-IPv4Addr.spec
Log Message:
Obsoletes the older perl-Network-IPv4Addr module
Index: perl-Net-IPv4Addr.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-IPv4Addr/EL-4/perl-Net-IPv4Addr.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Net-IPv4Addr.spec 6 May 2007 15:47:46 - 1.1
+++ perl-Net-IPv4Addr.spec 24 Aug 2009 20:05:33 - 1.2
@@ -1,6 +1,6 @@
Name: perl-Net-IPv4Addr
Version:0.10
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl extension for manipulating IPv4 addresses
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Obsoletes: perl-Network-IPv4Addr 0.10-1
%description
Net::IPv4Addr provides functions for parsing IPv4 addresses both in traditional
@@ -53,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-3
+- Obsoletes perl-Network-IPv4Addr
+- no provides as code needs changing to use the new version
+
* Sat May 05 2007 Sindre Pedersen Bjørdal foolish[AT]guezz.net - 0.10-2
- Add missing build dependencies
- Fix License
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Net-IPv4Addr/EL-5 perl-Net-IPv4Addr.spec,1.1,1.2
Author: ausil
Update of /cvs/pkgs/rpms/perl-Net-IPv4Addr/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20224
Modified Files:
perl-Net-IPv4Addr.spec
Log Message:
Obsolets perl-Network-IPv4Addr
Index: perl-Net-IPv4Addr.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-IPv4Addr/EL-5/perl-Net-IPv4Addr.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-Net-IPv4Addr.spec 6 May 2007 15:50:05 - 1.1
+++ perl-Net-IPv4Addr.spec 24 Aug 2009 20:06:49 - 1.2
@@ -1,6 +1,6 @@
Name: perl-Net-IPv4Addr
Version:0.10
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl extension for manipulating IPv4 addresses
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Obsoletes: perl-Network-IPv4Addr 0.10-1
%description
Net::IPv4Addr provides functions for parsing IPv4 addresses both in traditional
@@ -53,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-3
+- Obsoletes perl-Network-IPv4Addr
+- no provides as code needs changing to use the new version
+
* Sat May 05 2007 Sindre Pedersen Bjørdal foolish[AT]guezz.net - 0.10-2
- Add missing build dependencies
- Fix License
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Net-IPv4Addr/F-10 perl-Net-IPv4Addr.spec,1.2,1.3
Author: ausil
Update of /cvs/pkgs/rpms/perl-Net-IPv4Addr/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20806
Modified Files:
perl-Net-IPv4Addr.spec
Log Message:
obsoletes perl-Network-IPv4Addr
Index: perl-Net-IPv4Addr.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-IPv4Addr/F-10/perl-Net-IPv4Addr.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-Net-IPv4Addr.spec 6 Mar 2008 14:58:30 - 1.2
+++ perl-Net-IPv4Addr.spec 24 Aug 2009 20:08:52 - 1.3
@@ -1,6 +1,6 @@
Name: perl-Net-IPv4Addr
Version:0.10
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Perl extension for manipulating IPv4 addresses
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Obsoletes: perl-Network-IPv4Addr 0.10-1
%description
Net::IPv4Addr provides functions for parsing IPv4 addresses both in traditional
@@ -53,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-4
+- Obsoletes perl-Network-IPv4Addr
+- no provides as code needs changing to use the new version
+
* Thu Mar 06 2008 Tom spot Callaway tcall...@redhat.com - 0.10-3
- rebuild for new perl
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Net-IPv4Addr/F-11 perl-Net-IPv4Addr.spec,1.3,1.4
Author: ausil
Update of /cvs/pkgs/rpms/perl-Net-IPv4Addr/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21289
Modified Files:
perl-Net-IPv4Addr.spec
Log Message:
* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-3
- Obsoletes perl-Network-IPv4Addr
- no provides as code needs changing to use the new version
Index: perl-Net-IPv4Addr.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-IPv4Addr/F-11/perl-Net-IPv4Addr.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Net-IPv4Addr.spec 26 Feb 2009 23:10:59 - 1.3
+++ perl-Net-IPv4Addr.spec 24 Aug 2009 20:10:11 - 1.4
@@ -1,6 +1,6 @@
Name: perl-Net-IPv4Addr
Version:0.10
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Perl extension for manipulating IPv4 addresses
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Obsoletes: perl-Network-IPv4Addr 0.10-1
%description
Net::IPv4Addr provides functions for parsing IPv4 addresses both in traditional
@@ -53,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-5
+- Obsoletes perl-Network-IPv4Addr
+- no provides as code needs changing to use the new version
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.10-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Net-IPv4Addr/devel perl-Net-IPv4Addr.spec,1.4,1.5
Author: ausil
Update of /cvs/pkgs/rpms/perl-Net-IPv4Addr/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21668
Modified Files:
perl-Net-IPv4Addr.spec
Log Message:
* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-3
- Obsoletes perl-Network-IPv4Addr
- no provides as code needs changing to use the new version
Index: perl-Net-IPv4Addr.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-IPv4Addr/devel/perl-Net-IPv4Addr.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Net-IPv4Addr.spec 26 Jul 2009 13:41:51 - 1.4
+++ perl-Net-IPv4Addr.spec 24 Aug 2009 20:11:31 - 1.5
@@ -1,6 +1,6 @@
Name: perl-Net-IPv4Addr
Version:0.10
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Perl extension for manipulating IPv4 addresses
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker), perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Obsoletes: perl-Network-IPv4Addr 0.10-1
%description
Net::IPv4Addr provides functions for parsing IPv4 addresses both in traditional
@@ -53,6 +54,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Aug 24 2009 Dennis Gilmore den...@ausil.us - 0.10-6
+- Obsoletes perl-Network-IPv4Addr
+- no provides as code needs changing to use the new version
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.10-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Jcode/devel .cvsignore, 1.5, 1.6 perl-Jcode.spec, 1.19, 1.20 sources, 1.5, 1.6
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-Jcode/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31326
Modified Files:
.cvsignore perl-Jcode.spec sources
Log Message:
- Update to 2.07 (fix mime_encode, CPAN RT#29049)
- Run test suite in C locale to support build on old distributions
- Fix argument order for find with -depth
- Encode manpages in UTF-8
- Include old Changes file too
- Mark POD file as %doc
- Add explicit perl(MIME::Base64) dependency for MIME header support
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Jcode/devel/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- .cvsignore 30 Aug 2006 16:00:39 - 1.5
+++ .cvsignore 24 Aug 2009 20:49:02 - 1.6
@@ -1 +1 @@
-Jcode-2.06.tar.gz
+Jcode-2.07.tar.gz
Index: perl-Jcode.spec
===
RCS file: /cvs/pkgs/rpms/perl-Jcode/devel/perl-Jcode.spec,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- perl-Jcode.spec 26 Jul 2009 08:51:53 - 1.19
+++ perl-Jcode.spec 24 Aug 2009 20:49:02 - 1.20
@@ -1,56 +1,65 @@
-Name: perl-Jcode
-Version:2.06
-Release:9%{?dist}
-
-Summary:Perl extension interface for converting Japanese text
-
-License:GPL+ or Artistic
-Group: Development/Libraries
-URL:http://search.cpan.org/dist/Jcode/
-Source0:http://www.cpan.org/authors/id/D/DA/DANKOGAI/Jcode-2.06.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
-BuildArch: noarch
-BuildRequires: perl-devel = 3:5.8.1, perl-Test-Simple
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Name: perl-Jcode
+Version: 2.07
+Release: 1%{?dist}
+Summary: Perl extension interface for converting Japanese text
+License: GPL+ or Artistic
+Group: Development/Libraries
+URL: http://search.cpan.org/dist/Jcode/
+Source0:
http://www.cpan.org/authors/id/D/DA/DANKOGAI/Jcode-%{version}.tar.gz
+BuildArch: noarch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl(ExtUtils::MakeMaker), perl(MIME::Base64), perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(MIME::Base64)
%description
%{summary}.
-
%prep
%setup -q -n Jcode-%{version}
+# Fix character encoding of pod file
+%{__mv} Jcode/Nihongo.pod Jcode/Nihongo.pod.euc-jp
+%{__sed} -e 's/^=encoding euc-jp/=encoding utf8/' Jcode/Nihongo.pod.euc-jp |
+ /usr/bin/iconv -f euc-jp -t utf-8 -o Jcode/Nihongo.pod
+%{__rm} Jcode/Nihongo.pod.euc-jp
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
-
+%{__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 ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+%{__rm} -rf %{buildroot}
+%{__make} pure_install PERL_INSTALL_ROOT=%{buildroot}
+/usr/bin/find %{buildroot} -type f -name .packlist -exec %{__rm} -f {} ';'
+/usr/bin/find %{buildroot} -depth -type d -exec /bin/rmdir {} 2/dev/null ';'
+%{__chmod} -R u+w %{buildroot}
%check
-make test
-
+LC_ALL=C %{__make} test
%clean
-rm -rf $RPM_BUILD_ROOT
-
+%{__rm} -rf %{buildroot}
%files
%defattr(-,root,root,-)
-%doc Changes README
-%{perl_vendorlib}/Jcode*
-%{_mandir}/man3/*.3*
-
+%doc Changes* README
+%{perl_vendorlib}/Jcode.pm
+%dir %{perl_vendorlib}/Jcode/
+%doc %{perl_vendorlib}/Jcode/Nihongo.pod
+%{_mandir}/man3/Jcode.3pm*
+%{_mandir}/man3/Jcode::Nihongo.3pm*
%changelog
+* Mon Aug 24 2009 Paul Howarth p...@city-fan.org - 2.07-1
+- Update to 2.07 (fix mime_encode, CPAN RT#29049)
+- Run test suite in C locale to support build on old distributions
+- Fix argument order for find with -depth
+- Encode manpages in UTF-8
+- Include old Changes file too
+- Mark POD file as %%doc
+- Add explicit perl(MIME::Base64) dependency for MIME header support
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.06-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Jcode/devel/sources,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- sources 30 Aug 2006 16:00:39 - 1.5
+++ sources 24 Aug 2009 20:49:02 - 1.6
@@ -1 +1 @@
-56d787a94cbb557d8b21d10972befd94 Jcode-2.06.tar.gz
+f6c52253ff69a44c38a9183c469f6eb0 Jcode-2.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
