November 2007 - YaST Development - openSUSE Mailing Lists

[yast-devel] buttons buttons buttons
by Martin Schmidkunz 24 Oct '08

24 Oct '08

Hi, when testing openSUSE 11.1/SLES 11 I came across a rather curious situation: many modules have already switched their label from Abort/OK(Accept, Finish...) to the style guide compliant Cancel/OK label. However in every case there is a third, inactive "Back" button included. This doesn't make sense as there is nothing to go back and the dialog is just an overview. I suppose this is due to many of you using wizard.ycp as base template for creating your module. What do you think about using the button box (http://lizards.opensuse.org/2008/08/28/button-order-in-yast-trying-to-make-…) instead of the buttons of wizard.ycp? In my opinion this would have the following advantages: * consistent button order in pop ups and in the module * user would not need to deal with an inactive button * button order in YaST would be consistent with the desktop used by the user What do you think about that issue? Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz(a)novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 6

[yast-devel] 3 questions about yast....
by Roberto Angelino 28 Feb '08

28 Feb '08

OK. First some background: My customer has written a sles9->sles10 live update installation script. I just ran it via ssh. It uses autoyast (the sles10 version) and it installs onto a clean partition (i.e., a partition that isn't running sles9). It works, but they've had to mess with some of the ycp files. Note this script is specialized to their nodes because they only ship 2-3 type of nodes. It's not a general purpose script. Here are the 3 questions they have (for sles10 version): 1) After yast completes installation (i.e., post-install), the fstab is created. What yast module makes this call? It has to be in yast2-installation, but I can't find the connection between the installation and yast2-storage where WriteFstab() lives. 2) How does yast determine what the source partition to mount is? 3) bootloader_finish.ycp breaks the install at the end. They got the install to work by commenting out everything in bootload_finish.ycp. What does this file do? Thanks -robert -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

6 10

[yast-devel] Work report
by Stephan Kulow 12 Dec '07

12 Dec '07

Hi! For those seeing my commits on the commit list, I thought I give you a little report on what I did in your SVN: http://www.kdedevelopers.org/node/3119 What's not written in there: the way it's implemented relies on a fixed size of 1024x768 and I bet on my laptop screen to even look just as bad as on the screenshot. But that's details - and basically out of scope of ITO :) Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 5

[yast-devel] Language::language (and maybe other variables / functions)
by Lukas Ocilka 10 Dec '07

10 Dec '07

Hi, As I've already written, I'm just trying to break some YaST*.rpm dependencies (See thread "[yast-devel] openSUSE 11.0 - Splitting YaST packages - Call for help"). I've found that there might be a candidate for moving some functionality (or only variable) to yast2.rpm or somewhere similarly. It is: +-------------------------------------------------+ | modules/Language.ycp, namely Language::language | +-------------------------------------------------+ These modules use Language YCP module: add-on autoinstallation firstboot installation metapackage network packager Language.ycp is part of yast2-country which directly uses (requires) these rpms: yast2 yast2-bootloader yast2-storage yast2-x11 I'm writing to the yast-devel mailing-list first before asking yast2-country maintainer to move Language::language (or more) somewhere else because I want to know where you think it is a good idea, whether it would help your modules at all ;) So, let me know, please :) Bye and Thanks! Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic clients/release_notes_popup.ycp: string tmp = sformat (path_templ, Language::language); clients/release_notes_popup.ycp: tmp = sformat (path_templ, substring (Language::language, 0, 2)); clients/release_notes_popup.ycp: string tmp = sformat (path_templ, Language::language); clients/release_notes_popup.ycp: tmp = sformat (path_templ, substring (Language::language, 0, 2)); clients/inst_rpmcopy.ycp: Packages::SlideShowSetUp (Language::language); clients/inst_rpmcopy.ycp: Pkg::SetTextLocale (Language::language); clients/inst_rpmcopy.ycp: SlideShow::SetLanguage (Language::language); clients/yast_inf_finish.ycp: linuxrc["Language"] = Language::language; clients/inst_proposal.ycp: Pkg::SetLocale (Language::language); clients/inst_proposal.ycp: Pkg::SetAdditionalLocales ([Language::language]); clients/software_proposal.ycp: if (Pkg::GetPackageLocale () != Language::language) clients/software_proposal.ycp: Pkg::SetPackageLocale (Language::language); clients/software_proposal.ycp: if (! contains (Pkg::GetAdditionalLocales (), Language::language)) clients/software_proposal.ycp: add (Pkg::GetAdditionalLocales (), Language::language)); clients/inst_welcome.ycp:map welcome = CustomDialogs::load_file_locale(patterns,directory, Language::language); clients/language_auto.ycp: "language" : Language::language_on_entry, clients/language_auto.ycp: "languages" : Language::languages_on_entry, clients/language_auto.ycp: Console::SelectFont (Language::language); clients/language_proposal.ycp: string language_on_entry = Language::language; clients/language_proposal.ycp: (Language::languages == "" || Language::languages == language_on_entry) && clients/language_proposal.ycp: Language::languages = Misc::CustomSysconfigRead ("INSTALLED_LANGUAGES", "", clients/language_proposal.ycp: y2milestone ("languages got from target system: %1", Language::languages); clients/language_proposal.ycp: language_on_entry, Language::language, Language::languages); clients/language_proposal.ycp: if (force_reset && language_on_entry != Language::language) clients/language_proposal.ycp: "language_changed": (language_on_entry != Language::language ) clients/language_proposal.ycp: "language_changed": (language_on_entry != Language::language) clients/firstboot_language.ycp: string language_on_entry = Language::language; clients/firstboot_language.ycp: if( Language::language != language_on_entry || Language::ExpertSettingsChanged ) clients/language.ycp: splitstring (Language::languages, ",")); clients/language.ycp: y2milestone ("canceled -> restoring: %1", Language::language_on_entry); clients/language.ycp: Language::Set (Language::language_on_entry); clients/language.ycp: Console::SelectFont (Language::language); clients/language.ycp: Language::language, selection[Language::language,1]:"")); clients/language.ycp: string languages = Language::languages; clients/language.ycp: splitstring (languages, ","), ``(lang_code != Language::language)); clients/language.ycp: string language = options["lang"]:Language::language; clients/language.ycp: Language::languages = mergestring (llanguages, ","); clients/language.ycp: if (language != Language::language) clients/select_language.ycp: string language = Language::language; clients/select_language.ycp: list<string>languages = splitstring (Language::languages, ","); clients/select_language.ycp: // with the default selection according to Language::language clients/select_language.ycp: if (language != Language::language) clients/select_language.ycp: y2milestone ("Language changed from %1 to %2", Language::language, language); clients/select_language.ycp: Language::languages = clients/select_language.ycp: Language::languages = mergestring (selected_languages, ","); clients/inst_autoinit.ycp: Installation::encoding = Console::SelectFont( Language::language ); clients/inst_autoinit.ycp: UI::SetLanguage (Language::language, Installation::encoding); clients/inst_autoinit.ycp: WFM::SetLanguage (Language::language, "UTF-8"); clients/save_config_finish.ycp: string lang = Language::language; clients/inst_release_notes.ycp: Language::language, clients/inst_release_notes.ycp: substring (Language::language, 0, 2), clients/inst_productsources.ycp: language_long = Language::language; include/packager/load_release_notes.ycp: string tmp = sformat (path_templ, Language::language); include/packager/load_release_notes.ycp: tmp = sformat (path_templ, substring (Language::language, 0, 2)); include/installation/inst_inc_second.ycp: Pkg::SetLocale (Language::language); include/installation/inst_inc_second.ycp: string language = Language::language; include/installation/inst_inc_first.ycp: Installation::encoding = Console::SelectFont (Language::language); include/installation/inst_inc_first.ycp: UI::SetLanguage (Language::language, Installation::encoding); include/installation/inst_inc_first.ycp: WFM::SetLanguage (Language::language, "UTF-8"); modules/AutoinstClone.ycp: general["language"] = Language::language; modules/Timezone.ycp: string new_timezone = lang2tz[Language::language]:""; modules/Timezone.ycp: GetTimezoneForLanguage( Language::language, "US/Eastern"); modules/Timezone.ycp: * Uses Language::language for translation. modules/Packages.ycp: string language = Language::language; modules/Packages.ycp: list<string> locales = LocaleVersions (Language::language); modules/Packages.ycp: Pkg::SetTextLocale (Language::language); modules/Packages.ycp: force_reset, reinit, Language::language); modules/Packages.ycp: Pkg::SetAdditionalLocales ([Language::language]); modules/Keyboard.ycp: * Uses Language::language for translation. modules/Keyboard.ycp: default_keyboard = GetKeyboardForLanguage( Language::language, "english-us" ); modules/Keyboard.ycp: GetKeyboardForLanguage ( Language::language, "english-us" ); modules/ProductLicense.ycp: Language::language, modules/ProductLicense.ycp: substring (Language::language, 0, 2), // "it_IT" -> "it" modules/ProductLicense.ycp: y2milestone ("Preffered lang: %1", Language::language); modules/SlideShow.ycp: global string language = Language::language; modules/OneClickInstall.ycp: summary = YPX::SelectValue(xml,"/metapackage/group[@distversion='" + Product::name + "']/summary[@lang='" + Language::language + "']"); modules/OneClickInstall.ycp: summary = YPX::SelectValue(xml,"/metapackage/group[not(@distversion)]/summary[@lang='" + Language::language + "']"); modules/OneClickInstall.ycp: description = YPX::SelectValue(xml,"/metapackage/group[@distversion='" + Product::name + "']/description[@lang='" + Language::language + "']"); modules/OneClickInstall.ycp: description = YPX::SelectValue(xml,"/metapackage/group[not(@distversion)]/description[@lang='" + Language::language + "']"); modules/OneClickInstall.ycp: string summary = YPX::SelectValue(xml,THIS_REPO_XPATH + "summary[@lang='"+ Language::language +"']"); modules/OneClickInstall.ycp: string description = YPX::SelectValue(xml,THIS_REPO_XPATH + "description[@lang='"+ Language::language +"']"); modules/OneClickInstall.ycp: string summary = YPX::SelectValue(xml,THIS_SOFTWARE_XPATH + "summary[@lang='"+ Language::language +"']"); modules/OneClickInstall.ycp: string description = YPX::SelectValue(xml,THIS_SOFTWARE_XPATH + "description[@lang='"+ Language::language +"']");

4 5

[yast-devel] Re: [opensuse-factory] Accessible installer
by Stanislav Visnovsky 07 Dec '07

07 Dec '07

