[Bacula-users] Re: Bacula packaging
Kern Sibbald wrote: > Hello, > > With the exception of the RPMs that are built by Scott, and the FreeBSD port, > I have noticed that all the other "official" Bacula ports have seriously > lagged. I suspect that this is because the people responsible for those > ports are no longer available: too busy with work, changed jobs, lost > interest, ... > > Luca Berra (Mandrivia) I am sorry, but i fall in the list of persons that have lagged behind, mostly because i have been swamped in work, i'll try to catch up or get someone else from Mandriva (btw it is spelt Mandriva, not Mandrivia) to take over the port. For the time being please keep my name. regards, L. -- Luca Berra --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Re: Bacula packaging
Kern Sibbald wrote: > Hello José Luis, > >> I do have been too busy, unfortunately. >> Personal problems before and finishing my Master Thesis later (i'm just >> finished with this -- last friday was the day). >> > > Well sorry to hear about your problems, but congratulations on having > finished > your Master's Thesis. That is an especially impressive thing considering (if > I am not mistaken) that you are also working ! > well... you're right :-$ All is basically done, however. So let's continue on to the fun stuff. >> The fact that bacula 1.38 made it impossible to link the sd tools >> statically didn't make it easier. >> The fact that the documentation has been splitted apart didn't help either. >> > > Yes, 1.38 was quite a big change in packaging to previous versions. > > I'm not sure why you say that the SD tools don't statically link. I have no > problem here. Perhaps you are trying to link them with too many options such > as with openssl enabled but do not have the static libraries loaded. When I > want a static version, I vastly simplify the ./configure options (no > tcpwrappers, no comm encryption, ...). > Ok.. i'll try that sometime. For the time being, i will be supplying 3 "flavors" of bacula-sd and that's it. > [snip] >> No prob. Even though keeping the debian packaging stuff within an >> upstream package is normally regarded as a "not so good" idea. >> My packages' source code is freely available, anyway. >> > > Unless your packages source code is in some official Open Source repository > (e.g. Debian), I would much prefer adding it to the Bacula source. This > guarantees continuity for the whole community. Please let me know on this > point. I don't consider it urgent, but I would like to work on it ... > As you wish. It is indeed available from the Official Debian Archive. deb-src ftp://ftp..debian.org/debian main apt-get update && apt-get source bacula In form of a "pristine" upstream tarball (your released tarball) plus my changes (in `diff -u` form) >>> - For each port (ideally, over time), I would like to have a small >>> chapter in the manual much like the RPM FAQ chapter that explains how to >>> build the binaries from the platform code, and any other particularities >>> of the port. Given feedback from a knowledgeable person, this is >>> something I can help with a lot. >>> >> Ok. We can do that, definitively. >> > > OK. That is more of a long term project, but I think it will benefit > everyone > and also give you a chance to directly address the Bacula users in the > manual. > :-D > >> Well, i should be up to speed almost inmediately (hopefully) >> I arrived home late yesterday night, and am beginning to work right >> now let's see what happens. >> > > OK, thanks for the feedback. It would be nice if you could work on it a bit > in > the near future. However, before releasing anything, you might want to wait > just a few days, because I am going to release a 1.38.7 (I previously > suggested 1.38.6.1), which has *very* minimal changes to the source, none of > which should change the Debian release, but it would be nicer to release > 1.38.7 rather than 1.38.6 and have me release 1.38.7 a day or two later :-) > Alpha/beta releases now withstanding, i'll do that. I'm going out for a short vacation 8-16th April, but will try to stay connected. Cheers, J.L. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Re: Bacula packaging
Hello José Luis, On Thursday 06 April 2006 13:34, José Luis Tallón wrote: > Kern Sibbald wrote: > > Hello, > > Hi, Kern. > > > With the exception of the RPMs that are built by Scott, and the FreeBSD > > port, I have noticed that all the other "official" Bacula ports have > > seriously lagged. I suspect that this is because the people responsible > > for those ports are no longer available: too busy with work, changed > > jobs, lost interest, ... > > I do have been too busy, unfortunately. > Personal problems before and finishing my Master Thesis later (i'm just > finished with this -- last friday was the day). Well sorry to hear about your problems, but congratulations on having finished your Master's Thesis. That is an especially impressive thing considering (if I am not mistaken) that you are also working ! > > The fact that bacula 1.38 made it impossible to link the sd tools > statically didn't make it easier. > The fact that the documentation has been splitted apart didn't help either. Yes, 1.38 was quite a big change in packaging to previous versions. I'm not sure why you say that the SD tools don't statically link. I have no problem here. Perhaps you are trying to link them with too many options such as with openssl enabled but do not have the static libraries loaded. When I want a static version, I vastly simplify the ./configure options (no tcpwrappers, no comm encryption, ...). > > I do have an "alpha" 1.38.5 package, which i want to finish before the > weekend, now that i am home again :-) > I'll keep you posted > > > I do thank those of you who in the past who have supplied ports for the > > work you have done. I hope to hear from you all concerning your > > availability for future ports whether positive or negative. Things > > change, that is not a problem, but I'd like to organize the ports a bit > > better for the Bacula users, which is the purpose of this email. > > Indeed. I sincerely apologize to the users for my inability to deliver > updated packages in the past... things simply are not as easy as i would > like. It is quite understandable that you have been busy. I'm just pleased about all the work you have done. If you are now able to continue doing the Debian packaging -- all the better. > > > Three new people have proposed their ports: many thanks. Rather than > > writing much the same thing to each of you, I've decided to send this > > email -- bottom line, I would be *really* happy to have someone doing > > ports, even if it is a one shot event. > > > > Here is how I can see this working: > > - For each port, I would like to have one (or possibly two persons) > > officially designated as the ports person. The name and email address of > > the ports persons should be posted on the Web site so it is clear who the > > ports person(s) is. If more than one person is doing a particular port, > > they will work together to decide who does what (share the work, or > > alternate releases,...). Certain of you may be willing to do a port but > > won't have time to answer questions or take bug reports. If that is the > > case, we can indicate those things on the Web site as well (i.e. are you > > willing to help or is the user on his own ...). > > > > - For each port I would like to have all the necessary scripts and > > control files committed to the Bacula source code in the appropriate part > > of /platforms/... This will permit continuation of the > > port if a port person is not able to continue the work. This code can be > > committed and maintained by each of the ports persons directly. > > No prob. Even though keeping the debian packaging stuff within an > upstream package is normally regarded as a "not so good" idea. > My packages' source code is freely available, anyway. Unless your packages source code is in some official Open Source repository (e.g. Debian), I would much prefer adding it to the Bacula source. This guarantees continuity for the whole community. Please let me know on this point. I don't consider it urgent, but I would like to work on it ... > > > - For each port (ideally, over time), I would like to have a small > > chapter in the manual much like the RPM FAQ chapter that explains how to > > build the binaries from the platform code, and any other particularities > > of the port. Given feedback from a knowledgeable person, this is > > something I can help with a lot. > > Ok. We can do that, definitively. OK. That is more of a long term project, but I think it will benefit everyone and also give you a chance to directly address the Bacula users in the manual. > > > - Ideally the binaries for each port will be loaded in the Bacula ports > > section of Source Forge. This can be directly done by the ports person. > > There is no reason why these binaries can not be available elsewhere at > > the same time depending on your preference. > > I do have upload access, so count on it. Thanks. > > > - It is not required, but much bett
[Bacula-users] Re: Bacula packaging
Kern Sibbald wrote: > Hello, > Hi, Kern. > With the exception of the RPMs that are built by Scott, and the FreeBSD port, > I have noticed that all the other "official" Bacula ports have seriously > lagged. I suspect that this is because the people responsible for those > ports are no longer available: too busy with work, changed jobs, lost > interest, ... > I do have been too busy, unfortunately. Personal problems before and finishing my Master Thesis later (i'm just finished with this -- last friday was the day). The fact that bacula 1.38 made it impossible to link the sd tools statically didn't make it easier. The fact that the documentation has been splitted apart didn't help either. I do have an "alpha" 1.38.5 package, which i want to finish before the weekend, now that i am home again :-) I'll keep you posted > I do thank those of you who in the past who have supplied ports for the work > you have done. I hope to hear from you all concerning your availability for > future ports whether positive or negative. Things change, that is not a > problem, but I'd like to organize the ports a bit better for the Bacula > users, which is the purpose of this email. > Indeed. I sincerely apologize to the users for my inability to deliver updated packages in the past... things simply are not as easy as i would like. > Three new people have proposed their ports: many thanks. Rather than writing > much the same thing to each of you, I've decided to send this email -- bottom > line, I would be *really* happy to have someone doing ports, even if it is a > one shot event. > > Here is how I can see this working: > - For each port, I would like to have one (or possibly two persons) > officially > designated as the ports person. The name and email address of the ports > persons should be posted on the Web site so it is clear who the ports > person(s) is. If more than one person is doing a particular port, they will > work together to decide who does what (share the work, or alternate > releases,...). Certain of you may be willing to do a port but won't have > time to answer questions or take bug reports. If that is the case, we can > indicate those things on the Web site as well (i.e. are you willing to help > or is the user on his own ...). > > - For each port I would like to have all the necessary scripts and control > files committed to the Bacula source code in the appropriate part of > /platforms/... This will permit continuation of the port if > a port person is not able to continue the work. This code can be committed > and maintained by each of the ports persons directly. > No prob. Even though keeping the debian packaging stuff within an upstream package is normally regarded as a "not so good" idea. My packages' source code is freely available, anyway. > - For each port (ideally, over time), I would like to have a small chapter in > the manual much like the RPM FAQ chapter that explains how to build the > binaries from the platform code, and any other particularities of the port. > Given feedback from a knowledgeable person, this is something I can help with > a lot. > Ok. We can do that, definitively. > - Ideally the binaries for each port will be loaded in the Bacula ports > section of Source Forge. This can be directly done by the ports person. > There is no reason why these binaries can not be available elsewhere at the > same time depending on your preference. > I do have upload access, so count on it. > - It is not required, but much better if each of the ports releases either > has > an internal checksum or hashcode as is the case with RPMs or has a separate > signature file as is the case with the .tar.gz and the windows.exe files. > Given any binary file that does not have an internal hash or checksum, either > Scott or myself can generate a signature file for you. > Ok. Upcoming Debian packages will be signed by me. GPG Id: 0x0210652C > - When a new Bacula release is made, each ports person will indicate (I > haven't decided exactly how) his schedule for getting out the port. > > - If a ports person cannot do a particular port or can no longer do any port, > he should notify Kern so that we can attempt to replace him. > > For your information, here is the current list of packagers. I request each > of them as well as anyone who is interested to send a note to this list to > let us know what you think. > > Jose Luis Tallon (Debian) > Scott Barninger (RPMS) > Lars Koeller (FreeBSD) > Keith Conger (MacOSX) > Thomas Cameron (Gentoo) > Luca Berra (Mandrivia) > Eamon Brosnan(MacOSX) > Geert Hendrickx (NetBSD) > > I am interested in hearing your feedback on these ideas and refining them. > Well, i should be up to speed almost inmediately (hopefully) I arrived home late yesterday night, and am beginning to work right now let's see what happens. Regards, J.L.
