tag:blogger.com,1999:blog-88337495284739858212024-03-14T00:32:41.167-07:00Jano's Zypper Blogjanohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-8833749528473985821.post-36040759681379893092010-04-19T01:45:00.000-07:002010-04-19T02:01:43.387-07:00zypper-1.4.2: rewritten package selection codeZypper has undergone a major refactoring of its package selection code recently. This was mainly to enable automatic testing and to make it easier and safer to add new features.<br />I'll submit zypper 1.4.2 including this change to Factory soon. It seems to work fine for the most part, but if you spot something that used to work for you in 1.4.1, please let us know via bugzilla. Don't forget to attach both <a href="http://en.opensuse.org/Zypper/Troubleshooting#Solver_Test_Case">zypper.log and solver test case</a>.<br /><br />The new version already enables use of unified package arguments (in install, update, and remove commands) in the form of:<br /><pre>[+/-][repo:][type:]name[.arch][OPevr[.arch]]<br /><br />± (or ~|!) ; install/remove modifier<br />repo = ; repo alias, number, or name<br />type = patch|pattern|product ; if not specified 'package' isimplied<br />name ; can even be a glob<br />OP = -|=|>=|<=|>|< ; version operator<br />evr = [epoch:]version[-release] ; edition (version)</pre><br />E.g. $ zypper in packman:xine-ui-0.99.5cvs20091115-0.pm.1.4 (don't forget to quote the args, if they contain ?/*/</> or spaces).<br /><br />More about all this (and about a few more features added in the last months) later ...<br /><br />There is still some work to do to fully support this (especially don't try foo.arch :O), but the main focus now is to make sure that all that used to work before works also now. For future plans see <a href="http://en.opensuse.org/Zypper/Roadmap">roadmap</a> and comments in the <a href="http://gitorious.org/opensuse/zypper/blobs/master/tests/SolverRequester_test.cc">SolverRequester_test code</a>. Don't hesitate to send feedback to or discuss this stuff on zypp-devel@opensuse.org or comment this blog post.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com15tag:blogger.com,1999:blog-8833749528473985821.post-49272687697099281152009-12-11T03:57:00.000-08:002009-12-11T07:47:06.387-08:00Cloning openSUSE VirtualBox Machines<span style="font-style: italic;">... or "Waiting for device /dev/disk/by-ID/... to appear." problem</span><br /><br />A guess many people have figured this out by now, but i still know a lot who have not, so here it goes.<br /><br />There are a few caveats in cloning openSUSE or SLE VirtualBox machines. One is that openSUSE uses device ID in /etc/fstab and grub's menu.lst to reference your hard disk partitions. This is cool for physical machines, since no matter what the usual device name of your hard disk is (/dev/sda, sdb, hda, ...), the device ID always stays the same. When cloning the VirtualBox hard disk image, however, the device ID changes. This consequently causes a problem when booting your new machine with cloned image.<br /><br />Another one concerns the network card's udev rules, which affect the device names. These are set to use MAC address to identify the card, which also changes when creating new virtual machine (new random MAC address is generated). After booting the cloned machine with this new network card, the original one becomes eth1, and the new one is not configured; you need to configure it, e.g. using YaST. Thanx to <a href="http://mzugec.blogspot.com/">Mišo Žugec</a> for this tip.<br /><br />To avoid these problems, after installing a fresh openSUSE or SLE which i want to use for cloning, i change its /etc/fstab and /boot/grub/menu.lst to use the usual device files, and change the network card's udev rules from MAC to BusID. So, in nutshell, the cloning process looks like this:<br /><ol><li>Boot the virtual machine you want to use as base for cloning.</li><li><span style="font-weight: bold;">Replace the <code>/dev/disk/by-id/...-partY</code> with <code>/dev/sdXY</code></span> in /etc/fstab and /boot/grub/menu.lst.</li><li>In YaST Network module, click Edit to edit the network card, open the Hardware tab, click Change in the <span style="font-style: italic;">Udev rules</span> frame and <span style="font-weight: bold;">select BusID instead of MAC address</span>.<br /></li><li><span style="font-weight: bold;">Shut the machine down </span> (from within the machine itself, not using VirtualBox's power off).</li><li>Find the machine's .vdi hard disk file (usually under ~/.VirtualBox/ dir) and <span style="font-weight: bold;">use VBoxManage clonevdi command to clone it</span>, for example:<br /><code>(~/.VirtualBox/HardDisks)$ VBoxManage clonevdi my-perfect-oS11.2-base.vdi oS11.2-some-experiment.vdi</code></li><li><span style="font-weight: bold;">Create new machine in VirtualBox GUI and attach the cloned disk image to it</span> when asked. You can also copy an existing machine's .xml configuration file and change the hard disk UUID, or create a script that will do this for you.</li></ol>You're ready to boot your clone now. Of course, if you cloned a machine still using the device ID for hard disk, you should still be able to boot it, if you pass the right root=/dev/sdXY and resume=/dev/sdXY parameters to grub. You can also reconfigure the network devices after booting. But preparing the base is more convenient, if you need to clone it often.<br /><br />For more info see:<br /><a href="http://srackham.wordpress.com/cloning-and-copying-virtualbox-virtual-machines/"><span style="font-size:85%;">http://srackham.wordpress.com/cloning-and-copying-virtualbox-virtual-machines/</span></a><br /><a href="http://forgeftp.novell.com/lfl/.html/virtualbox.html"><span style="font-size:85%;">http://forgeftp.novell.com/lfl/.html/virtualbox.html</span></a>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com3tag:blogger.com,1999:blog-8833749528473985821.post-76548415611502677082009-06-13T02:09:00.000-07:002009-06-13T03:27:21.152-07:00DaysToGo - Minimalistic SuperKaramba Theme<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_ZgqM1MxbwdE/SjNxAbT2FhI/AAAAAAAAABI/ohZg4Nwepg8/s1600-h/daystogo.png" style="border: none;"><img style="cursor:pointer; cursor:hand;width: 200px; height: 200px; float: left;border: none;" src="http://1.bp.blogspot.com/_ZgqM1MxbwdE/SjNxAbT2FhI/AAAAAAAAABI/ohZg4Nwepg8/s200/daystogo.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5346741434763843090" /></a><br />I easily loose track of time when i have a lot of things to do on my list. I needed something to remind me how much time i have left when deciding what do to next or whether to promise to do something more. So i made this simple <a href="http://netdragon.sourceforge.net/">SuperKaramba</a> theme.<br /><br />You can download it from <a href="http://www.suse.de/~jkupec/superkaramba/daystogo.tar.gz">here</a>.<br /><br />The theme is pretty minimalistic and only contains three text items, one using a simple perl script, and an image for the background. So you can easily change it as you wish.<br /><br />To install SuperKaramba and the theme on a recent openSUSE using terminal do this:<pre>$ sudo zypper in kde4-superkaramba 'perl(Date::Parse)'<br />$ wget http://www.suse.de/~jkupec/superkaramba/daystogo.tar.gz<br />$ cp daystogo.tar.gz .kde4/share/apps/superkaramba/themes</pre><br />(Did you know you could install perl modules like this? :O)<br /><br />Now if you open Superkaramba, its theme selector should appear and should already contain the new theme. Opening the theme should also unpack the tarball. See the <a href="http://www.suse.de/~jkupec/superkaramba/Readme">Readme</a> file in the daystogo theme directory for further instruction on how to edit the theme (set your own text and date).<br /><br />The theme file is as simple as this:<pre style="white-space: pre-wrap;white-space: -moz-pre-wrap;white-space: -pre-wrap;white-space: -o-pre-wrap;">KARAMBA W=280 H=280<br /><br /><group> x=5 y=5 w=270 h=270<br />image x=-10 y=-10 path="img/SUSE_Head_lt.png"<br />text x=10 y=0 value="<span style="color: red;"><edit daystogo.theme></span>" color=255,255,255 fontsize=24 shadow=2 bgcolor=100,100,100 font="Sans"<br />text x=135 y=70 w=270 align=center sensor=program program="~/.kde4/share/apps/superkaramba/themes/daystogo/scripts/daystogo.pl <span style="color: red;">'31/dec/2009 23:59'</span>" line=1 color=255,255,255 shadow=4 bgcolor=0,50,0 fontsize=120 font="Sans" interval=900000<br />text x=270 y=250 w=270 align=right value="days to go" color=255,255,255 shadow=2 bgcolor=50,50,50 fontsize=24 font="Sans"<br /></group></pre>The red parts are what you want to change to suit you. See this <a href="http://netdragon.sourceforge.net/screate.html">manual</a> for description of used items and attributes. You'll find many more there, together with examples you can use to extend this theme or create your own. Looking at <a href="http://www.kde-look.org/index.php?xcontentmode=38">other existing themes</a> is useful, too.<br /><br />Last, but not least, i want to thank <a href="http://lehighost.deviantart.com">Troy Watson</a> for the pretty <a href="http://lehighost.deviantart.com/art/OpenSUSE-Icons-Linux-49879161">Geeko icon</a> i used as the background image.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com0tag:blogger.com,1999:blog-8833749528473985821.post-76189379524239066082009-06-12T03:57:00.000-07:002009-06-12T04:49:59.597-07:00Improved Installation Summary in ZypperAnd the best thing last (for now) :O) This was one of the most wanted features for a year now (<a href="https://bugzilla.novell.com/show_bug.cgi?id=389128">bnc #389128</a>). Here's how it currently (zypper 1.2.0) looks.<br /><br /><b>If the architecture or the vendor of an installed package is about to be changed</b>, the old and the new arch/vendor is shown next to the package name:<pre>The following packages are going to change vendor:<br /> kde4-akonadi openSUSE -> openSUSE Build Service<br /> kde4-knemo http://packman.links2linux.de -> openSUSE Build Service<br /> oxygen-icon-theme openSUSE -> openSUSE Build Service<br /> oxygen-icon-theme-scalable openSUSE -> openSUSE Build Service</pre>Other information, like version or repository is not shown <b>by default</b>, like it was before (i argue that it would be too much info for the default output):<pre>The following NEW packages are going to be installed:<br /> dmidecode libpkcs11-helper1 libstorage libx86emu1<br /><br />The following packages are going to be upgraded:<br /> ConsoleKit ConsoleKit-32bit ConsoleKit-x11<br />...<br />Continue? [y/n/?] (y):</pre>But <b>you can toggle display of such info</b> in the 'Continue?' dialog. Enter '?' to show all the available options:<pre>Continue? [y/n/?] (y): ?<br /><br />y - Yes, accept the summary and proceed with installation/removal of packages.<br />n - No, cancel the operation.<br />v - Toggle display of package versions.<br />a - Toggle display of package architectures.<br />r - Toggle display of repositories from which the packages will be installed.<br />m - Toggle display of package vendor names.<br />d - Toggle between showing all details and as few details as possible.<br />g - View the summary in pager.<br /><br />[y/n/?] (y):</pre>Enter '<b>v</b>' to see the versions:<pre>[y/n/?] (y): v<br />The following NEW packages are going to be installed:<br /> dmidecode 2.10-3.4<br /> libpkcs11-helper1 1.07-1.7<br /> libstorage 2.18.16-1.1<br /> libx86emu1 1.1-3.1<br /><br />The following packages are going to be upgraded:<br /> ConsoleKit 0.3.0-1.5 -> 0.3.0-1.6<br /> ConsoleKit-32bit 0.3.0-1.5 -> 0.3.0-1.6<br /> ConsoleKit-x11 0.3.0-1.5 -> 0.3.0-1.6</pre>If the list is too long, enter '<b>g</b>' to <b>view the result in pager</b>.<br /><br />Also, the package counts are shown at the end:<pre>1230 packages to upgrade, 2 to downgrade, 5 new, 2 to remove, 4 to change vendor.<br />Overall download size: 1.02 GiB. After the operation, 175.0 KiB will be freed.</pre>If you have colors enabled the numbers will be highlighted and the ones to-be-removed and to-change-vendor are shown in red to catch your attention.<br /><br />Enjoy, and let us know what you think!<br /><br /><span class="marker-todo">todo</span>: <span class="todo">Add an option to show the dependency graph of the listed packages. That will answer the questions why zypper wants to install or remove a particular package.</span><br /><span class="marker-todo">todo</span>: <span class="todo">Add an option to view detailed package info.</span><br /><span class="marker-todo">todo</span>: <span class="todo">Add an option to view the changelog (esp. of the to-be-upgraded packages).</span>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com4tag:blogger.com,1999:blog-8833749528473985821.post-90391110422886772842009-06-12T02:58:00.000-07:002009-06-12T03:56:44.517-07:00Zypper DialogsI was puzzled by how to make good user dialogs (or prompts) in Zypper for quite some time. My idea was that they should:<br /><ul><li>be translatable, including the answers (or options)</li><li>have default option, that would be chosen with a simple Enter key stroke (or automatically in non-interactive mode)</li><li>have the default option visibly marked</li><li>have help</li><li>be simple (have expert options hidden from default view)</li></ul>This has gradually evolved into the following:<br /><pre>Download (curl) error for 'http://foo.bar/beer/content':<br />Error code: Connection failed<br />Error message: Couldn't resolve host 'foo.bar'<br /><br />Abort, retry, ignore? [a/r/i/?] (a): ?<br /><br />a - Skip retrieval of the file and abort current operation.<br />r - Try to retrieve the file again.<br />i - Skip retrieval of the file and try to continue with the operation without the file.<br />u - Change current base URI and try retrieving the file again.<br /><br />[a/r/i/?] (a):</pre>And a translated version:<pre>Ukončiť, znova, ignorovať? [k/z/i/?] (k): ?<br /><br />k - Preskoč súčasný súbor a ukonči operáciu.<br />z - Skús stiahnuť súbor znova.<br />i - Preskoč súčasný súbor a pokračuj v operácii bez neho.<br />u - Zmeň základnú URI adresu a skús súbor stiahnuť znova.<br /><br />[k/z/i/?] (k):</pre><ul><li>the prompt options are made of a string like "a/r/i/u", which is marked for translation. Translators are advised in the source comment about the meaning of the options and that they<br />should use lowercase letters to translate them (but even a longer string would work).</li><br /><li>The default option is chosen by the programmer, using its position (0 in the above example). On Enter, this option would be used as an answer.</li><br /><li>The default option is visibly shown in separate parentheses. First i thought highlighting it with some color would be nice, but then my colleagues convinced me that showing different output in color/non-color mode was not a good idea.</li><br /><li>Whenever there's help or more options available, a question mark (<b>?</b>) is shown as one of the possible options. When entered, the help would be shown, as you can see in the examples above.</li><br /><li>Programmer can choose how many options should be shown, the rest will be hidden. Only the most important options should be shown, the rest will be listed after entering the '<b>?</b>'.</li></ul>It's surely not perfect, but hopefully quite usable. Debian's apt does something similar, but i'm not sure about the translations and other details.<br /><br /><span class="marker-todo">todo</span>: <span class="todo">Allow to pass arguments together with the option as part of the answer. This would allow to e.g. remove particular package from the list of to-be-installed packages when seeing the summary. Or show detailed info (e.g. changelog) of a package that caught your attention in the summary before starting the installation.</span><br /><br />(oh, did i mention that we'd be glad to receive patches implementing any of the todo's i mention in my blog posts? :O) If you like zypper and would enjoy some coding in C++, don't hesitate to contact us).janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com0tag:blogger.com,1999:blog-8833749528473985821.post-64217667375298858482009-06-11T03:16:00.000-07:002009-06-11T04:39:28.473-07:00Configure Your ZypperSo i mentioned <code>zypper.conf</code> in my <a href="http://jniq.blogspot.com/2009/06/colors-in-zypper.html">previous post</a>? Yes, Zypper now (since 1.2.0) reads configuration file from <code>/etc/zypp/zypper.conf</code> and from your <code>$HOME/.zypper.conf</code>. It does not have too much to offer right now, appart from the <a href="http://jniq.blogspot.com/2009/06/colors-in-zypper.html">colors</a>, but the point is now we can easily add new ones there, whenever there's a need.<br /><br />If there is Zypper option that you write too often, it should have it's configuration file counterpart as well, so that it saves you typing. I actually have a list of few, collected over time from users, so i'll be adding them soon. You'll always find the latest list of supported config options <a href="http://git.opensuse.org/?p=projects/zypp/zypper.git;a=blob_plain;f=zypper.conf;hb=HEAD">here</a>, so stay tuned (and let us know if you need something that's not there yet).<br /><br />So which value will be used after all, the one from the config file, or the one passed via command line? Here is the override priority order, highest to lowest.<br /><ol><li><b>command line options</b></li><li>options from <b><code>$HOME/.zypper.conf</code></b></li><li>options from <b><code>/etc/zypp/zypper.conf</code></b></li><li>and the lowest priority have the ones from <b><code>zypp.conf</code></b>, so that you can override libzypp's settings in zypper, if zypper allows it.</ol><br />You can use an alternative config file via <b><code>--config custom/zypper.conf</code></b> global option. If you do, the other config files (item 2 and 3 above) will be ignored.<br /><br /><span class="marker-todo">todo</span>: <span class="todo">Add command for manipulating the configuration files as an alternative to manual editing. The command would list available options with current values and descriptions and would allow to set new values, or restore the defaults.</span>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com4tag:blogger.com,1999:blog-8833749528473985821.post-45500209370658892462009-06-11T02:18:00.000-07:002009-06-11T03:15:37.230-07:00Colors in ZypperZypper 1.2.0 is coming to Factory soon, bringing a few new features i will briefly describe in a few posts.<br /><br />My last post was about colors in terminal applications, so i'll start with colors in zypper. There is new <code>[color]</code> section in zypper.conf (oh, i should have started with zypper.conf.. nevermind :O), where you can enable or disable colorization of the output, tell zypper whether you use dark or light terminal background, and, finally, select your own color for each kind of output, if you don't like the defaults.<br /><br />By default, zypper will print progress messages from ongoing operation in white, finished stuff in grey, result in white, errors in red (surprise :O), and apart from this general stuff there are some special things highlighted, like the package counts in the installation summary. More is yet to come (but i don't want to overcolorify it, of course).<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_ZgqM1MxbwdE/SjDYjS90q2I/AAAAAAAAABA/LgiJyMXTWKo/s1600-h/zypper-colors.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 225px;" src="http://4.bp.blogspot.com/_ZgqM1MxbwdE/SjDYjS90q2I/AAAAAAAAABA/LgiJyMXTWKo/s320/zypper-colors.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5346010858586942306" /></a><br /><br /><a href="http://git.opensuse.org/?p=projects/zypp/zypper.git;a=blob_plain;f=zypper.conf;hb=HEAD">Here</a> are the config options. Those who do not want to wait for the new package to reach Factory can get it from <a href="http://download.opensuse.org/repositories/zypp:/Head/openSUSE_Factory">zypp::Head OBS repo</a>.<br /><br />So, play around, enjoy, and let me know what you think.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com2tag:blogger.com,1999:blog-8833749528473985821.post-69738720814274828202009-03-06T07:04:00.000-08:002009-03-06T08:11:35.851-08:00Colors for Terminal AppsThis has been in my plans for a long time, but i had trouble learning how to do colored output in terminals correctly. I asked people, i googled, looked at terminfo, ncurses, but still could not find a satisfactory answer. So i started to look at other non-curses terminal apps, and i stopped already at the first one: git.<br /><br /><pre>#include <unistd.h><br />#include <stdlib.h><br />#include <string.h><br /><br />bool has_colors()<br />{<br /> if (::isatty(STDOUT_FILENO))<br /> {<br /> char *term = ::getenv("TERM");<br /> if (term && ::strcmp(term, "dumb"))<br /> return true;<br /> }<br /> return false;<br />}</pre><br /><br />This (translated to a C/C++ hybrid) is all that git (and now also zypper :O) does to detect the color capability of the <code>stdout</code>. <code>stout</code> must be a terminal, and the <code>TERM</code> environment variable must not be <code>"dumb"</code>. The idea is that most color-capable terminals understand the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=12782">ISO 6429</a> (former <a href="http://en.wikipedia.org/wiki/ANSI_escape_code">ANSI</a>) <a href="http://www.termsys.demon.co.uk/vtansi.htm#colors">color control sequences</a>, and if the above check fails for your terminal, you can configure git (and soon zypper :O) to never or always use colors (or set the <code>TERM</code> to <code>"dumb"</code>).<br /><br />Regarding <b>terminfo</b>, i found it hard to learn and an overkill for just printing colored text (of course, once learned it can be used in other ways, too, e.g. to move the cursor, turn off input echoing when writing passwords, etc.). Maybe some other time.<br /><br />On the other hand, <b>ncurses</b> are nothing for an existing terminal application which already does lots of output the usual way - you would have to rewrite all the output handling using ncurses. With ncurses it is that you write your app either with or without it from the start. But you cannot switch to it later, nor mix it with standard C I/O (<code>printf()</code> or C++ streams (<code>cout <<</code>). At least that's my impression from what i've learned...<br /><br />So, zypper is now (since 1.1.0) a bit less boring, with colors :O) The idea is to print normal messages and progress in darker color, highlight important messages like results, warnings, errors, and color some special stuff, e.g. in install summary, default options in prompts, and so on. And it should be configurable, so that anybody can adapt it to his or her terminal background and text color. I'll write more about that once it's done.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com0tag:blogger.com,1999:blog-8833749528473985821.post-73405725467470959092009-03-04T05:55:00.000-08:002009-03-04T13:30:36.660-08:00Augeas for libzypp and zypper?The need for a configuration file for zypper (plus my wish for a nice CLI for handling it) and a visit to <a href="http://www.fosdem.org/2009/schedule/events/fedora_augeas">Raphaël Pinson's presentation at FOSDEM</a> made me look at <a href="http://augeas.net/">Augeas</a> closely.<br /><br />Augeas enables you to read and edit your config files in a way which preserves comments and formatting details, allowing humans and programs coexist peacefully when it comes to editing configuration files. More than that, you can map some special structures of the file to special parts of the augeas tree, rather than using the generic INI file parser. See the zypp.conf for example (zypper.conf will have the same structure):<br /><br /><pre><br />[main]<br />## Option description.<br />## Default: etc.<br />##<br /># disabledoption = value<br /><br />## Another option description<br />##<br /><br />another.option = value<br /></pre><br /><br />With Augeas you can write a <i>lens</i> (the file contents description) which will map such file into a tree like this:<br /><br /><pre><br />/files/etc/zypp/zypp.conf/main/1<br />/files/etc/zypp/zypp.conf/main/1/description[1] = "Option description."<br />/files/etc/zypp/zypp.conf/main/1/description[2] = "Default: etc."<br />/files/etc/zypp/zypp.conf/main/1/description[3]<br />/files/etc/zypp/zypp.conf/main/1/commented<br />/files/etc/zypp/zypp.conf/main/1/disabledoption = "value"<br />/files/etc/zypp/zypp.conf/main/2<br />/files/etc/zypp/zypp.conf/main/2/description[1] = "Another option description."<br />/files/etc/zypp/zypp.conf/main/2/description[2]<br />/files/etc/zypp/zypp.conf/main/2/another.option = "value"<br /></pre><br /><br />Note the <i>commented</i> node. Augeas has an API for looking for the nodes, getting values from them, setting the values, and finally saving the tree back to the config file.<br /><br /><b>What does this mean for zypper?</b> Implementing <code>zypper conf --list</code> is a piece of cake, as well as <code>zypper conf --set another.option value</code>. Commenting or uncommenting the option is a matter of adding or removing the <i>commented</i> node. Getting the option description for <code>zypper conf --help some.option</code> is easy (and maybe it is possible to map the multi-line ## description to a single 'description' node!).<br /><br />Here is a draft of <a href="http://www.suse.de/%7Ejkupec/zypper/zypper.aug">lens for zypper</a> (it will need comments and further improvements). To try it out you can crete a /etc/zypp/zypper.conf file with contents like the above example, and use the <code>augtool</code> like this:<br /><br /><pre>$ augtool -I /the/dir/with/the/zypper.aug/file<br />augtool> print /files/etc/zypp/zypper.conf/<br />/files/etc/zypp/zypper.conf<br />/files/etc/zypp/zypper.conf/anon<br />/files/etc/zypp/zypper.conf/anon/description[1] = "Configuration file for zypper"<br />/files/etc/zypp/zypper.conf/anon/description[2]<br />/files/etc/zypp/zypper.conf/anon/description[3] = "Boolean values are 0 1 yes no on off true false"<br />/files/etc/zypp/zypper.conf/main<br />/files/etc/zypp/zypper.conf/main/1<br />/files/etc/zypp/zypper.conf/main/1/description[1] = "Whether to use colors"<br />/files/etc/zypp/zypper.conf/main/1/description[2]<br />/files/etc/zypp/zypper.conf/main/1/description[3] = "Default value: autodetected"<br />/files/etc/zypp/zypper.conf/main/1/description[4]<br />/files/etc/zypp/zypper.conf/main/1/description[5]<br />/files/etc/zypp/zypper.conf/main/1/colors = "yes"<br />augtool><br /></pre><br /><br />Type <code>help</code> for other commands, use TAB key for completion, and check also the <a href="http://augeas.net">Augeas home page</a> for more info.<br /><br /><b>What does this mean for libzypp?</b> Basically the above, with respect to libzypp's files. Currently, you either edit your repos.d/*.repo, locks, credentials, and other files by hand or you leave it to libzypp's frontends, or you at least take care not to write comments in those files, because they will all get removed upon the next change done by libzypp (what we do there is to rewrite the entire files from in-memory data upon saving). This can be easily avoided using Augeas and we can add an editing API for zypp.conf. Plus the bonuses described above.<br /><br />The library package (libaugeas0) would add 300 kiB of installed size to libzypp's/zypper's dependencies, (which is not little), plus an optional 200 kiB of the official lenses (augeas-lenses), if we decide to use them.<br /><br /><span class="marker-todo">todo</span>: <span class="todo">Look at Augeas' error reporting. The user can of course break the structure of the file in a way that the lens can't map it to the tree anymore. If parsing of the file will fail, we need to report why, so that the user can fix it.</span>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com4tag:blogger.com,1999:blog-8833749528473985821.post-63281172234157139342008-12-22T06:37:00.000-08:002008-12-22T07:08:32.170-08:00Gettext VariablesRecently i had trouble getting my zypper to talk in Slovak despite the correct locale set (using <tt>export LANG=sk_SK.utf8</tt>). I was so desperate after some time of searching for the cause that i even filed a <a href="https://bugzilla.novell.com/show_bug.cgi?id=459370">bug report</a>.<br /><br />Well, it turned out that i forgot about one more variable, the <tt><b>LANGUAGE</b></tt>. This defines a language preference list and takes higher priority that <tt>LANG</tt>, or <tt>LC_*</tt> variables. Mine was set to <tt>en_US</tt> (i don't know why, though) :O(<br /><br />So the fix for me was either to unset the <tt>LANGUAGE</tt> variable, or include <tt>sk</tt> in its value. Read more about this variable <a href="http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html#The-LANGUAGE-variable">here</a>.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com1tag:blogger.com,1999:blog-8833749528473985821.post-92196242177608499412008-12-09T04:35:00.000-08:002008-12-09T05:58:24.685-08:00RIS Specification UpdatedI filled some missing parts in the <a href="http://en.opensuse.org/Standards/Repository_Index_Service">Repository Index Service</a> specification, mainly regarding client handling the repository index. I would consider it done already, but there are still a few things i would like to see done in the future:<br /><ol><li>The <tt>distro_target</tt> attribute should be turned into some standard distribution identifier to make it really useful. The <a href="http://cpe.mitre.org/">CPE</a> looks like a good candidate.</li><li>The spec does not say how to handle repositories of type unknown to the client. They should be ignored, but the <tt>type</tt> attribute of <tt><repo></tt> is currently optional so the type does not need to be known when refreshing the service. One solution could be to make the <tt>type</tt> attribute required, another could be to require that the client removes any repositories comming from a service that are of unknown type. The latter seems to be cumbersome, i would go for the former.<br /></li><li>It might be worth to add the examples from this <a href="http://duncan.mac-vicar.com/blog/archives/351">Duncan's post</a> to the page (they're much better than those of mine :O).</li><li>The specification should not be kept solely as a wiki (should not be editable by broad public; version control is problematic, etc.). Any suggestion where it should be instead?</li></ol>Feel free to drop a comment about the specification, or the concept, etc.<br /><br />Some TODOs for libzypp:<br /><span class="marker-todo">todo</span>: <span class="todo">sync repo URI with the repoindex, if changed</span><br /><span class="marker-todo">todo</span>: <span class="todo">ignore repos with unknown type when refreshing service</span>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com1tag:blogger.com,1999:blog-8833749528473985821.post-84420908788490619952008-11-09T02:43:00.000-08:002008-11-18T02:03:51.723-08:00Zypper 1.0.0We're closing to the release of openSUSE 11.1 and SUSE Linux Enterprise 11. Since <a href="http://en.opensuse.org/Zypper">zypper</a>'s releases are tightly tied to those of openSUSE, this is also an important milestone for zypper. Thus, the next release of zypper will have version <b>1.0.0</b>. This marks more than <a href="http://en.opensuse.org/Zypper/History">two years</a> of zypper's development and the outset of implementation of new nice features.<br /><br />So what's next?<br /><br />Several ideas and problems appeared so far. Some need to be implemented in libzypp itself, some are purely zypper's. Here is a list of the most important things for <span style="font-style: italic;">zypper 2</span>.<br /><ul><li>Configuration file (.zypperrc).<br /></li><li>Nice overall install progress.</li><li>Much improved install summary (options to view version/vendor/arch changes, changelog, ...).</li><li>More options to handle patterns (remove, install suggested, ...).<br /></li><li>Advanced media error handling with options like eject DVD drive, select DVD drive, edit failed URI, enable/disable medium specific options.</li><li>Fixed or removed zypper shell (can it be useful enough to be worth to maintain it?)<br /></li><li>Interface to new libzypp functionality like 'download only'.</li><li>and more...<br /></li></ul>First there will be some bug fixes during the beta phase of SLE 11, mainly with respect to compatibility with SLE 10 version of rug. These (and all following releses for SLE) will be versioned 1.0.x and will eventually get also to openSUSE 11.1 via online update. After that we're ready to work on <span style="font-style: italic;">zypper 2</span>.<br /><br />Stay tuned on <a href="https://features.opensuse.org">features.opensuse.org</a>, this <a href="http://svn.opensuse.org/svn/zypp/trunk/zypper/doc/TODO">TODO</a> file, this blog and blogs of other <a href="http://en.opensuse.org/Libzypp">ZYpp</a> hackers (see my links).janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com4tag:blogger.com,1999:blog-8833749528473985821.post-36161798859060508382008-11-08T08:20:00.000-08:002008-11-08T09:08:12.377-08:00Zypper Command Reference<p>I needed an overview of all zypper's commands and options, so i created <a href="http://svn.opensuse.org/svn/zypp/trunk/zypper/tools/zypper-help-all">this little script</a> that prints all the help texts. It can be used to search for options through all commands, or to create a reference sheet for printing like this:</p><br /><code><br />$ ./zypper-help-all | fold -s | a2ps -rjB --columns 3 -o file.ps<br /></code><br /><br /><p><span class="marker-todo">todo</span>: <span class="todo">fix some inconsistencies in option names (see <a href="http://lists.opensuse.org/zypp-devel/2008-10/msg00050.html">this thread</a> for discussion)</span><br><br /><span class="marker-todo">todo</span>: <span class="todo">wrap the help texts at 79th column, <a href="https://bugzilla.novell.com/show_bug.cgi?id=423007">bug #423007</a> (no more need for 'fold -s' in the command above)</span><br /></p>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com2tag:blogger.com,1999:blog-8833749528473985821.post-49845552545581168252008-09-04T05:50:00.000-07:002008-09-04T07:01:29.876-07:00Convenient setters in C++?Libzypp's <a href="http://svn.opensuse.org/svn/zypp/branches/SuSE-Linux-11_0-Branch/libzypp/zypp/RepoInfo.h">RepoInfo</a> class was originaly written with property setters returning a <code>RepoInfo &</code> reference to the modified object. This pattern is common in higher OO languages like Java and is convenient as it saves typing when setting serveral properties at once (i'm not sure how it is performance-wise).<br /><br /><pre><br />RepoInfo repo;<br /><br />// you write<br />repo<br /> .setAlias("foo")<br /> .setName("Foo Project Repository")<br /> .setEnabled(true).setAutorefresh(false);<br /><br />// instead of<br />repo.setAlias("foo");<br />repo.setName("Foo Project Repository");<br />repo.setEnabled(true);<br />repo.setAutorefresh(false);<br /></pre><br /><br />Unless the class is part of a class hierarchy, everything's OK. But after splitting RepoInfo to RepoInfoBase and a derived RepoInfo the dark side of C++ has shown up.<br /><br /><pre><br />RepoInfo repo;<br />repo<br /> .setAlias("foo") // RepoInfoBase setter<br /> .setEnabled(true) // RepoInfoBase setter<br /> .setPriority(50); // RepoInfo setter - this won't compile becase setEnabled() returned<br /> // a RepoInfoBase &, and C++ does not bother with figuring out that the<br /> // object is also a RepoInfo.<br /></pre><br /><br />In order to make this work in this setup, you have to redefine each setter from the base class in the derived class and make it return the reference to the derived class:<br /><br /><pre><br />class RepoInfoBase<br />{<br /> RepoInfoBase & setAlias( ... ) { _pimpl->alias = ...; return *this; }<br />}<br /><br />class RepoInfo : public RepoInfoBase<br />{<br /> RepoInfo & setAlias( ... ) <br /> { RepoInfoBase::setAlias(...); return *this; }<br />}<br /></pre><br /><br />but by doing this the RepoInfo class looses some of the advantages of being derived from RepoInfoBase.<br /><br />So, is it best to stick with setters returning void, or is there a better way to do this?janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com1tag:blogger.com,1999:blog-8833749528473985821.post-15487006221185837682008-06-24T09:22:00.000-07:002008-11-09T03:27:38.509-08:00zypper's wiki updatedopenSUSE 11.0 is out so i synced zypper's <a href="http://en.opensuse.org/Zypper/Usage">usage</a> page with it. This <a href="http://en.opensuse.org/Zypper/Changes/11.0">changes</a> page may be of particular interest for those already familiar with zypper. I also took a while to reorganize the <a href="http://en.opensuse.org/Zypper">main</a> page a bit.<br /><br />If there is something wrong or something you'd like to see in those pages, let me know (or just add/change it). Feedback and help is welcome.<br /><br />(Writing docs is quite some work, it took me whole week to update those pages and the man page (which still has some glitches). Didn't i already tell to myself that i must make sure to update them as soon as any change happens? Well, but that's one week less for development... :O) oh...)janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com0tag:blogger.com,1999:blog-8833749528473985821.post-27759046956868234552008-05-07T09:13:00.000-07:002008-11-09T03:27:18.528-08:00More options to modifyrepo<p>In 10.3, <tt><b>zypper modifyrepo (mr)</b></tt> only allowed you to enable/disable one repository and enable/disable autorefresh for it. In 11.0 the options have grown in number a bit. Did i mention the nice help texts?</p><br /><br /><pre>$ zypper help mr<br />modifyrepo (mr) <options> <alias|#|uri><br />modifyrepo (mr) <options> <--all|--remote|--local|--medium-type><br /><br />Modify properties of repositories specified by alias, number or URI<br />or by the '--all, --remote, --local, --medium-type' aggregate options.<br /><br />Command options:<br />-d, --disable Disable the repository (but don't remove it).<br />-e, --enable Enable a disabled repository.<br />-r, --refresh Enable auto-refresh of the repository.<br />-R, --no-refresh Disable auto-refresh of the repository.<br />-n, --name Set a descriptive name for the repository.<br />-p, --priority <1-99> Set priority of the repository.<br />-k, --keep-packages Enable RPM files caching.<br />-K, --no-keep-packages Disable RPM files caching.<br />-a, --all Apply changes to all repositories.<br />-l, --local Apply changes to all local repositories.<br />-t, --remote Apply changes to all remote repositories.<br />-m, --medium-type <type> Apply changes to repositories of specified type.</pre><br /><br /><p>This is what you will see in zypper 0.11.3. The aggregate options (and the <tt>-k</tt> options) were added just recently by our new colleague Josef Reidinger. Those familiar with 10.3 zypper, note that the <tt>--enable-autorefresh/-a</tt> and <tt>--disable-autorefresh</tt> options are now deprecated (<tt>-a</tt> shorthand even had to be removed because of conflict with <tt>--all</tt>) in favor of <tt>--refresh</tt> and <tt>--no-refresh</tt> options. This change was introduced for the sake of consistency with other commands' options. All the options will be described in more detail in the man page soon.</p><br /><br /><h4>Few examples</h4><br /><p>To disable autorefresh for all repositories, do:</p><br /><br /><pre>$ zypper mr -Ra<br />Nothing to change for repository 'openSUSE-DVD 11.0'.<br />Autorefresh has been disabled for repository 'fate'.<br />Nothing to change for repository 'factory'.<br />Nothing to change for repository 'packman'.<br />Autorefresh has been disabled for repository 'factory-nonoss'.<br />Autorefresh has been disabled for repository 'factory-debug'.<br />Nothing to change for repository 'vbox'.<br />Autorefresh has been disabled for repository 'zypp:svn'.</pre><br /><br /><p>To disable all cd/dvd repositories, do:<br /></p><pre>$ zypper mr -d -m cd -m dvd<br />Repository 'openSUSE-DVD 11.0' has been sucessfully disabled.</pre><br /><p></p><br /><br /><p>To enable RPM caching of RPM files for all remote (http/https/ftp) repositories, do:<br /></p><pre>$ zypper mr -kt<br />Nothing to change for repository 'factory'.<br />RPM files caching has been enabled for repository 'factory-debug'.<br />RPM files caching has been enabled for repository 'factory-nonoss'.<br />RPM files caching has been enabled for repository 'fate'.<br />Nothing to change for repository 'packman'.<br />RPM files caching has been enabled for repository 'vbox'.<br />RPM files caching has been enabled for repository 'zypp:svn'.</pre><br /></p><br /><p>Of course don't forget to use <tt>zypper clean</tt> when you run out of free disk space then :O)</p>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com2tag:blogger.com,1999:blog-8833749528473985821.post-51676752664748682532008-05-07T05:45:00.000-07:002008-05-07T05:55:39.527-07:00Missing history and bookmarks in Firefox 3?In case you just updated to Firefox 3 (openSUSE 11.0 beta2 includes Firefox 2.9.95 (Firefox 3 beta 5) and you wondered why are your bookmarks and history not working, here is the probable cause & solution. Firefox 3 uses sqlite back-end for history, bookmarks and other stuff. So doing <tt><b>zypper in libsqlite3-0</b></tt> and restarting firefox should make them work again.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com3tag:blogger.com,1999:blog-8833749528473985821.post-24858276252345874052008-05-05T05:36:00.000-07:002008-11-09T03:27:18.529-08:00zypper search is back<p>I said i would write about zypper's XML output almost two months ago. Hm... obviously other stuff gained higher priority (i will get back to the XML output later). In the openSUSE Updater applets, the focus has shifted from the zypp back-end to <a href="http://www.packagekit.org/">PackageKit</a> and i focused on other zypper/libzypp features and fixes. I will write about them in the following few posts.</p><br /><p>Just recently i re-enabled all the original <tt>zypper search</tt> functionality (except <tt>--match-all</tt> which will be hopefully comming soon). Apart from the original features, there is one frequently requested change in the presenation of the search results (and thanx to the zypp and sat-solver guys it is also fast :O).</p><br /><p>The old zypper listed all available instances of a matching package, all versions from all repositories. But people are more often interested in what the package is about than what versions are available from each respository. Hence, since 0.11.1 you will see a list of packages grouped by their names and types with a summary column instead of repository and version column:</p><br /><pre><br />$ zypper search browser<br />Reading installed packages...<br /><br />S | Name | Summary | Type<br />--+---------------------+----------------------------------+--------<br />i | kim-browser | CIM Browser for CIM-XML Protocol | package<br /> | mysql-query-browser | A Graphical MySQL Query Shell | package<br /> | tvbrowser | digital TV guide | package<br /></pre><br /><p><br />This output caught a few users unprepared. I hope learning that <tt>--details</tt>/<tt>-s</tt> can turn on a detailed list similar to the old one satisfied most of them:</p><br /><pre><br />$ zypper search -s browser<br />Reading installed packages...<br /><br />S | Name | Type | Version | Arch | Repository<br />--+---------------------+---------+------------+--------+-----------<br />i | kim-browser | package | 0.3-208 | x86_64 | factory<br />v | kim-browser | package | 0.3-208 | i586 | factory<br /> | mysql-query-browser | package | 5.0r12-183 | x86_64 | factory<br /> | mysql-query-browser | package | 5.0r12-183 | i586 | factory<br /> | tvbrowser | package | 2.6.3-22 | noarch | factory<br /></pre><br /><p>Since zypper 0.11.2 the summaries will be abbreviated as needed to fit the width of your console screen. This is how it looks on an 80 character wide console:</p><br /><pre><br />$ search music<br />Reading installed packages...<br /><br />S | Name | Summary | Type<br />--+-----------------------+-----------------------------------------+-----------<br /> | asc-music | Music for Advanced Strategic Command--> | package<br /> | libmusicbrainz | Library That Provides Access to the M-> | srcpackage<br /> | libmusicbrainz-devel | Include Files and Libraries Mandatory-> | package<br /> | libmusicbrainz3 | Library That Provides Access to the M-> | srcpackage<br /> | libmusicbrainz3-6 | Library That Provides Access to the M-> | package<br /> | libmusicbrainz3-devel | Library That Provides Access to the M-> | package<br />i | libmusicbrainz4 | Library That Provides Access to the M-> | package<br /> | texlive-bin-musictex | MusiXTeX and MusicTeX | package<br /> | texlive-musictex | MusiXTeX and MusicTeX | package<br /></pre><br /><p>Of course you can use <tt>--no-abbrev</tt>/<tt>-A</tt> <i>global</i> option to turn the abbreviation off - the output will be messy, but you can read the whole summaries. Another way to obtain this info is to use <tt>zypper info</tt>.</p><br /><br /><p>...and don't forget to try <tt>zypper help search</tt>, zypper has nice help texts :O) I'll be fixing zypper update and writing a lot of documentation in the meantime.</p>janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com1tag:blogger.com,1999:blog-8833749528473985821.post-63534426819921804042008-03-06T10:02:00.000-08:002008-11-09T03:27:18.529-08:00bash completion for zypperVersion 0.10.3 of <a href="http://en.opensuse.org/Zypper">zypper</a> will include a bash completion script written by <a href="http://www.m4r3k.org/">Marek Stopka</a> during <a href="http://idea.opensuse.org/content/ideas/bash-completion-for-zypper">Hack Week 2</a>. The script uses zypper help [command] output to retrieve the list of commands and command options in order to feed it to the command line. Given the growing number of zypper's commands and options i believe this will be a pleasant help for many users.<br /><br />Thanx to Marek for doing this!<br /><br />Currently the script provides completion of commands and command options. This can be extended in the future to include package name completion for the install, remove and info commands, or even repository aliases for the repo handling commands and the --repo option.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com1tag:blogger.com,1999:blog-8833749528473985821.post-12350131229583867522008-03-06T06:25:00.000-08:002008-03-06T06:36:44.568-08:00Hi! In this blog i will write about my work on zypper or eventually libzypp and related stuff, plans, ideas... A few words about zypper's XML output, it's implementation and possibilities coming soon.janohttp://www.blogger.com/profile/14349559665817521848noreply@blogger.com0