[opensuse-buildservice] osc umlaut problem

Hi, is this just me or can someone reproduce this? 0 froh@byron:/tmp/serna-free $ osc request show 12780 Traceback (most recent call last): File "/usr/bin/osc", line 12, in <module> r = babysitter.run(osccli) File "/usr/lib/python2.6/site-packages/osc/babysitter.py", line 38, in run return prg.main() File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 307, in main return self.cmd(args) File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 330, in cmd retval = self.onecmd(argv) File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 446, in onecmd return self._dispatch_cmd(handler, argv) File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 1176, in _dispatch_cmd return handler(argv[0], opts, *args) File "/usr/lib/python2.6/site-packages/osc/commandline.py", line 783, in do_request print r UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 175: ordinal not in range(128) I'm using the osc from openSUSE:Tools, which is 0.120 In the debugger I see this unicode problem: I start the debugger 0 froh@byron:~ $ osc --debugger request show 12780 > /usr/lib/python2.6/site-packages/osc/babysitter.py(38)run() -> return prg.main() (Pdb) b /usr/lib/python2.6/site-packages/osc/commandline.py:783 Breakpoint 1 at /usr/lib/python2.6/site-packages/osc/commandline.py:783 (Pdb) c > /usr/lib/python2.6/site-packages/osc/commandline.py(783)do_request() -> print r (Pdb) s --Call-- > /usr/lib/python2.6/site-packages/osc/core.py(1343)__str__() -> def __str__(self): (Pdb) l 1338 return ret 1339 1340 def __cmp__(self, other): 1341 return cmp(self.reqid, other.reqid) 1342 1343 -> def __str__(self): 1344 # XXX: only prints out the first action element 1345 s = """\ 1346 Request to %s (sri%s): 1347 1348 %s/%s -> %s/%s 1349 1350 Source revision: 1351 %s 1352 1353 Message: 1354 %s 1355 1356 State: %-10s %s %s 1357 Comment: %s 1358 """ % (self.actions[0].type, 1359 self.reqid, 1360 self.actions[0].src_project, 1361 self.actions[0].src_package, 1362 self.actions[0].dst_project, 1363 self.actions[0].dst_package, 1364 self.actions[0].src_rev or 'not given', 1365 self.descr, 1366 self.state.name, 1367 self.state.when, self.state.who, self.state.comment) 1368 1369 if len(self.statehistory): 1370 histitems = [ '%-10s %s %s' \ 1371 % (i.name, i.when, i.who) \ 1372 for i in self.statehistory ] 1373 s += 'History: ' + '\n '.join(histitems) 1374 1375 s += '\n' 1376 return s 1377 1378 1379 def shorttime(t): 1380 """format time as Apr 02 18:19 1381 or Apr 02 2005 (Pdb) b 1376 Breakpoint 2 at /usr/lib/python2.6/site-packages/osc/core.py:1376 (Pdb) c > /usr/lib/python2.6/site-packages/osc/core.py(1376)__str__() -> return s I look at the result of this (Pdb) p s u"Request to submit (sri12780): \n\n home:computersalat:branches:openSUSE:Tools/obs-server -> openSUSE:Tools/obs-server\n\nSource revision:\n 2\n\nMessage:\n applied Marcus H\xfcwe's inject_localpkgdata patch for backend, cause of broken 'osc build -p DIR'\n\nState: new 2009-06-21T19:18:52 computersalat\nComment: None\n\n" I try to print it from the debugger: (Pdb) print s Request to submit (sri12780): home:computersalat:branches:openSUSE:Tools/obs-server -> openSUSE:Tools/obs-server Source revision: 2 Message: applied Marcus Hüwe's inject_localpkgdata patch for backend, cause of broken 'osc build -p DIR' State: new 2009-06-21T19:18:52 computersalat Comment: None this works fine. (Pdb) n --Return-- > /usr/lib/python2.6/site-packages/osc/core.py(1376)__str__()->u"Reques..None\n\n" -> return s Now here I get an exception: (Pdb) n UnicodeEncodeError: UnicodeE...ge(128)') > /usr/lib/python2.6/site-packages/osc/commandline.py(783)do_request() -> print r (Pdb) n --Return-- > /usr/lib/python2.6/site-packages/osc/commandline.py(783)do_request()->None -> print r (Pdb) n --Call-- > /usr/lib/python2.6/site-packages/osc/cmdln.py(419)cmdexc() -> def cmdexc(self, argv): (Pdb) n > /usr/lib/python2.6/site-packages/osc/cmdln.py(429)cmdexc() -> import sys (Pdb) n > /usr/lib/python2.6/site-packages/osc/cmdln.py(430)cmdexc() -> type, exc, traceback = sys.exc_info() (Pdb) n > /usr/lib/python2.6/site-packages/osc/cmdln.py(431)cmdexc() -> if isinstance(exc, CmdlnUserError): (Pdb) p exc UnicodeEncodeError('ascii', u"Request to submit (sri12780): \n\n home:computersalat:branches:openSUSE:Tools/obs-server -> openSUSE:Tools/obs-server\n\nSource revision:\n 2\n\nMessage:\n applied Marcus H\xfcwe's inject_localpkgdata patch for backend, cause of broken 'osc build -p DIR'\n\nState: new 2009-06-21T19:18:52 computersalat\nComment: None\n\n", 175, 176, 'ordinal not in range(128)') (Pdb) whats going on here?? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Does your terminal support unicode and if it does does python know that? Python should only beconverting down to ascii if it doesn't think your terminal can display unicode. Susanne Oberhauser wrote:
Hi,
is this just me or can someone reproduce this?
0 froh@byron:/tmp/serna-free $ osc request show 12780 Traceback (most recent call last): File "/usr/bin/osc", line 12, in <module> r = babysitter.run(osccli) File "/usr/lib/python2.6/site-packages/osc/babysitter.py", line 38, in run return prg.main() File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 307, in main return self.cmd(args) File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 330, in cmd retval = self.onecmd(argv) File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 446, in onecmd return self._dispatch_cmd(handler, argv) File "/usr/lib/python2.6/site-packages/osc/cmdln.py", line 1176, in _dispatch_cmd return handler(argv[0], opts, *args) File "/usr/lib/python2.6/site-packages/osc/commandline.py", line 783, in do_request print r UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 175: ordinal not in range(128)
I'm using the osc from openSUSE:Tools, which is 0.120
In the debugger I see this unicode problem:
I start the debugger
0 froh@byron:~ $ osc --debugger request show 12780 > /usr/lib/python2.6/site-packages/osc/babysitter.py(38)run() -> return prg.main() (Pdb) b /usr/lib/python2.6/site-packages/osc/commandline.py:783 Breakpoint 1 at /usr/lib/python2.6/site-packages/osc/commandline.py:783 (Pdb) c > /usr/lib/python2.6/site-packages/osc/commandline.py(783)do_request() -> print r (Pdb) s --Call-- > /usr/lib/python2.6/site-packages/osc/core.py(1343)__str__() -> def __str__(self): (Pdb) l 1338 return ret 1339 1340 def __cmp__(self, other): 1341 return cmp(self.reqid, other.reqid) 1342 1343 -> def __str__(self): 1344 # XXX: only prints out the first action element 1345 s = """\ 1346 Request to %s (sri%s): 1347 1348 %s/%s -> %s/%s 1349 1350 Source revision: 1351 %s 1352 1353 Message: 1354 %s 1355 1356 State: %-10s %s %s 1357 Comment: %s 1358 """ % (self.actions[0].type, 1359 self.reqid, 1360 self.actions[0].src_project, 1361 self.actions[0].src_package, 1362 self.actions[0].dst_project, 1363 self.actions[0].dst_package, 1364 self.actions[0].src_rev or 'not given', 1365 self.descr, 1366 self.state.name, 1367 self.state.when, self.state.who, self.state.comment) 1368 1369 if len(self.statehistory): 1370 histitems = [ '%-10s %s %s' \ 1371 % (i.name, i.when, i.who) \ 1372 for i in self.statehistory ] 1373 s += 'History: ' + '\n '.join(histitems) 1374 1375 s += '\n' 1376 return s 1377 1378 1379 def shorttime(t): 1380 """format time as Apr 02 18:19 1381 or Apr 02 2005 (Pdb) b 1376 Breakpoint 2 at /usr/lib/python2.6/site-packages/osc/core.py:1376 (Pdb) c > /usr/lib/python2.6/site-packages/osc/core.py(1376)__str__() -> return s
I look at the result of this (Pdb) p s u"Request to submit (sri12780): \n\n home:computersalat:branches:openSUSE:Tools/obs-server -> openSUSE:Tools/obs-server\n\nSource revision:\n 2\n\nMessage:\n applied Marcus H\xfcwe's inject_localpkgdata patch for backend, cause of broken 'osc build -p DIR'\n\nState: new 2009-06-21T19:18:52 computersalat\nComment: None\n\n"
I try to print it from the debugger: (Pdb) print s Request to submit (sri12780):
home:computersalat:branches:openSUSE:Tools/obs-server -> openSUSE:Tools/obs-server
Source revision: 2
Message: applied Marcus Hüwe's inject_localpkgdata patch for backend, cause of broken 'osc build -p DIR'
State: new 2009-06-21T19:18:52 computersalat Comment: None
this works fine.
(Pdb) n --Return-- > /usr/lib/python2.6/site-packages/osc/core.py(1376)__str__()->u"Reques..None\n\n" -> return s
Now here I get an exception:
(Pdb) n UnicodeEncodeError: UnicodeE...ge(128)') > /usr/lib/python2.6/site-packages/osc/commandline.py(783)do_request() -> print r (Pdb) n --Return-- > /usr/lib/python2.6/site-packages/osc/commandline.py(783)do_request()->None -> print r (Pdb) n --Call-- > /usr/lib/python2.6/site-packages/osc/cmdln.py(419)cmdexc() -> def cmdexc(self, argv): (Pdb) n > /usr/lib/python2.6/site-packages/osc/cmdln.py(429)cmdexc() -> import sys (Pdb) n > /usr/lib/python2.6/site-packages/osc/cmdln.py(430)cmdexc() -> type, exc, traceback = sys.exc_info() (Pdb) n > /usr/lib/python2.6/site-packages/osc/cmdln.py(431)cmdexc() -> if isinstance(exc, CmdlnUserError): (Pdb) p exc UnicodeEncodeError('ascii', u"Request to submit (sri12780): \n\n home:computersalat:branches:openSUSE:Tools/obs-server -> openSUSE:Tools/obs-server\n\nSource revision:\n 2\n\nMessage:\n applied Marcus H\xfcwe's inject_localpkgdata patch for backend, cause of broken 'osc build -p DIR'\n\nState: new 2009-06-21T19:18:52 computersalat\nComment: None\n\n", 175, 176, 'ordinal not in range(128)') (Pdb)
whats going on here??
S.
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Luke Imhoff <luke@cray.com> writes:
Does your terminal support unicode and if it does does python know that? Python should only beconverting down to ascii if it doesn't think your terminal can display unicode.
I never had this problem before. The terminal is a kde3 Konsole. 0 froh@byron:/tmp $ echo $TERM xterm+sl 0 froh@byron:/tmp $ echo $LANG en_EN.UTF-8 S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Dne Wed, 01 Jul 2009 07:53:57 -0500 Luke Imhoff <luke@cray.com> napsal(a):
Does your terminal support unicode and if it does does python know that? Python should only beconverting down to ascii if it doesn't think your terminal can display unicode.
In default configuration (in 2.x branch) Python always tries to print ascii. Not sure whether this is changed on SUSE, but for Debian this thing is kept. -- Michal Čihař | http://cihar.com | http://blog.cihar.com

