On Jan 4, 2012, at 3:11 PM, Henrik Ingo wrote: > >> - 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. >
As discussed in #drizzle, having errors print to stderr rather than /dev/null is fine, for now, but ideally should be removed before GA. >> - 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 > Right on… I think I was unclear as well. I thought that libdrizzle.so.* is the current libdrizzle, where libdrizzle-1.0* is for backward compat and should be packaged separately. Might need clarification from krow on that. > >>> 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. Currently, I think Fedora and RHEL 6 should be the only primary focus for RPM distros… once we get that squared away, and consistently building every release… then can work toward fixing EL5 if we want to (I personally don't care to support anything less than RHEL 6). > >> 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…) I'm onboard here. --- derks _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
