Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread Klaus Kaempf
* Pascal Bleser [EMAIL PROTECTED] [Jun 04. 2006 00:35]:
 
 I started a thread/discussion with the SUSE folks about that when
 openSUSE started. I was asking them whether it would be possible to do
 some refinements in YaST2, to have it fetch a list of repositories from,
 say, opensuse.org and propose them to the end-user as additional repos.

Actually, we were working on this functionality for 10.1 but
didn't have time to finish it. The current .repo/.channel thread
gives us quite good input for an actual implementation for 10.2

 
 It became pretty clear that it wouldn't be possible, because of
 ridiculous court rulings in the US and Germany (e.g. the Heise case),
 where linking to a resource that provides a package that under certain
 circumstances and/or jurisdictions would be.. well.. attackable in
 court, is already sufficient for potential trouble.

So you won't see SuSE/Novell offering such external links. However,
we will support a standard way of repository linking in the future.


Klaus

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread houghi
On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:
 So you won't see SuSE/Novell offering such external links. However,
 we will support a standard way of repository linking in the future.

Here I am telling everybody it is SUSE not SuSE and then I see people from
SUSE writing SuSE instead of SUSE. :-(

houghi
-- 
This openSUSE  mailinglist is about the community.  All discussion about
the community is welcome.If you have a techical question
just subscribe  via this email  address: [EMAIL PROTECTED],
post your original email again there, and you will get a straight answer.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread Eberhard Moenkeberg

Hi,

On Tue, 6 Jun 2006, houghi wrote:

On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:



So you won't see SuSE/Novell offering such external links. However,
we will support a standard way of repository linking in the future.


Here I am telling everybody it is SUSE not SuSE and then I see people from
SUSE writing SuSE instead of SUSE. :-(


I can't see any difference. ;-))

Cheers -e
--
Eberhard Moenkeberg ([EMAIL PROTECTED], [EMAIL PROTECTED])

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread Juergen Weigert
On Jun 06, 06 20:16:55 +0200, houghi wrote:
 On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:
  So you won't see SuSE/Novell offering such external links. However,
  we will support a standard way of repository linking in the future.
 
 Here I am telling everybody it is SUSE not SuSE and then I see people from
 SUSE writing SuSE instead of SUSE. :-(

Within SUSE, there is a secret brotherhood of traditionalists called SuSE.  :-)

please have mercy, 

Jw.

-- 
 o \  Juergen Weigert  paint it green! __/ _===.===_
V | [EMAIL PROTECTED]   wide open suse_/_---|\/
 \  | 0911 74053-508 (tm)__/  (//\
(/) | __/ _/ \_ vim:set sw=2 wm=8

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread Marcus Rueckert
On 2006-06-06 20:16:55 +0200, houghi wrote:
 Here I am telling everybody it is SUSE not SuSE and then I see people from
 SUSE writing SuSE instead of SUSE. :-(
 

you are so wrong: it is S.u.S.E.

scnr

darix

-- 
  openSUSE - SUSE Linux is my linux
  openSUSE is good for you
  www.opensuse.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread jdd

Juergen Weigert wrote:

On Jun 06, 06 20:16:55 +0200, houghi wrote:


On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:


So you won't see SuSE/Novell offering such external links. However,
we will support a standard way of repository linking in the future.


Here I am telling everybody it is SUSE not SuSE and then I see people from
SUSE writing SuSE instead of SUSE. :-(



Within SUSE, there is a secret brotherhood of traditionalists called SuSE.  :-)

please have mercy, 


Jw.


specially working on SuSEConfig and SuSEFirewall2 :-)

jdd

--
http://www.dodin.net
http://dodin.org/galerie_photo_web/expo/index.html
http://lucien.dodin.net
http://fr.susewiki.org/index.php?title=Gérer_ses_photos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-06 Thread Marcus Meissner
On Tue, Jun 06, 2006 at 08:16:55PM +0200, houghi wrote:
 On Tue, Jun 06, 2006 at 01:38:51PM +0200, Klaus Kaempf wrote:
  So you won't see SuSE/Novell offering such external links. However,
  we will support a standard way of repository linking in the future.
 
 Here I am telling everybody it is SUSE not SuSE and then I see people from
 SUSE writing SuSE instead of SUSE. :-(

In the end, we do not care anymore. Everyone knows what is meant.

Ciao, Marcus

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-05 Thread Adrian Schröter
Am Sunday 04 June 2006 12:54 schrieb Pascal Bleser:
 Adrian Schröter wrote:
  Am Sunday 04 June 2006 00:34 schrieb Pascal Bleser:
  Richard Bos wrote:

 ...

  The best place to host those channel rpms are of course suse itself as
  they get than mirrored automatically.  But as you already stated that
  might not be possible due to law implications.
 
  s/might/will/
 
  I started a thread/discussion with the SUSE folks about that when
  openSUSE started. I was asking them whether it would be possible to do
  some refinements in YaST2, to have it fetch a list of repositories from,
  say, opensuse.org and propose them to the end-user as additional repos.
 
  It became pretty clear that it wouldn't be possible, because of
  ridiculous court rulings in the US and Germany (e.g. the Heise case),
  where linking to a resource that provides a package that under certain
  circumstances and/or jurisdictions would be.. well.. attackable in
  court, is already sufficient for potential trouble.
 
  The issue was a task to.. mm.. I think it was Adrian, to take it to
  Novell's legal dept, but there was never any feedback on it (and it was
  in November 2005).
  Dunno if anything came back about that.. Adrian ?
 
  The problem is that this decisions needs to be made for each software
  seperatly. For example it is very unlikely that this would be ever
  possible with DeCSS, but there are maybe chances for other stuff like mp3
  playback. This will of course take much resources for each package at the
  legal department :/

 OK, now I get it, I thought it was some blessing of linking to
 repositories that provide packages that ...

 Note, I'm not talking about building and hosting packages like mad in
 the Build Service, that's another topic.

Yes, I understood that, but there seems no to be much difference between 
linking and building it legal wise.

-- 

Adrian Schroeter
SUSE Linux Products GmbH,  Maxfeldstr. 5, 90409 Nuernberg, Germany
email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-04 Thread Adrian Schröter
Am Sunday 04 June 2006 00:34 schrieb Pascal Bleser:
 Richard Bos wrote:
  Op zaterdag 3 juni 2006 15:45, schreef Pascal Bleser:
  The idea behind this is to be able to add a channel using the command:
  smart --install channel-whatever name
 
  It's even easier to provide .channel files somewhere (like the .repo
  files in the Build Service), and just do
 
  smart channel --add http:///guru.channel
  smart channel --add http:///packman.channel
 
  Not sure whether this is easier from a user perspective.  In your case
  the user needs to remember the url pointing to the channel repository. 
  In my proposal it is not needed to remember this.  One could for example
  use smart's functionality to find the channel rpm.  Once the correct rpm
  (providing the desired channel), just execute 'smart install
  channel-name'. Or the more lazy type of user could execute 'smart
  install '*name*.' and have the channel installed that way.  The only
  requirement is to have all channel rpms in a common place.  Just like the
  rpmkey rpms that I maintain at the moment.

 That's correct, good point.
 I'd rather name them smart-channel-* though ;)

  Your proposal just a *.channel repository is easier from a packager
  perspective, as there is not rpm needed.
  The advantage of having the channel files in an rpm, is that those gets
  updated automatically when the corresponding channel file gets updated. 
  This is the same for the rpmkey rpms.

 Yep, you're right.

  The best place to host those channel rpms are of course suse itself as
  they get than mirrored automatically.  But as you already stated that
  might not be possible due to law implications.

 s/might/will/

 I started a thread/discussion with the SUSE folks about that when
 openSUSE started. I was asking them whether it would be possible to do
 some refinements in YaST2, to have it fetch a list of repositories from,
 say, opensuse.org and propose them to the end-user as additional repos.

 It became pretty clear that it wouldn't be possible, because of
 ridiculous court rulings in the US and Germany (e.g. the Heise case),
 where linking to a resource that provides a package that under certain
 circumstances and/or jurisdictions would be.. well.. attackable in
 court, is already sufficient for potential trouble.

 The issue was a task to.. mm.. I think it was Adrian, to take it to
 Novell's legal dept, but there was never any feedback on it (and it was
 in November 2005).
 Dunno if anything came back about that.. Adrian ?

The problem is that this decisions needs to be made for each software 
seperatly. For example it is very unlikely that this would be ever possible 
with DeCSS, but there are maybe chances for other stuff like mp3 playback.

This will of course take much resources for each package at the legal 
department :/

bye
adrian

-- 

Adrian Schroeter
SUSE Linux Products GmbH,  Maxfeldstr. 5, 90409 Nuernberg, Germany
email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-04 Thread Richard Bos
Op zondag 4 juni 2006 00:34, schreef Pascal Bleser:
  I think that the buildserver could build/create a channel rpm for each
  project and have those stored in a central place.  This would be a good
  start.

 It won't be in a central place, unfortunately.

In my phrase above, I referred to the projects that are build on the 
buildserver.  I mean if the packages are allowed to be build on the 
buildserver, they are allowed to be distributed by by opensuse.  Or are these 
2 different animals?

If all sofrtware build on the buildserver is allowed to be distributed by 
novell/opensuse, than it is also possible to create smart channel files/rpms 
for each of the projects hosted on the buildserver.  Once an rpm is created 
it can be stored/movedto a common directory on the buildserver.

 It could be done for repositories that don't contain stuff like mad or
 lame (which discards my repository and Packman, at the very least), like
 latest mozilla.org packages, latest wine packages by Marcus, latest
 OpenOffice.org packages, etc...

 But the other ones must be hosted elsewhere.

See above.  It's about the software provided via the buildserver.  At the end 
it may result in 2 'smart-channel' repositories.  One at the buildserver and 
another 1 hosted somewhere else, providing smart-channel rpms that are not 
possible to host on the buildserver.

 Note that this structure would make it possible to host the/my smart
 RPMs in the openSUSE Build Service.
 I was very reluctant to the idea, and I'm still pretty sure it is going
 to make things more difficult for end-users but well... dunno... I'll
 think about it ;)

 The point is that to install e.g. smart-channel-packman, you'll have to
 add the Packman repository in the first place, because it won't be
 hosted in the Build Service... chicken vs egg.