Michal Čihař <michal@cihar.com> writes:
Dne Wed, 01 Jul 2009 07:53:57 -0500 Luke Imhoff <luke@cray.com> napsal(a):
Does your terminal support unicode and if it does does python know that? Python should only beconverting down to ascii if it doesn't think your terminal can display unicode.
In default configuration (in 2.x branch) Python always tries to print ascii. Not sure whether this is changed on SUSE, but for Debian this thing is kept.
can you guys reproduce the problem with this command line? osc request show 12780 I'm on openSUSE 11.1 with obs 0.120 from openSUSE:Tools. If so, I'm happy to fix this --- a pointer to how to set the utf-8 output configuration is appreciated. What I don't get is why "print s" from the debugger does it right, while the print in osc fails in my debugging session. S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi Dne Thu, 02 Jul 2009 07:28:58 +0200 Susanne Oberhauser <froh@novell.com> napsal(a):
can you guys reproduce the problem with this command line?
osc request show 12780
Yes.
I'm on openSUSE 11.1 with obs 0.120 from openSUSE:Tools.
On both openSUSE 11.1 and Debian unstable, osc 0.120.
What I don't get is why "print s" from the debugger does it right, while the print in osc fails in my debugging session.
Just played a bit with the source and I have to admit that I do not understand how the string conversion works :-). These work fine: print r.__str__() print unicode(r) But this one does not: print r -- Michal Čihař | http://cihar.com | http://blog.cihar.com

