[GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Fri, Jun 21, 2013 at 03:42:50AM +0300, Emmanouil Kiagias wrote:
> I just committed some basic functions for the new blend-gen-control. In the
> next few days I'll try to finish up a first working instance of the new
> blend-gen-control so then we can work on it and fix it to ours needs. In
> case you have any remarks any feedback is more than welcome :-)

[just answeredon your commit log - but by accident in private - so lets
 keep on posting here]

I pulled your change and gave it a very quick test.  You can simplify
things when setting the following in your

   /etc/postgresql/9.1/main/pg_hba.conf

host    udd          guest         127.0.0.1/32          trust


UDD is configured to give guest read access - so why not simplify your
code?  To give you an example that works for all machines I'm working
on you can have a look into

    git://git.debian.org/git/blends/website.git

file

    website/misc/pts/taskinfo-example.py

I can use this on my local host on alioth as well as on
blends.debian.net.

So with your code I get

./blend-gen-control
ERROR:blend-gen-control:Could not connect to UDD, error: fe_sendauth: no password supplied

With my attached patch I can go forward to


$ ./blend-gen-control --blend debian-med --release testing --architecture amd64
Traceback (most recent call last):
  File "./blend-gen-control", line 193, in <module>
    sys.exit(main())
  File "./blend-gen-control", line 183, in main
    _load_blend_info(args.blend)
  File "./blend-gen-control", line 84, in _load_blend_info
    _execute_query(query)
  File "./blend-gen-control", line 66, in _execute_query
    cur.execute(query)
AttributeError: 'NoneType' object has no attribute 'execute'


Hmmm, no time to check what went wrong here, may be you could catch this
exception and provide a better error message.

In general I'd prefer some defaults that will enable me to get reasonable
results even when leaving out the arguments:

  --blend:   This becomes redundant once you call blend-gen-control in a
             directory that contains the source of a certain Blend

  --release: As discussed previously we should target at the available
             packages in testing.  The option is nice to have but I would
             recommend setting "testing" as default

  --architecture: This is more complex.  Finally we want to build *one*
             source package that fits *all* architectures.  For the moment
             we could go with the manual specification (or setting the
             currrent architecture as default).  However, finally you will
             need to dig the archives / ask on mailing lists what syntax to
             use to get a source package that will create the right
             dependencies according to the architecture the source package
             was build on.  There are such packages inside the Debian
             archive but I admit I never dealt with this before and also
             would need to do some research first
             So what we create is a source package containing either one
             control file or several of them (one for each architecture)
             and once the binary packages are built from this source the
             correct architecture needs to come into effect to get the
             correct dependencies for this architecture.

Hope these hints will be helpful.

Kind regards

         Andreas.

-- 
http://fam-tille.de

diff --git a/blend-gen-control b/blend-gen-control
index 3491336..342515e 100755
--- a/blend-gen-control
+++ b/blend-gen-control
@@ -18,9 +18,11 @@ import pprint
 ##values(this is currently working for my local UDD instance)
 #### UDD connection confs ####
 HOST = "127.0.0.1"
-USER = "udd"
+USER = "guest"
 DATABASE = "udd"
-PORT = 5452
+UDDPORT=5452
+PORT=UDDPORT
+DEFAULTPORT=5432
 
 logging.basicConfig()
 logger = logging.getLogger("blend-gen-control")
@@ -36,14 +38,22 @@ blends_dependencies = {}
 conn = None
 cur = None
 
-##FIXME try also to connect with different port and host in case of errors
-#connect to UDD and initialize the cursor(cur) object
+# Define several prepared statements to query UDD
 try:
-    conn = psycopg2.connect(host=HOST,port=PORT,user=USER,database=DATABASE)
-    cur = conn.cursor()
+  conn = psycopg2.connect(host="localhost",port=PORT,user=USER,database=DATABASE)
 except psycopg2.OperationalError, err:
-    logger.error("Could not connect to UDD, error: {0}".format(err))
-    sys.exit(-1)    
+  try:
+    conn = psycopg2.connect(host="udd.debian.org",port=UDDPORT,user=USER,database=DATABASE)
+  except psycopg2.OperationalError, err:
+    # logger not known at this state: logger.warning
+    print >>stderr, "PostgreSQL does not seem to run on port %i .. trying default port %i.\n\tMessage: %s" % (PORT, DEFAULTPORT, str(err))
+    try:
+        conn = psycopg2.connect(host="localhost",port=DEFAULTPORT,user=USER,database=DATABASE)
+    except psycopg2.OperationalError:
+        # Hmmm, I observed a really strange behaviour on one of my machines where connecting to
+        # localhost does not work but 127.0.0.1 works fine.  No idea why ... but this should
+        # do the trick for the moment
+        conn = psycopg2.connect(host="127.0.0.1",port=DEFAULTPORT,user=USER,database=DATABASE)
 
 def _execute_query(query):
     """
@@ -180,4 +190,4 @@ def main():
     return 0
 
 if __name__ == '__main__':
-    sys.exit(main())
\ No newline at end of file
+    sys.exit(main())