No, it will be different.  Assume that there are 2 smart-channel directories 
(buildserver, and e.g. at packman).  You should include those 2 channels by 
default in your smart rpm.  The only thing the user now has to do to add 
packman is:

smart install smart-channel-packman and packman is added :)

In the same swing, one can execute:
smart install smart-channel-bs-home:rbos (bs = buildserver)

ps: is this discussion okay to be held here (opensuse = community) or should 
it be moved to somewhere else?

-- 
Richard Bos
Without a home the journey is endless

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-04 Thread Pascal Bleser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adrian Schröter wrote:
 Am Sunday 04 June 2006 00:34 schrieb Pascal Bleser:
 Richard Bos wrote:
...
 The best place to host those channel rpms are of course suse itself as
 they get than mirrored automatically.  But as you already stated that
 might not be possible due to law implications.
 s/might/will/

 I started a thread/discussion with the SUSE folks about that when
 openSUSE started. I was asking them whether it would be possible to do
 some refinements in YaST2, to have it fetch a list of repositories from,
 say, opensuse.org and propose them to the end-user as additional repos.

 It became pretty clear that it wouldn't be possible, because of
 ridiculous court rulings in the US and Germany (e.g. the Heise case),
 where linking to a resource that provides a package that under certain
 circumstances and/or jurisdictions would be.. well.. attackable in
 court, is already sufficient for potential trouble.

 The issue was a task to.. mm.. I think it was Adrian, to take it to
 Novell's legal dept, but there was never any feedback on it (and it was
 in November 2005).
 Dunno if anything came back about that.. Adrian ?
 
 The problem is that this decisions needs to be made for each software 
 seperatly. For example it is very unlikely that this would be ever possible 
 with DeCSS, but there are maybe chances for other stuff like mp3 playback.
 This will of course take much resources for each package at the legal 
 department :/