On 2009-07-02 08:19:18 +0200, Michal Čihař wrote:
What I don't get is why "print s" from the debugger does it right, while the print in osc fails in my debugging session.
Just played a bit with the source and I have to admit that I do not understand how the string conversion works :-).
These work fine:
print r.__str__() print unicode(r)
But this one does not:
print r
That's due to the implementation of the print function. It implicitly calls str() on the string returned by __str__() which fails in case the string is a unicode object which contains chars which cannot be converted to ascii (in this case 0xfc). It seems that if you directly pass a string or unicode object to the print call no str() method is called. Another question is if the usage of __str__() is correct in this case because we obviously can't ensure that the result can be converted to ascii - so should we use __unicode__() instead of __str__() in this case? Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Michal Čihař <michal@cihar.com> writes:
Hi
Dne Thu, 02 Jul 2009 07:28:58 +0200 Susanne Oberhauser <froh@novell.com> napsal(a):
can you guys reproduce the problem with this command line?
osc request show 12780
Yes.
I'm on openSUSE 11.1 with obs 0.120 from openSUSE:Tools.
On both openSUSE 11.1 and Debian unstable, osc 0.120.
What I don't get is why "print s" from the debugger does it right, while the print in osc fails in my debugging session.
Just played a bit with the source and I have to admit that I do not understand how the string conversion works :-).
These work fine:
print r.__str__() print unicode(r)
But this one does not:
print r
Researching a bit on python and unicode, I think the culprit is how we initialize the default encoding. Looking at /usr/lib/python2.6/site.py, we don't use the locale settings (LANG, LC_*) but hard code ascii. As a result of this, str() tries to encode the result of __str__ to ascii, which fails. The sys.setdefaultencoding function is disabled after site initialization on purpose: http://www.python.org/dev/peps/pep-0100/ The purpose isn't clear, though. There is thre fixes to this: 1. we enable in syte.py the use of the locale setting 2. we work around the IMNSHO braindead disablement of "setdefaultencoding": import sys, locale reload(sys) sys.setdefaultencoding(locale.getdefaultlocale()[1]) 3. We scatter explicit unicode awareness to every place we possibly handle unicode strings strings. I *strongly* opt for #1 or #2. #3 is just so plain inelegant, I refuse to do that. It's like checking return codes after exceptions have been invented. S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Hi Dne Fri, 03 Jul 2009 10:09:06 +0200 Susanne Oberhauser <froh@novell.com> napsal(a):
The sys.setdefaultencoding function is disabled after site initialization on purpose: http://www.python.org/dev/peps/pep-0100/
The purpose isn't clear, though.
I've found somewhere, that this function was supposed to be temporary until developers decide what should be default encoding. Unfortunately it was not removed later and is still there what only increases confusion.
There is thre fixes to this:
1. we enable in syte.py the use of the locale setting
Problem with this is that you will most likely break applications which do rely on default settings.
2. we work around the IMNSHO braindead disablement of "setdefaultencoding":
import sys, locale reload(sys) sys.setdefaultencoding(locale.getdefaultlocale()[1])
3. We scatter explicit unicode awareness to every place we possibly handle unicode strings strings.
I *strongly* opt for #1 or #2. #3 is just so plain inelegant, I refuse to do that. It's like checking return codes after exceptions have been invented.
4. Wait for python 3.0 :-). -- Michal Čihař | http://cihar.com | http://blog.cihar.com

