- split functionality that needs prj/pac as commandline arguments into a seperate tool (oscremote? osc -r?)

- implement 'info' command
- implement 'mv' command
- editmeta: the API will return a 500 if the xml is broken... the document
  could be presented for editing again in that case
- updatepacmetafromspec -- is that useful? 
  In which form would this be integrated best?
- use urllib.urlencode for parameter encoding
- _real_ SSL support, with certificate verification
- zsh completion, or even bash
- support #norootforbuild (or is it supported? do we just need to enforce it, like the bs does?)
  -> --norootforbuild als 'build' OPtion
- add option to disable gpg key checking?
- add support for adding tags to packages?
- prefer-rpms support for osc build
- plugin-ize subcommand implementation
  - look at Susannes extensions


checkin: 
	- handle error if PUT fails, so the change is not committed to
	  localmeta	


- changelog handling
  (should also work with multiple spec files <package-name>-<repository-name>.spec, and with <package-name>-<version>.spec)



implement a package search / indexing


> BTW: Can I upload a src.rpm instead of a tarball also?
no, because not all tools will be able to handle a src.rpm. And you will not
be able to build non rpm packages from it.
But someone could patch the commandline tool osc to import a src.rpm by
extracting it (hint hint ;)




<darix> ich hab nen vorschlag fuer osc
<darix> sagen wir ich leg ein server:mail/foo123 an
<darix> dann waere es cool sowas zu koennen wie
<darix> osc importfromspec server:mail foo123
This can actually be done by
	osc createpac server:mail foo123
followed by
	cd foo123; osc init server:mail foo123




bug:
 % osc rm subversion.de.po.bz2 subversion.nb.po.bz2
D    subversion.de.po.bz2
D    subversion.nb.po.bz2
poeml@aust ~/pac/opensuse/Subversion/subversion
 % osc ci subversion.de.po.bz2 subversion.nb.po.bz2
Sending        subversion.changes
Deleting       subversion.de.po.bz2
Deleting       subversion.nb.po.bz2
Sending        subversion.viewcvs.conf
Transmitting file data ..


15:47 < kesselborn> DuDE: beim osc local build: müssen die config vars gesetzt sein, wenn man env vars gesetzt hat?
15:48 < DuDE> kesselborn: hm, weiss ich gerade gar nicht
15:48 < kesselborn> ja, scheint so
15:48 < kesselborn> ok
15:48 < kesselborn> aber er nimmt dann die env vas
15:48 < kesselborn> vars
15:50 < DuDE> kesselborn: hm, das sollte ich aendern





osc repos server:search:ui :
  <repository name="SUSE_Linux_10.1">
    <path project="server:search" repository="SUSE_Linux_10.1" />
    <path project="KDE:KDE4" repository="SUSE_Linux_10.1" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
  <repository name="SUSE_Factory">
    <path project="server:search" repository="SUSE_Factory" />
    <path project="KDE:KDE4" repository="SUSE_Factory" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>



# shorter forms of the packstatus... useful for anything?
#http://api.opensuse.org/result/KDE:KDE3/packstatus?summary
#http://api.opensuse.org/result/KDE:KDE3/packstatus?summaryonly

results seems very slow, it presumably does more network accesses than necessary
it shouldn't take more time than prjresults


 # osc build SUSE_Factory i586 xorg-x11-libX11.spec                                                                                          
> ['/usr/bin/osc', 'build', 'i38', 'i386', 'SUSE_Factory', 'i586', 'xorg-x11-libX11.spec']                                                    
> Error: specfile 'SUSE_Factory' does not exist.                                                                                              
BUILD_DIST must *not* be set! Could you add this information to the
'osc help build' text?



http://api.opensuse.org/result/Apache/SUSE_Linux_10.0/apache2/result
15:06 <darix> kurz zeit ueber 1-2 osc feature request zu reden die ich grade bekommen habe?
15:06 <DuDE_> ja
15:06 <darix> ok
15:06 <darix> das 1. ist
15:06 <darix> osc listpackages [<project>]
15:06 <DuDE_> als Alias?
15:07 <darix> osc listpackages [<project>] [<package>]
15:07 <darix> es soll die gebauten sachen listen
15:07 <DuDE_> ach so, rpms
15:07 <darix> quasi alle rpms/debs die da sind
15:07 <darix> und dann
15:07 <DuDE_> mit Pfad/URL?
15:07 <DuDE_> also praktisch den Link auf software.opesuse.org?
15:07 <darix> osc getpackage [<project>] [<package>] [<rpm>]+
15:07 <darix> nein
15:07 <darix> im zweifel ueber API saugen
15:08 <DuDE_> hm, waere noetig, falls ein Projekt noch nicht durchgebaut hat
15:08 <darix> jau
15:08 <darix> richi wuerde sich wirklich drueber freuen
15:08 <darix> ich weiss dass es ueber die api vom backend geht
15:09 <darix> ich weiss nur nicht ob api alles durchreicht
15:09 <darix> und leider hab ich schon ein paar sachen im api code gefunden
15:09 <darix> der falsch mit dem backend spricht :/
15:09 <DuDE_> ja, macht osc build auch so, eigentlich, allerdings weiss es dann die noetigen Datein aus dem buildinfo (version, release)
15:09 <darix> man kann auf dem backend alle rpms listen lassen


 % osc addremove
A    .swp


Right now, a package must exist in the bs so that it can be built
locally. But this is a bug in osc which I'm going to fix at some point
in time.


editmeta:
Ah, or rather osc _thought_ it was unmodified because it uses a simple 
timestamp to compare the file with. This is basically suitable for 
humans editing, because they need more than a second... I can change
that to a real comparison. Meanwhile, you can add a small sleep ;)

On the other hand, it would be even nicer if there would be a facility 
that wouldn't require you to work around with an EDITOR script at all. 
Noted in the todo.


copypac:
put the current release number into the spec file before sending it

show request body of 400 responses (bad request)


geht print self.USAGE % self.__dict__ ?

if import cElememtTree fails, use elementtree
if that fails, point to home:cthiel1 repository (or devel:languages:python)


two merge issues:

1)
when updating, the file should be copied to store even if merge fails. this would prevent
that, after manual merging and osc resolve, one still sees the upstream changes in osc diff.

2)
check the following:
if I mark a file as "to be added" ("A"), and someone else alread adds (and
commits) the file in between, and I update -- will I get it marked as "D" after update??
D    apr_dbd_mysql.c
M    libapr-util1.spec


build command:
> "You need to call the command inside a package directory, which should be a
> buildsystem checkout. (Local modifications are fine.)"



buildinfo aenderungen:
preinstall="1" runscripts="1"