This is the old SliTaz forum - Please use the main

testing packages
  • jozeejozee March 2010
    =====FROM LUX=====

    Hello Dave,

    * Davesurrey wrote
    Firstly you have identified the source of the problem and the fix. Many thanks.

    Thank you for reporting your experience with ntop. I improved it, but I regret I had no time to improve it more and look for the smallest possible needed dependence.

    * Davesurrey wrote
    That is, one really must start with a clean install to be absolutely sure that an app works in isolation.


    But let me recall that this is the job of contributors, who provide new packages to Slitaz, not the devs, who in my opinion are the very heart of the developement staff, those who built the whole project from the beginning and make it evolving over the long distance. If those very few people (less than 10, maybe 5 persons, maybe even less) would spend more time controlling every single package submitted by contributors, they would no longer be able to develop the distro anymore. There is a balance to find between growth and stability, between creativity and rigour, and this is not obvious since it's also a mater of personal taste.

    I think that Slitaz has grown up very fast, thanks to a very little number of enthousiastic people who did an amazing job. So it would not be fair to complain too much on this. Also remember that "Cooking" means "unstable" in Slitaz.

    OK, but how to improve it now? Let's consider three possibilities.

    - 1 - Testing protocol
    I don't know how the whole staff (devs and contributors) works, but maybe it would be a good idea to define some more rigid guidelines for contributors in the sense that including a new package in the distro wouldn't be possible without having followed some pre-defined testing steps, like:
    * install the package in a freshly built default Slitaz environment;
    * do not try it only in virtual box or a chrooted environment (I'm not a specialist of this but I'm convinced that it is too far from real conditions);
    * see what happens if you change:
         - the langage (what about translations?);
         - the boot process (start with an X session from the beginning or from a text mode connection followed by a call to startx can change things);
         - the user (try it as root and as tux);
         - the location of the package (I think that the new version of taspkg allows to dispatch the binaries between several locations);
         - the window manager maybe;
    * and so on...

    - 2 - Testing team
    It may be that defining such a testing protocol won't be sufficient and that some contributors will "interpret" it in their own way. If so, electing a permanent "testing team" might be a solution in order to ensure that the distro will remain reasonably stable (are you a candidate for this job?). I'm not sure that this matches the idea of a TAZ ;-) so let's consider:

    - 3 - Testing community
    It may be that testing existing packages is the role to play by the community of users of the non-stable release of a distro (you, me...) after all.

    Now let's wait and see if the devs have an opinion on this.


    PS: By the way, it might be a good idea to maintain an up-to-date "Core-Cooking" flavor just for testing purposes (as far as I know the core flavor is a subset of the stable release). It has also been often asked in this forum that the Cooking iso is made up-to-date on a regular basis, say once a week. I don't know if it is possible, but it would certainly help also for testing purpose: if after every fresh install you have to upgrade 267 packages, very soon you'll stop to re-install and give up with this essential step for testing a new package.
  • jozeejozee March 2010
    ===== From LINEA=====

    I think having a team of official testers to report back to the package maintainers and the developers is a great idea.
  • jozeejozee March 2010
    =====DAVESURREY ======
    Hi Lux,
    Thanks for that very thoughtful and useful post. You raise many interesting points. You are correct and I should have said package contributors rather than devs when suggesting testing. But I was, and still am, unsure who is a dev and who a package contributor and I guess some do both.

    It will be interesting to see how the devs want to play this but I think that all users need to help in this and report back what they can. I only wish there were a specific place on the forum where those comments could be collected.

  • jozeejozee March 2010
    ===== From LuX =====


    * davesurrey wrote:
    It will be interesting to see how the devs want to play this

    Apparently Linea is a member of the administrator team, so hopefully his/her post (I suppose it's "her" without knowing :)) is kind of an answer.

    You're right that the developpers of the distro and the contributors of the packages are sometimes the same persons. Although these two functions are quite different they are also quite complementary. In my opinion however this confusion (which is quite normal) may have nasty side effects sometimes, precisely because they do not require the same balance between creativity and rigour.

    @marcophuls: It's sad to say that all the problems you report are not exceptionnal with Linux, since they are all related to material and drivers.

    Problems of resolution mostly depend on Xorg and your video card. I experienced it myself in Slitaz and in Xubuntu. Try this:

    - Set option "screen=your_resolution" at bootime (option vga=* is mostly used for tty, I think). If you're using a permanently installed Slitaz (in your HDD, not a live system) it may be that this will take effect only if you set it the first time you boot Slitaz, when Xorg is installed and configured automatically by tazx.

    - If there exists a specific driver for your video card, install it with tazpkg and specify it in /etc/X11/xorg.conf (changing the value "vesa" by the name of your driver). The list of available drivers is obtained with CLI "tazpkg search xorg-xf86-video". The name of your video card is obtained with CLI "lspci | grep VGA", I think.

    - If it isn't sufficient, edit /etc/X11/xorg.conf as root (keep a backup of it in case of) and modify it as you need. There are uncountably many posts on Linux's forums on the various possile ways to do it (in every distro). I reported some of them in this forum. Google "set resolution xorg.conf" for examples.

    For sound and wireless connection, you may search in this forum (and others) using keywords related to your material, and maybe open a new thread on this. It's all I can say, sorry.

    Hope this helps,
  • jozeejozee March 2010
    ===== Jozee =====

    @LuX and @davesurrey : Thanks for your comments. You will be happy to note that we have taken steps to address some of your concerns about the missing dependencies in the pkgs. You may like to look in:

    One of the major improvement that we have been working on for Slitaz 3.0 is to reduce the maintenance load and automate pkg building and tracking ( at the backend. We have now added automatic package dependency tracking. It means, in future, any commit to repos will automatically be checked for any updates on the corresponding pkg dependencies.

    This full automated pkg maintenance is a very unique and distinctive feature for Slitaz 3.0 which we hope will improve user satisfaction in future.

    Like Linea, I also support an idea of a team of official testers. Would you be willing to take this task?


  • jozeejozee March 2010
    ===== Dave ======
    jozee (or Rohit...sorry but not sure which you prefer to be addressed by) :-)
    Thank you for the information about deps and pkg builds in the future. That's very good news for all as it sounds a very practical and pragmatic approach.

    Regarding a testing team, although I believe Lux has made several valuable suggestions I am not wholly in agreeement with the idea of a dedicated testing team. Why?

    As I said above
    It will be interesting to see how the devs want to play this but I think that all users need to help in this and report back what they can

    I have just 2 PCs, a laptop and 2 netbooks. Hopefully I will install SliTaz 3 on a few more PCs of friends etc but it's still a very very small subset. I truly believe that we need to encourage all users to submit reports as a small band of testers would never catch all possibilities.

    So my personal preference would be to have a very visible and easy to input section of this forum for all to make input. At the moment bug reports are scattered all over the forum which helps no-one not-least the devs and pkg builders. Of course the ideal would be to hope that everyone will use the labs site to input bugs reports but IMO that's an ideal situation which will not likely occur for sometime (if ever.)

    May I take this opportunity to say that I have been rather honest recently in making some comments and criticisms of SliTaz but I have done that only because I feel it has many very good things going for it and I want it to succeed and expand. If I did not care about SliTaz I would not have bothered. Thank you in turn for taking my comments very positively.
    It's very much appreciated.

    Best wishes
  • jozeejozee March 2010
    ===== Seawolf=====

    RE: bug reports:
    I feel Labs should be used once a fix cannot be instantly offered (i.e. if it is actually a bug that needs attention). I may be more optimistic of this as a user can come to the forum and ask for help, try a couple of things and should nothing work and a problem area be identified, they can be pointed to Labs. That's what I expect of a forum & bug tracker...

    RE: testing:
    Shall we move discussion of testing to a new thread? 50+comments on this may be OTT! Perhaps @Jozee you could copy your post to a new thread & @davesurrey the same afterward; I'll then move this one.
    As I've mentioned before, I'm using SliTaz as a base for a distro. It's still on-going as I'm aiming to sync with the v3 Slitaz release.
    I'd be happy to be part of the testing team as it would be beneficial to both sides. I've experienced a couple of glitches with old versions on my girlfriend's laptop but none on my netbook (N130); I'm soon to try it on a 64-bit desktop and a 32-bit quad-core desktop too. Hopefully a series of tests can be defined for basic use, as well as including idiosyncratic features.
    I feel it may be asked of the package maintainers to just install the package on a clean stable & cooking system install, possibly using VirtualBox or similar for ease, just to make sure all deps are satisfied. While I appreciate package devs have enough work, it is simply adding polish to their product.
  • LuXLuX March 2010

    So, the proposition of creating a "testing team" has at least two supporters, Linea and Jozee, among the administrators (yet another category which I don't know exactly how it intersects with devs and contributors :).

    On the other hand Dave votes for the "testing community" and Seawolf for the "testing procedure".

    Please note that the three proposition I made are not mutually exclusive. The "testing community" already exists and will continue to exist after any kind of team is created by the developpers (I mentionned it more or less as the "don't change anything" alternative). And a "testing procedure" could be a by-product of the "testing team".

    @Dave: I completely agree with you that a relatively small list of packages testers can't detect every possible issue. The most obvious issue is the test of drivers. There are very few of them which I could test, since personnaly I have one laptop and nothing more!

    The "testing team" I had in mind was something like an intermediate slice between contributors and end users. The problems you experienced with Abiword, for example, shows that before a package is added to the repos, it must be a little more tested by non-contributors, that is by "normal people" using a standard (not-for-programers) environment. And this normal people should have the not normal possibility to contact directly the contributor who submitted the new receipt they are testing, without drawning their reports in the forum and the labs.

    I would be glad to take part of such a team, in that sense.

    I don't know it it's practicable: it is something to test a package installing a simple program like Abiword, and something else to test a package for a driver, a -dev package, a package for i18n, and so on. This might be the limit of the idea of a "testing team".

    @Seawolf: I do not consider the labs as a very convenient way of reporting bugs. It's too messy in my opinion. Let me mention finally an interesting alternative that exists in Arch Linux.

    - 4 - one package = one mini-forum
    When a contributor creates a new package for Arch, he is considered as a maintainer (as in Slitaz, of course) and apprently a web page is created (sometimes? every time?) which is similar to the labs report pages, but devoted to this single package and centralizes every issue concerning it. I don't know if the persons who can post on such pages are ordinary end user, but I don't think so. Look at this example that Rupp indicated to me:

    Briefly speaking, this system:
    one package - one maintainer - one page
    seems better to me than:
    one package - one maintainer - 7 labs pages - 25 forum pages.

    A "testing team" could be simply a list of selected persons having in charge to follow every creation of such a one-package-devoted page, and report on it following certain guidelines. At least one positive report (or two? or three? Let's say one) would mean the package is accepted.

    What do you think about it?

    Best regards,

    PS: It might be that the system I'm describing above already exists, but I never heard about it, I only know the forums and labs.
  • kultexkultex March 2010
    I could do testing to, when I have time (not very regular) and I agree absolutly with Lux - but I think we/you have to go a little deeper in analysis.

    First let me look on distrowatch - tinycore (as comparable distro) is on place 15 - Sltaz on 48!

    What are the differences? - SliTaz for me is more advanced (e.g. language support, all the little aps, much quicker ....just to tell some), but let me come to the advantage of tinycore - it comes with this very small iso without any browser or apps, it boots on every computer (at least all I have tried until now) and you install just what you want. And there I never had any depency problems - but I really spent days on solving depency issus on the snow dillo iso.

    And thats what I propose also for Slitaz - to define the small basic (for me, its either core or the dillo snow iso) - there could be all sorts of flavours, but for testing, it should be one of these basic isos. And there was always the discussion that the iso is going to be to big.

    and I want to mention also the browser issue - I am not happy with netsurf (you cannot modify posts in the forum, no flash....) and not with firefox (on old computers it eats to much memory) - I propose Midori as default browser for slitaz - quick on old machines, language support, flash10 compatible - ok it loads a lot of apps, but nearly no influence - it runs fine with 89MB .....

    and still there is the forum issue - no advantages with vanilla?

    regards kultex
  • slicelslicel March 2010
    Kultex has a good idea to test on a designated base system (probably boot a live cd of it so it is like a fresh install).

    On vanilla, clicking to see more comments is not as convenient as paging.

    On browsers, maybe this should be a new thread, it might be good to define classes of browsers-

    1. Basic
    2. Intermediate (css, ssl, javascript)
    3. Full (flash, java)

    Then choose-


    I am not saying those are the best choices. There was another thread that discussed browsers. I asked about privacy and security but did not receive an answer. I do not know if Dillo or Midori will always be up-to-date for privacy and security.
  • jozeejozee March 2010
    Midori is all set to be the new default browser for SliTaz. We have made the changes and flash 10 has been tested to work. Official annoucement for a testing release candidate will be made soon.

    We, definitely, need a testing team. Anyone of you would like to initiate and lead once a RC is announced?

    TinyCore guys must be doing an amazing job if there is no dependency problem. SliTaz also initially never had any dependency problems. But as the repos are growing and the pkg building process is getting fully automated, we have encountered strange and frustrating problems. This automation is an innovative step that we have taken to lessen the backend burden on maintainers. We hope to resolve the problems soon.

    Also, we are taking steps to centralize the documentaion. ( We hope to document down steps to troubleshoot easily.

    PS: Tiny Core is more like SliTaz justx flavor. Also, to quote Robert, the creator of Tiny Core, "SliTaz is the impetus for creating Tiny Core"
    (;topic=1212.0 ; )

  • kultexkultex March 2010

    what I hate most in vanilla is this sausage of letters, that comes out when you search


    I hope that the depency problem is solved soon - and interesting that SliTaz was the impetus for TinyCore and funny, that he did not take all the good things.

    And I was really astonished, that I never had any depency problem - I think its the merit of the appbrowser - everybody sees all the time the depency of the app and all the files, which and where they will be installed. The appbrowser is something, that could be worth to take from TinyCore. It really helped me to debug the depency problems of the dillo.iso

    And the justX flavor is also fine - I think this basic iso for testing should not be more than 16 - 18MB
  • jozeejozee March 2010
    @kultex :
    You are absolutely right, our Slitaz forum theme is missing styling for search results. Its my fault, I know about it and I hate it too. We need to update the vanilla git version again to get this styling working. I will look into it when I have some more time.
  • davesurreydavesurrey March 2010
    For example try to install inkscape.tcz in tinycore 2.7 or 2,8 or 2.9 using a basic install without any other app to influence the deps.
    I think you'll find, as the founder roberts was honest enough to admit, it doesn't work. So not all in Tinycore is perfect.
    However I do think TC is a very well executed distro with a lot of positive things, just like SliTaz. Just don't want anyone to get the idea TC is the 100% perfect benchmark for loading apps.
  • kultexkultex March 2010

    no - this was not my interrest, TC is slow (I dont want to say horrible, but compared to Slitaz it is), has no language support and so on.. I have no interest in TC (I think its clear, when you read my other posts), but sometimes its necessary to think/look outside one's own box. Everybody here is doing an amazing job, but this seems not be seen outside.

    So I hope this testing groop will be a start of something somewhere is called quality managment....
  • LineaLinea March 2010
    Hi, I can probably lead this, BUT only from the RC up until stable 3.0 is released (after that we'll have to wait how things develop).

    When the RC is announced, I'll try and setup a page on the Labs and announce a basic framework for testing purposes.

  • LuXLuX March 2010

    thank you, Linea, for accepting to lead a testing team. I would be glad to participate to it, as a "normal user involved in testing Slitaz packages in a 'not-for-developers' environment". Or even better, as I read in some other forum, as a "trusted user", a category of users of Slitaz which would be interesting to relate one with each other in a way or another.

    I'm not sure about the sense of your message, partly due to my poor English. I understand your last sentence as referring to something similar to what I called "1 - testing procedure". But maybe it isn't. I'll see your announcement (also in this thread I suppose), but if you have a moment in the meantime, I would be pleased to know if you have any feeling, good or bad, concerning Arch's system that I called "4 - one package = one mini-forum" in above?

  • LineaLinea March 2010
    Hi Lux

    I think having 'one package - one maintainer - one page' is a great idea, but SliTaz is
    a democracy ruled by a dictator. So I can only lend support to other people's ideas.

    Just to try and clarify a few other things:

    1 The testing community will always exist! - Forums, Labs, Community platform, Mailing list, etc.

    2 There is a testing procedure already - namely Tank which the developers use to build
    the packages (but they still depend on the users to report any runtime problems).

    3 The basic framework was just to concentrate on the 'core' packages on the LiveCD and try and fix any bugs.

  • kultexkultex March 2010
    Hi Linea,

    democracy and dictatorship is a bit of a contradiction, but as long as the dictator is not killing all democrats, it could work ....

    and yes - nice you take the responsibility to lead. May I be a bit democratic from the beginning and let me ask, if "setup a page on the Labs" is perhaps a bit of a contradiction too, because I imagine this more in slitaz docs, so the user is able to see direct, if the package or the platform (computer) normally should work or not or if it could be any problems?

    regards kultex
  • claudineiclaudinei March 2010
    Hi @kultex,

    I guess @Linea is referring to "Benevolent Dictatorship" when he says "SliTaz is
    a democracy ruled by a dictator". See:

  • LineaLinea March 2010
    Hi, I'll set things up a bit in the next few days.... We'll still need a page on the Labs (it's the only bugtracker we've got at the moment).

    @kultex - Could you create a page that you'd like to see in the docs (in

    @claudinei - Yes, that's exactly what I meant!

  • claudineiclaudinei March 2010
    Hi all,

    I agree with @Linea, i think the labs is the right place for this project. We can open a labs project called "Packages" and then every package will be a sub project.

    As an example, see the xfce page on labs:

    We can create a wiki page for every package:

  • kultexkultex March 2010
    first Linea, thank you for formatting and correcting my UMTS doc

    and I think it could be both - the comprehensive view on docs and if there are any problems a link to the labs. And I think the openwrt hardware overview shows this better I can do

    a first page with all the groups like Net, Office, Audio,Video ....... (Device Manufacturers)

    the second page with the apps should be somethin like this .......

    and it could be quite simple with

    Name of the package..............Maintainer..........Tester ..............Problem...............Link to Labs if necessary

    the same I imagine for hardware, but here the first page should be something like Netbooks, Laptops, Embedded divices, PII, PIII,

    The problem is - until eastern I have no time to work on this and Linea I think you know much better, what are the formatting possibilities in docs (no idea if there is a possibilty for a raster)
  • LineaLinea March 2010
    Hi folks, I've opened a project on the labs:

    You'll need to register if you want to join in.

    @kultex - You can use tables on the wiki:
    but it's a bit fiddly. There's a guide here:

    I'm starting to think 'one package - one maintainer - one page' is a good idea!

  • kultexkultex March 2010
    @Linea - the playground was very helpful, but please how I get the table of contents

    ok here is my proposal - until eastern I am on tour - most of the time no internet and no time. So it would be nice, that somebody is continuing
  • cngsoftcngsoft March 2010
    After testing the latest ISO and liking many of its new features, I've just spotted a minor glitch in the midori-0.2.4 package: its receipt lacks a reference to libunique. Not unlike NetSurf and its missing reference to libgsf back in the day, when installing Midori on a clean Slitaz distro it complains about the unavailability of; it can only be run after doing 'tazpkg get-install libunique'.

    Reversely, I've also seen that several packages (poppler and libunique come to mind) need cairo-xcb-1.8.4 to install while others need cairo-1.8.8; if I perform 'tazpkg remove cairo-xcb' and I refuse to remove the packages depending on it, these packages can still be run as if nothing had happened.

    Last but not least, libwebkit depends on enchant, that adds half a megabyte to the distros and isn't too useful on its own, for it can't check any spelling without dictionaries. Making enchant an optional package for libwebkit rather than a mandatory one would help distros stay slim.
  • LineaLinea March 2010
    @kultex - that's fine, myself and Claudinei are doing some work on the Labs also.
  • jozeejozee March 2010
    @cngsoft: thanks for update on midori. I just backtraced and found that libunique dep in DEPENDS was accidently overwritten by this recent update :

    We should disable libunique in compile options. It is an optional dep.

    PS: Please post bugs with the latest RC cooking release in the new thread and don't mix it in this thread.
  • cngsoftcngsoft March 2010
    @jozee: You're welcome. I'll send RC-exclusive bugs to from now on.

    Meanwhile, I've just spotted another DEPENDS glitch: the latest giflib (required by imlib2 for instance) features "xorg -libX11" rather than "xorg-libX11". The "-libX11" is misunderstood as an invalid options parameter by grep and the result confuses tazpkg.

    Also, xine-lib has several mandatory dependences that could be safely moved to optional ones, such as jack-audio-connection-kit, vcdimager and libmodplug. On the other hand, it still lacks an audio codec for MPEG-4 AAC despite the availability of faad2.
  • jozeejozee March 2010
    @cngsoft: thanks a lot. giflib fixed:

    xine-lib: jack is definitely optional. We will have a look. Thanks, I like this. Please do report on all typos/mistakes/suggestions on making dependencies as optional.
  • LineaLinea March 2010
    Hi folks, Claudinei and myself have setup a 'tiny' testing environment on the


    If anybody who responded to this thread (LuX, kultex, anybody) wants to
    participate in the testing environment, just join the Labs and we can add you to the list of contributors.

    Claudinei has already started a 'Core Packages' page for any packages on the LiveCD:

    Sample page:


    PS: The redmine wiki formatting is very similar to our dokuwiki:
  • cngsoftcngsoft March 2010
    I lost the first version of this post :( Oh well.

    @Linea: excellent idea.

    @jozee: using the current RC ISO as the base, I built a minimal Xine setup able to play AVI (XviD+MP3), MP4 (H264+AAC) and FLV files with just four packages: xine-ui-0.99.5, xine-lib-, xorg-libXxf86vm-1.0.2 and ffmpeg-0.5. Xine needs the first three to run, and the fourth one to parse the test files. Some of the dependencies listed by the receipts were really necessary (xorg-libXtst-1.0.3 and xorg-libXv-1.0.4 for instance, both already installed in the RC ISO, but absent from reduced flavors such as "justX") while others could be safely skipped: readline, xorg-libXvMC, libtheora, vcdimager-xmltools, libmodplug, libmng,
    imlib2 and jack-audio-connection-kit weren't necessary for Xine to play the test files.

    P.S.: there's a cosmetic glitch in the cooking packages. The default icon theme is stored in /usr/share/icons/SliTaz, identifies itself as "Tango" and features a symbolic link at /usr/share/icons/Tango; unfortunately, this link confuses tazpkg when installing the Tango icon set, that can't create its folder in the place of the link (it must be removed before reinstalling slitaz-tango-icon-1.7), and the misidentifying index.theme fools lxappearance into listing both icon sets under the same name (its "Name=Tango" entry must be edited into "Name=SliTaz").
  • LineaLinea March 2010

    I lost the first version of this post :( Oh well.

    Hmm... there must be a bug in vanilla.

    If you don't move this post to another thread, I might not be able to fix it :)
  • seawolfseawolf March 2010
    Excellent, thank-you!

    As long as each package gets added there as it is added to the repos, it will be great!

    I hope to have some time after university (i graduate - hopefully! - this summer) to help with this more!
  • seawolfseawolf March 2010
    I've spent the past couple of hours looking at other distros testing schemes. They may give us some ideas for things to check for, specifically to pick up things we may have missed.

    (I added them to the wiki page [ ])

  • claudineiclaudinei March 2010
    Hi @seawolf,

    What's your labs username? I need to now it in order to add you as a contributor for the packages project.

  • claudineiclaudinei March 2010
    Hello again @seawolf,

    I've discovered your labs account and added you as a developer of the packages project. Now you can edit the packages wiki pages on labs.

  • kultexkultex April 2010
    I wanted to report a problem with tazusb in the 'Core Packages', but I cannot write - my labs username is the same
  • claudineiclaudinei April 2010
    Hi @kultex,

    Excuse me for the delay... I added you as developer on the packages project on labs.
    But if you have any issue or bug to report about tazusb, pls use it's own labs page:

  • LuXLuX April 2010

    I have been offline for a while (too much work and dead-lines... and it is not finished!). I can see that a lot of things have changed in the meantime, I'm sorry that have missed them.

    However I would have been pleased to use now the new "tiny testing environment" as Linea called it. I gave it a try, and sadly enough I have to say that I have been a little bit disappointed. It looks like yet-another-place-to-report-bugs, in addition to the forum and the labs but more complicated. This is quite different from what I mentionned in my already-old post, which was intended to decrease the number of such places and put some order in it, not at all to increase it (I have never been able to understand the logic of the labs structure):

    I noticed that nobody created any page in the wiki of the "Packages" project, so apparently I'm not the only one who gets in trouble here. Probably it was not such a good idea (a false good idea, as we say in french).

    I don't know if there is a possiblity to create a 'testing team' or not but this has certainly nothing to do with creating new wiki pages in the labs. Perhaps the only reasonable thing to do in this direction after all, is simply to give more precise directives to people who submit new receipts, I don' know.

    Anyway I apologize for having done a suggestion which seem to have been useless at the end (and time-consuming for Linea and Claudinei).

    Best regards,

  • kultexkultex May 2010
    LuX - I think you dont have to apologize - I think this thread was the starter for the "Summer of Documentation" - !!! I really like this idea !!!

    I have a question: "Complete migration of Handbook and Cookbook (Scratchbook, if possible)" - to where? I hope to Guides -, because the whole documentation is quite a mess - like the French handbook seems to be more uptodate than

    then (sorry Jozee, I wanted to talk with you before writing this) I have to talk about Vanilla. This is not a forum software, this is a pain in the ass.

    What is the main feature for a forum software? - I think it is to find quick help - but in this thing I do not find my own posts. And I do not have hope - we are waiting now half a year, but nothing changed. I want just translate a comment from KdE_: "It sould be forbidden to use Vanilla as a froum software" - and I really agree.
    So whats about FluxBB - FluxBB v1.4-rc3 is finally out, it has a very good searchengine (for Keyword and for Author) and it is also light and fast. I know it is a lot of work, but I think it is necessary. Sometimes I was so angry, thinking not to answer any more questions.

  • kultexkultex May 2010
    @jozee or whoever did the changing in Vanilla - thanks a lot - now it is possible to work, still attachments missing, but the search is much better and I have my posts without searching
  • UR10UR10 May 2010
    some more dep problems in cooking:

    segfaults after upgrades

    wants libgoffice-0.6, which was up'd to 0.8

    also, ldconfig doesn't like the current libstd++ in gcc-lib-base

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social