Thanks for feedback, good comments... On Wed, Jan 4, 2012 at 10:45 PM, BJ Dierkes <[email protected]> wrote: >> https://code.launchpad.net/~hingo/pkg-drizzle/drizzle7-dev.rpm > Some things to note: > > --- > > - Turns out --user and --daemon don't work well together, so have to use > sudo -u drizzle /usr/sbin/drizzled --daemon instead. > > We previously used sudo and had other issues which I can't recall now. > Changes like this should be noted very clearly that the change was made due > to a specific bug (with link to bug) … so that the change can be reverted > once the bug is fixed. >
Yeah, I appreciated that you had been diligent in doing this when trying to understand the spec file. I will correct my manners (now that the bug exists). > - Remove 2>&1 so that errors are shown to user. Currently all auth and > policy plugins will break drizzled due to installing broken stuff into > /etc/drizzle/conf.d/ so let's at least not silently fail. > > Init script should never output anything to console. If there init script is > failing to start a process, it is assumed the admin would attempt to run the > daemon manually to see whats happening. You have to remember, that in > general init scripts start processes on boot up … in which case you don't > want any output to console… so I think this should be reverted. > I realize I'm breaking against many regulations here, and didn't intend it to become permanent. There was someone on drizzle-operations list recently who did exactly this: installed all rpms, found out drizzled wouldn't start, didn't understand why, and did *not* know how to start the daemon himself, until advised by email. So I thought under the circumstances this would be a nice thing to do. If something is printed at startup, does bad things happen? Doesn't it just end up in syslog/messages? I agree that this should in any case be removed once we fix the config files so any plugin rpm can be installed without breaking drizzled. But if you really really insist that this is a bad thing, I can remove immediately. > - Upstream: libdrizzle-2.0 is no longer there. Package libdrizzle* now > contains libdrizzle-1.0. > > It was my understanding that 'libdrizzle' is version 2.0 … and libdrizzle-1.0 > is obviously only for backward compat… so I think that libdrizzle-1.0 should > be a separate package… along with libdrizzle-1.0-devel > Clearly I was unclear: make install does not do anything for libdrizzle-2.0 anymore. libdrizzle-1.0 is currently the one and only libdrizzle that we get. http://bazaar.launchpad.net/~drizzle-trunk/drizzle/development/revision/2465 >> 2) Where do you publish RPMs? >> >> lp:~drizzle-developers/pkg-drizzle/drizzle7-dev.rpm says: >> >> * Tue Nov 15 2011 BJ Dierkes <[email protected]> - 2011.11.29-1 >> - Latest sources from upstream. Release notes available at: >> https://launchpad.net/drizzle/fremont/2011-11-13 >> >> BJ: Where are these RPMs actually available??? They are not on >> rpm.drizzle.org. >> > > When a build actually completes (for all distros) then I would rsync the > repos to rpm.drizzle.org … that said, due to bugs and build failures on > different OS versions… I've not had a solid build in a while which is why the > repos are not up to date. > Ok, glad to help you out then. This should kind of work now, except that .conf files for plugins break it. I failed to build drizzle at all on Centos5, I don't know if it is intended to be supported anymore. > FWIW, I'm currently using our internal build system (Rackspace) to build > across all RPM distros (RHEL, Fedora). This made sense when the majority of > the Drizzle team were employed by Rackspace… but not so much anymore. We may > need to discuss how to handle this moving forward so that nobody is relying > on me solely for packaging RPMs. If we want to continue to use the same > system, its called MonkeyFarm and its Open Source .. > http://github.com/rackspace/monkeyfarm …. but I'd need at least two systems > to get it all setup and running. If we get hudson setup to do RPM builds and > tests for all RHEL/Fedora releases… then we can also just copy the built RPMs > from there and sync them to a repo to kill two birds with one stone. > My plan is to make package building part of the normal jenkins process. I already created a job that does make dist. This will make package building a first class citizen in CI, so that it should never be broken. (If something breaks packages, it should be fixed and then the patch is resubmitted.) A side effect that when we do a release, we can just copy the output of these jenkins jobs, nobody needs to build a release manually. (Automating stuff is what engineering is all about anyway...) henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
