IRC logs for #aegir, 2011-09-02 (GMT)

2011-09-01
2011-09-03
TimeNickMessage
[10:00:21]* obrienmd has joined #aegir
[10:01:04]<halcyonCorsair>omega8cc: so you install nginx via packages, and then compile and install again over the top?
[10:03:07]<omega8cc>we need to replace tomcat with jetty anyway, not sure why it is configured that way, it is probably some legacy post-testing stuff, along with some really old tomcat version, feel free to open an issue
[10:03:15]<omega8cc>yes
[10:09:32]* ryanarmstrong has quit (Quit: Leaving.)
[10:10:16]<halcyonCorsair>omega8cc: do you use any particular nginx 1.0 features, or is it just for the uploadprogress and cache purge modules?
[10:10:30]<halcyonCorsair>hmm, i'll put the tomcat bit on my todo list re: opening an issue
[10:11:45]* berniecram_ has joined #aegir
[10:16:24]<omega8cc>halcyonCorsair: see the barracuda changelog for reasons why we use recent nginx versions
[10:24:52]<halcyonCorsair>omega8cc: gah, my mission impossible -- trying to basically deconstruct/reconstruct BoA with puppet/debian packaged stuff to make our sysadmins happy
[10:25:49]<halcyonCorsair>omega8cc: re: nginx 1.0.5 and broken web based cron -- should be ok if i switch to drush cron, yes?
[10:26:49]* obrienmd has quit (Ping timeout: 245 seconds)
[10:27:57]* ivanjaros has quit (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
[10:36:59]<omega8cc>broken web based cron?
[10:46:43]* juampy has quit (Quit: Leaving)
[11:08:58]* boztek has joined #aegir
[11:10:54]<mig5>hey boztek
[11:11:10]<mig5>was it you who succeeded in automating a provision-migrate from cli and actually made it work?
[11:16:17]* Vertice has quit (Ping timeout: 252 seconds)
[11:18:54]<boztek>mig5: yeah we do provision-migrates almost every day
[11:19:07]<mig5>how do you handle the frontend 'catching up' with the change?
[11:19:14]<mig5>if you aren't using hosting-task @site migrate
[11:19:20]<mig5>or are you just using headless aegir
[11:19:21]<boztek>let me check - pretty sure i hosting-import the site
[11:19:32]<mig5>ok
[11:19:34]<boztek>and platform maybe
[11:19:36]<boztek>let me look
[11:19:44]<mig5>but if it is already there but on the previous platform in the frontend, the import would fail wouldn't it?
[11:22:20]<boztek>ok - dont judge my dodgy code and theres probably some unrequired things here but i'll paste some code in from my script - http://pastebin.com/jpvzMcwb
[11:23:31]<boztek>i have a function that will take a uri and if a site exists does a migrate otherwise does a new site provision
[11:23:37]<boztek>that's the migrate bit
[11:23:45]<mig5>oh sweet and it's even fabric :)
[11:23:47]<mig5>that's great, thanks
[11:24:09]<boztek>that script is triggerred from our jenkins on every git commit to the develop branch
[11:24:17]<mig5>that's what i'm about to roll out :)
[11:24:18]<boztek>and the dev server migrates
[11:24:34]<mig5>i do a similar thing but non-aegir, that auto-deploys to dev server , stage and even live
[11:25:10]<boztek>sweet - i have a jenkins button to build to a QA before deploying live but we are still doing "manual" aegir clicking to do live deploys
[11:25:19]<mig5>so i'm trying to understand how your site can import if it had the same URI as it was before
[11:25:22]<mig5>on the previous platform
[11:25:28]<mig5>i would have thought that import would fail 'site already exists'
[11:25:34]<mig5>or in fact, it just wouldn't spawn an import task at all
[11:26:05]<boztek>provision-migrate seems to work for me
[11:26:22]<boztek>we are on aegir 1.1 at mo
[11:26:33]<mig5>same here, but in the frontend the old site would still be seen as being on the old platform
[11:26:40]<mig5>i guess i should just try it :)
[11:26:51]<mig5>maybe something to do with after you change the alias and import, aegir just 'figures it out'
[11:26:57]* ezra-g has joined #aegir
[11:27:22]<boztek>it took some trial and error to get it going but have been using it since March with no major problems
[11:27:34]<mig5>that's great stuff: really appreciated, thanks
[11:27:39]* obrienmd has joined #aegir
[11:30:16]<boztek>np - you were of course the inspiration for such experiments
[11:31:11]* boztek needs a mig5 poster to put up to "inspire" everyone
[11:31:19]* Vertice has joined #aegir
[11:31:41]* jhedstrom has quit (Ping timeout: 240 seconds)
[11:32:19]<mig5>haha
[11:32:25]<mig5>i have long since fallen from grace..
[11:34:28]* FatGuyLaughing has joined #aegir
[11:35:07]* Vertice has quit (Client Quit)
[11:37:30]* ezra-g has quit (Quit: COD: The Conference Organizing Distribution. http://usecod.com)
[11:38:29]* obrienmd has quit (Quit: Leaving.)
[11:47:15]* ezra-g has joined #aegir
[11:50:50]<realityloop>can anyone help with how I would debug this error? An error occurred at function : drush_provision_drupal_provision_install_validate
[11:55:36]* realityloop has quit (Remote host closed the connection)
[11:56:16]* realityloop has joined #aegir
[11:58:34]* realityl_ has joined #aegir
[12:01:44]* realityloop has quit (Ping timeout: 268 seconds)
[12:06:31]* ezra-g has quit (Quit: ezra-g)
[12:07:25]* omega8cc has quit (Quit: Cheers! It's Time for Offline Reality)
[12:09:59]* Vertice has joined #aegir
[12:13:43]<halcyonCorsair>realityl_: hi
[12:13:52]<realityl_>halcyonCorsair: hiya
[12:14:06]* realityl_ is now known as realityloop
[12:15:52]<halcyonCorsair>realityloop: re: your drush_provision_drupal_provision_install_validate error did it say PROVISION_SITE_INSTALLED, or PROVISION_URL_REQUIRED?
[12:18:41]<realityloop>PROVISION_SITE_INSTALLED
[12:19:02]* ezra-g has joined #aegir
[12:19:13]* recidive has joined #aegir
[12:19:36]<realityloop>halcyonCorsair: ^
[12:20:35]* ezra-g has quit (Client Quit)
[12:22:40]<mig5>means the site is already in the platform
[12:22:47]<halcyonCorsair>realityloop: are you reinstalling a site or has this sitename previously existed? basically that error occurs when sites/<site.url.com>/settings.php exists
[12:23:24]<halcyonCorsair>mig5: can also mean that aegir failed to tidy up on removing a site, which can happen
[12:23:57]<mig5>sure
[12:24:30]<realityloop>halcyonCorsair: brand new site
[12:24:48]<realityloop>I did run retry after initial fail though
[12:24:53]<mig5>there you go
[12:25:11]<realityloop>deleting dir and retrying
[12:26:59]* ergonlog1c has joined #aegir
[12:27:05]<realityloop>Running: /usr/local/bin/php /usr/local/drush/drush.php --php=/usr/local/bin/php @ne.ld provision-install --backend
[12:27:05]<realityloop>The external command could not be executed due to an application error.
[12:27:05]<realityloop>The command could not be executed successfully (returned: PHP Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 78 bytes) in /usr/local/drush/includes/drush.inc on line 1360 , code: 255)
[12:27:06]<realityloop>An error occurred at function : drush_hosting_task
[12:27:23]<realityloop>ah memory lmit :/
[12:27:45]* ergonlogic has quit (Ping timeout: 258 seconds)
[12:42:39]<halcyonCorsair>realityloop: heh, memory limit of 256mb is a minimum these days, and things like OP even more
[12:43:04]<realityloop>OP?
[12:44:35]<mig5>openpublish
[12:44:40]<realityloop>ah
[12:46:22]* obrienmd has joined #aegir
[12:49:27]<realityloop>well my OS X install of aegir nginx is humming along nicely
[12:50:31]* acbot has joined #aegir
[12:50:31]* acbot has quit (Changing host)
[12:50:31]* acbot has joined #aegir
[12:51:53]<acbot>did drupal 7-8 break aegir platform verify?
[12:52:41]<realityloop>acbot: 7.8 installs work fine
[12:53:12]<acbot>bugger.. my platform verify fails
[12:56:34]<boztek>acbot: mine is broken too
[12:57:34]<acbot>boztek: you get this error: Drush command terminated abnormally due to an unrecoverable error. Error: Class 'Helper module for CronRunTestCase' not found in /var/aegir/.drush/provision/platform/drupal/packages_7.inc, line 97
[12:58:29]<acbot>realityloop: did you upgrade a codebase or checkout a new one then verify it in aegir?
[12:58:38]<realityloop>acbot: new
[12:58:42]<acbot>hrm
[12:58:47]<boztek>acbot: yup
[12:58:56]<realityloop>drush dl drupal-7.8, add platform, create site
[12:59:01]<acbot>boztek: ok good to know..
[12:59:06]<acbot>realityloop, yeh same here
[12:59:12]<acbot>except add platform fails
[12:59:19]<realityloop>worked for me
[12:59:23]<boztek>http://drupal.org/node/1266484
[12:59:23]<hefring>http://drupal.org/node/1266484 => Cannot verify Drupal 7.8 with PHP 5.2 => Provision, Code, normal, fixed, 7 comments, 2 IRC mentions
[12:59:26]<acbot>boztek: do you have some non core modules on that platform?
[12:59:36]<boztek>acbot: of course :)
[12:59:48]<acbot>ah that issue seems to be it
[13:00:38]<realityloop>I'm running php 5.3.8
[13:01:16]<boztek>realityloop: you run aegir on 5.3?
[13:01:20]<boztek>that would be why
[13:01:35]<realityloop>boztek: I am on my desktop
[13:05:07]<acbot>thanks guys - patch works nicely
[13:07:00]* kvanderw has quit (Read error: Connection reset by peer)
[13:13:30]* kvanderw has joined #aegir
[13:24:46]* AquaticDisorder has quit (Remote host closed the connection)
[13:33:24]* FatGuyLaughing has quit (Quit: FatGuyLaughing)
[13:35:01]<mig5>holy shit.
[13:35:17]<mig5>fuck me, Vertice is a clever bastard.
[13:35:23]<Vertice>am i ?
[13:35:27]<mig5>yeah
[13:35:37]<mig5>you arsehole!
[13:35:40]<Vertice>you sir, are a scholar and a gentleman
[13:35:42]<mig5>:)
[13:35:59]<mig5>i just had my third ever 'click' moment with aegir
[13:36:02]<mig5>over the last 2 years
[13:36:20]<mig5>and once again it's what you did with hosting-import
[13:36:49]<mig5>now i understand how boztek's stuff works http://pastebin.com/raw.php?i=jpvzMcwb
[13:37:00]<boztek>?
[13:37:09]<mig5>the hosting-import of the site, after migrate/deploy, refreshes the frontend so that it knows 'oh, this site got moved to the new platform somehow'
[13:37:12]<mig5>that was the part i was missing
[13:37:16]<boztek>right
[13:37:16]<mig5>hosting-import just takes care of it
[13:37:24]<mig5>this is HUGE.
[13:37:30]<mig5>now to get some money out of realityloop :)
[13:37:34]<boztek>so it basically does what we hoped it would … woooot
[13:37:37]<mig5>yeah
[13:37:51]<realityloop>wha?
[13:37:52]<mig5>i am not sure you need the provision-deploy though
[13:37:59]<boztek>yeah
[13:38:03]<mig5>provision-migrate runs the drush updatedb hook, as well as the backup in case you need it
[13:38:04]<boztek>i need to test without it
[13:38:27]<mig5>realityloop: so what we were talking about, is automatable after all, even with an aegir frontend on each server
[13:38:32]<realityloop>nice
[13:38:54]<mig5>means you can get jenkins to watch each stage in a git repo and auto-deploy new builds in each aegir environment
[13:39:02]<realityloop>how much it gonna cost? :P
[13:39:06]<mig5>:)
[13:39:08]* EclipseGc has joined #aegir
[13:40:23]* merro has quit (Ping timeout: 252 seconds)
[13:40:24]<mig5>i need to write down a plan for my prototype... part of it is porting my non-aegir implementation of this
[13:40:41]<mig5>fortunately for you, the 'how could this work' part is already done because of that
[13:40:48]<realityloop>cool
[13:41:53]* merro has joined #aegir
[13:47:52]* sk33lz has quit (Quit: Leaving.)
[13:55:45]<mig5>boztek: can i pick your brain a little longer?
[13:55:50]<boztek>sure
[13:55:53]<mig5>11:24 < boztek> that script is triggerred from our jenkins on every git commit to the develop branch
[13:56:00]<boztek>ya
[13:56:04]* kvanderw has quit (Quit: Computer has gone to sleep)
[13:56:05]<mig5>what exactly are you committing here
[13:56:10]<mig5>are you keeping a copy of platform as a repo?
[13:56:13]<mig5>as opposed to using drush make?
[13:56:19]<boztek>no - drush make
[13:56:40]<mig5>so let's say your app is drush make, core, plus contrib, plus some custom modules
[13:56:46]<mig5>what is the commit that would trigger it
[13:56:49]<mig5>an update to the makefile?
[13:57:19]<boztek>app source is basically install profile so any push to the develop branch will ping jenkins and start a build
[13:57:28]<boztek>including make file
[13:58:10]<boztek>i'll show you my dir structure - one sec
[13:59:24]<boztek>there you go
[13:59:45]<boztek>nothing you havent seen before
[14:02:38]* sk33lz has joined #aegir
[14:04:57]* EclipseGc has quit (Quit: EclipseGc)
[14:05:21]* EclipseGc has joined #aegir
[14:16:53]* bdiddy has left #aegir ()
[14:41:46]* Harley has joined #aegir
[14:48:27]* EclipseGc has quit (Quit: EclipseGc)
[14:51:31]* recidive has quit (Quit: zzz)
[14:57:18]* obrienmd has quit (Quit: Leaving.)
[15:08:34]* acbot has quit (Quit: Ex-Chat)
[15:12:59]* sk33lz has quit (Quit: Leaving.)
[15:15:40]* welly_ has joined #aegir
[15:22:00]* samhassell has joined #aegir
[15:43:59]* Aurorus has quit (Quit: Aurorus)
[15:48:31]<Vertice>oh right
[15:48:35]<Vertice>i got distracted earlier
[15:49:34]<Vertice>this shit is sooo much easier with nosql
[15:49:41]<Vertice>mig5: ^^
[15:56:16]<mig5>monbodb is web scale!!
[15:56:20]<mig5>mongo even
[16:11:01]<realityloop>whats the name of darthsteven's daemon module?
[16:11:23]<darthsteven>realityloop: http://drupal.org/project/hosting_queue_runner
[16:11:32]<realityloop>thanks mate
[16:11:42]<realityloop>adding it to OS X docs :P
[16:11:57]<darthsteven>cool
[16:12:41]<darthsteven>it doesn't have a launch.d script for it though, so unsure of what you want to suggest to people for how to run it
[16:12:56]<darthsteven>you can run it as a crush command, but then you have to remember to
[16:13:01]<realityloop>I'll try and make one and submit back to the project :)
[16:16:04]<darthsteven>awesome
[16:17:41]<realityloop>darthsteven: already noticed an error in docs
[16:17:59]<realityloop>unless dev is getting ready for it being included in hostmaster core?
[16:18:41]<realityloop>Install this module in your main hostmaster (Aegir) site. You can enable the feature from: `admin/hosting`. This will disable your hosting tasks queue for you, ready for you to enable the daemon.
[16:19:04]<realityloop>I had to enable it from /admin/build/modules
[16:20:24]<mig5>it ought to have a feature file then
[16:20:47]<realityloop>mig5: http://drupalcode.org/project/hosting_queue_runner.git/tree/refs/heads/6...
[16:21:14]<mig5>hmm
[16:21:21]<mig5>sure it wasn't in the collapsed 'experimental' section ?
[16:21:53]<realityloop>mig5: http://drupalcode.org/project/hosting_queue_runner.git
[16:22:13]<mig5>i mean in admin/hosting
[16:22:15]<mig5>on your site
[16:22:18]<realityloop>oh.. yes it is there
[16:22:49]<realityloop>I don't like that thats collapsed :/
[16:25:34]* scientist_ has quit (Ping timeout: 245 seconds)
[16:27:00]* v|work has joined #aegir
[16:27:27]<darthsteven>realityloop: me neither really
[16:27:34]<darthsteven>realityloop: Open an issue!
[16:27:40]<mig5>Patch! Patch!!
[16:27:41]<darthsteven>realityloop: file a patch!
[16:27:42]<mig5>:)
[16:27:44]<mig5>snap!
[16:27:54]<darthsteven>patches are welcome!
[16:28:12]* v|work is now known as vantage|work
[16:28:34]<realityloop>:P
[16:30:11]* lolmaus has joined #aegir
[16:33:08]* scientist_ has joined #aegir
[16:33:41]* Slydder1 has joined #aegir
[16:41:22]* skwashd has quit (Quit: No Ping reply in 180 seconds.)
[16:41:48]* skwashd has joined #aegir
[16:50:13]* waako- has joined #aegir
[16:52:36]* welly_ has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
[16:57:28]* waako- has quit (Quit: Bye!)
[16:57:49]* waako has joined #aegir
[16:59:46]* berniecram_ has quit (Quit: berniecram_)
[17:11:39]<darthsteven>mig5: you still there?
[17:20:07]* merro_ has joined #aegir
[17:20:33]* merro has quit (Ping timeout: 268 seconds)
[17:20:33]* merro_ is now known as merro
[17:25:32]* waako is now known as waako|
[17:36:09]* merro has quit (Ping timeout: 252 seconds)
[17:36:57]* roflmaus has joined #aegir
[17:37:23]* merro has joined #aegir
[17:45:54]* roflmaus has quit ()
[17:52:13]* dob_ has joined #aegir
[17:53:51]* siliconmeadow has joined #aegir
[17:57:32]* Artusamak_afk is now known as Artusamak
[17:59:16]* amateescu has joined #aegir
[18:10:28]* vantage|work has quit (Quit: ChatZilla 0.9.87 [Firefox 3.6.21/20110830092825])
[18:17:18]* boztek has quit (Quit: Computer has gone to sleep.)
[18:21:23]* vantage|work has joined #aegir
[18:40:02]* realityloop has quit (Remote host closed the connection)
[18:40:51]* realityloop has joined #aegir
[18:43:16]* sdrycroft has joined #aegir
[18:46:22]<romaingar>hop
[18:49:32]* realityloop has quit (Remote host closed the connection)
[18:49:53]* realityloop has joined #aegir
[18:53:15]* sdrycroft has quit (Quit: Leaving.)
[19:03:01]* sdrycroft has joined #aegir
[19:05:59]* grugnog has quit (Ping timeout: 252 seconds)
[19:08:01]* sdrycroft has quit (Quit: Leaving.)
[19:11:11]* grugnog has joined #aegir
[19:11:49]* waako| is now known as waako||
[19:16:39]* sdrycroft has joined #aegir
[19:22:09]* samhassell has quit (Quit: Leaving)
[19:25:51]* AquaticDisorder has joined #aegir
[19:28:42]* Fuzzy76 has joined #aegir
[19:29:11]<Fuzzy76>Has there been any kind of user account sync integration with Aegir or is that something I should use with "normal" modules?
[19:30:41]<darthsteven>Fuzzy76: what do you mean by 'user account sync integration'?
[19:32:01]* waako|| has quit (Ping timeout: 252 seconds)
[19:32:14]<Fuzzy76>syncing of user accounts, basically :) hopefully also syncing fields added to users
[19:32:50]<Fuzzy76>bakery had som syncing for d6, but it isn't present in the d7 port
[19:34:28]* grugnog has quit (Ping timeout: 240 seconds)
[19:35:49]* waako has joined #aegir
[19:36:33]* grugnog has joined #aegir
[19:38:28]* realityloop has quit (Remote host closed the connection)
[19:40:58]<lolmaus>My linux box has died, but the HDD seems to be fine. Installed Ubuntu Server on another box. I now have to configure Aegir from scratch and import backups.
[19:41:04]* lolmaus T_T
[19:58:11]* AquaticDisorder has quit (Remote host closed the connection)
[20:03:06]* eugenmayer has joined #aegir
[20:10:10]* dob_ has quit (Remote host closed the connection)
[20:15:24]* beautifulmind has joined #aegir
[20:45:13]* mikl has joined #aegir
[20:48:14]* lolmaus has quit ()
[20:52:40]* dob_ has joined #aegir
[20:59:04]* ClemensTolboom has joined #aegir
[21:03:33]* lolmaus has joined #aegir
[21:03:53]* ClemensTolboom has quit (Client Quit)
[21:04:38]<lolmaus>Do Aegir and Nginx come along?
[21:06:16]<lolmaus>Aegir on Ubuntu repositories?! RADICAL!
[21:08:25]* beautifulmind1 has joined #aegir
[21:09:52]* beautifulmind has quit (Ping timeout: 258 seconds)
[21:10:45]* beautifulmind has joined #aegir
[21:12:38]* beautifulmind1 has quit (Ping timeout: 240 seconds)
[21:12:53]<lolmaus>Hey mig5, aptitude says i ain't got "aegir", but there's a package "aegir-provision". But it is not the full aegir, right?
[21:15:49]* omega8cc has joined #aegir
[21:15:55]<lolmaus>Hey omega8cc
[21:16:26]<omega8cc>lolmaus: hi
[21:16:58]<lolmaus>omega8cc, i've installed Ubuntu Server 10.04 on a dedicated box and i would like to install Aegir with Nginx. I've never used Nginx before and there are things i don't quite understand. Could you please help?
[21:18:22]<omega8cc>lolmaus: sure, just use: http://drupal.org/project/barracuda and http://drupal.org/project/octopus
[21:18:32]<lolmaus>omega8cc, both of them?
[21:18:42]<omega8cc>yes
[21:18:49]<lolmaus>omega8cc, do i need Apache if i'm using Nginx?
[21:18:55]<omega8cc>no
[21:20:01]<lolmaus>omega8cc, do i have to install both Aegir Master and Aegir Satellite on the same machine to obtain a basic Aegir environment?
[21:21:02]<omega8cc>no, Master is enough, but Satellite includes many improvements out of the box and the good practice is to avoid using Master
[21:21:49]<lolmaus>omega8cc, so to use a good practice i need both Master and Satellite on the same machine? And Barracuda+Octopus correspond?
[21:21:56]<omega8cc>yes
[21:23:03]<lolmaus>omega8cc, i'm installing that at work. But i have also got a linux box at home. I would like to use the home box as a backup system. Should i install Aegir Satellite on it?
[21:23:06]<omega8cc>Octopus is plugged into Barracuda and you can create more Satellite instances on the same server, hence the Octopus name
[21:23:45]<omega8cc>you can't install Octopus w/o Barracuda
[21:24:05]<lolmaus>omega8cc, oh i see
[21:24:41]<lolmaus>omega8cc, but can Aegir handle more than one server? For example, copy sites from one to the other
[21:25:31]<omega8cc>sure, Aegir can use remote passive heads, but BOA is unrelated to Aegir master/remote head concept
[21:26:14]<lolmaus>omega8cc, oh, now i seem to understand. :)
[21:26:29]<lolmaus>omega8cc, should i use "sudo su" prior to installing Barracuda?
[21:26:39]<omega8cc>BOA doesn't support remote stuff out of the box, however some folks already use it with remote heads
[21:27:03]<omega8cc>it is explained at the top of README.txt :p
[21:27:24]<omega8cc>read the docs first
[21:30:07]<eugenmayer>mig5: i benchmarked the whole clone / migrate process, which currently all goes down to deploy ( i fixed backup before ). Looks like the biggest impact has clear.6.inc
[21:31:12]<eugenmayer>eg updatedb always does a cc, no matter it has updates or not ( in numbers, it needs 7s without and 32s with cc)…but we repeat that cc 2 times after that, which is just waste i guess
[21:33:21]<eugenmayer>also, we menu_rebuild, which is not really needed. We could clear the cache using menu_cache_clear_all or cca(cache_menu)
[21:34:13]<eugenmayer>but one of the biggest flaws is the automatic node_access_rebuild, which is a huge impact ( 50% ) on the whole process
[21:35:38]<eugenmayer>i cant see a single reasons to actually just trigger this at all. This should be triggered by the admin when he visits the site or something - this can take up to 1hour depending on the installation ( e.g. a install of us with 10k nodes with taxonomy_access, content_access and node_access takes about 1 hour )
[21:36:01]<darthsteven>eugenmayer: agreed
[21:36:10]<darthsteven>eugenmayer: where is the code that starts that?
[21:36:35]<eugenmayer>http://drupalcode.org/project/provision.git/blob/HEAD:/platform/drupal/c...
[21:37:15]<omega8cc>eugenmayer: I think you could maintain the remote stuff development, as the folks who have written this stuff are no longer involved, while you seem to use it and have enough experience to co-maintain
[21:37:30]<mig5>I agree ^^
[21:37:47]<eugenmayer>omega8cc: actually i already forked aegir, dont think this is a good idea i maintain it
[21:37:49]<mig5>it is nice to have eugenmayer back with constructive views :) i welcome any patches you want to provide
[21:37:54]<eugenmayer>(private forked ofc)
[21:38:06]<mig5>you don't have to fork it though :)
[21:38:39]<mig5>this area is such a sore point in terms of performance, I am keen to see what you can do to improve it
[21:38:57]<omega8cc>eugenmayer: it is better to co-maintain than to fork, imo
[21:39:51]<eugenmayer>mig5: well, i fear i repeat myself the 10th time, but you guys do not focus on remotes at all ( which is not that bad ) - but you also dont have any interest in a progress in this ( which is not that bad either ), but you dont even dare to help a bit on that field with questions arround aegir provision in general, to help me kick start those things. This is just not a really fair trade to me - not have been in the past - which kind of
[21:40:18]<mig5>eugenmayer: it is not really like that: as omega8cc said, the original authors of this area of the code have abandoned the project
[21:40:21]<mig5>we are on our own like you
[21:40:43]<eugenmayer>i know that devseed is gone
[21:41:01]<mig5>and you came in at a shaky time. it is clear you have some good thoughts here, and i think we welcome an overhaul of the 'multiserver' stuff as it's been proven that it doesn't really work
[21:41:19]<omega8cc>plus it was not devseed who wrote the remote stuff
[21:41:30]<mig5>no it wasn't, not really
[21:41:30]<eugenmayer>oh, wasnt aware of that
[21:41:39]<mig5>it was adrian + the guys from pantheon/mercury
[21:41:43]<mig5>and none of us grok it
[21:42:06]<omega8cc>that is the truth
[21:42:13]<mig5>'i cant see a single reasons to actually just trigger this at all. This should be triggered by the admin when he visits the site or something' << this sounds reasonable to me
[21:42:21]<mig5>so long as it doesn't actually 'fail' a migration, sure
[21:42:51]<eugenmayer>well iam bearing with the whole "remote deployment" for some time already. My deeply thoughts about this is - thats the wrong tool for it
[21:43:19]<mig5>can we 'conditionally' rebuild things like menu depending on if there are changes needed. not sure we can detect that
[21:43:26]<lolmaus>Installing Barracuda. The progress indicator has stopped rotating. Is that bad?
[21:43:26]* waako is now known as waako|
[21:44:06]<omega8cc>lolmaus: at which step?
[21:44:06]<eugenmayer>that whole remote story should have never happened in aegir in my eyes, neither any deployment. Building, verifying and managing should be aegir, phing or whatever ( capistrano ), and sure let capistrano use drush
[21:44:24]<eugenmayer>mig5: we dont need this, but actually drupal detects this on its own
[21:44:40]<mig5>yes. i have been doing a lot of work with Jenkins + fabric in a similar capistrano style, to handle deployment between 'standalone' aegir servers
[21:44:44]<mig5>and it works better that wya
[21:44:45]<eugenmayer>mig5: you surely now this "your node acess permissions need to be rebuild message"
[21:44:46]<mig5>way*
[21:44:50]<lolmaus>omega8cc Install/upgrade required libraries and tools
[21:44:55]<mig5>yeah
[21:44:55]<lolmaus>Yay! It goes on!
[21:44:59]<lolmaus>Sorry for impatience
[21:45:14]<eugenmayer>mig5: that is the API way to tell drupal "you need to rebuild" and that can be our flag we look for
[21:45:35]<mig5>sure, as some sort of drush post hook even.. maybe
[21:45:51]<eugenmayer>i think thats just a var, let me check
[21:46:49]<eugenmayer>mig5: http://api.drupal.org/api/drupal/modules--node--node.module/function/nod...
[21:46:58]<mig5>oooh
[21:46:58]<mig5>nice
[21:47:11]<eugenmayer>so that is pretty triviali guess
[21:47:33]<mig5>'This can be used as an alternative to direct node_access_rebuild calls, allowing administrators to decide when they want to perform the actual (possibly time consuming) rebuild.'
[21:47:34]<darthsteven>eugenmayer, mig5: we do maintain the remote server stuff, which is different from the cluster server stuff, which we don't
[21:47:36]<mig5>hahah
[21:47:52]<mig5>darthsteven: well, we 'maintain' it all technically :)
[21:47:55]<mig5>except we don't
[21:48:04]<darthsteven>eugenmayer, mig5: We would welcome patches of the remote server stuff
[21:48:09]<darthsteven>I'd review them
[21:48:10]<eugenmayer>darthsteven: to be honest, i took those days to apply all the needed patches from my base (0.9) to 1.3
[21:48:17]<mig5>but i agree with eugenmayer here: the multiserver stuff was designed as a 'spoke' model which is not working
[21:48:23]<darthsteven>and commit them
[21:48:39]<darthsteven>mig5: yes, it works in some ways
[21:48:49]<mig5>it is slooooow, i've seen that myself
[21:49:01]<darthsteven>mig5: doing 'master-master' is a major pain though
[21:49:05]<mig5>eugenmayer suggests that as opposed to refactor it to 'mesh' model, we should not even bother trying to handle multiserver
[21:49:09]<mig5>and there is merit in that
[21:49:16]<eugenmayer>darthsteven: with that steps, i took a look at all patches applied on the code according to remotes and there is, iam not sure, a single field addressed of the bugs i know and fixed. Those bugs are very obvious and i think the reason you did not find / fix them is simply, because you dont use remotes
[21:49:20]<mig5>maybe the only 'multi server' stuff should be clusters
[21:49:25]* Slydder1 has quit (Quit: Leaving.)
[21:50:06]<darthsteven>eugenmayer: nope, I do use remotes
[21:50:26]<darthsteven>mig5: Maybe, but we'd need to get better at pushing/pulling sites between Aegir masters
[21:50:31]<eugenmayer>then, when you really use it with 1.3 you are _very_ patiente_ and you dont drive bigger installations
[21:50:36]* merro_ has joined #aegir
[21:51:03]<darthsteven>eugenmayer: pretty much. You can pop files in a symlink, which saves a lot of time
[21:51:09]<mig5>darthsteven: i think there are other tools that can handle that, like jenkins.. there doesn't need to be aegir master > aegir master... both masters can be told by something like jenkins, to pull from git for example
[21:51:11]* merro has quit (Ping timeout: 240 seconds)
[21:51:12]* merro_ is now known as merro
[21:51:19]<eugenmayer>there are a gazzilion bugs in remotes in 1.3 .. they never apear with local-master deployment, because of the special fact, that "building" and "deploying" is exact the same location
[21:51:40]<eugenmayer>its more specific, the same directory, which "fixes" a lot of bugs
[21:51:48]<eugenmayer>that is also database related
[21:51:52]<darthsteven>eugenmayer: provide patches and they'll get fixed, promise!
[21:52:30]<eugenmayer>iam fully covering mig5 opinion
[21:52:32]<darthsteven>mig5: maybe, but we still need a simple way of moving sites around, Jenkins powered or not
[21:52:40]<mig5>sure
[21:52:43]<mig5>i am building that product :)
[21:52:48]<mig5>all powered by one Webform :)
[21:53:12]<eugenmayer>freaking dont touch transport - thats a total complex fields. There is specialized software for that which we shall use. That software cares about "taking that app", installation it, and verifying that
[21:53:13]<mig5>i've been doing it for a while without aegir: today i built an aegir prototype that actually works
[21:53:28]<eugenmayer>and the most freaking important part, rollbacking _properly_ and staging properly
[21:53:44]<mig5>well you treat staging as another 'deployment', separate environment
[21:53:54]<eugenmayer>all build in, tested, and app-undipendent. Sure, capistrano will learn to ultilize drush here, but hey, thats a lot less work
[21:54:10]<eugenmayer>mig5: well thats not the same
[21:54:21]<eugenmayer>lets say, you finished development - looks fine.
[21:54:32]<eugenmayer>You want to "update/ upgrade" the live site, so you migrate
[21:54:53]<eugenmayer>but it freaks out ( there are several reasons here, it can happen ) .. and with aegir, you can have anything from
[21:55:04]<eugenmayer> - completly broken site, which needs to be _imported_ again
[21:55:16]<eugenmayer> - just fixing creds and importing DB manually
[21:55:26]<eugenmayer> - applying a backup
[21:55:42]<mig5>sure, but surely you do that in a staging environment first, not live
[21:55:44]<mig5>and you get it right
[21:55:48]<mig5>so that live works, after that :)
[21:55:48]<eugenmayer>and thats all on the "old live site" which is down until you recognise that all, because the rollback did "work fine"
[21:56:23]<eugenmayer>yeah, you migrated stage before and it worked
[21:56:35]<eugenmayer>those "issues" you get on migration are not code-related ( app-code )
[21:56:51]<eugenmayer>i give you one example, which ends up with a huge mess
[21:57:11]<eugenmayer>login into your remote and chown a directory to root:rooo 200 in sites/yousite
[21:57:16]<eugenmayer>migrate that site.
[21:58:34]<mig5>heh
[21:58:51]<lolmaus>Barracuda installation is loooong
[21:59:11]<eugenmayer>darthsteven: when you use remotes, how do you handle "files" ?
[21:59:28]<darthsteven>eugenmayer: symlinks
[21:59:52]<eugenmayer>so that symlink is parth of the tar and gets reapplied after it?
[22:00:09]<darthsteven>eugenmayer: yup, you just move symlinks around
[22:00:14]<darthsteven>eugenmayer: rather than the files
[22:00:15]<eugenmayer>thats one way - clone that site on your dev server
[22:00:19]<eugenmayer>"kaboom."
[22:00:19]<omega8cc>lolmaus: it takes about 30 minutes on vps like Linode
[22:00:28]<darthsteven>eugenmayer: sure
[22:00:32]<darthsteven>eugenmayer: it's a workaround
[22:00:40]<eugenmayer>yeah, but a clever one, i admit
[22:00:54]<darthsteven>eugenmayer: the node_access rebuild code has been removed
[22:01:01]<darthsteven>eugenmayer: we only do it if needed now
[22:01:01]<eugenmayer>with this approach, staging gets unusable though
[22:01:13]<eugenmayer>darthsteven: wonderful,pathed it on my install already
[22:01:14]<lolmaus>omega8cc, i'm trying to guess how long it'd take if i did everything manually
[22:01:15]<darthsteven>eugenmayer: I suspect we did actually fix some of the issues you raised
[22:01:23]<eugenmayer>darthsteven: no you did not :)
[22:01:45]<eugenmayer>darthsteven: i have check a lot of code the last to days because i was hunting 2 bugs
[22:02:23]<eugenmayer>Really, remotes are very broken, Thats not my way offending, its just a honest way to tell you that
[22:02:43]<darthsteven>eugenmayer: agreed. We can fix them
[22:02:44]<omega8cc>lolmaus: manually 2 x longer, probably, or 3 x or even a few hours if you don't know all related stuff well
[22:02:53]<darthsteven>eugenmayer: and if people choose not to use them, fine
[22:03:43]<eugenmayer>darthsteven: yeah, i was kind of fooled ( or mabye i simple not read the docs enaugh ) - thinking that aegir handles remotes fine when started with aegir
[22:03:53]<lolmaus>Yay! It finished! What do i do now?
[22:04:18]<mig5>we did fix several eugenmayer bugs :)
[22:04:23]<mig5>i mean, we committed your patches
[22:04:25]<eugenmayer>darthsteven: otherwise i would have tested it first and looked into the code - and never would have chosen aegir then.
[22:04:30]<omega8cc>lolmaus: run Octopus, but read all config options! ;)
[22:04:38]<darthsteven>eugenmayer: Awesome!
[22:04:41]<lolmaus>omega8cc, roger
[22:04:55]<eugenmayer>mig5: i know, the one you applied rather had nothing to do with remotes
[22:05:37]<mig5>i know, i'm just pointing out, the 'aegir world' is not against you :)
[22:05:48]<mig5>and we don't mind if you had never 'chosen aegir' either
[22:05:53]<mig5>but you are welcome to help us fix bugs
[22:06:00]<eugenmayer>never thought that - you just fight in a different war :)
[22:07:00]<eugenmayer>aegir is cool, but it goes beyond what is meaningfull :)
[22:07:10]<omega8cc>eugenmayer: I think it is time to get involved seriously, it would be the best option, because you seem to be the best candidate to maintain this remote mess I never even looked at ;)
[22:08:15]<lolmaus>omega8cc, i don't understand the options in Octopus config. What's the difference between My email and Client email?
[22:09:26]<omega8cc>your e-mail is the machine admin/root e-mail and client e-mail is the expected satellite admin e-mail
[22:09:41]<eugenmayer>omega8cc: well, before i get involved anyway, i will need to clear out some basic stuff. Iam not sure you guys want to focus on "enterprise deployment" at all, but rather on the mass-drupal-cms hosting thing, which has its difference ( on huge difference is the meaing of site/<yoursite>/ data, which has some key decisions arround it). Why that is important? Because aegir 1.3 is useless to me the way it has be decided to work ( not on
[22:10:14]<eugenmayer>Its not bad it works, it is maybe just a different approach
[22:10:21]<eugenmayer>*not bad how it works
[22:10:32]<darthsteven>eugenmayer: We're up for major refactoring for the 2.x branch
[22:10:42]<eugenmayer>i know
[22:10:58]<darthsteven>eugenmayer: but we need to talk through the issues first, rather than jumping into something
[22:11:20]<eugenmayer>darthsteven: but there are some huge key-issues which you dont seem to address right now. One of them is the "rollback" issues of "forked" processes.
[22:11:29]<lolmaus>omega8cc, ERROR: This script should be used only when the same version of BARRACUDA was used before.
[22:11:38]<darthsteven>eugenmayer: d.o issue link for that?
[22:12:12]<eugenmayer>darthsteven: there is none directly, i have posted that as a small comment below an issue which is AFAIK closed ( maybe a wontfix dont remember )
[22:12:33]<eugenmayer>darthsteven: you can try it yourself, create 2 drush commands A and B. create rolbacks for each of them
[22:12:50]<eugenmayer>call drush_backend_invoke B in A and let it fail
[22:13:01]<darthsteven>eugenmayer: okay...
[22:13:04]<eugenmayer>B rollbacks - A just fails and does not rollback
[22:13:19]<darthsteven>eugenmayer: where is that an issue in Aegir?
[22:13:25]<omega8cc>eugenmayer: I think it is also the Drupal community problem, as Dries believes it is now more and more enterprise stuff, while in fact both 'soho' and 'enterprise' approach can and should co-exist
[22:13:29]<eugenmayer>Sounds like "who need that"…but think about how how nested the calls are in aegir
[22:13:46]<eugenmayer>i bet you got a process-callstack arround 4 or 5 in migrate
[22:14:03]<eugenmayer>darthsteven: one issue is rollback of deploy in migrate
[22:14:59]<omega8cc>lolmaus: sounds like you didn't install Barracuda properly?
[22:15:16]<darthsteven>eugenmayer: that should be a simple fix then? Just raise an error in the migrate command where it calls drush_backend_invoke?
[22:15:25]<lolmaus>omega8cc, i used the stable install script. It installed with no error. How do i investigate the issue?
[22:16:11]<omega8cc>lolmaus: open an issue and pastebin your install log displayed on screen
[22:16:12]<eugenmayer>omega8cc: jap, they can. But both sides need to do compromises. One issues on the enterprise side is, that we, providing enterprise solutions, are not always the one dictating needs, those are customers. So sometimes the "enterprise" side cant move, because those customers are to big - they will not change ( e.g. company political reasons ). So thats were i see the core-issue .. the enterprise guys always seem to be "ego"
[22:16:29]<eugenmayer>darthsteven: no, thats rather an drush issues then an aegir issue
[22:16:59]<eugenmayer>it is just a very important one for aegir due to the things aegir does. Deployment, test, verify,
[22:17:08]<lolmaus>omega8cc, ah! Barracuda installed with error!
[22:17:32]<eugenmayer>those tasks can fail and then you need to rollback the whole chain darthsteven, and thats maybe just a real hard architectural limit of drush
[22:17:42]<lolmaus>omega8cc, "This server does not have a hostname that resolves to an IP address". My bad!
[22:17:42]<eugenmayer>(yet, 4.x)
[22:19:07]<eugenmayer>darthsteven: i dont think other drush apps really have that size aegir has and that "task" driven approach. Tasks can file and be nested, so the "maint task" must fail and rollback all "childs" .. that concept is missing completely, drush never ment to be that i suppose
[22:19:07]<darthsteven>eugenmayer: but I just outlined a possible fix?
[22:19:08]* Irishgringo has joined #aegir
[22:19:32]<lolmaus>omega8cc, "uname -n" and "hostname" do provide a hostname resolvable into a public ip address
[22:19:38]<darthsteven>eugenmayer: but the parent task can just detect that it should fail, and rollback at that level?
[22:19:56]<omega8cc>eugenmayer: yeah, there is a reason why big enterprises never generate any real innovation (or kills it early) so it is hard to balance with the world of small/young start-up-like mentality we probably prefer in Drupal so far
[22:20:20]<eugenmayer>darthsteven: i dont think so , thats a workarround not working generally. You dont know exactly at which point your processes can fail an how to reroll them - you dont know their "childs" and all this, so you need to kind of manually propagate a rollback
[22:20:51]<eugenmayer>in both directions, up and down. Getting this done without building it into the architecture isa huge task
[22:21:25]<darthsteven>eugenmayer: I'm totally not following, if each drush task takes care of rolling itself back, then there shouldn't be an issue?
[22:21:26]<eugenmayer>omega8cc: i think enterprise change enormously the last couple of years ( esp the last 3 years )
[22:21:48]<omega8cc>lolmaus: well, where are you installing it? on a vps or locally?
[22:22:05]<darthsteven>eugenmayer: if task A only cares if task B succeeds or fails, then its easy?
[22:22:27]<lolmaus>omega8cc, local dedicated linux box. It runs Ubuntu Server 11.04 and has two LAN interfaces: one for local network and one with a public IP address.
[22:22:43]<eugenmayer>omega8cc: i expect enterprise to become one of the innovators in software in the next years - it is already that case for or market, not overall. But as soon as "desktop application" dissapear, it will change more globally
[22:23:07]<eugenmayer>darthsteven: A -> B -> C -> D + F + G
[22:23:28]<eugenmayer>A does not know what to do up there, every task needs to cleanup
[22:23:38]<omega8cc>lolmaus: then please read *all* config comments/option before you will try it again :/
[22:24:04]<darthsteven>eugenmayer: right, so suppose that F 'fails'. C rolls back, B rolls back, A rolls back. Done
[22:24:27]<eugenmayer>darthsteven: maybe iam blind here, iam open to the an approach here. Drush is huge - i dont have an oversight about its capabilties, it also has changed a lot with 4.x and 5.x
[22:24:27]<darthsteven>eugenmayer: is this *actually* a problem in Aegir?
[22:24:44]* yolgezer has joined #aegir
[22:24:47]<eugenmayer>darthsteven: yes, esp if C calls 3 tasks in a row
[22:24:56]<eugenmayer>which all fork, and the last one fails
[22:25:07]<lolmaus>omega8cc, should i edit the barracuda installation script and run it again? Any cleanup necessary?
[22:25:09]<darthsteven>eugenmayer: we don't fork within a task though
[22:25:16]<eugenmayer>now C MUST care about calling rollback ann all 2 before and on C itself. That is forgotten a lot
[22:25:39]<omega8cc>eugenmayer: not sure, it is more about culture (and the scale) of organization than technology - some things just don't work in a big scale
[22:25:53]<eugenmayer>darthsteven: hmm, you are sure? clone .. drush_backend_invoke backup … provision-save .. provision-deploy ..
[22:26:08]<eugenmayer>omega8cc: agreed
[22:26:19]<darthsteven>eugenmayer: hmmm...so you're saying that if Task A calls Task B and then Task C, if Task C fails then we need to rollback Task B too?
[22:26:36]<eugenmayer>sure you need, in aegir terms, you need
[22:26:40]<eugenmayer>at least when you do migrate / clone
[22:27:14]<eugenmayer>you end up with funny database leftovers, users still residing in the database eventhough the site never gots deployed ( actually they stay forever then )
[22:27:35]<eugenmayer>i could not even fix this issue myself yet - i simply cant get the right context for DB rollback
[22:28:10]<eugenmayer>but - i applied some patches to db.drush.inc / mysql.servervice.inc you guys created and currently it seems the issue may be gone
[22:28:17]<omega8cc>lolmaus: it is better to start from scratch, especially when you don't have any experience with it yet
[22:28:27]<omega8cc>lolmaus: oh wait
[22:28:43]<omega8cc>ftp.drupal.org is down!
[22:28:47]<eugenmayer>darthsteven: in my opinion, aegir missues drush here
[22:28:48]<omega8cc>crap
[22:29:02]<eugenmayer>darthsteven: drush is a wonderful tool - a huge lovely one
[22:29:27]<omega8cc>lolmaus: maybe it is another reason why it failed for you
[22:29:34]<eugenmayer>darthsteven: but we should not use it to control logic about deploy, stage, verify, rollback - thats what special software is for like capistrano
[22:29:56]<eugenmayer>darthsteven: aegir should be the "brain", the manager, the trigger, the UI, the real tool to master all this
[22:30:10]<darthsteven>eugenmayer: Aegir is drush + Drupal. If you don't agree with that there are plenty of other tools
[22:30:17]<darthsteven>eugenmayer: which you seem to be aware of
[22:30:41]<eugenmayer>darthsteven: iam not sure we should really go the route to say
[22:30:55]<eugenmayer>"use aegir as is, or take capistratno"
[22:31:15]<eugenmayer>capistratano lacks a lot of things aegir can do and drush can do
[22:31:32]<lolmaus>omega8cc, but it complained about hostname not being resolved.
[22:31:39]<eugenmayer>but it is also the other way arround. I expect those being a wonderful combination. Then including something like ActiveMQ
[22:31:45]<lolmaus>omega8cc, is it okay to have _MY_HOSTN and _MY_FRONT the same?
[22:31:51]<eugenmayer>(like anarcat suggested in the past )
[22:31:54]<lolmaus>I don't understand the difference
[22:32:35]<darthsteven>eugenmayer: well, we can bikeshed about that any time
[22:33:00]<eugenmayer>darthsteven: if you undestand me right, eventhough i got fixed 90% of all bugs i ran into, i would tend to say, dont fix aegir in this point, replace that part with a new solution
[22:33:36]* scientist_ has quit (Ping timeout: 250 seconds)
[22:33:52]<eugenmayer>not because capistrano has a buy-in - but those guys focus full-time on what we fail to do properly and they dont care about all the things we do - perfect symbioses.
[22:34:00]<omega8cc>well, we plan to manage Wordpress sites, DNS, (I plan to implement Textpattern multisite), we can use Jenkins etc, so I don't see we are in any Drupal+Drush only jail
[22:34:08]<lolmaus>omega8cc, maybe i should set _DNS_SETUP_TEST=NO ?
[22:34:15]* scientist_ has joined #aegir
[22:34:23]<eugenmayer>omega8cc: read it several times already - what is Jenkins?
[22:34:47]<omega8cc>new name of Hudson
[22:34:53]<eugenmayer>ah, i remeber
[22:35:01]<eugenmayer>but hudson does not have any transport or?
[22:35:14]<eugenmayer>Usuaully you use capistrano + jenkins, or?
[22:35:45]<eugenmayer>(yet, hudson was "stage, test, verify" for me)
[22:36:24]<omega8cc>yes, it is great for automated testing
[22:36:39]* Harley has quit (Ping timeout: 272 seconds)
[22:38:08]<omega8cc>but there is no real workaround to the major Drupal flaw, which is lack of any kind of *content* dev/stage/prod workflow
[22:38:24]<eugenmayer>hehe
[22:38:27]<eugenmayer>Dont tell me..
[22:38:34]<omega8cc>so all those great tools are great to only some degree - code development only
[22:38:46]<omega8cc>all the rest is just a pure crap
[22:38:57]<omega8cc>no uuids etc
[22:39:09]<eugenmayer>well we use feature a lot
[22:39:16]<eugenmayer>also a lot exportables / uuid API
[22:39:38]<eugenmayer>as we large-scale maintain customers with same "software modules" ( features )
[22:39:47]<eugenmayer>it PITA from step 1 to step <last>
[22:39:54]<omega8cc>I never understood that, anyway, how anyone could believe it is a *CMS* when you basically can't *manage* the content
[22:40:25]<omega8cc>they are all workarounds, not solutions (features etc)
[22:40:40]<omega8cc>but we all know that well
[22:40:47]<eugenmayer>well with proper extending modules, you can live "ok" with those workarrounds
[22:41:15]<eugenmayer>we export taxonomies, nodeacces, filters, permissions, roles and a lot more with own integrations
[22:41:30]<eugenmayer>not the one you find with feature / fe / features_bonus. And it kind of works
[22:41:57]<eugenmayer>but the major issues of code / configruation / content separation is there - no doubt
[22:42:44]* ivanjaros has joined #aegir
[22:43:22]<omega8cc>it is an awful bundle of hacks/workarounds, only because it was not done properly from the start, but who could expect it will grow that big ;)
[22:44:50]<eugenmayer>omega8cc: mig5: darthsteven: this months i cannot do any work for aegir as a project. Iam fixing my stuff now and then we need to finish a project all our resources are bound to. Maybe, if there is interest, we can talk in october if the interests or the "aegir mission" can be a superset of what we critically need and what the community needs. If thats happen to be i could think of of way how we handle those issues we talked about a g
[22:48:26]* beautifulmind1 has joined #aegir
[22:49:18]* spyd has joined #aegir
[22:50:09]* beautifulmind has quit (Ping timeout: 245 seconds)
[22:50:38]<eugenmayer>darthsteven: i really missed that the node_access_rebuild thing alrady got fixed.
[22:50:47]<eugenmayer>(a long time ago actually)
[22:51:46]<omega8cc>eugenmayer: any good ideas are welcome, but patches are even more welcome :) Join the party!
[22:52:12]<omega8cc>we are all in the same boat anyway
[22:53:08]<eugenmayer>not quiet correct :)
[22:53:30]<eugenmayer>darthsteven: you might consider not to call menu_rebuild but rather just clearing the cache
[22:53:55]<darthsteven>eugenmayer: file the patch!
[22:54:12]<omega8cc>:)
[23:03:17]<eugenmayer>Importing database using command: mysql --defaults-file=/dev/fd/3 newkundenkontext [32.89 sec, 9.19 MB]
[23:03:40]<eugenmayer>that import takes 12s, while doing a drush sqlc < database.sql does take < 3s on the host locally
[23:04:12]<eugenmayer>(thats a small database, i expect this effect being a lot larger on live sites, i just have a small demo here, rather tiny )
[23:04:32]<eugenmayer>lets see if i can get his working locally
[23:05:49]* EclipseGc has joined #aegir
[23:10:21]* Irishgringo has quit (Remote host closed the connection)
[23:11:34]<omega8cc>over 4 hours of downtime? wtf? http://twitter.com/#!/search/ftp.drupal.org
[23:12:41]<eugenmayer>omega8cc: buutttt ftp.drupal.org now supports rsync :)
[23:12:44]<eugenmayer>(scp)
[23:14:56]<joestewart>just to chime in a little about aegir, drush, capistrano, etc. msonnabaum said in his Drupalcon presentation that he used Capistrano as a reference while designing and building drush deploy.
[23:18:14]<eugenmayer>drush deploy, is that something 5.x related?
[23:18:52]<eugenmayer>anybody has a clue why
[23:19:00]* waako| is now known as waako||
[23:19:15]<eugenmayer>drush @myalias < /var/pathtodump does just stall when calling it with $this->server->shell_exec($cmd)
[23:19:27]<omega8cc>http://london2011.drupal.org/conference/sessions/drush-deploy
[23:19:39]<eugenmayer>but works just fine when i htop to the dest host, coping the cmd ine of the stalled process and run it locally
[23:20:32]<eugenmayer>joestewart: omega8cc: interesting!
[23:21:06]* q-rban is now known as q0rban
[23:21:33]* ergonlog1c has quit (Ping timeout: 252 seconds)
[23:23:24]<joestewart>eugenmayer: project is http://drupal.org/project/drush_deploy and code is in there.
[23:26:38]* univate has joined #aegir
[23:27:00]* Brandonian has joined #aegir
[23:29:32]<eugenmayer>joestewart: that looks awesome interesting!!
[23:31:09]* kvanderw has joined #aegir
[23:32:14]* scientist_ has quit (Ping timeout: 240 seconds)
[23:35:02]<eugenmayer>joestewart: iam yet not sure what they do in profile install / DB / permission / creds wise, so next to "file transport"
[23:35:33]<eugenmayer>but if they do, that would be a holy-shit-awesomesouce addition to aegir.
[23:45:28]<eugenmayer>they even mention aegir as a deploy strat
[23:45:41]* berniecram_ has joined #aegir
[23:53:15]* waako|| is now known as waako
[23:53:19]* lukus has quit (Read error: Operation timed out)
[23:55:32]<eugenmayer>darthsteven: you defo want to look at drush_deploy when thinking about remotes with aegir
[23:55:55]<eugenmayer>i just looked at the screencast and they addressed a lot of things i pathed in in aegir and a lot of things would be a lot easier
[23:56:20]<eugenmayer>the idea would be, just interface drush deploy for the site setup / very and also rollback, so removing all this code from aegir
[23:56:26]* ergonlogic has joined #aegir
[23:57:00]<eugenmayer>we will still need to implement some logic for what we want to do before / after a site, we would need to add some tasks for multisite but as far as a can see, that is very generic
[23:57:12]<eugenmayer>and very simple to extend.
[23:58:06]* ergonlogic has quit (Client Quit)
[23:58:15]* ergonlogic has joined #aegir
[00:01:22]* boztek has joined #aegir
[00:03:24]* FatGuyLaughing has joined #aegir
[00:04:19]* snlnz has quit (Read error: Connection reset by peer)
[00:04:55]* snlnz has joined #aegir
[00:07:22]* ezra-g has joined #aegir
[00:09:15]* lukus has joined #aegir
[00:10:01]* merro has quit (Quit: merro)
[00:12:37]* berniecram_ has quit (Quit: berniecram_)
[00:16:29]* scottalan has joined #aegir
[00:17:49]* waako is now known as waako|
[00:25:33]* obrienmd has joined #aegir
[00:38:14]* scientist_ has joined #aegir
[00:53:15]* dob__ has joined #aegir
[00:55:35]* obrienmd has quit (Quit: Leaving.)
[00:56:00]* dob_ has quit (Ping timeout: 260 seconds)
[00:56:39]<eugenmayer>just if anybody listens, benchmarked "remote database dump import" like aegir default is doing
[00:56:57]<eugenmayer>and it is very slow when you dont have 100MBit ( sorry dedicated to dedicated )
[00:57:35]<eugenmayer>also, out of any reasons, the platform gets synced everytime, even if no files have been changed
[00:58:25]<eugenmayer>omega8cc: didnt you address this rsync issue ( do only diff rsync ) ?
[01:02:40]<omega8cc>eugenmayer: as far as I remember, none of my hacks were committed, but I was sure it was fixed anyway, or we got some regression maybe? weird..
[01:03:23]<eugenmayer>omega8cc: hmm
[01:03:52]<eugenmayer>hmm, maybe iam wrong
[01:04:08]<eugenmayer>http://pastebin.com/mCLWqyz6
[01:04:43]<eugenmayer>the only issue is, that calculation of "what change" takes 99s
[01:04:58]<eugenmayer>that actually can be perfectly the time for completly transfering those files
[01:05:43]<eugenmayer>-azv --stats --progress --relative --keep-dirlinks --times --omit-dir-times --delete is used
[01:05:53]<omega8cc>or the fact that there is "Number of files: 10673"
[01:06:35]<omega8cc>it is not that high, but if network is slow, then it may matter
[01:06:58]<omega8cc>however 99s is still far too long
[01:07:14]<eugenmayer>i see, —times is not used in current HEAD
[01:07:27]<eugenmayer>omega8cc: its a developer, 16Mbit
[01:07:37]<eugenmayer>(well yeah, deployer is a dedicated 1GBit
[01:07:56]<eugenmayer>16mbit, 1.5MB/s sould be just fine for this
[01:08:20]<omega8cc>so disk I/O performance maybe?
[01:08:38]<eugenmayer>well, "yes"
[01:08:51]<eugenmayer>its an vm, Mac AIR ( not the current one =
[01:09:14]<eugenmayer>but the laptop is idling right now. Well i can verify that it is not IO myself with other servers, thats up to me
[01:09:43]<eugenmayer>coming back with this if that cannot be IO related ( i mean remote server IO, not network traffic IO)
[01:14:05]<eugenmayer>--
[01:14:16]<eugenmayer>another thing which is buggin me is the implementation of "local db import"
[01:14:16]<eugenmayer>http://pastebin.com/J9ZV2HXr
[01:14:34]<omega8cc>hmm.. so this rsync is not run in quiet mode? it will then send back the progress info etc, which is useless, no? so why there is --stats --progress anyway, instead of -q ?
[01:15:13]<omega8cc>do we parse it or something?
[01:15:18]<eugenmayer>that alias is on the remote, its created, the command is called, i can see the process (htop) on the remote, but still it seems to be stalled. copieing the line and executing it on the remote works perfectly
[01:15:28]<eugenmayer>omega8cc: no, thats related to --debug
[01:15:36]<omega8cc>ah
[01:15:41]<eugenmayer>so i have to benchmark it withtout it i guess, that makes sense
[01:16:29]<eugenmayer>i bet that is kind of related to the pipe..
[01:16:37]<eugenmayer>(sql dump issue)
[01:20:21]* vantage|work has quit (Quit: ChatZilla 0.9.87 [Firefox 3.6.21/20110830092825])
[01:22:18]<omega8cc>eugenmayer: probably, you could see the difference when running remotely only web head and database locally to the hostmaster, if that is fast (it should) then sql dump over the network is a source of the pain
[01:26:01]* waako| is now known as waako||
[01:26:14]* CitizenKane has quit (Ping timeout: 258 seconds)
[01:27:52]* recidive has joined #aegir
[01:30:59]* siliconmeadow has quit (Ping timeout: 245 seconds)
[01:35:43]* CitizenKane has joined #aegir
[01:37:16]<eugenmayer>omega8cc: well db remote is one source of pain, thats for sure
[01:37:24]<eugenmayer>123seconds for a 15MB dump
[01:37:54]<eugenmayer>localy and the remote, it takes less then 10 seconds - so thats 100% no disk i/o issue, thats the way it is done
[01:38:20]<eugenmayer>i finally found out why my command is stuck, its the extra \ before my pipe.. \<
[01:38:32]<eugenmayer>but drush escapes thats, i cant stop it :/
[01:38:41]<omega8cc>uh
[01:40:35]<eugenmayer>it uses escapeshellcmd
[01:41:33]<eugenmayer>and out of any reason
[01:41:50]<eugenmayer>drush sqlq —input-file="file.sql" does not work at all with drush .. not even locally
[01:41:53]<eugenmayer>no idea why
[01:48:42]<eugenmayer>omega8cc: hehe, sqlq is wrong document...
[01:48:45]<omega8cc>hmm, why not drush sqlc < file.sql ?
[01:48:50]<eugenmayer>its not working
[01:49:11]<eugenmayer>it gets escaped to drush sqlc \< file.sql
[01:49:15]<eugenmayer>it that stalls
[01:49:20]<omega8cc>you need sqlc, not sqlq, no?
[01:49:33]<eugenmayer>drush sqlq —input-file=file.sql
[01:49:42]<eugenmayer>shoudl work, but its not implmented that way
[01:49:53]<eugenmayer>drush sqlq —file=file.sql
[01:50:10]<eugenmayer>wrong argument description + wrong example .. but the code told me more
[01:50:47]<omega8cc>I think that drush sqlc < file.sql should fast, no?
[01:51:27]<omega8cc>should be*
[01:52:59]<eugenmayer>yes, but it wont work that easy, wait, seems i did not make it clear
[01:53:20]<eugenmayer>ssh myhost 'drush @myallias sqlc < foo.sql'
[01:53:22]<eugenmayer>that would work
[01:53:35]<eugenmayer>but when you run this with drush_shell_exec you end up having
[01:53:36]* recidive has quit (Quit: zzz)
[01:53:47]<eugenmayer>ssh myhost 'drush @myallias sqlc \< foo.sql'
[01:53:53]<eugenmayer>and thats not working
[01:54:00]<eugenmayer>thats why i use —file now
[01:54:16]<eugenmayer>which is 99% the same as < foo.sql, but just adds the pipe internally
[01:55:17]<eugenmayer>(was that clear? :)
[01:55:44]<eugenmayer>*not working === process stals ( i expect the pipe not working, so its waiting for stdin
[01:57:52]* juampy has joined #aegir
[02:12:15]<omega8cc>hmm, so it escapes that <
[02:12:17]<omega8cc>fail
[02:13:38]<omega8cc>drush_shell_exec should be smart enough to not escape this, imo
[02:14:21]<eugenmayer>well thats a different issue i guess
[02:16:41]* beautifulmind1 has quit (Quit: Leaving.)
[02:19:04]<juampy>how could I verify a remote/local site from command line? I am not sure if "drush @site_name hostmaster-verify" is the right one.
[02:24:08]<eugenmayer>no
[02:24:16]<eugenmayer>provision-verify
[02:24:22]<eugenmayer>or waiit, a site?
[02:25:10]<eugenmayer>i dont think thats possible, only the platform
[02:25:49]<eugenmayer>or no, its the site
[02:25:51]<eugenmayer>so
[02:25:57]<eugenmayer>drush @yoursitealias provision-verify
[02:30:21]<EclipseGc>looking for a little drush expertise
[02:30:44]<EclipseGc>if I don't want my drush stuff in ~/.drush what's the next place to put it (say… system wide) and how?
[02:38:35]* recidive has joined #aegir
[02:46:37]* steveoliver has joined #aegir
[02:50:12]* sdrycroft has quit (Quit: Leaving.)
[02:51:00]* eugenmayer has quit (Quit: Leaving.)
[02:55:13]<lolmaus>I have failed installing Octopus. I want to retry it for the same domain. How do i clean up?
[02:56:48]* steveoliver has quit (Quit: Colloquy for iPhone - http://colloquy.mobi)
[03:02:24]<lolmaus>Also, Octopus installation says MySQL password rejected. Where does it store the password?
[03:02:54]<lolmaus>So that i reenter it
[03:10:17]* waako|| is now known as waako|||
[03:15:03]* ergonlogic has quit (Quit: leaving)
[03:15:13]* ergonlogic has joined #aegir
[03:15:35]* AquaticDisorder has joined #aegir
[03:18:14]* sk33lz has joined #aegir
[03:19:41]* amateescu has quit (Quit: Leaving)
[03:25:58]* eugenmayer has joined #aegir
[03:26:38]<eugenmayer>Hello. Is there any particular reason why we resync the platform on every ingoing site migration? Does not make any sense to me, esp for multi-sites. I think thats what platform-verify is?
[03:29:13]<eugenmayer>i think this is just a "fogotten" dep of the provision_drupal_sync_site call
[03:29:24]<eugenmayer>which does not only sync the site, but the platform also, which is rather confusing
[03:35:12]* guaka_ has joined #aegir
[03:36:45]* dob__ has quit (Remote host closed the connection)
[03:38:11]<eugenmayer>hrm, is provision-install for a platform or a site, hmm
[03:38:29]* guaka has quit (Ping timeout: 245 seconds)
[03:44:56]<lolmaus>Hey eugenmayer, could you please help me a little?
[03:45:32]<lolmaus>eugenmayer, i'm trying Octopus install script but it complains ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
[03:45:46]<lolmaus>How do i debug this? How do i change the password?
[03:46:03]<lolmaus>I've set root to accept connections from any host but this didn't help
[03:46:09]<eugenmayer>iam really clueless what octopus does
[03:46:10]* obrienmd has joined #aegir
[03:46:18]<lolmaus>Oh
[03:46:31]<eugenmayer>i remember it is the nginx+extra stack developmed by omega8cc, but iam using a classic LAMP stack
[03:46:34]<eugenmayer>so never installed it
[03:46:46]<lolmaus>eugenmayer, but this is general Aegir issue... Where does it store mysql root password?
[03:47:08]<eugenmayer>hostmaster/sites/yourhostmasterdomain/drushrc.php
[03:47:27]<eugenmayer>(for the hostmaster)
[03:47:51]<eugenmayer>that is for the cli, and for the webserver, its in conf/yourserver/apache/vhost.d/yoursite
[03:48:08]<eugenmayer>(its included in /youplatform/sites/yoursite/settings.phü
[03:48:37]<eugenmayer>lolmaus: just a very important hint to you
[03:48:55]<eugenmayer>aegir is _very_ restrictive what comes down to user-access permissions to the database
[03:49:09]<eugenmayer>it is always based on _hosts_, not only user/password
[03:49:30]<eugenmayer>so when you connect from the wrong host with the right user/ permssion you get denied
[03:49:54]<lolmaus>eugenmayer, but i've seet mysql root to accept any host
[03:49:57]<eugenmayer>that e.g. is important when you change aegirs main domain or hostname…that makes brakes those permissions
[03:50:21]<eugenmayer>Sorry, no idea. There could be a gazzilion issues.
[03:50:37]<lolmaus>eugenmayer, i ain't got hostmaster yet
[03:51:33]<eugenmayer>does not matter a lot
[03:51:52]<lolmaus>I used Barracuda to installed part of Aegir. It succeeded. Then i should've installed Octopus, but it failed with this mysql access error
[03:52:21]<lolmaus>So i just dunno what to do :(
[03:52:56]<eugenmayer>i dont even know what Barracuda / Octopus is
[03:53:03]<eugenmayer>maybe you wait for someone else or first
[03:53:15]<eugenmayer>start with a LAMP stack, and when you got the idea, move on to nginx
[03:53:34]<eugenmayer>(i remember you never used the nginx stack yet, so maybe it is just to much new at the same time)
[03:53:38]<lolmaus>eugenmayer, i had been using Aegir on a LAMP stack successfully.
[03:53:55]<lolmaus>eugenmayer, yeah i've never used Nginx yet
[03:58:18]<lolmaus>eugenmayer, but this is not an Nginx issue
[04:03:13]* juampy has quit (Read error: Operation timed out)
[04:14:19]* guaka_ has quit (Ping timeout: 245 seconds)
[04:15:57]* ergonlogic has quit (Quit: Lost terminal)
[04:42:21]* lolmaus has quit ()
[04:51:53]* mrconnerton has joined #aegir
[05:08:37]* waako||| is now known as waako||||
[05:12:22]* psynaptic is now known as psynaptic|away
[05:22:29]* noecc has left #aegir ("pax")
[05:32:28]* Dobuntu has joined #aegir
[05:38:29]* yolgezer has quit (Ping timeout: 252 seconds)
[05:44:52]* jhedstrom has joined #aegir
[05:48:04]* mrconnerton has quit (Ping timeout: 245 seconds)
[05:48:04]* mrconnerton_ has joined #aegir
[05:54:59]<wizonesolutions>So sorry to be a pain but I just want to get this straight. "Profile" and "distribution" in the Aegir sense can simply mean "Drupal site that's been built for a client." Doesn't necessarily imply something that is going to be released to the public.
[05:56:19]<Dobuntu>Hi everyone. I am thinking about setting up Aegir on my Ubuntu 10.04 box. I have read that I need to downgrade to php 5.2 however when I print phpinfo() I see that my php is already 5.2.10.2ubuntu6. Will that work or do I need a different php installation?
[05:57:38]<Dobuntu>#wizonesolutions, in the context of Drupal, the profile may refer to an 'Installation profile'
[05:57:41]<obrienmd>Dobuntu: that should work
[05:58:21]<Dobuntu>Thanks obrienmd!
[05:58:41]<wizonesolutions>Dobuntu: Yeah, I'm familiar with Drupal but new to Aegir and have been trying to make sure I have my head wrapped around deploying sites. Planning to develop locally and use a dev/stage/live workflow. And this seems to be the recommended way to do so.
[05:58:56]<Dobuntu>same here ;-)
[05:58:57]<wizonesolutions>e.g. build platforms/drush make files and migrate sites to the new codebase
[05:59:40]* romaingar has quit (Ping timeout: 252 seconds)
[05:59:40]<Dobuntu>Good luck to use both!
[05:59:48]<Dobuntu>us both that is
[06:05:05]* ruif13 has joined #aegir
[06:05:27]<ruif13>hi,
[06:05:38]<ruif13>please anyone can help install the aegir in mint?
[06:07:19]* juampy has joined #aegir
[06:10:50]<joestewart>wizonesolutions: the meaning of distribution to me would be the equivalent of the full download of an installation profile on d.o. ( the -core.tar.gz ones). Doesn't imply anything about releasing it.
[06:11:07]* Brandonian has quit (Quit: Brandonian)
[06:12:53]* obrienmd has quit (Quit: Leaving.)
[06:13:56]<ruif13>hi again , please i'm trying to install aegir in mint
[06:14:47]<ruif13>and i made the steps to 6
[06:14:55]<ruif13>of http://community.aegirproject.org/node/400
[06:15:20]<ruif13>and i'm stoped at shell with a msg "please wait..."
[06:16:06]<ruif13>it's ok? i need to wait about 10 minutes?
[06:16:12]<ruif13>or more?
[06:17:15]<ruif13>fatal error :(
[06:20:07]<ruif13>thanks
[06:26:15]* ezra-g is now known as ezra-g|brb
[06:32:18]<ruif13>anyone can help?
[06:32:21]<ruif13>please..
[06:37:25]* ezra-g|brb is now known as ezra-g
[06:44:48]<ruif13>helllo?
[06:44:52]<ruif13>anyone help?
[06:47:12]* omega8cc has quit (Quit: Cheers! It's Time for Offline Reality)
[06:49:20]<joestewart>ruif13: I probably won't be much help, but from above it appears you have the repo's available in mint OK. made it to step 6. don't understand "fatal error :(" though.
[06:49:54]<ruif13>hi joestewart
[06:50:01]<ruif13>before all thanks for your reply
[06:50:08]<ruif13>ysp
[06:50:13]<ruif13>hum
[06:50:25]<ruif13>gona check ;) that repositorys
[06:52:16]<ruif13>this is the http://pastebin.com/1rd3gV84
[06:52:39]<ruif13>i reeinstall tru synamptic
[06:54:52]<joestewart>ruif13: you'll need to do some things in the terminal. pastebin results of "ls -l /var/aegir"
[06:56:04]<ruif13>http://pastebin.com/Aid1spkr
[06:58:09]<ruif13>joestewart http://pastebin.com/Aid1spkr
[06:59:00]<joestewart>ruif13: yes, it did not install the front end. thinking what you should do next.
[06:59:25]* mrconnerton_ has quit (Ping timeout: 260 seconds)
[07:01:30]<joestewart>ruif13: I guess the first would be step 7 for troubleshooting. In root user's terminal - "env DEBUG=yes apt-get install aegir"
[07:05:42]<ruif13>yap appears all installed :S
[07:06:46]<ruif13>no prob joestewart i go forgot that
[07:07:26]* q0rban has quit (Remote host closed the connection)
[07:08:19]* ryanarmstrong has joined #aegir
[07:17:34]* Artusamak is now known as Artusamak_afk
[07:17:52]* mrconnerton_ has joined #aegir
[07:18:40]* mrconnerton_ is now known as mrconnerton
[07:18:50]* waako|||| is now known as waako|||||
[07:40:43]* waako||||| is now known as waako||||||
[07:41:12]<ivanjaros>is it known what is the most websites run on aegir and who runs them?
[07:44:13]* ezra-g has quit (Quit: COD: The Conference Organizing Distribution. http://usecod.com)
[07:47:57]* psynaptic|away is now known as psynaptic
[07:48:17]* jhedstrom has quit (Ping timeout: 252 seconds)
[07:50:48]* scientist_ has quit (Ping timeout: 258 seconds)
[07:54:31]* macrocosm has joined #aegir
[08:04:04]* psynaptic is now known as psynaptic|away
[08:08:49]* Irishgringo has joined #aegir
[08:15:20]* FatGuyLaughing has quit (Quit: FatGuyLaughing)
[08:18:05]* Artusamak_afk is now known as Artusamak
[08:21:11]* amateescu has joined #aegir
[08:27:54]<Dobuntu>Over at the Aegir community docs for installing on Ubuntu 10.04 (http://bit.ly/nUHzRz) it says we need to downgrade to php5.2. My system is already using a 5.2.10 version of php however the packages in my /etc/apt/preferences.d/php file are have 'Pin: release a=karma' as opposed to the stated 'Pin: version 5.2.10*' Is this likely to be an issue?
[08:28:29]* amateescu has quit (Quit: Leaving)
[08:31:20]* merro has joined #aegir
[08:32:29]* waako|||||| has quit (Quit: Leaving...)
[08:37:21]* obrienmd has joined #aegir
[08:51:06]<macrocosm>Anyone having clone issues after applying this change to /platform/drupal/packages_7.inc ? http://drupal.org/node/1266484
[08:51:07]<hefring>http://drupal.org/node/1266484 => Cannot verify Drupal 7.8 with PHP 5.2 => Provision, Code, normal, fixed, 8 comments, 3 IRC mentions
[08:59:28]* sk33lz has quit (Quit: Leaving.)
[09:09:46]<macrocosm>oh nice .. now I see your warning on twitter :/ lol ...still I was able to verify d-7.8 after the change ... its possible my clone issues are unrelated too
[09:10:43]* EclipseGc has quit (Quit: EclipseGc)
[09:12:37]* ruif13 has quit (Quit: Leaving.)
[09:15:08]* yolgezer has joined #aegir
[09:18:13]* EclipseGc has joined #aegir
[09:18:32]<recidive>hey guys, can someone tell me what's so different in drush/aegir installer that makes an install profile breaks to install
[09:18:43]<recidive>it looks like it doesn't respect the order of things
[09:19:49]<recidive>e.g. fields that are created in hook_enable() are not accessible, e.g. when you need to set a permission based on that field
[09:20:22]<recidive>anyone can help me? I'm not willing to add workarounds all around in my code, but rather find the real source of the problem
[09:22:09]* psynaptic|away is now known as psynaptic
[09:26:59]* Vertice has quit (Read error: Connection reset by peer)
[09:27:33]* psynaptic is now known as psynaptic|away
[09:29:00]* obrienmd has quit (Quit: Leaving.)
[09:34:09]* kvanderw has quit (Quit: Computer has gone to sleep)
[09:44:24]* sk33lz has joined #aegir
[09:45:05]* psynaptic|away is now known as psynaptic
[09:48:29]* sk33lz has quit (Ping timeout: 245 seconds)
[09:58:37]* recidive has quit (Quit: zzz)
[09:58:54]* yolgezer has quit (Ping timeout: 245 seconds)