- 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)


a merge issue:

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"