Michal Čihař <michal@cihar.com> writes:
There is thre fixes to this:
1. we enable in syte.py the use of the locale setting
Problem with this is that you will most likely break applications which do rely on default settings.
yes.
2. we work around the IMNSHO braindead disablement of "setdefaultencoding":
import sys, locale reload(sys) sys.setdefaultencoding(locale.getdefaultlocale()[1])
3. We scatter explicit unicode awareness to every place we possibly handle unicode strings strings.
I *strongly* opt for #1 or #2. #3 is just so plain inelegant, I refuse to do that. It's like checking return codes after exceptions have been invented.
4. Wait for python 3.0 :-).
ok, that means #2 for now, right? 1 froh@byron:/tmp $ rcsdiff -u /usr/bin/osc =================================================================== RCS file: /usr/bin/osc,v retrieving revision 1.1 diff -u -r1.1 /usr/bin/osc --- /usr/bin/osc 2009/07/03 11:20:56 1.1 +++ /usr/bin/osc 2009/07/03 11:22:39 @@ -3,7 +3,14 @@ # this wrapper exists so it can be put into /usr/bin, but still allows the # python module to be called within the source directory during development -import sys + +import sys, locale +# this is a hack to make osc work as expected with utf-8 characters, no matter +# how site.py is set... +reload(sys) +sys.setdefaultencoding(locale.getdefaultlocale()[1]) +del sys.setdefaultencoding + from osc import commandline from osc import babysitter This fixes the problem for me. S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2009-07-03 13:24:59 +0200, Susanne Oberhauser wrote:
Michal Čihař <michal@cihar.com> writes:
There is thre fixes to this:
1. we enable in syte.py the use of the locale setting
Problem with this is that you will most likely break applications which do rely on default settings.
yes.
2. we work around the IMNSHO braindead disablement of "setdefaultencoding":
import sys, locale reload(sys) sys.setdefaultencoding(locale.getdefaultlocale()[1])
3. We scatter explicit unicode awareness to every place we possibly handle unicode strings strings.
I *strongly* opt for #1 or #2. #3 is just so plain inelegant, I refuse to do that. It's like checking return codes after exceptions have been invented.
4. Wait for python 3.0 :-).
ok, that means #2 for now, right?
Hmm IMHO this is just a workaround which doesn't really fix the problem. The problem is that our implementation of __str__() is wrong in the sense of the return "type". We need to ensure that everything __str__() returns can be converted to the str type. For all other cases we should use __unicode__() but then there might be cases where "print obj" doesn't print out the expected result because print doesn't use __unicode__()... Actually my main "concern" with your workaround is that it will break other applications which use osc and rely on the correctness of __str__(). This all seems to be quite complicated:) Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Marcus Hüwe <suse-tux@gmx.de> writes:
Hmm IMHO this is just a workaround which doesn't really fix the problem. The problem is that our implementation of __str__() is wrong in the sense of the return "type". We need to ensure that everything __str__() returns can be converted to the str type. For all other cases we should use __unicode__() but then there might be cases where "print obj" doesn't print out the expected result because print doesn't use __unicode__()... Actually my main "concern" with your workaround is that it will break other applications which use osc and rely on the correctness of __str__(). This all seems to be quite complicated:)
The alternative is to make the encoding selection explicit throughout the code, like this: def __str__(self): s = ... return s.encode("utf-8") # evil as the locale setting may be different # return s.encode(locale.getdefaultlocale()[1]) Now how ugly is _that_ ? All #2 is trying to mimic is python3 behavior: it pretends all strings are unicode, and it assumes, that when str() comes into play, human interaction is close so coercion to the external representation as suggested by the locale is smart. Python3 will also go that route, btw: all strings will be unicode. How many third party plugins into osc do you think we realistically may have that will break by this change? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 2009-07-03 23:38:14 +0200, Susanne Oberhauser wrote:
Marcus Hüwe <suse-tux@gmx.de> writes:
Hmm IMHO this is just a workaround which doesn't really fix the problem. The problem is that our implementation of __str__() is wrong in the sense of the return "type". We need to ensure that everything __str__() returns can be converted to the str type. For all other cases we should use __unicode__() but then there might be cases where "print obj" doesn't print out the expected result because print doesn't use __unicode__()... Actually my main "concern" with your workaround is that it will break other applications which use osc and rely on the correctness of __str__(). This all seems to be quite complicated:)
The alternative is to make the encoding selection explicit throughout the code, like this:
def __str__(self):
s = ...
return s.encode("utf-8") # evil as the locale setting may be different # return s.encode(locale.getdefaultlocale()[1])
Now how ugly is _that_ ?
That's quite ugly:)
All #2 is trying to mimic is python3 behavior: it pretends all strings are unicode, and it assumes, that when str() comes into play, human interaction is close so coercion to the external representation as suggested by the locale is smart.
Python3 will also go that route, btw: all strings will be unicode.
How many third party plugins into osc do you think we realistically may have that will break by this change?
No they might break by the current implementation of the __str__() method and not by your change. But there's no "non-ugly" fix for this... so IMHO the best is if you commit your #2 diff so that at least osc can handle it correctly. Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Question: one of my submit requests to the games OBS project has been approved (GoOllie). In the past, when that happened, the build and publish were enabled by default. But for that package, everything is disabled. Is this a new default ? (which is a good idea in my opinion) Before I re-enable it, I just want to be sure it hasn't been disabled manually on purpose, maybe to save some build server for other packages to be built with higher priority. Thanks, Vincent -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpMlosACgkQSSdxpfEEQEygewCghd5rWTDl9W5nT2HByv111eks aogAnAgAf05wtZQS/lO3X2OFBkgCI4GR =3P9R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