OK, now I get it, I thought it was some blessing of linking to
repositories that provide packages that ...

Note, I'm not talking about building and hosting packages like mad in
the Build Service, that's another topic.

cheers
- --
  -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
  /\\ [EMAIL PROTECTED]   [EMAIL PROTECTED]
 _\_v The more things change, the more they stay insane.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEgrvTr3NMWliFcXcRAt6RAJ9D4OIo6wlZvW0i/2dalPanLIiRsACghrRB
4+vYtnShfR5o3U9rvzzCtjU=
=WFob
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-03 Thread jdd
Would be nice if you could tell ksmarttray to update certain channels (most 
notably ~/suse/update/10.1 of course) when checking for updates.


and probably using different words for similar thinbgs add 
to the mess.


what are those channels? I already had problem 
undersdtanding what are the different inst-source (not even 
trying to know what are the different metadata systems)


many things need to be simplified

jdd

--
http://www.dodin.net
http://dodin.org/galerie_photo_web/expo/index.html
http://lucien.dodin.net
http://fr.susewiki.org/index.php?title=Gérer_ses_photos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray (was: Package management tool confusion)

2006-06-03 Thread Michael Schueller
Am Samstag, 3. Juni 2006 01:31 schrieb Pascal Bleser:
 Michael Schueller wrote:
  Am Freitag, 2. Juni 2006 21:52 schrieb Marcus Meissner:
  On a side note: do you know if there are plans to develop a
  KDE native updater applet?
 
  Yes. We even have found a student who wants to do it ;)
 
  http://code.google.com/soc/suse/about.html
 
  Btw, the previous YOU watcher just run a commandline program
  (online_update)... It could be ported to just call rug...
  ;)
 
  How about patching the old SuSE-Watcher to just call smart ..
  That would be nice ;-)

 That's what ksmarttray already does ;)

 It's shipped as part of smart, in contrib/, and I package it as
 smart-ksmarttray.

 It's very simple though, it just calls smart update on a
 regular basis (interval is hardcoded in the sources), checks the
 output and reports it. So it's a lot like SuSE-watcher.

