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

[Emmanouil Kiagias <e.kiagias@gmail.com>]

Hello Andreas,

On Fri, Jun 21, 2013 at 10:15 AM, Andreas Tille <andreas@an3as.eu> wrote:

   /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

Thanks I will do it that way.

 

$ ./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.

That mean that the cursor has not initialized (has stayed None) , my bad I forgot to define cur as *global*, in my computer was working. Anyway I will avoid using *globals* in my code, I will change the existing code so we will avoid such problems. 

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

Yes I know that but for the moment I keep this argument cause it's easier for testing the script.

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

Ok I will make the --release argument optional and the default value will be "testing".

 

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

 

Ok, so for the moment I will go with the manual (or if no argument is passed I will the current architecture) 

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

No problem, I would love to make some research :-). As soon as we have a simple working blend-gen-control we can then customize it and bring it to the actual production needs.

 

             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.

If you also agree I can keep it simple for the moment and make a blend-gen-control to generate *one* control file(like the existing blends-dev) for a provided architecture, and once we have that we can organize how it will create the final source package?

Kind regards

Emmanouil