2009/7/2 Vincent Petry <PVince81@yahoo.fr>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Question: one of my submit requests to the games OBS project has been approved (GoOllie). In the past, when that happened, the build and publish were enabled by default. But for that package, everything is disabled. Is this a new default ? (which is a good idea in my opinion)
Before I re-enable it, I just want to be sure it hasn't been disabled manually on purpose, maybe to save some build server for other packages to be built with higher priority.
I accepted it, but added a message asking for some minor changes before you published it. See the output from osc request show 13353. You should have received an email... but since some time ago I don't receive them when someone accept a package from me (I receive it for requests). I have that configured in hermes... **bug**? Please, before publishing it: - Remove the "Vendor" tag (the OBS adds it and putting it in the spec file overrides that) - Add a menu entry (.desktop file and icon) - And something I didn't saw/said in the accept message: the .py files should be precompiled as is said at http://en.opensuse.org/Packaging/Python#Byte_Compiled_Files -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 7/2/2009 at 13:41, Cristian Morales Vega <cmorve69@yahoo.es> wrote: I accepted it, but added a message asking for some minor changes before you published it. See the output from osc request show 13353. You should have received an email... but since some time ago I don't receive them when someone accept a package from me (I receive it for requests). I have that configured in hermes... **bug**?
Yes, https://bugzilla.novell.com/show_bug.cgi?id=505185 Dominique -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Cristian, Thank you for accepting my request. I will fix the points you mentionned before enabling the build. I indeed didn't receive any message from you from the submitreq. Thanks, Vincent Cristian Morales Vega a écrit :
2009/7/2 Vincent Petry <PVince81@yahoo.fr>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Question: one of my submit requests to the games OBS project has been approved (GoOllie). In the past, when that happened, the build and publish were enabled by default. But for that package, everything is disabled. Is this a new default ? (which is a good idea in my opinion)
Before I re-enable it, I just want to be sure it hasn't been disabled manually on purpose, maybe to save some build server for other packages to be built with higher priority.
I accepted it, but added a message asking for some minor changes before you published it. See the output from osc request show 13353. You should have received an email... but since some time ago I don't receive them when someone accept a package from me (I receive it for requests). I have that configured in hermes... **bug**?
Please, before publishing it: - Remove the "Vendor" tag (the OBS adds it and putting it in the spec file overrides that) - Add a menu entry (.desktop file and icon) - And something I didn't saw/said in the accept message: the .py files should be precompiled as is said at http://en.opensuse.org/Packaging/Python#Byte_Compiled_Files -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkpMshcACgkQSSdxpfEEQEzdzgCeK3Mrhxlbs0UKufpRAHLJVYYw ZmMAn36ECGLRVXzNv87xpajfp7fRyHXn =mDkz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Donnerstag, 2. Juli 2009 13:14:19 schrieb Vincent Petry:
Hi,
Question: one of my submit requests to the games OBS project has been approved (GoOllie). In the past, when that happened, the build and publish were enabled by default. But for that package, everything is disabled. Is this a new default ? (which is a good idea in my opinion)
A submit request never changes the build flags.
Before I re-enable it, I just want to be sure it hasn't been disabled manually on purpose, maybe to save some build server for other packages to be built with higher priority.
We have not changed any build flags (yet) due to load issues. 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
participants (8)
-
Adrian Schröter
-
Cristian Morales Vega
-
Dominique Leuenberger
-
Luke Imhoff
-
Marcus Hüwe
-
Michal Čihař
-
Susanne Oberhauser
-
Vincent Petry