You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(32) |
Nov
(32) |
Dec
(26) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(14) |
Feb
(19) |
Mar
(18) |
Apr
|
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
(6) |
Mar
(4) |
Apr
(11) |
May
(6) |
Jun
(1) |
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(7) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Joseph N. <jn...@gm...> - 2018-12-05 09:05:01
|
Hi ! Maybe you can help ! _________________________________ Joseph NONGBE Consultant Systèmes d'information +225 43957272 jn...@gm... -------- Message transféré -------- Sujet : Issue when Install Bacula-postgresql Date : Wed, 5 Dec 2018 08:27:22 +0000 De : Joseph Nongbe <jn...@gm...> Pour : bac...@li... Dears, As explained in the Bacula Comunity Installation Guide, I want ton install the bacula-postgresql module by using the command : apt-get bacula-postgresql unfortunately, nothing done. I enter the right link in the repository. I think indeed ! the debian system said not to be able to find the package May someone help, please ? Debian version : 9 Bacula version : 9.2.2 -- _________________________________ Joseph NONGBE Consultant Systèmes d'information +225 43957272 jn...@gm... --- Cet email a fait l'objet d'une analyse antivirus par AVG. http://www.avg.com |
From: Kern S. <ke...@si...> - 2010-01-03 19:07:46
|
Hello, The other day, Eric pointed out to me that some of the manuals that we have posted in different languages are quite out of date -- in fact, the partial French translation apparently dates from version 1.38. As a consequence, starting with a few days ago with what is currently the development version 3.1.8, which will be released as version 5.0.0 sometime probably in January, I have reset all the foreign translations of the manual (French, Spanish, and German) to be identical to the current English manual. As we go forward, it would be really nice to have up to date translations. However, it is a lot of work. With the new git repo, it is much easier to maintain several versions of the manual and quite easily upload them, and going foward, we will maintain old versions of the manual in separate links on the web site. If any of you would like to start working on the previous translations to bring them up to date, it would be great. The only requirement would be to translate a whole chapter at a time. Once that is done, it is relatively easy to post it. If any of you want to checkout a version of the manual that has the old translations (it might be easier to start from an old one than starting from nothing), you can checkout the repo, then checkout a branch from the tag "Reset-translations", and you will have what existed prior to me copying the English over all the translations. Please note, there was a major re-organization of the manuals in version 3.0.0, and since then, I have re-organized them again in 3.1.8. Although there will be additional changes to the English version of the manual prior to release, there will not be any more major re-organizations until after the next major release. I hope you all had a great holiday season and survived seeing the New Year in ... Best regards, Kern |
From: Kern S. <ke...@si...> - 2007-12-13 15:22:08
|
Hello Thomas, OK, it is now done. The German manual builds without any visible errors -- I haven't looked at any of the output files though. Converting the German manual was much easier than the French manual, because you have updated all the files that you have translated to correspond to a recent version of the manual ... thanks. You might want to save a copy of your old German directory, though it is committed to the Branch-2.2 document, then checkout a whole new document tree. That will ensure that you get something clean. As you will see the manual-de is now gone. The README in the main directory is a good first cut at explaining what it going on ... Let me know if you have any problems -- I wouldn't be surprised if something shows up. The next step will be an attempt to make the whole set of documents look a bit more coherent -- the one that is really bad is the Bacula Concepts and Overview Guide ... By the way, if you want to change the title of a manual from English to German, you will need to change it in the main manual page, which is the name of the directory.tex (i.e. manuals/de/concepts/concepts.tex always has the main page for that manual), then you will need to make a corresponding change in the Makefile.in file in each manual, which is slightly tricky. Later today, I will add documentation to the README on how to do it. Finally, you need to re-run the ./configure ... to update the Makefile. Best regards, Kern On Thursday 13 December 2007 13:40, Kern Sibbald wrote: > On Thursday 13 December 2007 12:14, Thomas Glatthor wrote: > > Hello Kern, > > > > > > i have already committed my latest changes, > > so you can start with the reorganization. > > OK, thanks. I just did the French manual, so will take an hour pause to > recover, then I will start on the German manual ... > > Many thanks > > Kern > > > Best regards > > > > Thomas > > > > Kern Sibbald schrieb: > > > Hello Thomas, > > > > > > I have made the first cut of reorganizing the English version of the > > > manual, and would like to do the same thing to the French (no one is > > > working on it at the moment) and the German (you are actively working > > > on it) manuals. > > > > > > The situation is the following: > > > > > > The old manual was all in one single file (manual, manual-de, > > > manual-fr). > > > > > > The new manual is now split into 6 parts + the developers manual, and > > > it is all in: > > > > > > manual/en/catalog > > > concepts > > > console > > > developers > > > install > > > problems > > > utility > > > > > > In a certain sense, it is a big mess because the overall structure is > > > defined, but the parts are no longer coherent. I've separated the > > > parts by "files". To make it coherent, we will need two things: 1. move > > > some of the sections from one file to another (i.e. changes to the > > > source code). 2. Add some additional chapters ... > > > > > > Since I am ready to start moving text around from file to file, what I > > > propose is to modify the structure of the French and German manuals to > > > correspond to the English manual (i.e. to fill in manual/de/... and > > > manual/fr/... with the existing translations). Then at that point, I > > > can start moving sections around, carefully noting what I do, so that > > > the same can be applied to the French and German manuals. > > > > > > To do this, I will need you to commit all your work, then give me at > > > least one day to move things around (possibly faster if I am lucky). > > > > > > What do you think? > > > > > > Best regards, > > > > > > Kern > > > > > > PS: since there has been no recent work on the French manual, I will > > > start on it today ... > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac >e _______________________________________________ > Bacula-beta mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-beta |
From: Kern S. <ke...@si...> - 2007-12-13 12:40:47
|
On Thursday 13 December 2007 12:14, Thomas Glatthor wrote: > Hello Kern, > > > i have already committed my latest changes, > so you can start with the reorganization. OK, thanks. I just did the French manual, so will take an hour pause to recover, then I will start on the German manual ... Many thanks Kern > > Best regards > > Thomas > > Kern Sibbald schrieb: > > Hello Thomas, > > > > I have made the first cut of reorganizing the English version of the > > manual, and would like to do the same thing to the French (no one is > > working on it at the moment) and the German (you are actively working on > > it) manuals. > > > > The situation is the following: > > > > The old manual was all in one single file (manual, manual-de, manual-fr). > > > > The new manual is now split into 6 parts + the developers manual, and it > > is all in: > > > > manual/en/catalog > > concepts > > console > > developers > > install > > problems > > utility > > > > In a certain sense, it is a big mess because the overall structure is > > defined, but the parts are no longer coherent. I've separated the parts > > by "files". To make it coherent, we will need two things: 1. move some of > > the sections from one file to another (i.e. changes to the source code). > > 2. Add some additional chapters ... > > > > Since I am ready to start moving text around from file to file, what I > > propose is to modify the structure of the French and German manuals to > > correspond to the English manual (i.e. to fill in manual/de/... and > > manual/fr/... with the existing translations). Then at that point, I > > can start moving sections around, carefully noting what I do, so that the > > same can be applied to the French and German manuals. > > > > To do this, I will need you to commit all your work, then give me at > > least one day to move things around (possibly faster if I am lucky). > > > > What do you think? > > > > Best regards, > > > > Kern > > > > PS: since there has been no recent work on the French manual, I will > > start on it today ... |
From: Thomas G. <Tho...@ic...> - 2007-12-13 11:14:06
|
Hello Kern, i have already committed my latest changes, so you can start with the reorganization. Best regards Thomas Kern Sibbald schrieb: > Hello Thomas, > > I have made the first cut of reorganizing the English version of the manual, > and would like to do the same thing to the French (no one is working on it at > the moment) and the German (you are actively working on it) manuals. > > The situation is the following: > > The old manual was all in one single file (manual, manual-de, manual-fr). > > The new manual is now split into 6 parts + the developers manual, and it is > all in: > > manual/en/catalog > concepts > console > developers > install > problems > utility > > In a certain sense, it is a big mess because the overall structure is defined, > but the parts are no longer coherent. I've separated the parts by "files". > To make it coherent, we will need two things: 1. move some of the sections > from one file to another (i.e. changes to the source code). 2. Add some > additional chapters ... > > Since I am ready to start moving text around from file to file, what I propose > is to modify the structure of the French and German manuals to correspond to > the English manual (i.e. to fill in manual/de/... and manual/fr/... with the > existing translations). Then at that point, I can start moving sections > around, carefully noting what I do, so that the same can be applied to the > French and German manuals. > > To do this, I will need you to commit all your work, then give me at least one > day to move things around (possibly faster if I am lucky). > > What do you think? > > Best regards, > > Kern > > PS: since there has been no recent work on the French manual, I will start on > it today ... > |
From: Kern S. <ke...@si...> - 2007-12-13 10:53:43
|
Hello Thomas, I have made the first cut of reorganizing the English version of the manual, and would like to do the same thing to the French (no one is working on it at the moment) and the German (you are actively working on it) manuals. The situation is the following: The old manual was all in one single file (manual, manual-de, manual-fr). The new manual is now split into 6 parts + the developers manual, and it is all in: manual/en/catalog concepts console developers install problems utility In a certain sense, it is a big mess because the overall structure is defined, but the parts are no longer coherent. I've separated the parts by "files". To make it coherent, we will need two things: 1. move some of the sections from one file to another (i.e. changes to the source code). 2. Add some additional chapters ... Since I am ready to start moving text around from file to file, what I propose is to modify the structure of the French and German manuals to correspond to the English manual (i.e. to fill in manual/de/... and manual/fr/... with the existing translations). Then at that point, I can start moving sections around, carefully noting what I do, so that the same can be applied to the French and German manuals. To do this, I will need you to commit all your work, then give me at least one day to move things around (possibly faster if I am lucky). What do you think? Best regards, Kern PS: since there has been no recent work on the French manual, I will start on it today ... |
From: Kern S. <ke...@si...> - 2007-12-08 10:53:54
|
Hello, This is to let you know that over the next couple of weeks, I will be making a major reorganization of the manuals, and so request anyone wanting to make changes to the English manual to contact me first -- otherwise any changes you make risk being lost, which would be a pity. The changes I foresee are the following: 1. Reorganization of the manual directory structure to more easily accommodate multiple languages, multiple manual versions, and multiple manuals. 2. Divide the current 900+ page manual into a number of smaller manuals. I haven't yet decided exactly how many manuals to create, but at a minimum, I expect to have the following: Installation and Configuration Catalog database (installation, configuration, maintenance) Console (all types ...) FAQ Developers' Guide (already separate) Reference manual The problem in breaking up the manual is that there is a fine balance between one gigantic manual as we currently have and too many little manuals. Where the happy median is, I am not sure, but once the process is started and I have the new file structure, it should be relatively easy to split manuals in the future if we need to. I expect to make the same changes to the German and French manuals after completing the work on the English manual. Once I start that work (probably much later), I will send another email ... Best regards, Kern |
From: Ryan N. <nov...@um...> - 2007-07-19 14:26:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kern Sibbald wrote: > On Wednesday 18 July 2007 11:54, Adam C=E9cile wrote: >> Kern Sibbald a =E9crit : >>> Hello,=20 >>> >>> Since Beta 2.1.26 Eric and I have made a few changes and fixed a = few bugs=20 > in=20 >>> Bacula and Dirk has made a few updates to bat, so I am thinking o= f making=20 > a=20 >>> new beta release today or tomorrow. I will wait to get some feed= back from=20 >>> Eric concerning a problem Bill Moran has found in regression test= ing with=20 >>> regexwhere before cutting this beta. >>> >>> If anyone thinks there is any other critical item to implement/fi= x before=20 > the=20 >>> final release, now is the time to speak up. >>> >>> Best regards, >>> >>> Kern >>> >>> -----------------------------------------------------------------= -------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Bacula-users mailing list >>> Bac...@li... >>> https://lists.sourceforge.net/lists/listinfo/bacula-users >>> =20 >> Hi, >> >> I have some issues with a two drive autochanger and concurrent job= s. >> It works fine until two drive got tape from different pool. >> Let's assume there's one tape in drive0, pool weekly; one tape in= =20 >> drive1, pool daily; one job running on each tapes. >> If a new daily job is run, bacula will try to run it on drive0 and= then=20 >> fails because the drive is in use. >> >> Is this bug supposed to be fixed in 2.2 ? >=20 > This problem is fixed in the current 2.1.26 beta version. If you w= ant to be=20 > sure, I recommend that you test it. For what platforms is 'bat' available? Should it build from source on any UNIX OS? Which have been tested? I can test on HP-UX, IRIX and Solaris. I imagine Linux is covered. I do not have tape drives availa= ble on anything but Solaris though. - -- ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer I= I |$&| |__| | | |__/ | \| _| |nov...@um... - 973/972.0922 (2-09= 22) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C= 630 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn3Rtmb+gadEcsb4RAiDwAJ9ICN5QFqpl35b/OrFTfPfJDDNTfQCgh0oN /uWeAjTVyJZoHXlp3wERvUo=3D =3DY8wS -----END PGP SIGNATURE----- |
From: Kern S. <ke...@si...> - 2007-07-18 10:34:54
|
On Wednesday 18 July 2007 11:54, Adam C=E9cile wrote: > Kern Sibbald a =E9crit : > > Hello,=20 > > > > Since Beta 2.1.26 Eric and I have made a few changes and fixed a few bu= gs=20 in=20 > > Bacula and Dirk has made a few updates to bat, so I am thinking of maki= ng=20 a=20 > > new beta release today or tomorrow. I will wait to get some feedback f= rom=20 > > Eric concerning a problem Bill Moran has found in regression testing wi= th=20 > > regexwhere before cutting this beta. > > > > If anyone thinks there is any other critical item to implement/fix befo= re=20 the=20 > > final release, now is the time to speak up. > > > > Best regards, > > > > Kern > > > > -----------------------------------------------------------------------= =2D- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Bacula-users mailing list > > Bac...@li... > > https://lists.sourceforge.net/lists/listinfo/bacula-users > > =20 > Hi, >=20 > I have some issues with a two drive autochanger and concurrent jobs. > It works fine until two drive got tape from different pool. > Let's assume there's one tape in drive0, pool weekly; one tape in=20 > drive1, pool daily; one job running on each tapes. > If a new daily job is run, bacula will try to run it on drive0 and then=20 > fails because the drive is in use. >=20 > Is this bug supposed to be fixed in 2.2 ? This problem is fixed in the current 2.1.26 beta version. If you want to b= e=20 sure, I recommend that you test it. >=20 > It's my only whish, bacula is great ;) >=20 > Thanks in advance Kern, >=20 > Regards, Adam. >=20 > --=20 > Adam CECILE Linbox / Free&ALter Soft > 152 rue de Grigy t=E9l: +33 3 87 50 87 95 > Technop=F4le Metz 2000 fax: +33 3 87 75 19 26 > 57070 METZ - France http://www.linbox.com >=20 >=20 > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-devel-fr mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-devel-fr >=20 |
From: BOLLENGIER E. <er...@eb...> - 2007-07-18 10:09:54
|
Hi, > I have some issues with a two drive autochanger and concurrent jobs. > It works fine until two drive got tape from different pool. > Let's assume there's one tape in drive0, pool weekly; one tape in > drive1, pool daily; one job running on each tapes. > If a new daily job is run, bacula will try to run it on drive0 and then > fails because the drive is in use. > > Is this bug supposed to be fixed in 2.2 ? The reservation system have been rewrite in 2.2, IMHO this will fixe this bug. > It's my only whish, bacula is great ;) Thanks |
From: <ada...@li...> - 2007-07-18 09:57:21
|
Kern Sibbald a écrit : > Hello, > > Since Beta 2.1.26 Eric and I have made a few changes and fixed a few bugs in > Bacula and Dirk has made a few updates to bat, so I am thinking of making a > new beta release today or tomorrow. I will wait to get some feedback from > Eric concerning a problem Bill Moran has found in regression testing with > regexwhere before cutting this beta. > > If anyone thinks there is any other critical item to implement/fix before the > final release, now is the time to speak up. > > Best regards, > > Kern > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-users > Hi, I have some issues with a two drive autochanger and concurrent jobs. It works fine until two drive got tape from different pool. Let's assume there's one tape in drive0, pool weekly; one tape in drive1, pool daily; one job running on each tapes. If a new daily job is run, bacula will try to run it on drive0 and then fails because the drive is in use. Is this bug supposed to be fixed in 2.2 ? It's my only whish, bacula is great ;) Thanks in advance Kern, Regards, Adam. -- Adam CECILE Linbox / Free&ALter Soft 152 rue de Grigy tél: +33 3 87 50 87 95 Technopôle Metz 2000 fax: +33 3 87 75 19 26 57070 METZ - France http://www.linbox.com |
From: Kern S. <ke...@si...> - 2007-07-18 09:51:53
|
Hello, Since Beta 2.1.26 Eric and I have made a few changes and fixed a few bugs in Bacula and Dirk has made a few updates to bat, so I am thinking of making a new beta release today or tomorrow. I will wait to get some feedback from Eric concerning a problem Bill Moran has found in regression testing with regexwhere before cutting this beta. If anyone thinks there is any other critical item to implement/fix before the final release, now is the time to speak up. Best regards, Kern |
From: Kern S. <ke...@si...> - 2007-07-18 09:45:17
|
Hello Arno, Here is a little information that may help you. I'm copying the devel list too as some of the developers may be interested in this. As you mention below a hard linked file is simply one set of data that is pointed to by multiple file directory entries. All these "linked" files are completely equal to the original file that was created -- I don't think it is even possible to know in which order the files were linked. In a sense, a normal file is file data with a single hard linked file directory entry. When doing a backup, if the Bacula FD encounters a file that is hard linked, it backs up the data then "registers" that file as being backed up in a list of hard linked files. If another file is found that is hard linked, it will first check the list, and if the file is found in that "registered" list, the file data will not be backed up, but a "hard link" entry will be created indicating that the current file in question must be hard linked to the original file data that was backed up. This hard link entry contains a "pointer" to the file where Bacula actually saved the data. This ensures that the file data is not saved multiple times for each hard link. Now during the *normal* restore process, to properly restore the hard linked file, Bacula must restore the first copy that it saved which includes the data, then it must recreate the hard links to the other filenames, and it must be done in the correct order. During such a normal restore of all files, everything will work perfectly because it is done sequentially, and the file is first restored, then the link entries are processed, which restores the hard links. The problem (as far as I can tell) comes when the user uses the tree selection (or specific file/directory name selection). In this case, Bacula may be requested to restore a hard link entry, which has no file data. The code then finds the entry that does have the data and automatically marks it to be restored. In principle, the data will then always be restored first, and then the hard link, and thus all will work correctly. Previously, users with an IMAP program (Cyrius or something like that) that uses *lots* of hard links to link the mailbox files have reported some problems restoring files with errors like you are reporting. However, I was never able to track it down, and in fact the error was not totally reproducible (I have never been able to reproduce it). It is clear to me that something is going wrong in *some* case. It is not clear to me that there is anything wrong with the current design, but it seems there is either a bug, or some subtle twist in the whole scheme that is escaping me. My recommendation is to try to break it down to a single file with a single hard link or small number of hard links, and make it reproducible. Once we can reproduce it here, we can fix it. Concerning the suggestions about seeing what files exist ... That is pretty much out of the question. All the decisions on which files to restore are made in the Director, which has no knowledge of what is actually stored on the client. If the user blows away a hard link and wants to restore the link later but does not want the old file data restored, the only way to do it is to manually restore the link. If you use Bacula to select the link, it will automatically select the file data too -- you might be able to "trick" Bacula by selecting the link, then unselecting the data file. However, without doing a bit of research, I am not sure that the current Bacula listings clearly show the user which of the linked names actually contains the data. Of course, if the user deletes the hard link name where Bacula backed up the data, when Bacula restores that name, it is going to restore the data too. In the end, with the current Bacula design there is no convenient way to restore only a hard link -- I don't really consider this a big problem though. Best regards, Kern On Wednesday 18 July 2007 10:45, Arno Lehmann wrote: > Hi Kern, > > on the users list, we're currently discussing a problem related to > restoration of hard linked files. > > The issue is that, during restore, the user gets messages like > 17-Jul 11:40 linux-install-fd: RestoreFiles.2007-07-17_09.35.44 Error: > create_file.c:312 Could not hard link /part2/bin/cpio -> > /part2/var/ftp/bin/cpio: ERR=No such file or directory > > My assumption is that Bacula, during back up, registered this entry as > a hard link, and during restore, it simply tries to recreate the > directory entry, not the actual file data. > > Is this correct? > > I'm seeing several possible strategies to deal with hard links, but as > I didn't investigate how Bacula handles them in detail, if this > handling has been changed in recent versions, or if there is a feature > request regarding this, this is more or less guesswork. > > Anyway, if you're interested, the suggestions can be found below. > > Arno > > -------- Original-Nachricht -------- > Betreff: Re: [Bacula-users] FW: Bacula: Restore Error of > linux-install-fd Full > Datum: Wed, 18 Jul 2007 10:33:38 +0200 > Von: Arno Lehmann <al...@it...> > An: bac...@li... > Referenzen: > <6A8...@zu...> > <469...@it...> <469...@um...> > > Hi, > > 17.07.2007 19:22,, Ryan Novosielski wrote:: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Arno Lehmann wrote: > >> Hi, > >> > >> 17.07.2007 10:10,, Mair Wolfgang-awm013 wrote:: > >>> Hello, > ... > > >>> 17-Jul 11:40 linux-install-fd: RestoreFiles.2007-07-17_09.35.44 Error: > >>> create_file.c:312 Could not hard link /part2/bin/cpio -> > >>> /part2/var/ftp/bin/cpio: ERR=No such file or directory 17-Jul 11:40 > >> This is probably more of a problem. I think Bacula tries to restore > >> the hard link only, but the original file does not exist. This can > >> happen if you selectively restore, and in your selection are only file > >> entries detected as hard links by bacula, but the file data itself is > >> not restored and does no longer exist on disk. In my opinion, Bacula > >> should restore the complete file... I'm not sure if an upgrade to a > >> more current (beta) version fixes this, but I'm not even sure this is > >> the problem :-) > >> > >> [more hard link problems] > > > > This, unless you know more than I do, I'd have to disagree on. A hard > > link in UNIX is, if I understand this correctly, the equivalent of a > > cross-linked file in DOS. That is, the file is on disk, and there are > > multiple places pointing at it. The file is no more one of them than any > > other. > > Yes. One set of data, multiple directory entries pointing to it. The > directory entries are all equal, there's not one that points to the > original file and other marked as links. > > > A symlink is like a shortcut, and there the file is on disk in > > one place with a pointer at another place. Seems to me, backing up any > > one copy of a hard linked file should be enough. The question then is > > how does it handle multiple file locations? Maybe you are speaking to > > Bacula's handling. > > Yes... I recall there being a discussion about this some time ago. > > If I'm not mistaken, Bacula stores the file when it encounters it > first, but stores only the directory entry when it re-encounters the > same data from another directory entry again (data being identified by > device number and inode id). > > The problem Wolfgang encountered might result from the way Bacula > restores: The restored file collection probably did not include the > file itself, only the hard link information. > > I suppose that Bacula, in the version Wolfgang is running, is not > smart enough to notice that the data for this hard link is not > restored in the same job, so it tries to re-create the hard link > (directory entry) only. > > The question is - what would be the best approach when restoring hard > linked files? > > a) always restore the file data, thus creating unnecessary data on > disk when you actually only want the link restored? > b) always only restore the link (which is what happens now, if I guess > right), which will fail when the data is no longer present on disk, > and which will probably not be what the user wants? > c) be a little clever: Restore the data if it no longer exists on > disk, otherwise only recreate the hard link? > d) be really clever: Recreate the link only, when the file data still > exists on disk and is unchanged relative to the backed up data, and > restore the file if it's gone from disk, and restore the file as a > "complete" file if the data has changed. > > I'll try to illustrate: > > Backup time: > Data on device X, inode Y Link 1 Link2 > 123456 DataX/Y DataX/Y > > b, d) > Situation at restore time, data still exists. > Link2 selected for restore > DataX/Y Link2 > 123456 DataX/y > recreated as a hard link > > b) > Data gone, Link2 selected for restore > Link2 > DataX/Y > failure to create link because data does not exist > > c) > Data gone, Link2 selected for restore > DataX/Y Link2 > 123456 DataX/Y > recreated as a file with contents and directory entry > > c) > Data modified, Link2 selected for restore > DataX/Y Link2 > 987654 DataX/Y > this is probably not what the user expects because, after > restore, the contents of Link2 is not identical to what it was at > backup time. The file system structure is the same, though. > > d) > Other possibility: > DataX/Z Link2 > 123456 DataX/Z > file is recreated with the contents at backup time, but the > file system structure is different. > > > I think the most reasonable approach is d) as there, the restored file > contents will be identical to what you backed up, independent of file > changes in between. Obviously, that's the most difficult approach... > whenever Bacula tries to restore a file known as hard-linked, the FD > would have to decide if the data area still exists and has the same > contents as was backed up. > > > I don't really know. > > I don't, too - the above is mainly guesswork, based on vague > recollections of an earlier discussion :-) > > I'll ask Kern :-) > > Arno > > -- > Arno Lehmann > IT-Service Lehmann > www.its-lehmann.de > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-users mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-users > > -- > Arno Lehmann > IT-Service Lehmann > www.its-lehmann.de > |
From: Kern S. <ke...@si...> - 2007-07-16 16:40:47
|
Hello, Sorry this is a bit long ... 2.2.0 release should be soon: I have just made the last source code changes to version 2.1.27 that I am planning before the 2.2.0 release. Barring any new reported bugs, what is now in the SVN will be what is released, with the exception of a bit of work on the Release notes, and a review of the manual to ensure that we have documented all the new stuff. IMO, the code is very stable and ready for production use (the latest SVN changes are not yet tested, but *should* have little or no impact). The 2.2.0 release should occur any time from a week to a month from now. The exact date depends on how it "feels" and whether or not someone tests Win32. I am considering not releasing the Win32 binaries with 2.20 since IMO they have not been sufficiently tested. The old Win32 FD is compatible with 2.2.0. All that will be determined in the next week or two -- who knows, I may find enough energy to test Win32 myself. I remind you that the major objectives of this release were (at least from my own efforts) to improve performance, and to add a nice graphical user interface. Those two objectives with a lot of help from Eric and Dirk have been attained. The following items from the Projects List have been completed for 2.2.0: Items Completed: Item: 2 Implement a Bacula GUI/management tool. Item: 18 Quick release of FD-SD connection after backup. Item: 23 Implement from-client and to-client on restore command line. Item: 25 Implement huge exclude list support using dlist Item: 41 Enable to relocate files and directories when restoring Item: 42 Batch attribute inserts (ten times faster) Item: 43 More concurrency in SD using micro-locking Item: 44 Performance enhancements (POSIX/Win32 OS file access hints). Item: 40 Include JobID in spool file name After version 2.2.0: I plan to concentrate my personal efforts roughly 50/50 on two projects: 1. Implementing the framework to permit implementation of Projects List items 1 (Accurate restoration of renamed/deleted file) and 6 (Implement Base jobs -- also called de-duplication). 2. Setting up professional support services for Bacula (i.e. a company). I don't think the first item needs much explanation other than to say that once the framework is implemented, adding the specific features will be minor subprojects. The second item is something I have been discussing from time to time for about a year now. The background on that is that in the beginning Bacula was used by a small group of more or less independent sysadmins. I had a lot of pleasure working with them, helping them get Bacula installed, and implementing features they wanted. Now however, Bacula is being used more and more by enterprises (here I use this in a broad sense meaning: governments, universities, and corporations) which have some rather specific needs that are currently largely unfulfilled by the market place and by the Bacula Open Source project: 1. Enterprise needs require more high end features in Bacula 2. Enterprises are not willing (or cannot) make donations or pay for developement to an Open Source project (there are a very small numer of exceptions to this -- and thanks to those who are exceptions). 3. Enterprises can and do pay *very* hefty maintence fees sometimes for support of Open Source software, and some are willing to pay for certain development providing it is with a "company". 4. Many enterprises cannot or are reluctant to use Open Source software unless they have professional support contracts. 5. Other enterprises cannot or are reluctant to use Open Source software unless they have professional support contracts with the software supplier. 6. It is hard to find Open Source developers for a project like Bacula, but it is easy to hire them. 7. Bacula has now become a big project (especially with version 2.2.0) So after a lot of thought, as I have previously discussed, at least in part, on these lists, I have come up with the idea of creating a company to ensure that there is professional support for Bacula. To the best of my knowledge there is no parallel to the proposed company in the Open Software world. The nearest examples are Red Hat and MySQL, yet this company will be different. One unique aspect is that rather than retaining full control over the Bacula source code and putting it into this company, I have transferred its administration to the FSFE. I expect to see the Bacula project continue much as it is working hand in hand with the new company. The company service offering is planned to be: 1. Bacula Software Installation and Support Services with emphasis on providing level 3 support services to independent level 2 Bacula support providers. Only in the case where no level 2 (or special cases) do we expect to supply level 2 services. For those of you who are not familar with support levels: - Level 1 => in house support personnel - Level 2 => a company that supplies general support to level 1 support personnel of their clients. - Level 3 => support provided to professional support level 2 companies directly from the product developers. 2. Education and Certification Services These education and certification services are designed for: 1. Companies who wish to certify their own support or learn how to do it. 2. Individual consulatants. 3. Third party support providers 3. Consulting Services This should provide a means for companies to request and pay for development of specific features. The bottom line is that after a lot of discussions, I think this company can provide a nice interface between the Bacula project and independent Bacula service providers. Though I haven't gone into all the details, I don't see any conflict of interest with this project and the Bacula project -- in fact, IMO, it is probably the fastest way to have a way to employ people to add features to Bacula, no is there a conflict with large or small companies that supply consulting or support services. There is a small amount of overlap, but in general, we have found that existing support service organizations need some sort of contractual relationship with the Bacula project in order to satisfy their corporate customers, and that is the role we wish to fill. If all goes well, the company will be formed in the next few months, and will be in operation by the end of the year. At the moment, aside from myself, there are three other founders located in Switzerland, France, and Germany, and we are still looking for two or three more. Our current number of 4 is what we all consider the bare minimum to make the company work. We believe that it can be self-funding (each founder putting in a part of the capital and their manpower) and that at the end of the first year it will be profitable. If the concept works here in Europe, we will expand to the US within a year or two. The formation of such a company means a number of changes: 1. The development of Bacula will slow down for a period of about 6-9 months during the formation and initial running of the company, then should gradually get back to the current speed and over time if the company is successful, there should be a significant increase in the "contributions" to Bacula development. 2. Bacula project development will concentrate a bit more on Enterprise needs. 3. The Bacula project will remain largely unchanged. 4. In the near future the Bacula project will no longer be providing binaries. They will be available for free to individuals, contributors, and charitable organizations through the professional web site. 5. Professional support contracts will be possible (mostly through existing third party support organizations) or directly with the new company. 6. Bacula professional services will have a certification procedure, which will guarantee a minimum compentency level (provided you work with certified engineers or support services). 7. Enterprises will be able to contracturally fund specific development if desired. We have a *strong* preference that all development be integrated into the Open Source code base. I.e. we are not interested in proprietary development. At this point, we have a general corporate overview that will be posted on the corporate website once the corporation is created. We also have a proposed fee structure. We believe that we have defined a win-win situation that will benefit everyone currently working with Bacula including hardware manufacturers and future Bacula users. The losers (if there must be such) will be the large commercial backup software companies that are currently overcharging for their license fees. That is it in a nutshell. As part of this initiative, I have been visiting a few Bacula users. If you are a large professional service provider or a bank or big name company, or otherwise a big Bacula user and you are located in Europe, I would possibly like to visit your company for a day to explain this concept and more importantly to learn what you find missing in Bacula (the program or the services). If this interests you, please contact me directly off-list. As mentioned, we are still looking for a few additional "founders" that have Bacula experience (sysadmin, installation, running a Bacula installation, or programming) and over the next two years would like to work for a company such as what I have mentioned above. If that is your case, and you live in continental Europe, please contact me directly off-list. Best regards, Kern |
From: Kern S. <ke...@si...> - 2007-06-28 09:42:32
|
Hello, In making the Storage daemon locking a bit finer grained, I missed noticing one return statement in a subroutine -- consequence, a subroutine exited without clearing a lock giving a deadlock (on FreeBSD, the system would problably abort the program in detecting the deadlock). This occurred in the SVN sometime after 2.1.22 was released. It *should* now be fixed in the current SVN revision 5111. Thanks for reporting the problem, sorry for the inconvenience, and I would appreciate it if the regression testers would try the latest SVN. Regards, Kern |
From: Kern S. <ke...@si...> - 2007-05-07 13:56:15
|
Hello Dirk, I've taken a look at the multiplexing problems with the bat restore and have the following comments: For those of you who don't know exactly what we are talking about, when bat (or any restore command for that matter) is in the in memory tree selection routines, the Director is nested down in a subcommand interpreter that limits the commands to those of the restore tree. If you have a GUI like bat, while the user is selecting files from the Graphical tree, he/she can simply click on some other item, say Media, and thus generate a command that is sent to the Director that is normally handled by the main command interpreter, so Bacula gets confused, and this can abort the restore command that is in progress but not complete. The problem with the current bat implementation is as I have mentioned, it does not multiplex command, nor does it currently open multiple ports to the same Director (which accomplishes a sort of multiplexing). The structure of the classes is such that the Director has no class (if you want it is sort of a NULL class), but each Director has a Console attached to it and the console starts up the BSOCK (communications class). This allows each window that is started for a given Director to use the communications protocols that are defined in its console. The advantage is that there is a single unified console (text display window) for each director, and the console handles the details of the comm line, so each window needs only to know what its console is. That means we have: Console -> Socket 1. Now either we multiplex the Socket, which would be a major change to the Director source code (it may be the best long term solution), so is out of the question now. 2. Or we create a second Console ->Socket pair for use with the Restore command, which is by far the simplest kludge quickie solution, but has the disadvantage of separating Console output to two consoles for the same Director. 3. Or we block all other activity while the restore command is running (a bit ugly). 4. Or we re-arrange our classes (this would probably be something that can be done in the short term -- a week or two -- probably *after* the first beta release). The new arrangement might look something like the following: Director Open/close connection, ... Resource pointer Console pointer Socket pointer So we would pass a Director class to each of the Stacked widgets rather than a Console pointer, and the director communications would be done through the new Director class (we just move the console routines there). Now when the Restore window starts, it would get a Director pointer. It would then create a new Director, based on the Resource pointer in the Director, and would keep the existing Console, but it would cause a completely new connection to be established, so there would be a new Socket pointer. Now if all the I/O is done through the Director pointer, it will use the new socket (multiplex), but any console/status output would automatically go to the one and only console window associated with the director. There may be other solutions, but these are the ideas I had. By the way, in doing item 4, we can construct the new classes in keeping all the old classes, then convert the panes one at a time as necessary. My recommendation would be for the quickie fix to be item 2, which a better fix being item 4, and some more thought put into item 3 as a possible long term (6 month) solution. Best regards, Kern |
From: Kern S. <ke...@si...> - 2006-07-07 11:45:14
|
Hello, I am pleased to announce that there is now a new Bacula French speaking email list equivalent to the bacula-users list. It is called bacula-users-fr, and can now be subscribed to at: http://lists.sourceforge.net/mailman/listinfo/bacula-users-fr Also, Alexandre Baron <alexandre.baron at dalibo dot com> has begun an effort to translate the Bacula Website into French. When it is completed, it will be posted on our official web site. In the mean time, anyone who would like to see his work in progress can see: http://balex.homeip.net/bacula/fr/ Also, Eric Bollengier is working on translating the Bacula messages into French. Finally, Ludovic Strappazon has made nice progress in the monster task of translating the manual in to French, and I have now posted it to the Bacula web site on the same page as the rest of the documentation. When the "official" French Bacula site is put into place, the current links will be moved into the French pages ... Thank you very much to everyone in the French community for their support of Bacula, and I hope to see all these works come to fruition and a growing community of French speakers using the new list, who may have previously had some difficulties with English. Best regards, Kern PS: The new list is not yet mentioned in the Home Page email lists, but I will get to that in the near future ... |
From: Alexandre B. <ale...@da...> - 2006-07-06 15:40:19
|
Hi all, Le jeudi 6 juillet 2006 16:05, Kern Sibbald a =E9crit=A0: > On Thursday 06 July 2006 15:11, Mathieu Arnold wrote: > > +-Le 04/07/06 13:04 +0200, Kern Sibbald a dit : > > | On Tuesday 04 July 2006 10:05, Alexandre Baron wrote: > > |> I would like to promote Bacula in France and I am thinking about to > > |> create a french community aroud Bacula. That means at least create > > |> - a web site (baculafr.org or something similar) with online french > > |> documentation and latest news > > > > I do own bacula.fr, that could be used, or could redirect to > > bacula.org/fr if you'd rather have it this way. > > Oh, well that is an interesting and nice piece of information. > > I'm not sure exactly how to answer your question because there are a few > pieces of information I lack. Here are a few points that come to my mind. > > 1. If you are planning to put up a server, then it might be interesting to > make bacula.fr a French Bacula site. The only problem I would have is lo= ng > term support for the site. I cannot administer it, and would like to avo= id > any kind of "control" problem, which means that if you guys are well > organized; can assure the long term administration of the site; and can > work out how to resolve conflicts, this would be a really nice solution > allowing you to run things the way it suits you the best ... I can propose to host bacula.fr by my company that hosts already=20 postgresqlfr.org, so long term web site administration is not a problem. We= =20 have web servers and host many web site, so we can easily add one more web= =20 site. > 2. If you are not planning to put up a server or don't want to deal with > all the head-aches of security, ... then I see absolutely no problem havi= ng > bacula.fr redirected to bacula.org/fr and we maintain everything there -- > the site is currently hosted for Bacula for free in Germany. In the > beginning I would prefer to remain the person who actually posts the > content, but within a short time (a month or so), if one of you really > takes charge of the French material (French CVS home-page, organization of > French community, ...), I'll be very happy to provide someone with FTP > access to the Bacula site (the same and only access that I have). I have proposed to help for translation of the web site and hosting also. Let me know if you are interested my hosting proposal. I suggest to keep CV= S=20 for french site managed by you, and of course you remains the only person w= ho=20 posts the content (I just translate). But I have the idea for the future to= =20 put one CMS to permits to have many people allowed to post easily messages = on=20 bacula french web site. but this will take a longer time than just translat= e=20 php pages into french. For now, I've just started to translate Bacula web=20 site to have a start point to see if people are interested in Bacula french= =20 web site. I have started to translate Bacula web site into french. You can have an=20 overview on my personnal machine at : http://balex.homeip.net/bacula/fr/ So first we can just build bacula.org/fr (next week?) on your web server an= d=20 then, if we agree, create bacula.fr on another web server As the organization of French community is concerned, I suggest that people= =20 who are interested in Bacula French community management communicate in the= =20 new bacula-users-fr list when it will be created to determine if we (french= =20 people) are ready to organize it and who manage it (once again I propose my= =20 help for that but I don't necessary want to manage it). > But just so you know, in the next few days, I should be creating the > bacula-users-fr mailing list, and also posting the current French > translation of the manual to the web site. Ok, thanks very much for that. > The French Manual looks really=20 > nice -- though as you can image with such a big manual, there is still a > lot to translate. Bravo Ludovic for the excellent work you have done ... Yes, that's true. Thanks again Ludovic! Regards, Alexandre |
From: Mathieu A. <ma...@ma...> - 2006-07-06 14:34:49
|
+-Le 06/07/06 16:05 +0200, Kern Sibbald a dit : | On Thursday 06 July 2006 15:11, Mathieu Arnold wrote: |> +-Le 04/07/06 13:04 +0200, Kern Sibbald a dit : |> | On Tuesday 04 July 2006 10:05, Alexandre Baron wrote: |> |> I would like to promote Bacula in France and I am thinking about to |> |> create a french community aroud Bacula. That means at least create |> |> - a web site (baculafr.org or something similar) with online french |> |> documentation and latest news |> |> I do own bacula.fr, that could be used, or could redirect to |> bacula.org/fr if you'd rather have it this way. | | Oh, well that is an interesting and nice piece of information. | | I'm not sure exactly how to answer your question because there are a few | pieces of information I lack. Here are a few points that come to my mind. | | 1. If you are planning to put up a server [...] That is a solution, I also own a not so small web/colo hosting company here in Paris, and we don't plan on running out of business soon :-) | 2. If you are not planning to put up a server or don't want to deal with | all the head-aches of security That is also a possibility, which on your part is means having all the information centralized and so, easier to deal with. Now, I have absolutely no problem with either solution, they all seem right to me. -- Mathieu Arnold |
From: Kern S. <ke...@si...> - 2006-07-06 14:05:34
|
On Thursday 06 July 2006 15:11, Mathieu Arnold wrote: > +-Le 04/07/06 13:04 +0200, Kern Sibbald a dit : > | On Tuesday 04 July 2006 10:05, Alexandre Baron wrote: > |> I would like to promote Bacula in France and I am thinking about to > |> create a french community aroud Bacula. That means at least create > |> - a web site (baculafr.org or something similar) with online french > |> documentation and latest news > > I do own bacula.fr, that could be used, or could redirect to bacula.org/fr > if you'd rather have it this way. Oh, well that is an interesting and nice piece of information. I'm not sure exactly how to answer your question because there are a few pieces of information I lack. Here are a few points that come to my mind. 1. If you are planning to put up a server, then it might be interesting to make bacula.fr a French Bacula site. The only problem I would have is long term support for the site. I cannot administer it, and would like to avoid any kind of "control" problem, which means that if you guys are well organized; can assure the long term administration of the site; and can work out how to resolve conflicts, this would be a really nice solution allowing you to run things the way it suits you the best ... 2. If you are not planning to put up a server or don't want to deal with all the head-aches of security, ... then I see absolutely no problem having bacula.fr redirected to bacula.org/fr and we maintain everything there -- the site is currently hosted for Bacula for free in Germany. In the beginning I would prefer to remain the person who actually posts the content, but within a short time (a month or so), if one of you really takes charge of the French material (French CVS home-page, organization of French community, ...), I'll be very happy to provide someone with FTP access to the Bacula site (the same and only access that I have). There are currently several "emergency" situations going on here (my Spam filter no longer works, and a charitable site -- Mercy Ships -- that I administer is cut from the Internet -- the SonicWall box appears to have partially died), so I am slowed down by dealing with both of them in priority. But just so you know, in the next few days, I should be creating the bacula-users-fr mailing list, and also posting the current French translation of the manual to the web site. The French Manual looks really nice -- though as you can image with such a big manual, there is still a lot to translate. Bravo Ludovic for the excellent work you have done ... I look forward to feedback on the above two points ... Best regards, Kern |
From: Mathieu A. <ma...@ma...> - 2006-07-06 13:11:58
|
+-Le 04/07/06 13:04 +0200, Kern Sibbald a dit : | On Tuesday 04 July 2006 10:05, Alexandre Baron wrote: |> I would like to promote Bacula in France and I am thinking about to |> create a french community aroud Bacula. That means at least create |> - a web site (baculafr.org or something similar) with online french |> documentation and latest news I do own bacula.fr, that could be used, or could redirect to bacula.org/fr if you'd rather have it this way. -- Mathieu Arnold |
From: Alexandre B. <ale...@da...> - 2006-07-05 06:22:42
|
Hello, Le mardi 4 juillet 2006 17:13, vous avez =E9crit=A0: > On Tuesday 04 July 2006 15:08, Alexandre Baron wrote: > > ok, I will first subscribe to this list, but I think I will create a li= st > > for users and not developpers to translate your announce for eg. > > By the way, I was a bit puzzled by the above remark that you made (i.e. > unsure what you meant). > > The bacula-devel-fr list is explicitly meant for translators, whom I > consider to be "developers". So, it would be best to use that list when > discussing any translations. The language of that list is French and all > the current translators including myself are subscribed to it. The list = is > pretty inactive for the moment. > > However, if you would like a French speaking list for discussing bacula > issues, similar to the bacula-users list. I would be very happy to create > one (probably bacula-users-fr) providing there is someone like you who is > willing to help "moderate" the list. Yes, it should be a good to have such list. If you want I can help to moder= ate=20 it. > By "moderate" I don't mean anything really active, but rather someone nee= ds > to be listening and willing to respond to questions that no one else will > answer, and more importantly than that, I am very proud of the bacula-use= rs > list because the people who use it are very polite and helpful. > > I've seen a *lot* of mailing lists in my life and a good number are > arrogant, do not respect the ignorant users, are often vulgar, and get in= to > flame wars. This does not exist on any of the Bacula lists, and I would > like to avoid those kinds problems on any new Bacula lists. It is > relatively simple to avoid by just having one or two people who politely > discourage such behavior if/when it shows up. Ok, I understand your meaning and share your point of view about moderatati= on. Regards, Alexandre |
From: Alexandre B. <ale...@da...> - 2006-07-04 15:53:28
|
Le mardi 4 juillet 2006 17:08, Ludovic Strappazon a =E9crit=A0: > Hello all, > > If you want to take a look at the translated pages : > http://strapp.hd.free.fr/bacula-fr/ > > The "brief tutorial" chapter is completely translated : > http://strapp.hd.free.fr/bacula-fr/breve_documentation.html > > I'm currently working on "configuring the storage daemon". > > The translation is almost up to date and I now have a method to update. > > I'd be happy to get a feed back from readers, at least to know if I work > in the good way. Ok, I think I will take the time during this month to read all your=20 translations. I have had a quick look and it looks nice! Regards, Alexandre |
From: Kern S. <ke...@si...> - 2006-07-04 15:38:41
|
Hello Ludovic, I think there is sufficient material translated that we should now put this up on the Bacula web site. What do you think? Could you update to the current CVS since I changed the copyright? You may need to adjust the title page a bit as I see you have improved the appearance a bit, which will be lost with my copyright changes ... Probably we should simply note on the title page that the document is in the process of being translated and that the user should not be too surprised to run into untranslated chapters that are in English ... Best regards, Kern On Tuesday 04 July 2006 17:08, Ludovic Strappazon wrote: > Hello all, > > If you want to take a look at the translated pages : > http://strapp.hd.free.fr/bacula-fr/ > > The "brief tutorial" chapter is completely translated : > http://strapp.hd.free.fr/bacula-fr/breve_documentation.html > > I'm currently working on "configuring the storage daemon". > > The translation is almost up to date and I now have a method to update. > > I'd be happy to get a feed back from readers, at least to know if I work > in the good way. > > Best regards, > Ludovic Strappazon. > > > I think it is a good idea to create a fr subdirectory in the home-page of > > the docs. > > > > I am pretty flexible about giving CVS access. However, please read the > > Developer's guide, and you will see that I like to work with someone just > > a bit before giving them CVS access. What I propose is the following: In > > a separate email, I will send you a tarred copy of my checked out docs > > directory from the CVS. This guarantees that you have the current code > > as sometimes the public CVS lags behind. Then you detar the file, create > > your subdirectory, and do the translation, tar it back up and send it to > > me. Then we will go from there. > > > > A few pointers: a portion of the work will be to adjust the links so that > > clicking on the menu items keeps you in the fr subdirectory. Another > > part of the work is adjusting the links into the manual. For the moment, > > I suggest you leave them pointing to the English manual, because the > > portion of the manual that is translated into French is not loaded on the > > site. It is very likely that some of the pages are already translated. > > Once I get your translated web site, we can take a look at it, and put > > any translated manual pages on the web site, and those that need > > translating, we can give a priority. > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Bacula-devel mailing list > Bac...@li... > https://lists.sourceforge.net/lists/listinfo/bacula-devel |
From: Kern S. <ke...@si...> - 2006-07-04 15:13:26
|
Hello, On Tuesday 04 July 2006 15:08, Alexandre Baron wrote: > ok, I will first subscribe to this list, but I think I will create a list > for users and not developpers to translate your announce for eg. By the way, I was a bit puzzled by the above remark that you made (i.e. unsure what you meant). The bacula-devel-fr list is explicitly meant for translators, whom I consider to be "developers". So, it would be best to use that list when discussing any translations. The language of that list is French and all the current translators including myself are subscribed to it. The list is pretty inactive for the moment. However, if you would like a French speaking list for discussing bacula issues, similar to the bacula-users list. I would be very happy to create one (probably bacula-users-fr) providing there is someone like you who is willing to help "moderate" the list. By "moderate" I don't mean anything really active, but rather someone needs to be listening and willing to respond to questions that no one else will answer, and more importantly than that, I am very proud of the bacula-users list because the people who use it are very polite and helpful. I've seen a *lot* of mailing lists in my life and a good number are arrogant, do not respect the ignorant users, are often vulgar, and get into flame wars. This does not exist on any of the Bacula lists, and I would like to avoid those kinds problems on any new Bacula lists. It is relatively simple to avoid by just having one or two people who politely discourage such behavior if/when it shows up. Let me know what you think, Best regards, Kern |