June 2007 - YaST Development - openSUSE Mailing Lists

[yast-devel] Re: [zypp-devel] Source refresh policy
by Jan Kupec 21 Jun '07

21 Jun '07

(Posting also to sw-management and yast, as this is (most of it) not zypp-specific. Please, discuss parts which are not zypp-specific on sw-management <opensuse-softwaremgmt(a)opensuse.org>.) Jiri Srain wrote: > Hi! > > This is my suggestion on how to define the refresh policy with refactored > ZYPP: > > We need to keep the information when last a source was refreshed in order > to decide whether a source needs to be refreshed or not. In addition, we > will need some policies defining whether a source should be refreshed or > not. > The basic refresh should be done by a cron job. However, there may be > a reason not to do refresh via a cron job and do it only when SW management > tool starts. (if you don't have much time to read all this, skip to the IMPORTANT part below) I personally don't like either of these ideas: 1) If doing refresh in cronjob, the user can get surprisingly stuck when trying to use zypp in the very moment when the repos are being refreshed. Also the huge download happens without user's supervision. However, we can offer the user to set up the cron job for him, but we cannot do it behind his back. Or he can set up a cron job by himself. 2) Please NOT when a SW management tool starts!! This is much more annoying than getting a "repository out-of-date" warning! Let's leave it to the user when he wants to refresh. E.g., often user just wants to quickly check whether a package is in the repository and doesn't need an up-to-date data. At least, ask him at the tool start-up, and only if the refresh is needed (current repomanager is able to check whether a refresh is needed, Duncan do we have a simple method for the check, or is it hidden in the code? something like RepoManager::isUpToDate(RepoInfo) would be nice). What i said above does not hold true for every SW management tool. For example, updater applets should always have up-to-date data (as Jiri says a few lines below). IMPORTANT: always respect autorefresh setting! ...on the second thought... :O) We have this _autorefresh_ setting in .repo file which can be enabled/disabled for each repository separately by the user. If we respect this setting, then forget what i said above and i'll be fine with crons and on-start refreshing :O) behavior clarification: - autorefresh disabled - refresh metadata ONLY ON USER REQUEST (e.g. zypper refresh, (new) Refresh button in YaST). - autorefresh enabled - application chooses when to refresh We should just think about whether to enable or disable it by default. Example use case: for online update repo (small repo with patches) i'd use autorefresh enabled and let whatever app needs it to refresh it as it sees fit. But for factory i want to be in complete control when it will be refreshed (because of the amount of resources it takes - time, CPU, network), so i'd use autorefresh disabled. BTW: for cronjobs i'd recommend something like zypper refresh --respect-autorefresh (not implemented yet :O) because otherwise it would try to refresh all sources. (Also there will be zypper refresh --force to force refresh even if zypp indicates that it is not needed, but that's just by the way...) > There are two kinds of tools: > 1. Tools which take care of having the system up-to-date. They must always > work on as fresh metadata as possible > 2. Tools which should install a package. They should work as fast as possible. > we can pay the price of installing package which already has an update at > least in some cases. > > Therefore we need two different policies depending on the kind of source > (this is optional) and on the operation user performs (they can be set > to vehave the same of course). > > How often refresh is being performed via cron (if it is) can be read from > the cron configuration, I don't think we need to put this information to > any configuration file. > > In addition to cron, I suggest adding following variables (comments hopefully > explain their meaning) > > > --- snip --- > > # should the on-line update paplication (eg. YOU) consider doing a refresh > # or should it rely on a cron job? > ONLINE_UPDATE_AUTO_REFRESH="yes" > > # if the time since last refresh is higher than specified amount of time, > # the update tools refresh the source first > # if it is an update source (provided we have the tags); 0 means to refresh > # always when starting the on-line update tool > # filtering on-line update sources is questionable (consistency) > ONLINE_UPDATE_REFRESH_INTERVAL="1h" > > # should the desktop applet perform any refresh or just rely on cron job? > DESKTOP_APPLET_REFRESH="yes" > > # define how often the desktop applet should perform refresh. > DESKTOP_APPLET_REFRESH_INTERVAL="3h" > > # master switch for enabling or disabling auto refresh for software > # management tools (eg. 'yast -i', 'zypper') > # if disabled, refresh must be performed manually or via cron > INSTALLER_AUTO_REFRESH="yes" > > # auto refresh interval for tools primarily installing packages, not doing > # update; "0" means always when initializing source(s) > INSTALLER_AUTO_REFRESH_INTERVAL="24h" > > --- snap --- > > The above variables can be added to /etc/sysconfig/sw_management. > > The way time is specified can be discussed, I guess that the granularity of > hours or at most minutes is perfectly sufficient, however, we may support > any of fixed units or specifying the units with the value (as in examples > above). > Cheers, Jano -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] Re: [yast-announce] yast2-gtk now imported to the YaST repository on svn.opensuse.org
by Ricardo Cruz 20 Jun '07

