Re: Where have svt-av1 1.8.0-2 gone?
On Sat, 16 Mar 2024 09:39:33 +0900 Takashi Yano wrote: > On Fri, 15 Mar 2024 16:58:06 + > Jon Turney wrote: > > On 15/03/2024 13:31, Takashi Yano via Cygwin-apps wrote: > > > On Fri, 15 Mar 2024 13:14:49 + > > > Jon Turney wrote: > > >> On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: > > >>> I uploaded svt-av1 1.8.0-2 few hours ago, however > > >>> it does not appear on the mirror servers so far. > > >>> > > >>> Was anything wrong? > > >> > > >> Sorry, things will be a little slower than usual (uploads may take up to > > >> 4 hours to get processed) until I get around to fixing up things for > > >> some changes made on sourceware to provide better isolation. > > >> > > >> I see that this upload was declined because svt-av1 2.0.0 already exists. > > >> > > >> I guess you really want to upload it, as it provides a different set of > > >> shared libraries to 2.0.0. Please let me know. > > > > > > 1.8.0-2 is necessary for changing packaging. > > > > I see. I configured the necessary exception, sot his should be all > > uploaded now. > > > > > 1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1, > > > However, > > > 2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built. > > > So, I made > > > 1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in > > > libsvtav1dec0 > > > both obsolete libsvtav1 > > > for migration. > > > > Hmm... maybe your thinking here is not quite clear. > > > > You cannot assume that an installation is upgraded often enough that it > > receives every version of every package. > > > > (And in this case, where 1.8.0-2 appears in the repository after 2.0.0 > > does, it's not going to get automatically installed anywhere) > > > > So, as a principle, every version of a package must contain complete > > instructions for upgrading to it. > > > > > > In this particular case, that means the cygport should contain > > > > libsvtav1dec0_OBSOLETES=libsvtav1 > > > > for as long as the package produces libsvtav1dec0. > > > > > > (In fact, I think this all happens to work as desired because libsvtav1 > > is also obsoleted by the non-longer produced libsvtav1enc1, but I just > > point this out for completeness) > > What I did was: > 1.8.0-1: > libsvtav1_CONTENTS="usr/bin/*.dll" > > 1.8.0-2: > libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll" > libsvtav1enc1_OBSOLETES=libsvtav1 > libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" > libsvtav1dec0_OBSOLETES=libsvtav1 > > 2.0.0-1: > libsvtav1enc2_CONTENTS="usr/bin/cygSvtAv1Enc-2.dll" > libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" > > This expected: > 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1 > libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2) > -> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2) > > However, this does not seem to work as I expected. > My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2) > are installed for upgrading libsvtav1(1.8.0-1). > > Instead, I found > > 1.8.0-2: > libsvtav1_CATEGORY="_obsolete" > libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0" > libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll" > libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" > > works as expected. > Is it possible to change it like this now? If possible, I can upload fixed 1.8.0-2 (or 1.8.0-3). -- Takashi Yano
Re: Where have svt-av1 1.8.0-2 gone?
On Fri, 15 Mar 2024 16:58:06 + Jon Turney wrote: > On 15/03/2024 13:31, Takashi Yano via Cygwin-apps wrote: > > On Fri, 15 Mar 2024 13:14:49 + > > Jon Turney wrote: > >> On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: > >>> I uploaded svt-av1 1.8.0-2 few hours ago, however > >>> it does not appear on the mirror servers so far. > >>> > >>> Was anything wrong? > >> > >> Sorry, things will be a little slower than usual (uploads may take up to > >> 4 hours to get processed) until I get around to fixing up things for > >> some changes made on sourceware to provide better isolation. > >> > >> I see that this upload was declined because svt-av1 2.0.0 already exists. > >> > >> I guess you really want to upload it, as it provides a different set of > >> shared libraries to 2.0.0. Please let me know. > > > > 1.8.0-2 is necessary for changing packaging. > > I see. I configured the necessary exception, sot his should be all > uploaded now. > > > 1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1, > > However, > > 2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built. > > So, I made > > 1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in > > libsvtav1dec0 > > both obsolete libsvtav1 > > for migration. > > Hmm... maybe your thinking here is not quite clear. > > You cannot assume that an installation is upgraded often enough that it > receives every version of every package. > > (And in this case, where 1.8.0-2 appears in the repository after 2.0.0 > does, it's not going to get automatically installed anywhere) > > So, as a principle, every version of a package must contain complete > instructions for upgrading to it. > > > In this particular case, that means the cygport should contain > > libsvtav1dec0_OBSOLETES=libsvtav1 > > for as long as the package produces libsvtav1dec0. > > > (In fact, I think this all happens to work as desired because libsvtav1 > is also obsoleted by the non-longer produced libsvtav1enc1, but I just > point this out for completeness) What I did was: 1.8.0-1: libsvtav1_CONTENTS="usr/bin/*.dll" 1.8.0-2: libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll" libsvtav1enc1_OBSOLETES=libsvtav1 libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" libsvtav1dec0_OBSOLETES=libsvtav1 2.0.0-1: libsvtav1enc2_CONTENTS="usr/bin/cygSvtAv1Enc-2.dll" libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" This expected: 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1 libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2) -> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2) However, this does not seem to work as I expected. My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2) are installed for upgrading libsvtav1(1.8.0-1). Instead, I found 1.8.0-2: libsvtav1_CATEGORY="_obsolete" libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0" libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll" libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll" works as expected. Is it possible to change it like this now? -- Takashi Yano
Re: Where have svt-av1 1.8.0-2 gone?
On 15/03/2024 13:31, Takashi Yano via Cygwin-apps wrote: On Fri, 15 Mar 2024 13:14:49 + Jon Turney wrote: On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: I uploaded svt-av1 1.8.0-2 few hours ago, however it does not appear on the mirror servers so far. Was anything wrong? Sorry, things will be a little slower than usual (uploads may take up to 4 hours to get processed) until I get around to fixing up things for some changes made on sourceware to provide better isolation. I see that this upload was declined because svt-av1 2.0.0 already exists. I guess you really want to upload it, as it provides a different set of shared libraries to 2.0.0. Please let me know. 1.8.0-2 is necessary for changing packaging. I see. I configured the necessary exception, sot his should be all uploaded now. 1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1, However, 2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built. So, I made 1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in libsvtav1dec0 both obsolete libsvtav1 for migration. Hmm... maybe your thinking here is not quite clear. You cannot assume that an installation is upgraded often enough that it receives every version of every package. (And in this case, where 1.8.0-2 appears in the repository after 2.0.0 does, it's not going to get automatically installed anywhere) So, as a principle, every version of a package must contain complete instructions for upgrading to it. In this particular case, that means the cygport should contain libsvtav1dec0_OBSOLETES=libsvtav1 for as long as the package produces libsvtav1dec0. (In fact, I think this all happens to work as desired because libsvtav1 is also obsoleted by the non-longer produced libsvtav1enc1, but I just point this out for completeness) The first step I did was wrong, i.e. I should not have package which includes dlls whose versions are different. Sorry. No problem. Mistakes happen.
Re: Where have svt-av1 1.8.0-2 gone?
On Fri, 15 Mar 2024 13:14:49 + Jon Turney wrote: > On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: > > I uploaded svt-av1 1.8.0-2 few hours ago, however > > it does not appear on the mirror servers so far. > > > > Was anything wrong? > > Sorry, things will be a little slower than usual (uploads may take up to > 4 hours to get processed) until I get around to fixing up things for > some changes made on sourceware to provide better isolation. > > I see that this upload was declined because svt-av1 2.0.0 already exists. > > I guess you really want to upload it, as it provides a different set of > shared libraries to 2.0.0. Please let me know. 1.8.0-2 is necessary for changing packaging. 1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1, However, 2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built. So, I made 1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in libsvtav1dec0 both obsolete libsvtav1 for migration. The first step I did was wrong, i.e. I should not have package which includes dlls whose versions are diffrent. Sorry. -- Takashi Yano
Re: Unable to 'git push' to /git/cygwin-packages/*
On 15/03/2024 09:00, Mark Geisert via Cygwin-apps wrote:
On 3/14/2024 9:07 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:
On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:
Hi folks,
I'm getting the error:
fatal: remote error: service not enabled: /git/cygwin-packages/sshfs
when I attempt 'git push' to that repository. The same happens
with all the repositories for my packages. It's been this way for
a couple days at least.
Have I forgotten some step in the connection at my end? I'm
running ssh-agent.
[...]
What is the repository URL you are trying to push to (git remote -v)?
/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)
This maybe looks like pilot error.
We don't allow pushing using the git:// protocol (since this protocol
doesn't do any authorization, pushes with a it are very rarely enabled)
I suggest you need to do
git push
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:git/cygwin-packages/sshfs
to push successfully.
If that works, I suggest you memorialize that by doing
git remote set-url origin --push
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:git/cygwin-packages/sshfs
which will cause git to automatically use the ssh URL with a simple
'git push'.
With a minor correction ("/git" instead of "git" in the URL) this works
fine. I've made the git config change for all my projects.
Oops. Yes. Of course that's right, my mistake.
Glad to hear that things are working again for you!
Re: Where have svt-av1 1.8.0-2 gone?
On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote: I uploaded svt-av1 1.8.0-2 few hours ago, however it does not appear on the mirror servers so far. Was anything wrong? Sorry, things will be a little slower than usual (uploads may take up to 4 hours to get processed) until I get around to fixing up things for some changes made on sourceware to provide better isolation. I see that this upload was declined because svt-av1 2.0.0 already exists. I guess you really want to upload it, as it provides a different set of shared libraries to 2.0.0. Please let me know.
Where have svt-av1 1.8.0-2 gone?
I uploaded svt-av1 1.8.0-2 few hours ago, however it does not appear on the mirror servers so far. Was anything wrong? -- Takashi Yano
Re: Unable to 'git push' to /git/cygwin-packages/*
On 3/14/2024 11:26 AM, Corinna Vinschen via Cygwin-apps wrote: [...] You may also want to use https:// rather than git:// for reading the repository these days, given the insecurity of the git protocol. Right. I now remember this recommendation too. I will make the change in all the git configs for my projects. Thanks much, ..mark
Re: Unable to 'git push' to /git/cygwin-packages/*
On 3/14/2024 9:07 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:
On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:
On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:
Hi folks,
I'm getting the error:
fatal: remote error: service not enabled: /git/cygwin-packages/sshfs
when I attempt 'git push' to that repository. The same happens with
all the repositories for my packages. It's been this way for a
couple days at least.
Have I forgotten some step in the connection at my end? I'm running
ssh-agent.
[...]
What is the repository URL you are trying to push to (git remote -v)?
/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)
This maybe looks like pilot error.
We don't allow pushing using the git:// protocol (since this protocol
doesn't do any authorization, pushes with a it are very rarely enabled)
I suggest you need to do
git push
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs
to push successfully.
If that works, I suggest you memorialize that by doing
git remote set-url origin --push
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs
which will cause git to automatically use the ssh URL with a simple 'git
push'.
With a minor correction ("/git" instead of "git" in the URL) this works
fine. I've made the git config change for all my projects.
You might like to review the last time we discussed this at [1]
(Note that's slightly different, as to push to cygwin-apps repositories
you must present the key as
yourusername-rdbxbdvo6bxqt0dzr+a...@public.gmane.org, whereas for
cygwin-packages repositories, you can present the key as
cygwin-rdbxbdvo6bwxj1p+fo2...@public.gmane.org There are just different
due to historical reasons.)
[1] https://cygwin.com/pipermail/cygwin-apps/2021-September/041539.html
Thanks very much, Jon.
..mark