Hello Pascal,
yes, ksmarttray is a lot like the suse-watcher, but what i actually 
wanted to say was, that there was, and is, a tool which has the 
flexibility in handling different kinds of sources. Which is well 
tested and accepted by the users.
So, whatever zmd wanted to make better, or will do better in futur,
this tool is simply not coming out of the comunity.
It is against the meaning of opensource, and in this way i can not 
understand that NOVELL on on hand yells out OpenSource, and on the 
other hand fiddles somthing together behind close doors.
It will never be accepted, and it will never be this well dokomented
then smart.
And this is a really bad Point.
At least in germany it´s like that.
When you buy somthing, even when it´s software, and it is not well 
dokumented, you can give it back, because it not useable.

So, whatever the good thougts where, they should have never go this 
way. They should have taken something out of the comunity where 
they can say we know that it´s working, and here you will find 
documentation about.

Thats my point of this
Thanks Pascal for keeping us up2date with smart (and others)

Greets
Michael


 cheers

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray (was: Package management tool confusion)

2006-06-03 Thread Michael Schueller
Am Samstag, 3. Juni 2006 01:31 schrieb Pascal Bleser:
 It's very simple though, it just calls smart update on a
 regular basis (interval is hardcoded in the sources), checks the
 output and reports it. So it's a lot like SuSE-watcher.

 If someone with some KDE hacking skills would like to spend a
 little time on it, I think it's pretty easy to expand (it already
 does the dirty job of interfacing with smart)... or even use
 SuSE-watcher and copy/paste the ksmarttray code smart update
 output checking code into it.

Pascal

