November 2007 - YaST Development - openSUSE Mailing Lists

[yast-devel] YaST2 User config -> Ldap config
by Günther J. Niederwimmer 14 Nov '07

14 Nov '07

Hello, is there a simple way, to change the default opening from YaST2 User config module, for default ldap user mode ? Thank's for a answer -- mit freundlichen Grüßen / best Regards Günther J. Niederwimmer -- 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] YaST ui mode simple -> expert
by Günther J. Niederwimmer 12 Nov '07

12 Nov '07

Hello, is there a simple method to change the YaST2 to expert ? The Problem is, the YaST2 module yast2-mail (server) needed dns-server (LDAP), but with YaST2 simple, I can't configure dns-server with ldap support ? -- mit freundlichen Grüssen / best Regards Günther J. Niederwimmer -- 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] Three New yast-devtools Scripts, Three New openSUSE Articles
by Lukas Ocilka 09 Nov '07

09 Nov '07

Hi, I've just finished these three articles about three new tools in yast2-devtools (since 2.16.2): * Script: check_deps Generates output based on YCP or Perl modules imported in the source code. It can be used to check which other YCP/Perl modules are in use in your YaST module just to adjust RPM dependencies correctly. http://en.opensuse.org/YaST/Development/Devtools/check_deps * Script: gen_logic_deps Generates configuration file for 'dot' program (to generate graphical representation of dependencies). It uses check_deps script. http://en.opensuse.org/YaST/Development/Devtools/gen_logic_deps * Script: gen_logic_deps_nodes A simple wrapper script that uses output of gen_logic_deps script to generate graphical representation of only those packages that we are interested in. http://en.opensuse.org/YaST/Development/Devtools/gen_logic_deps_nodes Have a nice weekend Lukas

1 0

[yast-devel] Video of Mac OS X upgrade (Tiger -> Leopard)
by Joerg Kress 09 Nov '07

09 Nov '07

Hi, a video with an upgrade of Mac OS is now online at: http://public.littlecornerofthe.net/research/leo-upgrade.mpg.ogg It's edited for length, without those lengthy "doing something and updating the progress bar"-moments. The locale is German, sorry ;-) Other specs: We recorded only every 2nd frame as such the "realtime" parts are actually twice as fast in the video. I will do a writeup of things that are interesting to note. Any recommendations where to put those notes and a link to the video in the wiki? btw: it's not that exciting, seems like Apple thought the upgrade process is not worth the bling. Cheers, Josh -- Joerg Kress <jkress(a)suse.de> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

Re: [yast-devel] openSUSE 11.0 - Splitting YaST packages - Call for help
by Lukas Ocilka 09 Nov '07

09 Nov '07

Ruediger Oertel napsal(a): > at the moment this looks pretty nice, I don't have any cycle in > the yast2 area in recent distributions, only in 10.1 and SLES10. > But I'll be happy if we can keep it that way in STABLE. > > > STABLE,10.3,10.2: clean Well, there are some build cycles :( source # grep -r "#\!BuildIgnore" */*.spec.in bootloader/yast2-bootloader.spec.in:#!BuildIgnore: autoyast2-installation schema/yast2-schema.spec.in:#!BuildIgnore: yast2-build-test yast2-online-update schema/yast2-schema.spec.in:#!BuildIgnore: tomcat5 update/yast2-update.spec.in:#!BuildIgnore: autoyast2-installation We should focus on these (if they are still valid). Have a nice whatever :) Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 1

[yast-devel] Theme: foo(bar) is deprecated, [please fix]
by Lukas Ocilka 09 Nov '07

09 Nov '07

Hi, We just had a discussion about deprecated YCP code builtins. You've definitely already mentioned these warnings in YaST log or when building a YaST package: [Parser] Warning: 'select ()' is deprecated [Parser] Warning: find(...) is deprecated, please fix [Parser] Warning: tolist(...) is deprecated, please fix [Parser] Warning: 'lookup()' is deprecated My proposal was to disable these deprecated builtins in openSUSE 11.0 but Martin Vidner objected that we should leave them for a backward compatibility and just document them better. In fact, these builtins don't make YCP core slower so pros and cons of backward compatibility sound really good. The current generated documentation doesn't document these deprecated builtins because someone has removed the documentation from source code :) So it's also sometimes hard to understand what the current code does and how to replace it with new syntax/builtin. So, how to improve the current situation? 1.) Unify those warnings (minor). 2.a.) Write a hint how to replace the deprecated builtin by a new one (in that warning). 2.b.) Write a page at openSUSE WIKI about replacing deprecated builtins with new ones (and write that URL in the warning). Any better ideas? Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 0

[yast-devel] Script for creating graphs from ycp code
by Daniel Fiser 09 Nov '07

09 Nov '07

