Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On 09/03/2009 09:10 PM, Tom spot Callaway wrote: On 09/03/2009 02:20 PM, Hans de Goede wrote: Regeneration is as easy with dracut as it is with mkinitrd, actually they have the same cmdline syntax. The only extra step required with dracut when using pre-generated images is: yum install dracut Okay, so is there any reason why we don't have some sort of scriplet that regenerates the initrd when any of the system binaries used in the initrd are updated? Because people really dislike non booting systems. Automatically regenerating a very crucial part of the boot sequence is a very bad idea, as it will break occasionally. There is a reason why we keep a backup kernel at hand at all times and that reason is not only that sometimes a new kernel fails to work on certain systems, but also that sometimes a new initrd fails (for example due to changes in things it depends on). Also for there to be a security issue, there needs to be an attack vector, and during early userspace, there is very little attack vector, no other programs are running, no network interfaces are up, etc. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
clang static analyzer: use it!
Quick summary: use this tool:
http://clang-analyzer.llvm.org/
If you're not using its scan-build tool, then start. Right now.
Really. It's that good.
Recently I've run it on a variety of packages, from coreutils
(of course) to libvirt -- and libxml2 on request by the maintainer.
To use them, build the tools described here, from source:
(currently, there is no fedora package, afaik)
http://clang-analyzer.llvm.org/
I ran them like this for libxml2:
scan-build -o clang ./autogen.sh
scan-build -o clang make
The -o clang says to put the summary in a directory named clang.
The file you'll want is named e.g., clang/2009-09-04-1/index.html
The resulting HTML:
http://meyering.net/code/tmp/clang/libxml2-vs-clang-syntax-checker/index.html
is essentially the clang/ directory specified by the commands above.
Note that some of the things it reports are definitely false positives,
but if it's confused enough by your code to think that some part could
dereference NULL, then a human reviewer might make the same mistake.
In some cases it's a good indication you can make the code cleaner.
The second bug I looked at was a doosey:
http://meyering.net/code/tmp/clang/libxml2-vs-clang-syntax-checker/report-5Qxdd7.html#Path1
doc = cur-doc; { // curly on wrong line
if (doc != NULL) // no curly brace
oldenc = doc-encoding; // one-line then clause
if (ctxt-encoding != NULL) { // not part of if block
doc-encoding = BAD_CAST ctxt-encoding;
} else if (doc-encoding != NULL) {
encoding = doc-encoding;
}
}
Also note the section on dead store bugs.
At first glance, you might think you can blindly
remove the offending statement or expression.
Don't do that. At least not blindly.
For example, one dead store bug in libvirt exposed
an interface bug that made it so a function would always
return zero, rather than -1 upon failure.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: static linking and LGPL libraries
On 09/03/2009 09:22 PM, Tom spot Callaway wrote: On 09/03/2009 02:25 PM, Hans de Goede wrote: Note that we have the same problem with any package which does static linking against an lgpl library (such as glibc). This is (one of the big reasons) why we only permit static linking with explicit approval from FESCo. Still we do allow it for certain packages and every such package has the potential LGPL problem Notting described. I personally think it would be a good idea to include root.log inside the srpm of packages, this way people can truely use their GPL rights and exactly re-create the package by using all the same packages in a chroot as used during the original build. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sed -i symlink behavior...
On Thu, Sep 3, 2009 at 9:47 PM, Peter Bloomfield peterbloomfi...@bellsouth.net wrote: On 09/02/2009 10:07 AM, Warren Togami wrote: On 09/02/2009 11:39 AM, Jerry James wrote: On Wed, Sep 2, 2009 at 9:35 AM, Warren Togamiwtogami redhat com wrote: What is the correct behavior? Is this a bug that it changed? Read up on the --follow-symlinks option to sed. This is a new option it seems, meaning I can't rely on sed -i at all anymore. I'm rather displeased that a core utility fundamentally changed its own behavior. Warren Apparently [1] upstream sed always broke symlinks, and Red Hat made a patch to follow them instead. Fedora packages from some point up to sed-4.1.5-12.fc11 seem to have used it. So the default behavior in Fedora sed is now consistent with upstream, instead of with the prior patched version. That's inconvenient if you're accustomed to the Red Hat version, but better for interoperability! Peter [1] http://www.nabble.com/Re:-sed:-Patch-to-follow-symlinks-and--c-option-td7471749.html In fact the comment in this link is I want sed -i and perl -i to behave as similarly as possible. Hence, the patch is rejected as is. --copy is rejected for the same reason. . as i have already commented out previously. Regards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Review needed....
Perhaps it is luck, but I'm happy about that fact that not all contributors with an open review request begging on devel list for a reviewer. If anybody will do it, the devel list will explode with review beggars. It's strange to see that most of the baggers are working for a big north american distributor, or living in india, or both! No, I don't want a pony!!! Is it difficult to be patient? There are many more open reviews which are older... Please qry your friends (if you have some) or be patient.. -- Josephine Fine Tannhäuser -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On Wed, Sep 2, 2009 at 11:52 PM, Philip Prindeville
philipp_s...@redfish-solutions.com wrote:
Seems to be an rpm versioning issue:
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --rebuild
perl-Net-Patricia-1.15_01-1.fc9.src.rpm
INFO: mock.py version 0.9.14 starting...
State Changed: init plugins
State Changed: start
INFO: Start(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64)
State Changed: lock buildroot
State Changed: clean
State Changed: init
State Changed: lock buildroot
Mock Version: 0.9.14
INFO: Mock Version: 0.9.14
INFO: enabled root cache
State Changed: unpacking root cache
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled ccache
State Changed: running yum
State Changed: setup
ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64) 0 minutes 15 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-10-x86_64/result
ERROR: Command failed:
# /usr/bin/yum --installroot /var/lib/mock/fedora-10-x86_64/root/
resolvedep ccache 'perl(ExtUtils::MakeMaker)'
rpmdb: Program version 4.3 doesn't match environment version
error: db4 error(-30974) from dbenv-open: DB_VERSION_MISMATCH: Database
environment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in
/var/lib/mock/fedora-10-x86_64/root/var/lib/rpm
Traceback (most recent call last):
File /usr/bin/yum, line 29, in module
yummain.user_main(sys.argv[1:], exit_code=True)
File /usr/share/yum-cli/yummain.py, line 229, in user_main
errcode = main(args)
File /usr/share/yum-cli/yummain.py, line 84, in main
base.getOptionsConfig(args)
File /usr/share/yum-cli/cli.py, line 184, in getOptionsConfig
enabled_plugins=self.optparser._splitArg(opts.enableplugins))
File /usr/lib/python2.5/site-packages/yum/__init__.py, line 192, in
_getConfig
self._conf = config.readMainConfig(startupconf)
File /usr/lib/python2.5/site-packages/yum/config.py, line 774, in
readMainConfig
yumvars['releasever'] = _getsysver(startupconf.installroot,
startupconf.distroverpkg)
File /usr/lib/python2.5/site-packages/yum/config.py, line 844, in
_getsysver
idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed
[r...@builder SRPMS]#
The host was originally an FC8 host, that was yum updated to FC9. I use
it to build FC9 and FC10 packages via Mock.
Unfortunately, it looks like it doesn't want to use the old RPM database
from the previous FC8 install.
I am pretty sure that it is because this rpm proposed patch was rejected
upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=464752.
https://bugzilla.redhat.com/show_bug.cgi?id=464752
The maintainer has already expressed his opinion on this topic also on this
mailing list and is unnecessary to discuss further.
It seems however that without this patch, or something similar, can lead to
the situation reported in the last comments.
How do I clobber all of this to that the database gets written afresh?
Apparently, mock -r fedora-10-x86_64 --clean isn't adequate. Perhaps
mock --nuke would be useful here following an version update to zap
stale state?
Or should I just uninstall and reinstall mock?
Thanks,
-Philip
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
On Thu, Sep 03, 2009 at 06:47:58PM +0100, José Matos wrote: On Thursday 27 August 2009 Jindrich Novy wrote: On Wed, Aug 26, 2009 at 03:02:18PM +0200, Jindrich Novy wrote: Hi, first off, thanks many people who sent me RFE and bugfix proposals. I've tried to fix most of them in the current package set in the testing repository: rpm -i http://jnovy.fedorapeople.org/texlive/texlive-release-2009-0.1.fc11.noarc h.rpm Forgot to mention that the initial rawhide repository is now available as: rpm -i http://jnovy.fedorapeople.org/texlive/texlive-rawhide-release-2009-0.1.fc11 .noarch.rpm The update when using the more recent rawhide failed. I suspect that the metadata is not updated as I get lots of Package does not match intended download. It should be fixed now altogether with new packages in the repository. Jindrich Jindrich -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090904 changes
Compose started at Fri Sep 4 06:15:08 UTC 2009 Broken deps for i386 -- anerley-0.0.20-3.fc12.i686 requires libmissioncontrol-client.so.0 anerley-devel-0.0.20-3.fc12.i686 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) cluttermm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 cluttermm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-0.9) collectd-mysql-4.5.3-2.fc11.i586 requires libcrypto.so.8 collectd-mysql-4.5.3-2.fc11.i586 requires libssl.so.8 collectd-nut-4.5.3-2.fc11.i586 requires libcrypto.so.8 collectd-nut-4.5.3-2.fc11.i586 requires libssl.so.8 collectd-snmp-4.5.3-2.fc11.i586 requires libcrypto.so.8 cpptasks-javadoc-1.0b5-2.fc12.noarch requires cpptasks-1.0b5-2.fc12 gpsdrive-2.10-0.1.pre7.fc12.i586 requires libmapnik.so.0.5 kdebase3-3.5.10-12.fc12.i686 requires libssl.so.8 network-manager-netbook-1.2-5.fc12.i686 requires libnm_glib.so.0 openvrml-0.18.3-1.fc12.i686 requires java(x86-32) openvrml-0.18.3-1.fc12.i686 requires gecko-libs(x86-32) = 0:1.9.1 ppl-yap-0.10.2-5.fc12.i686 requires libYap.so python-repoze-what-quickstart-1.0-2.fc12.noarch requires python-repoze-who-plugins-sql qtparted-0.4.5-19.fc11.i586 requires libparted-1.8.so.8 rygel-0.3-5.fc12.i686 requires libgee.so.0 rygel-tracker-0.3-5.fc12.i686 requires libgee.so.0 tabled-0.3-4.fc12.i686 requires libssl.so.8 tabled-0.3-4.fc12.i686 requires libcrypto.so.8 Broken deps for x86_64 -- anerley-0.0.20-3.fc12.i686 requires libmissioncontrol-client.so.0 anerley-0.0.20-3.fc12.x86_64 requires libmissioncontrol-client.so.0()(64bit) anerley-devel-0.0.20-3.fc12.i686 requires pkgconfig(libmissioncontrol) anerley-devel-0.0.20-3.fc12.x86_64 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-gtk-0.9) cluttermm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 cluttermm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) cluttermm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-0.9) cluttermm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-0.9) collectd-mysql-4.5.3-2.fc11.x86_64 requires libcrypto.so.8()(64bit) collectd-mysql-4.5.3-2.fc11.x86_64 requires libssl.so.8()(64bit) collectd-nut-4.5.3-2.fc11.x86_64 requires libcrypto.so.8()(64bit) collectd-nut-4.5.3-2.fc11.x86_64 requires libssl.so.8()(64bit) collectd-snmp-4.5.3-2.fc11.x86_64 requires libcrypto.so.8()(64bit) cpptasks-javadoc-1.0b5-2.fc12.noarch requires cpptasks-1.0b5-2.fc12 gpsdrive-2.10-0.1.pre7.fc12.x86_64 requires libmapnik.so.0.5()(64bit) kdebase3-3.5.10-12.fc12.x86_64 requires libssl.so.8()(64bit) network-manager-netbook-1.2-5.fc12.x86_64 requires libnm_glib.so.0()(64bit) openvrml-0.18.3-1.fc12.i686 requires java(x86-32) openvrml-0.18.3-1.fc12.i686 requires gecko-libs(x86-32) =
Re: Review needed....
First of all: Congrats for this Am Freitag, den 04.09.2009, 09:43 +0200 schrieb Josephine Tannhäuser: Perhaps it is luck, but I'm happy about that fact that not all contributors with an open review request begging on devel list for a reviewer. If anybody will do it, the devel list will explode with review beggars. It's strange to see that most of the baggers are working for a big north american distributor, or living in india, or both! No, I don't want a pony!!! Is it difficult to be patient? Spot asked for a review 4 days ago because he needed it to fix a broken dep [1]. Peter Robinson asked for a couple of reviews [2] because they were needed for his Moblin feature. Both Spot and Peter explained why their reviews were urgent. Adam Williamson asked for a review of libva [3], but he also offered to swap reviews. This is a normal procedure and has nothing to do with bagging. The reason why there are several RH employees asking for a review is because these people work full time on Fedora and actually drive the development forward. OK, this leaves Kushal, who asked for a review of pony [4] back in May. I wonder why you bring this up after months. I mean: You didn't do the review, so what are you worrying about? Kushal's request was also with a good portion of humor as the subject Who wants a pony? shows. If there is somebody to understand what catchy subjects are, I guess it's the person starting threads with subjects like KDE vs. Gnome or Review needed... (when there actually is not review needed). What was the name of that person? ;) Regards, Christoph [1] https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00031.html [2] https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00090.html [3] https://www.redhat.com/archives/fedora-devel-list/2009-August/msg01086.html [4] https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review needed....
Am Freitag, den 04.09.2009, 12:41 +0200 schrieb Christoph Wickert: First of all: Congrats for this ...catchy subject Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora mini alpha testing
On 26/08/09 00:00, Peter Robinson wrote: Arriving fashionably late, and mostly intact, to the Constantine Alpha party I'd like to announce that Moblin on Fedora has made it's initial debut for Fedora Mini :) Still a work in progress, Moblin is now in a mostly usable state on Fedora for testing. It has hence come well dressed for the alpha party in the Constantine theme in that its still very much in the testing stage :-) But if your still game. to give your netbook it's first real work out read on! If its running the Constantine alpha or rawhide, you can test it by simply do a 'yum groupinstall Moblin Desktop Environment'. Once that's done simply logout or reboot and you can prepare for take off by selecting Moblin User Experience during login. While the core interface in now there there's still a couple of packages that are will arrive over the next week so. Running 'yum groupinstall Moblin Desktop Environment' again will top you up :) I look forward to feedback and help in making it great for F-12, and all other Moblin and Fedora Mini feedback. I'd also like some help in documenting supported netbook hardware combinations for F-12 so please send me smolt profiles, hardware reports or add and update details to the wiki page here (1). I look forward to a great start to Fedora Mini! Peter [1] https://fedoraproject.org/wiki/SIGs/FedoraMini/Hardware hi peter i'm trying to install on an up to date rawhide and the install is failing because certain apps have depsolving problems, network-manager-netbook, anerly and anjal are needing these libraries libnm_glib.so.0 libmissioncontrol-client.so.0 is this a known problem? phil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Friday 04 September 2009 02:30:14 am Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. llvm is in Fedora. Looking at the build instructions for clang, it seems like it would naturally fit as a subpackage for llvm. So, getting it into Fedora should not be too much to do since llvm is already approved. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fit and Finish test day coming up
We will look at sharing of files, music and desktops in the next Fit and Finish test day, which is coming up very soon, 2009-09-08, which is the coming Tuesday. Read all about it at http://fedoraproject.org/wiki/Test_Day:2009-09-08_Fit_and_Finish:Sharing Join us on Tuesday in #fedora-fit-and-finish on Freenode.e Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: static linking and LGPL libraries
On 09/04/2009 03:10 AM, Hans de Goede wrote: On 09/03/2009 09:22 PM, Tom spot Callaway wrote: On 09/03/2009 02:25 PM, Hans de Goede wrote: Note that we have the same problem with any package which does static linking against an lgpl library (such as glibc). This is (one of the big reasons) why we only permit static linking with explicit approval from FESCo. Still we do allow it for certain packages and every such package has the potential LGPL problem Notting described. I personally think it would be a good idea to include root.log inside the srpm of packages, this way people can truely use their GPL rights and exactly re-create the package by using all the same packages in a chroot as used during the original build. We don't keep every Koji build indefinitely. We need to garbage-collect older builds or our storage requirements would grow without bound. Rebuilding a package using *exactly* the same NVRs present in the buildroot is not practical, and after a few weeks, generally not possible. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On 09/04/2009 03:06 AM, Hans de Goede wrote: Also for there to be a security issue, there needs to be an attack vector, and during early userspace, there is very little attack vector, no other programs are running, no network interfaces are up, etc. I suppose this would be somewhat difficult to exploit, except possibly at the keyboard. :) ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. examples please. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, Sep 04, 2009 at 11:14:43AM -0400, Dave Jones wrote: On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. examples please. Out-of-tree modules: pvscsi, vmxnet (for VMWare). Generally stuff frowned-upon. BTW, I believe changing Plymouth theme require regeneration of initrd. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia pgp0gl3ZWTCEx.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Thu, 2009-09-03 at 11:05 -0400, Tom spot Callaway wrote: On 09/03/2009 10:57 AM, Hans de Goede wrote: It really is like having to support gentoo, versus having to support a distro using pre build packages. And I would really like to move to the having to support a pre-build package model for the initrd. ...but not for drivers ;) It's funny how sometimes building binaries makes life easier for users, but other times it's horribly wrong :) The problem is this: The kernel binary RPM contains this pre-built initrd. The kernel source RPM does not contain the sources necessary to make this pre-built initrd. This makes me rather uncomfortable from a Licensing perspective. I'm also concerned about it from a security perspective, as these binaries are very likely to be overlooked when security updates are pushed. The problem I have is that some folks want to include additional drivers into their initrd. What are we going to recommend for this case? I know one can still build a kernel-specific version, but I fear that this results in many users having no benefit of the generic image because it'll not contain the additional bits they needed to add. Can't we at least ensure all deps are available on the system by default, so that users *can* rebuild? Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12 Snapshot 1 available
Fedora 12 Snapshot 1 is now available for testing. These snapshots consist of live images only. Available at http://torrent.fedoraproject.org/: Fedora 12 Live Snapshot 1, for i686 and x86_64 Fedora 12 Live KDE Snapshot 1, for i686 and x86_64 Available at http://spins.fedoraproject.org/: Fedora 12 Live LXDE Snapshot 1, for i686 and x86_64 Fedora 12 Live XFCE Snapshot 1, for i686 Please report issues in bugzilla. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, 2009-09-04 at 17:27 +0200, Tomasz Torcz wrote: On Fri, Sep 04, 2009 at 11:14:43AM -0400, Dave Jones wrote: On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. examples please. Out-of-tree modules: pvscsi, vmxnet (for VMWare). Generally stuff frowned-upon. BTW, I believe changing Plymouth theme require regeneration of initrd. Yeah. Most of it is evil stuff. But I am bringing it up because nobody else has - the fact of the matter is that there are lots of third party drivers and tools that are going to break if they cannot regenerate the initrd. I think it's acceptable for Fedora to completely loathe and distrust binary drivers, but I really don't think it's acceptable to actively prevent someone from using them if they would like to. What'll happen is that lots of people will start building per-kernel initrd images again, and third party websites will talk about how to work around dracut defaults rather than embracing them because they won't have an option for a generated, portable image. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Fri, Sep 04, 2009 at 08:30:14AM +0200, Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. Recently I've run it on a variety of packages, from coreutils (of course) to libvirt -- and libxml2 on request by the maintainer. To use them, build the tools described here, from source: (currently, there is no fedora package, afaik) http://clang-analyzer.llvm.org/ I ran them like this for libxml2: scan-build -o clang ./autogen.sh scan-build -o clang make This does look neat. When I tried it though, I ended up with .. scan-build: Removing directory '/mnt/data/src/git-trees/kernel/linux-2.6/clang/2009-09-04-1' because it contains no reports. While I'd love to believe the kernel is bug free, I have a hard time convincing myself that clang is doing the right thing. I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
On Friday 04 September 2009 Jindrich Novy wrote: It should be fixed now altogether with new packages in the repository. Jindrich Thank you. Now I have installed on rawhide and it works (TM). :-) -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On Fri, Sep 04, 2009 at 10:53:19AM -0400, Jon Masters wrote: The problem I have is that some folks want to include additional drivers into their initrd. What are we going to recommend for this case? I know one can still build a kernel-specific version, but I fear that this results in many users having no benefit of the generic image because it'll not contain the additional bits they needed to add. Isn't the point of the new infrastructure that we can provide multiple initramfs modules that will all end up in the filesystem on boot? Users who want to add drivers could do it even more easily than they currently can. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Reasons to preseve X on tty7
I see this discussion petered out in November, but as I missed the followups
after the change in subjects for the thread, I had seen only Dan Nicholson's
initial attempt at rectifying this problem
I've seen the philosophical discussion, but the real problem traces to the
GDM version 2.20, which involved a major rewrite of the code and a
regression in configurability. (Has anyone heard of MAJOR release numbers?
Version 2.20 should have been 3.0, imho.)
Anyhow I've extended Dan Nicholson's approach in what I think is a more
reliable manner. I don't use XDM, so I can't comment on that, but I see that
KDM in the standard distribution has been configured to start X on vt1 and
then go up from vt7 for later sessions. Since reconfiguring KDM versus the
upstart files involves multiple changes, I leave that to the experts. (See
the file /etc/kde/kdm/kdmrc to see what I mean.)
I leave /etc/event.d/tty1 alone and start it, if need be, when
/etc/X11/prefdm kicks in. The logic in prefdm, by the way, kicks in AFTER
plymouth shuts down, not before, in case it feels like re-creating the
/var/spool/gdm/force-display-on-active-vt file. I also discovered that GDM
removes that file each time a session ends, so I modified
/etc/gdm/PostSession/Default to take that into account. This is why the
first session was created on vt1 but all subsequent sessions after that user
logs out were created on vt7.
The basic idea of forcing the display on an active VT is invalid, I think.
It affects only vt1, not any of the others. If Sam is working on vt2 and
Julie starts a new session, do you want Sam to be kicked off entirely? No.
The only issue is with vt1, which the kernel uses to write boot messages. If
you do fgconsole --next-available, you'll see that vt1 is NEVER available,
and if you try deallocvt 1 you'll see why ... VT 1 is the console and
cannot be deallocated.
So the only issue is that GDM won't start X on vt1 if it thinks it's already
allocated, even if there are no processes running there. fuser -v
/dev/tty1 tells us whether we *really* want to start (or continue) X
there.
I've tested this pretty thoroughly from runlevel 5 (killing gdm-binary from
within the gdm session and other weird states) and it seems to work.
The telinit 5 situation also seems to work fine.
--- /etc/X11/prefdm.orig2009-08-31 20:38:02.0 +0200
+++ /etc/X11/prefdm2009-09-01 13:27:45.0 +0200
@@ -8,6 +8,10 @@
# Run preferred X display manager
quit_arg=
preferred=
+
+# Hack for Fedora-modified GDM
+FORCEACTIVEVT=yes
+
if [ -f /etc/sysconfig/desktop ]; then
. /etc/sysconfig/desktop
if [ $DISPLAYMANAGER = GNOME ]; then
@@ -31,6 +35,22 @@
# shut down boot splash
/usr/bin/plymouth quit $quit_arg
+# Tell Fedora-modified GDM to reuse VT1 if it's really inactive or if X is
already there;
+# otherwise, tell it not to use VT1 (and start a terminal there if need be)
+TTY1_TASK=$(fuser -v /dev/tty1 21|awk -v RS='' '/ / { print $9 ; exit }')
+if [ -z $preferred ] || [ $preferred = /usr/sbin/gdm ]; then
+if [ $FORCEACTIVEVT = yes ]; then
+if [ -z $TTY1_TASK ] || [ $TTY1_TASK = Xorg ] || $TTY1_TASK =
X ]; then
+touch /var/spool/gdm/force-display-on-active-vt
+fi
+else
+rm -f /var/spool/gdm/force-display-on-active-vt
+if [ -z $TTY1_TASK ]; then
+initctl start tty1 /dev/null
+fi
+fi
+fi
+
shopt -s execfail
[ -n $preferred ] exec $preferred $@ /dev/null 21 /dev/null
--- /etc/gdm/PostSession/Default.orig2009-07-27 16:41:41.0 +0200
+++ /etc/gdm/PostSession/Default2009-08-31 19:25:54.0 +0200
@@ -1,3 +1,26 @@
#!/bin/sh
+PATH=/sbin:/usr/sbin:/bin:/usr/bin
+
+# Hack for Fedora-modified GDM
+FORCEACTIVEVT=yes
+
+if [ -f /etc/sysconfig/desktop ]; then
+. /etc/sysconfig/desktop
+fi
+
+# Tell Fedora-modified GDM to reuse VT1 if it's really inactive or if X is
already there;
+# otherwise, tell it not to use VT1 (and start a terminal there if need be)
+TTY1_TASK=$(fuser -v /dev/tty1 21|awk -v RS='' '/ / { print $9 ; exit }')
+if [ $FORCEACTIVEVT = yes ]; then
+if [ -z $TTY1_TASK ] || [ $TTY1_TASK = Xorg ] || $TTY1_TASK = X
]; then
+touch /var/spool/gdm/force-display-on-active-vt
+fi
+else
+rm -f /var/spool/gdm/force-display-on-active-vt
+if [ -z $TTY1_TASK ]; then
+initctl start tty1 /dev/null
+fi
+fi
+
exit 0
.
*From*: Dan Nicholson dbn lists gmail com
- *To*: Development discussions related to Fedora fedora-devel-list
redhat com
- *Subject*: Re: Reasons to preseve X on tty7
- *Date*: Tue, 11 Nov 2008 20:05:38 -0800
--
On Tue, Nov 11, 2008 at 1:28 PM, Bill Nottingham notting redhat com wrote:
Dan Nicholson (dbn lists gmail com) said:
Further testing with this is giving me some bizarre errors and hangs
relating to VT switching that don't happen with this patchset backed
out. Unless I can track those down, I can't really recommend using
it.
Re: clang static analyzer: use it!
On Fri, Sep 04, 2009 at 01:15:40PM -0400, Jeff Moyer wrote: I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? It may be that the kernel defines $(CC) to gcc, at which point you lose. Try doing a make with CC=/path/to/ccc-analyzer. That was exactly it. Nice. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review needed....
2009/9/4 José Matos wrote: On Friday 04 September 2009 Josephine Tannhäuser wrote: Perhaps it is luck, but I'm happy about that fact that not all contributors with an open review request begging on devel list for a reviewer. If anybody will do it, the devel list will explode with review beggars. It's strange to see that most of the baggers are working for a big north american distributor, or living in india, or both! No, I don't want a pony!!! I live in India. Is it difficult to be patient? There are many more open reviews which are older... Please qry your friends (if you have some) or be patient.. Is there any review you want us to look to? I will be happy to review few for you. -- Regards, Rakesh Pandit -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review needed....
On Friday 04 September 2009 Josephine Tannhäuser wrote: Perhaps it is luck, but I'm happy about that fact that not all contributors with an open review request begging on devel list for a reviewer. If anybody will do it, the devel list will explode with review beggars. It's strange to see that most of the baggers are working for a big north american distributor, or living in india, or both! No, I don't want a pony!!! Is it difficult to be patient? There are many more open reviews which are older... Please qry your friends (if you have some) or be patient.. Is there any review you want us to look to? -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 20090904
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-04/fedora-meeting.2009-09-04-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-09-04/fedora-meeting.2009-09-04-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-04/fedora-meeting.2009-09-04-17.01.log.html -- 17:01:37 jds2001 #startmeeting FESCo meeting 2009-09-04 17:01:37 zodbot Meeting started Fri Sep 4 17:01:37 2009 UTC. The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:37 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:38 jds2001 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:01:38 zodbot Current chairs: Kevin_Kofler dgilmore j-rod jds2001 jwb nirik notting sharkcz skvidal 17:01:42 * skvidal is here 17:01:43 * nirik is here. 17:01:46 * sharkcz is here 17:01:49 skvidal woah - and so is jds2001, apparently 17:01:50 jds2001 change in plans, I'm here :) 17:01:52 Kevin_Kofler Present. 17:01:57 * notting is here 17:02:17 jds2001 alright, let me pull up the agenda :) 17:02:45 j-rod Here 17:02:46 jds2001 notting: the report looks old and stale 17:02:55 notting jds2001: nothing else was in the tickets 17:02:55 jds2001 do we just have those two items? 17:02:59 jds2001 k 17:03:13 jds2001 #topic FLP proposal 17:03:16 jds2001 .fesco 243 17:03:18 zodbot jds2001: #243 (New entry of 'Build packages for which Fedora is upstream for all language translators' review correction' for F12 schedule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/243 17:03:46 nirik so they added a list... 17:03:54 notting given that list, i'm +1 for it 17:04:00 nirik but do we really want to add this right now for this cycle? I guess we could. 17:04:22 jds2001 yeah, that list is sane. 17:04:50 jds2001 but it adds something starting today 17:05:05 nirik well, yesterday... 17:05:09 jds2001 poelcat: you around? 17:05:19 notting realistically,it's 'build packages by beta freeze' 17:05:47 Kevin_Kofler The deadline is Sep 15. 17:05:56 Kevin_Kofler Who cares about the start date? 17:06:00 Kevin_Kofler We can make it today or whatever. 17:06:25 Kevin_Kofler I'm +1 to the proposal with the given list. 17:06:40 nirik how do indicate to the maintainers of those packages that they must do a build? 17:07:12 jds2001 i guess file a bug? 17:07:16 Kevin_Kofler But I'm completely -1 to the suggestion of introducing that kind of requirements for packages which are translated by upstream teams (or upstream projects which don't do translations at all). 17:07:29 jds2001 Kevin_Kofler: me too 17:07:59 * skvidal is cool w/the list too - +1 17:08:05 jds2001 +1 17:08:16 sharkcz +1, the list is OK 17:08:33 * warren has a question for FESCO when it is appropriate. 17:08:33 j-rod I'll play balk too, +1 17:08:47 notting play balk? we all take a base? 17:08:51 jds2001 warren: we only have one more item on the agenda :) 17:09:12 jds2001 which i suspect is a noop, but oh well. 17:09:32 nirik +1 from me too, but we should make sure they know abotu this... fedora-devel-announce email? or email to all the maintainers? 17:10:19 jds2001 yeah, who wants to take that? 17:10:23 jds2001 the proposal owner? 17:10:27 jds2001 or one of us? 17:11:02 * dgilmore is here 17:11:44 jds2001 bueller? 17:12:58 * jds2001 guesses he'll do it just to move on :) 17:13:06 notting i think the trans team can do it,as they're probably in a good position to do it for future releases too 17:13:12 sharkcz IMO the proposal owner should create a tracker bug + bugs for individual packages 17:13:23 notting unless it becomes part of the 'normal' schedule notices 17:13:50 jds2001 notting: i guess it would be in the future. 17:14:38 jds2001 ok, lets put a note in the ticket 17:14:52 jds2001 saying that this needs to be communicated by the trans team. 17:15:03 jds2001 sound good? 17:15:32 notting wfm 17:15:56 jds2001 #agreed FLP proposal is accepted, will need to be communicated to package owners by the translation team 17:16:04 poelcat jds2001: yes, i'm here 17:16:06 jds2001 #top libvdpau 17:16:19 jds2001 poelcat: cool 17:16:31 poelcat now that i saw ping :) 17:16:35 jds2001 poelcat: we just added an item to the F12 schedule :) 17:16:55 jds2001 poelcat: the translation team wanted all packages rebuilt for which we are upstream. 17:17:10 poelcat cool, i'll add it in 17:17:12 jds2001 There's a list in https://fedorahosted.org/fesco/ticket/243 17:17:26 poelcat how long does that task usually take? 17:17:38 notting a day or three 17:17:44 jds2001 poelcat: the translation team had it proposed to start yesterday and go to the 15th 17:17:49 notting less if all the maintainers are paying attention 17:17:50 jds2001 for future schedules :) 17:18:04 jds2001 but yeah, it doesnt take that long 17:18:39 poelcat just curious so i can build the logic in the right way... *who* builds the packages...each maintainer or automatically by releng? 17:18:58 jds2001 good question :) 17:19:04 jds2001 each
what features are required in Fedora kernel
Hi all, I am building kernels for some ARM based devices that use Fedora/ARM as user-land. These devices are usually very limited in the size of kernel that can be stored in their flash memories (like 2MB kernel, 4MB ramdisk). So I would like to know what kernel features make a Fedora kernel, what are the MUST HAVE features? Now I have those on my list - audit - SELinux - IPv6 - Netfilter for both IPv4 and IPv6 but there are others for sure. Heavily modular kernel is about 1.65 MB now. Thanks Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
Dave Jones da...@redhat.com writes: On Fri, Sep 04, 2009 at 08:30:14AM +0200, Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. Recently I've run it on a variety of packages, from coreutils (of course) to libvirt -- and libxml2 on request by the maintainer. To use them, build the tools described here, from source: (currently, there is no fedora package, afaik) http://clang-analyzer.llvm.org/ I ran them like this for libxml2: scan-build -o clang ./autogen.sh scan-build -o clang make This does look neat. When I tried it though, I ended up with .. scan-build: Removing directory '/mnt/data/src/git-trees/kernel/linux-2.6/clang/2009-09-04-1' because it contains no reports. While I'd love to believe the kernel is bug free, I have a hard time convincing myself that clang is doing the right thing. I added a path to the clang bin/ dir, and copied scan-build to my ~/bin and then ran with 'make defconfig ; scan-build -o clang make bzImage' Am I missing something obvious ? It may be that the kernel defines $(CC) to gcc, at which point you lose. Try doing a make with CC=/path/to/ccc-analyzer. Cheers, Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
On Friday 04 September 2009 Jindrich Novy wrote: It should be fixed now altogether with new packages in the repository. Jindrich One (really) minor hiccup, when installing all the doc files with yum install texlive-*-doc I get a missing dependency texlive-wadalab-doc is needed by package texlive-cjk-doc. Excluding the later from the transaction works. This problems appears (unsurprisingly) on both F11 and rawhide. -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: what features are required in Fedora kernel
On Friday 04 September 2009 02:17:10 pm Dan Horák wrote: I am building kernels for some ARM based devices that use Fedora/ARM as user-land. Glad to see someone else looking at the ARM kernel. These devices are usually very limited in the size of kernel that can be stored in their flash memories (like 2MB kernel, 4MB ramdisk). So I would like to know what kernel features make a Fedora kernel, what are the MUST HAVE features? Maybe some usb devices. Which ones...I don't know. :) Now I have those on my list - audit Note that the audit system on ARM is dysfunctional. No one has ever taken the time to write the requisite code in arch/arm/kernel/ptrace.c to call audit_syscall_entry(). Without that code upstream (or as a patch), the audit system is limited to user space originating events. I don't know if SE Linux AVC's are affected by the audit system not having its hands on a lot of information during the syscall. - SELinux - IPv6 - Netfilter for both IPv4 and IPv6 Netfilter is needed badly on that arch since the default system image has a mail server listening to the public IP address and running as root. Iptables is needed to block this access. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT for f12 status
On 09/03/2009 04:09 PM, Jiri Moskovcak wrote: On 09/02/2009 07:19 PM, Colin Walters wrote: On Wed, Sep 2, 2009 at 5:11 PM, Matthias Clasenmcla...@redhat.com wrote: On Wed, 2009-09-02 at 17:04 +, Colin Walters wrote: On Wed, Sep 2, 2009 at 4:38 PM, Matthias Clasenmcla...@redhat.com wrote: After talking to the abrt guys, I've changed the desktop spin ks to replace bug-buddy and kerneloops by abrt. This change should be made in comps (as per my original attached patch), not the kickstart. If we only change the kickstart then people doing automatic kickstarted desktop installs will get a divergent desktop which is not what we want. Sure, I agree that we should also do this change in comps. Ok, done. The comps change should be pulled into the kickstart through so there shouldn't have been a need to change it as well. Also I've attached a patch which should update the Obsoletes handling to correspond with what we determined in discussion earlier; if one of the ABRT people or a provenpackager could apply that'd be nice. I pushed the fixed spec file into the git repo. Now I'm testing the new package with some additional fixes to make abrt work better with livecd. (Still didn't get rid of debuginfo installation, as it needs a bit more work) Jirka I updated abrt in rawhide with promised fixes for livecd. Jirka attachment: jmoskovc.vcf-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: what features are required in Fedora kernel
On Fri, 4 Sep 2009, Dan Horák wrote: Hi all, I am building kernels for some ARM based devices that use Fedora/ARM as user-land. These devices are usually very limited in the size of kernel that can be stored in their flash memories (like 2MB kernel, 4MB ramdisk). So I would like to know what kernel features make a Fedora kernel, what are the MUST HAVE features? This is an interesting question. I'd hate to think that something being unable to be included because of technical reasons would cause us to be unable to call something Fedora. -Mike-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Minitube - youtube for your desktop, still a little early in development
On Thu, 2009-09-03 at 23:25 -0400, Michel Alexandre Salim wrote: That was the rationale for vagalume ending up in rpmfusion-free: the code itself is fully free, but it's not usable without some patent-encumbered codecs. By that rationale, though, shouldn't totem-youtube end up in rpmfusion-free too? My understanding is that Totem (and its YouTube plugin) simply call out to Gstreamer, and the Gstreamer libraries (through PackageKit's automatic-installer plugin, if necessary) are responsible for the decoding. So, the Totem plugin itself is not patent-encumbered by any means. Then again, it is also not very usable without those codecs, either. Maybe it should be moved to the RPMFusion Free repo? -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On 09/03/2009 11:30 PM, Jim Meyering wrote: Quick summary: use this tool: http://clang-analyzer.llvm.org/ If you're not using its scan-build tool, then start. Right now. Really. It's that good. ... The software does not understand Fedora gcc/g++ well. Just to get started, I had to add these to the command line: -I/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1 \ -I/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/x86_64-redhat-linux Then I got several dozen false positives (complaints that were incorrect) from my first file. How new is this software? -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
José Matos jama...@fc.up.pt wrote: On Friday 04 September 2009 Jindrich Novy wrote: It should be fixed now altogether with new packages in the repository. Jindrich One (really) minor hiccup, when installing all the doc files with yum install texlive-*-doc I get a missing dependency texlive-wadalab-doc is needed by package texlive-cjk-doc. Excluding the later from the transaction works. This problems appears (unsurprisingly) on both F11 and rawhide. I get lots of dependency problems on (vanilla) rawhide x86_64. Stuff like: html2ps-1.0-0.3.b5.fc12.noarch, jadetex-3.13-8.fc12.noarch, linuxdoc-tools-0.9.65-2.fc12.x86_64, ... (perhaps due to other packages depending on texlive?) --skip-broken isn't able to fix the mess, and yum gives up. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: what features are required in Fedora kernel
This is an interesting question. I'd hate to think that something being unable to be included because of technical reasons would cause us to be unable to call something Fedora. Well, I think it's more or less whatever works. That is, we require the various kernel features that the rest of the Fedora packages and their integration need to work properly. Are you trying to get the installed kernel rpm size real small, or just to get the kernel+initrd real small? The latter seems fairly easy--just make everything not in the boot path modular and make sure mkinitrd doesn't include anything unnecessary. Then everything else can be in post-boot modules and you don't necessarily have to strip down the kernel build particularly. Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
They do not claim to handle C++. They failed to generate the obvious error message upon finding C++ syntax. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
please push gstreamer-plugins-base update
For those of us that have pitivi installed and want the pitivi update, we need the new gstreamer-plugins-base update. The gstreamer packages are still sitting in updates-testing (after several updates pushes). Needless to say, dep resolving is failing. Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 520505] Spurious dependency on perl(Test::More)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=520505 --- Comment #5 from Chris Weyl cw...@alumni.drew.edu 2009-09-04 02:36:13 EDT --- (In reply to comment #4) (In reply to comment #2) There are often good reasons to pack the testsuite as documentation; I think this is the first time I've heard someone actually agree with Chris on this. On the other hand, I know several people (including myself) have repeatedly stated their opinions that it's pointless or even actively harmful when done as a general packaging practice. Well, I guess we'll end up needing a guideline for this sometime. Not to fan the flames, as it were, but I'm curious as to what you mean by actively harmful? If possible, some concrete examples would be helpful to understand the claimed harm. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 520505] Spurious dependency on perl(Test::More)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=520505 --- Comment #4 from Ville Skyttä ville.sky...@iki.fi 2009-09-04 02:29:50 EDT --- (In reply to comment #2) There are often good reasons to pack the testsuite as documentation; I think this is the first time I've heard someone actually agree with Chris on this. On the other hand, I know several people (including myself) have repeatedly stated their opinions that it's pointless or even actively harmful when done as a general packaging practice. Well, I guess we'll end up needing a guideline for this sometime. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-12 import.log, NONE, 1.1 perl-CGI-Application-Plugin-DBIC-Schema.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13011/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-DBIC-Schema.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-DBIC-Schema-0_2-1_fc11:F-12:perl-CGI-Application-Plugin-DBIC-Schema-0.2-1.fc11.src.rpm:1252051050
--- NEW FILE perl-CGI-Application-Plugin-DBIC-Schema.spec ---
Name: perl-CGI-Application-Plugin-DBIC-Schema
Version:0.2
Release:1%{?dist}
Summary:Easy DBIx::Class access from CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-DBIC-Schema/
Source0:
http://www.cpan.org/authors/id/V/VA/VANAMBURG/CGI-Application-Plugin-DBIC-Schema-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod)
Requires: perl(CGI::Application)
Requires: perl(DBIx::Class)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
CGI::Application::Plugin::DBIC::Schema adds easy access to a
DBIx::Class::Schema to your Titanium or CGI::Application modules. Lazy
loading is used to prevent a database connection from being made if the
schema method is not called during the request. In other words, the
database connection is not created until it is actually needed.
%prep
%setup -q -n CGI-Application-Plugin-DBIC-Schema-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Tue Sep 01 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.2-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file:
/cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Sep 2009 02:14:23 - 1.1
+++ .cvsignore 4 Sep 2009 07:58:13 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-DBIC-Schema-0.2.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Sep 2009 02:14:23 - 1.1
+++ sources 4 Sep 2009 07:58:13 - 1.2
@@ -0,0 +1 @@
+a76923798dc1e03dd67f5bd0542fe3c5 CGI-Application-Plugin-DBIC-Schema-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-11 import.log, NONE, 1.1 perl-CGI-Application-Plugin-DBIC-Schema.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13551/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-DBIC-Schema.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-DBIC-Schema-0_2-1_fc11:F-11:perl-CGI-Application-Plugin-DBIC-Schema-0.2-1.fc11.src.rpm:1252051269
--- NEW FILE perl-CGI-Application-Plugin-DBIC-Schema.spec ---
Name: perl-CGI-Application-Plugin-DBIC-Schema
Version:0.2
Release:1%{?dist}
Summary:Easy DBIx::Class access from CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-DBIC-Schema/
Source0:
http://www.cpan.org/authors/id/V/VA/VANAMBURG/CGI-Application-Plugin-DBIC-Schema-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod)
Requires: perl(CGI::Application)
Requires: perl(DBIx::Class)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
CGI::Application::Plugin::DBIC::Schema adds easy access to a
DBIx::Class::Schema to your Titanium or CGI::Application modules. Lazy
loading is used to prevent a database connection from being made if the
schema method is not called during the request. In other words, the
database connection is not created until it is actually needed.
%prep
%setup -q -n CGI-Application-Plugin-DBIC-Schema-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Tue Sep 01 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.2-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file:
/cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Sep 2009 02:14:23 - 1.1
+++ .cvsignore 4 Sep 2009 08:01:51 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-DBIC-Schema-0.2.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Sep 2009 02:14:23 - 1.1
+++ sources 4 Sep 2009 08:01:52 - 1.2
@@ -0,0 +1 @@
+a76923798dc1e03dd67f5bd0542fe3c5 CGI-Application-Plugin-DBIC-Schema-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-10 import.log, NONE, 1.1 perl-CGI-Application-Plugin-DBIC-Schema.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv14702/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-CGI-Application-Plugin-DBIC-Schema.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-CGI-Application-Plugin-DBIC-Schema-0_2-1_fc11:F-10:perl-CGI-Application-Plugin-DBIC-Schema-0.2-1.fc11.src.rpm:1252051453
--- NEW FILE perl-CGI-Application-Plugin-DBIC-Schema.spec ---
Name: perl-CGI-Application-Plugin-DBIC-Schema
Version:0.2
Release:1%{?dist}
Summary:Easy DBIx::Class access from CGI::Application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application-Plugin-DBIC-Schema/
Source0:
http://www.cpan.org/authors/id/V/VA/VANAMBURG/CGI-Application-Plugin-DBIC-Schema-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI::Application)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Pod)
Requires: perl(CGI::Application)
Requires: perl(DBIx::Class)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
CGI::Application::Plugin::DBIC::Schema adds easy access to a
DBIx::Class::Schema to your Titanium or CGI::Application modules. Lazy
loading is used to prevent a database connection from being made if the
schema method is not called during the request. In other words, the
database connection is not created until it is actually needed.
%prep
%setup -q -n CGI-Application-Plugin-DBIC-Schema-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Tue Sep 01 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.2-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file:
/cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 4 Sep 2009 02:14:23 - 1.1
+++ .cvsignore 4 Sep 2009 08:04:56 - 1.2
@@ -0,0 +1 @@
+CGI-Application-Plugin-DBIC-Schema-0.2.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-CGI-Application-Plugin-DBIC-Schema/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 4 Sep 2009 02:14:23 - 1.1
+++ sources 4 Sep 2009 08:04:56 - 1.2
@@ -0,0 +1 @@
+a76923798dc1e03dd67f5bd0542fe3c5 CGI-Application-Plugin-DBIC-Schema-0.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 520505] Spurious dependency on perl(Test::More)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=520505 --- Comment #6 from Stepan Kasal ska...@redhat.com 2009-09-04 05:19:54 EDT --- In the clarification of why it is harmful to add the test suite to the docs, please abstract from the fact that rpm currently searches for dependencies in %doc files. That's a bug that need to be fixed. (In package review, it is ensured that docs are not required for correct function; consequently, requirements of cocds cannot be necessary for proper function either.) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 520505] Spurious dependency on perl(Test::More)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=520505 --- Comment #7 from Ville Skyttä ville.sky...@iki.fi 2009-09-04 13:01:13 EDT --- As said, it's been discussed before. Bad API usage/coding examples; package size bloat; installing stuff upstream hasn't intended to be installed; potential for spurious dependency bloat (sorry that can't be left out as evidenced by this bug) - or if you eliminate these deps, the tests can't be run without manually managing them at which point it'd be better to download and use the source rpms for this purpose (they have the proper deps, Makefile.PL's etc infrastructure upstream intended for the test suite); kind of encourages bad practices such as mentioned by Chris in his mail referred to in comment 2 (installing packages in system locations and _then_ after the fact thinking about running test suites) etc. Yes, there are exceptions and _sometimes_ packaging the test suites or parts of them might be a good idea. It seems that test suites are packaged without much thought in Fedora packages these days though. If it was a good idea in general, why wouldn't it be done in -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 502403] RFE: add %{?perl_default_filter} to the perl spec template
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=502403 Ville Skyttä ville.sky...@iki.fi changed: What|Removed |Added Status|NEW |ASSIGNED Flag||needinfo?(cw...@alumni.drew ||.edu) --- Comment #9 from Ville Skyttä ville.sky...@iki.fi 2009-09-04 13:23:52 EDT --- Added upstream, please confirm it was done as intended: https://fedorahosted.org/rpmdevtools/changeset/6864c01 Please also remember to submit this stuff as an update to http://fedoraproject.org/wiki/Packaging:Perl#Filtering_Requires:_and_Provides -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 520505] Spurious dependency on perl(Test::More)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=520505 --- Comment #8 from Ville Skyttä ville.sky...@iki.fi 2009-09-04 13:17:04 EDT --- As said, it's been discussed before. Test suites often (usually?) contain undocumented and bad API usage/coding examples; package size bloat; installing stuff upstream hasn't intended to be installed; potential for spurious dependency bloat (sorry that can't be left out as evidenced by this bug) - or if you eliminate these deps, the tests can't be run without manually managing them at which point it'd be better to download and use the source rpms for this purpose (they have the proper deps, Makefile.PL's etc infrastructure upstream intended for the test suite and have less risk of littering system locations with generated test leftover data); kind of encourages bad practices such as mentioned by Chris in his mail referred to in comment 2 (installing packages in system locations and _then_ after the fact thinking about running test suites); if upstream docs aren't good enough it'd be better to let upstream know about that and ask them to improve things so more people would benefit; etc. Yes, there are exceptions and _sometimes_ packaging the test suites or parts of them might be beneficial. But I strongly think those cases are a rare exception and it seems that test suites are packaged without much thought in Fedora packages these days and FWIW I wouldn't personally consider approving any package that doesn't document a good rationale for including that stuff in the particular case of that package in question. If it was a good idea in general, why wouldn't it be done in other packages besides perl ones, and why isn't it done even in all perl packages, and why isn't there a general guideline that encourages shipping that stuff in place or being pushed by people, and all that already in place for lots and lots of years of packaging history? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 502403] RFE: add %{?perl_default_filter} to the perl spec template
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=502403 Chris Weyl cw...@alumni.drew.edu changed: What|Removed |Added Flag|needinfo?(cw...@alumni.drew | |.edu) | --- Comment #10 from Chris Weyl cw...@alumni.drew.edu 2009-09-04 15:12:48 EDT --- The update looks good to me; right place, right macro, right conditionalization. Thanks :) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Fedora-r-devel-list] R package dependencies, translated into RPM land.
OK; I've been chewing and debating on this with several folks, in several fora, for some time. Here are the facts as I've been able to determine them so far; at least some of them will be stupidly obvious to most of you. Please tear them apart as indicated. + The R community is much sysadmin-y and progammer-y than other language communities. Several positions about correctness which lots of admins take as Truth (i.e. dependency cycle == BAD) they find to be more of an aesthetic call. This is reasonable. + Different repositories in the R community have independant lives and attitudes. There is modest competition and grumbling between maintainers associated with different repos. + Package dependencies cross repo boundaries; sticking with the 'Better' repositories just won't work, and discussion of these variations tends to make R folks testy. conclusion: The goal of evolving the R packages into a DAG is a non-starter. + There are four classes of dependency in R-package land: Requires, Imports, Suggests, and Enhances. + Requires and Imports are required to load the package. [1] + Suggests may be required to fully CMD CHECK the package [1] + The need for suggests at CMD CHECK can be deactivated by build config file. [2] + Many of the dependency cycles can be avoided if we ignore Suggests as an RPM dependency. Now, on to opinion: + We would like all official packages to have passed a full R CMD CHECK + We would like an absolute minimum of manual special case handling. It may not be possible to make that amount zero. So: Here's my suggested procedure for building any single package, gangked from a message I sent to R-core: 1) Express binary package dependencies according to Depends and Imports. I'll call this the 'narrow dependency graph'. 2) As part of the binary package build process, run CHECK with R_CHECK_FORCE_SUGGESTS = false. I'll pull nomenclature out of my ear and call these built but not checked. 3) Build all binary packages which are downstream according to all of Depends, Imports, Suggests, and Extends. I'll call this the 'broad dependency graph'. 4) Install all the packages in the broad dependency graph. 5) for each package in the broad graph, run CHECK with R_CHECK_FORCE_SUGGESTS=true. Then the affected packages are checked. Perhaps this can be noted with a signature. Whew! - Allen S. Rout [1] http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file [2] http://cran.r-project.org/doc/manuals/R-exts.html#Customizing-checking-and-building ___ Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
