Re: Segfault for CVS over SSH
B. T. writes: > > The client is Red Hat 6.0 and the Server is 6.1. Bash is the shell on > both systems. You can get straces of the cvs 1.10.0 server process on > the at the following location: > > Committing one file -- this works > http://mail.indiansprings.org/people/benjy/one_file_works > > Committing multiple files -- this dies with signal 11 > http://mail.indiansprings.org/people/benjy/multiple_files_segfault Unfortunately, the server forks and it's the *child* that's dying with signal 11 -- you traced the parent. If you're handy with a debugger, you can set the CVS_SERVER_SLEEP environment variable to the number of seconds the child should sleep before starting to run -- that will give you time to attach a debugger to it and catch the crash. A traceback from the debugger will be much more useful than straces. -Larry Jones How many presents do you think I'd forfeit for just one clean smack upside Susie's head? -- Calvin
More info on cvs edit
where can I find docs on this, there doesn't seem to be anything about it in the man pages or other docs.
Re: CVS 1.10.8 Windows Binary
Kevin, Kevin Greiner wrote: > The only strange part is that the previous build I had, 1.10, was 897,563 > bytes while this build is only 569,344. Maybe the difference between Debug > and Release builds? The cvs.exe distributed with WinCvs is also a cvs-1.10.8 version + some patches (like the proxy support), is also compiled with VisualC++ 6.0 SP 3 and is only 479,232 bytes. Strange, isn't it ? Regards, alex.
RE: Unix to Dos filtering
> -Original Message- > From: Tony Hoyle [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 06, 2000 9:33 AM > Subject: Re: Unix to Dos filtering [snip] > Much of the same caveats exist re: sharing over samba as > sharing over NFS, only worse (samba has this habit of attempting > to convert text files itself unless you stop it...) Wrong. I distinctly remember the samba guys (Allison & Tridgell) saying they didn't want samba to attempt any such conversion. From the samba docs: !== !== CRLF-LF-Conversions.txt for Samba release 2.0.5a 22 Jul 1999 !== We get many requests for CRLF/LF format conversion handling by samba. The problem is that there is no clean way to determine which files should / could be converted and which MUST not be. Since Unix and DOS/Windows uses alike will use .txt to represent a file containing ASCII text we can not reliably use the file extension. The same applies to the .doc extension. Samba operates around the premise that we should leave all files unchanged. By not implementing CRLF/LF conversions we can not be guilty of damaging anyone's files. When someone comes along with a sound implementation that guarantees file integrity we will jump at the opportunity to implement this feature. Until such time there is no prospect for action on this topic. !== !== end CRLF-LF-Conversions.txt !== You may want to re-think your understanding of samba, et al. Steve
Segfault for CVS over SSH
I am having the same problem which Sean Chittenden described in December http://x31.deja.com/getdoc.xp?AN=561768387&search=thread&CONTEXT=952413 094.1035468817&HIT_CONTEXT=952413039.1034944541&hitnum=2 Basically, using either ssh or kerberos rsh as CVS_RSH and then setting the appropriate CVSROOT=:ext:[EMAIL PROTECTED]:/cvsroot results in a Signal 11 when committing multiple files or whole directories. Committing a single file works fine. I experienced the error under all of the following configurations: Client Server Redhat 6.0's 1.10.5 Redhat 6.1's 1.10.6 Cyclic's 1.10.8 Cyclic's 1.10.8 <- both self compiled Cyclic's 1.10.0 rpm Cyclic's 1.10.0 rpm The client is Red Hat 6.0 and the Server is 6.1. Bash is the shell on both systems. You can get straces of the cvs 1.10.0 server process on the at the following location: Committing one file -- this works http://mail.indiansprings.org/people/benjy/one_file_works Committing multiple files -- this dies with signal 11 http://mail.indiansprings.org/people/benjy/multiple_files_segfault This seems to pop up occasionally in various newsgroups and bug systems (debian). Thank you for any insight you can provide! -benjy
Re: remote shared repositories
I don't think there's a solution to this 'cos eventually, something'll have to merge the archive files. For example: user-1 copies repo into repo-copy-1 user-2 copies repo into repo-copy-2 user-1 commits file onto repo-copy-1 user-2 commits file onto repo-copy-2 What happens when it's time to put the changes back into the original repo? I suppose if everyone's working off of branches, the archive merges won't be too bad. My guess is that only the branch numbers would have to be changed within the merged archive. I don't see why this wouldn't be doable, but I don't know if anyone's actually done this. Noel [EMAIL PROTECTED] on 03/06/2000 06:35:12 PM To: [EMAIL PROTECTED] cc: Subject: Re: remote shared repositories With client/server, I need to be able to talk to the remote repository. In my case, I might be on the net only late evenings (one phone line), and still want to 'commit early, commit often'. I am very strongly of the 'commit your changes frequently' family (at least once per syntax error free make, or once at the end of each work day, or once per major code re-organization); with CVS, this means (or at least, seems to me to mean) commit onto branches until the code is stable enough for others to see. I can't do that if I can't talk to the remote. I can run a local repository, but then I have two repositories to synchronize. Michael Noel L Yap wrote: > > Why not just use client/server CVS? > > Noel > > [EMAIL PROTECTED] on 03/06/2000 03:52:17 PM > > To: [EMAIL PROTECTED] > cc: (bcc: Noel L Yap) > Subject: remote shared repositories > > How can I share a repository across two different machines? > > Lets say that two machines will talk to each other only once a > night. Lets say that each machine has developers, and they want > to work on a shared CVS project. > > How/can/is it possible for them to share/synchronize their CVS > repositories? What limits do they get regarding who can be > working on a given branch/how are different branches/trunks > shared? > > Michael
RE: scripting CVS login
Art Solano wrote: > Can you script cvs login? I have read through the documentation and it > only seems to be interactive. > [smc] It is AFAIK, always interactive, like telnet. That doesn't mean it can't be scripted, what you might want is "expect", a program made specifically for dealing with (scripting) interactive programs. URL is http://expect.nist.gov/ The other thing, I believe "cvs login" is necessary only once, and the necessary information is retained in the ".cvspass" Subsequent logins are not required. So if your script is always to be run as the same user against the same repository, just log that user in once and forget about "cvs login"... Hope it helps. --steve
unsubscribe
Too many messages on this list :-(
Re: scripting CVS login
"Art Solano" <[EMAIL PROTECTED]> writes: > Can you script cvs login? I have read through the documentation and it > only seems to be interactive. There used to be a CVS_PASSWORD environment variable, but it was deprecated due to security concerns (see login.c). I can't think of any way to make it non-interactive now, except to just put the correct entry in ~/.cvspass and hope. -Karl
RE: Password or Set-up Problem?
> From: Larry Jones [mailto:[EMAIL PROTECTED]] Hi, > > [big snip] > > ADD: cvspserver proto=tcp, wait.max=0.40, > user.group=root.(null) builtin=0 > > server=/home/phil/cvs-1.10.8/src/cvs > > > > [big snip] > > > > Does that look OK? > > That looks fine, but you need to then run a CVS command and see what > happens. I took the advantage of a kernal upgrade to wipe the disk and start again, but guess what same problem... I can run most of the CVS commands, but when it comes to logging in from either the local machine or a remote box, I get the 'Connection reset by Peer error'. Cheers Phil
Re: Password or Set-up Problem?
Phil Shrimpton writes: > > I took the advantage of a kernal upgrade to wipe the disk and start again, > but guess what same problem... > > I can run most of the CVS commands, but when it comes to logging in from > either the local machine or a remote box, I get the 'Connection reset by > Peer error'. That's why you need to do the login while you have inetd running with -d on the server machine. When inetd is running in debug mode, it will emit lots of messages about exactly what it's doing when it receives the connection request for the CVS server -- hopefully that will tell us what's going wrong. -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin
Re: Automating CVS login for scripts
Art Solano writes: > > Can I peform a CVS login unattended without user interaction so I may > include CVS commands within my scripts? No, but you only have to login once, not every time (CVS saves the login information in ~/.cvspass), so you just need to login once as the user the script will be running as, then you can run the script as much as you want without having to worry about loging in. -Larry Jones Years from now when I'm successful and happy, ...and he's in prison... I hope I'm not too mature to gloat. -- Calvin
CVS 1.10.8 Windows Binary
I just got down compiling (Release build only) CVS 1.10.8 for Windows using Microsoft Visual Studio 6.0. Since some of the interim releases on the SourceGear download site have Windows binaries and some do not, I'll gladly forward my binary build to whomever wants it. The only strange part is that the previous build I had, 1.10, was 897,563 bytes while this build is only 569,344. Maybe the difference between Debug and Release builds? Let me know... -- Kevin Greiner Product Integration Engineer MapQuest.com, Inc. 717-285-8493
Re: checking in Image files
[EMAIL PROTECTED] writes:
>
> I am trying to check in image files to CVS, but they seem to get
> corrupted once I check in.
> I used the following commands:
>
> cvs add -kb figure.jpg
> cvs add -kb figure.gif
> cvs commit
>
> Can you please let me know if you see anything missing?
That looks correct. What version(s) of CVS are you running and on what
platform{s}? Are you using a local repository or client/server? What
makes you think the files in the repository are corrupted?
-Larry Jones
You should see me when I lose in real life! -- Calvin
Re: RCS style locking
Any idea how to make this system work with the WinCVS client and a UNIX repository? On Mon, 6 Mar 2000, David Thornley wrote: > Ben Leibig wrote: > > > > Well, I've tried as hard as I can, but I can't convice our developers that > > RCS locking is not necessary when using CVS. They're all old school, and > > they don't trust CVS's ability to merge, nor do they claim they need it. > > If they don't need it, then they're never trying to work on the same > file > at the same time, so they don't need locks. But I digress > > > THey do however want the whole remote repository ability, which means I'm > > in a hard spot. I need to figure out how to provide locking (every file > > gets locked everytime it is checked out and unlocked everytime it is > > commited.) Using CVS, or to provide a remote repository system using RCS. > > Nope, not in CVS. If these are hard requirements, you'll have to try > to find something else that's going to work. > > The "cvs watch" facility could be used. If you have "cvs watch on", > then files are checked out into the developer's directory in read-only > mode. The developers will then use "cvs edit" to unlock the files. > You may want to look into Noel Yap's "cvs edit -c" patch. > > This is, in my experience, the most restrictive form of locking that > makes sense. It is easy to subvert, but, then, so are more restrictive > locks. > > > Actually the developers even want to have a copy of the checked out source > > all running in one directory on one of the UNIX servers. When they check > > out they want the file's permissions in that directory to change so they > > can access it untill the check it back in, then they want it to go to read > > only for everyone. > > The proposed procedure will provide multiple copies, one for each > developer, and each directory will have only the appropriate files > read/write. This isn't what the developers are asking for, but it's > the best CVS is going to do. > > It also strikes me as a lousy way to work, since you're working in > an environment where you can't control changes. If a guy who's working > on a header file goofs and goes to lunch, you can't compile in that > directory until after his lunch. In the CVS environment, you get > only checked-in changes, and only when you ask for them. Not quick > hacks that don't quite work yet whenever. > > I'm not sure how possable any of this is. It seems > > like what we really need is a client/server version of RCS. > > You need more than that, I'd think. I really doubt that there is > a system that'll do exactly what you've stated without a lot of > customization. > > -- > David H. Thornley Software Engineer > at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556 > at home: (612)-623-0552 or [EMAIL PROTECTED] or > http://www.visi.com/~thornley/david/ >
RE: RCS style locking
The problem with this is that many of our uses are using WinCVS. That's the primary reason for moving from RCS to CVS (the ability to use a client/server based repository) so I'm afraid that won't work. On Mon, 6 Mar 2000, Mahoney, Jesse N wrote: > >Ben, > > I would not think you would want to have everything locked > upon checkout (way too restrictive when dealing with entire > directory trees). > What you could do is use the CVSREAD environment variable and > set it to 'read-only'. This will cause all files to have > read-only permissions upon checkouts and updates. You then could > write a script which combines the "cvs admin -l" and "cvs edit" > commands such that users could lock and get edit privileges > all at once (similar to RCS). Obviously, then no one could > lock and edit if a lock already exists, and no one could check > in if a lock already exists by someone else. > Upon checkin of files, edit privileges get lost and files go > back to read-only. > > I think this probably the closest you'll come to mimicing RCS, > Hope it helps > > -Original Message- > From: Tobias Weingartner [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 06, 2000 11:51 AM > To: Ben Leibig > Cc: [EMAIL PROTECTED] > Subject: Re: RCS style locking > > > On Monday, March 6, Ben Leibig wrote: > > > > Well, I've tried as hard as I can, but I can't convice our developers that > > RCS locking is not necessary when using CVS. They're all old school, and > > they don't trust CVS's ability to merge, nor do they claim they need it. > > They'd rather step on each others toes, I understand. Well, for "RCS" style > locking, have a look at 'cvs admin -l'. However, I doubt it does exactly > what they/you want/need... > > > > THey do however want the whole remote repository ability, which means I'm > > in a hard spot. I need to figure out how to provide locking (every file > > gets locked everytime it is checked out and unlocked everytime it is > > commited.) Using CVS, or to provide a remote repository system using RCS. > > Ouch, good luck... > > > Actually the developers even want to have a copy of the checked out source > > all running in one directory on one of the UNIX servers. When they check > > out they want the file's permissions in that directory to change so they > > can access it untill the check it back in, then they want it to go to read > > only for everyone. > > Ahh, of course, since it's checked out just like the developers version, > things will be locked, thereby getting no work done. Yes, I understand, > they want an *exception*... > > > > I'm not sure how possable any of this is. It seems > > like what we really need is a client/server version of RCS. Anyone have > > any advice, if nothing else can someone tell me how to do the locking. I > > know this has come up before, but I don't really understand how the RCS > > lock works, nor if it still works with CVS 1.10.8. > > I'm sorry, I don't know how to help you. Maybe PCVS, Aegis, SourceSafe, > or whatever other thing out there, will have what these developers think > they need... > > --Toby. > >
Re: Password or Set-up Problem?
Phil Shrimpton writes: > > OK, I ran "inet -d" and the results were... > > [big snip] > ADD: cvspserver proto=tcp, wait.max=0.40, user.group=root.(null) builtin=0 > server=/home/phil/cvs-1.10.8/src/cvs > > [big snip] > > Does that look OK? That looks fine, but you need to then run a CVS command and see what happens. -Larry Jones I keep forgetting that rules are only for little nice people. -- Calvin
cvsignore
Hi, im trying to use the $CVSROOT/CVSROOT/cvsignore file to make the cvs update command to ignore some files . (*.class) . unfortunatly it doesnt work, and the cvs update still writes information about all my *.class files. any idea why is that ? Moshe.
scripting CVS login
Can you script cvs login? I have read through the documentation and it only seems to be interactive.
CVS login through scripts?
Is the cvs login command always interactive? Can I somehow script it?
Re: Feature wanted: checkin time tagging
[EMAIL PROTECTED] on 03/06/2000 11:06:11 PM >I like the windows find tool that combines find, xargs, and grep in >one box. Yes, it's limited, but it often works faster than trying to >get the correct command typed in. And, it's more of what I think of. Oh no, declaration of religious war ;) CVS was born out of Unix, it'll stay that way. If you want higher level tools, nothing is stopping anyone from building them (don't compilers still call the assembler to create object files? aren't automatics just a layer on top of sticks (ie manuals)?). >I don't want to be told "Here's a list of commands you can use to get >this done". I want one command that does it. > >I don't want to have to remember a list of steps, and worry about "did >I make a mistake anywhere?". You can create scripts to achieve this. >Yes, there is the ability to do this in CVS. As you said, >> Cripes, use "cvs diff" to give you a diff of your changes, checkout >> a new sandbox (or revert your old one), add the branch, apply the >> diffs (using patch), commit. >So I need to use diff, a temp file, a new checkout, and patch. Why not >have it all in one command? You can, through a script. In fact, I don't think you even need a temp file. >Right now, I can (usually, not always, and no I don't remember why it >failed when it did) do: >To decide that I want to create a branch at checkin, with modified >files: >cvs tag base-branch >cvs tag -b branch >cvs update -r branch >cvs commit > >Why do I need 4 commands to do one operation? 'cos if everyone got all the conglomerate commands they wanted, CVS would be bloated and unwieldy while not providing any more functionality it already had. >Just now I made some changes to files, and realized that what I had >should have been merged onto the trunk before I made these changes. >Nothing else had been modified on the trunk since my branching. So, in >theory, I could say > >cvs move-branch removeLocks onto-parent as-branch base-newrevision // >THIS DOESN'T EXIST -- modify repository only >cvs rtag -r base-newrevision -b newrevision // modify repository -- >make new branch >cvs update -r newrevision// switch my newly modified files onto >newrevsion >cvs commit > >That's another 4 commands, one of which doesn't exist, unless I do a >lot of diff, revert, patch, etc. > >Why? 'cos you made a mistake to begin with. >Why not put all that into CVS? The "flying fish" approach to the >repository is really the (my opinion) proper way to use it. Otherwise, >you can only commit a change when it is ready for prime time, or else >you will hose every other developer. If you get into the habit of creating and working on task branches, this wouldn't happen. Noel
Re: removing the need for "cvs add file" to contact the server....
[EMAIL PROTECTED] on 03/06/2000 05:59:45 PM >[ On Monday, March 6, 2000 at 15:17:02 (-0500), Noel L Yap wrote: ] >> Subject: Re: removing the need for "cvs add file" to contact the server >> >> Although "cvs watch dir" won't actually watch "dir", it does do >> something with (ie operate on) the directory (namely, keep track of it for >> future use). There is absolutely no way "cvs watch dir" can work on future >> elements of "dir" if it didn't do this, no matter what the implementation of it >> is. > >You're so confused over the concepts vs. what the implementation does in >order to make things happen that you're blind to the fact that "cvs >watch" cannot operate on directories, no matter how much you might want >it to! There is no ,v file for a directory -- there are only ,v files >for (surprise) *files*! CVS is a time machine -- it remembers state in >many ways. The trick with "cvs watch dir" being only one extremely >minor side-show miracle it performs. No, Greg, you're confusing the term "operate on" with "version". Just 'cos CVS *operates on* directories doesn't mean it *versions* them. The is very true of "cvs watch". "cvs watch" *operates on* directories though it doesn't *version* them. Now that (I hope) we have definitions all straightened out, it should be clear that "cvs watch" must operate on directories in order for CVS to watch future files. Again, this is very similar to setgid on directories -- new files don't have setgid set on them, but new subdirectories do. Noel
Re: removing the need for "cvs add file" to contact the server....
[EMAIL PROTECTED] on 03/06/2000 04:34:02 PM >> Also, I just thought of a couple of cases that might need discussion: >> Where, if anyplace, will CVS admin subdirectories get created? >> >> echo "dir" >.cvsignore >> mkdir dir >> cd dir >> touch file >> cvs add file > >"dir/CVS" will be created and populated and "file" will be marked as >"added", just as the user requests. > >> and, a little different: >> echo "dir0" >.cvsignore >> mkdir -p dir0/dir1 >> cd dir0/dir1 >> touch file >> cvs add file > >Once again CVS admin directories will be created where necessary and the >file specified will be marked as "added", just as the user requests >(i.e. dir/CVS *and* dir1/CVS will be created). I guess I should've been more ambiguous with the above commands ;) What if the final lines were "cvs add" instead of "cvs add file"? Noel
RE: RCS style locking
I'm referring to all versions of CVS. The documentation specifies that "cvs admin" is not supported and, therefore, may go away in the future. The "cvs admin" command is not currently being phased out. There's been some talk (but only talk) of removing "cvs admin -l". One thing with "cvs admin" is that it's a direct line to the RCS commands. RCS is an implementation issue, therefore, "cvs admin" as it is now may not exist in the future if the RCS implementation is abandoned (though this looks doubtful right now). Another thing with "cvs admin" is that, since it is a direct line to the RCS commands, it does a lot. IMHO, it'd be wise to replace what really is needed in "cvs admin" (I personally don't see a need for "cvs admin -l") with more mnemonic command names. Noel [EMAIL PROTECTED] on 03/06/2000 05:32:39 PM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: RCS style locking Noel, Is the admin command being phased out?? When you say 'not supported', which release(s) are you referring to? Jesse -Original Message- From: Noel L Yap [mailto:[EMAIL PROTECTED]] Sent: Monday, March 06, 2000 4:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: RCS style locking A word of caution. "cvs admin -l" is not supported. Future versions of CVS may not have it or may change its behaviour (I think I've made a change in my copy of CVS such that it does not "cvs unedit"; this change may already be distributed as part of the "cvs edit -c" patch; if not, it'll be distributed as part of the "cvs multiple edit per person" patch). Noel [EMAIL PROTECTED] on 03/06/2000 02:50:45 PM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Noel L Yap) Subject: RE: RCS style locking Ben, I would not think you would want to have everything locked upon checkout (way too restrictive when dealing with entire directory trees). What you could do is use the CVSREAD environment variable and set it to 'read-only'. This will cause all files to have read-only permissions upon checkouts and updates. You then could write a script which combines the "cvs admin -l" and "cvs edit" commands such that users could lock and get edit privileges all at once (similar to RCS). Obviously, then no one could lock and edit if a lock already exists, and no one could check in if a lock already exists by someone else. Upon checkin of files, edit privileges get lost and files go back to read-only. I think this probably the closest you'll come to mimicing RCS, Hope it helps -Original Message- From: Tobias Weingartner [mailto:[EMAIL PROTECTED]] Sent: Monday, March 06, 2000 11:51 AM To: Ben Leibig Cc: [EMAIL PROTECTED] Subject: Re: RCS style locking On Monday, March 6, Ben Leibig wrote: > > Well, I've tried as hard as I can, but I can't convice our developers that > RCS locking is not necessary when using CVS. They're all old school, and > they don't trust CVS's ability to merge, nor do they claim they need it. They'd rather step on each others toes, I understand. Well, for "RCS" style locking, have a look at 'cvs admin -l'. However, I doubt it does exactly what they/you want/need... > THey do however want the whole remote repository ability, which means I'm > in a hard spot. I need to figure out how to provide locking (every file > gets locked everytime it is checked out and unlocked everytime it is > commited.) Using CVS, or to provide a remote repository system using RCS. Ouch, good luck... > Actually the developers even want to have a copy of the checked out source > all running in one directory on one of the UNIX servers. When they check > out they want the file's permissions in that directory to change so they > can access it untill the check it back in, then they want it to go to read > only for everyone. Ahh, of course, since it's checked out just like the developers version, things will be locked, thereby getting no work done. Yes, I understand, they want an *exception*... > I'm not sure how possable any of this is. It seems > like what we really need is a client/server version of RCS. Anyone have > any advice, if nothing else can someone tell me how to do the locking. I > know this has come up before, but I don't really understand how the RCS > lock works, nor if it still works with CVS 1.10.8. I'm sorry, I don't know how to help you. Maybe PCVS, Aegis, SourceSafe, or whatever other thing out there, will have what these developers think they need... --Toby.
Re: CVS edit marker stays in repository
I haven't seen this problem although I am using cvs-1.10.8. You might want to download this version. Noel [EMAIL PROTECTED] on 03/07/2000 04:10:25 AM To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: CVS edit marker stays in repository Hello CVS users, using CVS 1.10 with the "cvs watch on" feature for getting the checked out files as read only, I must see that sometimes the edit entry/marker in the repository stays after a "cvs unedit" or "CVS commit". As a result "cvs editors" list still the file as being edited. Currently, as workarround I could perform an additional "cvs edit" & "cvs unedit" sequence to remove the wrong setting. Does anybody know a solution for this bug?
CVS edit marker stays in repository
Hello CVS users, using CVS 1.10 with the "cvs watch on" feature for getting the checked out files as read only, I must see that sometimes the edit entry/marker in the repository stays after a "cvs unedit" or "CVS commit". As a result "cvs editors" list still the file as being edited. Currently, as workarround I could perform an additional "cvs edit" & "cvs unedit" sequence to remove the wrong setting. Does anybody know a solution for this bug?