Let's move to yast-devel. Dňa Wednesday 28 November 2007 04:23:55 Hans Petter Jansson ste napísal: > The GNOME team set up a wiki page for 11.0 ideas. One of the requests is > for accessibility options to be available in the YaST installer, in > particular: > > * Screen magnifier - shows a magnified version of the portion of the > screen you're pointing at. > > * Screen reader - reads the labels and input text out loud. > > * Braille output - provides tactile display of labels and input text via > a special device. > > In GNOME, we use Orca to accomplish this, together with the at-spi > infrastructure. It is a Python app. I don't know what Qt/KDE uses, but I > imagine something similar. > > So I have some questions for the YaST/installer guys: > > * What accessibility technologies are available in the installer today, > and how are they configured? AFAIK, we have support for visually impaired people: - linuxrc can be run in linemode to allow screen readers - yast2 ncurses interface has high contrast color scheme available - there is support for braille peripherials > > * If we're missing accessibility functionality, how feasible would it be > to implement it for 11.0? Depends on the technology. One constraint I see right away is the size of of inst-sys, we would need to do some magic there to keep it reasonably sized. First, we would need to know exactly what we want to support. The 3 points above? Stano > > * Given that the installer is a Qt app, what technologies could we use? > > Also see > > http://en.opensuse.org/GNOME/Ideas/11.0#Accessibility -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

5 8

[yast-devel] Re: [opensuse-factory] Help Wanted: Move YaST tutorials from forgeftp.novell.com to openSUSE WIKI
by Lukas Ocilka 30 Nov '07

30 Nov '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote: > jdd wrote: >> Lukas Ocilka wrote: >> >>> I don't think there need to be a tutorial about "How to use YaST" :))) >> >> you think badly. > > please don't worry. I just jumped a little too fast on the keyboard and, > reading my mail, I find it too (much too) harsh. > > I appreciate greatly your work. I only think you underestimate the need > of documentation Easy :) It's true that several YaST modules would need help from our users. Yes, we are well aware of that and we are constantly pushing hard to make our modules more and more useful. Some examples: * Fully-open our development SVN (the newest YaST source code) (we accept patches) * Fully-open YaST documentation (we accept patches) * Generated documentation at http://forgeftp.novell.com * Fully-open IRC (irc.freenode.net) * Fully-open yast-devel(a)opensuse.org maililing-list However, it's also true that our view is a bit shaded by the knowledge we have. We'd appreciate if the community helped us to see what they don't understand well, why is that hard to understand, and how to improve the current state. What we need is the users' feedback, ideas, opinions, or even patches ;), ... As you certainly know, I've asked the openSUSE community what they wanted from YaST SSH Configuration module, I wanted to hear their opinion on the current implementation, labels, helps, etc. There hasn't been much feedback, but frankly, YaST SSHD is almost 'unused' YaST module ;) For the YaST documentation, there is a openSUSE manual available and also WIKI page for every single YaST module: http://en.opensuse.org/YaST/Modules Your example (YaST Printer): http://en.opensuse.org/YaST_Printer Well, tell us what you want :) Please. Thanks and Bye Lukas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHUHlTVSqMdRCqTiwRApTUAKCLNAUGC1lZf4nUsAybKl2/0uMtWwCbBOX2 ZR5XZD1QGVkLPzEJr0bdHk8= =tswe -----END PGP SIGNATURE----- -- 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] Help Wanted: Move YaST tutorials from forgeftp.novell.com to openSUSE WIKI
by Lukas Ocilka 30 Nov '07

30 Nov '07

Hi, I've added a new idea to idea.opensuse.org | Move YaST tutorials from forgeftp.novell.com to openSUSE WIKI | http://idea.opensuse.org/content/ideas/move-yast-tutorials-from-forgeftp.no… We are currently working on implementing features and that's why the documentation is a bit loosing at the end of the queue. On the other hand, moving those YaST tutorials can: * Help you to gain a respect from openSUSE community as well as from YaST developers :) ;) * Help you to understand YaST a lot more Additionally, this is not only about moving some texts somewhere else, you are expected to bring new ideas, new tutorials, you can realize your dreams :))) * * * * * More about idea.opensuse.org: It's a web/page for sharing ideas how to improve (openSUSE) Linux and also implementing those ideas. Maybe you are good designer but can't write in any programming language. Maybe you can just write in Perl or C++ and you are really good at it :) ... idea.opensuse.org is the best way to go! File an idea there or pick already filed one. * * * * * Thanks in advance Bye Lukas PS: YaST developers and their (development-related) help can be found also on IRC at irc.freenode.net, channel #yast -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 0

[yast-devel] symbols in builtins
by Duncan Mac-Vicar Prett 30 Nov '07

30 Nov '07

Hi y2hackers For a normal namespace I can do: for (unsigned int i=0; i < ns->symbolCount(); ++i) { SymbolEntryPtr s = ns->symbolEntry(i); Yes, I can also access the symbol table, which is the most useless structure as you can't iterate it and everything useful is private and everything useless is public ;-) But that iteration is enough to know the name of the symbols the namespace offers and their type (variable, function, etc). However, for a builtin., extern StaticDeclaration static_declarations; declaration_t *bi_dt = static_declarations.findDeclaration (qualified_name); and then create the call using the declaration YEBuiltin *bi_call = new YEBuiltin (bi_dt); IIRC from the declaration, I can get the symbol table, but as I said it is like getting nothing. Is there a way to get the symbol count and access every symbol somehow? Cheers! Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 1

[yast-devel] Re: [opensuse-factory] YaST Extension: Progress with Icons
by Lukas Ocilka 29 Nov '07

29 Nov '07

Will Stephenson napsal(a): > On Thursday 29 November 2007, Lukas Ocilka said: >> PS: It's currently implemented by replacing images with another ones but >> it would be better if there was a native Qt/GTK support for making >> images gray-scaled (initial state) and then make them colored again >> (active). Would it be possible? Thanks. > > Yes, in Qt4 see > QPixmap QIcon::pixmap ( const QSize & size, Mode mode = Normal, State state = > Off ) const > > in Qt3 it's in QIconSet. > > Will Great! :) Would be somebody so kind and implement such option to yast2-qt for me :)? The YaST Qt SVN is here: http://svn.opensuse.org/svn/yast/trunk/qt/ Thanks in advance Lukas

2 1

[yast-devel] YaST Extension: Progress with Icons
by Lukas Ocilka 29 Nov '07

29 Nov '07

Hi, I've just implemented a new feature of the YaST 'Progress' module: | Icons shown during the progress run | I hope you find it useful and that we get more icons to the UI to make it brighter, cooler, and ... ;) See this article with screen-shots: http://en.opensuse.org/YaST/Development/Progress_With_Icons (This feature is available in yast2-2.16.16 and later) Bye Lukas PS: It's currently implemented by replacing images with another ones but it would be better if there was a native Qt/GTK support for making images gray-scaled (initial state) and then make them colored again (active). Would it be possible? Thanks. -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 0

[yast-devel] sw_single Acccessibility Category
by Bryen 29 Nov '07

29 Nov '07

We're working on figuring out what all the accessibility tools software already exists. For now, we're looking at gnome.org's accessibility documentation and then running searches in sw_single to determine whether we have it already. But some tools listed in their documentation is named differently on our end. For example: gnome-online-keyboard in the documentation is gok in our repository. We think it would be well worth it if an accessibility category could be added so users could easily narrow down what tools are available for download/already-installed. Would it be feasible to add such a category? I would be more than happy to compile a list over the next few months of such tools so we can populate the category. Thanks! -- ---Bryen--- -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 5

[yast-devel] Redesign of YaST Control Center
by Thomas Goettlicher 29 Nov '07

29 Nov '07

Hi everyone, we want to redesign the YaST Control Center. Therefore we are looking for a radical new design. This is your chance to share your ideas regarding YaST Control Center. Please feel free to contribute with mockups and (unconventional) ideas here: http://en.opensuse.org/YaST/Development/New_Control_Center Thanks, Thomas --- 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

5 6

Re: [yast-devel] Wt and Yast
by Wim Dumon 28 Nov '07

28 Nov '07

On Nov 26, 2007 4:32 PM, Stanislav Visnovsky <visnov(a)suse.cz> wrote: > Hi Wim! > > Cool to see you here! > It's our pleasure to see that Wt is considered for Yast. <snip> > > The biggest issue I've faced was the fact that almost every functionality in > the Wt classes went down to figuring out the session, and this info seems to > be depend on the boost thread-local storage. So, I needed to be very careful > in which thread I'm running, creating additional overhead. > See my other post, I think you should structure it differently so that you don't need any thread switching at all. > YaST has a base component library, which provides the main() function. This > function evaluates the commandline arguments, picking client (typically YCP > code) and server (typically UI). You should accept that a single web daemon will be able to serve multiple yast sessions, and thus it is started in a way not specific to a particular user, but rather as a plain daemon. The way you start yast from the command-line is on the same level as where a particular user surfs to the daemon and starts a new session. That will cause the 'create application' callback (argument of Wt::WRun) to get called, from which you have to return a WApplication object. If multiple users are surfing to the Yast website simultaneously, multiple Yast applications are running simultaneously, either as separate unix processes or within the same unix process, depending on your wt deployment options. > In threaded example, YCP code is started and when it first encounters UI call, > it calls the UI component (*). The component then finally creates a real UI, > starting a thread to handle events and redraws (call it UI thread). Every UI > call from YCP synchronizes with the UI thread via 2 pipes implementing > message passing, the real UI functionality is always evaluated in the UI > thread. > I suggest you do something like this, since it only changes the bootstrap, and considers the YCP as a "worker" thread spawned from the Wt event loop: - createApplication() [in the Wt thread], creates a YCP thread, and waits for a synchronization signal from the worker thread. - YCP thread triggers UI code which sets up synchronization pipes and signals the Wt thread - Wt thread creates the WApplication and (and anything else). From here on it should be the same story as the Qt UI, but instead of running app->exec() method, it returns the Application instance. Bottom line: As Wt is an 'application server', it can cause multiple Yasts to be started (one per user surfing to the application server). We recommend to write your program in such a way as if the 'create application' callback that you specified as parameter of Wt::WRun() is the 'main()' function of what you would have written in a Qt application. The main task of main() in a Wt application is to call Wt::WRun(). Regards, Wim. -- 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] Wt and Yast
by Wim Dumon 27 Nov '07

27 Nov '07

On Nov 26, 2007 3:24 PM, Duncan Mac-Vicar Prett <dmacvicar(a)suse.de> wrote: > > On Monday 26 November 2007 11:49:05 Wim Dumon wrote: > > Hello Duncan and others, > > <snip> > > Could you provide us with some insights about your architecture and > > how you integrate Wt? We may be able to help you out so that Wt and > > Yast become good friends (e.g. by implementing something similar to > > QSocketNotifier?) > > For me QSocketNotifier was the missing part, as Qt offers a way to react to a > socket event while still integrating the event loop. Working on it - we will let you know when it is in CVS. > Also, is there a way in Witty to get into and out of the event loop? What do you mean with that? > Anyway, in case of getting further, we still faced some basic design problems, > like the UI having to run as root, unless we used fcgi, for which there too > many missing pieces in YaST (authentication?) > I don't know why you would have to run a Wt process as root... It's probably not an issue to let Wt listen to a port >= 1024 (possibly using apache to forward connecitons from port 80 to the Wt process) - the rest depends on the Yast architecture. And yes, it is wise to implement some form of authentication, but the user interface part in Wt should be straight-forward. >From a user perspective, the way I would envision using a yast web GUI, is by having a (non-root) daemon spawned from init.d, thus at boot time. Then, instead of logging in to the server (authenticating through ssh) and starting yast, I surf to the web page, authenticate there and "start" yast. This assumes that your main() routine only starts whttpd, and in your 'create application' callback function, after authentication, you are at the same level as a Qt application. Remind that in Qt you have to call app->exec(), whereas in Wt you need to return a WApplication from the this callback function - by returning this WApplication object, you have created a new instantiation of the application. I can imagine that this is the main point of conflict with your current architecture? However, in this way, you don't need to spawn special threads for getting the Wt event loop going, and you can structure your application further as you do a Qt application (given that we add WSocketNotifier), since you are already running inside Wt's event loop? Regards, Wim. -- 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] Pkg-bindings - new wiki page at opensuse.org
by Ladislav Slezak 27 Nov '07