20 Jun '07

Ter, 2007-06-19 às 17:12 +0200, Jiri Srain escreveu: > Hi! > > The Gtk UI frontend for YaST has been imported to the YaST subversion and is > now available at > > http://svn.opensuse.org/svn/yast/trunk/gtk/ > Thanks Jiri! I have synced stuff done in the meanwhile, and instructions to do a checkout were posted in our wiki page: http://en.opensuse.org/YaST2-GTK Cheers, Ricardo > Please, work on this repository instead of the one on svnforge.novell.com. > > According to the Changelog file, the last change is following: > > 2007-05-23 Ricardo Cruz <rpmcruz(a)alunos.dcc.fc.up.pt> > > * src/ygtkwizard.c: changed title alignment. > > * src/ygtkfindentry.c: overload entry's context menu key binding > by our own, if set (see package selector). > > * src/YGUI.cc: ignore widgets without YGWidget representation > (ie. YWizard buttons wrappers). > > If you did any changes since then, make sure that they are also at > svn.opensuse.org and if needed, recommit them there. > > Thanks! > > Jiri > -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Re: [zypp-devel] ZYPP: TRUNK->BETA REFACTORING-BACKUP-10_3->STABLE
by Jiri Srain 20 Jun '07

20 Jun '07

Dne středa 20 červen 2007 13:31 Michael Andres napsal(a): > svn copy -r 5789 > http://svn.opensuse.org/svn/zypp/trunk/ > http://svn.opensuse.org/svn/zypp/branches/REFACTORING-BACKUP-10_3 > > > REFACTORING-BACKUP-10_3 is a snapshot of the latest libzypp revision > we comitted to STABLE. > > TRUNK is now submitted to BETA only, until all the outdated Source* > stuff is removed, an all applications switched to the new Repo* > classes. > > > How to handle it in YaST? In the past, we created a temporayr branch for the new stuff and kept submitting trunk to STABLE (so that it was consistent in the whole repository). Any reason why not to do it this way? Jiri > > > -- > > cu, > Michael Andres > > +------------------------------------------------------------------+ > Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 > +------------------------------------------------------------------+ > Michael Andres YaST Development ma(a)novell.com > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) > Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 > +------------------------------------------------------------------+ -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

2 2

Re: [yast-devel] Fwd: YaST font different from KDE apps?
by Martin Vidner 19 Jun '07

19 Jun '07

On Mon, Jun 18, 2007 at 10:57:05PM +1000, Mohammad Bhuyan wrote: > Hi Martin, > > My apologies to email you direct as many attempts to pass the image to > fails. The image is now attacked with this email. > > My original question: > > But then why the original fonts with default installation (with MS > fonts) were same everywhere (KDE & YaST). Once changed to Liberation > fonts in KDE, KDE apps shows Liberation fonts where YaSt shows the one > which I am trying to know what font that is? I have uploaded the image to http://en.opensuse.org/Image:YaST_or_desktop_font.jpg (but I don't know the answer to your question. Anyone?) -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

4 3

[yast-devel] Fwd: YaST font different from KDE apps?
by Mohammad Bhuyan 18 Jun '07

18 Jun '07

Hi, Sent the following email to opensuse list. Due to the image size couldn't send the email to this list. Regards, Mohammad ---------- Forwarded message ---------- From: Mohammad Bhuyan <nuxser(a)gmail.com> Date: Jun 16, 2007 4:08 PM Subject: YaST font different from KDE apps? To: SuSE Linux <opensuse(a)opensuse.org>, yast-devel(a)opensuse.org Hi, I am using Liberation fonts with Liberation Sans being my KDE desktop font. Quite happy with how its looks (even better with subpixel hinting) but noticed an issue with YaST. Fonts in YaST seems to be little different from the other apps. I need second (third, forth, more the marrier) opinion if it is indeed a different font or not. I have attached a snapshot. And if it is a different font then its a bug in Yast to ignore fonts imposed by kde configuration. Thanks, Mohammad -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 2

