[opensuse-buildservice] tar_scm blocked in "source update running"

older
[opensuse-buildservice] project...

Cristian Morales Vega

20 Oct 2010 20 Oct '10

13:35

dolphin-emu from home:RedDwarf:NonFree, that uses the new tar_scm source service, has been in "source update running" for more than an hour. Also, at least the tar_scm version I have installed from openSUSE:Tools seems to have a typo that makes --filename not work. Where it says FILE="$FILENAME" VERSION="$MYVERSION" it should say FILE="$MYFILENAME" VERSION="$MYVERSION" I would create a SR, but not sure what/where is upstream/devel project for the source services. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Show replies by date

Adrian Schröter

20 Oct 20 Oct

14:02

Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega:

...

dolphin-emu from home:RedDwarf:NonFree, that uses the new tar_scm source service, has been in "source update running" for more than an hour.

Also, at least the tar_scm version I have installed from openSUSE:Tools seems to have a typo that makes --filename not work. Where it says

FILE="$FILENAME" VERSION="$MYVERSION"

it should say

FILE="$MYFILENAME" VERSION="$MYVERSION"

I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project. thanks! -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega

16:37

2010/10/20 Adrian Schröter :

...

Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega:

...
dolphin-emu from home:RedDwarf:NonFree, that uses the new tar_scm source service, has been in "source update running" for more than an hour.

Also, at least the tar_scm version I have installed from openSUSE:Tools seems to have a typo that makes --filename not work. Where it says

FILE="$FILENAME" VERSION="$MYVERSION"

it should say

FILE="$MYFILENAME" VERSION="$MYVERSION"

I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134 But this still doesn't explains the "source update running" four hours after :-( -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

21 Oct 21 Oct

10:49

Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:

...

2010/10/20 Adrian Schröter :

...
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega:

...
dolphin-emu from home:RedDwarf:NonFree, that uses the new tar_scm source service, has been in "source update running" for more than an hour.

Also, at least the tar_scm version I have installed from openSUSE:Tools seems to have a typo that makes --filename not work. Where it says

FILE="$FILENAME" VERSION="$MYVERSION"

it should say

FILE="$MYFILENAME" VERSION="$MYVERSION"

I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134

thanks, accepted.

...

But this still doesn't explains the "source update running" four hours after :-(

right, the system where the source service is running one was dead. I need to make this more reliable the next days :/ -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

10:57

Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb Adrian Schröter:

...

Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:

...
2010/10/20 Adrian Schröter :

...
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega: ...

...
I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134

thanks, accepted.

...
But this still doesn't explains the "source update running" four hours after :-(

right, the system where the source service is running one was dead.

I need to make this more reliable the next days :/

