20 Oct
2010
20 Oct
'10
14: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(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
20 Oct
20 Oct
15: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(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
17:37
2010/10/20 Adrian Schröter <adrian(a)suse.de>de>:
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb
Cristian Morales Vega:
SR #51134
But this still doesn't explains the "source update running" four hours
after :-(
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
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.
21 Oct
21 Oct
11:49
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb Cristian Morales Vega:
2010/10/20 Adrian Schröter <adrian(a)suse.de>de>:
thanks, accepted.
Am Mittwoch, 20. Oktober 2010, 15:35:04 schrieb
Cristian Morales Vega:
SR #51134 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. 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(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
11:57
Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb Adrian Schröter:
SR #51134
thanks, accepted.
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(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb
Cristian Morales Vega:
> 2010/10/20 Adrian Schröter <adrian(a)suse.de>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. 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 :/
12:51
2010/10/21 Adrian Schröter <adrian(a)suse.de>de>:
Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb
Adrian Schröter:
thanks, accepted.
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(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb
Cristian Morales Vega:
> 2010/10/20 Adrian Schröter <adrian(a)suse.de>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 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 :/
25 Oct
25 Oct
08:55
2010/10/21 Adrian Schröter <adrian(a)suse.de>de>:
Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb
Adrian Schröter:
thanks, accepted.
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(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Am Mittwoch, 20. Oktober 2010, 18:37:17 schrieb
Cristian Morales Vega:
> 2010/10/20 Adrian Schröter <adrian(a)suse.de>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 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 :/
11:49
Am Montag, 25. Oktober 2010, 09:55:07 schrieb Cristian Morales Vega:
2010/10/21 Adrian Schröter <adrian(a)suse.de>de>:
So, what would you need ? Multipe subdir arguments ?
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb
Adrian Schröter:
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 Mittwoch, 20. Oktober 2010, 18:37:17 schrieb
Cristian Morales Vega:
> 2010/10/20 Adrian Schröter <adrian(a)suse.de>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 :/
12:12
2010/10/25 Adrian Schröter <adrian(a)suse.de>de>:
Am Montag, 25. Oktober 2010, 09:55:07 schrieb Cristian
Morales Vega:
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(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
2010/10/21 Adrian Schröter
<adrian(a)suse.de>de>:
So, what would you need ? Multipe subdir arguments ? Am Donnerstag, 21. Oktober 2010, 12:49:04 schrieb
Adrian Schröter:
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 Mittwoch, 20. Oktober 2010, 18:37:17 schrieb
Cristian Morales Vega:
> 2010/10/20 Adrian Schröter <adrian(a)suse.de>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).
30 Jan
30 Jan
11:22
2010/10/25 Adrian Schröter <adrian(a)suse.de>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?
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
31 Jan
31 Jan
07:28
Am Sonntag, 30. Januar 2011, 12:22:47 schrieb Cristian Morales Vega:
2010/10/25 Adrian Schröter <adrian(a)suse.de>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.
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
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?
21:22
2011/1/31 Adrian Schröter <adrian(a)suse.de>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...
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
1 Feb
1 Feb
07:45
Am Montag, 31. Januar 2011, 22:22:40 schrieb Cristian Morales Vega:
2011/1/31 Adrian Schröter <adrian(a)suse.de>de>:
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(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
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...
3892
days inactive
3996
days old
buildservice@lists.opensuse.org
12 comments
2 participants
participants (2)
-
Adrian Schröter -
Cristian Morales Vega