Can't Create repos
I'm trying to construct koji-server on Fedora 10, but I got an error. Kojira can't create repos. It is always failed when try to create repos. 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT [r...@localhost kojibuilder1]# tail /var/log/kojira.log 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT Anyone got this error? And Could you tell me how to solve it? Thanks in advance. Nguyễn Văn Tân Thiết kế ngay một Pingbox độc đáo cho riêng bạn! Tạo một nơi để chat trên blog là chuyện nhỏ. http://vn.messenger.yahoo.com/pingbox/-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Can't Create repos
I have already had this problem. Re-check the repo directory permission (usually in /mnt/koji) and selinux linux permissions as well. I have selinux disabled, to avoid problems. I may find more usefull information in kojid.log. Rodrigo Trujillo From: NGUYEN VAN TAN tan2...@yahoo.com To: fedora-buildsys-list@redhat.com Date: 03/09/2009 08:29 Subject: Can't Create repos I'm trying to construct koji-server on Fedora 10, but I got an error. Kojira can't create repos. It is always failed when try to create repos. 2009-09-03 14:06:44,449 [INFO] koji.repo.manager: Created newRepo task 116 for tag 2 (dist-foo-build) 2009-09-03 14:07:00,198 [INFO] koji.repo.manager: Found repo 24, state=INIT 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT [r...@localhost kojibuilder1]# tail /var/log/kojira.log 2009-09-03 14:07:16,096 [INFO] koji.repo.manager: Problem: newRepo task 116 for tag 2 is FAILED 2009-09-03 14:10:00,128 [INFO] koji.repo.manager: Created newRepo task 121 for tag 2 (dist-foo-build) 2009-09-03 14:10:05,331 [INFO] koji.repo.manager: Problem: newRepo task 121 for tag 2 is FAILED 2009-09-03 14:10:05,397 [INFO] koji.repo.manager: Found repo 25, state=INIT 2009-09-03 14:13:05,745 [INFO] koji.repo.manager: Created newRepo task 128 for tag 2 (dist-foo-build) 2009-09-03 14:13:21,376 [INFO] koji.repo.manager: Found repo 26, state=INIT 2009-09-03 14:13:37,095 [INFO] koji.repo.manager: Problem: newRepo task 128 for tag 2 is FAILED 2009-09-03 14:16:23,676 [INFO] koji.repo.manager: Created newRepo task 133 for tag 2 (dist-foo-build) 2009-09-03 14:16:39,445 [INFO] koji.repo.manager: Problem: newRepo task 133 for tag 2 is FAILED 2009-09-03 14:16:39,492 [INFO] koji.repo.manager: Found repo 27, state=INIT Anyone got this error? And Could you tell me how to solve it? Thanks in advance. Nguyễn Văn Tân Yahoo! Mail nay NHANH HƠN - Thử ngay!-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On 09/02/2009 07:17 PM, Jesse Keating wrote: On Wed, 2009-09-02 at 10:26 +0200, Hans de Goede wrote: As one of the persons involved in dracut and in integrating dracut into the distribution I'm rather surprised to hear this. Where has this been discussed ? Were are the bugs for the situations where this does not work properly ? Also as one of the mkinitrd maintainers I would like to know if we're sticking with mkinitrd for Fedora 12, as there are some open issues which would be really good to fix before the beta if we go this way. The fact that it wasn't turned on at Alpha means it really shouldn't be on now, not without FESCo approval. That is interesting reasoning, first keep it out of Alpha even though it was ready as you were afraid it would delay the Alpha further (although there were no open bugs) and no now use that to also keep it out of Fedora 12 entirely. We've got some licensing concerns with a pre-generated binary blob of bits from other packages being shipped with the kernel package, and the kernel srpm doesn't have any sources to match those binary blobs. We already do the same with the stage1 and stage2 images of anaconda. The initrd is just a cpio archive, like the livecd images are just an iso, it is all mere aggregation. Those are my biggest issues. I'd much prefer to see work continue on dracut and have it available for F-12 users, but not default. We only have one more major test point, the Beta, and there is very little time after the beta to repair such a critical function as our initrd generation, and no opportunity to test such repairs. dracut already is the default in rawhide and there are very little bug reports because of it. Not to mention that other Features such as: https://fedoraproject.org/wiki/Anaconda/Features/FCoE https://fedoraproject.org/wiki/Anaconda/Features/MDRaid Depend up on it. Regards, Hans -- 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/02/2009 10:49 PM, Colin Walters wrote: Also I've attached a patch which should update the Obsoletes handling to correspond with what we determined in discussion earlier; Versioned obsoletes is preferable. Rahul -- 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 02/09/09 22:52, Philip Prindeville 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, inmodule
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.
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?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090903 changes
Compose started at Thu Sep 3 06:15:07 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) anjal-0.1.0-0.7.20090821git5ac8bfe.fc12.i686 requires libmissioncontrol-client.so.0 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 yum-plugin-versionlock-1.1.23-1.fc12.noarch requires yum = 0:3.2.24 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) anjal-0.1.0-0.7.20090821git5ac8bfe.fc12.x86_64 requires libmissioncontrol-client.so.0()(64bit) 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)
Re: rawhide report: 20090903 changes
2009/9/3 Rawhide Report rawh...@fedoraproject.org: PackageKit-0.5.2-0.1.20090902git.fc12 - * Wed Sep 02 2009 Richard Hughes rhug...@redhat.com - 0.5.2-0.1.20090902git - Update to a newer git snapshot from the 0.5.x series. - Should fix some issues with KPackageKit. Heads up: this is likely broken -- it will not detect the network state using NetworkManager due to the recent libnm_glib - libnm-glib rename. I'll do a new build today which will fix things. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ownership avrdude
Hi, I'm claiming ownership over avrdude. There is a new upstream release and I'm in progress of packaging software that depends on avrdude. Any objections? gr, Bart -- Bart Vanbrabant b...@vanbrabant.eu -- 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)
Hans de Goede (j.w.r.dego...@hhs.nl) said: The fact that it wasn't turned on at Alpha means it really shouldn't be on now, not without FESCo approval. That is interesting reasoning, first keep it out of Alpha even though it was ready as you were afraid it would delay the Alpha further (although there were no open bugs) and no now use that to also keep it out of Fedora 12 entirely. I agree - certainly, there has been nothing raised to FESCo yet to disable it, and it was not removed from the feature list in any FESCo discussion. That discussion can certainly be had if someone wants to raise it to FESCo. We've got some licensing concerns with a pre-generated binary blob of bits from other packages being shipped with the kernel package, and the kernel srpm doesn't have any sources to match those binary blobs. We already do the same with the stage1 and stage2 images of anaconda. The initrd is just a cpio archive, like the livecd images are just an iso, it is all mere aggregation. The issue is that stage1/stage2 are generated at *tree* build time, and therefore are guaranteed to match the tree (and source RPMs) we ship. As dracut images are currently built at *kernel* build time, that is not the case. Moving to building initramfs at kernel install time would solve this. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Minitube - youtube for your desktop, still a little early in development
Hey all, I packaged up this app I stumbled upon called minitube (http://flavio.tordini.org/minitube) but it seems a bit unstable and I don't really want to toss it up to a package review until its stable enough to be shipped but I wanted to mention it to see if anyone might find a use for it, would help testing and submitting bugs upstream, etc. Random side note, a thought that ran across my mind during this is: Do we have some sort of expectation of stability of software in the repositories? is there some sort of a policy/guideline or is it more of a judgement call placed on the packager? Spec: http://maxamillion.fedorapeople.org/minitube.spec SRPM: http://maxamillion.fedorapeople.org/minitube-0.5-2.fc11.src.rpm -Adam -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sed -i symlink behavior...
On 09/02/2009 11:39 AM, Jerry James wrote: On Wed, Sep 2, 2009 at 9:35 AM, Warren Togamiwtog...@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 -- 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/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 attachment: jmoskovc.vcf-- 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, Sep 03, 2009 at 08:38:49AM -0500, Adam Miller wrote: Hey all, I packaged up this app I stumbled upon called minitube (http://flavio.tordini.org/minitube) but it seems a bit unstable and I don't really want to toss it up to a package review until its stable enough to be shipped but I wanted to mention it to see if anyone might find a use for it, would help testing and submitting bugs upstream, etc. Does it have any functionality that the totem youtube plugin doesn't? -- 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: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
Hi, On 09/03/2009 03:36 PM, Bill Nottingham wrote: Hans de Goede (j.w.r.dego...@hhs.nl) said: The fact that it wasn't turned on at Alpha means it really shouldn't be on now, not without FESCo approval. That is interesting reasoning, first keep it out of Alpha even though it was ready as you were afraid it would delay the Alpha further (although there were no open bugs) and no now use that to also keep it out of Fedora 12 entirely. I agree - certainly, there has been nothing raised to FESCo yet to disable it, and it was not removed from the feature list in any FESCo discussion. That discussion can certainly be had if someone wants to raise it to FESCo. We've got some licensing concerns with a pre-generated binary blob of bits from other packages being shipped with the kernel package, and the kernel srpm doesn't have any sources to match those binary blobs. We already do the same with the stage1 and stage2 images of anaconda. The initrd is just a cpio archive, like the livecd images are just an iso, it is all mere aggregation. The issue is that stage1/stage2 are generated at *tree* build time, and therefore are guaranteed to match the tree (and source RPMs) we ship. As dracut images are currently built at *kernel* build time, that is not the case. Moving to building initramfs at kernel install time would solve this. Yes, but also loose one of the main advantage, that everyone with kenrel-versionFoo is using the exact same initrd, if we build at install time, and there is for example an mdraid issue, how do I know which exact version of mdadm is in the initrd ? I know this argument can be reversed, that if the exact version is not known, people cannot excercise their rights under the GPL. So I suggest we add a list of package NEVR's to the kernel rpm which contains the exact packages used to build the initrd, yet still keep building it as part of the kernel rpm (so at build time), as this is much easier for debugging issues. 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. Regards, Hans -- 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/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. 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. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NetworkManager-based packages won't rebuild to fix broken deps
On Mon, 2009-08-31 at 02:59 -0700, Alex Lancaster wrote: CM == Caolán McNamara writes: CM On Mon, 2009-08-31 at 01:53 -0700, Alex Lancaster wrote: Rawhide Report writes: Has something changed in the API/ABI? CM The name of the .pc file itself, i.e. libnm-glib.pc - libnm_glib.pc, so CM pkg-config --exists libnm-glib instead of pkg-config --exists libnm_glib CM etc. No idea if this is an intentional change or not, but I assume that CM it is. If so, it would have been kind of nice to announce it here on fedora-devel-list so that maintainers of dependent packages would be prepared. (At least I couldn't find an announcement in the quick search of the past few days of archives I checked). It would have, and I should have done so. That's my fault. The API/ABI changed for libnm-glib as a result of the port to PolicyKit 1.0, and the soname was also bumped. Since the name never should have been _ in the first place, at the same time as the soname bump and API/ABI changes, the library name and thus the pkgconfig file name were also changed. This also ensures that we see the error more clearly at build time instead of segfaults due to missing symbols at runtime. In addition to that, I'll be bumping the soname of the libnm-glib-vpn library for the Debian folks, but most programs don't link to libnm-glib-vpn. Dan -- 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/03/2009 11:35 AM, Hans de Goede wrote: 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. True, but we do provide SRPMS with the sources, if we include a list of the SRPMS with the sources, with full NEVR in the kernel rpm as doc, wouldn't that be sufficient? Ehh. I'm still thinking about that. We don't generally permit other packages to do that. I'm also concerned about it from a security perspective, as these binaries are very likely to be overlooked when security updates are pushed. We already have that issue with mkinitrd, and will have it when we move to generating dracut initrd's in %post too. IOW the security issue will always be there, so lets focus on the licensing issue please. Well, it is less of an issue with mkinitrd, because the user can easily regenerate it. I do not think this is the same case with the generic initrd. Perhaps we could regenerate the generic initrd on the user's system if any of the binary packages that are used to make it get an update? ~spot -- 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
Paul Howarth wrote:
On 02/09/09 22:52, Philip Prindeville 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, inmodule
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.
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?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
No joy:
[r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --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 30 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
Re: another spin of TeX Live 2009 packages
On Wednesday 26 August 2009 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: OK, I have finally installed texlive on F11. With this update all worked (with the exception of some quirks already reported in this list). Unfortunately in the end I had a non working latex. Making this story short for some reason texlive-latex was not installed when I had update the system. Installing it fixed the problem. Does it make sense to have the latex packages depending on this? Thanks, Jindrich Thanks for the hard, :-) -- José Abílio -- 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
Could the root cache be broken? Incompatible changes in RPM between F9 and F10 ? BTW, F9 was EOLed in July, so if it's broken now, I doubt it will be fixed. -- Mathieu Bridon (bochecha) -- 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, Sep 3, 2009 at 5:05 PM, Tom spot Callawaytcall...@redhat.com 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. 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. As long as we (fedora) ship the source code this shouldn't be an issue, or am I missing something? -- 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
Paul Howarth wrote:
On 03/09/09 17:07, Philip Prindeville wrote:
Paul Howarth wrote:
On 02/09/09 22:52, Philip Prindeville 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, inmodule
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.
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?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
No joy:
[r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --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 30 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, inmodule
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
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On 03/09/09 17:07, Philip Prindeville wrote:
Paul Howarth wrote:
On 02/09/09 22:52, Philip Prindeville 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, inmodule
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.
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?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
No joy:
[r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --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 30 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, inmodule
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
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
Hans de Goede (j.w.r.dego...@hhs.nl) said: 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. 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. True, but we do provide SRPMS with the sources, if we include a list of the SRPMS with the sources, with full NEVR in the kernel rpm as doc, wouldn't that be sufficient? Not really. In the case of initrd-built-with-kernel, it could be packages in the buildroot that never leave koji for release/updates, and are then garbage collected. 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 Thu, 2009-09-03 at 18:37 +0200, drago01 wrote: As long as we (fedora) ship the source code this shouldn't be an issue, or am I missing something? See the other messages. We have no facility to ensure that the binaries used in generation of the initrd during kernel build have matching srpms always available during the time that the kernel binary is available. We have no facility to even guarantee that the binaries used to generate the initrd at build time will ever be actually shipped, if say kernel was built at 0800, then say plymouth was built at 1600, and rawhide composed at 2000 you'd never actually publish the plymouth binary that went into the initrd, let alone the srpm to match it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
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. Jindrich -- 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)
Hi, On 09/03/2009 06:00 PM, Tom spot Callaway wrote: On 09/03/2009 11:35 AM, Hans de Goede wrote: 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. True, but we do provide SRPMS with the sources, if we include a list of the SRPMS with the sources, with full NEVR in the kernel rpm as doc, wouldn't that be sufficient? Ehh. I'm still thinking about that. We don't generally permit other packages to do that. Ok let me know which way it is going to be. I'm personally a fan of generating the initrd on the buildsys, as that way I can get the exact same initrd as a bug reporter easily. But if you say it has to be generated in %post, I'll start making the necessary adjustments to new-kernel-pkg and kernel.spec I'm also concerned about it from a security perspective, as these binaries are very likely to be overlooked when security updates are pushed. We already have that issue with mkinitrd, and will have it when we move to generating dracut initrd's in %post too. IOW the security issue will always be there, so lets focus on the licensing issue please. Well, it is less of an issue with mkinitrd, because the user can easily regenerate it. I do not think this is the same case with the generic initrd. Perhaps we could regenerate the generic initrd on the user's system if any of the binary packages that are used to make it get an update? 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 Regards, Hans -- 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 Thu, 3 Sep 2009, Philip Prindeville wrote: No joy: [r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root [r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --rebuild perl-Net-Patricia-1.15_01-1.fc9.src.rpm Don't run mock as root. That'll avoid the incompatible db environment from getting created. Also some older versions of mock left the db environment in the root-cache tarball which is sure to cause problems sooner or later (this has been fixed since then but don't remember which version) - Panu - -- 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)
Hi, On 09/03/2009 06:29 PM, Bill Nottingham wrote: Hans de Goede (j.w.r.dego...@hhs.nl) said: 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. 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. True, but we do provide SRPMS with the sources, if we include a list of the SRPMS with the sources, with full NEVR in the kernel rpm as doc, wouldn't that be sufficient? Not really. In the case of initrd-built-with-kernel, it could be packages in the buildroot that never leave koji for release/updates, and are then garbage collected. Only if one and the same package gets rebuild twice in a day, and between those rebuilds a kernel get build. Or a package from updates-testing gets tagged into the buildroot override and then never becomes stable. Note that we have the same problem with any package which does static linking against an lgpl library (such as glibc). Actually if the kernel rpm contains nevr's of the packages used, a package which does static linking against an lgpl library will be a bigger problem as there we are not telling the user which exact version to get to get the library sources used. And if we have the NEVR as used during build, we can always regenerate the srpm from CVS + the lookaside cache. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20090903) FESCo meeting
The following is a list of topics to be discussed at tomorrow's FESCo meeting, at 17:00UTC in #fedora-meeting on irc.freenode.net 243 New entry of 'Build packages for which Fedora is upstream for all language translators' review correction' for F12 schedule 238 Can libvdpau go in Fedora? For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. 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 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? ~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 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. I'm really very uncomfortable with the generic initrd not including matching sources in the corresponding SRPM (whether that is kernel or some dedicated generic-dracut package is immaterial). The answer of the sources are in the Fedora lookaside cache, somewhere, go track it down yourself isn't really sufficient for me. Unfortunately, I can't think of a good way to package up a generic initrd in a way that we can provide source properly. I'm open to suggestions though. ~spot -- 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 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 pgppLpE22LQ5f.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 09/03/2009 03: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. I'm really very uncomfortable with the generic initrd not including matching sources in the corresponding SRPM (whether that is kernel or some dedicated generic-dracut package is immaterial). The answer of the sources are in the Fedora lookaside cache, somewhere, go track it down yourself isn't really sufficient for me. Unfortunately, I can't think of a good way to package up a generic initrd in a way that we can provide source properly. I'm open to suggestions though. ~spot The problem is how we associate objects in rpmbuild/koji. You can look at RPM building as transitioning between 3 types of objects: 1) We begin with a pile of SOURCES for a package. 2) We compile those sources into a collection of ARTIFACTS 3) We cpio, compress, and tag those artifacts into one or more PACKAGES (typically one. More if we have sub-packages). The problem here is that the ARTIFACTS phase isn't really represented. We relate packages to sources and that's that. If we tracked the results of the build process independently of the RPM itself, we could track much more complicated relationships between packages (for example, the kernel borrowing bits of the output from the last glibc build to make its initrd). I believe there are package managers that do this. RPM isn't well suited to it though. It would take a lot of muscle. --CJD -- 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)
If we tracked the results of the build process independently of the RPM itself, we could track much more complicated relationships between packages (for example, the kernel borrowing bits of the output from the last glibc build to make its initrd). Koji's database has that information, sort of. It can tell you exactly which other packages were installed in the buildroot, so that is the superset of what-all bits could have been rolled into the output. -- 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/03/2009 04:59 PM, Roland McGrath wrote: Koji's database has that information, sort of. It can tell you exactly which other packages were installed in the buildroot, so that is the superset of what-all bits could have been rolled into the output. Yes, but I do not think we are in good faith satisfying the requirement to distribute the source for those binaries by pointing back to koji pages and possibly forcing the user to dig into the lookaside cache. ~spot -- 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 Thu, 03 Sep 2009 10:53:54 -0600
Philip Prindeville philipp_s...@redfish-solutions.com wrote:
Paul Howarth wrote:
On 03/09/09 17:07, Philip Prindeville wrote:
Paul Howarth wrote:
On 02/09/09 22:52, Philip Prindeville 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,
inmodule 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.
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?
I'd try this first:
# rm -rf /var/lib/mock/fedora-10-x86_64/root
Paul.
No joy:
[r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --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 30 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, inmodule
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 =
Licensing policy for apps developed by Fedora Infrastructure now in effect
Over the past few months, Fedora Infrastructure has been discussing having a consistent set of licenses for applications and scripts we create for Fedora. The goals of doing this were to * Be able to share code among the various programs that we write. * Not have our libraries force a specific license on the apps that we write. * Not have conflicting licenses between our apps and our libraries * Have a clear understanding of the steps we must take whenever we want to move code from an application under one license to a library under a different one. * Protect the code we write from being taken proprietary (note, this is not the same for every author. Mirrormanager, for instance, is under the MIT/X11 License). * Be able to stay compliant with licenses within our production, staging, and publictest environments At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing The basics are: * license code that is meant to be used as a library as LGPLv2+. * license code that's meant to be used as an application as GPLv2+. * If we want to write something and use another license we should discuss it to figure out how it's going to impact us and whether there's a better way to achieve our goals first. Most of our apps are currently under GPLv2(only) so we're going to be working to change the licensing on those apps over time to reflect GPLv2 or later. If you find something that we've written that's not under GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can either get to work on making the license match the guidelines or let you know why it's not being changed. The one other thing for Infrastructure developers and System Admins to note in the Policy is the section on handling AGPLv3 applications. During the discussions about whether to use AGPLv3+ for our web applications we found and delimited many issues that need to be addressed when deploying AGPLv3+ licensed code. The aGPL portion of the policy is our first attempt at keeping us compliant with any code that is under this license. Highlights are: * Apps deployed to production under AGPL must be deployed from RPMs. Any hotfixes to those apps must have the patch in a ticket in trac on http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX. * Any AGPL app deployed in infrastructure must have links in the footer to the fedora-infrastructure SRPM repo and the trac query that pulls up our hotfixes so that people can find the exact source that we're running at any given time. * Staging must follow the same rules regarding SRPM and hotfixes. Once again, failing to link to the exact source for what we have running would put us out of compliance. * No AGPL apps can be hosted on publictest boxes at this time as publictest boxes are intended for development and the high rate of change in development is not conducive for constantly updating RPMS or patches in trac. If there's demand for publictest hosting of AGPL apps we'll need to design some method of restricting who can access the applications running there to satisfy the legal requirements. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- 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
Philip Prindeville wrote: Panu Matilainen wrote: On Thu, 3 Sep 2009, Philip Prindeville wrote: No joy: [r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root [r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --rebuild perl-Net-Patricia-1.15_01-1.fc9.src.rpm Don't run mock as root. That'll avoid the incompatible db environment from getting created. Also some older versions of mock left the db environment in the root-cache tarball which is sure to cause problems sooner or later (this has been fixed since then but don't remember which version) - Panu - So... run it as whom? [phil...@builder SRPMS]$ mock -r fedora-10-x86_64 --init --rebuild perl-Net-Patricia-1.15_01-1.fc9.src.rpm ERROR: [Errno 1] Operation not permitted ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user. ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem. [phil...@builder SRPMS]$ Ok, changing my path: [phil...@builder SRPMS]$ mock -r fedora-10-x86_64 --init --unpriv --rebuild perl-Net-Patricia-1.15_01-1.fc9.src.rpm You are attempting to run mock which requires administrative privileges, but more information is needed in order to do so. Authenticating as root Password: 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 ERROR: Could not create dir /var/lib/mock/fedora-10-x86_64/result. Error: [Errno 13] Permission denied: '/var/lib/mock/fedora-10-x86_64/result' Traceback (most recent call last): File /usr/lib/python2.5/site-packages/mock/util.py, line 61, in mkdirIfAbsent os.makedirs(dirName) File /usr/lib64/python2.5/os.py, line 172, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/var/lib/mock/fedora-10-x86_64/result' ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm) Config(fedora-10-x86_64) 0 minutes 0 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-10-x86_64/result ERROR: Could not create dir /var/lib/mock/fedora-10-x86_64/result. Error: [Errno 13] Permission denied: '/var/lib/mock/fedora-10-x86_64/result' [phil...@builder SRPMS]$ and without --unpriv is not much different. -- 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
So... run it as whom? As your normal user. Just add it to the mock group: # usermod -G mock your user -- Mathieu Bridon (bochecha) -- 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/03/2009 05:08 PM, Tom spot Callaway wrote: On 09/03/2009 04:59 PM, Roland McGrath wrote: Koji's database has that information, sort of. It can tell you exactly which other packages were installed in the buildroot, so that is the superset of what-all bits could have been rolled into the output. Yes, but I do not think we are in good faith satisfying the requirement to distribute the source for those binaries by pointing back to koji pages and possibly forcing the user to dig into the lookaside cache. ~spot Isn't it more that we know how to do it? If someone came to the mailing list and said I formally demand, as per GPLvX, that you give me the source for $Foo we can quickly comply. We don't want to handle a large number of requests in that way, but we can do it for the auditors. --CJD -- 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)
Yes, but I do not think we are in good faith satisfying the requirement to distribute the source for those binaries by pointing back to koji pages and possibly forcing the user to dig into the lookaside cache. The requirement is to provide a written offer to give someone the source when they ask. Isn't it more that we know how to do it? If someone came to the mailing list and said I formally demand, as per GPLvX, that you give me the source for $Foo we can quickly comply. We don't want to handle a large number of requests in that way, but we can do it for the auditors. Right. We could possibly attempt to automate something to generate an easy-to-download list of possibly-related sources. That could even be self-service with a web thingy you can just hand a Fedora rpm N-V-R. But at any rate, we can automate it enough to make sure that we are not put out by manual work involved in complying with legitimate requests to produce the sources. Thanks, Roland -- 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/03/2009 05:46 PM, Roland McGrath wrote: The requirement is to provide a written offer to give someone the source when they ask. Well, that's true for GPL. Can someone generate a list of the binaries used in the generic initrd and the packages that they came from? ~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 Thu, 2009-09-03 at 14:46 -0700, Roland McGrath wrote: Yes, but I do not think we are in good faith satisfying the requirement to distribute the source for those binaries by pointing back to koji pages and possibly forcing the user to dig into the lookaside cache. The requirement is to provide a written offer to give someone the source when they ask. We don't distribute under that clause of the GPL, because the 3 year timeline on it is entirely too vague and we don't want to fall into that trap. We distribute under the clause that says if we offer binaries, we have to offer source with them. This gives us the ability to remove binary and source packages at will, because when we stop offering the binary, we can stop offering the source. This is why the kernel rpm having binaries with no matching source in the kernel srpm is a problem for us. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On 09/03/2009 06:14 PM, Jesse Keating wrote: We don't distribute under that clause of the GPL, because the 3 year timeline on it is entirely too vague and we don't want to fall into that trap. Ugh. I had conveniently forgotten about that, thanks for the reminder. ~spot -- 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, Sep 3, 2009 at 9:38 AM, Adam Millermaxamill...@gmail.com wrote: Hey all, I packaged up this app I stumbled upon called minitube (http://flavio.tordini.org/minitube) but it seems a bit unstable and I don't really want to toss it up to a package review until its stable enough to be shipped but I wanted to mention it to see if anyone might find a use for it, would help testing and submitting bugs upstream, etc. [snip] What would be the point of packaging something which can not operate without codecs that fedora can not and should not ship? -- 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 20:41 -0400, Gregory Maxwell wrote: What would be the point of packaging something which can not operate without codecs that fedora can not and should not ship? I don't think that's a valid point here. For one, Fedora already has the Totem YouTube plugin packaged, which functions similarly... -- 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: Minitube - youtube for your desktop, still a little early in development
On Thu, Sep 3, 2009 at 8:41 PM, Gregory Maxwellgmaxw...@gmail.com wrote: What would be the point of packaging something which can not operate without codecs that fedora can not and should not ship? 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? Regards, -- Michel Alexandre Salim -- 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 Thu, Sep 3, 2009 at 11:37 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: # usermod -G mock your user # usermod -a -G mock your user would generally be better (won't blitz your existing group memberships) -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Request: Pure Data
On Mon, 2009-08-31 at 18:33 +0100, Peter Robinson wrote: On Mon, Aug 31, 2009 at 6:28 PM, Mani Aa.mani@gmail.com wrote: http://puredata.info/ is not in the package database. From the license POV, there are no problems. I think this is the bug your after. A review is in progress but there's a few build issues. https://bugzilla.redhat.com/show_bug.cgi?id=488563 Nope, that's not pd (pure data), a graphical programming language for music and midi applications. That bug is about pure, a term-rewriting functional programming language. -- Fernando -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packaging Request: Pure Data
On Mon, 2009-08-31 at 18:56 -0400, Orcan Ogetbil wrote: On Mon, Aug 31, 2009 at 1:28 PM, Mani A wrote: http://puredata.info/ is not in the package database. From the license POV, there are no problems. Best A. Mani Hi, Fernando at planetccrma was working on packaging a recent version of puredata. I don't know the current status. It is done and released in the testing repository (will move to the regular repository soon). There should be an older version sitting in their repos. Transferring puredata to official Fedora repos is tremendous amount of work. Last time I checked, the SPEC file was a couple thousands of lines long and it was only for 32bit. What I'm packaging is not the base pd but pd-extended[1], which includes the basic pd and many many extensions which make for a much more usable system. And I separately package several additional pd extensions (in particular flext) that are quite important but not part of pd-extended (most were, but were spun off, it is a long long story leading to package name changes, obsoletes and provides, evil epochs, etc, etc [*]) See: http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/testing/10/SRPMS/pd-extended-0.41.4-1.fc10.ccrma.src.rpm (and others in the same directory, ommit /testing/ if not found there as it will move shortly) And: http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/testing/10/i386/repoview/pd-extended.html (also available for fc11) The current package does away with my original separation of the many external collections into separate subpackages. Now you get all of them at once and as a result the spec file is much much simpler (but you don't get a subpackage choice at install time). It should not be hard to transfer to Fedora, or at least not as hard as before. Re: 32 bit: current pd-extended mostly works on 64 bit archs but the port is not complete. It is something scheduled for the next main release (I was close to finish building it but gave up, some patches made into the current srpm). I think (but I'm not 100% sure) that the base pd (not pd-extended) is now working on 64 bit archs but is both newer (higher version number) and less complete (a lot less stuff in there). -- Fernando [1]: http://puredata.info/Members/hans/pd-extended-0-41-4-released [*] I have been packaging pd since at least 2001 (probably 2000 for internal releases), for RedHat and then Fedora, it was one of the first packages in the Planet CCRMA repositories. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 507637] Missing fontset info
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=507637 Jerry James loganje...@gmail.com changed: What|Removed |Added Version|11 |rawhide --- Comment #17 from Jerry James loganje...@gmail.com 2009-09-03 10:53:35 EDT --- Do you need help applying the changes to CVS? I'm happy to do that if you'll grant permission. -- 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-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Issue 45128] Silent Failing is Bad Practice (Font fallback and Glyph Fallback)
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=45128 --- Additional comments from mey...@openoffice.org Thu Sep 3 15:32:07 + 2009 --- Have a look at the votes for 23402 (closed as a duplicate of this issue). (Why on this issue there is no „vote for this issue“ link?) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 518887] FontForge segfaults while generating TrueType version of Kurier-Regular.otf
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=518887 --- Comment #7 from Kevin Fenzi ke...@tummy.com 2009-09-03 12:11:07 EDT --- Just an update here. I posted to the upstream devel list and it seems this bug is hopefully fixed in cvs: I think this one really depends on converting OpenType advanced typographic features to Apple ones. At least that's where the crash occurs. This is now fixed in cvs. So, as soon as there is another release I can whip up a package for you to test with, or if you are brave and willing to build from cvs to confirm it's fixed that would be great too. -- 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-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 466404] Segmentation fault.
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=466404 --- Comment #14 from Kevin Fenzi ke...@tummy.com 2009-09-03 12:14:46 EDT --- It doesn't look like this is going to be fixable... I talked with upstream and the problem here is that if they just exit when they see that they can't get a font, that would hit cases where people could save their work before it crashes. From upstream: If you think you can fix it, please do. As you point out it is not really my bug, and as I have been unable to fix it in 10 years I have given up. So, I guess the answer here is to make sure our font cache information is accurate? Can I go ahead and close this now? Or would someone here like to take a stab at patching it? :) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 518887] FontForge segfaults while generating TrueType version of Kurier-Regular.otf
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=518887 --- Comment #8 from zhoujingmil...@gmail.com 2009-09-03 15:54:05 EDT --- Thanks, Kevin, for the package, but I just tested the cvs version with Version: 01:15 GMT 3-Sep-2009(20090903) and Library Version: 02:27 GMT 1-Sep-2009 and the TrueType font is generated successfully. So it is confirmed that the issue is fixed in cvs. (So this bug will be closed?) -- 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-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 518887] FontForge segfaults while generating TrueType version of Kurier-Regular.otf
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=518887 --- Comment #9 from Kevin Fenzi ke...@tummy.com 2009-09-03 16:02:46 EDT --- Up to you. We can close it out now, or wait until the next release and I will close it when that release lands in Fedora. Which would you prefer? -- 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-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 518887] FontForge segfaults while generating TrueType version of Kurier-Regular.otf
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=518887 zhoujingmil...@gmail.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||UPSTREAM --- Comment #10 from zhoujingmil...@gmail.com 2009-09-03 18:34:45 EDT --- Since it is fixed already and people encountering similar problem will probably checking out later releases or cvs builds of fontforge, given that the information is still accessible to them, I would prefer to close it so that we get «less» bugs in total. So I will close it now. -- 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-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/saab-fonts/devel saab-fonts-fontconfig.conf, NONE, 1.1 saab-fonts.spec, 1.2, 1.3
Author: aalam
Update of /cvs/pkgs/rpms/saab-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv12394
Modified Files:
saab-fonts.spec
Added Files:
saab-fonts-fontconfig.conf
Log Message:
Updating spec file and add conf file
--- NEW FILE saab-fonts-fontconfig.conf ---
?xml version=1.0 encoding=UTF-8?
!DOCTYPE fontconfig SYSTEM ../fonts.dtd
fontconfig
alias
familysans-serif/family
prefer
familySaab/family
/prefer
/alias
alias
familySaab/family
default
familyserif/family
/default
/alias
/fontconfig
Index: saab-fonts.spec
===
RCS file: /cvs/pkgs/rpms/saab-fonts/devel/saab-fonts.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- saab-fonts.spec 27 Jul 2009 03:44:05 - 1.2
+++ saab-fonts.spec 4 Sep 2009 04:18:28 - 1.3
@@ -1,14 +1,16 @@
%global fontname saab
+%global fontconf 66-%{fontname}.conf
Name:%{fontname}-fonts
Version: 0.91
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: Free Punjabi Unicode OpenType Font
Group: User Interface/X
License: GPLv2+ with exceptions
URL: http://guca.sourceforge.net/typography/fonts/saab/
Source0: http://downloads.sf.net/guca/saab.0.91.zip
+Source1: %{name}-fontconfig.conf
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: fontpackages-devel
@@ -30,13 +32,24 @@ rm -rf $RPM_BUILD_ROOT
install -m 0755 -d $RPM_BUILD_ROOT%{_fontdir}
install -m 0644 -p Saab.otf $RPM_BUILD_ROOT%{_fontdir}
+install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
+ %{buildroot}%{_fontconfig_confdir}
+
+install -m 0644 -p %{SOURCE1} \
+%{buildroot}%{_fontconfig_templatedir}/%{fontconf}
+ln -s %{_fontconfig_templatedir}/%{fontconf} \
+ %{buildroot}%{_fontconfig_confdir}/%{fontconf}
+
%clean
rm -rf $RPM_BUILD_ROOT
-%_font_pkg Saab.otf
+%_font_pkg Saab.otf %{fontconf}
%doc
%changelog
+* Tue Sep 04 2009 A S Alam aa...@redhat.com - 0.91-3
+- Add fontconfig conf file
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.91-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/saab-fonts/devel saab-fonts.spec,1.3,1.4
Author: aalam
Update of /cvs/pkgs/rpms/saab-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23340
Modified Files:
saab-fonts.spec
Log Message:
Change font pirority from 66 -67
Index: saab-fonts.spec
===
RCS file: /cvs/pkgs/rpms/saab-fonts/devel/saab-fonts.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- saab-fonts.spec 4 Sep 2009 04:18:28 - 1.3
+++ saab-fonts.spec 4 Sep 2009 04:49:31 - 1.4
@@ -1,5 +1,5 @@
%global fontname saab
-%global fontconf 66-%{fontname}.conf
+%global fontconf 67-%{fontname}.conf
Name:%{fontname}-fonts
Version: 0.91
@@ -43,7 +43,7 @@ ln -s %{_fontconfig_templatedir}/%{fontc
%clean
rm -rf $RPM_BUILD_ROOT
-%_font_pkg Saab.otf %{fontconf}
+%_font_pkg Saab.otf -f %{fontconf}
%doc
%changelog
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 503662] Review Request: saab-fonts - OTF Saab Punjabi Font
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=503662 A S Alam aa...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE --- Comment #14 from A S Alam aa...@redhat.com 2009-09-04 00:56:31 EDT --- Build for Rawhide. Closing Bug -- 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-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
Licensing policy for apps developed by Fedora Infrastructure now in effect
Over the past few months, Fedora Infrastructure has been discussing having a consistent set of licenses for applications and scripts we create for Fedora. The goals of doing this were to * Be able to share code among the various programs that we write. * Not have our libraries force a specific license on the apps that we write. * Not have conflicting licenses between our apps and our libraries * Have a clear understanding of the steps we must take whenever we want to move code from an application under one license to a library under a different one. * Protect the code we write from being taken proprietary (note, this is not the same for every author. Mirrormanager, for instance, is under the MIT/X11 License). * Be able to stay compliant with licenses within our production, staging, and publictest environments At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing The basics are: * license code that is meant to be used as a library as LGPLv2+. * license code that's meant to be used as an application as GPLv2+. * If we want to write something and use another license we should discuss it to figure out how it's going to impact us and whether there's a better way to achieve our goals first. Most of our apps are currently under GPLv2(only) so we're going to be working to change the licensing on those apps over time to reflect GPLv2 or later. If you find something that we've written that's not under GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can either get to work on making the license match the guidelines or let you know why it's not being changed. The one other thing for Infrastructure developers and System Admins to note in the Policy is the section on handling AGPLv3 applications. During the discussions about whether to use AGPLv3+ for our web applications we found and delimited many issues that need to be addressed when deploying AGPLv3+ licensed code. The aGPL portion of the policy is our first attempt at keeping us compliant with any code that is under this license. Highlights are: * Apps deployed to production under AGPL must be deployed from RPMs. Any hotfixes to those apps must have the patch in a ticket in trac on http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX. * Any AGPL app deployed in infrastructure must have links in the footer to the fedora-infrastructure SRPM repo and the trac query that pulls up our hotfixes so that people can find the exact source that we're running at any given time. * Staging must follow the same rules regarding SRPM and hotfixes. Once again, failing to link to the exact source for what we have running would put us out of compliance. * No AGPL apps can be hosted on publictest boxes at this time as publictest boxes are intended for development and the high rate of change in development is not conducive for constantly updating RPMS or patches in trac. If there's demand for publictest hosting of AGPL apps we'll need to design some method of restricting who can access the applications running there to satisfy the legal requirements. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: CONFIG_CC_OPTIMIZE_FOR_SIZE?
Em Thu, Sep 03, 2009 at 11:48:42AM -0400, Aristeu Rozanski escreveu: Hi, does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I thought that option was useful for embedded systems only. IIRC because it makes the kernel faster :-) - Arnaldo ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: CONFIG_CC_OPTIMIZE_FOR_SIZE?
On Thu, Sep 03, 2009 at 01:01:55PM -0300, Arnaldo Carvalho de Melo wrote: Em Thu, Sep 03, 2009 at 11:48:42AM -0400, Aristeu Rozanski escreveu: Hi, does anyone know why CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in fedora kernel? I thought that option was useful for embedded systems only. IIRC because it makes the kernel faster :-) The reduced icache pressure makes it a win. As a bonus some non-performance-sensitive code (like the acpi interpretor) gets a _lot_ smaller on-disk. Dave ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Fedora 11 boot faisl on md with two HBAs
With Fedora 11 on IBM x3650 M2 (x86_64), I am having problems booting after adding a second, add-in, SAS controller with 12 SAS disks in an external enclosure. Without the add-in SAS controller, the system boots fine and provides file sharing over samba, etc. The main problem with this machine is that it has an EFI BIOS which appears to bind the external/add-on SAS HBA before the internal one on which the system drives are hosted (they are both LSI SAS 3801e HBAs - the internal one has an IBM part number, while the external one is LSI). Changing the BIOS order in the option ROMs and disabling boot services on the external/add-on HBA does not seem to affect the adapter binding order, and the EFI BIOS does not provide any mechanism for controlling this. Which brings us to the bootup issues. Note that after booting into rescue mode from the installer image mdadm works as expected, with raid arrays detected and started without any problems on the disks located on both controllers. The md configuration is : /boot is on /dev/md0 with devices /dev/sd[mn]3, raid1 /root is on /dev/md1 with devices /dev/sd[op]2, raid1 /usr, /var and swap are on an LVM vg on /dev/md2 with devices /dev/sd[m-p]2, raid10 /boot/efi is on /dev/md64 with devices /dev/sd[mn]2, raid1 A separate vg for the data volume is on /dev/md127 with devices /dev/sd[a-l], raid6 (whole disks) /dev/sd[m-p] are hosted on the internal HBA, and appear as /dev/sd[a-d] when the add-in HBA is disabled. /dev/sd[a-l] hang of the add-in HBA. Note that in rescue mode, the disks start at /dev/sdc, as I'm booting from a virtual console, and /dev/sda and /dev/sdb are assigned to virtual USB disks. The problem seems to be that during bootup the raid arrays are autodetected rather than using mdadm. If the raid456 module is not included in the initrd image, booting fails with raid6 personality not detected, when the boot process tries to start /dev/md1 incrementally with /dev/sda as its first member. (This appears not to reference /etc/mdadm.conf in the initrd at all.) If the raid456 module is included in the initrd image (using --with=raid456), booting fails with /dev/sda added incrementally to /dev/md1 and /dev/sdb added incrementally to /dev/md2; it appears autodetect fails because the raid device was built from rescue mode, so the components are listed with different letters in the superblock. If I put a line in /etc/mdadm.conf in the initird image, to only scan partitioned disks (DEVICE /dev/sd*[1234]), boot hangs after loading the raid modules. (Potentially on the call to mkblkdevs after scsi_wait_scan is rmmod-ed.) This seems to suggest that the md devices are being started by kernel raid autodetection rather than mdadm. Simply switching to mdamd would likely solve the problem, given it works fine in rescue mode. Alternative suggestions are welcome, of course. I will try partitioning the 12 disks, with ext2 partitions rather than raid-auto partitions, to see if this gets me past this issue. However, it would be nice to be able to create the raid devices on whole disks, and avoid the extra step. Thanks for the help, Murthy -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: X wont start for install on an hp pavilion HDX-16 1370us
On Wed, Sep 2, 2009 at 10:56 PM, Kam Leokam@gmail.com wrote: On Wed, Sep 2, 2009 at 8:12 PM, Ed Greshkoed.gres...@greshko.com wrote: Kevin Kempter wrote: Hi all; My son bought an hp Pavilion (HDX-16 1370us) laptop, with a 16 screen. Upon trying to start the anaconda installer Fedora 10 says 'X failed to start reverting back to text mode Thoughts? anyone have any hp experience similar they can share (hopefully with solutions)? Thanks in advance Well I've had this problem beforebut it wasn't on HP and it wasn't recent enough for me to recall anything other than I completed the install in text mode and then found/fixed the issue later. Basicallylogging in in text mode, give a startx, and looking in /var/log/Xorg.0.log to find out what went wrong and fixing it Anaconda did not find a suitable driver. It's happened before on other systems. Do as Ed recommends and complete the text mode installation. Before you go slogging through the log files do the following: yum upgrade yum install system-config-display system-config-display --reconfig It's late and I'm not thinking as clearly as I should be. The best reference is the F11 Installation Guide: http://docs.fedoraproject.org/install-guide/f11/en-US/html-single/#d0e6884 Go to 8.2.1. Problems with Booting into the Graphical Installation -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: X wont start for install on an hp pavilion HDX-16 1370us
Kam Leo wrote: Anaconda did not find a suitable driver. It's happened before on other systems. Do as Ed recommends and complete the text mode installation. Before you go slogging through the log files do the following: yum upgrade yum install system-config-display system-config-display --reconfig It's late and I'm not thinking as clearly as I should be. The best reference is the F11 Installation Guide: http://docs.fedoraproject.org/install-guide/f11/en-US/html-single/#d0e6884 Go to 8.2.1. Problems with Booting into the Graphical Installation At least someone reads the documentation :-) -- If food be the music of love, eat up, eat up. mei-mei.gres...@greshko.com Guess Who! http://tinyurl.com/krh5ac signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: So far I am not impressed with F11
On 09/02/2009 01:38 PM, Randall J. Berry wrote: So far F11 has been nothing short of a pain for me. I have had more issues with this one release than I have for all of the preceding releases combined. Next comes the issues with streaming audio or video. Since the update of Firefox 3.1 to 3.1.1 all streaming media (youtube and the like) played through the browser crashes at random points within the stream usually locking up the browser for a period of time and the audio/video does not return to normal. I tried to uninstall Firefox 3.1.1 and reinstall Firefox 3.1 but that did not work Firefox simply ceased to work. Streaming video was crashing for me too. After trying the different plugins (Adobe flash, swfdec, xine-plugin) rolling back the nspluginwrapper to version 1.3.0-5 fixed the problem. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Fedora 11 boot fails on md with two HBAs
[Fixed typo in header line, etc.; added info at end.] With Fedora 11 on IBM x3650 M2 (x86_64), I am having problems booting after adding a second, add-in, SAS controller with 12 SAS disks in an external enclosure. Without the add-in SAS controller, the system boots fine and provides file sharing over samba, etc. The main problem with this machine is that it has an EFI BIOS which appears to bind the external/add-on SAS HBA before the internal one on which the system drives are hosted (they are both LSI SAS 3801e HBAs - the internal one has an IBM part number, while the external one is LSI). Changing the BIOS order in the option ROMs and disabling boot services on the external/add-on HBA does not seem to affect the adapter binding order, and the EFI BIOS does not provide any mechanism for controlling this. Which brings us to the bootup issues. Note that after booting into rescue mode from the installer image mdadm works as expected, with raid arrays detected and started without any problems on the disks located on both controllers. The md configuration is : /boot is on /dev/md0 with devices /dev/sd[mn]3, raid1 /root is on /dev/md1 with devices /dev/sd[op]1, raid1 /usr, /var and swap are on an LVM vg on /dev/md2 with devices /dev/sd[m-p]2, raid10 /boot/efi is on /dev/md64 with devices /dev/sd[mn]2, raid1 A separate vg for the data volume is on /dev/md127 with devices /dev/sd[a-l], raid6 (whole disks) /dev/sd[m-p] are hosted on the internal HBA, and appear as /dev/sd[a-d] when the add-in HBA is disabled. /dev/sd[a-l] hang of the add-in HBA. Note that in rescue mode, the disks start at /dev/sdc, as I'm booting from a virtual console, and /dev/sda and /dev/sdb are assigned to virtual USB disks. The problem seems to be that during bootup the raid arrays are autodetected rather than using mdadm. If the raid456 module is not included in the initrd image, booting fails with raid6 personality not detected, when the boot process tries to start /dev/md1 incrementally with /dev/sda as its first member. (This appears not to reference /etc/mdadm.conf in the initrd at all.) If the raid456 module is included in the initrd image (using --with=raid456), booting fails with /dev/sda added incrementally to /dev/md1 and /dev/sdb added incrementally to /dev/md2; it appears autodetect fails because the raid device was built from rescue mode, so the components are listed with different letters in the superblock. If I put a line in /etc/mdadm.conf in the initird image, to only scan partitioned disks (DEVICE /dev/sd*[1234]), boot hangs after loading the raid modules. (Potentially on the call to mkblkdevs after scsi_wait_scan is rmmod-ed.) Partitioning /dev/sd[a-l] and setting the partition type to other than 'raid' does not seem to make any difference, during bootup the kernel still tries to assemble the root raid device (/dev/md1) from /dev/sda (though it is on /dev/md[op]1. This seems to suggest that the md devices are being started by kernel raid autodetection rather than mdadm. Simply switching to mdamd would likely solve the problem, given it works fine in rescue mode. Alternative suggestions are welcome, of course. Thanks for the help, Murthy -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: problems posting
On 09/03/2009 02:25 PM, Paul Allen Newell wrote: Over the last 3 months, I noticed that I have posted and not gotten any responses. Fair enough, maybe the posts aren't worth it. But I just did a check of the archives and I don't see any of my posts. Don't know if I am incorrectly posting or, in worse case, blacklisted. So, I am sending out a test with the hopes that someone at least tells me that it was seen. I posted this on 27jul09 and didn't hear anything, so I dug in a bit deeper with my email provider and think I have it sorted out. So, I am cut-and-pasting (with the addition of this paragraph) and trying again. If no answer, then at least I have something to go back to the fedora-lists and/or my email provider to go huh? Thanks in advance, Paul Your post came thru, I read it I've had no luck contributing to the above address either. Roger -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Fedora11: Plans for updated mesa/xorg packages ?
Does anyone know if there is a plan to release updated xorg/mesa packages for F11 any time soon ? The F11 ones are very broken, at least for ATI radeon based systems. I have been using code from freedesktops git sources (drm,mesa,xf86-video-ati) and this is now getting there, at least blender works ! However, the changes needed to the stock F11 are now getting larger (xserver update) and it would be good to have an RPM based system again ! -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: So far I am not impressed with F11
On Thursday 03 September 2009 12:41 AM, s wrote: On 09/02/2009 01:38 PM, Randall J. Berry wrote: So far F11 has been nothing short of a pain for me. I have had more issues with this one release than I have for all of the preceding releases combined. Next comes the issues with streaming audio or video. Since the update of Firefox 3.1 to 3.1.1 all streaming media (youtube and the like) played through the browser crashes at random points within the stream usually locking up the browser for a period of time and the audio/video does not return to normal. I tried to uninstall Firefox 3.1.1 and reinstall Firefox 3.1 but that did not work Firefox simply ceased to work. Streaming video was crashing for me too. After trying the different plugins (Adobe flash, swfdec, xine-plugin) rolling back the nspluginwrapper to version 1.3.0-5 fixed the problem. Don't get me wrong, but I find people tend to stick to their old ways and bork up their system trying to do things they _think_ is the _right_ way to do just because they have been doing it that way for *a long* time. That doesn't mean something is broken. For starters, all this business about flash and multimedia, earlier ugly hacks like wrappers or binary w32 codecs were the _only_ way to go. But lately that is not the case. Modern linux distributions _do not_ require packages like libflashsupport or nspluginwrapper to meet the usual requirements of an user. Most of the time its these which cause the problem. If the people having problems could be more specific and descriptive about their problems then those of us with everything _just working_ could try to help. I for one have an almost perfect experience other than an unstable session manager for XFCE. This is what I have installed for my almost perfect setup: for multimedia, yum list installed \*gstreamer\* Loaded plugins: keys, presto, refresh-packagekit, verify Installed Packages gstreamer.x86_64 0.10.24-1.fc11 @updates gstreamer-ffmpeg.x86_64 0.10.8-1.fc11 @rpmfusion-free-updates gstreamer-plugins-bad.x86_64 0.10.13-6.fc11 @rpmfusion-free-updates gstreamer-plugins-bad-extras.x86_64 0.10.13-6.fc11 @rpmfusion-free-updates gstreamer-plugins-base.x86_64 0.10.23-3.fc11 @updates gstreamer-plugins-flumpegdemux.x86_64 0.10.15-6.fc11 installed gstreamer-plugins-good.x86_64 0.10.15-4.fc11 @updates gstreamer-plugins-schroedinger.x86_64 1.0.7-1.fc11@updates gstreamer-plugins-ugly.x86_64 0.10.12-2.fc11 @rpmfusion-free-updates gstreamer-python.x86_64 0.10.16-1.fc11 @updates gstreamer-tools.x86_640.10.24-1.fc11 @updates phonon-backend-gstreamer.x86_64 4.3.1-6.fc11@updates totem-gstreamer.x86_642.26.3-1.fc11 @updates yum list installed \*player\* Loaded plugins: keys, presto, refresh-packagekit, verify Installed Packages gecko-mediaplayer.x86_64 0.9.6-1.fc11 @rpmfusion-free-updates gnome-mplayer.x86_64 0.9.6-2.fc11 @rpmfusion-free-updates gnome-mplayer-common.x86_640.9.6-2.fc11 @rpmfusion-free-updates mplayer.x86_64 1.0-0.109.20090329svn.fc11 @rpmfusion-free mplayer-doc.x86_64 1.0-0.109.20090329svn.fc11 @rpmfusion-free yum list installed \*dirac\* Loaded plugins: keys, presto, refresh-packagekit, verify Installed Packages dirac.x86_64 1.0.2-2.fc11 @fedora dirac-libs.x86_641.0.2-2.fc11 @fedora As for flash, the only thing I have is the 64 bit plugin and it has never failed on me. lt /usr/lib64/mozilla/plugins/ total 9.6M lrwxrwxrwx. 1 root root 41 2009-06-04 16:42 libjavaplugin.so - /etc/alternatives/libjavaplugin.so.x86_64 -rwxr-xr-x. 1 root root 86K 2009-06-05 12:09 gecko-mediaplayer-wmp.so -rwxr-xr-x. 1 root root 86K 2009-06-05 12:09 gecko-mediaplayer.so -rwxr-xr-x. 1 root root 86K 2009-06-05 12:09 gecko-mediaplayer-rm.so -rwxr-xr-x. 1 root root 86K 2009-06-05 12:09 gecko-mediaplayer-qt.so -rwxr-xr-x. 1 root root 86K 2009-06-05 12:09 gecko-mediaplayer-dvx.so -rwxr-xr-x. 1 root root 6.6K 2009-07-10 06:57 librhythmbox-itms-detection-plugin.so -rwxr-xr-x. 1 root root 9.2M 2009-08-01 17:27 libflashplayer.so Hopefully I haven't come on too strong, but I am sick and tired of all the ranting in the recent months and hope that this will help someone get started towards a perfect setup on Fedora. PS: Even pulseaudio works here, it has worked almost flawlessly since F10. (don't ask me how tho) -- Suvayu Open source is the future. It sets us free. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines:
using ant-conrib.rpm
Hi, has anybody any idea how to use the ant-contrib.rpm? It sits there in /usr/share/java but ant reports an error on: taskdef resource=net/sf/antcontrib/antlib.xml/ Suggestions? Thanks Christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: So far I am not impressed with F11
Are you really up-to-date with your Fedora 11 system? Firefox is now at 3.5.2 and you are talking about 3.1.1. You might want to look into that. I'm using Firefox 3.5.2 on Fedora 11 x86_64 and have no problems with YouTube. I watch YouTube and Vimeo videos just fine. If your system is behind on updates, I recommend doing a full update. If you are worried about the size of updates, install yum-presto first and then do a full update. Presto will download much smaller *.drpm packages if possible for your base of installed packages. Are you sure your sound hardware is plugged in and really working? For example you don't have a stereo jack that's not all the way in? It is very easy to overlook hardware issues and blame it all on the software. Bob On 09/02/2009 02:38 PM, Randall J. Berry wrote: So far F11 has been nothing short of a pain for me. I have had more issues with this one release than I have for all of the preceding releases combined. The issues begin with sound, at any given moment for apparently no reason all sound including system sounds turn to static. This has been an issue since day one of my fresh install of F11 and I have yet to find a reason for it. I also had the same issue with F10 which is why I skipped F10 on the machine in question and waited for F11. I have asked countless times for help on this issue and gotten no feedback I can't be the only person having this trouble. The only cure is a reboot and even then it's only a temporary fix because its sure to happen again even after periods of time when the computer has been left idle doing nothing. Next comes the issues with streaming audio or video. Since the update of Firefox 3.1 to 3.1.1 all streaming media (youtube and the like) played through the browser crashes at random points within the stream usually locking up the browser for a period of time and the audio/video does not return to normal. I tried to uninstall Firefox 3.1.1 and reinstall Firefox 3.1 but that did not work Firefox simply ceased to work. Then comes the issues with the power save feature. After the specified idle time when the monitor goes to sleep it will not come back with any activity via the mouse or keyboard. The only solution seems to be a blind reboot. Defeating all power saving features is the only work around for this issue. Not a fix, but at least the system is still functional. And last but not least the most recent issue which began last night when rebooting due to the previously mentioned sound issue. Which is that at random gnome panel now refuses to load on user accounts. The system reboots to a normal desktop except no system tray and any panel function ceases to operate leaving the desktop virtually unusable. I have done nothing to the system that would cause this to happen. I'm at my wits end with F11 as I seem to be the only one with these issues. If anyone has any idea what is going on please feel free to fill me in. I'll gladly file bugs if I knew what to file the bugs against but so far these issues appear without leaving any trace as to why. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: So far I am not impressed with F11
2009/9/3 s skell...@swbell.net: On 09/02/2009 01:38 PM, Randall J. Berry wrote: So far F11 has been nothing short of a pain for me. I have had more issues with this one release than I have for all of the preceding releases combined. Next comes the issues with streaming audio or video. Since the update of Firefox 3.1 to 3.1.1 all streaming media (youtube and the like) played through the browser crashes at random points within the stream usually locking up the browser for a period of time and the audio/video does not return to normal. I tried to uninstall Firefox 3.1.1 and reinstall Firefox 3.1 but that did not work Firefox simply ceased to work. Streaming video was crashing for me too. After trying the different plugins (Adobe flash, swfdec, xine-plugin) rolling back the nspluginwrapper to version 1.3.0-5 fixed the problem. For what it's worth I've had no crash problems running F11 64bit with the Adobe 64bit beta plugin (search the Adobe site for 64bit flash). Songbird crashes, but that's not really worrying me at the minute. -- imalone -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Question on shredding a terebyte drive
After reading the entire thread, and watching the video, here is what I'd do. Put the drive in a safe. Go buy a new drive, and make use of it. Drop the warranty claim even though it is valid. The company will save money in the end. In about 10 years, or whenever the corporate data on the drive is deemed obsolete and nonsensitive, hold a Corporate Smash Day in which this drive and others are given to budding young technologists supplied with sledgehammers and other tools. Offer an all-expenses paid dinner to whoever reduces the drives to the smallest pieces. Bob On 09/02/2009 04:32 PM, Dean S. Messing wrote: I have a terebyte sata drive that I need to securely wipe clean. It originally had 2 partitions. I deleted them using `fdisk', rebooted, and then as root ran shred -vz /dev/sdd The drive is capable of about 60MB/sec, but shred is only shredding about 25MB every 5 seconds according to its output. Since the default number of passes is 25, this works out to about 5 days. The `shred' process is running at 100% CPU, presumably computing the special random patterns for erasure. Since I have 4 CPUs would creating 4 unformatted partions on the drive and then running something like: shred -vz /dev/sdd1 shred -vz /dev/sdd2 shred -vz /dev/sdd3 shred -vz /dev/sdd4 in parallel cut my time? Would be just as secure? Thanks Dean -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Unable to install libX11
Hey i found that two files in /etc/yum.repos.d which are adobe-linux-i386.repo and yum-iisc-f11.repo. Also try looking in the directory /etc/yum.repos.d/ Do you have the following two files there? fedora.repo fedora-updates.repo What are their contents? As the other responders said, you haven't shown us the real error yet. K.Srilatha Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com adobe-linux-i386.repo Description: Binary data yum-iisc-f11.repo Description: Binary data -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: X wont start for install on an hp pavilion HDX-16 1370us
I had a similar problem with my HP S3707c desktop (GeForce 9100M graphics). Ended up booting into text mode with kernel parameter nouveau.modeset=0, logged in as root (no password), ran Xorg -configure, edited the resulting file to use the vesa driver and copied it to /etc/X11/xorg.conf, then ran startx. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: convert ico to svg or png
Gerhard Magnus Wed, 02 Sep 2009 14:20:42 -0700 Does anyone know a program for FC11 that will convert Windows icon files (.ico) into a format accepted by gnome (.svg or .png)? I asked nearly the same question recently on this list. I was suggested to use mogrify. It's a part of image-magick project (www.imagemagick.org). Works excellent! It is in fedora' repos. -- Hiisi. Registered Linux User #487982. Be counted at: http://counter.li.org/ -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Anyone using Skype on FC11 ?
until this actual attempt to use it, i had assumed it was open source. as its not, i dont expect i will use it; someone else had asked me to try it. i found most of my earlier issues were with install issues that weren't immediately obvious, now i seem to have sound via PA and i get no errors on a test call. i just want to verify i can make a call and will probly set it aside; i am not a supporter/user of closed source. thx for your time to reply, jackc... On 08/30/2009 01:24 AM, Tim wrote: On Fri, 2009-08-28 at 15:07 -0700, jack craig wrote: is the source open anywhere? It's a closed source application. That, and the various discovered nasties (never mind the ones that haven't, yet, been discovered, because it's closed source), are why it's not well regarded here. -- jack craig ja...@linuxlighthouse.com 831-684-1375 (Office) 831-596-6924 (cell) IM: jackcraigaptos (AIM) _ This email has been ClamScanned ! www.LinuxLightHouse.com -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Fw: Unable to install libX11
Thanks for the suggestions. Hey i found two files in /etc/yum.repos.d which are adobe-linux-i386.repo and yum-iisc-f11.repo which has contents which iam attaching here. In response to your suggestion, I tried copying even fedora.repo and fedora-updates.repo also which iam attaching here. I tried now installing using yum install libX11-devel\* but there is no progress. It got stuck in refresh-package-list. I copied the libX11 packages into /var/cache/yum/updates/packages. Thanks in advance K.Srilatha See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com adobe-linux-i386.repo Description: Binary data yum-iisc-f11.repo Description: Binary data fedora.repo Description: Binary data fedora-updates.repo Description: Binary data -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Chrome-Fedora People
On Tue, 2009-09-01 at 22:58 -0400, Kevin J. Cummings wrote: On 09/01/2009 10:24 PM, Patrick O'Callaghan wrote: On Tue, 2009-09-01 at 21:16 -0400, Jim wrote: ... That worked for me, but when I try to view video it claims that Flash is not installed, which it is (64-bit Adobe version). There doesn't appear to be a way to configure this. Using x86_64 + flashplayer 64bits -beta-, worked this way: # ln -s /usr/lib64/mozilla/plugins/* /usr/lib64/chromium-browser/plugins Check the about:config URL. -- Rodolfo Alcazar - rodolfo.alca...@padep.org.bo otbits.blogspot.com / counter.li.org: #367962 -- -- The time you enjoy wasting is not wasted time. Bertrand Russell -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
kmail eating my maildir???
Hi guys, I recently tried KDE 4.3 and despite some gfx performance flaws this one got me screaming: I installed kdepim 4.3 and run kmail, setup my maildir as inbox and the first thing I noticed: All mails were new, odd I thought and wanted to take a look at my maildir via mutt. To my surprise: My INBOX was empty now. RGHH. ALL MAILS GONE! Is this really the way to go? Is there no way to keep a sync between the maildir and akonadi? regards, Christoph ps: sent by mutt ;) -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Fedora update using preugrade with 2 arch.
Hi, Is it safe to preupgrade a F7 32 bits to a F11 64 bits ? BR -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Fedora update using preugrade with 2 arch.
Luc MAIGNAN wrote: Hi, Is it safe to preupgrade a F7 32 bits to a F11 64 bits ? BR All I know is I wouldn't do it Not only is F7--F11 a big jump in and of itself...but trying to go from 32 ~ 64 bits would certainly add to the complexity to the point of likely utter disaster -- I request a weekend in Havana with Phil Silvers! Guess Who! http://tinyurl.com/krh5ac signature.asc Description: OpenPGP digital signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Fedora update using preugrade with 2 arch.
On 09/03/2009 06:10 PM, Luc MAIGNAN wrote: Hi, Is it safe to preupgrade a F7 32 bits to a F11 64 bits ? No. Backup your data and do a fresh installation. Rahul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: problems posting
Roger wrote: On 09/03/2009 02:25 PM, Paul Allen Newell wrote: Over the last 3 months, I noticed that I have posted and not gotten any responses. Fair enough, maybe the posts aren't worth it. But I just did a check of the archives and I don't see any of my posts. Don't know if I am incorrectly posting or, in worse case, blacklisted. So, I am sending out a test with the hopes that someone at least tells me that it was seen. I posted this on 27jul09 and didn't hear anything, so I dug in a bit deeper with my email provider and think I have it sorted out. So, I am cut-and-pasting (with the addition of this paragraph) and trying again. If no answer, then at least I have something to go back to the fedora-lists and/or my email provider to go huh? Thanks in advance, Paul Your post came thru, I read it I've had no luck contributing to the above address either. Roger Thanks for confirm that I've got the email address sorted out -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Fedora11: Plans for updated mesa/xorg packages ?
On 09/03/2009 01:34 PM, Terry Barnaby wrote: Does anyone know if there is a plan to release updated xorg/mesa packages for F11 any time soon ? The F11 ones are very broken, at least for ATI radeon based systems. I have been using code from freedesktops git sources (drm,mesa,xf86-video-ati) and this is now getting there, at least blender works ! However, the changes needed to the stock F11 are now getting larger (xserver update) and it would be good to have an RPM based system again ! Do you have bugzilla numbers so we know what breakage you are talking about? Rahul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Removing Gnome from F11
On 09/03/2009 08:56 AM, john wendel wrote: I'm happily using LXDE on my F11 system, and I thought I'd remove Gnome, using yum remove gnome\*. Well, it was not to be. Yum decide to remove parts of LXDE, Firefox, Thunderbird, Java, abiword, most of the system admin utilities, and about 50 other programs that I would think have nothing to do with Gnome. Am I stupid or what? Why would Fedora's Firefox have a Gnome dependency when I'm sure that the Mozilla version doesn't? Are these real dependencies or packaging artifacts? I don't think I like this disto as much as I once did. Firefox uses GNOME VFS in Fedora. It can be disabled however that would would mean reduced functionality. Rahul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Unable to install libX11
On Thu, 3 Sep 2009 17:11:14 +0530 (IST), SriLatha wrote: Hey i found that two files in /etc/yum.repos.d which are adobe-linux-i386.repo and yum-iisc-f11.repo. Have you talked to the IISC guys yet? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Removing Gnome from F11
On Wed, 2009-09-02 at 20:26 -0700, john wendel wrote: I'm happily using LXDE on my F11 system, and I thought I'd remove Gnome, using yum remove gnome\*. Well, it was not to be. Yum decide to remove parts of LXDE, Firefox, Thunderbird, Java, abiword, most of the system admin utilities, and about 50 other programs that I would think have nothing to do with Gnome. Am I stupid or what? Why would Fedora's Firefox have a Gnome dependency when I'm sure that the Mozilla version doesn't? Are these real dependencies or packaging artifacts? I don't think I like this disto as much as I once did. John Have you tried: yum groupremove GNOME Desktop Environment -- === If it doesn't smell yet, it's pretty fresh. -- Dave Johnson, on dead seagulls === Aaron Konstam telephone: (210) 656-0355 e-mail: akons...@sbcglobal.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
So, how are the laptops (MBP, W500, XPS 16)?
I'm contemplating a laptop purchase and my current top three candidates are a MBP 17, Lenovo W500 (WUXGA/ATI Mobility FireGL V5700 (512MB)), and a Dell XPS 16 (1080p/ATI Mobility RADEON HD 4670 (1G)). I get the impression -- were I to go with the Lenovo or Dell -- that I'm pretty much stuck with the 2D radeon drivers, which seems a shame (I confess I like Compiz). Can anyone comment on their experiences with these laptops? o How well does video work? o Sound? o Sleep/resume? o Fan noise? My only two data points are the T61p I tried (shortly after Hardy Heron released; back then, they were using an NVIDIA card) and my wife's MBP. Hardy Heron wanted to run the T61p's (loud) fan constantly and sleep/resume, when it worked, took forever (over a minute to re-establish wireless connectivity). I found it unusable next to my wife's MBP which is generally quiet, resumes instantly, and rarely gets rebooted (despite both of us being constantly logged onto it). I'm hoping to hear that Linux has come a long way since my last attempt and would work well with either the Lenovo or the Dell. But, if ATI is still to be avoided, does anyone have have any experience with The Beast (Lenovo W700), which ships with an NVIDIA card? Seems too big, but I'll bet the screen is much nicer than the almost-too-dim W500's. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Removing Gnome from F11
On 09/02/2009 11:26 PM, john wendel wrote: I'm happily using LXDE on my F11 system, and I thought I'd remove Gnome, using yum remove gnome\*. Well, it was not to be. Yum decide to remove parts of LXDE, Firefox, Thunderbird, Java, abiword, most of the system admin utilities, and about 50 other programs that I would think have nothing to do with Gnome. That's going to remove a whole ton of stuff. I don't find it terribly surprising that it ends up removing firefox. In any event, the reason firefox gets removed is it depends upon xulrunner, which depends upon gnome-vfs2. (I found this out using yum deplist ) Why exactly we have that dependency, I do not know. I'll guess that the same is true for Thunderbird. And isn't abiword specifically a wp for Gnome? The system-* packages often depend upon gnome-python2-gnomekeyring. This is not surprising. These are Fedora programs, and Fedora is, and long has been, a Gnome-centric distribution. Those of us who use it with KDE or some other desktop/wm have to live with that. Am I stupid or what? Why would Fedora's Firefox have a Gnome dependency when I'm sure that the Mozilla version doesn't? Are these real dependencies or packaging artifacts? The Mozilla version is probably statically compiled, for one thing. rh -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
volume is erratic in Rhythmbox
sometimes volume is erratic in Rhythmbox, when I connect to a radio stream slide goes to zero!!! and sometimes it doesn't remember volume setting from a session to the next. anyone experiencing same behaviour??? Latest packages are in use -- Antonio Montagnani Skype : antoniomontag SIP: antoniomon...@ekiga.net -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Getting to grips with Plasma
If KDE 4 still feels strange to you, UserBase now has a treat in store. Hans (aka Mogger, on IRC) has created a whole set of short looping screencasts that show you exactly how to do all the common tasks associated with Plasma - covering desktop and panel widgets, extenders and activities. Each one lasts only a few seconds, but because it loops you have plenty of time to see exactly what is happening. Find them at http://userbase.kde.org/Plasma/FAQ/HowTo In case you didn't already know, there are already http://userbase.kde.org/Plasma #a general introduction http://userbase.kde.org/Plasma/FAQ #now updated to 4.3 http://userbase.kde.org/Plasma/Plasmoids#a few of our favourite plasmoids. Why not add your favourites? Anne -- New to KDE4? - get help from http://userbase.kde.org Just found a cool new feature? Add it to UserBase signature.asc Description: This is a digitally signed message part. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: kmail eating my maildir???
On Thursday 03 September 2009 13:39:36 Christoph Höger wrote: Hi guys, I recently tried KDE 4.3 and despite some gfx performance flaws this one got me screaming: I installed kdepim 4.3 and run kmail, setup my maildir as inbox and the first thing I noticed: All mails were new, odd I thought and wanted to take a look at my maildir via mutt. To my surprise: My INBOX was empty now. RGHH. ALL MAILS GONE! Is this really the way to go? Is there no way to keep a sync between the maildir and akonadi? Are you using standard packages? I have three installations all running KDE 4.3, and all using KMail to access IMAP mail. I have no such problem, so the question is, what is different about your install? Anne -- New to KDE4? - get help from http://userbase.kde.org Just found a cool new feature? Add it to UserBase signature.asc Description: This is a digitally signed message part. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Fedora 11: no display after init sequence
Hello there, after I upgraded from Fedora 10 to 11 using yum preupgrade (as proposed by the daily process that checks for upgrades in GNOME), display in X.org doesn't work anymore. My guess is that it's a video/display issue, directly or indirectly, because the system is responding, meaning I can login in gdm in blind mode using the keyboard (I got confirmation by reading /var/log/0-slave.log) but the display is not updated after the loading process with the Fedora logo. If I boot up in init 2 mode then switch to init 5, I get a blank screen with a still cursor in top/left corner. I tried booting with xdriver=vesa as kernel param, same problem. I changed my xorg.conf to use the vesa driver instead of the intel one, same problem, with a variant: the blue screen with Fedora logo shows corrupted. I tried both Option NoAccel True Option DRI False in xorg.conf (file attached), same problem. I tried `X -configure` then `X -config /root/xorg.conf.new`, same problem (file attached). When the display is not responding, I cannot switch back to a tty using ctrl+alt+Fn key combinations, meaning I have to reboot each time I want to try a different X.org config param. Nothing looked suspicious to my eyes in /var/log/messages or in /var/log/Xorg.0.log (attached). Hardware is a Dell Latitude E6500 with Intel chip and a WUXGA display (1920x1200). I also attached the output of `lspci -vv` and `lsmod|sort`. The system is up-to-date (yum), with correct Fedora 11 repositories shown then I run `yum repolist`. This is a production laptop and I critically need it to be usable quickly. I've made a complete backup of the system while it was still running Fedora 10. In last resort I can rollback to the backup, but well.. this is not my preferred option at all. Any help? What could I check or try? Regards -- wwp xorg.conf Description: Binary data xorg.conf.new Description: Binary data X.Org X Server 1.6.3 Release Date: 2009-7-31 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-128.4.1.el5 i686 Current Operating System: Linux monolith 2.6.30.5-43.fc11.i686.PAE #1 SMP Thu Aug 27 21:34:36 EDT 2009 i686 Kernel command line: ro root=UUID=045fd764-aead-4d18-8257-2f97c08b3e93 rhgb quiet Build Date: 19 August 2009 12:30:16AM Build ID: xorg-x11-server 1.6.3-4.fc11 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Thu Sep 3 09:03:22 2009 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout single head configuration (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Videocard0 (**) |--Input Device Keyboard0 (**) Option DontZap false (==) Automatically adding devices (==) Automatically enabling devices (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) Cannot locate a core pointer device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Keyboard0 (II) Loader magic: 0xa40 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (++) using VT number 1 (--) PCI:*(0:0:2:0) 8086:2a42:1028:024f Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7, Mem @ 0xf6c0/4194304, 0xe000/268435456, I/O @ 0xef98/8, BIOS @ 0x/131072 (II) No APM support in BIOS or kernel (II) System resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.6.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.6.3, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension
Re: Fedora11: Plans for updated mesa/xorg packages ?
On 09/03/2009 02:11 PM, Rahul Sundaram wrote: On 09/03/2009 01:34 PM, Terry Barnaby wrote: Does anyone know if there is a plan to release updated xorg/mesa packages for F11 any time soon ? The F11 ones are very broken, at least for ATI radeon based systems. I have been using code from freedesktops git sources (drm,mesa,xf86-video-ati) and this is now getting there, at least blender works ! However, the changes needed to the stock F11 are now getting larger (xserver update) and it would be good to have an RPM based system again ! Do you have bugzilla numbers so we know what breakage you are talking about? Rahul There are a large number of ATI R200/R300/R500 bugs listed in Freedesktop's bugzilla. Two that I have had dealings with are: 21774 and 23232, however due to heavy development in the xorg/mesa packages there are a lot more than that. Before using the git sources for drm/mesa,xf86-video-ati I had various crashes, hangs, system lockups and pixel errors on the screen on both R300 and R200 based systems. I think it is the same for Intel graphics as well. I don't like using raw git/non RPM code on my systems, but, without the git xorg/mesa code F11 is unworkable for me. Unfortunately the bug, 23232, requires a more recent XOrg XServer. This has heavy system dependencies and would require me to do a lot of work in building many packages right down to OpenSSL ... It seems, to me, that the XOrg/Mesa code has got a lot better since the code F11 was based on and a F11 update is due. It would certainly help me and many others ... Cheers Terry -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: kmail eating my maildir???
Am Donnerstag, den 03.09.2009, 14:47 +0100 schrieb Anne Wilson: On Thursday 03 September 2009 13:39:36 Christoph Höger wrote: Hi guys, I recently tried KDE 4.3 and despite some gfx performance flaws this one got me screaming: I installed kdepim 4.3 and run kmail, setup my maildir as inbox and the first thing I noticed: All mails were new, odd I thought and wanted to take a look at my maildir via mutt. To my surprise: My INBOX was empty now. RGHH. ALL MAILS GONE! Is this really the way to go? Is there no way to keep a sync between the maildir and akonadi? Are you using standard packages? I have three installations all running KDE 4.3, and all using KMail to access IMAP mail. I have no such problem, so the question is, what is different about your install? I am using no IMAP. This is a plain Maildir. I simply have my mails inside a good old maildir - which is emptied by KMail. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: volume is erratic in Rhythmbox
2009/9/3 Antonio M antonio.montagn...@gmail.com: sometimes volume is erratic in Rhythmbox, when I connect to a radio stream slide goes to zero!!! and sometimes it doesn't remember volume setting from a session to the next. anyone experiencing same behaviour??? Latest packages are in use I have the same issue. Sometimes it chooses a volume level of its own accord and stubbornly reverts back to it whenever it feels like it (usually after un-pausing or skipping a song). The chosen level is usually somewhere just above the level I want. The above refers to the main volume control in Gnome. The volume control in Rhythmbox is weirder still. It usually shows itself at zero, but if I nudge it up any amount at all, it pushes the main volume up way too high. So I leave it alone. -- Regards, Derek -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