Btw, it looks like your job caused it actually, trying to download something way bigger than 200MB (I can even check here via my local connection). I think I need to add a protection/limit here ... However, please use the "subdir" argument in source service download and package only a subdirectory (I don't think you really want the entire svn here). bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega

11:51

2010/10/21 Adrian Schröter :

...

Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb Adrian Schröter:

...
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:

...
2010/10/20 Adrian Schröter :

...
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega: ...

...
I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134

thanks, accepted.

...
But this still doesn't explains the "source update running" four hours after :-(

right, the system where the source service is running one was dead.

I need to make this more reliable the next days :/

Btw, it looks like your job caused it actually, trying to download something way bigger than 200MB (I can even check here via my local connection).

I think I need to add a protection/limit here ...

However, please use the "subdir" argument in source service download and package only a subdirectory (I don't think you really want the entire svn here).

Yeah. The useful part is 4MiB compressed, but everything is 40MiB (222MiB uncompressed). The problem is the useful and not useful parts are badly mixed, so subdir doesn't helps too much. The SVN includes an "Externals" dir with a full copy of every dependent library (very Windows-style): SDL, wxWidgets, LUA, etc. But I can't just ignore that dir since for example "WiiUse" is an external project... that has been modified so much that is not compatible anymore with the original version, being in fact an internal fork that is not really "External" at all. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega

25 Oct 25 Oct

07:55

2010/10/21 Adrian Schröter :

...

Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb Adrian Schröter:

...
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:

...
2010/10/20 Adrian Schröter :

...
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega: ...

...
I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134

thanks, accepted.

...
But this still doesn't explains the "source update running" four hours after :-(

right, the system where the source service is running one was dead.

I need to make this more reliable the next days :/

Btw, it looks like your job caused it actually, trying to download something way bigger than 200MB (I can even check here via my local connection).

I think I need to add a protection/limit here ...

However, please use the "subdir" argument in source service download and package only a subdirectory (I don't think you really want the entire svn here).

I returned to the manual tarball method. Upstream doesn't seems to want to change its SVN structure. And since they neither release tarballs I would appreciate if you can inform me if you ever find a solution that allows to use the tar_scm service. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

10:49

Am Montag, 25. Oktober 2010, 09:55:07 schrieb Cristian Morales Vega:

...

2010/10/21 Adrian Schröter :

...
Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb Adrian Schröter:

...
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:

...
2010/10/20 Adrian Schröter :

...
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega: ...

...
I would create a SR, but not sure what/where is upstream/devel project for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134

thanks, accepted.

...
But this still doesn't explains the "source update running" four hours after :-(

right, the system where the source service is running one was dead.

I need to make this more reliable the next days :/

Btw, it looks like your job caused it actually, trying to download something way bigger than 200MB (I can even check here via my local connection).

I think I need to add a protection/limit here ...

However, please use the "subdir" argument in source service download and package only a subdirectory (I don't think you really want the entire svn here).

I returned to the manual tarball method. Upstream doesn't seems to want to change its SVN structure. And since they neither release tarballs I would appreciate if you can inform me if you ever find a solution that allows to use the tar_scm service.

So, what would you need ? Multipe subdir arguments ? -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega

11:12

2010/10/25 Adrian Schröter :

...

Am Montag, 25. Oktober 2010, 09:55:07 schrieb Cristian Morales Vega:

...
2010/10/21 Adrian Schröter :

...
Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb Adrian Schröter:

...
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:

...
2010/10/20 Adrian Schröter :

...
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb Cristian Morales Vega: ... > I would create a SR, but not sure what/where is upstream/devel project > for the source services.

Please submit it to "openSUSE:Tools" project.

SR #51134

thanks, accepted.

...
But this still doesn't explains the "source update running" four hours after :-(

right, the system where the source service is running one was dead.

I need to make this more reliable the next days :/

Btw, it looks like your job caused it actually, trying to download something way bigger than 200MB (I can even check here via my local connection).

I think I need to add a protection/limit here ...

However, please use the "subdir" argument in source service download and package only a subdirectory (I don't think you really want the entire svn here).

I returned to the manual tarball method. Upstream doesn't seems to want to change its SVN structure. And since they neither release tarballs I would appreciate if you can inform me if you ever find a solution that allows to use the tar_scm service.

So, what would you need ? Multipe subdir arguments ?

The thing is I don't know SVN so much. Multiple subdirs doesn't seems to work neither since this way I can't get the files in the top dir. And I didn't find a way to make svn ignore a directory when doing the checkout. So I don't really have any suggestion... Manually what I do is checkout everything and then delete the unneeded dirs. But that doesn't seems a great solution for an automatic system. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega

30 Jan 30 Jan

11:22

2010/10/25 Adrian Schröter :

...

So, what would you need ? Multipe subdir arguments ?

I created a tarball with a svn snaspshot that when "svn up" is executed ignores the unneeded extra directories. My idea was to upload it with name "_service:tar_scm:dolphin-emu-2.0.rev6984.tar.bz2" and after that commit the _service file. I was expecting that, since the service includes if [ "$MYSCM" == "svn" ]; then if [ -z "$MYSUBDIR" -a -d "$TAR_DIRECTORY" ]; then # update existing content for speed/bandwidth reasons .... svn up it would take my manually uploaded file to start with. I had to patch osc to allow me to upload _service:* files. My problem now is that the upload fails with "Server returned an error: HTTP Error 400: Bad Request". Are _service: files upload also forbidden in the server side? There is any way to make this work? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

31 Jan 31 Jan

07:28

Am Sonntag, 30. Januar 2011, 12:22:47 schrieb Cristian Morales Vega:

...

2010/10/25 Adrian Schröter :

...
So, what would you need ? Multipe subdir arguments ?

I created a tarball with a svn snaspshot that when "svn up" is executed ignores the unneeded extra directories. My idea was to upload it with name "_service:tar_scm:dolphin-emu-2.0.rev6984.tar.bz2" and after that commit the _service file. I was expecting that, since the service includes

if [ "$MYSCM" == "svn" ]; then if [ -z "$MYSUBDIR" -a -d "$TAR_DIRECTORY" ]; then # update existing content for speed/bandwidth reasons .... svn up

it would take my manually uploaded file to start with.

I had to patch osc to allow me to upload _service:* files. My problem now is that the upload fails with "Server returned an error: HTTP Error 400: Bad Request". Are _service: files upload also forbidden in the server side? There is any way to make this work?

No, and this is on purpose. There must be the guarantee that the _service: files are really generated in the way the services are working. They are used to create the required trust in the uploaded sources. So it will never be allowed to upload them. Or we would be in the same situation that a packager or distro owner needs to review all uploaded tar balls and check against their upstream project manually. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Cristian Morales Vega

21:22

2011/1/31 Adrian Schröter :

...

No, and this is on purpose.

There must be the guarantee that the _service: files are really generated in the way the services are working. They are used to create the required trust in the uploaded sources. So it will never be allowed to upload them.

Or we would be in the same situation that a packager or distro owner needs to review all uploaded tar balls and check against their upstream project manually.

This same problem could not be simulated using two SVN repos? I create my own SVN repo, do the first checkout, and then change the _service to point to the real SVN? I don't really know enough about SVN internal working to say... -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Adrian Schröter

1 Feb 1 Feb

07:45

Am Montag, 31. Januar 2011, 22:22:40 schrieb Cristian Morales Vega:

...

2011/1/31 Adrian Schröter :

...
No, and this is on purpose.

There must be the guarantee that the _service: files are really generated in the way the services are working. They are used to create the required trust in the uploaded sources. So it will never be allowed to upload them.

Or we would be in the same situation that a packager or distro owner needs to review all uploaded tar balls and check against their upstream project manually.

This same problem could not be simulated using two SVN repos? I create my own SVN repo, do the first checkout, and then change the _service to point to the real SVN? I don't really know enough about SVN internal working to say...

When you change the _service file, it is part of the source log. The only way to trick this is to change it on the svn server or doing a man in the middle attack. The first would mean that did anyway a mistake to trust this upstream project and the latter is not that easy to do... bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

4834

Age (days ago)

4938

Last active (days ago)

List overview

Download

12 comments

2 participants

participants (2)

Adrian Schröter
Cristian Morales Vega

[opensuse-buildservice] tar_scm blocked in "source update running"

tags

participants (2)