Hello Andreas,
On Fri, Jun 21, 2013 at 10:15 AM, Andreas Tille <[email protected]> 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