Hi, I have created simple python script for creating graph of includes/imports from ycp scripts. The script generates graph in dot format (see www.graphviz.org) and it can be transformed to a lot of formats (see man dot). Some basic usage is written in help (just run script without paramters). Script is attached (ycp_graph) and I attach some graphs generated by this tool too. Graph bootloader-graph.png is generated by command: $ ./ycp_graph /usr/share/YaST2/clients/bootloader.ycp 10 BootArch \ BootCommon BootELILO BootGRUB BootLILO Bootloader \ BootPOWERLILO BootZIPL > bootloader-graph.txt $ dot -Tpng -obootloader-graph.png bootloader-graph.txt Graph firewall-graph.png by command: $ ./ycp_graph /usr/share/YaST2/clients/firewall.ycp 10 \ SuSEFirewallCMDLine SuSEFirewallUI SuSEFirewall \ SuSEFirewallServices SuSEFirewallExpertRules \ SuSEFirewallProposal > firewall-graph.txt $ dot -Tpng -ofirewall-graph.png firewall-graph.txt I hope it can help someone to cipher out some yast module as it helped me with bootloader :). Cheers, Dan

1 0

[yast-devel] Fwd: discussion about YaST infrastructure and foundation
by Duncan Mac-Vicar Prett 08 Nov '07

08 Nov '07

I am forwarding an extract of a discussion we had internally but we would like to open it so everyone can express their feedback and opinions. ---------- Forwarded Message ---------- Date: Wednesday 07 November 2007 From: Duncan Mac-Vicar Prett <dmacvicar(a)suse.de> To: Klaus Kaempf <kkaempf(a)suse.de> In YaST we have a problem. We don't have a multi-language/API foundation strategy. Which languages we support, and which we write our infrastructure in. Right now we have the YCP layer as a hub between languages, which gives us a nice component framework where we could write clients in any language and modules in any language. If we stay with this strategy, we need to fix two big issues: a) market YCP as a component model, and not as a language b) provide a easy way to glue natve code to ycp components. Last time I looked how pkg-bindings is implemented, it is _sick_ and you have to deal with symbol tables etc. The most sane way is generating perl bindings and then using it as a component. Why not auto-generating direct ycp glue? Once you follow the dependencies outside of YaST core, YaST is not that "light". The other possible strategy is to choose a platform, say Python, Ruby whatever, and that mean rewriting, which is what we will not do. The other possible strategy is to migrate our existing code to some standard infrastructure. The most known are jvm and CLR. LLVM probably won't qualify because it is too low level and Parrot seems to be still vaporware in respect of language support. If we are able to migrate (recompile) our code to one, it means we gain all target language compilers and that we can make use of the code writen in any of those plus all the code which is already written out there. Also we would gain nice IDEs, debuggers, profilers, standard tools and others. Only when I write Java in Eclipse I realize how much C++ tools suck. (no CDT is not good enough). I don't know more strategies. If anyone knows another one, speak up!. I don't know also which one is the best. I want all lines of research open, and if it possible, try them. Duncan ------------------------------------------------------- Date: Wednesday 07 November 2007 From: Klaus Kaempf <kkaempf(a)suse.de> To: Duncan Mac-Vicar Prett <dmacvicar(a)suse.de> I'd recommend to take this thread on yast-devel ! * Duncan Mac-Vicar Prett <dmacvicar(a)suse.de> [Nov 07. 2007 13:03]: > > In YaST we have a problem. We don't have a multi-language/API foundation > strategy. > > Which languages we support, and which we write our infrastructure in. Right > now we have the YCP layer as a hub between languages, which gives us a nice > component framework where we could write clients in any language and modules > in any language. > > If we stay with this strategy, we need to fix two big issues: > a) market YCP as a component model, and not as a language That was the original intention: YCP as a low-level, abstract, non-binary protocol / model to glue different components, namely the backend (scr) and the frontend (UI) together. However, nowadays there are standardized, open-source means available for both the backend (hal/dbus for local, cim for remote) and frontend (html/css being the most prominent) available. We'd rather deprecate ycp going forward and look for migration strategies away from it. > b) provide a easy way to glue natve code to ycp components. Last time I looked > how pkg-bindings is implemented, it is _sick_ and you have to deal with > symbol tables etc. The most sane way is generating perl bindings and then > using it as a component. Why not auto-generating direct ycp glue? Sure, why not ? I think the ycp layer still gives us a lot of unexplored capabilities and I hope the 'language independence' workgroup will look into them. > Once you follow the dependencies outside of YaST core, YaST is not > that "light". Right. And following customers requests, we'd rather fix this too. > > The other possible strategy is to choose a platform, say Python, Ruby > whatever, and that mean rewriting, which is what we will not do. Rewrite from scratch ? Certainly not. Migrating from YCP to another language platform ? Why not ? > > The other possible strategy is to migrate our existing code to some standard > infrastructure. The most known are jvm and CLR. LLVM probably won't qualify > because it is too low level and Parrot seems to be still vaporware in respect > of language support. If we are able to migrate (recompile) our code to one, > it means we gain all target language compilers and that we can make use of > the code writen in any of those plus all the code which is already written > out there. This includes a high risk of 'language chaos' with every component written in a different language, all glued together by a VM. A scenario we better stay away from. The current situation (bad support for popular/useful languages) is as bad as having no limits at all. We have to define requirements and limits and, based on them, make a platform/strategy decision. > Also we would gain nice IDEs, debuggers, profilers, standard tools and > others. Only when I write Java in Eclipse I realize how much C++ tools > suck. (no CDT is not good enough). Availability of tools is a very important decision factor. > > I don't know more strategies. If anyone knows another one, speak up!. I don't > know also which one is the best. I want all lines of research open, and if it > possible, try them. Research looks at technical possibilities, then market/budget requirements will limit them to a reasonable number. Klaus ------------------------------------------------------- ------------------------------------------------------- ---------- Forwarded Message ---------- Date: Wednesday 07 November 2007 From: Stanislav Visnovsky <visnov(a)suse.cz> Dňa Wednesday 07 November 2007 13:02:54 Duncan Mac-Vicar Prett ste napísal: > > In YaST we have a problem. We don't have a multi-language/API foundation > strategy. > > Which languages we support, and which we write our infrastructure in. Right > now we have the YCP layer as a hub between languages, which gives us a nice > component framework where we could write clients in any language and > modules in any language. > > If we stay with this strategy, we need to fix two big issues: > a) market YCP as a component model, and not as a language > b) provide a easy way to glue natve code to ycp components. Last time I > looked how pkg-bindings is implemented, it is _sick_ and you have to deal > with symbol tables etc. The most sane way is generating perl bindings and > then using it as a component. Why not auto-generating direct ycp glue? > Once you follow the dependencies outside of YaST core, YaST is not > that "light". > > The other possible strategy is to choose a platform, say Python, Ruby > whatever, and that mean rewriting, which is what we will not do. In the end, we will have to decide the preferred language, just to be able to maintain the stuff, having backup maintainers etc. From that point, I don't see many arguments why not move slowly toward that, on case-by-case basis. > > The other possible strategy is to migrate our existing code to some > standard infrastructure. The most known are jvm and CLR. LLVM probably > won't qualify because it is too low level and Parrot seems to be still > vaporware in respect of language support. If we are able to migrate > (recompile) our code to one, it means we gain all target language compilers > and that we can make use of the code writen in any of those plus all the > code which is already written out there. Also we would gain nice IDEs, > debuggers, profilers, standard tools and others. Only when I write Java in > Eclipse I realize how much C++ tools suck. (no CDT is not good enough). We would also get all the politics and myths attached to those technologies. Unfortuantelly, they will only add, not replace ones we already have attached to YaST ;-) > > I don't know more strategies. If anyone knows another one, speak up!. I > don't know also which one is the best. I want all lines of research open, > and if it possible, try them. I believe the overall impression for those technologies are going against us, and you cannot do much about it. Java will be the slow virtual machine and great development platform for next 10 years. Mono will be patent-ridden and Microsoft for the next 10 years. I'm afraid we cannot afford at this point to get into that game as it will just worsen the YaST image. I'd hope to be proven wrong! Stano -- 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] YCP toXml() and symbol table
by Duncan Mac-Vicar P. 06 Nov '07