if anybody would patch the suse-watcher to check about new updates 
with the smart engine, it would check the smart sources 
(channels=sources  jpp) for updates.
If you then press the Button Update now, the SuSE(Yast) Online 
Update would appear, which has mostly different sources.
So it would only make sence when the hacked suse-watcher only checks 
the suse update repo, and for all other sources you can use 
ksmarttray...

Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-03 Thread Richard Bos
Op zaterdag 3 juni 2006 15:45, schreef Pascal Bleser:
  The idea behind this is to be able to add a channel using the command:
  smart --install channel-whatever name

 It's even easier to provide .channel files somewhere (like the .repo
 files in the Build Service), and just do

 smart channel --add http:///guru.channel
 smart channel --add http:///packman.channel

Not sure whether this is easier from a user perspective.  In your case the 
user needs to remember the url pointing to the channel repository.  In my 
proposal it is not needed to remember this.  One could for example use 
smart's functionality to find the channel rpm.  Once the correct rpm 
(providing the desired channel), just execute 'smart install channel-name'.  
Or the more lazy type of user could execute 'smart install '*name*.' and 
have the channel installed that way.  The only requirement is to have all 
channel rpms in a common place.  Just like the rpmkey rpms that I maintain at 
the moment.

Your proposal just a *.channel repository is easier from a packager 
perspective, as there is not rpm needed.
The advantage of having the channel files in an rpm, is that those gets 
updated automatically when the corresponding channel file gets updated.  This 
is the same for the rpmkey rpms.

The best place to host those channel rpms are of course suse itself as they 
get than mirrored automatically.  But as you already stated that might not be 
possible due to law implications.

I think that the buildserver could build/create a channel rpm for each project 
and have those stored in a central place.  This would be a good start.

-- 
Richard Bos
Without a home the journey is endless

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray

2006-06-03 Thread Pascal Bleser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard Bos wrote:
 Op zaterdag 3 juni 2006 15:45, schreef Pascal Bleser:
 The idea behind this is to be able to add a channel using the command:
 smart --install channel-whatever name
 It's even easier to provide .channel files somewhere (like the .repo
 files in the Build Service), and just do

 smart channel --add http:///guru.channel
 smart channel --add http:///packman.channel
 
 Not sure whether this is easier from a user perspective.  In your case the 
 user needs to remember the url pointing to the channel repository.  In my 
 proposal it is not needed to remember this.  One could for example use 
 smart's functionality to find the channel rpm.  Once the correct rpm 
 (providing the desired channel), just execute 'smart install channel-name'. 
  
 Or the more lazy type of user could execute 'smart install '*name*.' and 
 have the channel installed that way.  The only requirement is to have all 
 channel rpms in a common place.  Just like the rpmkey rpms that I maintain at 
 the moment.

That's correct, good point.
I'd rather name them smart-channel-* though ;)

 Your proposal just a *.channel repository is easier from a packager 
 perspective, as there is not rpm needed.
 The advantage of having the channel files in an rpm, is that those gets 
 updated automatically when the corresponding channel file gets updated.  This 
 is the same for the rpmkey rpms.

Yep, you're right.

 The best place to host those channel rpms are of course suse itself as they 
 get than mirrored automatically.  But as you already stated that might not be 
 possible due to law implications.

s/might/will/

I started a thread/discussion with the SUSE folks about that when
openSUSE started. I was asking them whether it would be possible to do
some refinements in YaST2, to have it fetch a list of repositories from,
say, opensuse.org and propose them to the end-user as additional repos.

It became pretty clear that it wouldn't be possible, because of
ridiculous court rulings in the US and Germany (e.g. the Heise case),
where linking to a resource that provides a package that under certain
circumstances and/or jurisdictions would be.. well.. attackable in
court, is already sufficient for potential trouble.

The issue was a task to.. mm.. I think it was Adrian, to take it to
Novell's legal dept, but there was never any feedback on it (and it was
in November 2005).
Dunno if anything came back about that.. Adrian ?

 I think that the buildserver could build/create a channel rpm for each 
 project 
 and have those stored in a central place.  This would be a good start.

It won't be in a central place, unfortunately.
It could be done for repositories that don't contain stuff like mad or
lame (which discards my repository and Packman, at the very least), like
latest mozilla.org packages, latest wine packages by Marcus, latest
OpenOffice.org packages, etc...

