From rdieter at math.unl.edu Mon May 1 12:05:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 01 May 2006 07:05:14 -0500 Subject: gsview pulled from Extras (soon) Message-ID: <4455F97A.4070806@math.unl.edu> It's been brought to my attention that gsview does not meet necessary licensing requirements, so will be pulled from Extras shortly: http://bugzilla.redhat.com/bugzilla/190276 -- Rex From katzj at redhat.com Mon May 1 15:09:05 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 11:09:05 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <20060429101046.GA3880@redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> Message-ID: <1146496145.11225.7.camel@orodruin.boston.redhat.com> On Sat, 2006-04-29 at 11:10 +0100, Joe Orton wrote: > On Fri, Apr 28, 2006 at 02:23:48PM -0400, Jeremy Katz wrote: > > What does this mean to you as a package maintainer? In a lot of cases, > > hopefully nothing. But there are cases where header files included in > > packages are generated at build-time and have an architecture or build > > specific nature. These conflicts will need to be fixed similar to how > > things have been fixed for runtime library issues -- either moving files > > around or removing the cause for the difference. If there is a valid > > reason for them to be different, then you might want to explore having a > > common stub header that includes the different headers as appropriate > > (eg, how /usr/include/gnu/stubs.h is handled) > > Nobody has come up with a feasible plan for dealing with > %{_bindir}/foo-config scripts AFAIK. Probably the best thing to do in these cases is to create pkgconfig .pc files and then make the foo-config script a simple wrapper around pkgconfig. Jeremy From katzj at redhat.com Mon May 1 15:13:13 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 11:13:13 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <26282.1146340047@sss.pgh.pa.us> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <26282.1146340047@sss.pgh.pa.us> Message-ID: <1146496394.11225.11.camel@orodruin.boston.redhat.com> On Sat, 2006-04-29 at 15:47 -0400, Tom Lane wrote: > Joe Orton writes: > > Nobody has come up with a feasible plan for dealing with > > %{_bindir}/foo-config scripts AFAIK. > > Indeed. I don't have a reasonable solution for > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190093 > for instance. (The one proposed by Bastien in the bug is not > reasonable.) And once we start shipping multilib -devel (which is part of the point here), the suggestion is moot. > I've always thought that the decision to have only one bin-dir for both > arches was a serious mistake. Maybe we could revisit that before we > start trying to stretch the entire world upon that Procrustean bed. More than one bin dir changes one set of problems out for a completely different (and imho, far worse) set of problems. The number of scripts with hard-coded paths of /usr/bin, etc are huge. And once you start having more than one bindir, you have to deal with questions of which should and is first in the path, etc. Jeremy From tgl at redhat.com Mon May 1 15:24:24 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 01 May 2006 11:24:24 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146496145.11225.7.camel@orodruin.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <1146496145.11225.7.camel@orodruin.boston.redhat.com> Message-ID: <5993.1146497064@sss.pgh.pa.us> Jeremy Katz writes: > On Sat, 2006-04-29 at 11:10 +0100, Joe Orton wrote: >> Nobody has come up with a feasible plan for dealing with >> %{_bindir}/foo-config scripts AFAIK. > Probably the best thing to do in these cases is to create pkgconfig .pc > files and then make the foo-config script a simple wrapper around > pkgconfig. How will that fix the problem that you need to return different results depending on whether the user is interested in the 32-bit or 64-bit libraries? Right now the script would require psychic abilities to figure that out, because the user has no way to indicate it. If we bit the bullet and had separate /usr/bin/ and /usr/bin64/ directories, then it'd be trivial: store the appropriate config program in each of those directories, and the user uses $PATH or an explicit path to indicate which one he wants. regards, tom lane From fedora at leemhuis.info Mon May 1 15:33:16 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 01 May 2006 17:33:16 +0200 Subject: FESCo Election Message-ID: <1146497596.2830.40.camel@localhost.localdomain> Hi All! Just FYI, FESCo (the Fedora Extras Steering Committee) currently plans a election of the members for the next FESCo. The current plan is that all members of the cvsextras group in the accounts systems (e.g. all Fedora Extras packagers) can vote their new "leaders". For details see https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00026.html For further discussion please use fedora-extras-list. tia CU thl -- Thorsten Leemhuis From pjones at redhat.com Mon May 1 15:51:25 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 01 May 2006 11:51:25 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <5993.1146497064@sss.pgh.pa.us> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <1146496145.11225.7.camel@orodruin.boston.redhat.com> <5993.1146497064@sss.pgh.pa.us> Message-ID: <1146498686.29761.29.camel@localhost.localdomain> On Mon, 2006-05-01 at 11:24 -0400, Tom Lane wrote: > Jeremy Katz writes: > > On Sat, 2006-04-29 at 11:10 +0100, Joe Orton wrote: > >> Nobody has come up with a feasible plan for dealing with > >> %{_bindir}/foo-config scripts AFAIK. > > > Probably the best thing to do in these cases is to create pkgconfig .pc > > files and then make the foo-config script a simple wrapper around > > pkgconfig. > > How will that fix the problem that you need to return different results > depending on whether the user is interested in the 32-bit or 64-bit > libraries? Right now the script would require psychic abilities to > figure that out, because the user has no way to indicate it. > > If we bit the bullet and had separate /usr/bin/ and /usr/bin64/ > directories, then it'd be trivial: store the appropriate config program > in each of those directories, and the user uses $PATH or an explicit > path to indicate which one he wants. That doesn't work well either, though. Most of the time, pkg-config isn't being run by a user, it's being run by configure or make, or one of them via rpm . You don't want to have to change the paths everywhere to build for the other arch, you want to do: rpm -ba --target=i386 foo.spec and just have it work. -- Peter From tgl at redhat.com Mon May 1 16:04:27 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 01 May 2006 12:04:27 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146498686.29761.29.camel@localhost.localdomain> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <1146496145.11225.7.camel@orodruin.boston.redhat.com> <5993.1146497064@sss.pgh.pa.us> <1146498686.29761.29.camel@localhost.localdomain> Message-ID: <6324.1146499467@sss.pgh.pa.us> Peter Jones writes: > On Mon, 2006-05-01 at 11:24 -0400, Tom Lane wrote: >> How will that fix the problem that you need to return different results >> depending on whether the user is interested in the 32-bit or 64-bit >> libraries? Right now the script would require psychic abilities to >> figure that out, because the user has no way to indicate it. > ... You don't want to have to change the paths everywhere > to build for the other arch, you want to do: > rpm -ba --target=i386 foo.spec > and just have it work. If you have a non-psychic solution for that, I'd like to see it, because I'm not seeing what it is. regards, tom lane From mclasen at redhat.com Mon May 1 16:23:28 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 01 May 2006 12:23:28 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <6324.1146499467@sss.pgh.pa.us> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <1146496145.11225.7.camel@orodruin.boston.redhat.com> <5993.1146497064@sss.pgh.pa.us> <1146498686.29761.29.camel@localhost.localdomain> <6324.1146499467@sss.pgh.pa.us> Message-ID: <1146500608.3515.0.camel@dhcp83-48.boston.redhat.com> On Mon, 2006-05-01 at 12:04 -0400, Tom Lane wrote: > Peter Jones writes: > > On Mon, 2006-05-01 at 11:24 -0400, Tom Lane wrote: > >> How will that fix the problem that you need to return different results > >> depending on whether the user is interested in the 32-bit or 64-bit > >> libraries? Right now the script would require psychic abilities to > >> figure that out, because the user has no way to indicate it. > > > ... You don't want to have to change the paths everywhere > > to build for the other arch, you want to do: > > rpm -ba --target=i386 foo.spec > > and just have it work. > > If you have a non-psychic solution for that, I'd like to see it, because > I'm not seeing what it is. Have rpmbuild setup PKG_CONFIG_PATH according to target arch ? Matthias From notting at redhat.com Mon May 1 17:02:42 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 May 2006 13:02:42 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <20060429101046.GA3880@redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> Message-ID: <20060501170242.GE31572@devserv.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > On Fri, Apr 28, 2006 at 02:23:48PM -0400, Jeremy Katz wrote: > > What does this mean to you as a package maintainer? In a lot of cases, > > hopefully nothing. But there are cases where header files included in > > packages are generated at build-time and have an architecture or build > > specific nature. These conflicts will need to be fixed similar to how > > things have been fixed for runtime library issues -- either moving files > > around or removing the cause for the difference. If there is a valid > > reason for them to be different, then you might want to explore having a > > common stub header that includes the different headers as appropriate > > (eg, how /usr/include/gnu/stubs.h is handled) > > Nobody has come up with a feasible plan for dealing with > %{_bindir}/foo-config scripts AFAIK. Port package to pkgconfig. Write foo-config script that calls pkg-config. Bill From notting at redhat.com Mon May 1 17:06:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 May 2006 13:06:22 -0400 Subject: [packaging question] multilib gtkimm (Input Method modules) In-Reply-To: <44530544.2050403@redhat.com> References: <44530544.2050403@redhat.com> Message-ID: <20060501170621.GF31572@devserv.devel.redhat.com> Jens Petersen (petersen at redhat.com) said: > Is there a better to deal with this? Can something be added to > comps.xml to help? Have the package installer always resolve and install .compatarch when .normalarch is asked for. Bill From tgl at redhat.com Mon May 1 17:55:53 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 01 May 2006 13:55:53 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <20060501170242.GE31572@devserv.devel.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <20060501170242.GE31572@devserv.devel.redhat.com> Message-ID: <6978.1146506153@sss.pgh.pa.us> Bill Nottingham writes: > Joe Orton (jorton at redhat.com) said: >> Nobody has come up with a feasible plan for dealing with >> %{_bindir}/foo-config scripts AFAIK. > Port package to pkgconfig. Write foo-config script that calls pkg-config. (1) How many upstream projects will take back changes to make their foo-config scripts depend on pkgconfig? I'm afraid this proposed solution will mean we end up maintaining many local forks of foo-config. (2) pkg-config isn't psychic either. As near as I can tell from a quick read of its man page, the only way it can solve the problem is if rpmbuild sets PKG_CONFIG_PATH to select either 32- or 64-bit libraries. While that's adequate for solving our own build problems, it doesn't help for people doing ordinary source builds of library-using software; from their point of view foo-config is still broken. And this makes it even less likely that any upstreams will take back the foo-config changes, because the "solution" depends not only on pkgconfig but on a worldview that says RPM is the only build environment that matters. regards, tom lane From mclasen at redhat.com Mon May 1 18:03:21 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 01 May 2006 14:03:21 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <6978.1146506153@sss.pgh.pa.us> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <20060501170242.GE31572@devserv.devel.redhat.com> <6978.1146506153@sss.pgh.pa.us> Message-ID: <1146506601.3515.2.camel@dhcp83-48.boston.redhat.com> On Mon, 2006-05-01 at 13:55 -0400, Tom Lane wrote: > Bill Nottingham writes: > > Joe Orton (jorton at redhat.com) said: > >> Nobody has come up with a feasible plan for dealing with > >> %{_bindir}/foo-config scripts AFAIK. > > > Port package to pkgconfig. Write foo-config script that calls pkg-config. > > (1) How many upstream projects will take back changes to make their > foo-config scripts depend on pkgconfig? I'm afraid this proposed > solution will mean we end up maintaining many local forks of foo-config. > > (2) pkg-config isn't psychic either. As near as I can tell from a quick > read of its man page, the only way it can solve the problem is if > rpmbuild sets PKG_CONFIG_PATH to select either 32- or 64-bit libraries. > While that's adequate for solving our own build problems, it doesn't > help for people doing ordinary source builds of library-using software; > from their point of view foo-config is still broken. And this makes it > even less likely that any upstreams will take back the foo-config > changes, because the "solution" depends not only on pkgconfig but on a > worldview that says RPM is the only build environment that matters. Setting up PKG_CONFIG_PATH is hardly something that only rpm can do... From notting at redhat.com Mon May 1 18:08:34 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 May 2006 14:08:34 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <6978.1146506153@sss.pgh.pa.us> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <20060501170242.GE31572@devserv.devel.redhat.com> <6978.1146506153@sss.pgh.pa.us> Message-ID: <20060501180834.GE4824@devserv.devel.redhat.com> Tom Lane (tgl at redhat.com) said: > > Port package to pkgconfig. Write foo-config script that calls pkg-config. > > (1) How many upstream projects will take back changes to make their > foo-config scripts depend on pkgconfig? I'm afraid this proposed > solution will mean we end up maintaining many local forks of foo-config. How many upstream projects will take back changes to make their FOO work with PAM? How many upstream projects will take back changes to make their FOO work with SELinux? How many upstream projects will take back changes to make their FOO work with udev? I'm not saying it's 100% the same, but there's a difference between mere packaging and integration, and this is one of those things. > (2) pkg-config isn't psychic either. As near as I can tell from a quick > read of its man page, the only way it can solve the problem is if > rpmbuild sets PKG_CONFIG_PATH to select either 32- or 64-bit libraries. > While that's adequate for solving our own build problems, it doesn't > help for people doing ordinary source builds of library-using software; > from their point of view foo-config is still broken. And this makes it > even less likely that any upstreams will take back the foo-config > changes, because the "solution" depends not only on pkgconfig but on a > worldview that says RPM is the only build environment that matters. You can always set your arch, with setarch or similar personality mechanisms. Regardless it's less broken than what we have now, and it solves the problems that we need to solve. I don't think waiting around for a perfect solution is the right answer. Bill From tgl at redhat.com Mon May 1 18:47:35 2006 From: tgl at redhat.com (Tom Lane) Date: Mon, 01 May 2006 14:47:35 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <20060501180834.GE4824@devserv.devel.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <20060429101046.GA3880@redhat.com> <20060501170242.GE31572@devserv.devel.redhat.com> <6978.1146506153@sss.pgh.pa.us> <20060501180834.GE4824@devserv.devel.redhat.com> Message-ID: <7410.1146509255@sss.pgh.pa.us> Bill Nottingham writes: > Tom Lane (tgl at redhat.com) said: >> (1) How many upstream projects will take back changes to make their >> foo-config scripts depend on pkgconfig? I'm afraid this proposed >> solution will mean we end up maintaining many local forks of foo-config. > How many upstream projects will take back changes to make their FOO work > with PAM? "work with" is one thing, "depend on" is something very different. Especially for something that is (IIUC) both a build and a run time dependency. I don't think this analogy holds water. regards, tom lane From katzj at redhat.com Mon May 1 22:19:03 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 18:19:03 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146248628.9570.39.camel@aglarond.local> References: <1146248628.9570.39.camel@aglarond.local> Message-ID: <1146521943.11225.87.camel@orodruin.boston.redhat.com> On Fri, 2006-04-28 at 14:23 -0400, Jeremy Katz wrote: > What does this mean to you as a package maintainer? In a lot of cases, > hopefully nothing. But there are cases where header files included in > packages are generated at build-time and have an architecture or build > specific nature. These conflicts will need to be fixed similar to how > things have been fixed for runtime library issues -- either moving files > around or removing the cause for the difference. If there is a valid > reason for them to be different, then you might want to explore having a > common stub header that includes the different headers as appropriate > (eg, how /usr/include/gnu/stubs.h is handled) And, now I've gone through and tried to install all of the i386 -devel packages on a full x86_64 install to find the conflicts. The picture isn't too bad -- there are 110 conflicts, but they tend to fall into a few general categories and a couple of the categories take care of fixing lots of packages. The list of conflicting packages is attached. The categories of problems are: * foo-config scripts. As previously mentioned on this thread, the best way to fix these is to create a pkg-config file and replace the foo-config script with a wrapper that calls pkg-config (and is thus the same on all arches) * gtk-doc creates lots of conflicts -- it looks like this is probably due to the links within documents being auto-generated. Using some sort of consistent way of generating the link ids would fix this and make it easier to find out what's really changed in the gtk-doc. * jar(/zip) conflicts in java packages -- looks like this is due to timestamps in the archives. Is there a way that these can be generated similar to gzip -n? * some of the modular X libs look like they compress the man pages themselves but without using gzip -n * actual header file conflicts * a few weird cases where buildroots get encoded other places (eg, /usr/bin/compile_et) or packages not properly using %{_libdir} (eg, inn-devel) I'll work on making the full output with the exact conflicts in each package available later tonight but wanted to get info out about which packages were problematic. Also, I plan to start filing bugs on packages which haven't been fixed on May 16th. Jeremy -------------- next part -------------- apr-devel-1.2.6-2 apr-util-devel-1.2.6-2 arts-devel-1.5.2-1 aspell-devel-0.60.3-6 audiofile-devel-0.2.6-4 beecrypt-devel-4.1.2-9.2.1 cairo-java-1.0.3-0 cairo-java-devel-1.0.3-0 cdrecord-devel-2.01.01.0.a03-3 cups-devel-1.2-0.5.rc3.2 cyrus-sasl-devel-2.1.21-11 e2fsprogs-devel-1.38-12 eclipse-jdt-devel-3.1.2-1jpp_13fc eclipse-platform-devel-3.1.2-1jpp_13fc eclipse-rcp-devel-3.1.2-1jpp_13fc esound-devel-0.2.36-2.2.1 freetype-devel-2.1.10-5.2.1 fribidi-devel-0.10.7-1 gd-devel-2.0.33-6.2 gdk-pixbuf-devel-0.22.0-23 ghostscript-devel-8.15.2-2 gimp-print-devel-4.2.7-16 gkrellm-devel-2.2.9-1 glib-devel-1.2.10-18.2.2 glib-java-devel-0.2.4-1 gmime-devel-2.1.19-3 gmp-devel-4.1.4-6.2.1 gnome-vfs2-devel-2.14.1-4 gphoto2-devel-2.1.99-10 gstreamer-devel-0.10.4-1 gstreamer-plugins-base-devel-0.10.5-1 gstreamer-plugins-good-devel-0.10.2-1 gtk+-devel-1.2.10-50 gtkspell-devel-2.0.11-1.2.1 guile-devel-1.6.7-6 g-wrap-devel-1.9.6-3 httpd-devel-2.2.0-6 ImageMagick-c++-devel-6.2.5.4-4.2.1 ImageMagick-devel-6.2.5.4-4.2.1 imlib-devel-1.9.13-26.2.1 inn-devel-2.4.3-1 java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_83rh kdelibs-devel-3.5.2-1 kdenetwork-devel-3.5.2-1 krb5-devel-1.4.3-5 libart_lgpl-devel-2.3.17-2.2.1 libbonobo-devel-2.14.0-1 libbtctl-devel-0.6.0-5 libcroco-devel-0.6.1-1 libgcj-devel-4.1.0-11 libgconf-java-devel-2.12.1.0.20060301.rh1-0 libgcrypt-devel-1.2.2-1.2.1 libglade-java-devel-2.12.2.0.20060301.rh1-1 libgnomecanvas-devel-2.14.0-1 libgnome-java-devel-2.12.1.0.20060301.rh1-0 libgnomeprint22-devel-2.12.1-4.2 libgnomeprintui22-devel-2.12.1-1.2.1 libgpg-error-devel-1.1-1.2.1 libgsf-devel-1.14.0-1 libgssapi-devel-0.7-2.1 libgtk-java-devel-2.8.3.0.20060301.rh1-0 libicu-devel-3.4-6.2 libIDL-devel-0.8.6-2.2.1 libidn-devel-0.6.2-1.1 libpng-devel-1.2.8-2.2.1 libsilc-devel-0.9.12-12.2.1 libtiff-devel-3.8.2-1 libusb-devel-0.1.11-2.2 libuser-devel-0.54.6-1 libvte-java-devel-0.11.11.0.20060301.rh1-1.2 libwmf-devel-0.2.8.4-4.2 libwvstreams-devel-4.2.1-2 libXevie-devel-1.0.1-1 libXfontcache-devel-1.0.2-1 libXi-devel-1.0.1-1 libxml2-devel-2.6.24-1 libxml-devel-1.8.17-13.2.1 libXrandr-devel-1.1.1-1 libXres-devel-1.0.1-1 libxslt-devel-1.1.15-1.2.1 libXxf86dga-devel-1.0.1-1 libXxf86misc-devel-1.0.1-1 libXxf86vm-devel-1.0.1-1 mikmod-devel-3.1.6-36.2.1 mod_perl-devel-2.0.2-5.1 neon-devel-0.25.5-1.2 netpbm-devel-10.33-2 net-snmp-devel-5.3-8 nspr-devel-4.6.1-2.2 nss-devel-3.11-4 opal-devel-2.2.1-1 opensp-devel-1.5.2-1.2 ORBit2-devel-2.14.0-1 pciutils-devel-2.2.1-1.2 pcre-devel-6.3-1.2.1 php-devel-5.1.2-5 pwlib-devel-1.10.0-1 pygtk2-devel-2.8.6-1 python-devel-2.4.3-2 qt-devel-3.3.6-1 sane-backends-devel-1.0.17-8 SDL-devel-1.2.9-5.2.1 setools-devel-2.3-2 sox-devel-12.17.9-1.2 syslinux-devel-3.10-2.2 tn5250-devel-0.17.3-1.2.1 tog-pegasus-devel-2.5.1-3.FC6 xdelta-devel-1.1.3-17.2.1 xfsprogs-devel-2.7.11-1 xmlsec1-devel-1.2.9-4.2 From katzj at redhat.com Tue May 2 01:39:19 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 21:39:19 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146521943.11225.87.camel@orodruin.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <1146521943.11225.87.camel@orodruin.boston.redhat.com> Message-ID: <1146533959.10942.2.camel@aglarond.local> On Mon, 2006-05-01 at 18:19 -0400, Jeremy Katz wrote: > I'll work on making the full output with the exact conflicts in each > package available later tonight Now up at http://people.redhat.com/~katzj/multiarch-devel-conflicts.txt. Decided not to attach it since it's about 115k and spamming everyone's inbox isn't very nice :) Jeremy From petersen at redhat.com Thu May 4 04:41:15 2006 From: petersen at redhat.com (Jens Petersen) Date: Thu, 04 May 2006 13:41:15 +0900 Subject: [packaging question] multilib gtkimm (Input Method modules) In-Reply-To: <20060501170621.GF31572@devserv.devel.redhat.com> References: <44530544.2050403@redhat.com> <20060501170621.GF31572@devserv.devel.redhat.com> Message-ID: <445985EB.9080301@redhat.com> Bill Nottingham wrote: > Jens Petersen (petersen at redhat.com) said: >> Is there a better to deal with this? > > Have the package installer always resolve and install .compatarch > when .normalarch is asked for. So would require changes to yum? Jens From notting at redhat.com Thu May 4 04:57:47 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 May 2006 00:57:47 -0400 Subject: [packaging question] multilib gtkimm (Input Method modules) In-Reply-To: <445985EB.9080301@redhat.com> References: <44530544.2050403@redhat.com> <20060501170621.GF31572@devserv.devel.redhat.com> <445985EB.9080301@redhat.com> Message-ID: <20060504045747.GD12038@devserv.devel.redhat.com> Jens Petersen (petersen at redhat.com) said: > Bill Nottingham wrote: > >Jens Petersen (petersen at redhat.com) said: > >>Is there a better to deal with this? > > > >Have the package installer always resolve and install .compatarch > >when .normalarch is asked for. > > So would require changes to yum? Yes. I suppose it may be pluginable. Bill From skvidal at linux.duke.edu Thu May 4 05:02:37 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 04 May 2006 01:02:37 -0400 Subject: [packaging question] multilib gtkimm (Input Method modules) In-Reply-To: <20060504045747.GD12038@devserv.devel.redhat.com> References: <44530544.2050403@redhat.com> <20060501170621.GF31572@devserv.devel.redhat.com> <445985EB.9080301@redhat.com> <20060504045747.GD12038@devserv.devel.redhat.com> Message-ID: <1146718958.8619.2.camel@cutter> On Thu, 2006-05-04 at 00:57 -0400, Bill Nottingham wrote: > Jens Petersen (petersen at redhat.com) said: > > Bill Nottingham wrote: > > >Jens Petersen (petersen at redhat.com) said: > > >>Is there a better to deal with this? > > > > > >Have the package installer always resolve and install .compatarch > > >when .normalarch is asked for. > > > > So would require changes to yum? > > Yes. I suppose it may be pluginable. > plugins for that level of involvement in the depsolver are not advised. If there's a reason to depsolve this way - then open a bug/rfe about it, please - but right now it feels like too little rigor in multilib package creation. -sv From rdieter at math.unl.edu Fri May 5 14:13:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 05 May 2006 09:13:19 -0500 Subject: gsview pulled from Extras (soon) In-Reply-To: <4455F97A.4070806@math.unl.edu> References: <4455F97A.4070806@math.unl.edu> Message-ID: <445B5D7F.4080901@math.unl.edu> Rex Dieter wrote: > It's been brought to my attention that gsview does not meet necessary > licensing requirements, so will be pulled from Extras shortly: > http://bugzilla.redhat.com/bugzilla/190276 The deed is done. I've 'cvs remove'd all gview bits and posted removal requests to the FC?Status pages. -- Rex From katzj at redhat.com Mon May 8 20:14:10 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 May 2006 16:14:10 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146521943.11225.87.camel@orodruin.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <1146521943.11225.87.camel@orodruin.boston.redhat.com> Message-ID: <1147119251.981.64.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 18:19 -0400, Jeremy Katz wrote: > * foo-config scripts. As previously mentioned on this thread, the best > way to fix these is to create a pkg-config file and replace the > foo-config script with a wrapper that calls pkg-config (and is thus the > same on all arches) So, I've sat down and written a pretty generic foo-config script that should be able to be used to replace the vast majority of /usr/bin/foo-config scripts with a) a symlink to foo-config b) a .pc file in the appropriate location (%{_libdir}/pkg-config for arch-independent things) That should make the barrier here significantly lower. Matthias -- does this look okay to add to the pkgconfig package[1]? Jeremy [1] I'll send mail to the upstream pkgconfig list contributing it as a contrib/ type script, but overall, it's a transition kludge and the right thing to do is to help convince more upstream projects to use pkgconfig instead of relying on crutches. From mclasen at redhat.com Mon May 8 20:20:48 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 08 May 2006 16:20:48 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1147119251.981.64.camel@orodruin.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <1146521943.11225.87.camel@orodruin.boston.redhat.com> <1147119251.981.64.camel@orodruin.boston.redhat.com> Message-ID: <1147119648.2577.3.camel@dhcp83-7.boston.redhat.com> On Mon, 2006-05-08 at 16:14 -0400, Jeremy Katz wrote: > On Mon, 2006-05-01 at 18:19 -0400, Jeremy Katz wrote: > > * foo-config scripts. As previously mentioned on this thread, the best > > way to fix these is to create a pkg-config file and replace the > > foo-config script with a wrapper that calls pkg-config (and is thus the > > same on all arches) > > So, I've sat down and written a pretty generic foo-config script that > should be able to be used to replace the vast majority > of /usr/bin/foo-config scripts with > a) a symlink to foo-config > b) a .pc file in the appropriate location (%{_libdir}/pkg-config for > arch-independent things) > > That should make the barrier here significantly lower. Matthias -- does > this look okay to add to the pkgconfig package[1]? Sure. I would be even more sure if I could see it...missing attachment ? From katzj at redhat.com Mon May 8 20:20:55 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 May 2006 16:20:55 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1147119648.2577.3.camel@dhcp83-7.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <1146521943.11225.87.camel@orodruin.boston.redhat.com> <1147119251.981.64.camel@orodruin.boston.redhat.com> <1147119648.2577.3.camel@dhcp83-7.boston.redhat.com> Message-ID: <1147119655.981.66.camel@orodruin.boston.redhat.com> On Mon, 2006-05-08 at 16:20 -0400, Matthias Clasen wrote: > On Mon, 2006-05-08 at 16:14 -0400, Jeremy Katz wrote: > > On Mon, 2006-05-01 at 18:19 -0400, Jeremy Katz wrote: > > > * foo-config scripts. As previously mentioned on this thread, the best > > > way to fix these is to create a pkg-config file and replace the > > > foo-config script with a wrapper that calls pkg-config (and is thus the > > > same on all arches) > > > > So, I've sat down and written a pretty generic foo-config script that > > should be able to be used to replace the vast majority > > of /usr/bin/foo-config scripts with > > a) a symlink to foo-config > > b) a .pc file in the appropriate location (%{_libdir}/pkg-config for > > arch-independent things) > > > > That should make the barrier here significantly lower. Matthias -- does > > this look okay to add to the pkgconfig package[1]? > > Sure. I would be even more sure if I could see it...missing attachment ? *sigh* Attached for real this time Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: foo-config Type: application/x-shellscript Size: 822 bytes Desc: not available URL: From petersen at redhat.com Tue May 9 02:29:00 2006 From: petersen at redhat.com (Jens Petersen) Date: Tue, 09 May 2006 11:29:00 +0900 Subject: [packaging question] multilib gtkimm (Input Method modules) In-Reply-To: <44530544.2050403@redhat.com> References: <44530544.2050403@redhat.com> Message-ID: <445FFE6C.2050703@redhat.com> Jens Petersen wrote: > # require 32bit gtk IM module for 64bit multilib arches > %ifarch x86_64 s390x > Requires: %{_prefix}/lib/gtk-2.0/immodules/im-scim.so > %endif Would adding this for now be acceptable? > to the main scim package, so that installing scim.x86_64 would pull in > scim-libs.i386 [in addition to scim-libs.x86_64] Jens From notting at redhat.com Tue May 9 02:37:24 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 May 2006 22:37:24 -0400 Subject: [packaging question] multilib gtkimm (Input Method modules) In-Reply-To: <445FFE6C.2050703@redhat.com> References: <44530544.2050403@redhat.com> <445FFE6C.2050703@redhat.com> Message-ID: <20060509023724.GB1014@devserv.devel.redhat.com> Jens Petersen (petersen at redhat.com) said: > Jens Petersen wrote: > > # require 32bit gtk IM module for 64bit multilib arches > > %ifarch x86_64 s390x > > Requires: %{_prefix}/lib/gtk-2.0/immodules/im-scim.so > > %endif > > Would adding this for now be acceptable? It'd be a ugly hack. Why not just: Requires: im-scim.so ? Bill From aalam at redhat.com Tue May 9 05:58:39 2006 From: aalam at redhat.com (A S Alam) Date: Tue, 09 May 2006 11:28:39 +0530 Subject: missing header in timezone POT file Message-ID: <44602F8F.9070009@redhat.com> Timezone POT file's Header is missing in translate/system-config-date/timezone/timezones.pot with CVSROOT CVSROOT=:ext:aalam at i18n.redhat.com:/usr/local/CVS can someone please check and help? -- A S Alam join us at #fedora-l10n (freenode) "Either find a way or make one" From bugs.michael at gmx.net Tue May 9 09:42:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 9 May 2006 11:42:25 +0200 Subject: Attention, Extras packagers! [on Upgrades + Obsoletes] Message-ID: <20060509114225.fa05ecb5.bugs.michael@gmx.net> Seeing how the Fedora Extras Broken Dependencies reports have grown larger for some time, I believe some education is needed. Forgive me for calling it "education", but particularly the first issue really appears to be something that is not known widely yet: ==== When eliminating sub-packages in a spec file, regardless of whether it's done with or without a corresponding "Obsoletes: ..."/"Provides: ..." pair of tags, old binary builds will NOT disappear from the repository automatically. They become _binary orphans_, since no new builds of your packages will cause the old builds to be purged from the repository by an automated clean-up job. Yum and other tools like repoview and createrepo -- in the following I will write just "Yum" -- will still see these old packages in the repository. With Yum our users will still be able to install these obsolete packages as long as the RPM transaction succeeds. Else the user will encounter broken dependencies during installation or during a future update. During installation of a package, Yum sees ALL packages in the repository prior to creating the transaction set. Together with dependencies on specific versions of other packages, which have been upgraded meanwhile and are no longer available, the transaction would fail even more badly. Repoview and "yum list" also see and advertise all packages, including obsolete ones. || You need to request that the repository maintainers delete these || old/obsolete sub-packages! There is a related bug report about Yum (http://bugzilla.redhat.com/190116), since it's non-intuitive that "yum install foo" does not fetch the package which provides the highest version of "foo". Examples: 1) You have "foo" and "foo-devel" built and published. In an update, you eliminate and obsolete "foo-devel" and publish the new "foo". "foo-devel" will remain in the repository even if you make your new package "Provides: foo-devel = %{version}-%{release}" with version-release being higher than before. A "yum install foo-devel" will take your old foo-devel package and will usually fail badly in the transaction (because -devel packages depend on a specific version of their mother package). 2) You have "foo" and "foo-emacs" built and published. In an upgrade, support for Emacs is gone. First of all, this would be regression and should be avoided. But if you simply eliminate the "foo-emacs" package, the old binary builds will remain in the package repository. Forever. If they depend on other packages which are still available, too, even if it's older versions, users may still be able to install all this old stuff with "yum install foo-emacs". With the next upgrade: *boom* For instance, if any dependencies are upgraded/changed and a way which gets incompatible with the old sub-package which should have been deleted. ==== Further, we've had a couple of ABI breaking upgrades so far. Not just due to SONAME changes, but due to ordinary _major version upgrades_. Where apparently the package maintainers didn't talk to eachother despite the fact that ABI upgrades (in everything other than Fedora Extras Development) should be avoided like the plague. || When a package NEV (name-epoch-version) or NEVR || (name-epoch-version-release) is hardcoded as a dependency, || inform your fellow package maintainer about this strict dependency! Example: 1) Your package "foo" depends on a specific version of "bar", and you use a "Requires: bar = 2.0-1" tag for this. First of all, the reason for this strict dependency must be documented in the spec file. Secondly, the maintainer of "bar" must be informed about this package relationship, so any version upgrades of bar are coordinated properly with the packager of "foo". From gauret at free.fr Tue May 9 11:35:40 2006 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 9 May 2006 13:35:40 +0200 Subject: Attention, Extras packagers! [on Upgrades + Obsoletes] In-Reply-To: <20060509114225.fa05ecb5.bugs.michael@gmx.net> References: <20060509114225.fa05ecb5.bugs.michael@gmx.net> Message-ID: <200605091335.40104.gauret@free.fr> Le Mardi 9 Mai 2006 11:42, Michael Schwendt a ?crit : > || When a package NEV (name-epoch-version) or NEVR > || (name-epoch-version-release) is hardcoded as a dependency, > || inform your fellow package maintainer about this strict dependency! It can be a good habit to run "repoquery --whatrequires mypackage" before upgrading. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr There are only 10 types of people in the world : those who understand binary and those who don't. From roozbeh at farsiweb.info Tue May 9 13:32:10 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 09 May 2006 17:02:10 +0330 Subject: %{_host} different in FC and FE build environments Message-ID: <1147181530.3323.13.camel@tameshk.farsiweb.info> I was playing with an SVG rendering problem I had on a box that stopped gnome-games from working, and after a lot of debugging I found that it was because I had compiled the gtk2 package myself, but was using FC4's librsvg2. Now, librsvg2 runs this in it's %post: %{_bindir}/update-gdk-pixbuf-loaders %{_host} The %{_host} macro, expanded at build time, had resulted in "i386-redhat-linux-gnu". But gtk2, which I had rebuilt using a stock FC4's rpmbuild, had that %{_host} macro expanded to "i686-redhat-linux-gnu" (as defined in /usr/lib/rpm/macros). This resulted in an error message and all. I tried --target i386, I tried setarch i386, I tried mock, and I still got i686. The only way I could fix this was through defining redefining _host explicitly in my '.rpmmacros'. So, this means that the defaults used for building FC (beehive and co) is different from the FE ones (mock and co). This needs to be fixed, or to say the least, will result in weird things if we move, say, libwmf from core to extras. The question is: where should this be fixed? rpm? mock? beehive? where? I would prefer rpm (because that will have minimum change, and will enable people who just use plain rpmbuild), but wanted to ask before I file a bug. roozbeh From roozbeh at farsiweb.info Tue May 9 13:39:25 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 09 May 2006 17:09:25 +0330 Subject: Attention, Extras packagers! [on Upgrades + Obsoletes] In-Reply-To: <20060509114225.fa05ecb5.bugs.michael@gmx.net> References: <20060509114225.fa05ecb5.bugs.michael@gmx.net> Message-ID: <1147181965.3323.17.camel@tameshk.farsiweb.info> ??? ???????? 2006-05-09 ???? 11:42 +0200? Michael Schwendt ????: > 1) Your package "foo" depends on a specific version of "bar", and you use > a "Requires: bar = 2.0-1" tag for this. First of all, the reason for this > strict dependency must be documented in the spec file. Secondly, the > maintainer of "bar" must be informed about this package relationship, so > any version upgrades of bar are coordinated properly with the packager of > "foo". Does this include Core dependencies? And can we expect the Core maintainers to inform the Extras maintainers about this? This doesn't concern my packages of course, except the impossible case of python-abi getting upgraded, but it perhaps concerns other Extras packagers. roozbeh From rdieter at math.unl.edu Tue May 9 13:44:23 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 09 May 2006 08:44:23 -0500 Subject: %{_host} different in FC and FE build environments Message-ID: <44609CB7.6090405@math.unl.edu> Roozbeh Pournader wrote: > I was playing with an SVG rendering problem I had on a box that stopped > gnome-games from working, and after a lot of debugging I found that it > was because I had compiled the gtk2 package myself, but was using FC4's > librsvg2. Now, librsvg2 runs this in it's %post: > > %{_bindir}/update-gdk-pixbuf-loaders %{_host} > > The %{_host} macro, expanded at build time, had resulted in > "i386-redhat-linux-gnu". But gtk2, which I had rebuilt using a stock > FC4's rpmbuild, had that %{_host} macro expanded to > "i686-redhat-linux-gnu" (as defined in /usr/lib/rpm/macros). This > resulted in an error message and all. > > I tried --target i386, I tried setarch i386, I tried mock, and I still > got i686. The only way I could fix this was through defining redefining > _host explicitly in my '.rpmmacros'. > > So, this means that the defaults used for building FC (beehive and co) > is different from the FE ones (mock and co). This needs to be fixed, or > to say the least, will result in weird things if we move, say, libwmf > from core to extras. > > The question is: where should this be fixed? rpm? mock? beehive? where? The problem being is that %{_host) is based on the build host, not the target arch/platform. Any variant in buildhost will exhibit the problem you're seeing. The bug is in gtk2, IMO. I ran into the same problem in the past, my quick-n-dirty fix was to change %{_bindir}/update-gdk-pixbuf-loaders %{_host} to %{_bindir}/update-gdk-pixbuf-loaders %{_target_platform} add to %configure: --host="%{_target_platform}" -- Rex From roozbeh at farsiweb.info Tue May 9 14:06:24 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 09 May 2006 17:36:24 +0330 Subject: %{_host} different in FC and FE build environments In-Reply-To: <44609CB7.6090405@math.unl.edu> References: <44609CB7.6090405@math.unl.edu> Message-ID: <1147183584.3323.21.camel@tameshk.farsiweb.info> ??? ???????? 2006-05-09 ???? 08:44 -0500? Rex Dieter ????: > The problem being is that %{_host) is based on the build host, not the > target arch/platform. Any variant in buildhost will exhibit the problem > you're seeing. The bug is in gtk2, IMO. Aha. But I don't see a good strategy for fixing this in FC4/FE4 and FC5/FE5 without breaking things. So we need a hot fix somewhere. Where should that hotfix happen then? roozbeh From rdieter at math.unl.edu Tue May 9 14:17:37 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 09 May 2006 09:17:37 -0500 Subject: %{_host} different in FC and FE build environments Message-ID: <4460A481.5080109@math.unl.edu> >> The problem being is that %{_host) is based on the build host, not the >> target arch/platform. Any variant in buildhost will exhibit the problem >> you're seeing. The bug is in gtk2, IMO. > > Aha. But I don't see a good strategy for fixing this in FC4/FE4 and > FC5/FE5 without breaking things. So we need a hot fix somewhere. Where > should that hotfix happen then? As I said, the fix (IMO) needs to be in gtk2, see existing bugzilla reports on this same issue: http://bugzilla.redhat.com/bugzilla/143950 http://bugzilla.redhat.com/bugzilla/143547 -- Rex From roozbeh at farsiweb.info Tue May 9 14:49:48 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 09 May 2006 18:19:48 +0330 Subject: %{_host} different in FC and FE build environments In-Reply-To: <4460A481.5080109@math.unl.edu> References: <4460A481.5080109@math.unl.edu> Message-ID: <1147186188.3323.23.camel@tameshk.farsiweb.info> ??? ???????? 2006-05-09 ???? 09:17 -0500? Rex Dieter ????: > >> The problem being is that %{_host) is based on the build host, not the > >> target arch/platform. Any variant in buildhost will exhibit the problem > >> you're seeing. The bug is in gtk2, IMO. > > > > Aha. But I don't see a good strategy for fixing this in FC4/FE4 and > > FC5/FE5 without breaking things. So we need a hot fix somewhere. Where > > should that hotfix happen then? > > As I said, the fix (IMO) needs to be in gtk2, see existing bugzilla > reports on this same issue: > http://bugzilla.redhat.com/bugzilla/143950 > http://bugzilla.redhat.com/bugzilla/143547 Both of these are RHEL ones. Should I open a bug for Fedora? roozbeh From jwboyer at jdub.homelinux.org Tue May 9 20:06:43 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 9 May 2006 15:06:43 -0500 Subject: %{_host} different in FC and FE build environments In-Reply-To: <1147186188.3323.23.camel@tameshk.farsiweb.info> References: <4460A481.5080109@math.unl.edu> <1147186188.3323.23.camel@tameshk.farsiweb.info> Message-ID: <20060509200643.GG2418@yoda.jdub.homelinux.org> On Tue, May 09, 2006 at 06:19:48PM +0330, Roozbeh Pournader wrote: > ??? ???????? 2006-05-09 ???? 09:17 -0500? Rex Dieter ????: > > >> The problem being is that %{_host) is based on the build host, not the > > >> target arch/platform. Any variant in buildhost will exhibit the problem > > >> you're seeing. The bug is in gtk2, IMO. > > > > > > Aha. But I don't see a good strategy for fixing this in FC4/FE4 and > > > FC5/FE5 without breaking things. So we need a hot fix somewhere. Where > > > should that hotfix happen then? > > > > As I said, the fix (IMO) needs to be in gtk2, see existing bugzilla > > reports on this same issue: > > http://bugzilla.redhat.com/bugzilla/143950 > > http://bugzilla.redhat.com/bugzilla/143547 > > Both of these are RHEL ones. Should I open a bug for Fedora? If that is indeed the right fix, yes. josh From jorton at redhat.com Thu May 11 12:21:51 2006 From: jorton at redhat.com (Joe Orton) Date: Thu, 11 May 2006 13:21:51 +0100 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1147119251.981.64.camel@orodruin.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <1146521943.11225.87.camel@orodruin.boston.redhat.com> <1147119251.981.64.camel@orodruin.boston.redhat.com> Message-ID: <20060511122151.GA31211@redhat.com> I've been fixing up my packages' -config scripts by just doing: -libdir=@libdir@ +libdir=`pkg-config --variable=libdir $PACKAGE` which is simple enough and a maintainable hack, and not entirely dreadful. Still, I think this task is futile for many packages; httpd, mod_perl, probably both {postgre,my}sql. joe From wwoods at redhat.com Fri May 12 21:42:00 2006 From: wwoods at redhat.com (Will Woods) Date: Fri, 12 May 2006 17:42:00 -0400 Subject: Fedora Core package cleanup project Message-ID: <1147470120.18573.7.camel@metroid.rdu.redhat.com> I'm announcing the start of a new QA project, and I'm asking for your help. In the past, Core packages have not been held to the same standards as Extras. We want to fix this! We're starting by cleaning up the spec files so that Core packages can all be built using Mock. (If you aren't familiar with Mock, it's a cool RPM build tool that we use to build Fedora Extras.) This is where you come in: We need people to attempt Mock builds of Fedora Core packages, and file bugs when they find packages that don't build. Doing so will earn you the thanks and respect of your peers, but as an added incentive we're going to give away free stuff (!) to people who help out. Filing a bug on a broken package will earn you one Karma Point. If you include a patch that makes that package build successfully, you'll get five Karma Points. These will be redeemable for cool stuff from the Red Hat Cool Stuff Store (at an exchange rate to be determined once we figure out how much stuff we're actually allowed to give away :) For more info, check out: http://fedoraproject.org/wiki/QA/FixBuildRequires Ok? OK! Let's get testin'! -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bdpepple at ameritech.net Fri May 12 23:21:58 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Fri, 12 May 2006 19:21:58 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <1147476118.23834.1.camel@shuttle.piedmont.com> On Fri, 2006-05-12 at 17:42 -0400, Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. (If you aren't > familiar with Mock, it's a cool RPM build tool that we use to build > Fedora Extras.) > > This is where you come in: We need people to attempt Mock builds of > Fedora Core packages, and file bugs when they find packages that don't > build. > > Doing so will earn you the thanks and respect of your peers, but as an > added incentive we're going to give away free stuff (!) to people who > help out. > > Filing a bug on a broken package will earn you one Karma Point. If you > include a patch that makes that package build successfully, you'll get > five Karma Points. These will be redeemable for cool stuff from the Red > Hat Cool Stuff Store (at an exchange rate to be determined once we > figure out how much stuff we're actually allowed to give away :) > > For more info, check out: > http://fedoraproject.org/wiki/QA/FixBuildRequires > > Ok? OK! Let's get testin'! What about existing bugs that had been opened on Missing BR w/patches? For example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182174 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 12 23:57:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 May 2006 19:57:22 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147476118.23834.1.camel@shuttle.piedmont.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147476118.23834.1.camel@shuttle.piedmont.com> Message-ID: <1147478242.11744.2.camel@ender> On Fri, 2006-05-12 at 19:21 -0400, Brian Pepple wrote: > > What about existing bugs that had been opened on Missing BR w/patches? > For example: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182174 That's a good question. If it's your bug, then feel free to set it as blocking the master bug and you'll get karma credits. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Sat May 13 10:50:14 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 13 May 2006 12:50:14 +0200 Subject: Fedora Core package cleanup project In-Reply-To: Your message of "Fri, 12 May 2006 17:42:00 EDT." <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <200605131050.k4DAoKfQ028662@mx1.redhat.com> wwoods at redhat.com said: > For more info, check out: http://fedoraproject.org/wiki/QA/FixBuildRequires On that page, there is a link to the "fixbuildrequires file from Fedora CVS module": http://cvs.fedora.redhat.com/viewcvs/fedora-qa/fixbuildrequires?root=fedora&view=markup This doesn't work: ---- An Exception Has Occurred fedora-qa/fixbuildrequires: unknown location HTTP Response Status 404 Not Found Python Traceback Traceback (most recent call last): File "/usr/share/viewcvs/lib/viewcvs.py", line 3275, in main request.run_viewcvs() File "/usr/share/viewcvs/lib/viewcvs.py", line 291, in run_viewcvs % self.where, '404 Not Found') ViewCVSException: 404 Not Found: fedora-qa/fixbuildrequires: unknown location ---- Could someone please look into it ? Thanks, Christian From garrick at usc.edu Sat May 13 10:57:56 2006 From: garrick at usc.edu (Garrick Staples) Date: Sat, 13 May 2006 03:57:56 -0700 Subject: Fedora Core package cleanup project In-Reply-To: <200605131050.k4DAoKfQ028662@mx1.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <200605131050.k4DAoKfQ028662@mx1.redhat.com> Message-ID: <20060513105756.GQ4298@polop.usc.edu> On Sat, May 13, 2006 at 12:50:14PM +0200, Christian.Iseli at licr.org alleged: > > wwoods at redhat.com said: > > For more info, check out: http://fedoraproject.org/wiki/QA/FixBuildRequires > > On that page, there is a link to the > "fixbuildrequires file from Fedora CVS module": > http://cvs.fedora.redhat.com/viewcvs/fedora-qa/fixbuildrequires?root=fedora&view=markup The bottom of that page says "we're still getting the CVS module in place." (took me a while too since the link is at the top and the disclaimer is at the bottom) -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Sat May 13 11:02:13 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 13 May 2006 13:02:13 +0200 Subject: Fedora Core package cleanup project In-Reply-To: Your message of "Sat, 13 May 2006 03:57:56 PDT." <20060513105756.GQ4298@polop.usc.edu> Message-ID: <200605131102.k4DB2JKw017000@mx3.redhat.com> garrick at usc.edu said: > The bottom of that page says "we're still getting the CVS module in place." > (took me a while too since the link is at the top and the disclaimer is at > the bottom) Doh. Sorry. Guess I'll need to learn to read after all... Thanks for reading it aloud to me :) Cheers, Christian From Christian.Iseli at licr.org Sat May 13 16:42:27 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 13 May 2006 18:42:27 +0200 Subject: Fedora Core package cleanup project In-Reply-To: Your message of "Fri, 12 May 2006 17:42:00 EDT." <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <200605131642.k4DGgStw031568@mx1.redhat.com> wwoods at redhat.com said: > This is where you come in: We need people to attempt Mock builds of Fedora > Core packages, and file bugs when they find packages that don't build. How 'bout a quick rpmlint on built packages ? One of the warning that'll probably often appear is the non-standard-group thing. Is there any plan to either remove or expand the group tag in spec files (and use comps.xml if it's removed) ? Christian From michael at knox.net.nz Sat May 13 20:05:34 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 14 May 2006 08:05:34 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <200605131642.k4DGgStw031568@mx1.redhat.com> References: <200605131642.k4DGgStw031568@mx1.redhat.com> Message-ID: <44663C0E.9030407@knox.net.nz> Christian.Iseli at licr.org wrote: > wwoods at redhat.com said: >> This is where you come in: We need people to attempt Mock builds of Fedora >> Core packages, and file bugs when they find packages that don't build. > > How 'bout a quick rpmlint on built packages ? > > One of the warning that'll probably often appear is the > non-standard-group thing. Is there any plan to either remove or expand the > group tag in spec files (and use comps.xml if it's removed) ? I think that is a good idea, but I am guess the core devs will want this first hurdle out the way first. Michael From michael at knox.net.nz Sun May 14 02:40:29 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 14 May 2006 14:40:29 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <4466989D.7030105@knox.net.nz> Quick question.. Is it OK to do this with FC5 as the build host? I mirror locally FC5 + updates and would save me a ton of bandwidth (which still costs heaps in NZ). Thanks Michael Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. (If you aren't > familiar with Mock, it's a cool RPM build tool that we use to build > Fedora Extras.) > > This is where you come in: We need people to attempt Mock builds of > Fedora Core packages, and file bugs when they find packages that don't > build. > > Doing so will earn you the thanks and respect of your peers, but as an > added incentive we're going to give away free stuff (!) to people who > help out. > > Filing a bug on a broken package will earn you one Karma Point. If you > include a patch that makes that package build successfully, you'll get > five Karma Points. These will be redeemable for cool stuff from the Red > Hat Cool Stuff Store (at an exchange rate to be determined once we > figure out how much stuff we're actually allowed to give away :) > > For more info, check out: > http://fedoraproject.org/wiki/QA/FixBuildRequires > > Ok? OK! Let's get testin'! > > -w > > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jkeating at redhat.com Sun May 14 03:17:40 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 13 May 2006 23:17:40 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <4466989D.7030105@knox.net.nz> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> Message-ID: <200605132317.46229.jkeating@redhat.com> On Saturday 13 May 2006 22:40, Michael J Knox wrote: > Quick question.. > > Is it OK to do this with FC5 as the build host? I mirror locally FC5 + > updates and would save me a ton of bandwidth (which still costs heaps in > NZ). It really should be done w/ development as things have changed enough. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun May 14 03:18:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 13 May 2006 23:18:21 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <200605131642.k4DGgStw031568@mx1.redhat.com> References: <200605131642.k4DGgStw031568@mx1.redhat.com> Message-ID: <200605132318.22046.jkeating@redhat.com> On Saturday 13 May 2006 12:42, Christian.Iseli at licr.org wrote: > How 'bout a quick rpmlint on built packages ? We're focusing on BuildRequires only for this round of QA. It makes it much easier to process the patches if that's all they address. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at knox.net.nz Sun May 14 04:22:55 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 14 May 2006 16:22:55 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <200605132317.46229.jkeating@redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <200605132317.46229.jkeating@redhat.com> Message-ID: <4466B09F.5030404@knox.net.nz> Jesse Keating wrote: > On Saturday 13 May 2006 22:40, Michael J Knox wrote: >> Quick question.. >> >> Is it OK to do this with FC5 as the build host? I mirror locally FC5 + >> updates and would save me a ton of bandwidth (which still costs heaps in >> NZ). > > It really should be done w/ development as things have changed enough. > Fair enough. I will start mirroring devel too Michael From Matt_Domsch at dell.com Sun May 14 13:50:50 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 14 May 2006 08:50:50 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <4466989D.7030105@knox.net.nz> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> Message-ID: <20060514135050.GA8419@lists.us.dell.com> On Sun, May 14, 2006 at 02:40:29PM +1200, Michael J Knox wrote: > Quick question.. > > Is it OK to do this with FC5 as the build host? I mirror locally FC5 + > updates and would save me a ton of bandwidth (which still costs heaps in > NZ). FWIW, I've taken 3 systems the past 12 hours, and have nearly finished rebuilding rawhide on x86_64. You can find the results here: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Some have had rpmlint run on them, many haven't (2 of my build systems did't have it installed; d'oh). I'll run them all, and rpmdiff against rawhide, when done. The above resyncs at the top of the hour as packages finish. So folks can start looking without needing to build each themselves. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From bdpepple at ameritech.net Sun May 14 14:10:30 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 14 May 2006 10:10:30 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <20060514135050.GA8419@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <20060514135050.GA8419@lists.us.dell.com> Message-ID: <1147615830.8004.2.camel@shuttle.piedmont.com> On Sun, 2006-05-14 at 08:50 -0500, Matt Domsch wrote: > On Sun, May 14, 2006 at 02:40:29PM +1200, Michael J Knox wrote: > > Quick question.. > > > > Is it OK to do this with FC5 as the build host? I mirror locally FC5 + > > updates and would save me a ton of bandwidth (which still costs heaps in > > NZ). > > FWIW, I've taken 3 systems the past 12 hours, and have nearly finished > rebuilding rawhide on x86_64. You can find the results here: > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > > Some have had rpmlint run on them, many haven't (2 of my build systems > did't have it installed; d'oh). I'll run them all, and rpmdiff > against rawhide, when done. The above resyncs at the top of the hour > as packages finish. So folks can start looking without needing to > build each themselves. > A lot of theses failures are due to Rawhide being broken (libX11-devel is missing), and shouldn't have bugs opened on them. If you could run this after Rawhide is fixed, it would be more useful. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun May 14 14:12:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 14 May 2006 10:12:51 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147615830.8004.2.camel@shuttle.piedmont.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <20060514135050.GA8419@lists.us.dell.com> <1147615830.8004.2.camel@shuttle.piedmont.com> Message-ID: <200605141012.54769.jkeating@redhat.com> On Sunday 14 May 2006 10:10, Brian Pepple wrote: > A lot of theses failures are due to Rawhide being broken (libX11-devel > is missing), and shouldn't have bugs opened on them. ?If you could run > this after Rawhide is fixed, it would be more useful. Yeah, whoops. Bad timing on starting this :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Sun May 14 14:49:50 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 14 May 2006 09:49:50 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <1147615830.8004.2.camel@shuttle.piedmont.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <20060514135050.GA8419@lists.us.dell.com> <1147615830.8004.2.camel@shuttle.piedmont.com> Message-ID: <20060514144950.GB8419@lists.us.dell.com> On Sun, May 14, 2006 at 10:10:30AM -0400, Brian Pepple wrote: > On Sun, 2006-05-14 at 08:50 -0500, Matt Domsch wrote: > > On Sun, May 14, 2006 at 02:40:29PM +1200, Michael J Knox wrote: > > > Quick question.. > > > > > > Is it OK to do this with FC5 as the build host? I mirror locally FC5 + > > > updates and would save me a ton of bandwidth (which still costs heaps in > > > NZ). > > > > FWIW, I've taken 3 systems the past 12 hours, and have nearly finished > > rebuilding rawhide on x86_64. You can find the results here: > > > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > > > > Some have had rpmlint run on them, many haven't (2 of my build systems > > did't have it installed; d'oh). I'll run them all, and rpmdiff > > against rawhide, when done. The above resyncs at the top of the hour > > as packages finish. So folks can start looking without needing to > > build each themselves. > > > > A lot of theses failures are due to Rawhide being broken (libX11-devel > is missing), and shouldn't have bugs opened on them. If you could run > this after Rawhide is fixed, it would be more useful. will do. I'll try to let it run continuously for a while, so as new packages hit rawhide, it'll pick those up. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jkeating at redhat.com Sun May 14 17:05:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 14 May 2006 13:05:27 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <200605141012.54769.jkeating@redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> Message-ID: <200605141305.33087.jkeating@redhat.com> On Sunday 14 May 2006 10:12, Jesse Keating wrote: > Yeah, whoops. ?Bad timing on starting this :/ A new rawhide push just went out. This has fixed deps for the X11 libs. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at knox.net.nz Sun May 14 19:45:50 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 15 May 2006 07:45:50 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <20060514144950.GB8419@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <20060514135050.GA8419@lists.us.dell.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <20060514144950.GB8419@lists.us.dell.com> Message-ID: <446788EE.8010804@knox.net.nz> Matt Domsch wrote: > On Sun, May 14, 2006 at 10:10:30AM -0400, Brian Pepple wrote: > >>On Sun, 2006-05-14 at 08:50 -0500, Matt Domsch wrote: >> >>>On Sun, May 14, 2006 at 02:40:29PM +1200, Michael J Knox wrote: >>> >>>>Quick question.. >>>> >>>>Is it OK to do this with FC5 as the build host? I mirror locally FC5 + >>>>updates and would save me a ton of bandwidth (which still costs heaps in >>>>NZ). >>> >>>FWIW, I've taken 3 systems the past 12 hours, and have nearly finished >>>rebuilding rawhide on x86_64. You can find the results here: >>> >>>http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ >>> >>>Some have had rpmlint run on them, many haven't (2 of my build systems >>>did't have it installed; d'oh). I'll run them all, and rpmdiff >>>against rawhide, when done. The above resyncs at the top of the hour >>>as packages finish. So folks can start looking without needing to >>>build each themselves. >>> >> >>A lot of theses failures are due to Rawhide being broken (libX11-devel >>is missing), and shouldn't have bugs opened on them. If you could run >>this after Rawhide is fixed, it would be more useful. > > > will do. I'll try to let it run continuously for a while, so as new > packages hit rawhide, it'll pick those up. > > Nice work... I will start working through those. Michael From bugs.michael at gmx.net Mon May 15 10:44:35 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 15 May 2006 12:44:35 +0200 Subject: atitvout + gai-pal : Orphaned dependencies! Message-ID: <20060515124435.35771846.bugs.michael@gmx.net> http://fedoraproject.org/wiki/Extras/OrphanedPackages The packages lrmi xosd are on the list of orphaned packages. They are required by: atitvout (lrmi) gai-pal (xosd) From Matt_Domsch at dell.com Mon May 15 13:52:20 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 15 May 2006 08:52:20 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <200605141305.33087.jkeating@redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> Message-ID: <20060515135220.GC8419@lists.us.dell.com> On Sun, May 14, 2006 at 01:05:27PM -0400, Jesse Keating wrote: > On Sunday 14 May 2006 10:12, Jesse Keating wrote: > > Yeah, whoops. ??Bad timing on starting this :/ > > A new rawhide push just went out. This has fixed deps for the X11 libs. So, for everything that had failed to build for any reason (including broken libX11), I rebuilt everything (tclx is still going after 10 hours, dang it's got a long 'make test' run...). Here's the list of SRPMs that failed to generate binary RPMs on x86_64 against rawhide (258 packages). The full package build results, logs, rpmlints and rpmdiffs are posted here: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ And the list: agg-2.4-1.src.rpm amanda-2.5.0-2.src.rpm apmd-3.2.2-3.2.src.rpm arptables_jf-0.0.8-6.2.1.src.rpm arts-1.5.2-1.src.rpm at-spi-1.7.7-6.src.rpm beagle-0.2.6-2.src.rpm bluez-pin-0.30-2.src.rpm bsf-2.3.0-6jpp_3fc.src.rpm cairo-java-1.0.3-0.src.rpm classpathx-jaf-1.0-2jpp_5fc.src.rpm cman-kernel-2.6.15.1-0.FC5.19.src.rpm compat-gcc-296-2.96-135.src.rpm compat-gcc-32-3.2.3-55.fc5.src.rpm control-center-2.14.1-3.src.rpm crash-4.0-2.18.1.src.rpm cyrus-sasl-2.1.21-11.src.rpm desktop-printing-0.19-6.src.rpm device-mapper-multipath-0.4.5-12.2.src.rpm dictd-1.9.15-6.src.rpm diskdumputils-1.2.8-4.src.rpm dlm-kernel-2.6.15.1-0.FC5.17.src.rpm e2fsprogs-1.38-12.src.rpm eclipse-3.1.2-1jpp_13fc.src.rpm eel2-2.14.1-2.src.rpm ekiga-2.0.1-1.src.rpm elilo-3.6-1.1.src.rpm eog-2.15.1-1.src.rpm epiphany-2.15.1-1.src.rpm evolution-connector-2.6.1-2.src.rpm evolution-sharp-0.10.2-9.src.rpm failed-to-build.txt foomatic-3.0.2-34.src.rpm freeglut-2.4.0-4.src.rpm frysk-0.0.1.2006.02.19.rh2-0.FC5.2.src.rpm gail-1.8.11-1.src.rpm gcalctool-5.8.10-1.src.rpm gcc-4.1.0-14.src.rpm gdk-pixbuf-0.22.0-23.src.rpm gdm-2.15.0-1.src.rpm gecko-sharp2-0.11-6.src.rpm GFS-kernel-2.6.15.1-5.FC5.20.src.rpm gimp-print-4.2.7-16.src.rpm gmime-2.1.19-3.src.rpm gnbd-kernel-2.6.15-5.FC5.26.src.rpm gnome-games-2.15.1-1.src.rpm gnome-media-2.14.0-2.src.rpm gnome-mount-0.4-5.src.rpm gnome-panel-2.14.1-2.src.rpm gnome-power-manager-2.15.1-1.src.rpm gnome-python2-2.12.4-1.src.rpm gnome-python2-desktop-2.14.0-1.src.rpm gnome-python2-extras-2.14.0-1.src.rpm gnome-utils-2.15.0-1.src.rpm gnucash-1.9.5-3.src.rpm gnu-efi-3.0c-1.src.rpm gpart-0.1h-1.2.src.rpm gphoto2-2.1.99-10.src.rpm grub-0.97-5.src.rpm gtk-doc-1.6-2.src.rpm g-wrap-1.9.6-4.src.rpm hal-0.5.7-7.src.rpm hal-cups-utils-0.5.5-2.src.rpm hdparm-6.3-2.2.src.rpm HelixPlayer-1.0.6-1.2.2.src.rpm ImageMagick-6.2.5.4-4.2.1.src.rpm imlib-1.9.13-26.2.1.src.rpm initscripts-8.33-1.src.rpm iproute-2.6.16-1.src.rpm iprutils-2.1.1-1.2.src.rpm iptraf-3.0.0-2.src.rpm isdn4k-utils-3.2-45.src.rpm jakarta-commons-codec-1.3-2jpp_4fc.src.rpm jakarta-commons-dbcp-1.2.1-3jpp_3fc.src.rpm jakarta-commons-el-1.0-4jpp_6fc.src.rpm jakarta-commons-pool-1.2-2jpp_4fc.src.rpm jakarta-taglibs-standard-1.1.1-4jpp_3fc.src.rpm java-1.4.2-gcj-compat-1.4.2.0-40jpp_83rh.src.rpm jsch-0.1.18-1jpp_7fc.src.rpm kdeartwork-3.5.2-1.src.rpm kdebase-3.5.2-7.src.rpm kdebindings-3.5.2-1.src.rpm kdegames-3.5.2-1.src.rpm kdelibs-3.5.2-3.src.rpm kdemultimedia-3.5.2-2.src.rpm kdenetwork-3.5.2-1.src.rpm kdepim-3.5.2-2.src.rpm kdesdk-3.5.2-1.src.rpm kdeutils-3.5.2-1.src.rpm kdevelop-3.3.2-1.src.rpm kdewebdev-3.5.2-1.src.rpm kon2-0.3.9b-26.2.src.rpm latex2html-2002.2.1-5.1.src.rpm ldapjdk-4.17-1jpp_3fc.1.1.src.rpm libbonoboui-2.14.0-1.src.rpm libbtctl-0.6.0-5.src.rpm libgconf-java-2.12.1.0.20060301.rh1-0.src.rpm libglade-java-2.12.3-0.src.rpm libgnomecups-0.2.2-3.2.1.src.rpm libgnomeprint22-2.12.1-4.2.src.rpm libnl-1.0-0.8.pre5.src.rpm libnotify-0.3.0-6.src.rpm libofx-0.8.0-2.2.src.rpm librtas-1.2.4-1.2.1.src.rpm libsemanage-1.6.7-1.src.rpm libunwind-0.98.2-4.src.rpm libusb-0.1.11-2.2.src.rpm libvte-java-0.11.11.0.20060301.rh1-2.src.rpm libwmf-0.2.8.4-7.src.rpm libwnck-2.14.1-2.src.rpm longrun-0.9-1.12.src.rpm lvm2-2.02.01-1.2.1.src.rpm lvm2-2.02.06-1.0.src.rpm magma-plugins-1.0.5-0.FC5.1.1.src.rpm mcstrans-0.1.3-1.src.rpm memtest86+-1.65-2.2.src.rpm mesa-6.5-4.src.rpm metacity-2.15.2-2.src.rpm mozilla-1.7.13-1.1.fc5.src.rpm mozplugger-1.7.3-2.2.1.src.rpm mtools-3.9.10-1.2.1.src.rpm mx4j-3.0.1-1jpp_9fc.src.rpm nano-1.3.8-1.2.1.src.rpm nautilus-2.14.1-3.src.rpm nautilus-sendto-0.4-7.2.src.rpm net-tools-1.60-70.src.rpm nfs-utils-1.0.8.rc2-5.FC5.src.rpm nfs-utils-lib-1.0.8-3.1.src.rpm nmap-4.03-1.src.rpm notify-daemon-0.3.1-10.src.rpm nss_ldap-250-4.src.rpm nut-2.0.3-1.src.rpm opal-2.2.1-1.src.rpm openCryptoki-2.1.6-2.2.src.rpm openhpi-2.2.1-4.2.src.rpm openswan-2.4.5-1.src.rpm pam-0.99.4.0-1.src.rpm pango-1.13.0-1.src.rpm perl-XML-Simple-2.14-2.1.src.rpm planner-0.13-4.1.src.rpm ppc64-utils-0.9-12.2.1.src.rpm prctl-1.4-5.2.src.rpm psgml-1.2.5-4.1.src.rpm psmisc-22.1.03072006cvs-1.1.src.rpm pydict-0.3.0-8.1.src.rpm python-pyblock-0.15-1.src.rpm pyxf86config-0.3.24-1.src.rpm qt-3.3.6-3.src.rpm reiserfs-utils-3.6.19-2.2.src.rpm rgmanager-1.9.31-3.src.rpm rhythmbox-0.8.8-2.src.rpm rhythmbox-0.9.4.1-2.src.rpm s390utils-1.5.0-2.1.src.rpm salinfo-0.5-1.11_FC5.src.rpm scim-1.4.4-16.src.rpm selinux-doc-1.25.2-1.src.rpm setserial-2.17-19.2.1.src.rpm sound-juicer-2.14.3-2.src.rpm squashfs-tools-2.2r2-2.2.1.src.rpm stardict-2.4.5-2.3.src.rpm startup-notification-0.8-3.2.1.src.rpm struts-1.2.8-2jpp_9fc.src.rpm subversion-1.3.1-4.src.rpm synaptics-0.14.4-6.src.rpm syslinux-3.10-2.2.src.rpm system-config-netboot-0.1.40-1.FC6.src.rpm tclx-8.4.0-1.2.src.rpm tetex-3.0-24.src.rpm thunderbird-1.5.0.2-2.src.rpm tn5250-0.17.3-1.2.1.src.rpm tomboy-0.3.5-3.src.rpm tomcat5-5.5.15-1jpp_6fc.src.rpm totem-1.4.0-2.src.rpm transfig-3.2.4-13.2.src.rpm tux-3.2.18-4.2.1.src.rpm tvtime-1.0.1-3.2.src.rpm valgrind-3.1.1-2.src.rpm vino-2.13.5-2.2.src.rpm vixie-cron-4.1-54.FC5.src.rpm vte-0.13.0-1.src.rpm xchat-2.6.0-4.src.rpm xdoclet-1.2.2-2jpp_5fc.src.rpm xen-3.0.2-4.src.rpm xfig-3.2.4-20.src.rpm xjavadoc-1.1-1jpp_4fc.src.rpm xorg-x11-apps-1.0.3-1.src.rpm xorg-x11-drv-acecad-1.1.0-1.src.rpm xorg-x11-drv-aiptek-1.0.1-1.src.rpm xorg-x11-drv-apm-1.1.1-1.src.rpm xorg-x11-drv-ark-0.6.0-1.src.rpm xorg-x11-drv-calcomp-1.1.0-1.src.rpm xorg-x11-drv-chips-1.1.1-1.src.rpm xorg-x11-drv-cirrus-1.1.0-1.src.rpm xorg-x11-drv-citron-2.2.0-1.src.rpm xorg-x11-drv-cyrix-1.1.0-1.src.rpm xorg-x11-drv-digitaledge-1.1.0-1.src.rpm xorg-x11-drv-dmc-1.1.0-1.src.rpm xorg-x11-drv-dummy-0.2.0-1.src.rpm xorg-x11-drv-dynapro-1.1.0-1.src.rpm xorg-x11-drv-elo2300-1.1.0-1.src.rpm xorg-x11-drv-elographics-1.1.0-1.src.rpm xorg-x11-drv-evdev-1.1.0-3.src.rpm xorg-x11-drv-fbdev-0.2.0-1.src.rpm xorg-x11-drv-fpit-1.1.0-1.src.rpm xorg-x11-drv-glint-1.1.1-1.src.rpm xorg-x11-drv-hyperpen-1.1.0-1.src.rpm xorg-x11-drv-i128-1.2.0-1.src.rpm xorg-x11-drv-i740-1.1.0-1.src.rpm xorg-x11-drv-i810-1.6.0-1.src.rpm xorg-x11-drv-jamstudio-1.1.0-1.src.rpm xorg-x11-drv-joystick-1.1.0-1.src.rpm xorg-x11-drv-keyboard-1.1.0-1.src.rpm xorg-x11-drv-magellan-1.1.0-1.src.rpm xorg-x11-drv-magictouch-1.0.0.5-1.2.src.rpm xorg-x11-drv-mga-1.4.1-1.src.rpm xorg-x11-drv-microtouch-1.1.0-1.src.rpm xorg-x11-drv-mouse-1.1.0-1.src.rpm xorg-x11-drv-mutouch-1.1.0-1.src.rpm xorg-x11-drv-neomagic-1.1.1-1.src.rpm xorg-x11-drv-nsc-2.8.1-1.src.rpm xorg-x11-drv-nv-1.1.1-2.src.rpm xorg-x11-drv-palmax-1.1.0-1.src.rpm xorg-x11-drv-penmount-1.1.0-1.src.rpm xorg-x11-drv-rendition-4.1.0-1.src.rpm xorg-x11-drv-s3-0.4.1-1.src.rpm xorg-x11-drv-s3virge-1.9.1-1.src.rpm xorg-x11-drv-savage-2.1.1-1.src.rpm xorg-x11-drv-siliconmotion-1.4.1-1.src.rpm xorg-x11-drv-sis-0.9.1-1.src.rpm xorg-x11-drv-sisusb-0.8.1-1.src.rpm xorg-x11-drv-spaceorb-1.1.0-1.src.rpm xorg-x11-drv-summa-1.1.0-1.src.rpm xorg-x11-drv-tdfx-1.2.1-1.src.rpm xorg-x11-drv-tek4957-1.1.0-1.src.rpm xorg-x11-drv-trident-1.2.1-1.src.rpm xorg-x11-drv-tseng-1.1.0-1.src.rpm xorg-x11-drv-ur98-1.1.0-1.src.rpm xorg-x11-drv-v4l-0.1.1-1.src.rpm xorg-x11-drv-vesa-1.1.0-1.src.rpm xorg-x11-drv-vga-4.1.0-1.src.rpm xorg-x11-drv-via-0.2.1-1.src.rpm xorg-x11-drv-vmmouse-12.4.0-1.src.rpm xorg-x11-drv-vmware-10.13.0-1.src.rpm xorg-x11-drv-void-1.1.0-1.src.rpm xorg-x11-drv-voodoo-1.1.0-1.src.rpm xorg-x11-fonts-7.0-3.src.rpm xorg-x11-resutils-1.0.1-1.2.src.rpm xorg-x11-server-1.0.99.903-1.src.rpm xorg-x11-server-utils-1.0.1-4.src.rpm xorg-x11-utils-1.0.1-2.src.rpm xorg-x11-xdm-1.0.4-1.src.rpm xorg-x11-xfs-1.0.2-1.src.rpm xorg-x11-xfwp-1.0.1-1.2.src.rpm xorg-x11-xsm-1.0.2-1.src.rpm xscreensaver-4.24-2.src.rpm yaboot-1.3.13-0.18.src.rpm yelp-2.15.1-1.src.rpm zsh-4.2.5-1.2.2.src.rpm Some of these are obvious, like yaboot shouldn't build on x86_64 (it's ExclusiveArch'd). But most others should... There are a few duplicate packages (2 different versions) just because rawhide was updated: lvm2, rhythmbox leap out. If it failed once, it failed twice. :-) -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From bugs.michael at gmx.net Mon May 15 16:00:31 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 15 May 2006 18:00:31 +0200 Subject: licq + atitvout + gai-pal : Orphaned dependencies! In-Reply-To: <20060515124435.35771846.bugs.michael@gmx.net> References: <20060515124435.35771846.bugs.michael@gmx.net> Message-ID: <20060515180031.c95475dc.bugs.michael@gmx.net> On Mon, 15 May 2006 12:44:35 +0200, Michael Schwendt wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > The packages > > lrmi > xosd > > are on the list of orphaned packages. They are required by: > > atitvout (lrmi) > gai-pal (xosd) licq also needs xosd. From pknirsch at redhat.com Mon May 15 17:26:45 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Mon, 15 May 2006 19:26:45 +0200 Subject: Post/Pre install/uninstall script failures in fc5-extras packages on x86_64 Message-ID: <4468B9D5.1070603@redhat.com> Hi folks. I've ran a rather long running check to see if the fc5-extras packages have any post/pre install/uninstall script problems. It's the same test i run a while ago for fc4. Almost all script failures are fixed there, so i though i rerun the same test on the extras packages now. Here a quick summary list of the affected packages and the required fixes. All are simple specfile changes, so no big deal. I'll put the whole logfiles on my http://people.redhat.com/pknirsch webpage in the next few days: boa-0.94.14-0.4.rc21.fc5.x86_64 - Missing PreReq: chkconfig bwbar-1.2.2-4.x86_64 - Missing PreReq: chkconfig Canna-3.7p3-15.fc5.x86_64 - Missing PreReq: shadow-utils clamav-update-0.88-2.fc5.x86_64 - Missing groupadd clamav or - Missing PreReq: clamav-data compat-wxGTK-devel-2.4.2-17.fc5.x86_64 - Missing PreReq: coreutils ddclient-3.6.6-1.fc5.noarch - Missing PreReq: chkconfig, coreutils exim-4.61-2.fc5.x86_64 - Missing directories /usr/share/ssl/certs and /usr/share/ssl/privates, need to be created prior to running openssl req fish-1.12.0-1.fc5.x86_64 - Missing PreReq: coreutils, grep fonts-hebrew-fancy-0.101-2.fc5.noarch - Missing PreReq: fontconfig fpc-2.0.2-4.fc5.x86_64 - Missing PreReq: coreutils, gawk, gcc graphviz-2.8-3.fc5.x86_64 - Missing PreReq: coreutils ifplugd-0.24-6.x86_64 - Missing PreReq: chkconfig kannel-1.4.0-8.fc5.x86_64 - Missing PreReq: chkconfig monotone-server-0.26-1.fc5.x86_64 - Missing PreReq: chkconfig nethack-3.4.3-9.fc5.x86_64 - Missing PreReq: xorg-x11-font-utils nsd-2.3.3-7.fc5.x86_64 - Missing PreReq: chkconfig plt-scheme-301-2.fc5.x86_64 - Even on 64bit machines /usr/lib/plt/install is called, needs to be /usr/lib64/plt/install on those machines though. pop-before-smtp-1.36-2.noarch - Missing PreReq: chkconfig sblim-cmpi-base-1.5.4-3.fc5.x86_64 - If no cimserver is running the script complains that it can't deregister the providers in the preuninstall script. slib-3a1-5.1.noarch - Missing PreReq: coreutils snort-2.4.4-3.fc5.x86_64 - Missing PreReq: chkconfig t1lib-5.1.0-6.fc5.x86_64 - Missing PreReq: coreutils, findutils thttpd-2.25b-10.fc5.x86_64 - Missing PreReq: chkconfig torque-localhost-2.1.0p0-0.7.200604171430cvs.fc5.x86_64 - /var/torque/server_priv/serverdb already exists during preinstall, probably created by some of the other scripts of the required torque packages. vnstat-1.4-5.x86_64 - Missing PreReq: shadow-utils xpilot-ng-server-4.7.2-6.fc5.x86_64 - Missing PreReq: chkconfig Would be great if the specific owners of those packages could include the fixes in their newer versions. Thanks, Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From tibbs at math.uh.edu Mon May 15 17:32:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 15 May 2006 12:32:59 -0500 Subject: Post/Pre install/uninstall script failures in fc5-extras packages on x86_64 In-Reply-To: <4468B9D5.1070603@redhat.com> (Phil Knirsch's message of "Mon, 15 May 2006 19:26:45 +0200") References: <4468B9D5.1070603@redhat.com> Message-ID: >>>>> "PK" == Phil Knirsch writes: PK> exim-4.61-2.fc5.x86_64 PK> Missing directories /usr/share/ssl/certs and PK> /usr/share/ssl/privates, need to be created prior to running PK> openssl req Shouldn't these be /etc/pki/tls/certs and /etc/pki/tls/private now? - J< From pknirsch at redhat.com Mon May 15 18:20:42 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Mon, 15 May 2006 20:20:42 +0200 Subject: Post/Pre install/uninstall script failures in fc5-extras packages on x86_64 In-Reply-To: References: <4468B9D5.1070603@redhat.com> Message-ID: <4468C67A.9030903@redhat.com> Jason L Tibbitts III wrote: >>>>>> "PK" == Phil Knirsch writes: > > PK> exim-4.61-2.fc5.x86_64 > PK> Missing directories /usr/share/ssl/certs and > PK> /usr/share/ssl/privates, need to be created prior to running > PK> openssl req > > Shouldn't these be /etc/pki/tls/certs and /etc/pki/tls/private now? > > - J< Should, yeah, but check the snippet from the postinstall script: if [ ! -f /usr/share/ssl/certs/exim.pem ] ; then umask 077 FQDN=`hostname` if [ "x${FQDN}" = "x" ]; then FQDN=localhost.localdomain fi cat << EOF | openssl req -new -x509 -days 365 -nodes -out /usr/share/ssl/certs/exim.pem -keyout /usr/share/ssl/private/exim.pem &>/dev/null So it actively tries to create them in /usr/share/ssl/... Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From nicolas.mailhot at laposte.net Mon May 15 18:31:59 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 May 2006 20:31:59 +0200 Subject: Post/Pre install/uninstall script failures in fc5-extras packages on x86_64 In-Reply-To: <4468B9D5.1070603@redhat.com> References: <4468B9D5.1070603@redhat.com> Message-ID: <1147717922.18763.13.camel@rousalka.dyndns.org> Le lundi 15 mai 2006 ? 19:26 +0200, Phil Knirsch a ?crit : > fonts-hebrew-fancy-0.101-2.fc5.noarch > - Missing PreReq: fontconfig If this package does not properly handle the missing fontconfig case then it needs to be fixed Resources should not require libraries which may use them -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From laroche at redhat.com Mon May 15 21:29:36 2006 From: laroche at redhat.com (Florian La Roche) Date: Mon, 15 May 2006 23:29:36 +0200 Subject: Fedora Core package cleanup project In-Reply-To: <20060514135050.GA8419@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <20060514135050.GA8419@lists.us.dell.com> Message-ID: <20060515212936.GA7244@dudweiler.stuttgart.redhat.com> On Sun, May 14, 2006 at 08:50:50AM -0500, Matt Domsch wrote: > On Sun, May 14, 2006 at 02:40:29PM +1200, Michael J Knox wrote: > > Quick question.. > > > > Is it OK to do this with FC5 as the build host? I mirror locally FC5 + > > updates and would save me a ton of bandwidth (which still costs heaps in > > NZ). > > FWIW, I've taken 3 systems the past 12 hours, and have nearly finished > rebuilding rawhide on x86_64. You can find the results here: > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > > Some have had rpmlint run on them, many haven't (2 of my build systems > did't have it installed; d'oh). I'll run them all, and rpmdiff > against rawhide, when done. The above resyncs at the top of the hour > as packages finish. So folks can start looking without needing to > build each themselves. Hello Matt, another good test would be to check the dependencies (Provides:/Requires:) of the new rpm packages against the existing packages. Some packages might still compile, but have less complete content if we move to the smaller mock buildroots compared to the more complete buildroots we use right now. regards, Florian La Roche From Matt_Domsch at dell.com Mon May 15 22:35:45 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 15 May 2006 17:35:45 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <20060515212936.GA7244@dudweiler.stuttgart.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <20060514135050.GA8419@lists.us.dell.com> <20060515212936.GA7244@dudweiler.stuttgart.redhat.com> Message-ID: <20060515223545.GA1373@lists.us.dell.com> On Mon, May 15, 2006 at 11:29:36PM +0200, Florian La Roche wrote: > another good test would be to check the dependencies (Provides:/Requires:) > of the new rpm packages against the existing packages. Some packages > might still compile, but have less complete content if we move to the > smaller mock buildroots compared to the more complete buildroots we use > right now. rpmdiff does this: rpmdiff libacl-2.2.34-1.2.x86_64.rpm added REQUIRES libacl.so.1()(64bit) rpmdiff jpilot-0.99.8-5.x86_64.rpm removed REQUIRES libcrypto.so.6()(64bit) I'd be worried most about these that are removed... Here's a list by package name for things added or removed. http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/rpmdiff-added-or-removed.log It's 217K, so I won't attach it here, but it looks like the below list... -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com rpmdiff ElectricFence-2.2.2-20.2.x86_64.rpm added REQUIRES libefence.so.0()(64bit) rpmdiff ElectricFence-2.2.2-20.2.x86_64.rpm added REQUIRES libefence.so.0()(64bit) rpmdiff ElectricFence-2.2.2-20.2.x86_64.rpm added REQUIRES libefence.so.0()(64bit) rpmdiff GConf2-2.14.0-1.x86_64.rpm rpmdiff GConf2-devel-2.14.0-1.x86_64.rpm added REQUIRES libgconf-2.so.4()(64bit) rpmdiff GConf2-2.14.0-1.x86_64.rpm rpmdiff GConf2-devel-2.14.0-1.x86_64.rpm added REQUIRES libgconf-2.so.4()(64bit) rpmdiff GConf2-2.14.0-1.x86_64.rpm rpmdiff GConf2-devel-2.14.0-1.x86_64.rpm added REQUIRES libgconf-2.so.4()(64bit) From chris.stone at gmail.com Mon May 15 23:35:35 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 15 May 2006 16:35:35 -0700 Subject: licq + atitvout + gai-pal : Orphaned dependencies! In-Reply-To: <20060515180031.c95475dc.bugs.michael@gmx.net> References: <20060515124435.35771846.bugs.michael@gmx.net> <20060515180031.c95475dc.bugs.michael@gmx.net> Message-ID: On 5/15/06, Michael Schwendt wrote: > On Mon, 15 May 2006 12:44:35 +0200, Michael Schwendt wrote: > > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > > > The packages > > > > lrmi > > xosd > > > > are on the list of orphaned packages. They are required by: > > > > atitvout (lrmi) > > gai-pal (xosd) > > licq also needs xosd. Are you sure xosd is orphaned? it's also used by bmp-xosd, and an irssi plugin also uses xosd. I have xosd installed on my system, and it doesn't look orphaned to me. From kevin at tummy.com Mon May 15 23:51:53 2006 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 15 May 2006 17:51:53 -0600 (MDT) Subject: licq + atitvout + gai-pal : Orphaned dependencies! References: <20060515124435.35771846.bugs.michael@gmx.net> <20060515180031.c95475dc.bugs.michael@gmx.net> Message-ID: <20060515.175153.850290488.kevin@tummy.com> >>>>> "Christopher" == Christopher Stone writes: Christopher> On 5/15/06, Michael Schwendt Christopher> wrote: >> On Mon, 15 May 2006 12:44:35 +0200, Michael Schwendt wrote: >> >> > http://fedoraproject.org/wiki/Extras/OrphanedPackages >> > >> > The packages >> > >> > lrmi > xosd >> > >> > are on the list of orphaned packages. They are required by: >> > >> > atitvout (lrmi) > gai-pal (xosd) >> >> licq also needs xosd. Christopher> Are you sure xosd is orphaned? it's also used by Christopher> bmp-xosd, and an irssi plugin also uses xosd. I have Christopher> xosd installed on my system, and it doesn't look orphaned Christopher> to me. I just un-orphaned it this afternoon. bmp-xosd is a subpackage of xosd. Orphaning a package won't go out and remove it from everyone's system (thank goodness. ;) For anyone who doesn't know, you can do: 'yum list extras' and yum will tell you all packages you have installed that are not listed in any currently enabled repository. If anyone really would like to take over xosd or lrmi or tpb, drop me an email and I would be happy to have someone else take them over. Until then, I will maintain them. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Tue May 16 10:15:52 2006 From: laroche at redhat.com (Florian La Roche) Date: Tue, 16 May 2006 12:15:52 +0200 Subject: Fedora Core package cleanup project In-Reply-To: <20060515223545.GA1373@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4466989D.7030105@knox.net.nz> <20060514135050.GA8419@lists.us.dell.com> <20060515212936.GA7244@dudweiler.stuttgart.redhat.com> <20060515223545.GA1373@lists.us.dell.com> Message-ID: <20060516101551.GA5723@dudweiler.stuttgart.redhat.com> On Mon, May 15, 2006 at 05:35:45PM -0500, Matt Domsch wrote: > On Mon, May 15, 2006 at 11:29:36PM +0200, Florian La Roche wrote: > > another good test would be to check the dependencies (Provides:/Requires:) > > of the new rpm packages against the existing packages. Some packages > > might still compile, but have less complete content if we move to the > > smaller mock buildroots compared to the more complete buildroots we use > > right now. > > rpmdiff does this: > > rpmdiff libacl-2.2.34-1.2.x86_64.rpm > added REQUIRES libacl.so.1()(64bit) > > rpmdiff jpilot-0.99.8-5.x86_64.rpm > removed REQUIRES libcrypto.so.6()(64bit) > > I'd be worried most about these that are removed... > > Here's a list by package name for things added or removed. > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/rpmdiff-added-or-removed.log Ok, the data is all available in the above url and seems quite a few BuildRequires: are missing. (By the way: a similar check can be done to use a "everything" buildroot and check what additional libs get picked up by configure-scripts. Usually we only have very few packages showing any difference.) > > It's 217K, so I won't attach it here, but it looks like the below list... Good list to find missing BuildRequires: regards, Florian La Roche From dwmw2 at infradead.org Tue May 16 18:34:50 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 16 May 2006 19:34:50 +0100 Subject: Fedora Core package cleanup project In-Reply-To: <200605131642.k4DGgStw031568@mx1.redhat.com> References: <200605131642.k4DGgStw031568@mx1.redhat.com> Message-ID: <1147804490.3806.30.camel@pmac.infradead.org> On Sat, 2006-05-13 at 18:42 +0200, Christian.Iseli at licr.org wrote: > How 'bout a quick rpmlint on built packages ? > > One of the warning that'll probably often appear is the > non-standard-group thing. Is there any plan to either remove or expand the > group tag in spec files (and use comps.xml if it's removed) ? Legacy character sets in specfiles (like libxml2) also need fixing. I believe rpmlint should catch that -- ideally, RPM would refuse to build it too. -- dwmw2 From bugs.michael at gmx.net Tue May 16 20:44:01 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 16 May 2006 22:44:01 +0200 Subject: licq + atitvout + gai-pal : Orphaned dependencies! In-Reply-To: References: <20060515124435.35771846.bugs.michael@gmx.net> <20060515180031.c95475dc.bugs.michael@gmx.net> Message-ID: <20060516224401.e7ee24d8.bugs.michael@gmx.net> On Mon, 15 May 2006 16:35:35 -0700, Christopher Stone wrote: > > On Mon, 15 May 2006 12:44:35 +0200, Michael Schwendt wrote: > > > > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > > > > > The packages > > > > > > lrmi > > > xosd > > > > > > are on the list of orphaned packages. They are required by: > > > > > > atitvout (lrmi) > > > gai-pal (xosd) > > > > licq also needs xosd. > > Are you sure xosd is orphaned? Yes, of course: http://fedoraproject.org/wiki/Extras/OrphanedPackages?action=diff&rev2=255&rev1=254 > it's also used by bmp-xosd, and an > irssi plugin also uses xosd. I have xosd installed on my system, and > it doesn't look orphaned to me. The notion of an "orphan" is about whether the package has a package owner or not. The package itself may be up-to-date and in good shape. From michael at knox.net.nz Wed May 17 02:45:07 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 17 May 2006 14:45:07 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <1147804490.3806.30.camel@pmac.infradead.org> References: <200605131642.k4DGgStw031568@mx1.redhat.com> <1147804490.3806.30.camel@pmac.infradead.org> Message-ID: <446A8E33.5040202@knox.net.nz> Going over Matt Domsch's build logs and noticed that most (if not all) the xorg-x11-drv-* packages have failed to build Can they be lumped into one bug report or is the preference for 1 report 1 package? Michael From Matt_Domsch at dell.com Wed May 17 02:54:18 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 16 May 2006 21:54:18 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <20060515135220.GC8419@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> <20060515135220.GC8419@lists.us.dell.com> Message-ID: <20060517025418.GA20920@lists.us.dell.com> On Mon, May 15, 2006 at 08:52:20AM -0500, Matt Domsch wrote: > Here's the list of SRPMs that failed to generate binary RPMs on > x86_64 against rawhide (258 packages). The full package build > results, logs, rpmlints and rpmdiffs are posted here: > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Just a little re-arranging, sticking the overall log files at the top of the directory listing. Once a package is gone from rawhide, it'll be gone from the directory here too, so that should just keep around the current version of packages. I'm excluding tclx from the build list, as 'make test' never completes inside the chroot. So it fails to build, but also stalls the builder. :-( Once that's fixed I'll add it back in. The current state of affairs: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Packages that failed to build: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/00-failed-to-build.txt (presently 249 packages, progress made already!) Packages that add or remove files/provides/requires as compared to rawhide: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/00-rpmdiff-added-or-removed.txt Within each package, there are the build logs, rpmdiff.log, and rpmlint.log for easy review. This *should* run daily around 10am CDT (UCT-5), and results will land on the site as soon as the builds are all done (usually just a few hours). Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From michael at knox.net.nz Wed May 17 03:03:24 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 17 May 2006 15:03:24 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <20060517025418.GA20920@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> <20060515135220.GC8419@lists.us.dell.com> <20060517025418.GA20920@lists.us.dell.com> Message-ID: <446A927C.20209@knox.net.nz> Matt Domsch wrote: > On Mon, May 15, 2006 at 08:52:20AM -0500, Matt Domsch wrote: > >>Here's the list of SRPMs that failed to generate binary RPMs on >>x86_64 against rawhide (258 packages). The full package build >>results, logs, rpmlints and rpmdiffs are posted here: >> http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > > > Just a little re-arranging, sticking the overall log files at the top > of the directory listing. Once a package is gone from rawhide, it'll > be gone from the directory here too, so that should just keep around > the current version of packages. > > I'm excluding tclx from the build list, as 'make test' never completes > inside the chroot. So it fails to build, but also stalls the > builder. :-( Once that's fixed I'll add it back in. > > The current state of affairs: > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > > Packages that failed to build: > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/00-failed-to-build.txt > (presently 249 packages, progress made already!) > > Packages that add or remove files/provides/requires as compared to rawhide: > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/00-rpmdiff-added-or-removed.txt > > Within each package, there are the build logs, rpmdiff.log, and > rpmlint.log for easy review. > > This *should* run daily around 10am CDT (UCT-5), and results will land > on the site as soon as the builds are all done (usually just a few hours). > Nice work Matt.. I am wondering if a temp wiki page should be created to list the currently failed builds with BZ# so people can see from a quick look at which packages are good or bad. Michael From dwmw2 at infradead.org Wed May 17 20:42:26 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 17 May 2006 21:42:26 +0100 Subject: Do not BuildRequires: glibc-kernheaders In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <1147898546.8013.12.camel@shinybook.infradead.org> The glibc-kernheaders packages provides 'kernel-headers'. If you need to require a specific _version_, you should use that. But if you just need to require that it exists, you don't need to do anything -- the standard gcc development packages depend on it. If there's a file missing from /usr/include/linux or /usr/include/asm when you try to build, that's either a bug in the glibc-kernheaders package, or a bug in the package you're trying to build. If it's a kernel header you _should_ be using from userspace, assume the former and file a bug against glibc-kernheaders. If the latter, fix it not to include kernel headers. Do _NOT_ add 'BuildRequires: glibc-kernheaders' to any packages. That will break. Soon. -- dwmw2 From michael at knox.net.nz Thu May 18 01:26:02 2006 From: michael at knox.net.nz (Michael J Knox) Date: Thu, 18 May 2006 13:26:02 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <446A8E33.5040202@knox.net.nz> References: <200605131642.k4DGgStw031568@mx1.redhat.com> <1147804490.3806.30.camel@pmac.infradead.org> <446A8E33.5040202@knox.net.nz> Message-ID: <446BCD2A.1020902@knox.net.nz> Michael J. Knox wrote: > Going over Matt Domsch's build logs and noticed that most (if not all) > the xorg-x11-drv-* packages have failed to build > > Can they be lumped into one bug report or is the preference for 1 report > 1 package? > OK, I will just keep on making 1 for 1 bug reports then. Michael From Matt_Domsch at dell.com Thu May 18 13:28:50 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 18 May 2006 08:28:50 -0500 Subject: Fedora Core package cleanup project - packages with bugs filed (or not) In-Reply-To: <446A927C.20209@knox.net.nz> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> <20060515135220.GC8419@lists.us.dell.com> <20060517025418.GA20920@lists.us.dell.com> <446A927C.20209@knox.net.nz> Message-ID: <20060518132850.GA24137@lists.us.dell.com> On Wed, May 17, 2006 at 03:03:24PM +1200, Michael J. Knox wrote: > I am wondering if a temp wiki page should be created to list the > currently failed builds with BZ# so people can see from a quick look at > which packages are good or bad. Something like this? Here's a mapping of package name to filed bugzilla number(s) which are tied to the BR blocker. Because getting the list out of bugzilla is, for now, a manual process, I'll have to update this by hand. But I wrote a little program to take the bugzilla blocker list (in CSV format), compare against the list my build system produces for failed builds, and links them. Empty lists (shown with []) means no bug has been filed (yet). There's your chance for karma points! This file will start appearing in my build system results as 00-failed-to-build-bugnumbers.txt Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com agg [] amanda ['191796'] apmd [] arptables_jf ['191688'] arts [] at-spi [] avahi ['191663'] beagle ['191664'] bluez-pin ['191761'] bsf [] cairo-java [] classpathx-jaf [] cman-kernel [] compat-gcc-296 ['191696'] compat-gcc-32 [] component ['bug_id'] control-center [] desktop-printing [] device-mapper-multipath [] dictd [] diskdumputils ['191722'] dlm-kernel [] e2fsprogs [] eclipse [] eel2 ['191909'] ekiga ['191597'] elilo [] emacs [] eog ['191666'] epiphany ['191665'] evolution-connector [] foomatic [] freeglut [] frysk [] gail [] gcalctool ['191910'] gcc [] gdk-pixbuf [] gdm [] gecko-sharp2 [] GFS-kernel [] gimp-print [] gmime [] gnbd-kernel [] gnome-games [] gnome-media [] gnome-panel [] gnome-python2 [] gnome-python2-desktop [] gnome-python2-extras [] gnome-terminal [] gnome-utils ['191757'] gnucash [] gnu-efi [] gpart [] gphoto2 [] grub [] gtk-doc [] g-wrap [] hal-cups-utils [] hdparm [] HelixPlayer [] ImageMagick [] imlib ['191752'] initscripts [] iproute [] iprutils [] iptraf [] jakarta-commons-codec [] jakarta-commons-dbcp [] jakarta-commons-el [] jakarta-commons-pool [] jakarta-taglibs-standard [] java-1.4.2-gcj-compat [] jsch ['191668'] kdeartwork [] kdebase [] kdebindings [] kdegames [] kdelibs [] kdemultimedia [] kdenetwork [] kdepim [] kdesdk [] kdeutils [] kdevelop [] kdewebdev ['191983'] kon2 [] latex2html ['191762'] ldapjdk [] libbonoboui ['191728'] libbtctl [] libgconf-java [] libglade-java [] libgnomeprint22 ['191976'] libnl [] libnotify ['191731'] librtas [] libsemanage ['191733'] libunwind [] libvte-java [] libwnck ['191756'] longrun [] lvm2 ['191748'] magma-plugins [] mcstrans ['191726'] memtest86+ [] mesa [] metacity ['191960'] mozilla [] mtools [] mx4j [] nautilus ['191817'] nautilus-sendto ['191818'] net-tools ['191737'] nfs-utils ['191943'] nfs-utils-lib ['191749'] nmap [] notify-daemon ['191810'] opal ['191936'] openCryptoki [] openhpi ['191935'] openswan [] pam ['191915'] pango ['191958'] perl-XML-Simple ['191911'] planner [] ppc64-utils [] prctl [] psgml ['191902'] psmisc [] pydict ['191898'] python-pyblock ['191866'] pyxf86config ['191894'] qt [] reiserfs-utils ['191889'] rgmanager [] rhythmbox ['191760'] s390utils [] salinfo [] scim ['191886'] setserial [] sound-juicer ['182174'] squashfs-tools [] stardict ['191878'] startup-notification ['191877'] struts [] subversion ['191611'] syslinux [] system-config-netboot [] tclx [] tetex [] thunderbird ['191881'] tomboy ['191833'] tomcat5 [] totem [] tux ['191828'] valgrind ['191820'] vino [] vixie-cron ['191823'] vte [] xchat ['191577'] xdoclet [] xen [] xjavadoc [] xorg-x11-apps ['191896'] xorg-x11-drv-acecad ['191900'] xorg-x11-drv-aiptek ['191903'] xorg-x11-drv-apm [] xorg-x11-drv-ark ['191905'] xorg-x11-drv-calcomp ['191904'] xorg-x11-drv-chips [] xorg-x11-drv-cirrus [] xorg-x11-drv-citron [] xorg-x11-drv-cyrix [] xorg-x11-drv-digitaledge [] xorg-x11-drv-dmc [] xorg-x11-drv-dummy [] xorg-x11-drv-dynapro [] xorg-x11-drv-elo2300 [] xorg-x11-drv-elographics [] xorg-x11-drv-evdev [] xorg-x11-drv-fbdev [] xorg-x11-drv-fpit [] xorg-x11-drv-glint [] xorg-x11-drv-hyperpen [] xorg-x11-drv-i128 [] xorg-x11-drv-i740 [] xorg-x11-drv-i810 [] xorg-x11-drv-jamstudio [] xorg-x11-drv-joystick [] xorg-x11-drv-keyboard [] xorg-x11-drv-magellan [] xorg-x11-drv-magictouch [] xorg-x11-drv-mga [] xorg-x11-drv-microtouch [] xorg-x11-drv-mouse [] xorg-x11-drv-mutouch [] xorg-x11-drv-neomagic [] xorg-x11-drv-nsc [] xorg-x11-drv-nv [] xorg-x11-drv-palmax [] xorg-x11-drv-penmount [] xorg-x11-drv-rendition [] xorg-x11-drv-s3 [] xorg-x11-drv-s3virge [] xorg-x11-drv-savage [] xorg-x11-drv-siliconmotion [] xorg-x11-drv-sis [] xorg-x11-drv-sisusb [] xorg-x11-drv-spaceorb [] xorg-x11-drv-summa [] xorg-x11-drv-tdfx [] xorg-x11-drv-tek4957 [] xorg-x11-drv-trident [] xorg-x11-drv-tseng [] xorg-x11-drv-ur98 [] xorg-x11-drv-v4l [] xorg-x11-drv-vesa [] xorg-x11-drv-vga [] xorg-x11-drv-via [] xorg-x11-drv-vmmouse [] xorg-x11-drv-vmware [] xorg-x11-drv-void [] xorg-x11-drv-voodoo [] xorg-x11-fonts [] xorg-x11-resutils [] xorg-x11-server ['192021'] xorg-x11-server-utils ['191987'] xorg-x11-utils ['191966'] xorg-x11-xdm ['191858'] xorg-x11-xfs ['191856'] xorg-x11-xfwp ['191813'] xorg-x11-xsm ['191802'] xscreensaver ['191769'] yaboot [] zsh ['191647'] From jkeating at redhat.com Thu May 18 13:42:19 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 09:42:19 -0400 Subject: Fedora Core package cleanup project - packages with bugs filed (or not) In-Reply-To: <20060518132850.GA24137@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> <20060515135220.GC8419@lists.us.dell.com> <20060517025418.GA20920@lists.us.dell.com> <446A927C.20209@knox.net.nz> <20060518132850.GA24137@lists.us.dell.com> Message-ID: <1147959739.14172.6.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-18 at 08:28 -0500, Matt Domsch wrote: > Something like this? Here's a mapping of package name to filed > bugzilla number(s) which are tied to the BR blocker. Because getting > the list out of bugzilla is, for now, a manual process, I'll have to > update this by hand. But I wrote a little program to take the > bugzilla blocker list (in CSV format), compare against the list my > build system produces for failed builds, and links them. Empty lists > (shown with []) means no bug has been filed (yet). There's your > chance for karma points! > > This file will start appearing in my build system results as > 00-failed-to-build-bugnumbers.txt > I went through the bug reports last night and make sure each one mentioned the package name in the summary. I also created a template that will help with this. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=191529 That gives you a good list of whats been filed already. It think a wiki page to reproduce this list is just extra work. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Thu May 18 21:40:44 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 19 May 2006 09:40:44 +1200 Subject: Fedora Core package cleanup project - packages with bugs filed (or not) In-Reply-To: <1147959739.14172.6.camel@dhcp83-49.boston.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> <20060515135220.GC8419@lists.us.dell.com> <20060517025418.GA20920@lists.us.dell.com> <446A927C.20209@knox.net.nz> <20060518132850.GA24137@lists.us.dell.com> <1147959739.14172.6.camel@dhcp83-49.boston.redhat.com> Message-ID: <446CE9DC.9060409@knox.net.nz> Jesse Keating wrote: > On Thu, 2006-05-18 at 08:28 -0500, Matt Domsch wrote: > >>Something like this? Here's a mapping of package name to filed >>bugzilla number(s) which are tied to the BR blocker. Because getting >>the list out of bugzilla is, for now, a manual process, I'll have to >>update this by hand. But I wrote a little program to take the >>bugzilla blocker list (in CSV format), compare against the list my >>build system produces for failed builds, and links them. Empty lists >>(shown with []) means no bug has been filed (yet). There's your >>chance for karma points! >> >>This file will start appearing in my build system results as >>00-failed-to-build-bugnumbers.txt >> > > > I went through the bug reports last night and make sure each one > mentioned the package name in the summary. I also created a template > that will help with this. > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=191529 > > That gives you a good list of whats been filed already. It think a wiki > page to reproduce this list is just extra work. > > Now that the app names are in the subject of the bug reports, it is a lot easier and probably don't need a wiki page now. Michael From Matt_Domsch at dell.com Thu May 18 22:36:32 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 18 May 2006 17:36:32 -0500 Subject: Fedora Core package cleanup project - packages with bugs filed (or not) In-Reply-To: <20060518132850.GA24137@lists.us.dell.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147615830.8004.2.camel@shuttle.piedmont.com> <200605141012.54769.jkeating@redhat.com> <200605141305.33087.jkeating@redhat.com> <20060515135220.GC8419@lists.us.dell.com> <20060517025418.GA20920@lists.us.dell.com> <446A927C.20209@knox.net.nz> <20060518132850.GA24137@lists.us.dell.com> Message-ID: <20060518223632.GA10716@lists.us.dell.com> New build done. Nice progress, down from 249 yesterday to 225 today. I'm going to start excluding the kernel from the builds, as it takes too long, and it's building fine. Yell if that's a problem. http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com agg [] amanda ['191796 NEW'] apmd [] arptables_jf ['191688 NEW'] arts [] at-spi [] beagle ['191664 NEW'] bluez-pin ['191761 NEW'] bsf [] cairo-java [] classpathx-jaf [] cman-kernel [] compat-gcc-296 ['191696 NEW'] compat-gcc-32 [] control-center ['192233 NEW'] desktop-printing ['192239 NEW'] device-mapper-multipath ['192242 NEW'] dictd [] diskdumputils ['191722 NEW'] dlm-kernel [] e2fsprogs ['192247 NEW'] eclipse [] eel2 ['191909 NEW'] ekiga ['191597 NEW'] elilo [] emacs [] eog ['191666 NEW'] epiphany ['191665 NEW'] evolution-connector ['192251 NEW'] foomatic [] freeglut ['192255 NEW'] frysk ['192256 NEW'] gail [] gaim [] gcalctool ['191910 NEW'] gcc [] gdk-pixbuf [] gdm [] gecko-sharp2 [] gedit [] GFS-kernel [] gimp-print [] gmime ['192116 CLOSED'] gnbd-kernel [] gnome-media [] gnome-panel [] gnome-python2 [] gnome-python2-desktop [] gnome-python2-extras [] gnome-terminal [] gnome-utils ['191757 NEW'] gnucash ['192008 CLOSED'] gnu-efi [] gpart [] gphoto2 [] grub [] gtk-doc [] hal-cups-utils [] hdparm [] HelixPlayer [] ImageMagick ['192036 NEW'] imlib ['191752 NEW'] initscripts [] iproute [] iprutils [] iptraf [] jakarta-commons-codec [] jakarta-commons-dbcp [] jakarta-commons-el [] jakarta-commons-pool [] jakarta-taglibs-standard [] java-1.4.2-gcj-compat [] jsch ['191668 NEW'] kdeartwork [] kdebase ['192037 NEW'] kdebindings [] kdegames [] kdelibs [] kdemultimedia [] kdenetwork [] kdepim [] kdesdk [] kdevelop [] kdewebdev ['191983 ASSIGNED'] kon2 [] latex2html ['191762 NEW'] ldapjdk [] libbonoboui ['191728 NEW'] libgconf-java [] libglade-java [] libgnomeprint22 ['191976 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] librtas [] libsemanage ['191733 MODIFIED'] libunwind [] libvte-java [] libwnck ['191756 NEW'] longrun [] lvm2 ['191748 NEW'] magma-plugins [] memtest86+ [] metacity ['191960 NEW'] mozilla ['191984 NEW'] mtools [] mx4j [] nautilus ['191817 NEW'] nautilus-sendto ['191818 NEW'] net-tools ['191737 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openCryptoki [] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] pango ['191958 NEW'] perl-XML-Simple ['191911 NEW'] ppc64-utils [] prctl [] psgml ['191902 NEW'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rgmanager [] rhythmbox ['191760 NEW'] s390utils [] salinfo [] scim ['191886 ASSIGNED'] setserial ['191884 CLOSED'] sound-juicer ['182174 NEW'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] startup-notification ['191877 NEW'] struts [] subversion ['191611 NEW'] syslinux [] system-config-netboot [] tclx [] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 NEW'] tomcat5 [] tux ['191828 NEW'] valgrind ['191820 NEW'] vino ['191827 NEW'] vixie-cron ['191823 NEW'] vte [] xchat ['191577 NEW'] xdoclet [] xen [] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm [] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips [] xorg-x11-drv-cirrus [] xorg-x11-drv-citron ['192292 NEW'] xorg-x11-drv-cyrix [] xorg-x11-drv-digitaledge ['192316 NEW'] xorg-x11-drv-dmc ['192312 NEW'] xorg-x11-drv-dummy ['192304 NEW'] xorg-x11-drv-dynapro ['192300 NEW'] xorg-x11-drv-elo2300 ['192320 NEW'] xorg-x11-drv-elographics ['192318 NEW'] xorg-x11-drv-evdev ['192317 NEW'] xorg-x11-drv-fbdev ['192325 NEW'] xorg-x11-drv-fpit ['192324 NEW'] xorg-x11-drv-glint [] xorg-x11-drv-hyperpen ['192326 NEW'] xorg-x11-drv-i128 [] xorg-x11-drv-i740 [] xorg-x11-drv-i810 [] xorg-x11-drv-jamstudio [] xorg-x11-drv-joystick [] xorg-x11-drv-keyboard [] xorg-x11-drv-magellan [] xorg-x11-drv-magictouch [] xorg-x11-drv-mga [] xorg-x11-drv-microtouch [] xorg-x11-drv-mutouch [] xorg-x11-drv-neomagic [] xorg-x11-drv-nsc [] xorg-x11-drv-nv [] xorg-x11-drv-palmax [] xorg-x11-drv-penmount [] xorg-x11-drv-rendition [] xorg-x11-drv-s3 [] xorg-x11-drv-s3virge [] xorg-x11-drv-savage [] xorg-x11-drv-siliconmotion [] xorg-x11-drv-sis [] xorg-x11-drv-sisusb [] xorg-x11-drv-spaceorb [] xorg-x11-drv-summa [] xorg-x11-drv-tdfx [] xorg-x11-drv-tek4957 [] xorg-x11-drv-trident [] xorg-x11-drv-tseng [] xorg-x11-drv-ur98 [] xorg-x11-drv-v4l [] xorg-x11-drv-vesa [] xorg-x11-drv-vga ['192168 NEW'] xorg-x11-drv-via ['192167 NEW'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 NEW'] xorg-x11-drv-void ['192045 NEW'] xorg-x11-drv-voodoo ['192042 NEW'] xorg-x11-fonts ['192038 NEW'] xorg-x11-resutils ['192040 NEW'] xorg-x11-server ['192021 NEW'] xorg-x11-server-utils ['191987 NEW'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yaboot [] zsh ['191647 NEW'] From bugs.michael at gmx.net Fri May 19 14:03:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 19 May 2006 16:03:47 +0200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! Message-ID: <20060519160347.d3210503.bugs.michael@gmx.net> http://fedoraproject.org/wiki/Extras/OrphanedPackages The packages gtkglarea2 ots perl-XML-XPath perl-XML-XQL are on the list of orphaned packages. They are required by (at least): abiword (ots) inkscape (perl-XML-XQL) lablgtk (gtkglarea2) perl-Template-Toolkit (perl-XML-XPath) If not picked up by anybody with a corresponding change to CVS owners.list, they may disappear in the near future and would break dependencies. From gemi at bluewin.ch Fri May 19 15:17:25 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 19 May 2006 17:17:25 +0200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! In-Reply-To: <20060519160347.d3210503.bugs.michael@gmx.net> References: <20060519160347.d3210503.bugs.michael@gmx.net> Message-ID: <1148051846.11725.0.camel@scriabin.tannenrauch.ch> On Fri, 2006-05-19 at 16:03 +0200, Michael Schwendt wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > The packages > > gtkglarea2 I thought Ralf Corsepius would take this up. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From rc040203 at freenet.de Fri May 19 15:26:11 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 May 2006 17:26:11 +0200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! In-Reply-To: <1148051846.11725.0.camel@scriabin.tannenrauch.ch> References: <20060519160347.d3210503.bugs.michael@gmx.net> <1148051846.11725.0.camel@scriabin.tannenrauch.ch> Message-ID: <1148052371.882.36.camel@mccallum.corsepiu.local> On Fri, 2006-05-19 at 17:17 +0200, G?rard Milmeister wrote: > On Fri, 2006-05-19 at 16:03 +0200, Michael Schwendt wrote: > > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > > > The packages > > > > gtkglarea2 > > I thought Ralf Corsepius would take this up. As I've repeatedly stated, I am willing to co-maintain and to team up with others. Therefore, I had added myself to the CC-list in owners.list on 2006/03/04 - IIRC, this step had been proposed by Michael. Ralf From michael at knox.net.nz Fri May 19 21:31:11 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 20 May 2006 09:31:11 +1200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! In-Reply-To: <20060519160347.d3210503.bugs.michael@gmx.net> References: <20060519160347.d3210503.bugs.michael@gmx.net> Message-ID: <446E391F.6080207@knox.net.nz> Michael Schwendt wrote: > http://fedoraproject.org/wiki/Extras/OrphanedPackages > > The packages > > gtkglarea2 > ots > perl-XML-XPath > perl-XML-XQL > > are on the list of orphaned packages. They are required by (at least): > > abiword (ots) > inkscape (perl-XML-XQL) > lablgtk (gtkglarea2) > perl-Template-Toolkit (perl-XML-XPath) > > > If not picked up by anybody with a corresponding change to CVS owners.list, > they may disappear in the near future and would break dependencies. Well, I use abiword, so I will grab ots. Michael From uwog at uwog.net Sat May 20 21:32:31 2006 From: uwog at uwog.net (J.M. Maurer) Date: Sat, 20 May 2006 23:32:31 +0200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! In-Reply-To: <446E391F.6080207@knox.net.nz> References: <20060519160347.d3210503.bugs.michael@gmx.net> <446E391F.6080207@knox.net.nz> Message-ID: <1148160751.3085.0.camel@sigma.lan.uwog.net> > > abiword (ots) > > inkscape (perl-XML-XQL) > > lablgtk (gtkglarea2) > > perl-Template-Toolkit (perl-XML-XPath) > > > > > > If not picked up by anybody with a corresponding change to CVS > owners.list, > > they may disappear in the near future and would break dependencies. > > Well, I use abiword, so I will grab ots. Thanks. The ots project looks dead, but the new maintainer is planning to make a new release 'soonish', whenever that may be :) Cheers, Marc From michael at knox.net.nz Sat May 20 21:34:20 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 21 May 2006 09:34:20 +1200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! In-Reply-To: <1148160751.3085.0.camel@sigma.lan.uwog.net> References: <20060519160347.d3210503.bugs.michael@gmx.net> <446E391F.6080207@knox.net.nz> <1148160751.3085.0.camel@sigma.lan.uwog.net> Message-ID: <446F8B5C.9050909@knox.net.nz> J.M. Maurer wrote: >>> abiword (ots) >>> inkscape (perl-XML-XQL) >>> lablgtk (gtkglarea2) >>> perl-Template-Toolkit (perl-XML-XPath) >>> >>> >>> If not picked up by anybody with a corresponding change to CVS >> owners.list, >>> they may disappear in the near future and would break dependencies. >> Well, I use abiword, so I will grab ots. > > Thanks. The ots project looks dead, but the new maintainer is planning > to make a new release 'soonish', whenever that may be :) > Will the new maintianer be using the libots.sf.net site? Michael From uwog at uwog.net Sat May 20 21:56:59 2006 From: uwog at uwog.net (J.M. Maurer) Date: Sat, 20 May 2006 23:56:59 +0200 Subject: abiword, inkscape, lablgtk, perl-Template-Toolkit : Orphaned dependencies! In-Reply-To: <446F8B5C.9050909@knox.net.nz> References: <20060519160347.d3210503.bugs.michael@gmx.net> <446E391F.6080207@knox.net.nz> <1148160751.3085.0.camel@sigma.lan.uwog.net> <446F8B5C.9050909@knox.net.nz> Message-ID: <1148162219.3085.3.camel@sigma.lan.uwog.net> > > Thanks. The ots project looks dead, but the new maintainer is > planning > > to make a new release 'soonish', whenever that may be :) > > > > Will the new maintianer be using the libots.sf.net site? Yes, he will. Cheers, Marc From rc040203 at freenet.de Mon May 22 10:10:52 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 22 May 2006 12:10:52 +0200 Subject: bugzilla overload Message-ID: <1148292652.882.158.camel@mccallum.corsepiu.local> Hi, Pardon, if this is the wrong list, but ... Since a couple of days, bugzilla.redhat.com seems to become increasingly inaccessible: Since this morning (I.e. for the last ca 6 hours), I am permanently welcomed with this message: *** The server is currently experiencing a higher than normal load. Please check back shortly. *** Any remedy in sight? Ralf From jspaleta at gmail.com Mon May 22 13:51:28 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 22 May 2006 09:51:28 -0400 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both Message-ID: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> Good Morning, Anyone interested in taking over maintainership of glabels and istanbul? In just under a month I will be moving to Alaska and I will be without residential broadband for the foreseeable future. Whats worse is the new place of employment which does have band is currently an all windows shop (something I'll fix in a finite amount of time), making a tad more difficult to sneak in a few minutes of fedora related moonlighting, until I'm there long to resuscitate some decommissioned desktops into Linux machines. So both of these packages will be effectively orphaned unless someone else becomes the primary maintainer. glabels in fedora extras is currently tracking the stable glabels branch, and its pretty straight forward. Just get on the low traffic upstream glabels mailinglist and watch for any "stable" release announcements or upstream bugs. Istanbul will require more work at some point. Fedora's Istanbul is still using gstreamer08, and the version of Instanbul in cvs is ported to gstreamer-0.10. BUT the X display grabbing gstreamer module that cvs Istanbul relies on isn't in gstreamer-bad, which fedora isn't going to ship. Moving fedora-extras-development to the gst 0.10 based Istanbul, will have to wait for the module to move over to gstreamer-good and for that new release of gstreamer-good to be dropped into Core. You'll have to watch the gstreamer plugins release announcements and watch the changes in istanbul cvs to see when the pieces fall into place. This burned me leading up to fc5, I didn't realize that the required gst plugin was placed in the gstreamer-bad pile. There is also the chance to build the current gst08 based istanbul for FC4. Last time I checked the needed FC4 gsteamer-plugins package was in FC4 updates-testing. IF that has moved over to updates-released istanbul can be built for FE4. Istanbul is a very thin layer of python gui over gstreamer's inherent pipelining functionality. The real magic (or lack there of) is at the gstreamer plugin level. Any takers? -jef"I hope its not cold in Alaska"spaleta From thomas at apestaart.org Mon May 22 14:31:46 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 22 May 2006 16:31:46 +0200 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> Message-ID: <1148308306.2626.157.camel@otto.amantes> Hi, > Istanbul will require more work at some point. Fedora's Istanbul is > still using gstreamer08, and the version of Instanbul in cvs is ported > to gstreamer-0.10. BUT the X display grabbing gstreamer module that > cvs Istanbul relies on isn't in gstreamer-bad, which fedora isn't > going to ship. It was moved to -good in the 0.10.3 release of -good two weeks ago. Of course it would still need an update of the core package. Thomas From jspaleta at gmail.com Mon May 22 14:45:49 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 22 May 2006 10:45:49 -0400 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <1148308306.2626.157.camel@otto.amantes> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> <1148308306.2626.157.camel@otto.amantes> Message-ID: <604aa7910605220745s707f5247hd4912f58cc34da23@mail.gmail.com> On 5/22/06, Thomas Vander Stichele wrote: > It was moved to -good in the 0.10.3 release of -good two weeks ago. > Of course it would still need an update of the core package. good to know, but sadly a little too late for me to deal with. -jef From katzj at redhat.com Mon May 22 14:58:08 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 10:58:08 -0400 Subject: bugzilla overload In-Reply-To: <1148292652.882.158.camel@mccallum.corsepiu.local> References: <1148292652.882.158.camel@mccallum.corsepiu.local> Message-ID: <1148309888.1881.36.camel@orodruin.boston.redhat.com> On Mon, 2006-05-22 at 12:10 +0200, Ralf Corsepius wrote: > Pardon, if this is the wrong list, but ... > > Since a couple of days, bugzilla.redhat.com seems to become increasingly > inaccessible: [snip] > Any remedy in sight? There are a few things at work here, but hopefully things should improve later today Jeremy From rc040203 at freenet.de Mon May 22 15:41:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 22 May 2006 17:41:47 +0200 Subject: [Bug 190664] Review Request: keyutils - Kernel key management userspace utilities In-Reply-To: <200605221432.k4MEWLr3007839@www.beta.redhat.com> References: <200605221432.k4MEWLr3007839@www.beta.redhat.com> Message-ID: <1148312507.882.184.camel@mccallum.corsepiu.local> Due to continued unreachability of bugzilla, replying to the lists. On Mon, 2006-05-22 at 10:32 -0400, bugzilla at redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: Review Request: keyutils - Kernel key management userspace utilities > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190664 > > > > > > ------- Additional Comments From dhowells at redhat.com 2006-05-22 10:32 EST ------- > Is that sufficient, Ralf? I'd have to check your current src.rpm, but bugzilla currently is inaccessible, and I've lost the original URL, because I deleted the original mail ;) Ralf From peter at thecodergeek.com Mon May 22 16:09:21 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 22 May 2006 09:09:21 -0700 Subject: Pre-orphaning annoucement for glabels and istanbul, looking for a new maintainer for both In-Reply-To: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> References: <604aa7910605220651w7758882fx8493ba7618c1cf33@mail.gmail.com> Message-ID: <4471E231.1070409@thecodergeek.com> Jeff Spaleta wrote: > glabels in fedora extras is currently tracking the stable glabels > branch, and its pretty straight forward. Just get on the low traffic > upstream glabels mailinglist and watch for any "stable" release > announcements or upstream bugs. I've been using gLabels a lot as of recent. If no one has any outstanding complaints thereof, I'd be happy to take it off your hands for a while. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Mon May 22 18:44:37 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 14:44:37 -0400 Subject: Improving the way we select multilib packages for trees In-Reply-To: <1146521943.11225.87.camel@orodruin.boston.redhat.com> References: <1146248628.9570.39.camel@aglarond.local> <1146521943.11225.87.camel@orodruin.boston.redhat.com> Message-ID: <1148323477.3180.6.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 18:19 -0400, Jeremy Katz wrote: > On Fri, 2006-04-28 at 14:23 -0400, Jeremy Katz wrote: > > What does this mean to you as a package maintainer? In a lot of cases, > > hopefully nothing. But there are cases where header files included in > > packages are generated at build-time and have an architecture or build > > specific nature. These conflicts will need to be fixed similar to how > > things have been fixed for runtime library issues -- either moving files > > around or removing the cause for the difference. If there is a valid > > reason for them to be different, then you might want to explore having a > > common stub header that includes the different headers as appropriate > > (eg, how /usr/include/gnu/stubs.h is handled) [snip] > I'll work on making the full output with the exact conflicts in each > package available later tonight but wanted to get info out about which > packages were problematic. Also, I plan to start filing bugs on > packages which haven't been fixed on May 16th. I've now gone and filed a ton of bugs about this and made them all block https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192658 Note that these need to be fixed in advance of the FC6 test1 freeze (which is currently scheduled for June 7th). Jeremy From mharris at mharris.ca Tue May 23 15:30:09 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 23 May 2006 11:30:09 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <446A8E33.5040202@knox.net.nz> References: <200605131642.k4DGgStw031568@mx1.redhat.com> <1147804490.3806.30.camel@pmac.infradead.org> <446A8E33.5040202@knox.net.nz> Message-ID: <44732A81.2000208@mharris.ca> Michael J. Knox wrote: > Going over Matt Domsch's build logs and noticed that most (if not all) > the xorg-x11-drv-* packages have failed to build > > Can they be lumped into one bug report or is the preference for 1 report > 1 package? Thankfully, they've ended up in one bug per package. That makes it easy to close each one individually as each driver package gets updated. I had hoped to get this all done by today, but didn't realize the volume of bugs that would be coming into bugzilla. I was hit with about 120 bugs in the last few days. I believe I will be able to allocate some time to resolving the buildrequires problems in the various X packages in rawhide this week, and hopefully also the multilib/manpage problems. I'd like to thank everyone who has worked on finding and reporting these issues! -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From michael at knox.net.nz Tue May 23 20:25:30 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 24 May 2006 08:25:30 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <44732A81.2000208@mharris.ca> References: <200605131642.k4DGgStw031568@mx1.redhat.com> <1147804490.3806.30.camel@pmac.infradead.org> <446A8E33.5040202@knox.net.nz> <44732A81.2000208@mharris.ca> Message-ID: <44736FBA.5040305@knox.net.nz> Mike A. Harris wrote: > Michael J. Knox wrote: > >> Going over Matt Domsch's build logs and noticed that most (if not all) >> the xorg-x11-drv-* packages have failed to build >> >> Can they be lumped into one bug report or is the preference for 1 >> report 1 package? > > > Thankfully, they've ended up in one bug per package. That makes it > easy to close each one individually as each driver package gets > updated. Yes, I ended up doing one report per package. > I had hoped to get this all done by today, but didn't realize the > volume of bugs that would be coming into bugzilla. I was hit with > about 120 bugs in the last few days. Ouch! I noticed that there have been patches attached to most of the xorg-x11-drv reports. > I believe I will be able to allocate some time to resolving the > buildrequires problems in the various X packages in rawhide this > week, and hopefully also the multilib/manpage problems. > > I'd like to thank everyone who has worked on finding and reporting > these issues! Anything that can be done to make FC a even better palce :) Michael From mharris at mharris.ca Thu May 25 13:24:18 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 25 May 2006 09:24:18 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <44736FBA.5040305@knox.net.nz> References: <200605131642.k4DGgStw031568@mx1.redhat.com> <1147804490.3806.30.camel@pmac.infradead.org> <446A8E33.5040202@knox.net.nz> <44732A81.2000208@mharris.ca> <44736FBA.5040305@knox.net.nz> Message-ID: <4475B002.7070908@mharris.ca> Michael J. Knox wrote: >> I had hoped to get this all done by today, but didn't realize the >> volume of bugs that would be coming into bugzilla. I was hit with >> about 120 bugs in the last few days. > > Ouch! I noticed that there have been patches attached to most of the > xorg-x11-drv reports. Yep, and that helps, but I still need to review each one to ensure all of the changes are accurate, and adjust if necessary. For example, there is a bug requesting that xorg-x11-fonts have "BuildRequires: fontconfig" added to it, as it calls fc-cache aparently during font building. The proper fix for that though, is to patch the Makefiles, etc. to _not_ call fc-cache, as we do not ship any build time created fonts.cache files in any font packages - we generate them at install time in the rpm scripts, and not for all fonts. I prefer to confirm all suggested changes, to catch things like that, rather than blindly applying all patches. ;) >> I believe I will be able to allocate some time to resolving the >> buildrequires problems in the various X packages in rawhide this >> week, and hopefully also the multilib/manpage problems. >> >> I'd like to thank everyone who has worked on finding and reporting >> these issues! > > Anything that can be done to make FC a even better palce :) A better palace? Oooh.. I can't wait to see it! ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From katzj at redhat.com Fri May 26 16:21:32 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 26 May 2006 12:21:32 -0400 Subject: FC6 test1 schedule slip Message-ID: <1148660492.2558.18.camel@aglarond.local> As might be somewhat clear from the request to clean up buildrequires, we're trying to switch the building of Core to be using mock for Fedora Core 6. Given this, we really want to make the switch prior to test1 to avoid later problems. So, to make this possible, we're going to slip test1 by a week to give time for shaking out problems from switching to the new build system. This makes the new freeze date for test1 June 14th and the rest of the schedule ripples accordingly. Jeremy From jkeating at redhat.com Mon May 29 12:57:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 May 2006 08:57:39 -0400 Subject: libxml1 going away Message-ID: <1148907459.7067.31.camel@ender> libxml1 has reached its end of days. Gtk-Perl R-gnomeGUI Both have listed deps on libxml1. Can these be moved to libxml2? We're really really really rather not bring libxml1 into Extras. I would like to have libxml1 removed from the distribution by Test 1. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jpo at lsd.di.uminho.pt Mon May 29 16:30:57 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 29 May 2006 17:30:57 +0100 Subject: FYI: the texinfo package has been splitted in two Message-ID: <447B21C1.3090707@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Fedora Core 6 texinfo package has been splitted in two texinfo + texinfo-tex In particular, the files /usr/bin/texi2dvi /usr/bin/texi2pdf /usr/bin/texindex have been moved into texinfo-tex. jpo PS1 - The package texinfo-tex requires texinfo. PS2 - I have just changed a package build requirement from BuildRequires: texinfo into BuildRequires: /usr/bin/texi2dvi - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEeyHBl0metZG9hRsRAk8gAJ9Rp4Bsrmdkt7yhcsk/we/Cotxt5ACghiM6 zts00BEqYNZLeP8hA87+UxI= =N+C7 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Mon May 29 20:19:18 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 May 2006 16:19:18 -0400 Subject: libxml1 going away In-Reply-To: <1148907459.7067.31.camel@ender> References: <1148907459.7067.31.camel@ender> Message-ID: <20060529201918.GA7477@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > libxml1 has reached its end of days. > > Gtk-Perl > R-gnomeGUI > > Both have listed deps on libxml1. Can these be moved to libxml2? We're > really really really rather not bring libxml1 into Extras. I would like > to have libxml1 removed from the distribution by Test 1. The way to fix this is to port those to GTK+2/GNOME 2, not just from libxml1 to libxml2. Bill From andreas.bierfert at lowlatency.de Tue May 30 08:18:38 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Tue, 30 May 2006 10:18:38 +0200 Subject: libpqxx upgrade Message-ID: <20060530101838.1d4d98d0@alkaid.a.lan> Hi, I am pushing a libpqxx upgrade on fc{4,5} and devel today which will change the lib version from 2.5.5 to 2.6.6. This probably will only affect koffice which I will push as soon es libpqxx has finished building but in case anything other depends on this... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: