location of up2date cvs

[David Farning]

I was looking for the location of the cvs tree for up2 date. I tried

export CVSROOT=:pserver:***@rhlinux.redhat.com:/usr/local/CVS
cvs -z3 login
cvs -z3 co up2 date

and just got a bunch of *.po stuff.

Has the fedora development stuff moved?


Thanks
Dave farning

[Paul Nasrat]

Post by David Farning
I was looking for the location of the cvs tree for up2 date. I tried
cvs -z3 login
cvs -z3 co up2 date
and just got a bunch of *.po stuff.
Has the fedora development stuff moved?

No i18n has been on elvis/rhlinux.redhat.com for a while I don't believe
up2date has ever been exposed.

Best bet track rawhide src.rpms for now.

Paul

[Panu Matilainen]

Post by Paul Nasrat

Post by David Farning
I was looking for the location of the cvs tree for up2 date. I tried
cvs -z3 login
cvs -z3 co up2 date
and just got a bunch of *.po stuff.
Has the fedora development stuff moved?

No i18n has been on elvis/rhlinux.redhat.com for a while I don't believe
up2date has ever been exposed.

rhlinux.redhat.com did have various things (initscripts, kudzu, rhgb...)
even if they weren't advertised anywhere and I *think* up2date was one
of those. Could be wrong though.

- Panu -

[David Farning]

Post by Panu Matilainen

Post by Paul Nasrat

Post by David Farning
I was looking for the location of the cvs tree for up2 date. I tried
cvs -z3 login
cvs -z3 co up2 date
and just got a bunch of *.po stuff.
Has the fedora development stuff moved?

No i18n has been on elvis/rhlinux.redhat.com for a while I don't believe
up2date has ever been exposed.

rhlinux.redhat.com did have various things (initscripts, kudzu, rhgb...)
even if they weren't advertised anywhere and I *think* up2date was one
of those. Could be wrong though.
- Panu -

The reason I ask is that i am working on a gui front end for a package
management system. I wanted to know the current devel state of up2date.

My initial work is porting sysnaptic to python/pygtk. How does the
development community feel about writing some of the wigets in C++ and
then wrapping them? I am looking at doing this for reasons of
efficiency.

The package and dependency caches will be based closely on yum (if not
directly using yum code extended for interactive use)

On the back side I'm looking a the existing up2date code to allow
different types of repos to be read and down loaded.

The basic set of event will be.

1. Create pkgStatus list to include all known packages and their statue
ie name, epoch, version, location ,installStatue

2. Via gui interaction a transaction set is developed ie package
install, update, or remove

3. Do a dry run transaction set test -- paranoid

4. Do transaction set

Thanks
Dave Farning

[seth vidal]

Post by David Farning
The reason I ask is that i am working on a gui front end for a package
management system. I wanted to know the current devel state of up2date.
My initial work is porting sysnaptic to python/pygtk. How does the
development community feel about writing some of the wigets in C++ and
then wrapping them? I am looking at doing this for reasons of
efficiency.
The package and dependency caches will be based closely on yum (if not
directly using yum code extended for interactive use)
On the back side I'm looking a the existing up2date code to allow
different types of repos to be read and down loaded.

David,
This sounds like a great idea. A couple of ideas for you.

1. work on learning the redhat-config-packages infrastructure or at
least understanding it.

2. make tweaks to the ui and talk to katzj and bfox about them

3. be prepared for apt repos and yum repos to be the same thing,
hopefully, in the future.

-sv

[David Farning]

Post by seth vidal

Post by David Farning
The reason I ask is that i am working on a gui front end for a package
management system. I wanted to know the current devel state of up2date.
My initial work is porting sysnaptic to python/pygtk. How does the
development community feel about writing some of the wigets in C++ and
then wrapping them? I am looking at doing this for reasons of
efficiency.
The package and dependency caches will be based closely on yum (if not
directly using yum code extended for interactive use)
On the back side I'm looking a the existing up2date code to allow
different types of repos to be read and down loaded.

