10:08 a.m.
I was looking for the location of the cvs tree for up2 date. I tried
export CVSROOT=:pserver:anonymous@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
10:36 a.m.
On Thu, Nov 06, 2003 at 10:08:16AM -0600, David Farning wrote:
I was looking for the location of the cvs tree for up2 date. I
tried
export CVSROOT=:pserver:anonymous@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?
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
11:46 a.m.
On Thu, 2003-11-06 at 18:36, Paul Nasrat wrote:
On Thu, Nov 06, 2003 at 10:08:16AM -0600, David Farning wrote:
> I was looking for the location of the cvs tree for up2 date. I tried
>
> export CVSROOT=:pserver:anonymous@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?
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 -
12:15 p.m.
On Thu, 2003-11-06 at 11:46, Panu Matilainen wrote:
On Thu, 2003-11-06 at 18:36, Paul Nasrat wrote:
> On Thu, Nov 06, 2003 at 10:08:16AM -0600, David Farning wrote:
> > I was looking for the location of the cvs tree for up2 date. I tried
> >
> > export CVSROOT=:pserver:anonymous@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?
>
> 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
12:25 p.m.
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
12:53 p.m.
On Thu, 2003-11-06 at 12:25, seth vidal wrote:
> 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.
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.
-sv
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
12:56 p.m.
> 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
1:08 p.m.
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?
-sv
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
1:24 p.m.
On Thu, 2003-11-06 at 14:08, David Farning wrote:
> 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
1:43 p.m.
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
On Thu, 2003-11-06 at 13:15, David Farning wrote:
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
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
3:07 p.m.
On Thu, Nov 06, 2003 at 02:43:19PM -0500, Stan Bubrouski wrote:
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 <barryn(a)pobox.com>
7514
days inactive
7514
days old
10 comments
6 participants
participants (6)
-
Barry K. Nathan -
David T Farning -
Panu Matilainen -
Paul Nasrat -
seth vidal -
Stan Bubrouski