Thread: [Madwifi-devel] ath_hal directory (Re: [Madwifi-cvs] revision 1726 committed)
Status: Beta
Brought to you by:
otaku
From: Pavel R. <pr...@gn...> - 2006-09-27 01:17:51
|
Hello, Matthew! On Fri, 2006-09-22 at 18:01 +0200, Matthew W.S.Bell wrote: > Project : madwifi > Revision : 1726 > Author : mentor (Matthew W. S. Bell) > Date : 2006-09-22 18:01:25 +0200 (Fri, 22 Sep 2006) > > Log Message : > Move ah_osdep and hal compilation stuff to ath_hal/. > Split out ah_osdep files to fix dependency issues. > Fix OS register access macros. > I will be somewhat amazed if the history gets preserved across files copies. [skip] > Modified: trunk/ath/Makefile.kernel > =================================================================== > --- trunk/ath/Makefile.kernel 2006-09-22 15:47:45 UTC (rev 1725) > +++ trunk/ath/Makefile.kernel 2006-09-22 16:01:25 UTC (rev 1726) > @@ -12,43 +12,6 @@ > WLAN= $(srctree)/$(src)/../net80211 > COMPAT= $(srctree)/$(src)/../include > > - > -# Determine endianess. Note that it's not indicated for some CPUs at > -# all, so this value is only valid for certain processors. > -ifeq ($(filter-out arm%,$(ARCH)),) > -ENDIAN = le > -endif Could you please test changes to the files you are changing? TARGET is still referenced in ath/Makefile.kernel, and it's actually needed to calculate AH_NEED_DESC_SWAP used in if_ath.c. You restored ath_hal, which I removed in particular to simplify kernel integration. I knew that TARGET calculation would have to be duplicated. What am I supposed to do now? Revert your changes or deal with the consequences of your changes? I'm going to commit minimal changes that restore kernel integration (commit 1735 is just the beginning, since things are still broken), but I'm still undecided whether keeping a separate ath_hal directory is worth the trouble. I'll have to deal with code duplication somehow. Unfortunately, I need working kernel integration right now. But generally, I think the approach should be such that whoever makes the changes also deals with the consequences. It shouldn't be so that the easy part is done by one person, whereas difficult decisions are shifted to someone else. I'd like to know the reasons for keeping the ath_hal directory separate, so I can weigh it against the inconvenience of having TARGET calculation in two places or refactoring it in some way. > > -INCS = -include $(COMPAT)/compat.h -I$(COMPAT) -I$(HAL) -I$(HAL)/linux \ > +INCS = -include $(COMPAT)/compat.h -I$(COMPAT) -I$(HAL) \ > -I$(WLAN) -I$(src)/.. -I$(src) That's another broken piece. -I$(HAL)/linux is removed, but how would ah_osdep.h be found now? -- Regards, Pavel Roskin |
From: Pavel R. <pr...@gn...> - 2006-09-27 03:24:09
|
On Wed, 2006-09-27 at 03:42 +0100, Matthew "mentor" Bell wrote: > I have every intention of cleaning my own mess up, and, indeed, do > believe it should be me to do so. > The reason that I moved the madwifi specific parts of the hal module > to ath_hal was that I thought that the HAL should be kept separate for > conceptual and import reasons. I would suggest that there is either an > ath_hal directory which contain the vendor/HAL in a subdirectory, or > that the madwifi-specific hal code be kept in a subdirectory of ath/. OK, kernel integration seems to be fixed as of revision 1741. The biggest remaining issue with the build system is calculation of TARGET in three different files: ath/Makefile, ath_hal/Makefile and scripts/get_arch_target.sh. I think the simplest approach would be to move it to a separate file Makefile.target and leave ARCH calculation in scripts/get_arch_target.sh (which would become scripts/get_arch.sh) -- Regards, Pavel Roskin |
From: Paolo <oo...@us...> - 2006-09-27 15:50:58
|
On Tue, Sep 26, 2006 at 11:24:01PM -0400, Pavel Roskin wrote: > > OK, kernel integration seems to be fixed as of revision 1741. nope 4 me: CC [M] drivers/net/wireless/madwifi/ath_hal/ah_os.o drivers/net/wireless/madwifi/ath_hal/ah_os.c:38:20: opt_ah.h: No such file or directory make[7]: *** [drivers/net/wireless/madwifi/ath_hal/ah_os.o] Error 1 -- paolo |
From: Michael R. <ma...@no...> - 2006-10-02 17:31:29
|
Hi. Paolo wrote: >> help. Quick Google search for "subversion debian sarge" gives for > Debian Woody here, sorry. Nothing speaks against installing Subversion on Debian Woody, by the way. Chances are that there are no ready-made packages available, but you still can compile it from source. Which is, as Pavel said, something you should really consider if you want to be of help. Otherwise it will be very hard for us to determine if problems reported by you are caused by your "unsupported" way of keeping your source tree up to date or by a real problem in our repository. Bye, Mike |
From: Paolo <oo...@us...> - 2006-10-02 18:48:41
|
On Mon, Oct 02, 2006 at 07:31:24PM +0200, Michael Renzmann wrote: > > Otherwise it will be very hard for us to determine if problems reported > by you are caused by your "unsupported" way of keeping your source tree > up to date or by a real problem in our repository. I don't want to waste anybody's time. I assumed CS are reliable incr diff against revisions, they turned out not so because TRAC is broken here. CS must be consistent with src changes, if not there's a bug. I reported the issue to TRAC's ticket system, though I'm afraid it's hardly predictable if/when they'll take care of it, as I saw very many tickets wrt CS. Since it's a pretty handy way to update src, and now I know the tricks, I'll double^2 check before reporting issues. thx -- paolo |
From: Pavel R. <pr...@gn...> - 2006-09-27 17:30:42
|
Hello! On Wed, 2006-09-27 at 17:50 +0200, Paolo wrote: > On Tue, Sep 26, 2006 at 11:24:01PM -0400, Pavel Roskin wrote: > > > > OK, kernel integration seems to be fixed as of revision 1741. > > nope 4 me: > > CC [M] drivers/net/wireless/madwifi/ath_hal/ah_os.o > drivers/net/wireless/madwifi/ath_hal/ah_os.c:38:20: opt_ah.h: No such file or directory > make[7]: *** [drivers/net/wireless/madwifi/ath_hal/ah_os.o] Error 1 I cannot reproduce it with the current kernel from the wireless branch, either for in-tree or out-of-tree compilation. What's the kernel version you are using? Just in case, what's the version of GNU make? I guess this patch might help you: Index: ath_hal/Makefile.kernel =================================================================== --- ath_hal/Makefile.kernel (revision 1743) +++ ath_hal/Makefile.kernel (working copy) @@ -14,7 +14,7 @@ COMPAT= $(srctree)/$(src)/../include INCS = -include $(COMPAT)/compat.h -I$(COMPAT) -I$(HAL) \ - -I$(WLAN) -I$(src)/.. -I$(src) + -I$(WLAN) -I$(srctree)/$(src)/.. -I$(srctree)/$(src) EXTRA_CFLAGS += $(INCS) -DOPT_AH_H=\"$(HAL)/public/$(TARGET).opt_ah.h\" But I'd like to be able to reproduce your problem, so extra details will be appreciated. -- Regards, Pavel Roskin |
From: Pavel R. <pr...@gn...> - 2006-09-28 01:57:00
|
Hello! On Wed, 2006-09-27 at 22:42 +0200, Paolo wrote: > On Wed, Sep 27, 2006 at 01:30:33PM -0400, Pavel Roskin wrote: > > > > > > > > OK, kernel integration seems to be fixed as of revision 1741. > > > > > > nope 4 me: > > > > > > CC [M] drivers/net/wireless/madwifi/ath_hal/ah_os.o > > > drivers/net/wireless/madwifi/ath_hal/ah_os.c:38:20: opt_ah.h: No such file or directory > > > I cannot reproduce it with the current kernel from the wireless branch, > > either for in-tree or out-of-tree compilation. What's the kernel > > version you are using? Just in case, what's the version of GNU make? > > it's on Debian Sarge: > gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) > GNU Make 3.80 OK, I'll try to put one sentence on a line. Hopefully it would work better. What's the kernel version you are trying to compile? Is it a kernel shipped with Debian or some other kernel? Does the kernel include any other patches? Is the kernel compiled in the source tree or outside it? I tried and could not reproduce this problem with Linux 2.6.12 without any patches, compiled in or outside the source tree. > no, no difference -BTW I was at r1741. > Instead, the problem is in ath_hal/ah_os.c: > > - #include "opt_ah.h" > + #include "ath_hal/opt_ah.h" > > then it compiles fine. I wouldn't say that the problem is in ath_hal/ah_os.c. I think the problem is with your setup or with the madwifi makefiles. Just because some change works to you, it doesn't mean it's a good idea. > BTW: r1742.diff did not apply cleanly, seems the svn that builds the CS is > broken somehow: > > Index: trunk/ath_hal/ah_target.inc > =================================================================== > --- (revision ) > +++ trunk/ath_hal/ah_target.inc (revision 1742) > @@ -1,0 +1,36 @@ "svn diff -r 1741:1742" gives : --- scripts/get_arch.sh (revision 0) +++ scripts/get_arch.sh (revision 1742) @@ -0,0 +1,45 @@ Something must be broken on the system generating the patches for mailing. It would be great if you actually used Subversion, because I'm not sure you are dealing with the same codebase as others. -- Regards, Pavel Roskin |
From: Paolo <oo...@us...> - 2006-09-28 08:45:00
|
On Wed, Sep 27, 2006 at 09:56:57PM -0400, Pavel Roskin wrote: > > it's on Debian Sarge: > > gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) > > GNU Make 3.80 > > OK, I'll try to put one sentence on a line. > Hopefully it would work better. > > What's the kernel version you are trying to compile? hmf, sorry, forgot: 2.6.17.13 - I'm topped there till the slmodem driver will compile on 2.6.18.*. > Is it a kernel shipped with Debian or some other kernel? > Does the kernel include any other patches? stock+suspend2 patches; ieee80211,ipw2200,ipw3945 from latest on sf.net. > Is the kernel compiled in the source tree or outside it? in-tree; BTW that install breaks the patch in Kconfig done by add_radiotap from ipw3945. > > - #include "opt_ah.h" > > + #include "ath_hal/opt_ah.h" ... > Just because some change works to you, it doesn't mean it's a good idea. sure - but WFM is still top prio for me ;) > > --- (revision ) > > +++ trunk/ath_hal/ah_target.inc (revision 1742) > > @@ -1,0 +1,36 @@ > > "svn diff -r 1741:1742" gives > : > --- scripts/get_arch.sh (revision 0) > +++ scripts/get_arch.sh (revision 1742) > @@ -0,0 +1,45 @@ > > Something must be broken on the system generating the patches for > mailing. so it seems CS are *not* generated by "svn diff -r *:*": above is missing '-- path (revision 0)' > It would be great if you actually used Subversion, because I'm not sure > you are dealing with the same codebase as others. too hassles either to upgrade or try to get svn work here - already spent too much time on that. If CS turns out to be really broken/unreliable, I'll stick with snaphots, though I'd like to save BW. ATM let's consider it a test on the CS facility as well. thanks -- paolo |
From: Paolo <oo...@us...> - 2006-09-28 09:42:39
|
On Wed, Sep 27, 2006 at 09:56:57PM -0400, Pavel Roskin wrote: ... > Just because some change works to you, it doesn't mean it's a good idea. ok, just quick update ... r1743, k2.6.17.13 seems to work, at least it assoc to WPA-PSK AP. -- paolo |
From: Pavel R. <pr...@gn...> - 2006-09-28 03:29:21
|
Hello! Sorry, a few more questions. Does revision 1747 fix the problem? If it doesn't, please run "make V=1" and post the last command before the compile error. Also please check that opt_ah.h is located in the same directory as ah_os.c. Otherwise, the problem is in the install script. -- Regards, Pavel Roskin |
From: Michael R. <ma...@no...> - 2006-09-28 04:51:39
|
Hi. Paolo wrote: > BTW: r1742.diff did not apply cleanly, seems the svn that builds the CS is > broken somehow: As you stated before, you're not using Subversion to get the changesets, you're using Trac for that. So, if there is an issue, it is neither in Subversion nor in the Subversion repository, it's a bug of Trac. Trac's browser tool is made available on madwifi.org to allow users and developers to review changesets and browse the source. Especially the colorized diff view usually is more convenient than looking at plain text diffs. However, although the browser offers other formats, it is not meant to be used as download tool for changesets. If you need to be on the bleeding edge of the driver development, then use Subversion. If your system lacks Subversion, then you should either upgrade your distribution (Woody is stone-aged), check the usual resources for backported packages or compile Subversion manually. If you don't want to or can't do that and still decide to download the changeset diffs from Trac's source browser, then at least don't complain to us that the diffs are broken. Otherwise I will switch off the related functionality in Trac. Don't get me wrong, but we really don't have the resources to take care of bogus issues that are most probably caused by a bug in Trac. Bye, Mike |
From: Paolo <oo...@us...> - 2006-09-30 14:55:01
|
On Wed, Sep 27, 2006 at 11:29:14PM -0400, Pavel Roskin wrote: > Does revision 1747 fix the problem? no - actually I have to correct my prev posting, as I put "ath/opt_ah.h" not "ath_hal/opt_ah.h" in ah_os.c. Sorry for the mess. Anyway that fixed the compile. As of r1716, when file are moved around, opt_sh is in ath/ and there it=20 stays up to r1747.=20 So in r1747 I have #include "opt_ah.h" in ath_hal/ah_os.c but opt_ah.h is in ath/, and compile fails.=20 But now to make it compile I need to set #include "../ath/opt_ah.h". >=20 > If it doesn't, please run "make V=3D1" and post the last command before > the compile error. make KBUILD_MODULES=3D1 \ -f scripts/Makefile.build obj=3Ddrivers/net/wireless/madwifi make -f scripts/Makefile.build obj=3Ddrivers/net/wireless/madwifi/ath make -f scripts/Makefile.build obj=3Ddrivers/net/wireless/madwifi/ath_hal gcc -m32 -Wp,-MD,drivers/net/wireless/madwifi/ath_hal/.ah_os.o.d -nostdi= nc -isystem /usr/lib/gcc-lib/i486-linux/3.3.5/include -D__KERNEL__ -Iinclud= e -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno= -trigraphs -fno-strict-aliasing -fno-common -O2 -fomit-frame-pointer -pipe = -msoft-float -mpreferred-stack-boundary=3D2 -march=3Di686 -mcpu=3Dpentium4= -mregparm=3D3 -ffreestanding -Iinclude/asm-i386/mach-default -DATH_SUPER= G_FF=3D1 -DATH_SUPERG_DYNTURBO=3D1 -DATH_TURBO_SCAN=3D1 -DATH_SUPERG_XR=3D1= -DAH_BYTE_ORDER=3DAH_LITTLE_ENDIAN -include /mnt/mandrake/usr/src/linux-2.= 6.17/drivers/net/wireless/madwifi/ath_hal/../include/compat.h -I/mnt/mandra= ke/usr/src/linux-2.6.17/drivers/net/wireless/madwifi/ath_hal/../include -I/= mnt/mandrake/usr/src/linux-2.6.17/drivers/net/wireless/madwifi/ath_hal/../a= th_hal -I/mnt/mandrake/usr/src/linux-2.6.17/drivers/net/wireless/madwifi/at= h_hal/../hal -DOPT_AH_H=3D\"/mnt/mandrake/usr/src/linux-2.6.17/drivers/net/= wireless/madwifi/ath_hal/../hal/public/i386-elf.opt_ah.h\" -DMODULE -D"KBU= ILD_STR(s)=3D#s" -D"KBUILD_BASENAME=3DKBUILD_STR(ah_os)" -D"KBUILD_MODNAME= =3DKBUILD_STR(ath_hal)" -c -o drivers/net/wireless/madwifi/ath_hal/.tmp_ah_= os.o drivers/net/wireless/madwifi/ath_hal/ah_os.c drivers/net/wireless/madwifi/ath_hal/ah_os.c:38:20: opt_ah.h: No such fil= e or directory make[2]: *** [drivers/net/wireless/madwifi/ath_hal/ah_os.o] Error 1 >=20 > Also please check that opt_ah.h is located in the same directory as > ah_os.c. Otherwise, the problem is in the install script. hm, is the install.sh supposed to shuffle files among dirs: $ find -name opt_ah.h =2E/ath/opt_ah.h in modules/madwifi-ng-*/ thanks -- paolo |
From: Paolo <oo...@us...> - 2006-09-30 20:12:58
|
On Sat, Sep 30, 2006 at 04:54:47PM +0200, Paolo wrote: > > As of r1716, when file are moved around, opt_sh is in ath/ and there it ^^---: s/16/26/ -- paolo |
From: Michael R. <ma...@no...> - 2006-10-02 17:25:05
|
Hi. Paolo wrote: >> As you stated before, you're not using Subversion to get the changesets, >> you're using Trac for that. So, if there is an issue, it is neither in >> Subversion nor in the Subversion repository, it's a bug of Trac. > that's true iff such CS *.diff are made by TRAC, but not by the > download/format method (well, only one that makes sense for patch(1) here > is the diff anyway) since the problem lies in the wrong '@@ -1,0 ...' > header. From what I can tell, you're using the source browser to get the changesets in diff format. If that's correct, then Trac is responsible for the generation of these diffs as far as I know. > But that's not a bogus issue imo, It's bogus as far as MadWifi is concerned. It's no bug that has been introduced in one of the changes that have been committed by any of the MadWifi developers, but an issue that is caused by a bug in Trac. That's what I refered to here. > it's a bug that perhaps TRAC devel may want to hear of - I'll bug them. That surely is a good idea. However, be aware that madwifi.org is: a) not running the latest stable release (0.10 as of now) b) running a custom version of a previous stable release (0.9.4 with some self-made patches) It may well be that the Trac developers will refuse to act on your report due to these facts, or will ask you to do things you can not do (update to the latest stable release, for example, which would require you to have access to our server). However, the following information might help when reporting this bug: our custom modifications to Trac do not, to the best of my knowledge, concern any code that is involved in the creation of diffs. I can provide more details about the modifications, if needed, but I will be on vacation to the end of this week, so my response to such a request will certainly take a few days. Bye, Mike |
From: Paolo <oo...@us...> - 2006-10-02 18:56:04
|
On Mon, Oct 02, 2006 at 07:25:02PM +0200, Michael Renzmann wrote: > > That surely is a good idea. However, be aware that madwifi.org is: no problem wrt your points: if the issue is/was known, fine, they'll let me know if they care. If it's new bug, it'll hopely stay on their todo - again if they care. Eventually we'll likely know someday (if) it's been dealt with & fixed, or not. Then madwifi.org may consider to upgrade or not. In anycase I see it a no_lost-no_lost situation :) -- paolo |
From: Matthew \mentor\ B. <me...@ma...> - 2006-09-27 02:43:03
|
I have every intention of cleaning my own mess up, and, indeed, do believe it should be me to do so. The reason that I moved the madwifi specific parts of the hal module to ath_hal was that I thought that the HAL should be kept separate for conceptual and import reasons. I would suggest that there is either an ath_hal directory which contain the vendor/HAL in a subdirectory, or that the madwifi-specific hal code be kept in a subdirectory of ath/. shamefully, Matthew W. S. Bell Pavel Roskin wrote:non-madwifi/vendor code > Hello, Matthew! > > On Fri, 2006-09-22 at 18:01 +0200, Matthew W.S.Bell wrote: >> Project : madwifi >> Revision : 1726 >> Author : mentor (Matthew W. S. Bell) >> Date : 2006-09-22 18:01:25 +0200 (Fri, 22 Sep 2006) >> >> Log Message : >> Move ah_osdep and hal compilation stuff to ath_hal/. >> Split out ah_osdep files to fix dependency issues. >> Fix OS register access macros. >> I will be somewhat amazed if the history gets preserved across files copies. > [skip] >> Modified: trunk/ath/Makefile.kernel >> =================================================================== >> --- trunk/ath/Makefile.kernel 2006-09-22 15:47:45 UTC (rev 1725) >> +++ trunk/ath/Makefile.kernel 2006-09-22 16:01:25 UTC (rev 1726) >> @@ -12,43 +12,6 @@ >> WLAN= $(srctree)/$(src)/../net80211 >> COMPAT= $(srctree)/$(src)/../include >> >> - >> -# Determine endianess. Note that it's not indicated for some CPUs at >> -# all, so this value is only valid for certain processors. >> -ifeq ($(filter-out arm%,$(ARCH)),) >> -ENDIAN = le >> -endif > > Could you please test changes to the files you are changing? TARGET is > still referenced in ath/Makefile.kernel, and it's actually needed to > calculate AH_NEED_DESC_SWAP used in if_ath.c. > > You restored ath_hal, which I removed in particular to simplify kernel > integration. I knew that TARGET calculation would have to be > duplicated. What am I supposed to do now? Revert your changes or deal > with the consequences of your changes? > > I'm going to commit minimal changes that restore kernel integration > (commit 1735 is just the beginning, since things are still broken), but > I'm still undecided whether keeping a separate ath_hal directory is > worth the trouble. I'll have to deal with code duplication somehow. > Unfortunately, I need working kernel integration right now. > > But generally, I think the approach should be such that whoever makes > the changes also deals with the consequences. It shouldn't be so that > the easy part is done by one person, whereas difficult decisions are > shifted to someone else. > > I'd like to know the reasons for keeping the ath_hal directory separate, > so I can weigh it against the inconvenience of having TARGET calculation > in two places or refactoring it in some way. >> >> -INCS = -include $(COMPAT)/compat.h -I$(COMPAT) -I$(HAL) -I$(HAL)/linux \ >> +INCS = -include $(COMPAT)/compat.h -I$(COMPAT) -I$(HAL) \ >> -I$(WLAN) -I$(src)/.. -I$(src) > > That's another broken piece. -I$(HAL)/linux is removed, but how would > ah_osdep.h be found now? |
From: Pavel R. <pr...@gn...> - 2006-10-01 06:55:35
|
On Sat, 2006-09-30 at 22:12 +0200, Paolo wrote: > On Sat, Sep 30, 2006 at 04:54:47PM +0200, Paolo wrote: > > > > As of r1716, when file are moved around, opt_sh is in ath/ and there it > > ^^---: s/16/26/ You must have missed revision 1736: "Move opt_ah.h from ath to ath_hal, where it's more suitable" Seeing the corresponding e-mail in madwifi-cvs, I'm not surprised. The unified diff on http://madwifi.org/changeset/1736 is empty. Apparently trac cannot deal with file moving properly. I guess you'll need to start using Subversion if you want to be of any help. Quick Google search for "subversion debian sarge" gives for instance this: http://andrewbeacock.blogspot.com/2006/09/installing-subversion-132-using.html -- Regards, Pavel Roskin |
From: Paolo <oo...@us...> - 2006-09-27 20:43:19
|
On Wed, Sep 27, 2006 at 01:30:33PM -0400, Pavel Roskin wrote: > > > > > > OK, kernel integration seems to be fixed as of revision 1741. > > > > nope 4 me: > > > > CC [M] drivers/net/wireless/madwifi/ath_hal/ah_os.o > > drivers/net/wireless/madwifi/ath_hal/ah_os.c:38:20: opt_ah.h: No such file or directory > I cannot reproduce it with the current kernel from the wireless branch, > either for in-tree or out-of-tree compilation. What's the kernel > version you are using? Just in case, what's the version of GNU make? it's on Debian Sarge: gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) GNU Make 3.80 > > I guess this patch might help you: > > Index: ath_hal/Makefile.kernel > =================================================================== > --- ath_hal/Makefile.kernel (revision 1743) > +++ ath_hal/Makefile.kernel (working copy) no, no difference -BTW I was at r1741. Instead, the problem is in ath_hal/ah_os.c: - #include "opt_ah.h" + #include "ath_hal/opt_ah.h" then it compiles fine. Whether it'll work is another story - I'll try as soon as I have the chance to reboot the (remote) pc with new k. BTW: r1742.diff did not apply cleanly, seems the svn that builds the CS is broken somehow: Index: trunk/ath_hal/ah_target.inc =================================================================== --- (revision ) +++ trunk/ath_hal/ah_target.inc (revision 1742) @@ -1,0 +1,36 @@ ____^____ +# Determine HAL target based on the kernel architecture + should really be instead: Index: trunk/ath_hal/ah_target.inc =================================================================== --- (revision ) +++ trunk/ath_hal/ah_target.inc (revision 1742) @@ -0,0 +1,36 @@ ____^____ +# Determine HAL target based on the kernel architecture + while it'd help to avoid warnings if '---' line had filename as well and CS are not \r -terminated. thanks |
From: Paolo <oo...@us...> - 2006-09-28 08:44:50
|
On Thu, Sep 28, 2006 at 06:51:32AM +0200, Michael Renzmann wrote: > Paolo wrote: > >BTW: r1742.diff did not apply cleanly, seems the svn that builds the CS is > >broken somehow: > > As you stated before, you're not using Subversion to get the changesets, > you're using Trac for that. So, if there is an issue, it is neither in > Subversion nor in the Subversion repository, it's a bug of Trac. that's true iff such CS *.diff are made by TRAC, but not by the download/format method (well, only one that makes sense for patch(1) here is the diff anyway) since the problem lies in the wrong '@@ -1,0 ...' header. > Don't get me wrong, but we really don't have the resources to take care > of bogus issues that are most probably caused by a bug in Trac. no problem, thanks really for your support instead :) But that's not a bogus issue imo, it's a bug that perhaps TRAC devel may want to hear of - I'll bug them. -- paolo |
From: Paolo <oo...@us...> - 2006-10-01 08:43:58
|
On Sun, Oct 01, 2006 at 02:55:30AM -0400, Pavel Roskin wrote: > > You must have missed revision 1736: no, it's here ... > unified diff on http://madwifi.org/changeset/1736 is empty. Apparently ... indeed. > help. Quick Google search for "subversion debian sarge" gives for Debian Woody here, sorry. Ok, let's TRAC devel know CS feat is broken; I'll silently use CS.diff (CS.zip in case) or snapshots when really desperate. thanks -- paolo |