2010/10/20 Adrian Schröter <adrian@suse.de>:

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

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 <adrian@suse.de>:

...

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

2010/10/21 Adrian Schröter <adrian@suse.de>:

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 <adrian@suse.de>:

...

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

2010/10/25 Adrian Schröter <adrian@suse.de>:

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

...

2010/10/21 Adrian Schröter <adrian@suse.de>:

...

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 <adrian@suse.de>:

...

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

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

2010/10/25 Adrian Schröter <adrian@suse.de>:

...

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

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

2011/1/31 Adrian Schröter <adrian@suse.de>:

...

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