06 Nov '07

Hi hackers <symbols> <symbol global="1" category="filename" type="unspec" name="simple-1.ycp"/> <symbol category="function" type="function" name="foobar"/> <symbol category="variable" type="string" name="foo"/> </symbols> is function symbol type meant to be "function" or is a bug in the xml output? I browsed the code quickly but could not find if function sets the symbol type to something. If not, how can I know the return type? Duncan -- 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] EmbeddablePackageCallbacks
by Benji Weber 05 Nov '07

05 Nov '07

Greetings all, I've created a separate EmbeddablePackageCallbacks , should mean you can try it without breaking everything that uses the existing callbacks. It's rather hacky atm, but is semi functional. ymp installation: http://bw.uwcs.co.uk/new_callbacks/new_callbacks_oci.ogg sw_single starting: http://bw.uwcs.co.uk/new_callbacks/new_callbacks.ogg You'll need in YaST/modules http://bw.uwcs.co.uk/new_callbacks/EmbeddablePackageCallbacks.ycp [new file, needs ycpc -c] http://bw.uwcs.co.uk/new_callbacks/PackageCallbacksInit.ycp [replaces existing file, needs ycpc -c] And to try out in YaST/clients http://bw.uwcs.co.uk/new_callbacks/sw_single.ycp http://bw.uwcs.co.uk/new_callbacks/OneClickInstallWorker.ycp modified to use embedded progress bars instead of popups. -- Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2