[yast-devel] YaST goes yellow-black :-)
by Katarina Machalkova 18 Jun '07

18 Jun '07

Hola! I've created new theme for text-mode YaST interface, so besides default white-on-blue one, you can now enjoy yellow-on-black theme, which will be applied in the future to urxvt-style terminals by default. Here are some preliminary screenshots: main window: http://users.suse.cz/~kmachalkova/mainwin.png sw_single module: http://users.suse.cz/~kmachalkova/swsingle.png release notes (richtext): http://users.suse.cz/~kmachalkova/relnotes.png Once feature #301893 is finished, you can pick text-mode YaST interface theme yourself by defining sysconfig variable Enjoy! B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

6 9

[yast-devel] How to display license agreement when using autoyast
by Harry Hart 15 Jun '07

15 Jun '07

Hello - Please forgive the very basic question, but I'm hoping someone can suggest a solution. How can I arrange for a license agreement to be displayed during an autoyast install? I have tried the following possibilities, but so far, none seems to work: 1. Turned on <confirm>true</confirm> in the autoyast XML control file. 2. Added a "workflow" and "module" element in the autoyast control file. 3. Added a license.zip file to one of the "add-on products" (This works when adding the "add-on" after installation, but not during auto-install.) 4. Added the yast2-firstboot package to the list of packages to be installed. If I understood how autoyast determines which YCP modules to run (and in what order), then I could try adding my own (to the "root" CRAMFS archive on the installation medium), but so far, I don't understand how to tell autoyast to run an additional new module. (I am using SLES 10, not OpenSUSE.) Any help, pointers, explanation would be much appreciated. Thanks in advance! - Harry -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2

[yast-devel] [PROPOSAL] adaptation of zypp apps to new repo management API
by Jan Kupec 15 Jun '07

15 Jun '07

Yesterday we (Prague YaST team) had a discussion about how to proceed with adaptation of YaST to the new repository management API of libzypp. First thing to note, the API has yet to mature in the upcoming days, as we test it with zypper and still modify it as needed. _After_ the API is declared done, we propose to proceed as follows: 1. document transition from old API to the new one (a method to method, code to code map) and post to yast-devel. 2. drop the old source management code from libzypp trunk 3. submit libzypp trunk package to BETA (all dependent packages will then fail building and maintainers will get the notice). 4. maintainers of the dependencies adapt their code 5. after tuning, submit all the stuff to STABLE (in time for the last Aplha release) If you are a maintainer of a package affected by the changes in libzypp, please provide feedback on the new API as you start looking at it (probably after publishing the transition document). Cheers, jano -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] YCP return bug?
by Benji Weber 12 Jun '07

12 Jun '07

Hi all, Could someone tell me whether this is a bug in YCP or if I am misunderstanding the documentation, it is certainly counter-intuitive. The documentation (http://forgeftp.novell.com//yast/doc/SL10.2/tdg/id_ycp_return.html) states: The return statement immediately leaves the current function or a current top level block (that contains it) and optionally assigns a return_value to this block. If blocks are nested, i.e. if the current block is contained in another block, the return statement leaves all nested blocks and defines the value of the outermost block. Therefore I would expect the following programme to print "One" "Two" "Three". However, it actually prints "One" "One" "Three". { string One() { return "One"; } string Two() { string value = "One"; foreach(string str, ["Two"], { return str; }); return value; } string Three() { string value = "One"; foreach(string str, ["Three"], { value = str; }); return value; } y2milestone(One()); y2milestone(Two()); y2milestone(Three()); } _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

5 7

[yast-devel] [Bruno Haible] Re: xgettext: Extracting comment blocks from YCP files
by Karl Eichwalder 12 Jun '07

12 Jun '07

Please, change comments in YCP source files as explained in the attachment, if time permits. This bug surfaced along with https://bugzilla.novell.com/show_bug.cgi?id=230388 aTdHvAaNnKcSe! Karl -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

2 1