openbsdbinpatch-misc Mailing List for Binary patches for OpenBSD
Brought to you by:
convexo
Menu
▾
▴
openbsdbinpatch-misc — General discussion about OpenBSD's binpatch
You can subscribe to this list here.
| 2007 |
Jan
(48) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: G. S. G. G. <ger...@gm...> - 2008-04-22 22:28:16
|
On 4/21/08, Mike Erdely <mi...@er...> wrote:
> Below is a diff to bsd.binpatch.mk that adds a "combo" target.
> It iterates through the binpatch packages <= ${PATCH} untarring
> them to a temporary location. Then creates an "upto${PATCH}" tarball.
>
> Thoughts?
Ok, I have looked closer and I have two questions.
> --- bsd.binpatch.mk Mon Mar 31 01:40:25 2008
> +++ bsd.binpatch.mk Mon Mar 31 01:51:57 2008
> @@ -257,6 +257,26 @@ package: build
> @echo "|"
> @echo "+-------------------------"
>
> +${PACKAGEDIR}/${DISTNAME}-${ARCH}-upto${PATCH}.tgz:
> ${PACKAGEDIR}/${FULLPKGNAME}.tgz
> + @echo "===> Building combination package for ${PATCH}"
> + @rm -Rf ${.CURDIR}/.combo_pkg
> + @mkdir -p ${.CURDIR}/.combo_pkg
1. did you choose ${.CURDIR} instead of ${.WRKDIR} for creating
.combo_pkg for a reason?
2. Does -C has any purpose here?
> + @tar -C ${WRKINST} -czpf
> ${PACKAGEDIR}/${DISTNAME}-${ARCH}-upto${PATCH}.tgz \
> + `(cd ${.CURDIR}/.combo_pkg && find . -type f)`
> + @rm -Rf ${.CURDIR}/.combo_pkg
Thanks in advance.
--
Gerardo Santana
|
|
From: G. S. G. G. <ger...@gm...> - 2008-04-22 04:41:09
|
I have just moved the CVS repository to Git. You can access the public repository here: http://github.com/santana/binpatch/tree/master -- Gerardo Santana |
|
From: Mike E. <mi...@er...> - 2008-04-21 20:03:40
|
On Mon, Apr 21, 2008 at 02:57:42PM -0500, Gerardo Santana G?mez Garrido wrote:
> Hi Mike,
>
> I guess this line
> + mypkg=${DISTNAME}-${ARCH}-`printf "%03d\n" $$count`.tgz; \
>
> shoud be
> + mypkg=${DISTNAME}-${ARCH}-`printf "%03d" $$count`.tgz; \
>
> without the new line.
Haha! Of course the \n snuck in there from testing. Strangely, it
works even with the \n in there. But, you're right... It shouldn't be
there.
> It looks fine to me.
>
> The only issue I see is that the user may expect that this new target
> also builds the packages, if they don't exist. Nothing that the
> documentation can't fix though.
>
> Any other thought?
I think documentation is the way to go.
> --
> Gerardo Santana
-ME
|
|
From: G. S. G. G. <ger...@gm...> - 2008-04-21 19:57:44
|
Hi Mike,
I guess this line
+ mypkg=${DISTNAME}-${ARCH}-`printf "%03d\n" $$count`.tgz; \
shoud be
+ mypkg=${DISTNAME}-${ARCH}-`printf "%03d" $$count`.tgz; \
without the new line.
It looks fine to me.
The only issue I see is that the user may expect that this new target
also builds the packages, if they don't exist. Nothing that the
documentation can't fix though.
Any other thought?
--
Gerardo Santana
|
|
From: Mike E. <mi...@er...> - 2008-04-21 18:53:41
|
Below is a diff to bsd.binpatch.mk that adds a "combo" target.
It iterates through the binpatch packages <= ${PATCH} untarring
them to a temporary location. Then creates an "upto${PATCH}" tarball.
Thoughts?
-ME
--- bsd.binpatch.mk Mon Mar 31 01:40:25 2008
+++ bsd.binpatch.mk Mon Mar 31 01:51:57 2008
@@ -257,6 +257,26 @@ package: build
@echo "|"
@echo "+-------------------------"
+${PACKAGEDIR}/${DISTNAME}-${ARCH}-upto${PATCH}.tgz: ${PACKAGEDIR}/${FULLPKGNAME}.tgz
+ @echo "===> Building combination package for ${PATCH}"
+ @rm -Rf ${.CURDIR}/.combo_pkg
+ @mkdir -p ${.CURDIR}/.combo_pkg
+ @count=0;\
+ while [ $$count -lt ${PATCH} ]; do \
+ count=`expr $$count + 1`;\
+ mypkg=${DISTNAME}-${ARCH}-`printf "%03d\n" $$count`.tgz; \
+ if [ -f ${PACKAGEDIR}/$$mypkg ]; then \
+ echo "======> Extracting $$mypkg"; \
+ tar -C ${.CURDIR}/.combo_pkg/ -xzphf ${PACKAGEDIR}/$$mypkg; \
+ fi; \
+ done
+ @echo "======> Creating ${DISTNAME}-${ARCH}-upto${PATCH}.tgz"
+ @tar -C ${WRKINST} -czpf ${PACKAGEDIR}/${DISTNAME}-${ARCH}-upto${PATCH}.tgz \
+ `(cd ${.CURDIR}/.combo_pkg && find . -type f)`
+ @rm -Rf ${.CURDIR}/.combo_pkg
+
+combo: ${PACKAGEDIR}/${DISTNAME}-${ARCH}-upto${PATCH}.tgz
+
# Installs the binary patch
install:
tar xzpf ${PACKAGEDIR}/${FULLPKGNAME}.tgz -C /
|
|
From: Mike E. <mi...@er...> - 2007-02-20 22:30:56
|
Mike Erdely wrote: > After the meeting it will be available on the MD BUG website: > http://mdbug.org/ We've changed our name to CapBUG (Capital Area BSD Users Group). The slides are on http://mdbug.org/wp-content/uploads/2007/02/binpatch.html or http://mdbug.org/wp-content/uploads/2007/02/binpatch.pdf -ME |
|
From:
<ger...@gm...> - 2007-01-20 14:40:13
|
2007/1/17, Antoine Jacoutot <aja...@lp...>: > On Wed, 17 Jan 2007, Gerardo Santana G=F3mez Garrido wrote: > > By the way, I started to work on XF4 support and have some questions > > I'd like to share with everyone in another message. Has someone else > > tried it? > > Wouldn't it be better to concentrace on xenocara support as it is the > future. Well except if XF4 support is very easy to implement, of course ;= ) Certainly. I'll check xenocara. --=20 Gerardo Santana |
|
From: Mike E. <mi...@er...> - 2007-01-18 03:23:37
|
Ingo Schwarze wrote: > Hi Mike, Hey, Ingo, >> Was wondering if I could get some feedback from you guys. > Imho, that presentation looks very useful! Appreciate it. > Still, just in case you are interested in some very minor > nitpicking: I am, thanks. > - On slide 3, > a remark "not yet officially supported in OpenBSD 4.0" > behind option 3, "use binpatch" > might help to avoid confusion. Added. > - On slide 4, > an additional remark > "Choose this option if you only need to patch one or two > boxes and aim for quickness and simplicity." > might be helpful - otherwise, people might wonder whether > errata are useful at all. I added this, but don't see how people would consider errata not useful. = The=20 usefulness of the publication of problems and fixes shouldn't depend on t= he=20 number of boxes you have to manage. Or am I misunderstanding you? > - On slide 5, line 1, after "for patching" > consider adding "more than a handful of servers" Changed to "This seems to be the most recommended method for patching a m= ore=20 than a small number of servers." > - On silde 5, line 4, > "use cdXY.iso", not "user cdXY.iso" Thanks. > - On slide 6, line 5, > "It doesn't hurt to apply patches already applied." > is dangerous. It *can* hurt applying them out of order. > With kernel patches, this is obvious, with userland patches, > order is *usually*, but by no means *necessarily* irrelevant. > Not sure how to patch this in the slides - you certainly > do not want to discuss all the details. I changed it to "Tarballs can be copied and applied to many servers. If y= ou=20 can=92t remember whether you installed a binpatch already, it doesn=92t h= urt to=20 re-apply it while applying newer binpatches." Better? > Yours, > Ingo -ME |
|
From: Mike E. <mi...@er...> - 2007-01-18 02:56:31
|
Gerardo Santana G=F3mez Garrido wrote: > I see your point. >=20 > Our difference arises probably from my belief that /var/db/binpatch is > a convenience too. >=20 > But even if I were the first patchtools enthusiast and supporter, I'd > look back to the ports subsystem. I don't see a target in bsd.port.mk > that handles /var/db/pkg directly; it's the pkgtools that handle > /var/db/pkg. Even before "make install" ran pkg_add in ports, /var/db/pkg was created = using=20 bsd.port.mk. I guess it doesn't matter. If it's not imported into CVS for bsd.binpatc= h.mk,=20 I'll just patch my local copy. -ME |
|
From:
<ger...@gm...> - 2007-01-18 01:16:02
|
2007/1/17, Mike Erdely <mi...@er...>: > Gerardo Santana G=F3mez Garrido wrote: > > 2007/1/16, Mike Erdely <mi...@er...>: > >> I think the goal should be to keep binpatch simple. > > Agreed, totally. > > > > the patch_* tools would be a pair of convenient scripts, nothing more, > > that handle patch information as mentioned before. > > If that's the case, creation of the /var/db/binpatch files should not dep= end on > things available just for convenience, IMO. > > > We can package those scripts in a binpatch package as you suggest, but > > it will not prevent anybody to just untar them. > > And still I think that a patch_add script should handle /var/db/binpat= ch. > > What you're suggesting, though is that using a script and using tar will = present > different results. > > -ME I see your point. Our difference arises probably from my belief that /var/db/binpatch is a convenience too. But even if I were the first patchtools enthusiast and supporter, I'd look back to the ports subsystem. I don't see a target in bsd.port.mk that handles /var/db/pkg directly; it's the pkgtools that handle /var/db/pkg. --=20 Gerardo Santana |
|
From: Ingo S. <sch...@us...> - 2007-01-17 23:18:42
|
Hi Mike,
> Was wondering if I could get some feedback from you guys.
Imho, that presentation looks very useful!
Still, just in case you are interested in some very minor
nitpicking:
- On slide 3,
a remark "not yet officially supported in OpenBSD 4.0"
behind option 3, "use binpatch"
might help to avoid confusion.
- On slide 4,
an additional remark
"Choose this option if you only need to patch one or two
boxes and aim for quickness and simplicity."
might be helpful - otherwise, people might wonder whether
errata are useful at all.
- On slide 5, line 1, after "for patching"
consider adding "more than a handful of servers"
- On silde 5, line 4,
"use cdXY.iso", not "user cdXY.iso"
- On slide 6, line 5,
"It doesn't hurt to apply patches already applied."
is dangerous. It *can* hurt applying them out of order.
With kernel patches, this is obvious, with userland patches,
order is *usually*, but by no means *necessarily* irrelevant.
Not sure how to patch this in the slides - you certainly
do not want to discuss all the details.
- Regarding slide 16,
currently none... ;-)
Yours,
Ingo
|
|
From: Mike E. <mi...@er...> - 2007-01-17 22:46:28
|
Tobias Weisserth wrote: > On Wednesday, 17. January 2007 16:13, Gerardo Santana G=F3mez Garrido w= rote: >> 2007/1/16, Mike Erdely <mi...@er...>: >>> Was wondering if I could get some feedback from you guys. >> Impressive. I have already shared it with some co-workers. > Indeed. Looking sharp! In fact, what's inside the slides is basically w= hat=20 > I've been thinking of putting inside one or more manpages as it provide= s a=20 > good structure and overview. Perfect. Thanks for the feedback. Exactly the reaction I was looking for. -ME |
|
From: Mike E. <mi...@er...> - 2007-01-17 22:43:04
|
Gerardo Santana G=F3mez Garrido wrote: > 2007/1/16, Mike Erdely <mi...@er...>: >> I think the goal should be to keep binpatch simple. > Agreed, totally. >=20 > the patch_* tools would be a pair of convenient scripts, nothing more, > that handle patch information as mentioned before. If that's the case, creation of the /var/db/binpatch files should not dep= end on=20 things available just for convenience, IMO. > We can package those scripts in a binpatch package as you suggest, but > it will not prevent anybody to just untar them. > And still I think that a patch_add script should handle /var/db/binpat= ch. What you're suggesting, though is that using a script and using tar will = present=20 different results. -ME |
|
From: Mike E. <mi...@er...> - 2007-01-17 22:40:46
|
Gerardo Santana G=F3mez Garrido wrote: > Impressive. I have already shared it with some co-workers. > Let me know where it will be stored, to link to it. After the meeting it will be available on the MD BUG website: http://mdbu= g.org/ -ME |
|
From: z0mbix <zo...@zo...> - 2007-01-17 17:50:54
|
Here's what I've knocked up so far if you want to test it out: #!/bin/sh # # This is just a wrapper script that installs binpatch patches and logs the # date and time and a list of what files were installed. See the binpatch # website for more information on binary patching your OpenBSD system: # # http://openbsdbinpatch.sourceforge.net/ # # Author: z0mbix (zombie | at | zombix | dot | org) # Date: 19/01/06 # # Version: 0.5 - Added support for downloading binpatches and gzsig verific= ation # RELEASE=3D`uname -r` ARCH=3D`machine` DATE=3D`date '+%b %d %Y %T'` PATCHNO=3D$1 PATCHDBDIR=3D/var/db/binpatch DBFILE=3D${PATCHDBDIR}/install.log PATCHFILE=3Dbinpatch-$RELEASE-$ARCH-$PATCHNO.tgz SIGNKEY=3D~/.ssh/id_rsa.pub # Set to NO if not required # Check for one argument: if [ $# !=3D 1 ]; then echo "usage: patch_add 001" exit 1 fi # Try to get from BINPATCH_PATH if it doesn't exist in cwd: if [ ! -f $PATCHFILE ]; then # Use standard ftp in non-verbose mode and save in cwd: ftp -VEa $BINPATCH_PATH/$PATCHFILE fi # Try to install from cwd: if [ -f $PATCHFILE ]; then # Check if the user wants to check gzsig: if [ "${SIGNKEY}" !=3D "NO" ]; then # Check gzsig and exit if not verified: if ! gzsig verify -q ${SIGNKEY} $PATCHFILE; then echo "$PATCHFILE NOT verified with key ${SIGNKEY}. Exiting!" exit 1 else echo "$PATCHFILE verified with key ${SIGNKEY}" fi fi # Create db directory if it does not exist: if [ ! -d ${PATCHDBDIR}/$RELEASE/$PATCHNO ]; then mkdir -p ${PATCHDBDIR}/$RELEASE/$PATCHNO # Create file list for this binpatch: tar tzf $PATCHFILE > ${PATCHDBDIR}/$RELEASE/$PATCHNO/FILES # Check if binpatch includes kernel updates: if grep "^./bsd$" ${PATCHDBDIR}/$RELEASE/$PATCHNO/FILES > /dev/null; then echo "Kernel Update!" echo " Backing up /bsd to /bsd.old" fi if grep "^./bsd.mp$" ${PATCHDBDIR}/$RELEASE/$PATCHNO/FILES > /dev/null; then cp /bsd.mp /bsd.mp.old fi # Actually unpack the binpatch tarball in /: tar xzpvf "$PATCHFILE" -C / # Update install file with new patch details: echo "$RELEASE-$ARCH-$PATCHNO installed: ${DATE}" | tee -a ${DBFILE} # Cleanup binpatch file: rm $PATCHFILE else echo "Directory ${PATCHDBDIR}/$RELEASE/$PATCHNO already exi= sts!" echo "If you are re-installing this patch, remove this directory" echo "and re-run patch_add $PATCHNO" fi else echo "Could not find: $PATCHFILE" fi I'll tidy this up some more tomorrow, but atleast a simple implementation so far. Just set BINPATCH_PATH in your shell. Cheers z0mbix On 17/01/07, Gerardo Santana G=F3mez Garrido <ger...@gm...> wr= ote: > 2007/1/16, Mike Erdely <mi...@er...>: > > Mike Erdely wrote: > > > Gerardo Santana G=F3mez Garrido wrote: > > >> If we make a difference between a build server (binpatch framework) > > >> and patch tools (patch_*) I think the later should handle > > >> /var/db/binpatch. > > > > > > Unless you want to keep it simple and have the binpatch "tools" be op= tional. If > > > you have all of the components in the tarball, it doesn't matter whet= her you use > > > patch_add or tar, the result should be the same. > > > > No comments about this? I think the goal should be to keep binpatch si= mple. As > > an example, if someone were to write a front-end to PF, you'd still wan= t to be > > able to "vi /etc/pf.conf" and have the same functionality, right? > > Agreed, totally. > > the patch_* tools would be a pair of convenient scripts, nothing more, > that handle patch information as mentioned before. > > We can package those scripts in a binpatch package as you suggest, but > it will not prevent anybody to just untar them. > > And still I think that a patch_add script should handle /var/db/binpatch. > > What I would like to see next is z0mbix's scripts making use of your > idea of optional mirrors for downloading binpatches, as well as > verifying signatures. > > -- > Gerardo Santana > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Openbsdbinpatch-misc mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbsdbinpatch-misc > |
|
From: Antoine J. <aja...@lp...> - 2007-01-17 17:02:01
|
On Wed, 17 Jan 2007, Gerardo Santana G=F3mez Garrido wrote: > By the way, I started to work on XF4 support and have some questions > I'd like to share with everyone in another message. Has someone else > tried it? Wouldn't it be better to concentrace on xenocara support as it is the=20 future. Well except if XF4 support is very easy to implement, of course ;= ) --=20 Antoine |
|
From: Tobias W. <tob...@gm...> - 2007-01-17 15:36:42
|
Hi everybody, On Wednesday, 17. January 2007 16:13, Gerardo Santana G=F3mez Garrido wrote: > > Was wondering if I could get some feedback from you guys. > > Impressive. I have already shared it with some co-workers. Indeed. Looking sharp! In fact, what's inside the slides is basically what= =20 I've been thinking of putting inside one or more manpages as it provides a= =20 good structure and overview. > By the way, I started to work on XF4 support and have some questions > I'd like to share with everyone in another message. Has someone else > tried it? Not yet, I'm still pretty booked until next week, then I'll setup the sparc= =20 with 4.0 and the HP risc with as well. I'm thinking about buying a cheap=20 Apple G4 on Ebay for some other OpenBSD related project, if I can get it fo= r=20 a cheap price. Then I'll gladly test whatever you've got in store for me ;-) regards, Tobias |
|
From:
<ger...@gm...> - 2007-01-17 15:13:41
|
2007/1/16, Mike Erdely <mi...@er...>: > I was planning to give a preso on binpatch for our first Maryland BSD Users > group on Jan 31. (http://mdbug.org/) > > Was wondering if I could get some feedback from you guys. Impressive. I have already shared it with some co-workers. Let me know where it will be stored, to link to it. By the way, I started to work on XF4 support and have some questions I'd like to share with everyone in another message. Has someone else tried it? -- Gerardo Santana |
|
From:
<ger...@gm...> - 2007-01-17 14:55:56
|
2007/1/16, Mike Erdely <mi...@er...>: > Mike Erdely wrote: > > Gerardo Santana G=F3mez Garrido wrote: > >> If we make a difference between a build server (binpatch framework) > >> and patch tools (patch_*) I think the later should handle > >> /var/db/binpatch. > > > > Unless you want to keep it simple and have the binpatch "tools" be opti= onal. If > > you have all of the components in the tarball, it doesn't matter whethe= r you use > > patch_add or tar, the result should be the same. > > No comments about this? I think the goal should be to keep binpatch simp= le. As > an example, if someone were to write a front-end to PF, you'd still want = to be > able to "vi /etc/pf.conf" and have the same functionality, right? Agreed, totally. the patch_* tools would be a pair of convenient scripts, nothing more, that handle patch information as mentioned before. We can package those scripts in a binpatch package as you suggest, but it will not prevent anybody to just untar them. And still I think that a patch_add script should handle /var/db/binpatch. What I would like to see next is z0mbix's scripts making use of your idea of optional mirrors for downloading binpatches, as well as verifying signatures. --=20 Gerardo Santana |
|
From: Mike E. <mi...@er...> - 2007-01-17 01:48:08
|
I was planning to give a preso on binpatch for our first Maryland BSD Users group on Jan 31. (http://mdbug.org/) Was wondering if I could get some feedback from you guys. -ME |
|
From: z0mbix <zo...@zo...> - 2007-01-16 23:06:30
|
On 16/01/07, Mike Erdely <mi...@er...> wrote: > Mike Erdely wrote: > > Gerardo Santana G=F3mez Garrido wrote: > >> If we make a difference between a build server (binpatch framework) > >> and patch tools (patch_*) I think the later should handle > >> /var/db/binpatch. > > > > Unless you want to keep it simple and have the binpatch "tools" be opti= onal. If > > you have all of the components in the tarball, it doesn't matter whethe= r you use > > patch_add or tar, the result should be the same. > > No comments about this? I think the goal should be to keep binpatch simp= le. As > an example, if someone were to write a front-end to PF, you'd still want = to be > able to "vi /etc/pf.conf" and have the same functionality, right? > > -ME The patch_* tools could be included in the binpatch distribution as they're not exactly very big but I agree that we should keep binpatch simple and let the user use whatever tools they wish to install the tarballs. Some old-school admins will always use tar no matter what tools are provided. |
|
From: Mike E. <mi...@er...> - 2007-01-16 23:05:53
|
z0mbix wrote: > I'll see what I can add to patch_add to enable this functionality. > What other functionality do you think we need? md5sum/sha1 checksums? A recent patch to bsd.binpatch.mk includes the ability to use gzsig to sign packages. Maybe you should include the ability to verify that signature. > Cheers z0mbix -ME |
|
From: z0mbix <zo...@zo...> - 2007-01-16 22:58:42
|
On 12/01/07, Gerardo Santana G=F3mez Garrido <ger...@gm...> wr= ote: > 2007/1/11, Mike Erdely <mi...@er...>: > > Gerardo Santana G=F3mez Garrido wrote: > > > Indeed. I like them. I have read them many times and haven't found > > > anything I'd like to change so far. > > > > > > They can be enriched though if someone else has another idea/script. > > > > > > Otherwise, I'd like to have your permission z0mbix to add them to the > > > binpatch distribution. > > > > What might be a good idea is creating two ports or a binpatch port with= a > > binpatch-build multi-package. The binpatch port installed scripts like= z0mbix's > > with a /usr/local/share/examples/binpatch/binpatch.conf (@sample'd to > > /etc/binpatch.conf) with a mirror list (which I, for instance, would mo= dify to > > point to my local mirror of binpatches or it could point to, like, > > http://erdelynet.com/downloads/4.0/). > > Aha, and/or BINPATCH_PATH, similar to PKG_PATH. > All these are great ideas, I now have around 6 OpenBSD servers at work and 2 at home. It's getting a bit of a pain to manually pull these packages down for each update. This would save me quite a bit of time already and I don't have a particularly large OpenBSD network. I'll see what I can add to patch_add to enable this functionality. What other functionality do you think we need? md5sum/sha1 checksums? Cheers z0mbix |
|
From: Mike E. <mi...@er...> - 2007-01-16 21:35:42
|
Mike Erdely wrote: > Gerardo Santana G=F3mez Garrido wrote: >> If we make a difference between a build server (binpatch framework) >> and patch tools (patch_*) I think the later should handle >> /var/db/binpatch. >=20 > Unless you want to keep it simple and have the binpatch "tools" be opti= onal. If=20 > you have all of the components in the tarball, it doesn't matter whethe= r you use=20 > patch_add or tar, the result should be the same. No comments about this? I think the goal should be to keep binpatch simp= le. As=20 an example, if someone were to write a front-end to PF, you'd still want = to be=20 able to "vi /etc/pf.conf" and have the same functionality, right? -ME |
|
From: Antoine J. <aja...@lp...> - 2007-01-13 12:25:00
|
On Fri, 12 Jan 2007, Gerardo Santana G=F3mez Garrido wrote: > If we make a difference between a build server (binpatch framework) > and patch tools (patch_*) I think the later should handle > /var/db/binpatch. I agree. --=20 Antoine |