27 Nov '07

Hello developers, I have created a wiki page for pkg-bindings (http://en.opensuse.org/YaST_Pkg_Bindings) currently it's quite small but the most important for you are the change log pages where I summarized the changes which may influence other Yast modules. Here is a summary of changes in openSUSE 10.3 (compared to 10.2): http://en.opensuse.org/YaST_Pkg_Bindings-openSUSE_10.3 and in the current development branch (SVN trunk): http://en.opensuse.org/YaST_Pkg_Bindings-SVN_Trunk -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- 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] Wt and Yast
by Wim Dumon 26 Nov '07

26 Nov '07

Hello Duncan and others, We, the developers of Wt, are a bit surprised to see your efforts on integrating Wt with Yast causes crashes and other problems (we followed your progress on the yast mailing list and the comments on your blog). Normally, Wt runs uber-stable (e.g. on our public site) and we want to keep it that way, so we're very eager to know what exactly caused the crashes so that we can catch and fix the bugs. We picked up something about Wt's thread model being incompatible with Yasts use of threads. Therefore, we have patched Wt so that you can disable all use of threads completely (in our CVS version). Could you provide us with some insights about your architecture and how you integrate Wt? We may be able to help you out so that Wt and Yast become good friends (e.g. by implementing something similar to QSocketNotifier?) Thank you, Wim Dumon. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 3

[yast-devel] How to preselect a table entry?
by Johannes Meixner 26 Nov '07

26 Nov '07

Hello, how can I have a particular table entry preselected like an entry in a SelectionBox? Or how can I show a table without any entry preselected? It seems by default the topmost entry ina a table is preselected. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

6 8

[yast-devel] SVN access
by Stephan Kulow 26 Nov '07

26 Nov '07

Hi! I picked up branches/tmp/sh/qt4-port/, merged with mod-ui and finished the port to integrate well into the event loop and the threading. What I wonder though: 1. Can I continue my experiments in yast svn? git is all fine, but I only trust $HOME :) 2. is there an easy way I can keep it in parallel to sh's qt? E.g. just install as yast2-qt4 for the time being? Greetings, Stephan P.S. cmake anyone? :) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 2

Re: [yast-devel] How to preselect a table entry?
by Thomas Fehr 23 Nov '07

23 Nov '07

Hi Again, Lukas kindly reminded me that this is an english mailing list, sorry for forgetting that. Here my reply again in english: > how can I have a particular table entry preselected like > an entry in a SelectionBox? Basically with the following: string tag = (string)UI::QueryWidget(`id(`table), `CurrentItem); UI::ChangeWidget(`id(`table), `CurrentItem, tag ); AFAIK nothing gets preselected, if one uses a value with ChangeWidget that does not exist in the table. Tschuess, Thomas Fehr -- Thomas Fehr, SuSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Markus Rex, HRB 16746 (AG Nürnberg) Tel: +49-911-74053-0, Fax: +49-911-74053-482, Email: fehr(a)suse.de GPG public key available. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 3

[yast-devel] improvements in ruby bindings
by Duncan Mac-Vicar Prett 23 Nov '07

23 Nov '07

Copied from: http://duncan.mac-vicar.com/blog/archives/281 After quite lot of hacking nights, I managed to get some yast2 ruby bindings improvements working. You might know that ycp is not only a language, but a component technology. Every component using the YaST2 technology can be reused from other YaST components no matter what language they are written in, as long as there are bindings for that. That was the original intention of the ruby bindings. So for example, there is a component call Storage, which is written in the ycp language. The component (well, it is really a namespace, but YaST sees it as a namespace component) is located in /usr/share/YaST2/modules/Storage.ycp (.ybc for the bytecode compiled version) and offers some medium level functions that YaST uses. This component needs low level access to the system, for which there is another module called Libstorage ( located in /usr/share/YaST2/modules/LibStorage.pm ) which in this case is written in perl which is a language YaST supports as long as you follows some simple rules. The reason is because libstorage is a C++ library, and there is no easy way to bind it to the YaST environment, but as YaST supports perl, you can generate perl bindings for the C++ library and all the library functionality will be available to other components in YaST. So repeat after me. ycp is not only a language. It is a communication protocol, used by YaST component framework. So, with the ruby bindings, you where able to do: require 'yast' m = YaST::Module.new("Storage") dp = m.GetDiskPartition("/dev/sda1") dp.each do | key, value | puts "#{key} #{value}" end But I was never happy with the syntax. The idea was that you construct a dynamic proxy for a YaST component and then call methods on it. This had some disadvantages: * If the component did not exist, you did not get an error till the method call * It was not possible to do introspection to the component, because the methods call where implemented using the method_missing hook. So basically the proxy responded to all methods and only raised an error if the equivalent call to the YaST side was not possible. So I decided to look for a new approach. This is the result till now: require 'yast' require 'ycp/storage' dp = YCP::Storage::GetDiskPartition("/dev/sda1") dp.each do | key, value | puts "#{key} #{value}" end Oh yes, you notice. First, there is no need to instantiate the module, a classic require will do it. The bindings modify the built-in require method, so if you require something under ycp/, a module is created on the fly. A real module, a real symbol. You can also import it manually using YCP::import Now, you can do this: puts YCP::Storage.methods When the module is imported, the symbols are declared in the module, so you can ask for them in the module. I still need to work on other symbol types, but it should be straight forward. The last improvement is that I simplified the C part of the bindings a lot, and moved most of the magic to pure ruby code, which makes easier to work with. Next improvement, the other way around, making nicer how to call ruby components from any other component. -- 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: [yast-commit] r42330 Moved setLanguage from YUI to YApplication
by Martin Vidner 23 Nov '07

23 Nov '07

On Thu, Nov 22, 2007 at 08:14:51PM -0000, sh-sh-sh(a)svn.opensuse.org wrote: > URL: http://svn.opensuse.org/viewcvs/yast?rev=42330&view=rev > Log: > Moved setLanguage from YUI to YApplication Please don't forget to update the dependencies when making incompatible changes across packages. (Like ncurses and qt requiring the new core version) This could be made automatic using autoreqprov if we took care about ABI versioning like it is done in libzypp. I will try to prepare simple instructions. Anyway, please submit yast2-core to autobuild when you have a consistent set of packages, so that liby2util can be finally put to rest. > > Modified: > trunk/core/libyui/src/YApplication.cc > trunk/core/libyui/src/YApplication.h > trunk/core/libyui/src/YUI.h > trunk/core/libyui/src/YUI_builtins.cc > trunk/core/package/yast2-core.changes > trunk/ncurses/package/yast2-ncurses.changes > trunk/ncurses/src/NCApplication.cc > trunk/ncurses/src/NCApplication.h > trunk/ncurses/src/YNCursesUI.cc > trunk/ncurses/src/YNCursesUI.h > trunk/qt/package/yast2-qt.changes > trunk/qt/src/YQApplication.cc > trunk/qt/src/YQApplication.h > trunk/qt/src/YQCheckBox.cc > trunk/qt/src/YQDumbTab.cc > trunk/qt/src/YQLabel.cc > trunk/qt/src/YQRadioButton.cc > trunk/qt/src/YQUI.h > trunk/qt/src/YQUI_builtins.cc > trunk/qt/src/YQUI_core.cc > trunk/qt/src/YQUI_x11.cc > trunk/qt/src/YQWizard.cc > trunk/qt/src/pkg/YQPackageSelectorBase.cc > trunk/qt/src/pkg/YQPkgConflictList.cc > trunk/qt/src/pkg/YQPkgPatternList.cc > trunk/qt/src/pkg/YQPkgRpmGroupTagsFilterView.h > trunk/qt/src/pkg/YQPkgSearchFilterView.cc > -- 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

1 0

[yast-devel] [Announcement] YaST-DOC in external SVN
by Lukas Ocilka 21 Nov '07

21 Nov '07

Hi, I've moved our additional YaST documentation to the external SVN at opensuse.org. See: http://svn.opensuse.org/svn/yast/trunk/doc/ It contains several scripts and XML files for generating XML documentation from sources, for building HTML from those XML files, etc. Some other add-on are there as well, such as tutorials. Several scripts still need to be adapted their new environment (external SVN). All from that place is used to generate the documentation stored at http://forgeftp.novell.com/yast/doc/ 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] ITO project proposal #1: Web user interface
by Duncan Mac-Vicar Prett 21 Nov '07

21 Nov '07

