Does cvsync let ancient patches escape from the attic?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Does cvsync let ancient patches escape from the attic?

Brett Mahar-2
Hi,

Yesterday I updated to current and rebuilt the ports I use. All went
well except building mupdf, which stalled at "file to patch:":

# cd textproc/mupdf/                                                                    
# make install
===>  Checking files for mupdf-0.9
`/usr/ports/distfiles/mupdf-0.9-source.tar.gz' is up to date.
>> (SHA256) mupdf-0.9-source.tar.gz: OK
.....
===>  Extracting for mupdf-0.9
===>  Patching for mupdf-0.9
File to patch:



Looking in /usr/ports/textproc/mupdf/patches/
$ ls
CVS                          
patch-apps_unix_ximage_c
patch-debian_mupdf_pc
patch-Makerules
patch-debian_mupdf_desktop

Somehow patch-apps_unix_ximage_c has gotten in there, even though
(according to
http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
) it was moved to the attic over 2 years ago.

To use cvsync I do:

$ su - cvsyncuser
$ cvsync -4 -c /home/cvsyncuser/cvsync-config

and then to update my source to build from:

# cd /usr/ports (and src & xenocara)
# cvs -d /usr/cvsync up -Pd

The only thing I can think that I have done out-of-the-ordinary is
# chown -R cvsyncuser /usr/cvsync repository when I stopped cvsync'ing as root (but it seems unlikely chown would cause a file to move directories).

Has anyone seen this happen before? Have I done something to mess
this up?

Brett.

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

patrick keshishian
On Thu, Feb 9, 2012 at 4:43 PM, Brett <[hidden email]> wrote:

> Hi,
>
> Yesterday I updated to current and rebuilt the ports I use. All went
> well except building mupdf, which stalled at "file to patch:":
>
> # cd textproc/mupdf/
> # make install
> ===>  Checking files for mupdf-0.9
> `/usr/ports/distfiles/mupdf-0.9-source.tar.gz' is up to date.
>>> (SHA256) mupdf-0.9-source.tar.gz: OK
> .....
> ===>  Extracting for mupdf-0.9
> ===>  Patching for mupdf-0.9
> File to patch:
>
>
>
> Looking in /usr/ports/textproc/mupdf/patches/
> $ ls
> CVS
> patch-apps_unix_ximage_c
> patch-debian_mupdf_pc
> patch-Makerules
> patch-debian_mupdf_desktop
>
> Somehow patch-apps_unix_ximage_c has gotten in there, even though
> (according to
> http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
> ) it was moved to the attic over 2 years ago.

$ cvs status patch-apps_unix_ximage_c

see if there is sticky tag there. If so, then do:

$ cvs up -dPA

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Brett Mahar-2
> > Somehow patch-apps_unix_ximage_c has gotten in there, even though
> > (according to
> > http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
> > ) it was moved to the attic over 2 years ago.
>
> $ cvs status patch-apps_unix_ximage_c
>
> see if there is sticky tag there. If so, then do:
>
> $ cvs up -dPA
>
> --patrick
>

# cvs -d/usr/cvsync status /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c  
===================================================================
File: patch-apps_unix_ximage_c  Status: Up-to-date

   Working revision:    1.1     Fri Feb 10 00:17:20 2012
   Repository revision: 1.1     /usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not return to the attic.

The hostname in my cvsync config file is cvsync.allbsd.org if that would make any difference.

Brett.

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

patrick keshishian
On Thu, Feb 9, 2012 at 6:26 PM, Brett <[hidden email]> wrote:
>> >
>> > Somehow patch-apps_unix_ximage_c has gotten in there, even though
>> > (according to
>> >
http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/

>> > ) it was moved to the attic over 2 years ago.
>>
>> $ cvs status patch-apps_unix_ximage_c
>>
>> see if there is sticky tag there. If so, then do:
>>
>> $ cvs up -dPA
>>
>> --patrick
>>
>
> # cvs -d/usr/cvsync status
/usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c
> ===================================================================
> File: patch-apps_unix_ximage_c  Status: Up-to-date
>
>   Working revision:    1.1     Fri Feb 10 00:17:20 2012
>   Repository revision: 1.1    
/usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v
>   Sticky Tag:          (none)
>   Sticky Date:         (none)
>   Sticky Options:      (none)
>
> I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not
return to the attic.
>
> The hostname in my cvsync config file is cvsync.allbsd.org if that would
make any difference.

I would try another cvsync host and see if the issue gets resolved.

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Constantine A. Murenin
In reply to this post by Brett Mahar-2
On 09/02/2012, Brett <[hidden email]> wrote:

>> > Somehow patch-apps_unix_ximage_c has gotten in there, even though
>> > (according to
>> > http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
>> > ) it was moved to the attic over 2 years ago.
>>
>> $ cvs status patch-apps_unix_ximage_c
>>
>> see if there is sticky tag there. If so, then do:
>>
>> $ cvs up -dPA
>>
>> --patrick
>>
>
> # cvs -d/usr/cvsync status
> /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c
> ===================================================================
> File: patch-apps_unix_ximage_c  Status: Up-to-date
>
>    Working revision:    1.1     Fri Feb 10 00:17:20 2012
>    Repository revision: 1.1
> /usr/cvsync/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
>
> I ran the $ cvs up -dPA command anyway but patch-apps_unix_ximage_c did not
> return to the attic.
>
> The hostname in my cvsync config file is cvsync.allbsd.org if that would
> make any difference.
>
> Brett.

Looks like cvsync.allbsd.org is in trouble -- patch-apps_unix_ximage_c
is present both outside Attic at rev1.1, and within Attic at rev1.2.

http://cvsweb.allbsd.org/cvsweb.cgi/ports/textproc/mupdf/patches/?cvsroot=openbsd
http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/

Perhaps Hiroki can clarify how this could have happened.

C.

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Brett Mahar-2
On Fri, 10 Feb 2012 01:26:22 -0500
"Constantine A. Murenin" <[hidden email]> wrote:

> On 09/02/2012, Brett <[hidden email]> wrote:
> >> > Somehow patch-apps_unix_ximage_c has gotten in there, even though
> >> > (according to
> >> > http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
> >> > ) it was moved to the attic over 2 years ago.
> >>
> >> $ cvs status patch-apps_unix_ximage_c
> >>
> >> see if there is sticky tag there. If so, then do:
> >>
> >> $ cvs up -dPA
> >>
> >> --patrick
> >>

> >
> > The hostname in my cvsync config file is cvsync.allbsd.org if that would
> > make any difference.
> >
> > Brett.
>
> Looks like cvsync.allbsd.org is in trouble -- patch-apps_unix_ximage_c
> is present both outside Attic at rev1.1, and within Attic at rev1.2.
>
> http://cvsweb.allbsd.org/cvsweb.cgi/ports/textproc/mupdf/patches/?cvsroot=openbsd
> http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/
>
> Perhaps Hiroki can clarify how this could have happened.
>
> C.

I cvsync'd again, trying with anoncvs.comstyle.com this time:

        config {
            hostname anoncvs.comstyle.com
            compress
            collection {
                name openbsd release rcs
                prefix /usr/cvsync/
                scanfile /home/cvsyncuser/cvsync-scanfile
                umask 002
            }
        }

but the patch came back:

# cvs -d /usr/cvsync up -dPA            
cvs update: Updating .
# ls /usr/ports/textproc/mupdf/patches/
CVS                        patch-apps_unix_ximage_c   patch-debian_mupdf_pc
patch-Makerules            patch-debian_mupdf_desktop
# rm /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c                
# ls /usr/ports/textproc/mupdf/patches/                          
CVS                        patch-debian_mupdf_desktop
patch-Makerules            patch-debian_mupdf_pc
# cvs -d /usr/cvsync up -dPA                                    
cvs update: Updating .
cvs update: warning: patch-apps_unix_ximage_c was lost
U patch-apps_unix_ximage_c
# ls /usr/ports/textproc/mupdf/patches/
CVS                        patch-apps_unix_ximage_c   patch-debian_mupdf_pc
patch-Makerules            patch-debian_mupdf_desktop

Looks like Hiroki and Allbsd are in the clear!

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Brad Smith-14
On 10/02/12 2:11 AM, Brett wrote:

> On Fri, 10 Feb 2012 01:26:22 -0500
> "Constantine A. Murenin"<[hidden email]>  wrote:
>
>> On 09/02/2012, Brett<[hidden email]>  wrote:
>>>>> Somehow patch-apps_unix_ximage_c has gotten in there, even though
>>>>> (according to
>>>>> http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
>>>>> ) it was moved to the attic over 2 years ago.
>>>>
>>>> $ cvs status patch-apps_unix_ximage_c
>>>>
>>>> see if there is sticky tag there. If so, then do:
>>>>
>>>> $ cvs up -dPA
>>>>
>>>> --patrick
>>>>
>
>>>
>>> The hostname in my cvsync config file is cvsync.allbsd.org if that would
>>> make any difference.
>>>
>>> Brett.
>>
>> Looks like cvsync.allbsd.org is in trouble -- patch-apps_unix_ximage_c
>> is present both outside Attic at rev1.1, and within Attic at rev1.2.
>>
>> http://cvsweb.allbsd.org/cvsweb.cgi/ports/textproc/mupdf/patches/?cvsroot=openbsd
>> http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/
>>
>> Perhaps Hiroki can clarify how this could have happened.
>>
>> C.
>
> I cvsync'd again, trying with anoncvs.comstyle.com this time:
>
>          config {
>              hostname anoncvs.comstyle.com
>              compress
>              collection {
>                  name openbsd release rcs
>                  prefix /usr/cvsync/
>                  scanfile /home/cvsyncuser/cvsync-scanfile
>                  umask 002
>              }
>          }
>
> but the patch came back:
>
> # cvs -d /usr/cvsync up -dPA
> cvs update: Updating .
> # ls /usr/ports/textproc/mupdf/patches/
> CVS                        patch-apps_unix_ximage_c   patch-debian_mupdf_pc
> patch-Makerules            patch-debian_mupdf_desktop
> # rm /usr/ports/textproc/mupdf/patches/patch-apps_unix_ximage_c
> # ls /usr/ports/textproc/mupdf/patches/
> CVS                        patch-debian_mupdf_desktop
> patch-Makerules            patch-debian_mupdf_pc
> # cvs -d /usr/cvsync up -dPA
> cvs update: Updating .
> cvs update: warning: patch-apps_unix_ximage_c was lost
> U patch-apps_unix_ximage_c
> # ls /usr/ports/textproc/mupdf/patches/
> CVS                        patch-apps_unix_ximage_c   patch-debian_mupdf_pc
> patch-Makerules            patch-debian_mupdf_desktop
>
> Looks like Hiroki and Allbsd are in the clear!

What if you delete the patches dir and do an update again from the
textproc/mupdf dir?

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Brett Mahar-2
On Fri, 10 Feb 2012 09:49:11 -0500
Brad Smith <[hidden email]> wrote:

> >
> >> On 09/02/2012, Brett<[hidden email]>  wrote:
> >>>>> Somehow patch-apps_unix_ximage_c has gotten in there, even though
> >>>>> (according to
> >>>>> http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
> >>>>> ) it was moved to the attic over 2 years ago.
> >>>>

>
> What if you delete the patches dir and do an update again from the
> textproc/mupdf dir?
>

I tried this with both

# cvs -d /usr/cvsync up -Pd
and
# cvs -d /usr/cvsync up -APd

but patch-apps_unix_ximage_c came back with the rest of the patches folder both times.

Am going to delete the cvsync scanfile, run an update and see if that changes anything.

Brett.

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Brett Mahar-2
In reply to this post by Brad Smith-14
> >> On 09/02/2012, Brett<[hidden email]>  wrote:
> >>>>> Somehow patch-apps_unix_ximage_c has gotten in there, even though
> >>>>> (according to
> >>>>> http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/Attic/
> >>>>> ) it was moved to the attic over 2 years ago.
> >>>>


> What if you delete the patches dir and do an update again from the
> textproc/mupdf dir?
>

After removing the scanfile entry from the config file, I tried anoncvs.comstyle.com again and it worked properly:

# cvs -d /usr/cvsync up -Pd
cvs update: Updating .
cvs update: Updating files
cvs update: Updating patches
cvs update: patches/patch-apps_unix_ximage_c is no longer in the repository
cvs update: Updating pkg

Then I ran cvsync again, using allbsd server (still without scanfile), and the patch came back:

# cd /usr/ports/textproc/mupdf/
# cvs -d /usr/cvsync up -Pd
cvs update: Updating .
cvs update: Updating files
cvs update: Updating patches
U patches/patch-apps_unix_ximage_c
cvs update: Updating pkg

So it seems like something is wrong with that directory on allbsd, but also that something did not update properly when I used the comstyle repository earlier on. Whether that was due to using a cvsync scanfile first time around I do not know.

Brett.

Reply | Threaded
Open this post in threaded view
|

Re: Does cvsync let ancient patches escape from the attic?

Hiroki Sato-3
Hi,

Brett <[hidden email]> wrote
  in <[hidden email]>:

br> So it seems like something is wrong with that directory on allbsd, but
br> also that something did not update properly when I used the comstyle
br> repository earlier on. Whether that was due to using a cvsync scanfile
br> first time around I do not know.

 I cleaned up the repository on allbsd.org and resync from the
 upstream.  The files in question were left for some reason.  Probably
 it was the cause.

 If anyone noticed this (or similar) problem persisted, please let me
 know.

-- Hiroki

[demime 1.01d removed an attachment of type application/pgp-signature]