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.
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!
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 :-(
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:
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 :/
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
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).
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.
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.
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 ?
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.
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?
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
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...
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
buildservice@lists.opensuse.org
-
Adrian Schröter -
Cristian Morales Vega