But the other ones must be hosted elsewhere.

Note that this structure would make it possible to host the/my smart
RPMs in the openSUSE Build Service.
I was very reluctant to the idea, and I'm still pretty sure it is going
to make things more difficult for end-users but well... dunno... I'll
think about it ;)

The point is that to install e.g. smart-channel-packman, you'll have to
add the Packman repository in the first place, because it won't be
hosted in the Build Service... chicken vs egg.

cheers
- --
  -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
  /\\ [EMAIL PROTECTED]   [EMAIL PROTECTED]
 _\_v The more things change, the more they stay insane.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEgg6Nr3NMWliFcXcRAoIOAJ4yZ9WwZeETZ7PI3fHXxeIyf6NwawCdHHXE
eGOJ5MWTdQloP47EMOYOpiQ=
=n6iJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[opensuse] SuSE-watcher/ksmarttray (was: Package management tool confusion)

2006-06-02 Thread Pascal Bleser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Schueller wrote:
 Am Freitag, 2. Juni 2006 21:52 schrieb Marcus Meissner:
 On a side note: do you know if there are plans to develop a KDE
 native updater applet?
 Yes. We even have found a student who wants to do it ;)

 http://code.google.com/soc/suse/about.html

 Btw, the previous YOU watcher just run a commandline program
 (online_update)... It could be ported to just call rug... ;)
 
 How about patching the old SuSE-Watcher to just call smart ..
 That would be nice ;-)

That's what ksmarttray already does ;)

It's shipped as part of smart, in contrib/, and I package it as
smart-ksmarttray.

It's very simple though, it just calls smart update on a regular basis
(interval is hardcoded in the sources), checks the output and reports
it. So it's a lot like SuSE-watcher.

If someone with some KDE hacking skills would like to spend a little
time on it, I think it's pretty easy to expand (it already does the
dirty job of interfacing with smart)... or even use SuSE-watcher and
copy/paste the ksmarttray code smart update output checking code into it.

At least it would be nice to do a simple config dialog for the update
interval (passing it from the command-line would be the easiest hack,
but probably not the most noob-friendly).

Note that as smart is written in Python, a neat solution would be to
code such a systray app (or kicker applet) in Python/QT or Python/KDE,
to directly use the smart API instead of forking smart update and
checking the output (although it works).
But then again, Python/QT/KDE has very, very few documentation :\

cheers
- --
  -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
  /\\ [EMAIL PROTECTED]   [EMAIL PROTECTED]
 _\_v The more things change, the more they stay insane.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEgMpBr3NMWliFcXcRAoH0AJ4tvbV9NKMAnaPbTYvJ81tOrS8S7QCeJyy4
g/4gfY5cVECFjAacaykW9bY=
=c6ec
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [opensuse] SuSE-watcher/ksmarttray (was: Package management tool confusion)

2006-06-02 Thread Martin Schlander
Lørdag 03 juni 2006 01:31 skrev Pascal Bleser:
 If someone with some KDE hacking skills would like to spend a little
 time on it, I think it's pretty easy to expand (it already does the
 dirty job of interfacing with smart)... or even use SuSE-watcher and
 copy/paste the ksmarttray code smart update output checking code into it.

 At least it would be nice to do a simple config dialog for the update
 interval (passing it from the command-line would be the easiest hack,
 but probably not the most noob-friendly).

 Note that as smart is written in Python, a neat solution would be to
 code such a systray app (or kicker applet) in Python/QT or Python/KDE,
 to directly use the smart API instead of forking smart update and
 checking the output (although it works).
 But then again, Python/QT/KDE has very, very few documentation :\

Would be nice if you could tell ksmarttray to update certain channels (most 
notably ~/suse/update/10.1 of course) when checking for updates.

I actually thought it did something like that - but after updating some 
channels manually I discovered a bunch of updates available ksmarttray hadn't 
told me about. Still pretty new Smart-user.

Of course making an entire kde/qt port of the smart-gui would be very much 
appreciated also :)

Martin / cb400f

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]