David,
This sounds like a great idea. A couple of ideas for you.
1. work on learning the redhat-config-packages infrastructure or at
least understanding it.

I'm currently working on that. It seems that one of the main reasons
cited for why linux is not ready for the desktop is the lack of a
cohesive gui config system. The creation of fedora will hopefull help
the user community develop a unified gui config system that is available
GNU/Linux wide.

Post by seth vidal
2. make tweaks to the ui and talk to katzj and bfox about them
3. be prepared for apt repos and yum repos to be the same thing,
hopefully, in the future.

That is my feeling/hope. The use of nevral is much more elegant that
the apt cache. I've been looking into how to put together some sort of
kludge to convert the apt pkgcache into a nevral.

Post by seth vidal
-sv
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[seth vidal]

Post by David Farning

Post by seth vidal
3. be prepared for apt repos and yum repos to be the same thing,
hopefully, in the future.

That is my feeling/hope. The use of nevral is much more elegant that
the apt cache. I've been looking into how to put together some sort of
kludge to convert the apt pkgcache into a nevral.

Don't do that right now. We're already working on a new format that I
hope will match your goals in both directions.

give us some more time, though.

-sv

[David Farning]

Post by seth vidal
Don't do that right now. We're already working on a new format that I
hope will match your goals in both directions.
give us some more time, though.

Should I expect the current nevral design to last?

Post by seth vidal
-sv
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[seth vidal]

Post by David Farning

Post by seth vidal
Don't do that right now. We're already working on a new format that I
hope will match your goals in both directions.
give us some more time, though.

Should I expect the current nevral design to last?

sortof.

You'll be able to get to things via a the nevral data but the metadata
is changing.

Like I said - sit tight, let me get some other bits ironed out and
cleared through the other people involved. It's VERY important to me
that the other pkg mgmt people are onboard and happy with what is being
proposed.

Thanks
-sv

[Stan Bubrouski]

Well as far as up2date goes I'm none to pleased with it to be honest.
It seems to frequently lock-up due to errors in underlying python
libraries when it recieves something unexpected fro mthe server. I've
found myself only running up2date from a shell so I can see the output
and know when it is locked up.

Honestly I wish it were written in different language, but that just me
I guess, I don't know python (perl fan about all other scripting lang.)
so I can't fix bugs on my own which erks me cause now I gotta learn
python ;-)

-sb

Post by David Farning
The reason I ask is that i am working on a gui front end for a package
management system. I wanted to know the current devel state of up2date.
My initial work is porting sysnaptic to python/pygtk. How does the
development community feel about writing some of the wigets in C++ and
then wrapping them? I am looking at doing this for reasons of
efficiency.
The package and dependency caches will be based closely on yum (if not
directly using yum code extended for interactive use)
On the back side I'm looking a the existing up2date code to allow
different types of repos to be read and down loaded.
The basic set of event will be.
1. Create pkgStatus list to include all known packages and their statue
ie name, epoch, version, location ,installStatue
2. Via gui interaction a transaction set is developed ie package
install, update, or remove
3. Do a dry run transaction set test -- paranoid
4. Do transaction set
Thanks
Dave Farning
--
fedora-devel-list mailing list
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Barry K. Nathan]

Post by Stan Bubrouski
It seems to frequently lock-up due to errors in underlying python
libraries when it recieves something unexpected fro mthe server. I've
found myself only running up2date from a shell so I can see the output
and know when it is locked up.

Me Too(tm)

I filed this right after the Red Hat 9 release (unfortunately I didn't
do much testing of the betas between Red Hat 8.0 and 9), as bug 88349.
IIRC, Red Hat 8.0's up2date did *not* have this problem -- tracebacks
appeared in their own dialog boxes. (It could be some other component
that changed and caused this problem, for all I know.)

-Barry K. Nathan <***@pobox.com>