From jonstanley at gmail.com Sun Jun 1 02:16:01 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 31 May 2008 22:16:01 -0400 Subject: corrupt rpmdb in mock-chroot In-Reply-To: <1212275069.3635.62.camel@localhost.localdomain> References: <1212275069.3635.62.camel@localhost.localdomain> Message-ID: On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder wrote: > > Rebuilding the rpm database seems to fix this, but it's a pain to be > sure. Any ideas as to why I'm seeing this corruption when creating an > i386 mock chroot from a x86_64 system? This is normal and expected. You created the rpmdb with x86_64 rpm, and are accessing it with i386 rpm. The Berkeley DB format is different based on the arch of the creating machine, therefore generates the database differently on the two platforms. If I plan on doing anything in a chroot (especially a non-native arch one) other than building a SRPM, the first thing that happens is to rm -f /var/lib/rpm/__db*. Don't worry, this got me the first time too (and is fatal to a pungi compose) :) From paul.schroeder at bluecoat.com Mon Jun 2 12:19:50 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 02 Jun 2008 07:19:50 -0500 Subject: corrupt rpmdb in mock-chroot In-Reply-To: References: <1212275069.3635.62.camel@localhost.localdomain> Message-ID: <1212409190.3635.66.camel@localhost.localdomain> On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: > On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder > wrote: > > > > > Rebuilding the rpm database seems to fix this, but it's a pain to be > > sure. Any ideas as to why I'm seeing this corruption when creating an > > i386 mock chroot from a x86_64 system? > > This is normal and expected. You created the rpmdb with x86_64 rpm, > and are accessing it with i386 rpm. The Berkeley DB format is > different based on the arch of the creating machine, therefore > generates the database differently on the two platforms. If I plan on > doing anything in a chroot (especially a non-native arch one) other > than building a SRPM, the first thing that happens is to rm -f > /var/lib/rpm/__db*. Don't worry, this got me the first time too (and > is fatal to a pungi compose) :) Ah.. I see.. I would think there would be some way to tell it to create the DB in i386 format though? Is there an environment variable or something that can be set? From dennis at ausil.us Mon Jun 2 13:25:39 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 2 Jun 2008 08:25:39 -0500 Subject: corrupt rpmdb in mock-chroot In-Reply-To: <1212409190.3635.66.camel@localhost.localdomain> References: <1212275069.3635.62.camel@localhost.localdomain> <1212409190.3635.66.camel@localhost.localdomain> Message-ID: <200806020825.48643.dennis@ausil.us> On Monday 02 June 2008, Paul B Schroeder wrote: > On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: > > On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder > > > > wrote: > > > Rebuilding the rpm database seems to fix this, but it's a pain to be > > > sure. Any ideas as to why I'm seeing this corruption when creating an > > > i386 mock chroot from a x86_64 system? > > > > This is normal and expected. You created the rpmdb with x86_64 rpm, > > and are accessing it with i386 rpm. The Berkeley DB format is > > different based on the arch of the creating machine, therefore > > generates the database differently on the two platforms. If I plan on > > doing anything in a chroot (especially a non-native arch one) other > > than building a SRPM, the first thing that happens is to rm -f > > /var/lib/rpm/__db*. Don't worry, this got me the first time too (and > > is fatal to a pungi compose) :) > > Ah.. I see.. I would think there would be some way to tell it to > create the DB in i386 format though? Is there an environment variable > or something that can be set? No, the hosts rpm is used to populate the chroot. when you enter the chroot you can delete /var/lib/rpm/__db* and things will work. You get the same issues with building say F-7 chroots on a F-9 host where the chroot has a different version of the the database than the host. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From paul.schroeder at bluecoat.com Mon Jun 2 13:46:58 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 02 Jun 2008 08:46:58 -0500 Subject: corrupt rpmdb in mock-chroot In-Reply-To: <200806020825.48643.dennis@ausil.us> References: <1212275069.3635.62.camel@localhost.localdomain> <1212409190.3635.66.camel@localhost.localdomain> <200806020825.48643.dennis@ausil.us> Message-ID: <1212414418.3635.76.camel@localhost.localdomain> On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote: > On Monday 02 June 2008, Paul B Schroeder wrote: > > On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: > > > On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder > > > > > > wrote: > > > > Rebuilding the rpm database seems to fix this, but it's a pain to be > > > > sure. Any ideas as to why I'm seeing this corruption when creating an > > > > i386 mock chroot from a x86_64 system? > > > > > > This is normal and expected. You created the rpmdb with x86_64 rpm, > > > and are accessing it with i386 rpm. The Berkeley DB format is > > > different based on the arch of the creating machine, therefore > > > generates the database differently on the two platforms. If I plan on > > > doing anything in a chroot (especially a non-native arch one) other > > > than building a SRPM, the first thing that happens is to rm -f > > > /var/lib/rpm/__db*. Don't worry, this got me the first time too (and > > > is fatal to a pungi compose) :) > > > > Ah.. I see.. I would think there would be some way to tell it to > > create the DB in i386 format though? Is there an environment variable > > or something that can be set? > > No, the hosts rpm is used to populate the chroot. when you enter the chroot > you can delete /var/lib/rpm/__db* and things will work. > You get the same issues with building say F-7 chroots on a F-9 host where the > chroot has a different version of the the database than the host. > I understand how it's working. (Although, I didn't know Berkely DB had diff formats for diff archs beforehand) But I was hoping there might be a way (in my Makefiles) to tell my x86_64 host's rpm to always operate in i386 mode. I can live with it, but I am setting up a build environment for other (read less Linux literate) folks to use. I'd like to head off any forthcoming confusion if possible. Cheers...Paul... From dennis at ausil.us Mon Jun 2 14:11:49 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 2 Jun 2008 09:11:49 -0500 Subject: corrupt rpmdb in mock-chroot In-Reply-To: <1212414418.3635.76.camel@localhost.localdomain> References: <1212275069.3635.62.camel@localhost.localdomain> <200806020825.48643.dennis@ausil.us> <1212414418.3635.76.camel@localhost.localdomain> Message-ID: <200806020911.55999.dennis@ausil.us> On Monday 02 June 2008, Paul B Schroeder wrote: > On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote: > > On Monday 02 June 2008, Paul B Schroeder wrote: > > > On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: > > > > On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder > > > > > > > > wrote: > > > > > Rebuilding the rpm database seems to fix this, but it's a pain to > > > > > be sure. Any ideas as to why I'm seeing this corruption when > > > > > creating an i386 mock chroot from a x86_64 system? > > > > > > > > This is normal and expected. You created the rpmdb with x86_64 rpm, > > > > and are accessing it with i386 rpm. The Berkeley DB format is > > > > different based on the arch of the creating machine, therefore > > > > generates the database differently on the two platforms. If I plan > > > > on doing anything in a chroot (especially a non-native arch one) > > > > other than building a SRPM, the first thing that happens is to rm -f > > > > /var/lib/rpm/__db*. Don't worry, this got me the first time too (and > > > > is fatal to a pungi compose) :) > > > > > > Ah.. I see.. I would think there would be some way to tell it to > > > create the DB in i386 format though? Is there an environment variable > > > or something that can be set? > > > > No, the hosts rpm is used to populate the chroot. when you enter the > > chroot you can delete /var/lib/rpm/__db* and things will work. > > > > You get the same issues with building say F-7 chroots on a F-9 host where > > the chroot has a different version of the the database than the host. > > I understand how it's working. (Although, I didn't know Berkely DB had > diff formats for diff archs beforehand) But I was hoping there might be > a way (in my Makefiles) to tell my x86_64 host's rpm to always operate > in i386 mode. > > I can live with it, but I am setting up a build environment for other > (read less Linux literate) folks to use. I'd like to head off any > forthcoming confusion if possible. > > Cheers...Paul... Please dont CC me on list email just "reply to list" you could try run setarch i386 before the mock command. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From paul.schroeder at bluecoat.com Mon Jun 2 17:47:09 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 02 Jun 2008 12:47:09 -0500 Subject: corrupt rpmdb in mock-chroot In-Reply-To: <200806020911.55999.dennis@ausil.us> References: <1212275069.3635.62.camel@localhost.localdomain> <200806020825.48643.dennis@ausil.us> <1212414418.3635.76.camel@localhost.localdomain> <200806020911.55999.dennis@ausil.us> Message-ID: <1212428829.3635.128.camel@localhost.localdomain> On Mon, 2008-06-02 at 09:11 -0500, Dennis Gilmore wrote: > On Monday 02 June 2008, Paul B Schroeder wrote: > > On Mon, 2008-06-02 at 08:25 -0500, Dennis Gilmore wrote: > > > On Monday 02 June 2008, Paul B Schroeder wrote: > > > > On Sat, 2008-05-31 at 22:16 -0400, Jon Stanley wrote: > > > > > On Sat, May 31, 2008 at 7:04 PM, Paul B Schroeder > > > > > > > > > > wrote: > > > > > > Rebuilding the rpm database seems to fix this, but it's a pain to > > > > > > be sure. Any ideas as to why I'm seeing this corruption when > > > > > > creating an i386 mock chroot from a x86_64 system? > > > > > > > > > > This is normal and expected. You created the rpmdb with x86_64 rpm, > > > > > and are accessing it with i386 rpm. The Berkeley DB format is > > > > > different based on the arch of the creating machine, therefore > > > > > generates the database differently on the two platforms. If I plan > > > > > on doing anything in a chroot (especially a non-native arch one) > > > > > other than building a SRPM, the first thing that happens is to rm -f > > > > > /var/lib/rpm/__db*. Don't worry, this got me the first time too (and > > > > > is fatal to a pungi compose) :) > > > > > > > > Ah.. I see.. I would think there would be some way to tell it to > > > > create the DB in i386 format though? Is there an environment variable > > > > or something that can be set? > > > > > > No, the hosts rpm is used to populate the chroot. when you enter the > > > chroot you can delete /var/lib/rpm/__db* and things will work. > > > > > > You get the same issues with building say F-7 chroots on a F-9 host where > > > the chroot has a different version of the the database than the host. > > > > I understand how it's working. (Although, I didn't know Berkely DB had > > diff formats for diff archs beforehand) But I was hoping there might be > > a way (in my Makefiles) to tell my x86_64 host's rpm to always operate > > in i386 mode. > > > > I can live with it, but I am setting up a build environment for other > > (read less Linux literate) folks to use. I'd like to head off any > > forthcoming confusion if possible. > > > > Cheers...Paul... > > Please dont CC me on list email just "reply to list" > Oops.. Apologies.. > you could try run setarch i386 before the mock command. > Yea.. I tried that one already.. Didn't work. From ob.system at gmail.com Thu Jun 5 23:14:15 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Thu, 5 Jun 2008 18:14:15 -0500 Subject: rsync Message-ID: <6a28481b0806051614m16112eadiac5a8d0afc08d00c@mail.gmail.com> Hi guys fedora have rsync for cvs.fedoraproject.org ? I need a copy of pkgs repositorye for svn+koji convertion (with cvs2svn) Thanks Oscar Calixto -------------- next part -------------- An HTML attachment was scrubbed... URL: From ob.system at gmail.com Thu Jun 5 23:27:10 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Thu, 5 Jun 2008 18:27:10 -0500 Subject: rsync In-Reply-To: <6a28481b0806051614m16112eadiac5a8d0afc08d00c@mail.gmail.com> References: <6a28481b0806051614m16112eadiac5a8d0afc08d00c@mail.gmail.com> Message-ID: <6a28481b0806051627m692ff35kf42395fd1ea60b83@mail.gmail.com> Hi guys fedora have rsync for cvs.fedoraproject.org ? > > I need a copy of pkgs repositorye for svn+koji convertion (with cvs2svn) > Because rsync rsync://cvs.fedoraproject/rpms/ /desdir do not work, but rsync rsync://cvs.fedoraproject.org/rpms it's works. Thanks Oscar -------------- next part -------------- An HTML attachment was scrubbed... URL: From ob.system at gmail.com Fri Jun 13 17:04:20 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Fri, 13 Jun 2008 12:04:20 -0500 Subject: CVS to SVN with Rsync Message-ID: <6a28481b0806131004n597fbc60q6c8cc7b40fae029@mail.gmail.com> Hi guys I need yuo help. How to convert CVS to SVN without a raw copy of fedora pkgs repository? I tried with rsync rsync://cvs.fedoraproject.org/pkgs cvs-backup but it's not work. I need a copy of pkgs repositorye for svn+koji (with cvs2svn). Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Fri Jun 13 19:45:31 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 13 Jun 2008 21:45:31 +0200 Subject: CVS to SVN with Rsync In-Reply-To: <6a28481b0806131004n597fbc60q6c8cc7b40fae029@mail.gmail.com> References: <6a28481b0806131004n597fbc60q6c8cc7b40fae029@mail.gmail.com> Message-ID: <4852CE5B.8070706@kanarip.com> Oscar Victorio Calixto Bacho wrote: > Hi guys > > I need yuo help. > > How to convert CVS to SVN without a raw copy of fedora pkgs repository? > > I tried with > rsync rsync://cvs.fedoraproject.org/pkgs > cvs-backup > Euh, how about: $ rsync -aHvz rsync://cvs.fedoraproject.org/pkgs/ cvs-backup -Jeroen From ob.system at gmail.com Fri Jun 13 22:02:32 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Fri, 13 Jun 2008 17:02:32 -0500 Subject: CVS to SVN with Rsync In-Reply-To: <4852CE5B.8070706@kanarip.com> References: <6a28481b0806131004n597fbc60q6c8cc7b40fae029@mail.gmail.com> <4852CE5B.8070706@kanarip.com> Message-ID: <6a28481b0806131502v39317899j6c96d895198f6cc8@mail.gmail.com> 2008/6/13 Jeroen van Meeuwen : > Oscar Victorio Calixto Bacho wrote: > >> Hi guys >> >> I need yuo help. >> >> How to convert CVS to SVN without a raw copy of fedora pkgs repository? >> >> I tried with >> rsync rsync://cvs.fedoraproject.org/pkgs < >> http://cvs.fedoraproject.org/pkgs> cvs-backup >> >> > Euh, how about: > > $ rsync -aHvz rsync://cvs.fedoraproject.org/pkgs/ cvs-backup > > -Jeroen > > the rsync version is 3.0.2 it's do not work, it stop in rpms/R-RScaLAPACK/FC-6/Attic/ Do I need acces write or SSH key (FAccount) for this command? thanks Oscar Bacho -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Sat Jun 14 00:06:46 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 14 Jun 2008 02:06:46 +0200 Subject: CVS to SVN with Rsync In-Reply-To: <6a28481b0806131502v39317899j6c96d895198f6cc8@mail.gmail.com> References: <6a28481b0806131004n597fbc60q6c8cc7b40fae029@mail.gmail.com> <4852CE5B.8070706@kanarip.com> <6a28481b0806131502v39317899j6c96d895198f6cc8@mail.gmail.com> Message-ID: <48530B96.9080708@kanarip.com> Oscar Victorio Calixto Bacho wrote: > it's do not work, > > it stop in rpms/R-RScaLAPACK/FC-6/Attic/ > If you restart the command after it fails does it continue (where it left off)? > Do I need acces write or SSH key (FAccount) for this command? > No you can check it out anonymously. -Jeroen From wacker at octothorp.org Sat Jun 14 05:52:09 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Fri, 13 Jun 2008 23:52:09 -0600 (MDT) Subject: Tonight's updates appear to have broken Pungi. Message-ID: Hi all, After tonight's updates, I do what I always do, pungify and post. This time, I got the following. Pungi.Gather:INFO: Adding repo fedora Pungi.Gather:INFO: URL for repo fedora is ['http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Everything/x86_64/os/'] Warning: Reusing existing destination directory. Traceback (most recent call last): File "/usr/bin/pungi", line 189, in main() File "/usr/bin/pungi", line 81, in main mygather = pypungi.gather.Gather(config, ksparser) File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 131, in __init__ if repo.priority: AttributeError: F8_RepoData instance has no attribute 'priority' Warning: Reusing existing destination directory. Traceback (most recent call last): File "/usr/bin/pungi", line 189, in main() File "/usr/bin/pungi", line 111, in main mypungi.doCreaterepo(comps=False) File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 137, in doCreaterepo self._makeMetadata(self.topdir, self.config.get('default', 'cachedir'), compsfile, repoview=True, repoviewtitle=repoviewtitle) File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 94, in _makeMetadata repomatic = createrepo.MetaDataGenerator(conf) File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 119, in __init__ self._test_setup_dirs() File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", line 149, in _test_setup_dirs raise MDError, _('Directory %s must exist') % mydir createrepo.utils.MDError: Directory /home/wacker/9/9/source/SRPMS must exi I'm guessing that it's either yum-utils or pykickstart. Any ideas TIA. Bill in Denver From jkeating at j2solutions.net Sat Jun 14 12:32:31 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 14 Jun 2008 08:32:31 -0400 Subject: Tonight's updates appear to have broken Pungi. In-Reply-To: References: Message-ID: <6EDF417D-2791-470D-8DEA-F281E8E79857@j2solutions.net> On Jun 14, 2008, at 1:52, "William F. Acker WB2FLW +1-303-722-7209" wrote: > Hi all, > > After tonight's updates, I do what I always do, pungify and > post. This time, I got the following. > Pungi.Gather:INFO: Adding repo fedora > Pungi.Gather:INFO: URL for repo fedora is ['http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Everything/x86_64/os/'] > Warning: Reusing existing destination directory. > Traceback (most recent call last): > File "/usr/bin/pungi", line 189, in > main() > File "/usr/bin/pungi", line 81, in main > mygather = pypungi.gather.Gather(config, ksparser) > File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line > 131, in __init__ > if repo.priority: > AttributeError: F8_RepoData instance has no attribute 'priority' > Warning: Reusing existing destination directory. > Traceback (most recent call last): > File "/usr/bin/pungi", line 189, in > main() > File "/usr/bin/pungi", line 111, in main > mypungi.doCreaterepo(comps=False) > File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 137, > in doCreaterepo > self._makeMetadata(self.topdir, self.config.get('default', > 'cachedir'), compsfile, repoview=True, repoviewtitle=repoviewtitle) > File "/usr/lib/python2.5/site-packages/pypungi/pungi.py", line 94, > in _makeMetadata > repomatic = createrepo.MetaDataGenerator(conf) > File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", > line 119, in __init__ > self._test_setup_dirs() > File "/usr/lib/python2.5/site-packages/createrepo/__init__.py", > line 149, in _test_setup_dirs > raise MDError, _('Directory %s must exist') % mydir > createrepo.utils.MDError: Directory /home/wacker/9/9/source/SRPMS > must exi I'm guessing that it's either yum-utils or > pykickstart. Any ideas > > Yeah, pykickstart changes. I'll put out a new pungi early next week. In the meantime, change "priority" to "cost" in the code. -- Jes From wacker at octothorp.org Sat Jun 14 23:16:36 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sat, 14 Jun 2008 17:16:36 -0600 (MDT) Subject: Tonight's updates appear to have broken Pungi. In-Reply-To: <6EDF417D-2791-470D-8DEA-F281E8E79857@j2solutions.net> References: <6EDF417D-2791-470D-8DEA-F281E8E79857@j2solutions.net> Message-ID: On Sat, 14 Jun 2008, Jesse Keating wrote: > Yeah, pykickstart changes. I'll put out a new pungi early next week. In the > meantime, change "priority" to "cost" in the code. That worked. Thanks. Now, for the next problem in the message to follow. -- Bill in Denver From wacker at octothorp.org Sat Jun 14 23:20:29 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sat, 14 Jun 2008 17:20:29 -0600 (MDT) Subject: Respinning cause both the old and new versions of NM to be included. Message-ID: Hi all, After last night's updates, we now get the original version of NetworkManager as well as the new one. I can't see what's pulling the old one in. At first, I thought it had something to do with the fact that the i386 version of NM was missing from the x86_64 repo, but the problem occurs even in pure i386. TIA. -- Bill in Denver From ob.system at gmail.com Mon Jun 16 18:26:44 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Mon, 16 Jun 2008 13:26:44 -0500 Subject: CVS to SVN with Rsync In-Reply-To: <48530B96.9080708@kanarip.com> References: <6a28481b0806131004n597fbc60q6c8cc7b40fae029@mail.gmail.com> <4852CE5B.8070706@kanarip.com> <6a28481b0806131502v39317899j6c96d895198f6cc8@mail.gmail.com> <48530B96.9080708@kanarip.com> Message-ID: <6a28481b0806161126x3eec0d5atbead48dab615d39e@mail.gmail.com> Hi Again > If you restart the command after it fails does it continue (where it left > off)? This is the output after rsync -avHz rsync://cvs.fedoraproject.org/pkgs/*cvs-backup receiving file list ... rsync: opendir "CVSROOT/admin" (in pkgs) failed: Permission denied (13) rsync: opendir "import" (in pkgs) failed: Permission denied (13) done CVSROOT/Attic/ CVSROOT/Attic/oldmodules,v rpms/Pound/ rpms/PyAmanith/ rpms/PyKDE/ rpms/PyKDE/EL-5/ rpms/PyKDE/F-7/ rpms/PyKDE/F-8/ rpms/PyKDE/F-9/ rpms/PyKDE/FC-5/ rpms/PyKDE/FC-6/ rpms/PyKDE/devel/ rpms/PyOpenGL/ It left off in this point Thanks Oscar Bacho * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From wacker at octothorp.org Tue Jun 17 05:00:21 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 16 Jun 2008 23:00:21 -0600 (MDT) Subject: Tonight's updates appear to have broken Pungi. In-Reply-To: References: <6EDF417D-2791-470D-8DEA-F281E8E79857@j2solutions.net> Message-ID: On Sat, 14 Jun 2008, William F. Acker WB2FLW +1-303-722-7209 wrote: > On Sat, 14 Jun 2008, Jesse Keating wrote: > >> Yeah, pykickstart changes. I'll put out a new pungi early next week. In the >> meantime, change "priority" to "cost" in the code. > > That worked. Thanks. Now, for the next problem in the message to follow. As did pungi-1.2.18.1-1.fc9 that I pulled from koji. -- Bill in Denver From wacker at octothorp.org Tue Jun 17 05:04:42 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 16 Jun 2008 23:04:42 -0600 (MDT) Subject: Respinning cause both the old and new versions of NM to be included. In-Reply-To: References: Message-ID: On Sat, 14 Jun 2008, William F. Acker WB2FLW +1-303-722-7209 wrote: > Hi all, > > After last night's updates, we now get the original version of > NetworkManager as well as the new one. I can't see what's pulling the old > one in. At first, I thought it had something to do with the fact that the > i386 version of NM was missing from the x86_64 repo, but the problem occurs > even in pure i386. > > TIA. I found a workaround. By adding --excludepkgs=Networkmanager,NetworkManager-glib* to the repo lines for fedora and fedora-updates, and putting the new NetworkManager stuff in the local repo, I'm now getting only the new version. This also fixes the missing i386 version in the x86_64 spinn. Hope this helps someone. -- Bill in Denver From mikem at redhat.com Mon Jun 23 22:58:43 2008 From: mikem at redhat.com (Mike McLean) Date: Mon, 23 Jun 2008 18:58:43 -0400 Subject: possible koji logo Message-ID: <48602AA3.3040004@redhat.com> Using the unicode character as a base, I drew a set of paths in the gimp and painted along them using one of the calligraphy brushes. I turned on the 'jitter' option on the paintbrush tool to give it a more natural look. This png shows this path tracing side-by-side with the unicode character at the same scale. http://people.redhat.com/mikem/software/koji-icon-path.png If you want the gimp file with the path data, it is here: http://people.redhat.com/mikem/software/koji-icon-path.xcf.bz2 Having the paths enables us to scale the icon very well and make variations more easily. Anyway, I think it might need a few tweaks, but overall I think I like it. What do folks think? From dennis at ausil.us Wed Jun 25 05:51:08 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Jun 2008 00:51:08 -0500 Subject: possible koji logo Message-ID: <200806250051.14032.dennis@ausil.us> On Monday 23 June 2008, Mike McLean wrote: > Using the unicode character as a base, I drew a set of paths in the gimp > and painted along them using one of the calligraphy brushes. I turned on > the 'jitter' option on the paintbrush tool to give it a more natural look. > > This png shows this path tracing side-by-side with the unicode character > at the same scale. > http://people.redhat.com/mikem/software/koji-icon-path.png > If you want the gimp file with the path data, it is here: > http://people.redhat.com/mikem/software/koji-icon-path.xcf.bz2 > > Having the paths enables us to scale the icon very well and make > variations more easily. > > Anyway, I think it might need a few tweaks, but overall I think I like > it. What do folks think? I like it, It looks nice and clean. maybe we can get Mo to touch it up? -- Dennis Gilmore -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: