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

- implement 'info' command
- implement 'mv' command
- creation of new project (workaround: editmeta <newprj>)
- creation of new package (workaround: editmeta prj <newpac>)
- editing of user data
  <watchlist>
    <project name="ASCIIParadize"/>
    <project name="crashtest"/>
  </watchlist>
- editmeta: validate input
- updatepacmetafromspec -- is that useful? 
  In which form would this be integrated best?
- clean up the way how a .oscrc template is being added: at the moment, there
  are two places doing this


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


results: aggregate results of all packages in a project
-> packstatus: http://api.opensuse.org/result/KDE:KDE3/packstatus
               http://api.opensuse.org/result/KDE:KDE3/packstatus?summary
               http://api.opensuse.org/result/KDE:KDE3/packstatus?summaryonly




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


17:24 <darix> und wie waere ein osc link src_project src_package
              [local_package] ?:p
or: "linkpac"?
just create a _link file with the content
	<link project='exim' package='exim'/>



<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




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


17:30 < DuDE> jbl_: at the moment there is only exclude_stuff = [store, '.svn', 'CVS'], it should be extended to use globs

01:20 < darix> DuDE: http://rafb.net/paste/results/hUjH7v14.html
01:21 < darix> that happens if the log is not accessible atm

02:26 <darix> Transmitting file data ..Traceback (most recent call last):
02:26 <darix>   File "/usr/bin/osc", line 10, in ?
02:26 <darix>     commandline.main()
02:26 <darix>   File "/usr/lib/python2.4/site-packages/osc/commandline.py", line 667, in main
02:26 <darix>     cmd_dict[cmd](args)
02:26 <darix>   File "/usr/lib/python2.4/site-packages/osc/commandline.py", line 340, in checkin
02:26 <darix>     p.to_be_deleted.remove(filename)
02:26 <darix> ValueError: list.remove(x): x not in list


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>


16:59 < kesselborn> for var in ['OSC_SU_WRAPPER', 'OSC_BUILD_ROOT', 'OSC_PACKAGECACHEDIR', 'BUILD_ROOT']
16:59 < kesselborn> Du hast OSC_SU_WRAPPER', 'OSC_BUILD_ROOT', vergessen

curl -d " " -n "http://api.opensuse.org/source/server:php/php5_hardened?cmd=rebuild&arch=i586&repo=SUSE_Linux_10.0"


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