ITO time proposal YaST Web UI, Approach: Wt Why: - there is already a prototype from Stano - nobody has come wth a better approach? - It is C++ - It is similar to Qt - It offers AJAX - widget-centric (avoid the web indiscipline and mess) - integration with (existing) C++ libraries - Provides plain widgets, which work regardless of JavaScript availability (but benefit from JavaScript availability), and Wt::Ext widgets (based on http://extjs.com) - built in web server - no need to rewrite yast modules, only to "rework" them http://www.webtoolkit.eu/ (package available on home:dmacvicar in OBS) Current problems: - semantic: when is yast running? daemon? listening? only one session? how many users? - threading problems - completness (implement widgets) Goal: - solve the semantic issues - to be able to login and use very basic functionality of any module Time: proposal 4 days (too much too less?) When to start? Proposal Nov 12 Who takes care of the pizza? -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

5 13

[yast-devel] Mod-ui: HVStretch widget dropped
by Katarina Machalkova 20 Nov '07

20 Nov '07

Hola brave yast hackers! I'd like to use this way to announce that with mod-ui transition, HVStretch widget has been dropped and it should no longer be used. Should you still need it in your module, consider using e.g. `Empty, or some combination of `HStretch and `VStretch. These modules seem to be affected: ldap-client certify so please fix them accordingly, and if writing new code, please do not use HVStretch any more, to prevent crashes and other ugly things with new mod-ui. The documentation on UI widgets should be updated as well Thanks B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter

2 2

[yast-devel] YaST2 and Disk order
by Günther J. Niederwimmer 19 Nov '07

19 Nov '07

Hello, Know you that YaST2 change the Order of disk's anytime ? The Problem that I found, is with three disks and 17 Partitions on my Test System ? YaST2 have on install time, a different order for the Disks then in installed time ? One Problem YaST2 find on install time the swap partition on disk /dev/sdcX, after installing the swap partition is on /dev/sdbX, also when I config "/home" on /dev/sdcX later it is on /dev/sdbX :(. The grub menu.lst is also broken after installation :( A other Problem is, why find YaST2 a different Order of disk's (?), as ubuntu or fedora ? When i make a test installation with "ubuntu" or "fedora", i have the same disk order in both installation ? With SUSE I have a different disk order, and nothing is booting "normal" :( . -- 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] Commits available on irc
by Duncan Mac-Vicar P. 19 Nov '07

19 Nov '07

If you hang out in freenode, the channel #zypp has real time forwarding of commits to the subversion repository. For #yast, the commits go to #yast-commits as they have more traffic than ZYpp repo. The YaST bot includes the ZYpp commits too. Any setting can be changed, so lets see how it works this way! Cheers! Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

9 15

[yast-devel] Re: [opensuse-factory] YaST2 SSHD Module - Call for help/volunteers
by Lukas Ocilka 19 Nov '07

19 Nov '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lukas Ocilka wrote: > Robison, Jonathon (M.) napsal(a): >> Although you may be correct in that it needs polish, don't forget that this >> is a great step forward in getting CLI config tasks into YaST. Every >> marathon starts with the first step. >> >> Now if I could just get wpa_supplicant configuration into YaST . . . > >> See (and modify) http://en.opensuse.org/YaST_SSHD_Server/Enhancements_WIP I've filed some real enhancement request at this http://en.opensuse.org/YaST_SSHD_Server/Enhancements_WIP wiki page. The current YaST SSHD screenshots can be found here http://en.opensuse.org/YaST_SSHD_Server Some of enhancements are quite easy to do even if you don't known any programming language, what they actually need is just to think about the current wording and propose a better-understandable one. Thanks & Bye Lukas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHG1yIVSqMdRCqTiwRAgBzAKCZoAx4Hre8VuxtvGkkxGc/DY/8OwCglDwz seNqny1Q5oN1f1QCMvAKtTA= =HmZe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

4 6

[yast-devel] First mod-ui SVN trunk + STABLE / FACTORY
by Stefan Hundhammer 17 Nov '07

17 Nov '07

Advanced UI, inc. proudly presents: Package "yast2-core" checked into STABLE: ls -l /work/src/done/STABLE/yast2-core total 1884 -rw-rw-r-- 1 sh suse 1804299 Nov 16 20:25 yast2-core-2.16.6.tar.bz2 -rw-rw-r-- 1 sh suse 105504 Nov 16 20:25 yast2-core.changes -rw-rw-r-- 1 sh suse 4988 Nov 16 20:25 yast2-core.spec Package "yast2-qt" checked into STABLE: ls -l /work/src/done/STABLE/yast2-qt total 2156 -rw-rw-r-- 1 sh suse 2107385 Nov 16 20:25 yast2-qt-2.16.1.tar.bz2 -rw-rw-r-- 1 sh suse 81620 Nov 16 20:25 yast2-qt.changes -rw-rw-r-- 1 sh suse 2408 Nov 16 20:25 yast2-qt.spec yast2-ncurses will follow shortly. ------------------------------------------------------------------- yast2-core change log: - V 2.16.6 - Merged mod-ui branch to trunk: - Moved YCP code out of widget code (still to be done for some non-widget classes) - Clearer and consistent widget (C++) interfaces - Reasonable support for creating YWidgets from C++ - Now using widget factories for better abstraction and handling - Moved misc. YCP parsers out of widget classes to separate classes - Item parsers (YSelectionBox, YComboBox, YTree, YTable, ...) now more forgiving - Individual table cells can now queried and set in YTable - More informative error messages - Error messages in log now report the YCP code location - Renamed YTextEdit to YInputField (old name still valid) - Renamed YTime to YTimeField (old name still valid) - Renamed YDate to YDateField (old name still valid) - Dropped YColoredLabel widget (nowhere in use any more anyway) - Dropped UI::CollectUserInput() (nowhere in use) - Dropped YImage from YCPByteBlock (nowhere in use any more) - All YSelectionWidgets (YSelectionBox, YComboBox, YTree, YTable, YMultiSelectionBox, YMenu) now support UI::QueryWidget(`myWidget, `Items ) (returning an item list) - Consistent icon support for YSelectionWidgets (YSelectionBox, YComboBox, YTree, YTable, YMultiSelectionBox, YMenu) Background and more details at http://www.suse.de/~sh/y2-mod-ui.pdf http://www.suse.de/~sh/y2-ui-arch-old.pdf http://www.suse.de/~sh/y2-ui-arch-modular.pdf ------------------------------------------------------------------- As promised, all existing YCP code should keep working without changes. But there might still be some rough edges to be ironed out. If you have any problems, please contact me on IRC or via mail. Notice that this is just a first version. It's not the full, shiny, new standalone C++ lib yet that it wants to become. But we are getting there. CU -- Stefan Hundhammer <sh(a)suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- 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] SCR Agent: any-XML Parser
by Lukas Ocilka 16 Nov '07

16 Nov '07

Hi, I'd like to announce moving the *anyxml* SCR agent to *yast2.rpm*. This has been done because not only yast2-packager but also yast2-users found it suitable for parsing generic XML (see bugzilla #332187). What is this XML parser good for? It uses Perl module XML::Bare so it can parse every valid XML content, not only YaST-specific formats. Where can I find it? In yast2-2.16.11.rpm and later. How can I use it? See http://forgeftp.novell.com/yast/doc/SL10.3/scr/2.anyxml.html Is that new feature? Do we use it anywhere else? No, anyxml is in openSUSE since 10.3. We use it for Online Repositories. Example: --- anyxml.ycp --- { any xml = SCR::Read (.anyxml, "any.xml"); y2milestone ("XML: %1", xml); } --- anyxml.ycp --- --- any.xml --- <?xml version="1.0"?> <book> <author> <firstname>John</firstname> <surname>Fish</surname> </author> <copyright>2007</copyright> <content> <chapter> <title>Learn YCP in 20 Minutes</title> <para>hahaha</para> </chapter> </content> </book> --- any.xml --- Run: `/sbin/yast2 ./anyxml.ycp` and see the result in y2log... --- result in y2log --- test/anyxml.ycp:4 XML: $[ "book":$[ "author":$[ "firstname":$[ "pos":0, "value":"John" ], "pos":0, "surname":$[ "pos":1, "value":"Fish" ], "value":"\n\t" ], "content":$[ "chapter":$[ "para":$[ "pos":1, "value":"hahaha" ], "pos":0, "title":$[ "pos":0, "value":"Learn YCP in 20 Minutes" ], "value":"\n\t " ], "pos":2, "value":"\n\t" ], "copyright":$[ "pos":1, "value":2007 ], "pos":0, "value":"\n " ], "value":"" ] --- result in y2log --- author_firstname = foo["book","author","firstname","value"]:"Unknown"; Have a nice day Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 0

[yast-devel] y2base calling convention changed
by Stefan Hundhammer 16 Nov '07

16 Nov '07

I just learned the hard way after half a day of debugging that the current directory is no longer searched when executing YCP scripts. y2base HelloWorld.ycp qt no longer works. Instead, use y2base ./HelloWorld.ycp qt Regrettably, the error message is not informative. See also https://bugzilla.novell.com/show_bug.cgi?id=342213 CU -- Stefan Hundhammer <sh(a)suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- 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] 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

[yast-devel] Re: [zypp-devel] libzypp for openSUSE 11.0
by Stanislav Visnovsky 05 Nov '07

05 Nov '07

Dňa Monday 05 November 2007 10:29:13 Benji Weber ste napísal: > On 05/11/2007, Stanislav Visnovsky <visnov(a)suse.cz> wrote: > > Wow. Is this an actual code? > > Yes, but I modified PackageCallbacks which will break a lot of things. > I was going to create a new EmbeddableCallbacks or something that can > be used alongside. Cool! I'd suggest to create an experimental branch so everyone can try it out, maybe also using buildservice to get the packages. This is definitely very interesting! Stano -- 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] Time for cleanup... [now]
by Lukas Ocilka 05 Nov '07

05 Nov '07

Hi, It's just a time for digging our skeletons out of the code! I've done a simple `grep` for 'hacks' and 'ugliness' in our code. File is attached. Please, try to remove hacks if possible and next time, try to even avoid implementing 'hacks' ;) (because I'd find them again) ;) I have to admit that my `simple grep` for these skeletons is not 100% correct, not even 90%, there are several false-positive matches. Anyway, it shows that there are several pieces of code that really need rewriting for openSUSE 11.0. Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic add-on/src/add-on-workflow.ycp: // FIXME: this function is ugly add-on/src/add-on-workflow.ycp: // a little hack because of packager leaving autoinstallation/doc/web/xsl/myxref.xsl: autoinstallation/doc/misc/multiplesource-sa.dsl:;;Formal Paras are ugly by default! autoinstallation/doc/autoyast.dsl:;;Formal Paras are ugly by default! backup/src/functions.ycp: // chack if partition is now mounted backup/src/ui.ycp: // "Renaming", Cron settings, It seems to be a hack }8-> bootloader/src/modules/BootCommon.ycp: // testsuite hack bootloader/src/modules/BootELILO.ycp: // FIXME: UGLY HACK because of testsuites bootloader/src/routines/misc.ycp:// UGHLY HACK because of testsuites build-test/yast2-build-test.spec:- quick Beta hack: deleted macros from BuildRequires and insert control-center-gnome/etc/Makefile.am:# hacks core/agent-ini/src/IniFile.h: * @param rewrite a #19066 hack - if rewriting is active, .st accesses rewrite_by core/agent-ini/src/IniFile.h: * @param rewrite a #19066 hack - if rewriting is active, .st accesses rewrite_by core/agents-non-y2/ag_hostnames: #hack: not quoting $2 enables scanning for a particular version core/agent-modules/src/ModulesConf.cc:/* Temporary hack, the whole parser should be reworked */ core/libycp/src/YCPDebugger.cc: // discarded, thus this must be the last check. Kind of ugly! core/libycp/src/YBlock.cc: // HACK ahead: Y2ALLGLOBAL should make all core/libycp/src/YCPBuiltinTerm.cc:// not static to get seen by l_select hack core/libyui/doc/FAQs/why-widget-labels-above-and-not-at-the-left.txt:account by every YCP hacker - everywhere, in each dialog. core/libyui/doc/FAQs/notify-events.txt:how ui-ncurses behaves. It's up to the YCP hackers to decide wheter core/libyui/doc/FAQs/notify-events.txt:something is sufficient or not. And it's up to the UI hackers to decide core/libyui/doc/FAQs/notify-events.txt:in the next release. Come to an agreement among the YCP hackers and make core/libyui/doc/FAQs/notify-events.txt:> in the next release. Come to an agreement among the YCP hackers and make core/libyui/doc/html/index.html:to.Note: This dialog looks extremely ugly - don't try core/libyui/doc/html/UI-Events.html: hackers or users is pure coincidence and not intended. Ah yes, and core/libyui/doc/html/examples/SelectionBox5.ycp: "Minimalistic selbox (rather ugly): ", core/libyui/doc/YCP-UI-layout.xml: <para><emphasis role="i"><emphasis role="b">Note:</emphasis> This dialog looks extremely ugly - don't try core/libyui/doc/YCP-UI-layout.html:Note: This dialog looks extremely ugly - don't try this at home, kids core/libyui/doc/events/event-intro.html:present or past YaST2 hackers or users is pure coincidence and not intended. core/libyui/doc/events/event-intro.xml: hackers or users is pure coincidence and not intended. Ah yes, and core/libyui/doc/examples/SelectionBox5.ycp: "Minimalistic selbox (rather ugly): ", country/language/src/modules/Language.ycp: // FIXME ugly hack: see bug #47711 devtools/yxp/yxp.y:/* hack because of foreach . TODO move it there */ devtools/ydoc/src/ydoc2: # UGLY devtools/yast2/check_ycp/doc/html/check_ycp_html-check.html: paragraphs. This just looks plain ugly, even more so if this results in devtools/yast2/check_ycp/doc/html/check_ycp_emacs.html: If you are a real hardcore YCP hacker, you can even go so far and change the devtools/yast2/check_ycp/doc/check_ycp.sgml:paragraphs. This just looks plain ugly, even more so if this results in devtools/yast2/check_ycp/doc/check_ycp.sgml:If you are a real hardcore YCP hacker, you can even go so far and change the devtools/yast2/check_ycp/doc/check_ycp-contents.xml: paragraphs. This just looks plain ugly, even more so if this results in devtools/yast2/check_ycp/doc/check_ycp-contents.xml: If you are a real hardcore YCP hacker, you can even go so far and change the devtools/yast2/check_ycp/check_ycp: # Hack: let's not check a 'module "Foo"' declaration, just uppercasing devtools/ycpdoc/src/ycpdoc: # a hack to write a part of module index: devtools/devtools/bin/y2autoconf:# "po" hacking: y2automake runs after us so "po" may not have Makefile.am yet devtools/devtools/bin/y2automake:# Build hack: devtools/devtools/admin/copyright/gpl/COPYING: `Gnomovision' (which makes passes at compilers) written by James Hacker. dhcp-server/src/DhcpServer.pm: # FIXME temporary hack because of testsuite dns-server/src/DnsZones.pm:# This function is a light hack fo NSUPDATE. dns-server/src/DnsZones.pm:# This light hack is here because nsupdate needs at least one NS record working for it's updates dns-server/src/DnsFakeTabs.ycp:// Dirty hack for tabs in YCP until the widget implementation is ready firewall/src/dialogs.ycp: // hack function for disabling BackButon firstboot/configure.in.in:## Nasty hack: xgettext doesn't work for XML files, so let's symlink it ftp-server/src/dialogs.ycp: * special hack widget where is handlig disable back button ftp-server/src/dialogs.ycp: * special hack widget where is handlig Start/Stop button gtk/src/ygtkcellrendererarrow.c: // a bit ugly, but let's use a cycle here to avoid calling a function gtk/src/YGPackageSelector.cc: // the plain list; hacky anyway gtk/src/YGPackageSelector.cc: // select path, so the buttons get updated and all (hacky) gtk/src/ygtksteps.c: // ugly -- should use gtk_widget_queue_draw_area (widget, x, y, w, h) gtk/src/ygtksteps.h: TODO: the PangoLayout usage is getting a bit hacky. We may want to gtk/src/YGUtils.cc: // (if you think this is ugly, just wait for the Perl version! :P) gtk/TODO: We could hack this through if we had stock images support (may depend gtk/README: A code overview is given on the HACKING file. gtk/configure.in:Hello hacker: please read the README carefully while this builds. gtk/test.sh:echo "Hackish script to run a ton of yast2-gtk test that we know" gtk/HACKING: hackish. Attempts at abstracting this were successful, but not gtk/configure.in.in:Hello hacker: please read the README carefully while this builds. gtk/integrate/yast2: # FIXME: why the hack was this done? full screening something that http-server/src/YaPI/HTTPDModules.pm: { option => "XBitHack", "context" => [ "Directory", "Server", "Virtual" ], http-server/src/YaST/httpdUtils.pm: # this is a hack. inetd/src/routines.ycp: // HACK: inetd/src/dialogs.ycp: * BTW: This module should have been rewritten ages ago! No more hacking, please. installation/configure.in:#argh hack installation/configure.in.in:## Nasty hack: xgettext doesn't work for XML files, so let's symlink it installation/configure.in.in:#argh hack instserver/src/Instserver.ycp: // HACK: support sles8 too ipsec/src/FreeSwanCerts.pm:# Quick and dirty hack to substitute some known fields of issuer DN to so kerberos-server/src/KerberosServer.pm: if (!SCR->Write (".ldapserver.krb5ACLHack", "" )) ldap/src/LdapServerAccess.pm:BEGIN {$TYPEINFO{AddSambaACLHack} = ["function", ldap/src/LdapServerAccess.pm:sub AddSambaACLHack { ldap/src/LdapServerAccess.pm: if (!SCR->Write (".ldapserver.sambaACLHack", $dn)) { ldap-client/src/Ldap.ycp: // this is a hack ldap-client/src/Ldap.ycp: // this is a hack ldap-server/src/ldap-server_proposal.ycp: /* XXX: hack to resolve bug #44335: ldap-server/agents/ag_ldapserver:# - lots of those ugly direct data accesses (like $section->{$opt_name}->[0]{dataref}{__internal}{filename} ) ldap-server/agents/ag_ldapserver: if( $path[0] eq 'sambaACLHack' ) { ldap-server/agents/ag_ldapserver: summary => "DN missing in sambaACLHack", ldap-server/agents/ag_ldapserver: return $class->sambaACLHack( $dn ); ldap-server/agents/ag_ldapserver: if( $path[0] eq 'krb5ACLHack' ) { ldap-server/agents/ag_ldapserver: #summary => "DN missing in krb5ACLHack", ldap-server/agents/ag_ldapserver: return $class->krb5ACLHack( $dn ); ldap-server/agents/ag_ldapserver: #FIXME: extremely ugly check to determine if the database entry is the one from slapd.conf.default ldap-server/agents/ag_ldapserver:sub krb5ACLHack ldap-server/agents/ag_ldapserver: y2debug("-> krb5ACLHack"); ldap-server/agents/ag_ldapserver: my $acl = "## Yast2 krb5 hack ACL\n"; ldap-server/agents/ag_ldapserver: $acl .= "## Yast2 krb5 hack ACL done\n"; ldap-server/agents/ag_ldapserver: # kick out old krb5 hack ACLs ldap-server/agents/ag_ldapserver: next unless( $slapd[$i] =~ /^## Yast2 krb5 hack ACL/ ); ldap-server/agents/ag_ldapserver: } while( $slapd[++$i] !~ /^## Yast2 krb5 hack ACL done/ ); ldap-server/agents/ag_ldapserver:sub sambaACLHack { ldap-server/agents/ag_ldapserver: y2debug("-> sambaACLHack"); ldap-server/agents/ag_ldapserver: my $acl = "## Yast2 samba hack ACL\n"; ldap-server/agents/ag_ldapserver: $acl .= "## Yast2 samba hack ACL done\n"; ldap-server/agents/ag_ldapserver: # kick out old samba hack ACLs ldap-server/agents/ag_ldapserver: next unless( $slapd[$i] =~ /^## Yast2 samba hack ACL/ ); ldap-server/agents/ag_ldapserver: } while( $slapd[++$i] !~ /^## Yast2 samba hack ACL done/ ); liby2util/src/.deps/digest_bin-Digest.Po: /usr/include/openssl/e_os2.h /usr/include/openssl/symhacks.h \ liby2util/src/.deps/digest_bin-Digest.Po:/usr/include/openssl/symhacks.h: liby2util/src/.deps/Digest.Plo: /usr/include/openssl/e_os2.h /usr/include/openssl/symhacks.h \ liby2util/src/.deps/Digest.Plo:/usr/include/openssl/symhacks.h: live-installer/src/live-installer.ycp: // FIXME hack because of bootloader - libzypp does not contain product database live-installer/configure.in.in:## Nasty hack: xgettext doesn't work for XML files, so let's symlink it mail/users-plugin/UsersPluginMail.pm: # UGLY: Access the Namespace-Structure directly, as the access method lowercase the values make.log:./../../src/inst_you.ycp: 50: Warning: Function Hack has no comment. metapackage/COPYING: `Gnomovision' (which makes passes at compilers) written by James Hacker. ncurses/src/ncursesw.h:/* The (char*) cast is to hack around missing const's */ ncurses/src/ncursesw.h:/* The (wchar*_t) cast is to hack around missing const's */ network/src/dsl/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/lan/address.ycp: // The combo is a hack to allow changing misdetected network/src/modem/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/installation/inst_do_net_test.ycp: // ugly hack (see bug #42177) network/src/installation/network/dsl/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/installation/network/lan/address.ycp: // The combo is a hack to allow changing misdetected network/src/installation/network/modem/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/installation/network/provider/dialogs.ycp: * The SelectionBox "----" divider hack network/src/installation/network/provider/dialogs.ycp:define any dividerHack(list provs, any prev) { network/src/installation/network/provider/dialogs.ycp: provider = dividerHack(provs, prev); network/src/modules/Lan.ycp: // if(!Arch::s390 ()) /* FIXME: Temporary hack until the detection is functional */ network/src/modules/network/dsl/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/modules/network/lan/address.ycp: // The combo is a hack to allow changing misdetected network/src/modules/network/modem/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/modules/network/installation/inst_do_net_test.ycp: // ugly hack (see bug #42177) network/src/modules/network/provider/dialogs.ycp: * The SelectionBox "----" divider hack network/src/modules/network/provider/dialogs.ycp:define any dividerHack(list provs, any prev) { network/src/modules/network/provider/dialogs.ycp: provider = dividerHack(provs, prev); network/src/routines/dsl/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/routines/lan/address.ycp: // The combo is a hack to allow changing misdetected network/src/routines/modem/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/routines/installation/inst_do_net_test.ycp: // ugly hack (see bug #42177) network/src/routines/provider/dialogs.ycp: * The SelectionBox "----" divider hack network/src/routines/provider/dialogs.ycp:define any dividerHack(list provs, any prev) { network/src/routines/provider/dialogs.ycp: provider = dividerHack(provs, prev); network/src/provider/dialogs.ycp: * The SelectionBox "----" divider hack network/src/provider/dialogs.ycp:define any dividerHack(list provs, any prev) { network/src/provider/dialogs.ycp: provider = dividerHack(provs, prev); network/src/clients/network/dsl/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/clients/network/lan/address.ycp: // The combo is a hack to allow changing misdetected network/src/clients/network/modem/dialogs.ycp: // 0 is index to CreateWidgets... ugly network/src/clients/network/installation/inst_do_net_test.ycp: // ugly hack (see bug #42177) network/src/clients/network/provider/dialogs.ycp: * The SelectionBox "----" divider hack network/src/clients/network/provider/dialogs.ycp:define any dividerHack(list provs, any prev) { network/src/clients/network/provider/dialogs.ycp: provider = dividerHack(provs, prev); nis-client/agents/ag_yp_conf: # a hack to make testing simple nis-client/agents/ag_yp_conf: # a hack to make testing simple ntp-client/src/misc.ycp:// FIXME this is quite ugly ... the whole checkinf if something was changed online-update/src/inst_you.ycp: // I have a feeling that we may need a lot of hacks here online-update/src/inst_you.ycp: boolean Hack (string what) { online-update/src/inst_you.ycp: boolean hack = (SCR::Read (.target.size, "/tmp/hack-" + what) != -1); online-update/src/inst_you.ycp: if (hack) online-update/src/inst_you.ycp: y2milestone ("HACK: %1", what); online-update/src/inst_you.ycp: return hack; online-update/src/inst_you.ycp: if (after_restart || Hack ("init-target-and-sources")) online-update/src/inst_you.ycp: Hack ("ui")) online-update/yast2-online-update.spec.in: # remove the.desktop from the older unhacked package during update packagemanager/src/inst/rpm/librpmDb.cv3.cc: /* HACK. Source RPM, so just do things differently */ packagemanager/src/inst/InstSrc.cc:// DESCRIPTION : Hack for adrian to enforce package packagemanager/src/inst/InstSrc.cc: rememberPreviouslyDnlPackage( path_r ); // Hack not to keep more than one downloaded package packagemanager/src/inst/InstSrc.cc:#warning Hack not to keep more than one downloaded package packagemanager/src/inst/InstSrcDataUL.cc: // slideshow via ftp/http hack packagemanager/src/inst/InstSrcManager.cc:#warning be friendly to slideshow hack packagemanager/src/y2pm/InstTarget.h: * Hack to let InstTarget lookup required and conflicting file relations. packagemanager/src/y2pm/RpmDb.h: * Hack to lookup required and conflicting file relations. packagemanager/src/y2pm/PMSolvable.h: * Hack to let InstTarget lookup required and conflicting file relations. packagemanager/src/PMManager_solver.cc:#warning hack for unknown file dependencies packager/src/clients/inst_kickoff.ycp: // hack 'pre-req' cyclic dependency between bash, aaa_base, and perl packager/src/clients/inst_kickoff.ycp: // hack 'pre-req' cyclic dependency between bash, aaa_base, and perl packager/configure.in.in:## Nasty hack: xgettext doesn't work for XML files, so let's symlink it pam/src/PamSettings.ycp: // FIXME temporary hack for backward compatibility perl-bindings/doc/examples/Makefile.am.common:# this is a hacked up version of the thing that is in newer devtools perl-bindings/src/YCP.cc: // this is a hack before the builtin namespaces get a uniform interface: perl-bindings/src/YCP.cc: // maybe a special exceptional hack to make Path for the 1st argument? perl-bindings/src/YCP.pm: # HACK: pkg-bindings/src/Source.cc:// hack: zypp/MediaProducts.h cannot be included in PkgModuleFunctions.h pkg-bindings/src/Source.cc: * (idempotence hack, broken design: #155459, #176013, use SourceSaveAll). printer/agent-ppd/src/PPDdb.cc: /* Add special vendors hacks */ printer/agent-ppd/src/PPDdb.cc: * Preprocess the strings, apply hacks and update the db. printer/agent-ppd/src/PPDdb.cc: /* special vendor/printer hacks */ product-creator/src/Kiwi.ycp: string cmd = sformat ("ZYPP_READONLY_HACK=1 kiwi --root %1 --prepare %2 --logfile terminal", chroot_dir, config_dir); product-creator/src/Kiwi.ycp: cmd = sformat ("ZYPP_READONLY_HACK=1 kiwi --create %1 -d %2 --logfile terminal", chroot_dir, out_dir); profile-manager/src/ProfileManager.ycp: if (position == "first") // hack: missing newline qt/src/pkg/YQPkgConflictDialog.cc: // Here comes a real nasty hack. qt/src/pkg/YQPkgPatternList.h: * be set >0 and rootItemDecorated( true ), but that would look very ugly qt/src/YQUI_core.cc: // Ugly hack as a workaround of bug #121872 (Segfault at program exit qt/src/YQCheckBoxFrame.h: * This is a nasty hack, but it prevents oversights from the Qt designers. qt/src/YQCheckBoxFrame.cc: * This is a nasty hack. But it is necessary because QGroupBox handles its qt/src/YQMenuButton.cc: * the 100 delay is a ugly dirty workaround registration/src/clients/inst_suse_register.ycp:chacl * -x maptimeout,markkeys,maxwin,meta,monitor,msgminwait,msgwait,multiuser,nethack,next,nonblock repair/doc/Research/Rescue/research/results/misc/wrong_library_path.html:never heard of this library (have you been hacked?). Do you have it? repair/doc/Research/Rescue/research/results/misc/wrong_library_path.html:> never heard of this library (have you been hacked?). Do you have it? repair/doc/Research/Rescue/research/results/login/index.html:<!-- <li>All logins fail, perhaps a hacker attack or partitions full: repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:<center><a href=/googlegroups/help.html>Click here</a> for information about upcoming improvements to this beta version of Google's Usenet search.</center> <table width=100%% cellpadding=2 cellspacing=0 border=0><tr><td bgcolor=#009933 nowrap>Usenet Messages from the thread "HACKED ? All logins fail"   </td><td bgcolor=#009933 align=right nowrap>Messages 1 - 5 of 5. </td></tr></table> repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:From: <a href=/groups?hl=de&lr=&safe=off&q=author:jdewitt%40broadcastzone.com+>jdewitt</a> (<a href=mailto:jdewitt%40broadcastzone.com>jdewitt(a)broadcastzone.com</a>) Subject: HACKED ? All logins fail Newsgroups: <a href=/groups?hl=de&lr=&safe=off&group=comp.os.linux.misc>comp.os.linux.misc</a> Date: 2000-10-18 10:10:29 PST repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:From: <a href=/groups?hl=de&lr=&safe=off&q=author:d9910739%40mail.connect.usq.edu.au+>Michael Westerman</a> (<a href=mailto:d9910739%40mail.connect.usq.edu.au>d9910739(a)mail.connect.usq.edu.au</a>) Subject: Re: HACKED ? All logins fail Newsgroups: <a href=/groups?hl=de&lr=&safe=off&group=comp.os.linux.misc>comp.os.linux.misc</a> Date: 2000-10-18 20:27:40 PST repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:From: <a href=/groups?hl=de&lr=&safe=off&q=author:ynotssor%40my-deja.com+>ynotssor(a)my-deja.com</a> (<a href=mailto:ynotssor%40my-deja.com>ynotssor(a)my-deja.com</a>) Subject: Re: HACKED ? All logins fail Newsgroups: <a href=/groups?hl=de&lr=&safe=off&group=comp.os.linux.misc>comp.os.linux.misc</a> Date: 2000-10-18 23:00:09 PST repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:Possibly hacked; it sounds symptomatic of repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:From: <a href=/groups?hl=de&lr=&safe=off&q=author:avflinsch%40att.net+>aflinsch</a> (<a href=mailto:avflinsch%40att.net>avflinsch(a)att.net</a>) Subject: Re: HACKED ? All logins fail Newsgroups: <a href=/groups?hl=de&lr=&safe=off&group=comp.os.linux.misc>comp.os.linux.misc</a> Date: 2000-10-19 11:39:58 PST repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:From: <a href=/groups?hl=de&lr=&safe=off&q=author:gregab%40NOS.PAM-gbsoft.org+>Grega Bremec</a> (<a href=mailto:gregab%40NOS.PAM-gbsoft.org>gregab(a)NOS.PAM-gbsoft.org</a>) Subject: Re: HACKED ? All logins fail Newsgroups: <a href=/groups?hl=de&lr=&safe=off&group=comp.os.linux.misc>comp.os.linux.misc</a> Date: 2000-10-19 13:43:03 PST repair/doc/Research/Rescue/research/results/login/all_logins_fail.html:friends with hacked versions that send all of the attempted passwords repair/doc/Research/Rescue/research/results/hardware/power_supply_problem.html:I've replaced this with a 1000uF, 16v from Radio Shack on both rev 1.0 repair/doc/Research/Rescue/research/results/hardware/cdrom_problem_2.html:From: <a href=/groups?hl=en&lr=&safe=off&q=author:thaal01%40cai.com+>Alan.J.Thackray</a> (<a href=mailto:thaal01%40cai.com>thaal01(a)cai.com</a>) Subject: Re: CDROM Problem Newsgroups: <a href=/groups?hl=en&lr=&safe=off&group=comp.os.linux.hardware>comp.os.linux.hardware</a> Date: 1999/02/24 repair/doc/Research/Rescue/research/results/kernel/modprobe_cant_locate_module.html:# Kernel hacking repair/doc/Research/Rescue/research/results/rescue_disk/password_repair_via_rescue2.html:<pre>Help....I am running redhat 6.2 i386. I was hacked and my root password repair/doc/Research/Rescue/research/results/rescue_disk/password_repair_via_rescue2.html: >Help....I am running redhat 6.2 i386. I was hacked and my root password repair/doc/Research/Rescue/research/results/rescue_disk/password_repair_via_rescue2.html:> >Help....I am running redhat 6.2 i386. I was hacked and my root password repair/doc/Research/Rescue/research/results/rescue_disk/password_repair_via_rescue2.html:> > >Help....I am running redhat 6.2 i386. I was hacked and my root password repair/doc/Research/Rescue/research/results/rescue_disk/password_repair_via_rescue2.html:> > > >Help....I am running redhat 6.2 i386. I was hacked and my root password repair/doc/Research/Rescue/research/results/rescue_disk/password_repair_via_rescue2.html:> > >Help....I am running redhat 6.2 i386. I was hacked and my root password ruby-bindings/src/ruby/YCP.cc: // this is a hack before the builtin namespaces get a uniform interface: ruby-bindings/src/ruby/YCP.cc: // maybe a special exceptional hack to make Path for the 1st argument? ruby-bindings/src/ruby/YCP.rb: # HACK: samba-server/src/SambaBackendLDAP.pm: $ret = LdapServerAccess->AddSambaACLHack($admin_dn, 0); samba-server/src/SambaBackendLDAP.pm: y2error("Samba ACL Hack failed"); scanner/src/Scanner.ycp: { // An ugly workaround for a strange problem (Suse/Novell Bugzilla bug #75709): schema/scripts/collect.sh: # HACK: avoid creating a separate desktop file security/src/Security.ycp: /* Local permissions hack */ sound/data/src/gen_opt_list.ycp: // FIXME this is hack for one current addon module... FIXME sound/data/sndcards.ycp: "vaio_hack" : $[ sound/data/alsa-module-syntax:snd-nm256 vaio_hack enable:(enable),allows:{{0,Disabled},{1,Enabled}},default:0,dialog:check sound/sound/src/routines.ycp: * (oss is nasty hacked, because it's not trivial to check this) sound/sound/src/routines.ycp: define boolean nm256hack (string modname) ``{ sound/sound/src/routines.ycp: string warn_text = Sound::STRINGS["nm256hackWarning"]:""; sound/sound/src/routines.ycp: // ppc hack - use snd-aoa instead of snd-powermac (#217300) sound/sound/src/routines.ycp: * Hack for Thinkpad 600E notebook - it need cs4236 module instead of cs4610 sound/sound/src/routines.ycp: define void Thinkpad600E_cs4236_hack (integer card_id) ``{ sound/sound/src/write_routines.ycp: // this is a hack for snd-aoa driver, additional modules are needed (#217300) sound/sound/src/texts.ycp: "nm256hackWarning": sound/sound/src/texts.ycp:snd_vaio_hack option value to 1 or by sound/sound/src/card_wizard.ycp: Thinkpad600E_cs4236_hack (card_id); sound/sound/src/wizards.ycp: boolean nm256out = nm256hack (Sound::unconfigured_cards[0,"module"]:""); storage/libstorage/bindings/ycp/LibStorage_wrap.cc:/* Note: SwigMagicFuncHack is a typedef used to get the C++ compiler to just shut up already */ storage/libstorage/bindings/ycp/LibStorage_wrap.cc:typedef int (CPerlObj::*SwigMagicFuncHack)(SV *, MAGIC *); storage/libstorage/bindings/ycp/LibStorage_wrap.cc:typedef int (*SwigMagicFuncHack)(SV *, MAGIC *); storage/libstorage/bindings/ycp/LibStorage_wrap.cc:typedef int (*SwigMagicFuncHack)(struct interpreter *, SV *, MAGIC *); storage/libstorage/bindings/ycp/LibStorage_wrap.cc: mg->mg_virtual->svt_get = (SwigMagicFuncHack) get; storage/libstorage/bindings/ycp/LibStorage_wrap.cc: mg->mg_virtual->svt_set = (SwigMagicFuncHack) set; storage/libstorage/bindings/ycp/LibStorage_wrap.xml: <attribute name="code" value="/* -----------------------------------------------------------------------------
 * perlrun.swg
 *
 * This file contains the runtime support for Perl modules
 * and includes code for managing global variables and pointer
 * type checking.
 * ----------------------------------------------------------------------------- */

#ifdef PERL_OBJECT
#define SWIG_PERL_OBJECT_DECL CPerlObj *SWIGUNUSEDPARM(pPerl),
#define SWIG_PERL_OBJECT_CALL pPerl,
#else
#define SWIG_PERL_OBJECT_DECL
#define SWIG_PERL_OBJECT_CALL
#endif

/* Common SWIG API */

/* for raw pointers */
#define SWIG_ConvertPtr(obj, pp, type, flags) SWIG_Perl_ConvertPtr(SWIG_PERL_OBJECT_CALL obj, pp, type, flags)
#define SWIG_NewPointerObj(p, type, flags) SWIG_Perl_NewPointerObj(SWIG_PERL_OBJECT_CALL p, type, flags)

/* for raw packed data */
#define SWIG_ConvertPacked(obj, p, s, type) SWIG_Perl_ConvertPacked(SWIG_PERL_OBJECT_CALL obj, p, s, type)
#define SWIG_NewPackedObj(p, s, type) SWIG_Perl_NewPackedObj(SWIG_PERL_OBJECT_CALL p, s, type)

/* for class or struct pointers */
#define SWIG_ConvertInstance(obj, pptr, type, flags) SWIG_ConvertPtr(obj, pptr, type, flags)
#define SWIG_NewInstanceObj(ptr, type, flags) SWIG_NewPointerObj(ptr, type, flags)

/* for C or C++ function pointers */
#define SWIG_ConvertFunctionPtr(obj, pptr, type) SWIG_ConvertPtr(obj, pptr, type, 0)
#define SWIG_NewFunctionPtrObj(ptr, type) SWIG_NewPointerObj(ptr, type, 0)

/* for C++ member pointers, ie, member methods */
#define SWIG_ConvertMember(obj, ptr, sz, ty) SWIG_ConvertPacked(obj, ptr, sz, ty)
#define SWIG_NewMemberObj(ptr, sz, type) SWIG_NewPackedObj(ptr, sz, type)


/* Runtime API */

#define SWIG_GetModule(clientdata) SWIG_Perl_GetModule()
#define SWIG_SetModule(clientdata, pointer) SWIG_Perl_SetModule(pointer)


/* Error manipulation */

#define SWIG_ErrorType(code) SWIG_Perl_ErrorType(code) 
#define SWIG_Error(code, msg) sv_setpvf(GvSV(PL_errgv),"%s %s\\n", SWIG_ErrorType(code), msg)
#define SWIG_fail goto fail 

/* Perl-specific SWIG API */

#define SWIG_MakePtr(sv, ptr, type, flags) SWIG_Perl_MakePtr(SWIG_PERL_OBJECT_CALL sv, ptr, type, flags)
#define SWIG_MakePackedObj(sv, p, s, type) SWIG_Perl_MakePackedObj(SWIG_PERL_OBJECT_CALL sv, p, s, type)
#define SWIG_SetError(str) SWIG_Error(SWIG_RuntimeError, str)


#define SWIG_PERL_DECL_ARGS_1(arg1) (SWIG_PERL_OBJECT_DECL arg1)
#define SWIG_PERL_CALL_ARGS_1(arg1) (SWIG_PERL_OBJECT_CALL arg1)
#define SWIG_PERL_DECL_ARGS_2(arg1, arg2) (SWIG_PERL_OBJECT_DECL arg1, arg2)
#define SWIG_PERL_CALL_ARGS_2(arg1, arg2) (SWIG_PERL_OBJECT_CALL arg1, arg2)

/* -----------------------------------------------------------------------------
 * pointers/data manipulation
 * ----------------------------------------------------------------------------- */

/* For backward compatibility only */
#define SWIG_POINTER_EXCEPTION 0

#ifdef __cplusplus
extern "C" {
#endif

#define SWIG_OWNER SWIG_POINTER_OWN
#define SWIG_SHADOW SWIG_OWNER << 1

#define SWIG_MAYBE_PERL_OBJECT SWIG_PERL_OBJECT_DECL

/* SWIG Perl macros */

/* Macro to call an XS function */
#ifdef PERL_OBJECT 
# define SWIG_CALLXS(_name) _name(cv,pPerl) 
#else 
# ifndef MULTIPLICITY 
# define SWIG_CALLXS(_name) _name(cv) 
# else 
# define SWIG_CALLXS(_name) _name(PERL_GET_THX, cv) 
# endif 
#endif 

/* Note: SwigMagicFuncHack is a typedef used to get the C++ compiler to just shut up already */

#ifdef PERL_OBJECT
#define MAGIC_PPERL CPerlObj *pPerl = (CPerlObj *) this;
typedef int (CPerlObj::*SwigMagicFunc)(SV *, MAGIC *);

#ifdef __cplusplus
extern "C" {
#endif
typedef int (CPerlObj::*SwigMagicFuncHack)(SV *, MAGIC *);
#ifdef __cplusplus
}
#endif

#define SWIG_MAGIC(a,b) (SV *a, MAGIC *b)
#define SWIGCLASS_STATIC
#else
#define MAGIC_PPERL
#define SWIGCLASS_STATIC static SWIGUNUSED
#ifndef MULTIPLICITY
#define SWIG_MAGIC(a,b) (SV *a, MAGIC *b)
typedef int (*SwigMagicFunc)(SV *, MAGIC *);

#ifdef __cplusplus
extern "C" {
#endif
typedef int (*SwigMagicFuncHack)(SV *, MAGIC *);
#ifdef __cplusplus
}
#endif


#else
#define SWIG_MAGIC(a,b) (struct interpreter *interp, SV *a, MAGIC *b)
typedef int (*SwigMagicFunc)(struct interpreter *, SV *, MAGIC *);
#ifdef __cplusplus
extern "C" {
#endif
typedef int (*SwigMagicFuncHack)(struct interpreter *, SV *, MAGIC *);
#ifdef __cplusplus
}
#endif

#endif
#endif

/* Workaround for bug in perl 5.6.x croak and earlier */
#if (PERL_VERSION < 8)
# ifdef PERL_OBJECT
# define SWIG_croak_null() SWIG_Perl_croak_null(pPerl)
static void SWIG_Perl_croak_null(CPerlObj *pPerl)
# else
static void SWIG_croak_null()
# endif
{
 SV *err=ERRSV;
# if (PERL_VERSION < 6)
 croak("%_", err);
# else
 if (SvOK(err) && !SvROK(err)) croak("%_", err);
 croak(Nullch);
# endif
}
#else
# define SWIG_croak_null() croak(Nullch)
#endif



#include <stdlib.h>

SWIGRUNTIME const char *
SWIG_Perl_TypeProxyName(const swig_type_info *type) {
 if (!type) return NULL;
 if (type->clientdata != NULL) {
 return (const char*) type->clientdata;
 } 
 else {
 return type->name;
 }
}

SWIGRUNTIME swig_cast_info *
SWIG_TypeProxyCheck(const char *c, swig_type_info *ty) {
 SWIG_TypeCheck_Template(( (!iter->type->clientdata && (strcmp((char*)iter->type->name, c) == 0)) 
 || (iter->type->clientdata && (strcmp((char*)iter->type->clientdata, c) == 0))), ty);
}


/* Function for getting a pointer value */

SWIGRUNTIME int
SWIG_Perl_ConvertPtr(SWIG_MAYBE_PERL_OBJECT SV *sv, void **ptr, swig_type_info *_t, int flags) {
 swig_cast_info *tc;
 void *voidptr = (void *)0;
 SV *tsv = 0;
 /* If magical, apply more magic */
 if (SvGMAGICAL(sv))
 mg_get(sv);

 /* Check to see if this is an object */
 if (sv_isobject(sv)) {
 IV tmp = 0;
 tsv = (SV*) SvRV(sv);
 if ((SvTYPE(tsv) == SVt_PVHV)) {
 MAGIC *mg;
 if (SvMAGICAL(tsv)) {
 mg = mg_find(tsv,'P');
 if (mg) {
 sv = mg->mg_obj;
 if (sv_isobject(sv)) {
 tsv = (SV*)SvRV(sv);
 tmp = SvIV(tsv);
 }
 }
 } else {
 return SWIG_ERROR;
 }
 } else {
 tmp = SvIV(tsv);
 }
 voidptr = INT2PTR(void *,tmp);
 } else if (! SvOK(sv)) { /* Check for undef */
 *(ptr) = (void *) 0;
 return SWIG_OK;
 } else if (SvTYPE(sv) == SVt_RV) { /* Check for NULL pointer */
 if (!SvROK(sv)) {
 *(ptr) = (void *) 0;
 return SWIG_OK;
 } else {
 return SWIG_ERROR;
 }
 } else { /* Don't know what it is */
 return SWIG_ERROR;
 }
 if (_t) {
 /* Now see if the types match */
 char *_c = HvNAME(SvSTASH(SvRV(sv)));
 tc = SWIG_TypeProxyCheck(_c,_t);
 if (!tc) {
 return SWIG_ERROR;
 }
 *ptr = SWIG_TypeCast(tc,voidptr);
 } else {
 *ptr = voidptr;
 }

 /* 
 * DISOWN implementation: we need a perl guru to check this one.
 */
 if (tsv && (flags & SWIG_POINTER_DISOWN)) {
 /* 
 * almost copy paste code from below SWIG_POINTER_OWN setting
 */
 SV *obj = sv;
 HV *stash = SvSTASH(SvRV(obj));
 GV *gv = *(GV**) hv_fetch(stash, "OWNER", 5, TRUE);
 if (isGV(gv)) {
 HV *hv = GvHVn(gv);
 /*
 * To set ownership (see below), a newSViv(1) entry is added. 
 * Hence, to remove ownership, we delete the entry.
 */
 if (hv_exists_ent(hv, obj, 0)) {
 hv_delete_ent(hv, obj, 0, 0);
 }
 }
 }
 return SWIG_OK;
}

SWIGRUNTIME void
SWIG_Perl_MakePtr(SWIG_MAYBE_PERL_OBJECT SV *sv, void *ptr, swig_type_info *t, int flags) {
 if (ptr && (flags & SWIG_SHADOW)) {
 SV *self;
 SV *obj=newSV(0);
 HV *hash=newHV();
 HV *stash;
 sv_setref_pv(obj, (char *) SWIG_Perl_TypeProxyName(t), ptr);
 stash=SvSTASH(SvRV(obj));
 if (flags & SWIG_POINTER_OWN) {
 HV *hv;
 GV *gv=*(GV**)hv_fetch(stash, "OWNER", 5, TRUE);
 if (!isGV(gv))
 gv_init(gv, stash, "OWNER", 5, FALSE);
 hv=GvHVn(gv);
 hv_store_ent(hv, obj, newSViv(1), 0);
 }
 sv_magic((SV *)hash, (SV *)obj, 'P', Nullch, 0);
 SvREFCNT_dec(obj);
 self=newRV_noinc((SV *)hash);
 sv_setsv(sv, self);
 SvREFCNT_dec((SV *)self);
 sv_bless(sv, stash);
 }
 else {
 sv_setref_pv(sv, (char *) SWIG_Perl_TypeProxyName(t), ptr);
 }
}

SWIGRUNTIMEINLINE SV *
SWIG_Perl_NewPointerObj(SWIG_MAYBE_PERL_OBJECT void *ptr, swig_type_info *t, int flags) {
 SV *result = sv_newmortal();
 SWIG_MakePtr(result, ptr, t, flags);
 return result;
}

SWIGRUNTIME void
SWIG_Perl_MakePackedObj(SWIG_MAYBE_PERL_OBJECT SV *sv, void *ptr, int sz, swig_type_info *type) {
 char result[1024];
 char *r = result;
 if ((2*sz + 1 + strlen(SWIG_Perl_TypeProxyName(type))) > 1000) return;
 *(r++) = '_';
 r = SWIG_PackData(r,ptr,sz);
 strcpy(r,SWIG_Perl_TypeProxyName(type));
 sv_setpv(sv, result);
}

SWIGRUNTIME SV *
SWIG_Perl_NewPackedObj(SWIG_MAYBE_PERL_OBJECT void *ptr, int sz, swig_type_info *type) {
 SV *result = sv_newmortal();
 SWIG_Perl_MakePackedObj(result, ptr, sz, type);
 return result;
}

/* Convert a packed value value */
SWIGRUNTIME int
SWIG_Perl_ConvertPacked(SWIG_MAYBE_PERL_OBJECT SV *obj, void *ptr, int sz, swig_type_info *ty) {
 swig_cast_info *tc;
 const char *c = 0;

 if ((!obj) || (!SvOK(obj))) return SWIG_ERROR;
 c = SvPV(obj, PL_na);
 /* Pointer values must start with leading underscore */
 if (*c != '_') return SWIG_ERROR;
 c++;
 c = SWIG_UnpackData(c,ptr,sz);
 if (ty) {
 tc = SWIG_TypeCheck(c,ty);
 if (!tc) return SWIG_ERROR;
 }
 return SWIG_OK;
}


/* Macros for low-level exception handling */
#define SWIG_croak(x) { SWIG_Error(SWIG_RuntimeError, x); SWIG_fail; }


typedef XS(SwigPerlWrapper);
typedef SwigPerlWrapper *SwigPerlWrapperPtr;

/* Structure for command table */
typedef struct {
 const char *name;
 SwigPerlWrapperPtr wrapper;
} swig_command_info;

/* Information for constant table */

#define SWIG_INT 1
#define SWIG_FLOAT 2
#define SWIG_STRING 3
#define SWIG_POINTER 4
#define SWIG_BINARY 5

/* Constant information structure */
typedef struct swig_constant_info {
 int type;
 const char *name;
 long lvalue;
 double dvalue;
 void *pvalue;
 swig_type_info **ptype;
} swig_constant_info;


/* Structure for variable table */
typedef struct {
 const char *name;
 SwigMagicFunc set;
 SwigMagicFunc get;
 swig_type_info **type;
} swig_variable_info;

/* Magic variable code */
#ifndef PERL_OBJECT
#define swig_create_magic(s,a,b,c) _swig_create_magic(s,a,b,c)
 #ifndef MULTIPLICITY
 SWIGRUNTIME void _swig_create_magic(SV *sv, char *name, int (*set)(SV *, MAGIC *), int (*get)(SV *,MAGIC *)) 
 #else
 SWIGRUNTIME void _swig_create_magic(SV *sv, char *name, int (*set)(struct interpreter*, SV *, MAGIC *), int (*get)(struct interpreter*, SV *,MAGIC *)) 
 #endif
#else
# define swig_create_magic(s,a,b,c) _swig_create_magic(pPerl,s,a,b,c)
SWIGRUNTIME void _swig_create_magic(CPerlObj *pPerl, SV *sv, const char *name, int (CPerlObj::*set)(SV *, MAGIC *), int (CPerlObj::*get)(SV *, MAGIC *)) 
#endif
{
 MAGIC *mg;
 sv_magic(sv,sv,'U',(char *) name,strlen(name));
 mg = mg_find(sv,'U');
 mg->mg_virtual = (MGVTBL *) malloc(sizeof(MGVTBL));
 mg->mg_virtual->svt_get = (SwigMagicFuncHack) get;
 mg->mg_virtual->svt_set = (SwigMagicFuncHack) set;
 mg->mg_virtual->svt_len = 0;
 mg->mg_virtual->svt_clear = 0;
 mg->mg_virtual->svt_free = 0;
}


SWIGRUNTIME swig_module_info *
SWIG_Perl_GetModule(void) {
 static void *type_pointer = (void *)0;
 SV *pointer;

 /* first check if pointer already created */
 if (!type_pointer) {
 pointer = get_sv("swig_runtime_data::type_pointer" SWIG_RUNTIME_VERSION SWIG_TYPE_TABLE_NAME, FALSE);
 if (pointer && SvOK(pointer)) {
 type_pointer = INT2PTR(swig_type_info **, SvIV(pointer));
 }
 }

 return (swig_module_info *) type_pointer;
}

SWIGRUNTIME void
SWIG_Perl_SetModule(swig_module_info *module) {
 SV *pointer;

 /* create a new pointer */
 pointer = get_sv("swig_runtime_data::type_pointer" SWIG_RUNTIME_VERSION SWIG_TYPE_TABLE_NAME, TRUE);
 sv_setiv(pointer, PTR2IV(module));
}

#ifdef __cplusplus
}
#endif
" id="246" addr="fda04b30" /> storage/storage/src/inst_resize_ui.ycp: // Quick hack for now: define global variables that are storage/storage/src/inst_resize_ui.ycp: // End quick hack sysconfig/src/parse_configs.pl: # hack for /etc/sysconfig/network/ifcfg-* files tune/idedma/src/hwinfo/SystemSettings.ycp: * I have to admit that this is very ugly but it is here tune/idedma/src/hwinfo/routines.ycp: // haha, hack! we need to translate the 'modules' entry into some more readable form... tune/idedma/src/hwinfo/system_settings_dialogs.ycp:// FIXME: temporary hack - disable serial console config tune/idedma/src/hwinfo/system_settings_dialogs.ycp:// FIXME: temporary hack - disable serial line configuration tune/idedma/src/hwinfo/system_settings_ui.ycp: * I have to admit that this is very ugly but it is here tune/hwinfo/src/SystemSettings.ycp: * I have to admit that this is very ugly but it is here tune/hwinfo/src/routines.ycp: // haha, hack! we need to translate the 'modules' entry into some more readable form... tune/hwinfo/src/system_settings_dialogs.ycp:// FIXME: temporary hack - disable serial console config tune/hwinfo/src/system_settings_dialogs.ycp:// FIXME: temporary hack - disable serial line configuration tune/hwinfo/src/system_settings_ui.ycp: * I have to admit that this is very ugly but it is here tv/src/Tv.ycp: // this is a hack for detected cards (see bug #24132) tv/src/ui.ycp: // hack for ncurses selection (first card is selected as a default): update/configure.in.in:## Nasty hack: xgettext doesn't work for XML files, so let's symlink it users/src/Users.pm:# this is hacked a bit; there probably could be a case when more groups have users/src/Users.pm: # hack: change of default group's gid vm/configure.in.in:## Nasty hack: xgettext doesn't work for XML files, so let's symlink it y2pmsh/src/instsrc.cc:/** this is a hack since y2pm does not allow updating sources. we remember the yast2/scripts/yast2:# quick hack: treat gtk like qt yast2/library/agents/ag_netd:# Testsuite hack: yast2/library/agents/ag_netd: # A special hack - write known services/protocols to fd3 yast2/library/network/src/SuSEFirewall.ycp: // "any" for all zones, this is ugly yast2/library/wizard/doc/Progress.html:Q: Hey, it is ugly! yast2/library/wizard/doc/Progress.html:Q: This progress bar is ugly and has terrible API. I will use my yxmlconv/src/statements.rb:# after <do>, either <block> or a statement follow. Ugly. yxmlconv/src/statements.rb:# And even <do> is optional. More ugly. yxmlconv/src/statements.rb:# after <do>, either <block> or a statement follow. Ugly. yxmlconv/src/statements.rb:# after <do>, either <block> or a statement follow. Ugly.

1 0

[yast-devel] Weirdness in YaST testsuites
by Lukas Ocilka 02 Nov '07

02 Nov '07

Hi, All of you have definitely already written some testsuite for your YaST module. That's right because writing testsuites (that are executed in the RPM-build-time) can prevent from getting more bugreports later. Anyway, sometimes there are some problems between chair and keyboard that need a small hint from some other developer (Mvidner for today ;)). Today's problem were constructors in imported modules. I was unable to make testsuite pass even if everything seemed to be all right: --- cut (shortened) --- include "testsuite.ycp"; import "Bootloader"; map EXECUTE = $[ "target" : $[ "bash_output" : $[] ] ] TESTSUITE_INIT ([READ, WRITE, EXECUTE], nil); TEST (``(Bootloader::Read()), [READ, WRITE, EXECUTE], nil); --- cut (shortened) --- make check kept returning: Encoding.ycp:33 Can't convert value '0' to type 'map' Encoding.ycp:33 contains: map m = (map) SCR::Execute( .target.bash_output, "locale -k charmap" ); So, has what helped? Just moving the >import "Bootloader";< after >TESTSUITE_INIT< call. --- cut (shortened) --- include "testsuite.ycp"; map EXECUTE = $[ "target" : $[ "bash_output" : $[] ] ] TESTSUITE_INIT ([READ, WRITE, EXECUTE], nil); import "Bootloader"; TEST (``(Bootloader::Read()), [READ, WRITE, EXECUTE], nil); --- cut (shortened) --- That's all for now. Next time "How to make your computer implement manager's FATE requests automagically -- Three steps to a better life". Have a nice day Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

2 3