Hello all,
A yum update has yielded:
Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for nfs-utils to pack into transaction set. nfs-utils-1.0.9-8.fc6.i38 100% |=========================| 29 kB 00:00 ---> Package nfs-utils.i386 1:1.0.9-8.fc6 set to be updated --> Running transaction check --> Processing Dependency: rtld(GNU_HASH) for package: nfs-utils --> Processing Dependency: libgssapi.so.2(libgssapi_CITI_2) for package: nfs-utils --> Finished Dependency Resolution Error: Missing Dependency: rtld(GNU_HASH) is needed by package nfs-utils Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2) is needed by package nfs-utils
Just an FYI. Have a good day!
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
Gilbert Sebenste wrote:
Hello all,
A yum update has yielded:
Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for nfs-utils to pack into transaction set. nfs-utils-1.0.9-8.fc6.i38 100% |=========================| 29 kB 00:00 ---> Package nfs-utils.i386 1:1.0.9-8.fc6 set to be updated --> Running transaction check --> Processing Dependency: rtld(GNU_HASH) for package: nfs-utils --> Processing Dependency: libgssapi.so.2(libgssapi_CITI_2) for package: nfs-utils --> Finished Dependency Resolution Error: Missing Dependency: rtld(GNU_HASH) is needed by package nfs-utils Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2) is needed by package nfs-utils
Thanks for the report. Would be better filed in bugzilla.
Will Woods, How hard would it be to add tests to make sure we dont push updates that has broken dependencies?
Rahul
On Wednesday 27 September 2006 17:49, Rahul Sundaram wrote:
nfs-utils-1.0.9-8.fc6.i38 100% |=========================| 29 kB 00:00 ---> Package nfs-utils.i386 1:1.0.9-8.fc6 set to be updated --> Running transaction check --> Processing Dependency: rtld(GNU_HASH) for package: nfs-utils --> Processing Dependency: libgssapi.so.2(libgssapi_CITI_2) for package: nfs-utils --> Finished Dependency Resolution Error: Missing Dependency: rtld(GNU_HASH) is needed by package nfs-utils Error: Missing Dependency: libgssapi.so.2(libgssapi_CITI_2) is needed by package nfs-utils
Thanks for the report. Would be better filed in bugzilla.
Will Woods, How hard would it be to add tests to make sure we dont push updates that has broken dependencies?
This is not an FC5 updates stream, unless somebody requested the wrong package to be pushed as an update. See the .fc6? Thats a development package...
On Wednesday 27 September 2006 18:06, Jesse Keating wrote:
This is not an FC5 updates stream, unless somebody requested the wrong package to be pushed as an update. See the .fc6? Thats a development package...
Ah CRAP! The developer asked to push a FC6 package as an FC5 update. *sigh*
On Wed, 27 Sep 2006, Jesse Keating wrote:
On Wednesday 27 September 2006 18:07, Jesse Keating wrote:
Ah CRAP! The developer asked to push a FC6 package as an FC5 update. *sigh*
I've pulled the update, new metadata and content should hit the servers in 10~ minutes.
Thanks, Jesse. I didn't even see the .fc6. Bad cold clouding the mind.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Wed, Sep 27, 2006 at 06:07:34PM -0400, Jesse Keating wrote:
On Wednesday 27 September 2006 18:06, Jesse Keating wrote:
This is not an FC5 updates stream, unless somebody requested the wrong package to be pushed as an update. See the .fc6? Thats a development package...
Ah CRAP! The developer asked to push a FC6 package as an FC5 update. *sigh*
While we're at it, can the maintainer fix fc5 package so that it doesn't require pkgconfig for no reason? Yes, it's in bugzilla and it's been already fixed in devel/fc6.
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 27 September 2006 17:49, Rahul Sundaram wrote:
Will Woods, How hard would it be to add tests to make sure we dont push updates that has broken dependencies?
The tests are actually already written - RHEL QA has a whole bunch of checks that they run for each errata (package update). They're interested in opening that tool up, but I'd need someone to help me understand how and where it would fit into the Fedora infrastructure.
This is probably a post-FC6 work item. I'll add it to my list!
Bill Nottingham wrote:
Will Woods (wwoods@redhat.com) said:
Will Woods, How hard would it be to add tests to make sure we dont push updates that has broken dependencies?
The update tool already has this, AFAIK.
Bill
Doesnt seem to. I see a number of package update dependency issues. Last one before this was the bind-config/caching-nameserver mess.
Rahul
On Thursday 28 September 2006 13:24, Rahul Sundaram wrote:
Doesnt seem to. I see a number of package update dependency issues. Last one before this was the bind-config/caching-nameserver mess.
That was partly due to me not clicking the button to check for broken deps.
Jesse Keating wrote:
On Thursday 28 September 2006 13:24, Rahul Sundaram wrote:
Doesnt seem to. I see a number of package update dependency issues. Last one before this was the bind-config/caching-nameserver mess.
That was partly due to me not clicking the button to check for broken deps.
Curious. Are we planning to get this system in place for Fedora Extras or Fedora Legacy updates too? Why do you have to manually click a button to get the tests running instead of it running by default?
Rahul
On Thu, 28 Sep 2006, Jesse Keating wrote:
Jesse Keating wrote: That was partly due to me not clicking the button to check for broken deps.
Why isn't this run by default? Just curious.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Thursday 28 September 2006 13:49, Gilbert Sebenste wrote:
Jesse Keating wrote: That was partly due to me not clicking the button to check for broken deps.
Why isn't this run by default? Just curious.
Because the checking process is still under development and returns some false positives at times and was preventing updates from actually going out. Still Under Development.
On Thu, 28 Sep 2006, Jesse Keating wrote:
Why isn't this run by default? Just curious.
Because the checking process is still under development and returns some false positives at times and was preventing updates from actually going out. Still Under Development.
Gotcha. Thanks!
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste@weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** *******************************************************************************
Jesse Keating (jkeating@redhat.com) said:
Why isn't this run by default? Just curious.
Because the checking process is still under development and returns some false positives at times and was preventing updates from actually going out. Still Under Development.
Also, it's sloooooooooooooow. :)
Bill
On Thursday 28 September 2006 16:32, Bill Nottingham wrote:
Also, it's sloooooooooooooow.
To be fair, if I push updates when they come in so that its just one or two updates rather than being lazy and letting 10 or so stack up, its much faster (:
On Thu, Sep 28, 2006 at 11:18:06PM +0530, Rahul Sundaram wrote:
Jesse Keating wrote:
On Thursday 28 September 2006 13:24, Rahul Sundaram wrote:
Doesnt seem to. I see a number of package update dependency issues. Last one before this was the bind-config/caching-nameserver mess.
That was partly due to me not clicking the button to check for broken deps.
Curious. Are we planning to get this system in place for Fedora Extras or Fedora Legacy updates too? Why do you have to manually click a button to get the tests running instead of it running by default?
I'm working on a redesign of the current update system to allow it to encompass Core/Extras/Legacy. The current system that is in place is gets the job done, but is not modular and is a pain to maintain. I'm working on porting it to the TurboGears stack, and making it dead simple to plug in modules to any part of the package update process.
The dependency checking is currently a button because it takes *forever* and sometimes brings up false-positives. I'm going to prod at the code this weekend and see if I can get this issue resolved once and for all.
luke
Luke Macken wrote:
On Thu, Sep 28, 2006 at 11:18:06PM +0530, Rahul Sundaram wrote:
Jesse Keating wrote:
On Thursday 28 September 2006 13:24, Rahul Sundaram wrote:
Doesnt seem to. I see a number of package update dependency issues. Last one before this was the bind-config/caching-nameserver mess.
That was partly due to me not clicking the button to check for broken deps.
Curious. Are we planning to get this system in place for Fedora Extras or Fedora Legacy updates too? Why do you have to manually click a button to get the tests running instead of it running by default?
I'm working on a redesign of the current update system to allow it to encompass Core/Extras/Legacy. The current system that is in place is gets the job done, but is not modular and is a pain to maintain. I'm working on porting it to the TurboGears stack, and making it dead simple to plug in modules to any part of the package update process.
The dependency checking is currently a button because it takes *forever* and sometimes brings up false-positives. I'm going to prod at the code this weekend and see if I can get this issue resolved once and for all.
Thanks for the update luke. When is your Pup notification changes hitting the development tree btw?
Rahul
On Fri, Sep 29, 2006 at 10:01:33AM +0530, Rahul Sundaram wrote:
Luke Macken wrote:
On Thu, Sep 28, 2006 at 11:18:06PM +0530, Rahul Sundaram wrote:
Jesse Keating wrote:
On Thursday 28 September 2006 13:24, Rahul Sundaram wrote:
Doesnt seem to. I see a number of package update dependency issues. Last one before this was the bind-config/caching-nameserver mess.
That was partly due to me not clicking the button to check for broken deps.
Curious. Are we planning to get this system in place for Fedora Extras or Fedora Legacy updates too? Why do you have to manually click a button to get the tests running instead of it running by default?
I'm working on a redesign of the current update system to allow it to encompass Core/Extras/Legacy. The current system that is in place is gets the job done, but is not modular and is a pain to maintain. I'm working on porting it to the TurboGears stack, and making it dead simple to plug in modules to any part of the package update process.
The dependency checking is currently a button because it takes *forever* and sometimes brings up false-positives. I'm going to prod at the code this weekend and see if I can get this issue resolved once and for all.
Thanks for the update luke. When is your Pup notification changes hitting the development tree btw?
The code has been in pirut since 1.1.9-1. Once FC6 hits and updates start getting pushed through the update system, pup/pirut will notice the updateinfo.xml.gz in the repodata and start using it.
Puplet notifications are working for rawhide; it just can't determine if an update is a security fix or not.
luke
Luke Macken wrote:
The code has been in pirut since 1.1.9-1. Once FC6 hits and updates start getting pushed through the update system, pup/pirut will notice the updateinfo.xml.gz in the repodata and start using it.
Great.
Puplet notifications are working for rawhide; it just can't determine if an update is a security fix or not.
Why is it unable to differentiate a security fix in rawhide? Does the system differentiate between packages with bug fixes and one that has new features or just between security updates and the rest?
I cant seem to the find the preference button shown in a earlier mockup. Do you plan on adding it? I would also like a preference to install all updates by default, ignore all updates, ignore or auto install updates by classification, automatically download updates in the background and only ask me for confirmation to install it.
Rahul
On Friday 29 September 2006 03:23, Rahul Sundaram wrote:
Puplet notifications are working for rawhide; it just can't determine if an update is a security fix or not.
Why is it unable to differentiate a security fix in rawhide? Does the system differentiate between packages with bug fixes and one that has new features or just between security updates and the rest?
The update tool has a checkbox for 'security' that makes the tool act slightly different for that update. Adds the SECURITY word to the subject, etc... We don't use the update tool for rawhide, rawhide is just a compose of what happens to be in the FC6 collection at that time. There is no real knowledge of whats new in that compose when creating the repodata so nothing is really an 'update' per se, its a brand new tree which happens ot have some packages which are newer than the previous tree or whats installed on people's system.
On Fri, Sep 29, 2006 at 12:53:08PM +0530, Rahul Sundaram wrote:
I cant seem to the find the preference button shown in a earlier mockup. Do you plan on adding it? I would also like a preference to install all updates by default, ignore all updates, ignore or auto install updates by classification, automatically download updates in the background and only ask me for confirmation to install it.
The buttons exist, but are not visible by default and no preferences dialog has been created yet (any volunteers?). I was using Gazpacho to edit pup.glade, which apparently decided to change a bunch of the settings around for no reason.
luke
-
Bill Nottingham -
Dominik 'Rathann' Mierzejewski -
Gilbert Sebenste -
Jesse Keating -
Luke Macken -
Rahul Sundaram -
Will Woods