| # | Time | Nick | Message |
|---|
| # | 01:22:05 | b_bonner_ has joined #evergreen |
| # | 01:24:45 | b_bonner has quit IRC |
| # | 01:24:46 | b_bonner_ is now known as b_bonner |
| # | 02:22:56 | twofish has quit IRC |
| # | 02:28:23 | twofish has joined #evergreen |
| # | 02:42:01 | bjwebb has quit IRC |
| # | 02:55:32 | bjwebb has joined #evergreen |
| # | 07:56:28 | mrpeters-isl has joined #evergreen |
| # | 08:16:42 | sfortin has joined #evergreen |
| # | 08:19:32 | rserey has joined #evergreen |
| # | 08:33:05 | AaronZ-PLS has joined #evergreen |
| # | 08:41:15 | dbs has joined #evergreen |
| # | 08:41:15 | dbs has joined #evergreen |
| # | 08:46:49 | guest has joined #evergreen |
| # | 08:51:15 | Dyrcona has joined #evergreen |
| # | 09:01:52 | Meliss has joined #evergreen |
| # | 09:09:10 | kmlussier has joined #evergreen |
| # | 09:09:48 | jenny1 has joined #evergreen |
| # | 09:17:52 | yboston has joined #evergreen |
| # | 09:25:10 | dbwells | really basic git question here: If I want to checkout another user's branch from 'working', but have never pushed anything to 'working' or checked out anything from there before, do I need to do a 'git fetch working' first? It seems so, but I want to be a little more sure before I update the wiki. |
| # | 09:25:45 | dbwells | This is of course after adding the remote, but before doing a checkout. |
| # | 09:25:45 | tsbere | dbwells: You have to git fetch whatever for any remote repo, in general. |
| # | 09:26:00 | tsbere | You can grab all your remotes at once with git fetch --all |
| # | 09:26:23 | tsbere | But if you don't fetch you will be running on your local copy, not the updated version. (git pull does an automatic fetch, though) |
| # | 09:29:46 | tsbere | phasefx: I had considered trying to figure out grace period on backdated checkin when I did "grace periods in the db", but I couldn't find any evidence that had happened in 1.6 on so I didn't bother fighting with it then. |
| # | 09:30:22 | dbwells | tsbere: thanks. The 'Working Repos' section of the wiki doesn't mention 'fetch' at all. I'll add it to the the 'To track these repositories' section for those of us completely new to git. |
| # | 09:36:04 | RBecker has quit IRC |
| # | 09:38:45 | RBecker has joined #evergreen |
| # | 09:39:19 | dbs | huh. http://pastebin.ca/2068379 (maybe more tweaking of reporter.old_super_simple_record required, sigh) |
| # | 09:40:35 | tsbere | dbs: I think the issue is the NULL inside of the arrays. In particular, they are arrays with a single NULL value.....would have to look at the generating queries to say more about why though. |
| # | 09:40:41 | dbs | tsbere: I know |
| # | 09:40:53 | tsbere | arrays can be picky about when they accept nulls |
| # | 09:40:57 | tsbere | I forget the whole ruleset |
| # | 09:41:57 | tsbere | I think I ran into that at one point in an early test of fallthrough on 8.4, though, so I don't think it is just postgres 9.0 |
| # | 09:42:44 | dbs | currently isbn and issn are built in the view with array_accum(DISTINCT replace("substring"(isbn.value, '^\\S+'::text), '-'::text, ''::text)) AS isbn |
| # | 09:43:43 | tsbere | So some entry has a null value or two. Hmmm. |
| # | 09:47:03 | dbs will hack at this later today |
| # | 09:52:23 | dbs | huh, array_agg() returns NULL, while array_accum() returns {}. Think I'll try cutting over to array_agg() for those definitions. |
| # | 09:55:33 | tsbere | array_accum was probably from the 8.3 and earlier days. array_agg came about in 8.4. |
| # | 09:59:38 | KN2W has joined #evergreen |
| # | 10:00:09 | dbs | Right. I guess I'm surprised that nobody else ran into this |
| # | 10:00:19 | dbs casts a baleful glance at his customized upgrade script |
| # | 10:03:55 | tsbere | Looks like 5 uses of array_accum in master, and no uses of array_agg. Should they all be replaced with the builtin now? |
| # | 10:16:40 | bshum | Huh, hadn't ever noticed that. |
| # | 10:41:27 | dbwells | grabbing 0539 |
| # | 10:44:19 | jamesrf has quit IRC |
| # | 10:49:10 | eeevil | dbs / tsbere: builtin FTW, IMO ... and othe acronyms |
| # | 10:49:56 | moodaepo_ has joined #evergreen |
| # | 10:59:39 | mrpeters-isl | shouldn't i be able to checkout just a specifc tag from git? I'm using git://git.evergreen-ils.org/Evergreen.git/refs/heads/tags/rel_2_0_4 and getting "fatal" The remote end ung up unexpectedly" |
| # | 11:00:22 | gmcharlt | mrpeters-isl: an SVN tag become a branch in Git |
| # | 11:00:41 | gmcharlt | mrpeters-isl: the clone is always just of the repo - i.e., git clone git://git.evergreen-ils.org/Evergreen.git |
| # | 11:01:07 | gmcharlt | to switch branches, you can (depending on the particular version of Git you're running) either do |
| # | 11:01:15 | gmcharlt | git checkout tags/rel_2_0_4 |
| # | 11:01:18 | gmcharlt | or do |
| # | 11:01:43 | gmcharlt | git branch --track rel_2_0_4 tags/rel_2_0_4; git checkout rel_2_0_4 |
| # | 11:02:00 | mrpeters-isl | ok |
| # | 11:02:05 | csharp | okay - for phasefx eeevil berick or others who may know... I have a question about the "grace period" in Evergreen |
| # | 11:02:36 | csharp | the "grace period" as I understand it, is not really a grace period, but a consequence of when fines are being calculated |
| # | 11:02:36 | tsbere | mrpeters-isl: Or git clone -b tags/rel_2_0_4 <url> |
| # | 11:02:47 | Dyrcona | csharp: other who may know would include tsbere and myself. |
| # | 11:02:54 | csharp | Dyrcona: ah good |
| # | 11:02:58 | mrpeters-isl | yeah, im kind of cheating and doing this with TortoiseGit |
| # | 11:02:59 | tsbere | csharp: Grace period varies from version to version of evergreen now. |
| # | 11:03:01 | mrpeters-isl | so its a GUI |
| # | 11:03:07 | mrpeters-isl | but i got it to do what i need |
| # | 11:03:31 | tsbere | csharp: Thus, which version you looking at? |
| # | 11:03:34 | csharp | in 1.6 and forward, fines are calculated the day of, not the night of the first overdue day, correct? |
| # | 11:03:39 | csharp | tsbere: 1.6.1.8 |
| # | 11:03:53 | kmlussier has quit IRC |
| # | 11:04:03 | csharp | is my understanding of the grace period being a fluke of sorts correct? |
| # | 11:04:11 | csharp | (at least initially)? |
| # | 11:04:16 | tsbere | csharp: Grace period in 1.6 is still based on "when do you run the fine generator cron job, and what do you pass into it?" |
| # | 11:04:38 | tsbere hasn't looked at 1.6 too closely, though, he knows 2.0/2.1 better |
| # | 11:04:41 | Dyrcona | csharp: fines caculated at checkin time don't have a grace period in 1.6. |
| # | 11:05:10 | csharp | Dyrcona: right - that's what we're seeing (and having to explain to our libraries) |
| # | 11:05:23 | Dyrcona | csharp: as tsbere said, the fine generator uses the grace period given to it. |
| # | 11:05:25 | csharp | so the grace period (as expected behavior) returns in 2.0? |
| # | 11:05:47 | csharp looks up the PINES cron jobs |
| # | 11:06:14 | Dyrcona | csharp: not sure. I know in 2.1 it can be configured in the circ_matrix_matchpoint if you're using indb circ and checkins, etc. will use that value. |
| # | 11:06:34 | csharp | ohhh I see what you're talking about |
| # | 11:06:36 | tsbere | In 2.0 (or at least later versions thereof) use the 1.6 method with a "generate on checkin" as well. The on checkin has been patched to only generate non-daily fines. |
| # | 11:06:52 | tsbere | Hourly fines in 2.0 never have a grace period. |
| # | 11:07:13 | tsbere | 2.1 moves the grace period off of the cron job and into the db |
| # | 11:07:37 | tsbere | Either on the recurring fine rule (script based or indb) or overridden by the matchpoint (indb only) |
| # | 11:08:28 | tsbere | That makes grace periods work at checkin as well as from cronjob regardless of fine interval |
| # | 11:08:34 | csharp | okay our cron entry is: 30 0 * * * . /etc/profile && /openils/bin/fine_generator.pl /openils/conf/opensrf_core.xml /tmp/generate_fines-LOCK 1 |
| # | 11:09:12 | Dyrcona | csharp: you're using 1 day with the fine generator. |
| # | 11:09:18 | csharp | hmm |
| # | 11:09:49 | csharp | ah - it looks like the issue is just with backdated checkins |
| # | 11:09:56 | eeevil | csharp: so, grace period is not a fluke, it's intentional, and in all released versions it works the same way (with the exception of a bug in 2.0 which is fixed in the release 2.0.6) |
| # | 11:10:11 | csharp needs to read his own helpdesk tickets more closely ;-) |
| # | 11:10:32 | eeevil | csharp: and to clarify, that "1" is not "1 day", it's "1 fine interval" |
| # | 11:11:06 | Dyrcona | eeevil: right, sorry, 1 fine interval, which is usually 1 day, and for us always is. :) |
| # | 11:11:16 | csharp | eeevil: okay - there's an early PINES urban legend around here that the "grace day" was just a consequence of the way the fine generator works |
| # | 11:11:31 | csharp | or worked, rather |
| # | 11:11:46 | csharp | eeevil: thanks for the clarification |
| # | 11:11:56 | tsbere | csharp: If you move your fine generator back an hour to before midnight it would probably act that way. And with the 1 on the end would turn into 2 days. |
| # | 11:12:13 | eeevil | csharp: yes, I've heard that legend :) |
| # | 11:12:32 | jamesrf has joined #evergreen |
| # | 11:12:42 | csharp | eeevil: well, it's nice to know that it's by design |
| # | 11:13:17 | eeevil | csharp: it is, thought the 2.1+ design is much better ... someone finally cared enough to fund improvement ;) |
| # | 11:13:25 | eeevil | tsbere++ |
| # | 11:13:27 | csharp | we're just trying to communicate it all to our libraries without causing undue panic ;-) |
| # | 11:13:51 | eeevil | right |
| # | 11:14:04 | tsbere | Not sure anyone here cared enough to tell me to do it other than myself. |
| # | 11:14:11 | eeevil | ha |
| # | 11:14:11 | csharp | 1.6 has been received generally positively, but this has been a bump |
| # | 11:14:17 | eeevil | tsbere: well, they funded your time |
| # | 11:14:18 | csharp | tsbere++ |
| # | 11:14:25 | tsbere | eeevil: True. |
| # | 11:22:01 | jenny1 has quit IRC |
| # | 11:23:12 | jenny1 has joined #evergreen |
| # | 11:37:37 | youdonotexist has joined #evergreen |
| # | 11:42:13 | dbwells | csharp: way back when we coded up a simple script to detect and void backdate-into-grace situations. It's plenty hard-coded and makes various assumptions, but I can paste it up somewhere if interested. |
| # | 11:42:55 | dbwells | We still use it. |
| # | 11:48:58 | dbs | dbwells: please do! |
| # | 11:50:42 | dbs | jeff: *ping* on 2 fronts: your refactoring of added content to use record ID - does that live anywhere yet? And OpenSRF-PHP would make a great collab branch. Good git practice :) |
| # | 11:56:47 | jcp-jasonb has joined #evergreen |
| # | 11:58:36 | brian_f has joined #evergreen |
| # | 12:00:34 | bshum | Time for a meeting :) |
| # | 12:02:05 | tsbere | So it is. |
| # | 12:02:11 | gmcharlt | indeed |
| # | 12:02:17 | tsbere forgot about the meeting, due to being swamped so far today |
| # | 12:03:23 | dbs | meeting shepherder? |
| # | 12:03:27 | dbs | meeting minuter? |
| # | 12:03:48 | bshum | http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-05-24 |
| # | 12:04:01 | bshum | I don't mind taking notes. |
| # | 12:05:26 | dbs | I can shepherd, then |
| # | 12:05:51 | dbs | action items - we could look at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-04-30 |
| # | 12:06:18 | dbs | I think that mostly calls out for a tsbere++ / gmcharlt++ |
| # | 12:06:31 | gmcharlt | dbs: thanks |
| # | 12:06:31 | dbs | and sundry other increments |
| # | 12:07:01 | gmcharlt | from my POV main big task remaining (beside folks just getting comfortable with Git) is finishing porting ILS-contrib over to Git |
| # | 12:07:37 | tsbere | My main big task is migrating this weekend. But I can help get people comfortable with git in the meantime ;) |
| # | 12:08:18 | gmcharlt | dbs: that raises a secondary question - what do the syrup folks want to do? |
| # | 12:08:37 | dbs | gmcharlt: artunit said he would be able to join at 12:15, I would defer to him |
| # | 12:08:39 | mitchel has joined #evergreen |
| # | 12:08:42 | gmcharlt | ok |
| # | 12:09:22 | dbs | I'm a little concerned about code.launchpad.net not being able to import multiple branches from a single git repo; that has implications for bug tracking and translations |
| # | 12:09:26 | eeevil | gmcharlt: I have a process of my own for cutting releases from git, but I'd like to solicit green-field ideas from the general community ... particularly from the git graybeards |
| # | 12:09:44 | berick returns from mtg |
| # | 12:09:59 | gmcharlt | eeevil: sure. do you have your notes up somewhere? |
| # | 12:12:33 | tsbere | dbs: Can it pull multiple git repos? |
| # | 12:12:52 | mitchel | Hello I have been going through the troubleshooting : checking_for_errors section and got to step 7 and am recieving the following errors. can anyone help me with this |
| # | 12:13:28 | gmcharlt | mitchel: we're in a development meeting; would you mind holding your question for about 30 minutes or so? |
| # | 12:13:29 | dbs | tsbere: I believe it could, but that seems horribly hacky (either github / gitorious / mvlc for each branch, or having multiple repos at git.evergreen-ils.org - just to satisfy launchpad) |
| # | 12:13:39 | eeevil | gmcharlt: well, that's the thing... I want green-field ideas, not modifications on mine ;) |
| # | 12:13:51 | tsbere | dbs: Not multiple repos. Multiple "HEAD" files. Tis hacky, though.... |
| # | 12:13:55 | eeevil | gmcharlt: but I plan to put mine up, yes |
| # | 12:13:55 | gmcharlt | eeevil: ah, sure - I can write up some ideas |
| # | 12:14:03 | mitchel | ok no problem |
| # | 12:14:26 | dbs | ACTIONs for eeevil and gmcharlt noted :) |
| # | 12:14:51 | dbs will check on launchpad's ability to handle multiple repos (but is pretty sure it could) |
| # | 12:15:18 | dbs | Any other outstanding action items from last meeting? |
| # | 12:16:23 | artunit | gmcharlt: just joined, syrup folks want to be gitified |
| # | 12:16:29 | dbs | artunit++ |
| # | 12:16:39 | dbs | ACTION for gmcharlt / tsbere :) |
| # | 12:16:53 | dbs | and for artunit and gfawcett - send pubkeys to gitadmin@evergreen-ils.org |
| # | 12:17:06 | gmcharlt | artunit: cool; that can be done whever you want, and what dbs said |
| # | 12:17:17 | artunit | thanks, will follow up |
| # | 12:17:28 | dbs | Given no other outstanding action items - oh hey, did anyone want to add anything else to the agenda? |
| # | 12:18:06 | phasefx yawns, yeah, xul self-destruct, one day, we can wait |
| # | 12:18:07 | bradl | more beer. and nachos. |
| # | 12:18:19 | dbs | Okay. Sounds good to me |
| # | 12:18:30 | atz | the separate working/non-working repos strikes me as non-git-like. i'm assuming we separated them for permissions purposes |
| # | 12:18:33 | tsbere thinks his stuff falls under git processes |
| # | 12:18:38 | dbs | bradl: we're onto your tricks with the beer / no-beer thing |
| # | 12:18:58 | gmcharlt | atz: it's accommodating different workflows |
| # | 12:19:01 | dbs | okay, let's move on to git processes; atz, do you want to expand? |
| # | 12:19:10 | gmcharlt | some people/orgs have their trees that they maintain |
| # | 12:19:30 | gmcharlt | the working repos are a way for people to push random branches for people to look at |
| # | 12:20:00 | afterl has joined #evergreen |
| # | 12:20:16 | atz | right, but all we would need is a namespace convention for branches in the same repo (w/ possible permissions tied to it) |
| # | 12:20:48 | atz | gmcharlt, you can probably comment whether gitosis or any of the other mgmt tools could accomplish that |
| # | 12:21:06 | atz | my impression is that it could (but haven't done it myself) |
| # | 12:21:12 | tsbere | The working repos also allow for "we don't get an email every time someone updates working code" |
| # | 12:21:33 | atz | i guess i just use RSS |
| # | 12:21:44 | gmcharlt | atz: well, they do - see the username convention on the working repo |
| # | 12:22:10 | gmcharlt | and one can slice and dice who gets to do what to which brances to the nth degree with gitosis if one is so inclined |
| # | 12:22:38 | tsbere | The way I see it, by keeping the working repos split from the main we don't have constant email during churn on a working repo. That is one of the few benefits over just using the main repo with the same rules. |
| # | 12:24:14 | dbs | For masochists, are there commit mailing lists for all of the non-main repos? |
| # | 12:24:20 | tsbere | Not currently. |
| # | 12:24:30 | tsbere | Trivial to add to the git side these days, though. |
| # | 12:26:25 | dbs is happy to keep working with things the way they are |
| # | 12:27:18 | bjwebb | is the working repo soley for the purpose of branches. what is the relation of working's master to the main master? |
| # | 12:27:37 | tsbere | The working's master is kept in sync with the main's master |
| # | 12:27:51 | bjwebb | okay |
| # | 12:27:54 | tsbere | This is done via an automatic server-side push every time the main repo's master is updated |
| # | 12:28:26 | phasefx | git and working question. if I like rebasing all the time, is it okay for me to push to working/ for folks to see, given that I don't expect anyone to base anything off of a given working/ branch? |
| # | 12:28:27 | jamesrf_ has joined #evergreen |
| # | 12:28:50 | dbs thinks http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git#community_git_repository does a pretty good job of sorting out the purposes of the repos, but I'm sure suggestions for clarification would be appreciated |
| # | 12:28:50 | tsbere | phasefx: I would say "yes for user/, no for collab/" |
| # | 12:29:03 | phasefx | tsbere: cool deal |
| # | 12:29:26 | atz | so if it isn't permissions, i don't think email notice mgmt is enough to maintain separate repos. but i'm happy enough that we're using git formally, so i can work w/ it. |
| # | 12:30:36 | atz | s/it/them/ |
| # | 12:30:54 | dbs | Okay, assuming that we'll keep things as they are for now, moving on |
| # | 12:31:24 | dbs | Requests for branch reviews - via launchpad with a tag to enable queries for open requests? or to the -dev list? |
| # | 12:31:57 | dbs would like to ensure that pull requests / branch reviews (whatever you want to call them) don't get dropped |
| # | 12:32:01 | tsbere | Both? List on the dokuwiki somewhere? All of the above? |
| # | 12:33:13 | gmcharlt | all of the above, with posting on launchpad a minimum, I'd say |
| # | 12:33:34 | gmcharlt | launchpad allows the bug wranglers to, well, bug people to look at pull requests |
| # | 12:34:17 | dbs | okay. tagged 'reviewme' or something like that? |
| # | 12:34:27 | dbs | or 'pullrequest'? |
| # | 12:36:06 | berick | pullrequest is probably more specific |
| # | 12:36:09 | berick | which is good |
| # | 12:36:31 | dbs | Okay. ACTION item for dbs - put that in the "contributing" documentation |
| # | 12:37:00 | moodaepo_ has quit IRC |
| # | 12:37:09 | dbs | "Consider requiring reviewer sign-off before committing to a main branch?" |
| # | 12:37:45 | phasefx | I kind of like it |
| # | 12:37:46 | atz | Very reasonable |
| # | 12:38:29 | gmcharlt | dbs: talking about patches from non-commiters? +1 |
| # | 12:38:47 | gmcharlt | I also think that getting there for committers too would be good, but I think that's a longer-term project |
| # | 12:38:48 | dbs | gmcharlt: well, from all |
| # | 12:39:27 | phasefx | release managers in charge of a given branch, etc. some day, eh? |
| # | 12:39:53 | jbeliveau has joined #evergreen |
| # | 12:40:20 | dbs | phasefx: well, that's even more gatekeeping. requiring signoff from somebody else means that at least another pair of eyes have glanced at your code, |
| # | 12:40:28 | atz | gmcharlt: obviously somebody else is looking at non-committer patches in order to commit them. the "new" value would be from reviewing committers code. |
| # | 12:41:08 | gmcharlt | atz: looking at yes, signing off, that's not actually been explicitly stated |
| # | 12:41:43 | atz | i don't get why one would think it was ok to commit if they would NOT sign off on it. |
| # | 12:42:05 | dbs | heh. okay, a baby step would be "a committer must sign-off on contributions from non-committers" |
| # | 12:42:48 | gmcharlt | atz: yeah, I don't think there's any controversy on commiters signing off on non-committer's patches, just a matter of noting that "officially" |
| # | 12:42:49 | dbs | I think atz and I are suggesting that committer's patches should be no different than a non-committer's patch: two signed-off-by lines (minimum) for any commit that goes into a main branch |
| # | 12:43:44 | eeevil | dbs: IMO, once all committers are reviewing more incoming patches from non-committers, I think we can move that way |
| # | 12:43:49 | berick | i think everyone's generally on the same page. i agree with gmcharlt, though, that it's a longer-term project |
| # | 12:44:30 | dbs | okay. given no overwhelming support, set a date to review this in, say, 3 months? |
| # | 12:44:34 | gmcharlt | though to not make it completely open-ended, I suggest setting 12/31/2011 as a date for fully implementing taht requirement |
| # | 12:44:54 | eeevil | mmm.. dbs++ (review) |
| # | 12:45:15 | dbs | (and meanwhile committers can of course ask for other committers to sign-off their commits if they so desire) |
| # | 12:45:21 | berick | and no reason we can't ... |
| # | 12:45:21 | berick | right |
| # | 12:45:54 | atz | i guess that makes it a "recommendation" for now |
| # | 12:46:03 | dbs | atz: agreed |
| # | 12:46:10 | gmcharlt | atz: agreed |
| # | 12:46:30 | dbs | okay, next - just points of information about my meeting with OpenLibrary as written in the agenda |
| # | 12:46:38 | phasefx | let buildbot sign things that compile :) |
| # | 12:46:38 | dbs | unless there's questions, we can move on |
| # | 12:46:57 | dbs | phasefx: err, that's a low bar :) |
| # | 12:47:20 | phasefx smiles aimlessly |
| # | 12:47:40 | kmlussier has joined #evergreen |
| # | 12:48:05 | phasefx | if someone can write up a workflow for how this signing thing works, that'd be great. Is it just with merges/cherry-picks? |
| # | 12:48:06 | berick | phasefx: haha |
| # | 12:48:30 | dbs | UWindsor is having a Conifer dev get-together focused on TT OPAC development at the end of June - artunit, is the invite still open to other TT OPAC hackers (senator, berick, ...) to join us? |
| # | 12:48:37 | artunit | sure |
| # | 12:48:39 | phasefx | or can a signing be a commit in and of itself |
| # | 12:48:57 | artunit | windsor is not far from the detroit airport |
| # | 12:49:00 | dbs | phasefx: merges/cherry-picks is what I was thinking of |
| # | 12:49:40 | dbs isn't sure what "can a signing be a commit in and of itself" means and may need yet another trip to git re-education camp |
| # | 12:49:44 | phasefx | dbs: k, making sense to me now |
| # | 12:49:44 | berick | phasefx: it is possible to sign off on a commit (fwiw, i think) |
| # | 12:49:52 | berick | as in, git commit -s |
| # | 12:50:11 | atz | berick: and you can set config to automatically sign your own commits |
| # | 12:50:12 | dbs | git cherry-pick -s # is what I was thinking |
| # | 12:50:15 | eeevil | berick: yes, and that's the default if you tell it to be |
| # | 12:50:22 | phasefx | berick: that's what I was curious about.. signing something after the fact |
| # | 12:50:23 | eeevil | (signing, I mean) |
| # | 12:50:35 | dbs | and /me was assuming that everybody was doing 'git commit -s' now :) |
| # | 12:50:45 | atz | eeevil and I are on the same idea |
| # | 12:50:54 | eeevil | and there's --amend |
| # | 12:51:03 | atz nod |
| # | 12:51:05 | eeevil | anyway, we're pulling dbs off track |
| # | 12:51:08 | eeevil | TT OPAC FTW |
| # | 12:51:19 | senator | i would love to come to windsor, but i don't think it's likely i can make it |
| # | 12:51:28 | senator | i'll be at ALA for one thing |
| # | 12:51:36 | dbs | eeevil and berick can attest to the friendliess of immigration at the windsor bridge |
| # | 12:51:48 | artunit | heh, i will be smarter about the bridge this time |
| # | 12:51:49 | senator | aye, i've been before myself |
| # | 12:52:03 | artunit | it needs to be characterized as a conference |
| # | 12:52:14 | eeevil | oh, yes, if I have to cross a boarder then that one is great |
| # | 12:52:18 | eeevil | very clean holding cells |
| # | 12:52:21 | senator | it's the reception on the way back to the us that's brusque |
| # | 12:52:23 | dbs | eeevil++ |
| # | 12:52:35 | berick wonders if he can renew is expired passport in time *sigh* |
| # | 12:52:41 | senator | ooh |
| # | 12:52:43 | dbs | "Explain to me this free software business model..." |
| # | 12:52:51 | senator | crap. mine expired last year too actually. |
| # | 12:52:54 | artunit has a son with an american girlfriend and sees the crossing a lot |
| # | 12:53:07 | berick | dbs: do you have specific dates? |
| # | 12:53:11 | artunit | i'm not sure americans need passports |
| # | 12:53:14 | dbs | june 27 - 29 |
| # | 12:53:42 | berick | thanks |
| # | 12:53:44 | artunit | my son's girlfriend has a special license |
| # | 12:54:00 | dbs | Hope we see you there, but moving on... Bugs with patches attached: http://ur1.ca/3p7ya - I've commented on the first two as of last night |
| # | 12:54:14 | berick | my last crossing worked w/ expired passport and birth cert, but i thought they clamped down on that |
| # | 12:54:51 | dbs | I think the clamping down has in fact occurred. Valid passport or death. |
| # | 12:55:55 | dbs | All right, I need to prep for a call at 1:00, anyone else want to take the reins? |
| # | 12:56:14 | eeevil | sure |
| # | 12:56:30 | artunit | berick: confusing passport advice here: http://gocanada.about.com/od/canadatraveloverview/qt/uscitizenborder.htm |
| # | 12:56:52 | atz | we appear to have reached the end of the agenda |
| # | 12:57:30 | eeevil | atz: I think that's a wiki artifact .. we're at patch review queue |
| # | 12:58:33 | atz | ah, just the end the "agenda" section of the agenda. |
| # | 12:58:51 | eeevil | so, we need to get those reviewed ... anyone care to call dibs on some? |
| # | 12:59:11 | mitchel has quit IRC |
| # | 12:59:17 | bshum | I'll take LP 731521. |
| # | 12:59:28 | bshum | Apparently it's an old wishlist that I opened that mrpeters-isl wrote some stuff for us. |
| # | 12:59:38 | bshum | But might not apply to Evergreen community. |
| # | 12:59:45 | bshum | Will review and comment. |
| # | 12:59:51 | eeevil | even just as far as pushing them to a decided importance |
| # | 12:59:58 | eeevil | but, patch review would be relly rad |
| # | 13:00:20 | eeevil | really, even |
| # | 13:00:40 | dbs | I'll take the first two, if dbwells and jamesrf respond to my comments :) |
| # | 13:01:09 | eeevil | berick: could I cajole you into taking 776583 (SIP, 3rd one) |
| # | 13:01:31 | tsbere thinks berick already has that on his plate for later this week or so |
| # | 13:01:38 | berick | indeed I do |
| # | 13:01:38 | dbwells | dbs: or if you respond to mine? :) |
| # | 13:01:43 | berick | eeevil: consider me cajoled |
| # | 13:01:58 | eeevil | I'll take 740320 and 520175 |
| # | 13:02:50 | eeevil | if dibs callers would be so kind as to assign the bugs to themselves, you'd have my undying gratitude |
| # | 13:04:04 | berick grabs |
| # | 13:04:04 | eeevil | committer or not, reviewing would be appreciated |
| # | 13:04:25 | dbwells reads some backscroll, wonders if artunit realizes 'has a son with an american girlfriend' is an ambiguous statement (which I took the wrong way, I think) |
| # | 13:04:46 | eeevil | if you know the code area in question, don't be shy about grabbing a patch-having bugs |
| # | 13:04:47 | berick | haha |
| # | 13:04:49 | eeevil | bug |
| # | 13:05:05 | atz | dbwells: d'oh |
| # | 13:05:37 | artunit | dbwells: heh, it's an ambiguous statement |
| # | 13:05:55 | jcp-jasonb | Since I wrote it, I'd like to point out that 758945's scope has changed. It's only about using template macros more than once in a single section. The case sensitivity stuff wasn't well thought out and was removed. |
| # | 13:06:24 | eeevil | ok ... well, getting some names on patch-bugs is better than usual ;) ... time to move on to release stuff? |
| # | 13:06:37 | eeevil | or does anyone need more time on the patches righ tnow |
| # | 13:07:16 | eeevil | SILENCE IS ASSENT! moving on |
| # | 13:07:48 | berick | i think we could use 2.2 milestone, now that 2.1 is frozen (re: patches) |
| # | 13:07:56 | berick | don't think I have that capability.. |
| # | 13:08:26 | eeevil | berick: I'll add one |
| # | 13:08:31 | eeevil | unfortunately, looks like a 1.6.1.9 would be worthwhile |
| # | 13:09:28 | berick | thanks |
| # | 13:13:21 | eeevil | added |
| # | 13:13:50 | eeevil | now ... should be branch 2.2? |
| # | 13:13:55 | eeevil | I don't see a need ATM |
| # | 13:14:09 | berick | i don't see a need yet either |
| # | 13:14:12 | senator | ditto |
| # | 13:14:16 | eeevil | k |
| # | 13:14:33 | Dyrcona | neither do i, and I'm probably the most likely person to want a 2.2 branch. |
| # | 13:14:34 | eeevil | 2.0.7! ... let's wait for the existing 2 bugs to get attention |
| # | 13:15:30 | mtate has quit IRC |
| # | 13:17:19 | phasefx | Dyrcona: https://bugs.launchpad.net/evergreen/+bug/488243 Do you know the rationale for disabling the reset password button for the use phone pw setting? Wanted to make that very strict? |
| # | 13:17:53 | Dyrcona | At one point, I thought that I did, but now, not so much. |
| # | 13:18:50 | tsbere | phasefx: I think it was discussed in IRC. But am too lazy to go log-hunting. |
| # | 13:18:56 | Dyrcona | phasefx: Might make more sense if that setting is in use that the reset password button would use the last four digits of the phone. |
| # | 13:19:34 | dbs | re: array_accum(), array_agg(), and {NULL} vs NULL... http://archives.postgresql.org/pgsql-hackers/2010-09/msg00040.php (ugly ugly thread) |
| # | 13:19:51 | phasefx | I don't know who came up with the initial requirements for phone-based pw's, but I think at least one library must be confused by the behavior (it's getting to me 3rd hand) |
| # | 13:20:23 | Dyrcona | our own members are confused by it also. |
| # | 13:20:25 | kmlussier has quit IRC |
| # | 13:20:37 | bshum | phasefx: Dyrcona: I noticed that graying out my password reset button at our site after our upgrade to 2.0.6. Was thinking to open a new bug ticket about it. |
| # | 13:21:01 | phasefx can send a general query to the list and solicit opinions. If there's consensus, we could change it.. otherwise, YAOUS :) |
| # | 13:21:18 | kmlussier has joined #evergreen |
| # | 13:21:29 | Dyrcona | i vote for changing it rather than YAOUS. |
| # | 13:22:11 | dbs | YAOUS-- |
| # | 13:22:34 | phasefx | existing setting says use phone as default password |
| # | 13:22:39 | phasefx | that doesn't sound strict to me |
| # | 13:22:49 | phasefx votes for relaxing that restriction |
| # | 13:22:59 | Dyrcona | me, too. |
| # | 13:23:04 | phasefx | also says "when creating new users" |
| # | 13:23:43 | Dyrcona | disabling the reset password button seemed like a good idea at the time, but now, it seems like a rather bad idea. |
| # | 13:23:55 | eeevil | ok, so we'll wait on that too |
| # | 13:23:58 | phasefx | apparently just commenting it out doesn't result in a working reset button |
| # | 13:28:19 | phasefx | an explicit if(uEditUsePhonePw) return; in uEditMakeRandomPw |
| # | 13:28:40 | eeevil | 2.1.x status check: there are known outstanding issues to fix ... I still want to cut it, though. phasefx, can you target the new ones you added today? at least at the 2.1 series |
| # | 13:30:45 | phasefx | eeevil: you mean set Target to milestone to something, or? |
| # | 13:30:51 | Dyrcona | phasefx: I could send you a patch to remove the unwanted feature with the password reset button. |
| # | 13:31:20 | phasefx | Dyrcona: I believe Callender is going hands-on with it |
| # | 13:31:45 | Dyrcona | OK. just i'm mostly responsible for the mess, so thought I ought to clean it up. |
| # | 13:32:05 | phasefx | Callender: ^^ |
| # | 13:32:31 | bshum | Dyrcona: Happy to test it out here too, since we're live with the button and the setting enabled ;) |
| # | 13:32:41 | phasefx | Callender: Dyrcona: I think we want the button to generate a random password as normal, but let the setting still control the default for new users |
| # | 13:33:03 | Callender | Well, I can remove the code to allow it, the question is what to do on a password reset using the phone number setting. Having it re-use a phone number is a bit more work |
| # | 13:33:44 | eeevil | phasefx: to a series, but milestone is ok ... so we can find what needs to be fixed |
| # | 13:34:08 | atz | Callender: or use anew the *current* phone number... i don't see any way to restore it to whatever the phone number was when the account was created. |
| # | 13:34:55 | phasefx | eeevil: ah, never used Nomiate before. Okay, I can do that. I guess for milestone we need a target after -rc1 |
| # | 13:35:04 | atz | also, if have to deal with the possibility of there being no phone number |
| # | 13:35:15 | Callender | Still though, there could be cases where there ... yes! |
| # | 13:35:25 | phasefx votes for random number :) |
| # | 13:35:34 | Callender | and if there is things like no day phone, but an evening phone |
| # | 13:35:45 | atz | Callender: exactly |
| # | 13:35:50 | bshum | Callender: Let's not get started on what to do if there are extensions ;) |
| # | 13:36:12 | phasefx | staff can always type in a phone number password manually on the edge case of wanting to reset a pw for a non-new user |
| # | 13:36:14 | Callender | bshum: good point! This all rings of deja vu.... |
| # | 13:36:21 | tsbere | Provide an org unit setting for the phone field(s) for "how to get the password digits" :P |
| # | 13:36:21 | Callender | ok, random it is.. for now |
| # | 13:37:36 | brian_f has quit IRC |
| # | 13:37:59 | atz was never a fan of the predictable phone-based passwords. |
| # | 13:40:12 | bshum | So, just to verify for the notes |
| # | 13:41:14 | bshum | 2.1 rc is being cut sometime? |
| # | 13:41:30 | eeevil | so ... unless there are opinions on 2.1 cutting (RC?), or objections tot he default next-meeting-date (2011-06-07T12:00:00-0400) let's adjourn? |
| # | 13:41:35 | eeevil | bshum: sometime, yes |
| # | 13:41:53 | eeevil | asking for opinions ... I'd like to cut it very soon. tomorrow, say |
| # | 13:42:21 | bshum | +1 to adjourn and next-meeting-date |
| # | 13:42:49 | kmlussier has quit IRC |
| # | 13:43:28 | artunit | +1 |
| # | 13:48:39 | jcp-jasonb has quit IRC |
| # | 13:50:26 | kmlussier has joined #evergreen |
| # | 13:50:28 | brian_f has joined #evergreen |
| # | 13:56:33 | mtate has joined #evergreen |
| # | 13:58:13 | kmlussier has quit IRC |
| # | 14:06:40 | kmlussier has joined #evergreen |
| # | 14:14:00 | lisppaste | MarkEIN pasted "untitled" at http://paste.lisp.org/display/122222 |
| # | 14:15:15 | mrpeters-isl | looks to me like the build from source didn't get completed, MarkEIN |
| # | 14:15:37 | mrpeters-isl | or, if those files exist then maybe you didnt set your environment variables |
| # | 14:15:59 | mrpeters-isl | As the opensrf user, add an environmental variable to opensrf's .bashrc file: |
| # | 14:15:59 | mrpeters-isl | echo "export PERL5LIB=/openils/lib/perl5:\$PERL5LIB" >> ~/.bashrc |
| # | 14:15:59 | mrpeters-isl | . ~/.bashrc # inherit the new environment |
| # | 14:16:25 | kmlussier has quit IRC |
| # | 14:17:37 | jamesrf has left #evergreen |
| # | 14:20:37 | rserey has quit IRC |
| # | 14:22:32 | MarkEIN_ has joined #evergreen |
| # | 14:23:47 | kmlussier has joined #evergreen |
| # | 14:30:04 | kmlussier has quit IRC |
| # | 14:30:34 | MarkEIN_ | I'm getting a bunch off errors in my log files when i start the Opensrf perl services. I pasted the errors here http://paste.lisp.org/display/122222. Any ideas? |
| # | 14:33:05 | gmcharlt | MarkEIN_: looks like a typo when you set PERL5LIB |
| # | 14:33:15 | gmcharlt | @INC includes /openils/lib/perl15 when it should be /openils/lib/perl5 |
| # | 14:33:15 | pinesol_green | gmcharlt: Error: "INC" is not a valid command. |
| # | 14:34:15 | mrpeters-isl | nice catch, gmcharlt |
| # | 14:37:00 | tsbere | Is there any documentation on batch-printing notices (such as overdue notices)? |
| # | 14:37:48 | jbeliveau | http://pastebin.com/raw.php?i=WwHeaVhd I'm currently setting up opensrf on debian 6, and these are the errors I'm getting when trying to start. I tried specifying --localstatedir on ./configure and that didn't seem to change much |
| # | 14:37:51 | jamesrf_ is now known as jamesrf |
| # | 14:38:37 | bshum | tsbere: Documentation I don't think so. And it also depends on which method you use, scripted or A/T based print nofications. |
| # | 14:38:43 | bshum | *notifications |
| # | 14:39:09 | tsbere | bshum: Right now we pull data directly out of legacy ILS. I don't want to do that with evergreen. ;) |
| # | 14:40:00 | bshum | Let's just say that print notices are not the most elegant approaches. |
| # | 14:40:28 | tsbere | Well, if I had my way I wouldn't be trying, because we wouldn't be printing anything. But I don't get my way. :/ |
| # | 14:41:31 | dbs | fix for {NULL} vs NULL is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=b6849b3d1200f3619d71d5e51d98ad47fe7de280 and works_for_me |
| # | 14:41:44 | bshum | tsbere: Well I haven't tried legacy print overdues via scripted pieces in 2.1 (it's marked "deprecated" as of 2.0, but we still use it) |
| # | 14:42:07 | dbs | will probably bundle with http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=d7750b5d19728fdaeda2c0e20555ee174a1db245 to replace ARRAY_ACCUM with ARRAY_AGG throughout |
| # | 14:42:22 | bshum | tsbere: mrpeters-isl and berick(I think?) had some nice stuff going with A/T that we hope to try sometime after our migration. |
| # | 14:42:30 | dbs | any pointers on the new approach to upgrade scripts appreciated |
| # | 14:42:45 | dbs goes to tell cataloguers that thaey can, in fact, catalogue again |
| # | 14:42:53 | kmlussier has joined #evergreen |
| # | 14:43:18 | tsbere | dbs: You can run the make-db-patch.pl file (I think) for the basics. Lives in the src/sql/Pg folder. |
| # | 14:43:59 | dbs | tsbere: ah cool, thanks |
| # | 14:44:01 | b_bonner has quit IRC |
| # | 14:44:32 | b_bonner has joined #evergreen |
| # | 14:45:10 | tsbere | berick: I have some code that does stuff in regards to active_date kicking around (re dev list email) |
| # | 14:47:19 | b_bonner has quit IRC |
| # | 14:47:34 | berick | tsbere: cool. i knew it was percolating somewhere... |
| # | 14:47:45 | berick | tsbere: mind explaining on the list? |
| # | 14:48:11 | b_bonner has joined #evergreen |
| # | 14:48:19 | tsbere | berick: Technically was waiting on other things internally before testing it (like our migration, and waiting on internal dev process stuff to happen) |
| # | 14:50:19 | bjwebb has quit IRC |
| # | 14:50:55 | tsbere pokes kmlussier about that, if she is around |
| # | 14:51:04 | kmlussier has quit IRC |
| # | 14:51:10 | tsbere | Guess that answers that. |
| # | 14:51:25 | berick | heh |
| # | 14:52:24 | berick | tsbere: well, just understanding what you want to do w/ active_date should be enough |
| # | 14:52:45 | lisppaste | MarkEIN pasted "opensrf C service error" at http://paste.lisp.org/display/122223 |
| # | 14:53:13 | lisppaste | MarkEIN annotated #122222 "untitled" at http://paste.lisp.org/display/122222#1 |
| # | 14:55:08 | MarkEIN_ | I fixed the perl error but now i got som errors when I start the C service. annotated to this post, http://paste.lisp.org/display/122222 |
| # | 14:55:43 | kmlussier has joined #evergreen |
| # | 14:55:47 | gmcharlt | MarkEIN_: that one's noise; doesn't mean breakage in this case |
| # | 14:56:56 | kmlussier | tsbere: just sent a message to the dev list |
| # | 14:57:04 | tsbere | kmlussier: Just saw it. |
| # | 14:57:27 | b_bonner has quit IRC |
| # | 14:57:46 | kmlussier | tsbere: My internet connection has been in and out today. Wasn't trying to ignore you. ;-) |
| # | 14:58:11 | b_bonner has joined #evergreen |
| # | 14:58:51 | tsbere | berick: Easy way to explain to you would probably be "show you my untested work". http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=shortlog;h=refs/heads/active_date |
| # | 15:00:22 | b_bonner has quit IRC |
| # | 15:00:50 | brian_f has quit IRC |
| # | 15:01:12 | berick | tsbere++ # sweet, that's exactly what I was hoping it was ;) |
| # | 15:01:40 | b_bonner has joined #evergreen |
| # | 15:05:53 | gmcharlt | tsbere: adding a column to config.copy_status to specify that changing to that status should update the active date would be more maintainable in the long run than hardcoding lists of copy statuses |
| # | 15:07:27 | tsbere | gmcharlt: Would you believe I basically wrote that while trying to debug something else and determining how many hours it would likely take me for internal procurement stuff? I gave it very little actual thought. But yea, since I thought that might be a better idea. |
| # | 15:07:52 | tsbere hasn't done anything to it for a couple days beyond rebase it to add actual commit messages |
| # | 15:08:42 | tsbere | If berick doesn't run with the code I could do that myself, but might be a week or two before I can get to it. |
| # | 15:09:57 | gmcharlt | tsbere: cool. and another use for active_date occurred to me - have an interval from the active date be a matchpoint in the circ matrix |
| # | 15:10:21 | gmcharlt | use case: libraries who want circ policies for new items to change when they become not-new without having to touch those items |
| # | 15:10:40 | berick will run with whatever is there in 2-3 weeks. |
| # | 15:10:55 | tsbere | gmcharlt: That sounds like a good idea too. |
| # | 15:13:58 | tsbere makes notes |
| # | 15:15:51 | dbs can't believe nobody else has run into this {NULL} thing and wonders if he's just special |
| # | 15:17:31 | Dyrcona | dbs: you are special. |
| # | 15:19:41 | jeff | hooray active_date. |
| # | 15:20:02 | jeff | glad to see it evolve per previous discussions without having to re-visit those discussions. :) |
| # | 15:21:04 | berick | :) |
| # | 15:21:10 | kmlussier has quit IRC |
| # | 15:24:01 | kmlussier has joined #evergreen |
| # | 15:28:21 | dbs | Dyrcona: you're sweet :) |
| # | 15:31:39 | pmplett has joined #evergreen |
| # | 15:38:04 | b_bonner has quit IRC |
| # | 15:39:43 | lisppaste | MarkEIN annotated #122222 "error after smoke test" at http://paste.lisp.org/display/122222#2 |
| # | 15:40:18 | b_bonner has joined #evergreen |
| # | 15:40:21 | mrpeters-isl | MarkEIN_ did you register the router/opensrf users with private/public ejabberd hosts? |
| # | 15:41:00 | MarkEIN_ | I did. Should i try and do it again? |
| # | 15:41:35 | mrpeters-isl | well, lets try this |
| # | 15:41:49 | kmlussier has quit IRC |
| # | 15:42:30 | jenny1 has quit IRC |
| # | 15:43:50 | mrpeters-isl | you should be able to use the registered-users switch to make sure they were registered properly |
| # | 15:44:31 | mrpeters-isl | but, check out - http://open-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors |
| # | 15:44:49 | mrpeters-isl | settings-tester.pl would be a good place to start - i'm betting there is something that will error out in there |
| # | 15:45:14 | kmlussier has joined #evergreen |
| # | 15:45:23 | MarkEIN_ | thanks i will try that |
| # | 15:45:42 | mrpeters-isl | let us know if anything does |
| # | 15:46:07 | b_bonner has quit IRC |
| # | 15:46:26 | b_bonner has joined #evergreen |
| # | 15:48:45 | b_bonner has quit IRC |
| # | 15:49:52 | kmlussier has quit IRC |
| # | 15:52:14 | kmlussier has joined #evergreen |
| # | 15:53:48 | tsbere | gmcharlt: A question on your suggestion/idea for the active_date in the circ matchpoint. Would you think it should be a single value "less than this age" or a "less than this, greater than that" set of two settings? |
| # | 15:54:51 | gmcharlt | tsbere: a single "item age" value covers the use cases that occur to me |
| # | 15:58:47 | b_bonner has joined #evergreen |
| # | 15:59:46 | tsbere | hmmmm. Is it an error that serial.unit doesn't get all four of the asset.copy triggers? |
| # | 15:59:52 | Meliss has quit IRC |
| # | 16:00:10 | jenny has joined #evergreen |
| # | 16:01:25 | b_bonner has joined #evergreen |
| # | 16:07:43 | kmlussier has quit IRC |
| # | 16:10:18 | dbwells | tsbere: Almost certainly. One of the bummers of inherited tables, it's easy to forget about triggers. |
| # | 16:11:01 | tsbere | dbwells: Well, it gets two of them. Just not the other two, apparently. |
| # | 16:11:12 | kmlussier has joined #evergreen |
| # | 16:13:33 | sfortin has quit IRC |
| # | 16:15:46 | kmlussier has quit IRC |
| # | 16:18:16 | dbwells | grabbing 0540 |
| # | 16:30:15 | dbs | Dyrcona: if you have a test system handy, please try deleting a record that does not contain an ISBN or ISSN |
| # | 16:30:36 | Dyrcona | ok. |
| # | 16:30:43 | dbs | Or updating a record that does not contain an ISBN or ISSN, actually. |
| # | 16:31:10 | dbs | awesome, thanks |
| # | 16:32:00 | Dyrcona | from the staff client, I presume. |
| # | 16:32:11 | Dyrcona | first, i have to find a record without an isbn... |
| # | 16:32:33 | dbs | Dyrcona: sure. It shouldn't really matter, as it's the "update reporter.materialized_simple_record" trigger that gets firest |
| # | 16:32:34 | dbs | fired |
| # | 16:33:00 | dbs | reporter.simple_rec_trigger() |
| # | 16:33:30 | dbs | if you just "SELECT reporter.simple_rec_trigger(<record_id>);" that should be enough |
| # | 16:37:00 | kmlussier has joined #evergreen |
| # | 16:38:25 | Dyrcona | ERROR: function reporter.simple_rec_trigger(integer) does not exist |
| # | 16:38:27 | Dyrcona | LINE 1: select reporter.simple_rec_trigger(92546) |
| # | 16:38:53 | Dyrcona | i'm on trunk. |
| # | 16:41:05 | tsbere | Tis a trigger. Doesn't take parameters. |
| # | 16:41:16 | dbs | err |
| # | 16:41:18 | dbs | reporter.simple_rec_delete(NEW.id) |
| # | 16:41:19 | kmlussier has quit IRC |
| # | 16:41:55 | dbs | sorry, moving too fast trying to close post-upgrade issues and wasting your time as you get closer to migration, dbs-- |
| # | 16:42:07 | KN2W has quit IRC |
| # | 16:42:14 | dbs | or, reporter.simple_rec_update(NEW.id); |
| # | 16:42:18 | tsbere | Anything that fixes a bug before our migration is likely not wasting our time. |
| # | 16:42:34 | tsbere | Less bugs = happy us ;) |
| # | 16:42:43 | Dyrcona | s'alright. cause reporter.simple_rec_trigger() doesn't exist on our system so that *might* be a problem. |
| # | 16:43:27 | tsbere | Dyrcona: In pgadmin it is under "Trigger Functions" instead of "Functions". And is there. |
| # | 16:43:31 | Dyrcona | reporter.simple_rec_update(92546) returns t |
| # | 16:43:43 | Dyrcona | ok. was looking under regular functions, sorry. |
| # | 16:44:36 | dbs | Dyrcona: hmm. well, thanks, as disturbing as that is... |
| # | 16:45:14 | dbs | SELECT isbn FROM reporter.old_super_simple_record WHERE id = 92546; ? |
| # | 16:45:40 | Dyrcona | reporter.simple_rec_delete(92546) also returns t and I'm sure 92546 does not have as isbn or issn |
| # | 16:45:48 | Dyrcona | does that help? |
| # | 16:46:19 | dbs | It does, would like to see if reporter.old_super_simple_record shows {NULL} or {} |
| # | 16:50:33 | Dyrcona | has {NULL} for both isbn and issn |
| # | 16:52:31 | dbs is totally freaked out now |
| # | 16:55:50 | dbs | UPDATE reporter.materialized_simple_record SET isbn = '{NULL}' WHERE id = 92546; # does that work? |
| # | 16:56:11 | dbs gets ERROR: array must not contain null values |
| # | 16:56:48 | dbs | ahhh |
| # | 16:56:56 | dbs | http://www.postgresql.org/docs/9.0/interactive/runtime-config-compatible.html |
| # | 16:57:26 | dbs | array_nulls: This controls whether the array input parser recognizes unquoted NULL as specifying a null array element. By default, this is on, allowing array values containing null values to be entered |
| # | 16:58:04 | tsbere | Have you been upgrading since 8.2 or earlier? Might have gotten shut off because of that? |
| # | 16:58:28 | Dyrcona | so yours must be off, because I get Query returned successfully: 0 rows affected, 11 ms execution time. |
| # | 16:58:50 | dbs | tsbere: since 8.3, but could also be a debian vs. ubuntu tweaked default (maybe)? |
| # | 16:58:56 | Dyrcona | no. we're running on a new 9.0 install. |
| # | 16:59:17 | tsbere | Dyrcona: I was wondering if dbs had been upgrading. Not us. |
| # | 16:59:38 | Dyrcona | sorry, missed that it was from you. :p |
| # | 17:00:08 | Dyrcona is tired. |
| # | 17:00:57 | dbs | SET array_nulls TO 'off'; # resolves the problem, as the docs would suggest |
| # | 17:02:01 | dbs | err, actually that's the opposite of what I would understand the docs to say, but like Dyrcona, I'm tired |
| # | 17:03:28 | tsbere | dbs: That makes it read NULL as 'NULL' I think, inside of an array. |
| # | 17:04:17 | dbs | Yeah, it does (checking the contents of rmsr after successfully updating it with {NULL}). |
| # | 17:04:18 | dbs | sheesh |
| # | 17:05:25 | dbs | {"NULL"} is not the droid I'm looking for |
| # | 17:06:05 | tsbere | If you swap it for array_agg does it behave better? |
| # | 17:06:10 | dbs | tsbere: you guys are running on Ubuntu Lucid IIRC? Stock postgresql or compiled from source? |
| # | 17:06:24 | tsbere | dbs: Backportish postgresql |
| # | 17:09:20 | dbs | tsbere: no, switching to array_agg was the first thing I tried, but within the view def for reporter.old_super_simple_record it still returns {NULL} instead of {} |
| # | 17:12:34 | dbwells | tsbere: fix for the missing serial.unit triggers is committed back through rel_2_0. Thanks for bringing it up. |
| # | 17:13:53 | jbeliveau has quit IRC |
| # | 17:14:31 | tsbere | dbwells: Yay. Good to know :D |
| # | 17:23:23 | atz_ has joined #evergreen |
| # | 17:25:59 | atz has quit IRC |
| # | 17:28:45 | Dyrcona has quit IRC |
| # | 17:38:09 | yboston has quit IRC |
| # | 17:47:01 | dbs has quit IRC |
| # | 18:01:30 | guest has left #evergreen |
| # | 18:12:16 | jenny has left #evergreen |
| # | 18:22:36 | cua has joined #evergreen |
| # | 18:22:46 | cua | hello |
| # | 18:23:12 | cua | i have a problem with the instalation of evergreen |
| # | 18:23:51 | cua | i got this error: |
| # | 18:24:19 | cua | Exception: OpenSRF::EX::Session 2011-05-24T10:22:05 OpenSRF::Transport /usr/local/share/perl/5.10.1/OpenSRF/Transport.pm:92 Session Error: router@private.localhost/open-ils.cstore IS NOT CONNECTED TO THE NETWORK!!! |
| # | 18:25:00 | cua | when i try this comands: cd /openils/bin |
| # | 18:25:15 | cua | and ./autogen.sh -c /openils/conf/opensrf_core.xml -u |
| # | 18:25:51 | cua | any idea? |
| # | 18:31:03 | phasefx | cua: have you seen this? http://evergreen-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors |
| # | 19:04:03 | cua | yes |
| # | 19:04:05 | cua | i did |
| # | 19:05:22 | phasefx | and no errors until you got to the autogen part? |
| # | 19:05:52 | cua | yes |
| # | 19:07:41 | cua | what can it be? |
| # | 19:07:57 | phasefx | I'm not sure. Have you tried settings-tester.pl? |
| # | 19:09:32 | phasefx | from the Evergreen directory that got created when you untarred the download, and as user opensrf, try perl Open-ILS/src/support-scripts/settings-tester.pl |
| # | 19:09:44 | cua | this is my first time with evergreen, i don´t know about that |
| # | 19:10:16 | cua | ok |
| # | 19:10:19 | cua | i'll try |
| # | 19:10:51 | lisppaste | phasefx pasted "testing paste.lisp.org/new/evergreen" at http://paste.lisp.org/display/122228 |
| # | 19:11:50 | phasefx | cua: if you have a lot of output to share, try using http://paste.lisp.org/new/evergreen instead of pasting into the channel |
| # | 19:17:48 | cua | ok i will, thre is a lot lines |
| # | 19:19:44 | lisppaste | CUA pasted "ERROR" at http://paste.lisp.org/display/122229 |
| # | 19:20:35 | youdonotexist has quit IRC |
| # | 19:21:05 | phasefx | cua: so it looks like it can't connect to your database |
| # | 19:21:56 | phasefx | cua: what instructions did you follow for installation so I can reference them? |
| # | 19:22:11 | tsbere just had a power spike, so says his UPS |
| # | 19:22:45 | phasefx 's UPS died, and shorted out his side of the building when plugged back into the wall :) chaos powers |
| # | 19:23:04 | cua | let me see |
| # | 19:23:20 | cua | http://www.open-ils.org/dokuwiki/doku.php?id=server:2.0:install |
| # | 19:23:26 | tsbere | phasefx: My old UPS would have killed my PC for that spike. <_< It is still sitting on the floor nearby, unplugged. |
| # | 19:24:37 | cua | and for the database instalation i follow http://www.guia-ubuntu.org/index.php?title=PostgreSQL |
| # | 19:24:48 | cua | but, is in spanish. sorry |
| # | 19:24:56 | phasefx | cua: so the part where you used Open-ILS/src/support-scripts/eg_db_config.pl, step 4, did you specify the correct database name, database user? |
| # | 19:26:48 | phasefx | cua: the settings-tester output leads me to believe it's trying to use the user "postgres" to connect to the database, but if you did what is said in step 3.II., then it'll be "evergreen" |
| # | 19:26:50 | lisppaste | CUA pasted "DB" at http://paste.lisp.org/display/122231 |
| # | 19:27:09 | cua | those are the lines i use |
| # | 19:27:15 | cua | in that part |
| # | 19:27:57 | phasefx | okay, so the next thing to check is to make sure that the evergreen user is actually specified in /openils/conf/opensrf.xml eg_db_config.pl is supposed to modify that file for you, I believe |
| # | 19:28:34 | cua | ok i´ll check |
| # | 19:28:46 | phasefx | cua: I'd grep '<user>' /openils/conf/opensrf.xml |
| # | 19:29:41 | cua | from opensrf user? |
| # | 19:30:06 | phasefx | cua: yeah, or root, but safer to do things as user opensrf in most cases |
| # | 19:31:30 | lisppaste | CUA pasted "DB" at http://paste.lisp.org/display/122232 |
| # | 19:31:43 | cua | sorry, i mistake |
| # | 19:32:02 | lisppaste | CUA pasted "User" at http://paste.lisp.org/display/122233 |
| # | 19:32:37 | phasefx | cua: grep for '<user>' |
| # | 19:33:52 | lisppaste | CUA pasted "User" at http://paste.lisp.org/display/122234 |
| # | 19:35:33 | phasefx | yeah, wrong user. hrmm. you can either change those by hand, or you can try the eg_db_config script again. In either case, you'll want to stop_all your services |
| # | 19:36:07 | tsbere | phasefx / cua : This happens to me when I forget to chown -R /openils after make install. eg_db_config can't edit the file then, as it is still owned by root. |
| # | 19:36:51 | phasefx | cua: ^^ |
| # | 19:37:10 | cua | i´m here |
| # | 19:37:16 | dbs has joined #evergreen |
| # | 19:38:17 | cua | which line?? |
| # | 19:38:56 | phasefx | cua: let's follow tsbere's angle. exit out of the file if you're editing it, and do ls -l /openils/conf/ are the files owned by opensrf or root? |
| # | 19:39:22 | afterl has quit IRC |
| # | 19:39:42 | cua | ok |
| # | 19:40:53 | lisppaste | CUA pasted "files" at http://paste.lisp.org/display/122235 |
| # | 19:41:10 | phasefx | hrmm |
| # | 19:41:55 | tsbere now suspects the eg_db_config call wasn't made correctly |
| # | 19:42:02 | phasefx | cua: well, I'd try repeating the Open-ILS/src/support-scripts/eg_db_config.pl instruction again, and then grep '<user>' /openils/conf/opensrf.xml again, and see if those postgres users got changed to evergreen |
| # | 19:42:36 | cua | ok, i´ll try |
| # | 19:42:52 | cua | if not |
| # | 19:43:12 | phasefx | if it doesn't work, we can go back to changing opensrf.xml by hand |
| # | 19:43:16 | cua | i´ll do it manually |
| # | 19:43:33 | cua | thanks a lot phasefx |
| # | 19:44:05 | phasefx | happy to help |
| # | 19:44:12 | cua | hava a great day |
| # | 19:44:37 | phasefx | cua: just make sure you restart services after changing opensrf.xml or using eg_db_config |
| # | 19:44:52 | phasefx | and then run autogen.sh again |
| # | 19:45:11 | cua | ok. i will |
| # | 19:46:06 | cua has quit IRC |
| # | 20:53:49 | pmplett has quit IRC |
| # | 21:36:21 | dbs | so - what the heck do we do with sequential sql/upgrade/*.sql entries when a pull request has an upgrade number that's now less than a subsequently merged commit? |
| # | 21:38:44 | gmcharlt | dbs: I think make it the responsibility of the committer to renumber as needed |
| # | 21:38:45 | dbs | I'm reviewing dbwells' branch for which he called 0539, but 0540 got called as well and has been committed first. So... when I cherry-pick his commit, do I set the INSERT to config.upgrade_log back to 0539? Or more logically, 0541? |
| # | 21:39:05 | gmcharlt | so cherry pick, then update and mv to 0541 |
| # | 21:39:23 | dbs | So our nice sequence is going to be like a real database sequence: holes |
| # | 21:39:58 | dbs | I guess that also suggests that there's no reason to bother with updating 002 with the upgrade number (or we move that INSERT stmt out into its own file or something) |
| # | 21:40:23 | dbs | ... not until it's committed, anyway |
| # | 21:40:34 | gmcharlt | dbs: well, no need for holes |
| # | 21:40:51 | gmcharlt | numbers can get claimed by the committer at the time that the patch is merge dinto master |
| # | 21:41:08 | dbs | feels like something that should be further automated, it's nutty for us to be creating branches with numbers that are doomed to conflict |
| # | 21:41:45 | dbs | Not that I have any better proposals. upgrade log uses timestamps pulled from commit instead? dunno. |
| # | 21:42:20 | gmcharlt | well, patch authors probably shouldn't be selecting numbers when they hack |
| # | 21:42:25 | gmcharlt | just use XXXX or something |
| # | 21:42:56 | dbs | includes filenames |
| # | 21:43:36 | gmcharlt | yep |
| # | 21:43:43 | gmcharlt | one of tsbere's recent braches does that |
| # | 21:44:57 | tsbere | All of my upgrade scripts use XXXX |
| # | 21:45:14 | jeff | oof. hello! |
| # | 21:45:21 | tsbere | Was thinking about rigging up make-db-patch with a --nonum, even. |
| # | 21:45:45 | tsbere currently uses 9999 and then strips off the wrapping anyway, though |
| # | 21:45:47 | gmcharlt | tsbere: good idea |
| # | 21:45:52 | tsbere then renames to XXXX |
| # | 21:46:33 | tsbere | I figure if I use an unwrapped one then the committer can use the --wrap option on my upgrade script |
| # | 21:46:44 | dbs | Seems reasonable enough - each topic branch should only have one schema upgrade script |
| # | 21:47:03 | dbs doesn't know what --wrap refers to |
| # | 21:47:11 | dbs waves at jeff |
| # | 21:47:34 | jeff | hi. saw your pokes/prods earlier. will work to get both out. |
| # | 21:48:46 | tsbere | dbs: make-db-patch has multiple options. One is to wrap an existing upgrade script properly. Another it to scan the core db files for changes and include them (diff from HEAD by default, or from a ref you provide). |
| # | 21:48:56 | tsbere | s/it to/is to/ |
| # | 21:48:57 | dbs | jeff++ |
| # | 21:49:26 | dbs | jeff: I'm interested in the added content stuff because of more openlibrary work that i need to do in the near future |
| # | 21:49:34 | jeff | once again, please save your incrementing for AFTER i do what i say i'm going to do ;-) |
| # | 21:50:22 | dbs | jeff: I think you learned that from me, a king of talk |
| # | 21:50:28 | dbs | tsbere: thanks! |
| # | 21:51:12 | dbs | is it kosher to edit the commit message that another author wrote for a patch? |
| # | 21:51:23 | tsbere | depends on the edit, I think. |
| # | 21:51:32 | gmcharlt | dbs: yes, assuming it's a useful edit, natch |
| # | 21:51:51 | tsbere | Technically, signing-off of a cherry pick is an edit of the commit message, come to think of it. |
| # | 21:52:04 | gmcharlt has often added descriptive text to other's Koha patches |
| # | 21:52:07 | dbs | mostly wrapping lines so that they're < 70 chars wide instead of 140 chars |
| # | 21:52:53 | dbs | vim looks angry when it encounters git commit messages with overly long lines |
| # | 21:54:01 | jeff | i appreciate that. it taught me about the "first line is a subject/summary" convention. |
| # | 21:54:31 | dbs | btw, calling 0541 |
| # | 21:54:36 | jeff | hardy vim syntax doesn't have it, 7.3 on my laptop does. |
| # | 21:54:45 | dbs | hardy! |
| # | 21:55:57 | tsbere | btw gmcharlt: Your comment about using active_date in the circ matrix got my brain stuck in a problem solving loop <_< |
| # | 21:55:57 | jeff | yeah, EOL'd while i was out of town. not that i didn't know it was coming... |
| # | 21:57:55 | dbs is about to update one of his machines to Fedora 15, as soon as his wife logs out |
| # | 21:59:40 | tsbere apologizes to anyone who looked at his active_date branch (or does so in the next week or two) because he has already rebased it like mad locally |
| # | 22:00:55 | dbs finally finds and reads make-db-patch.pl |
| # | 22:09:08 | lisppaste | dbs pasted "version stamp is sensitive to input (slashes methinks)" at http://paste.lisp.org/display/122239 |
| # | 22:12:16 | tsbere | dbs: So it is. |
| # | 22:12:30 | dbs edits VERSION manually for now :) |
| # | 22:12:35 | tsbere already has an idea for fixing that |
| # | 22:12:42 | tsbere will finish his current idea first |
| # | 22:13:01 | dbs | tsbere++ |
| # | 22:13:08 | jeff generates a new ssh key |
| # | 22:22:38 | tsbere | gmcharlt: Pushed a new commit to my mdp-improve branch (and a pile of merge). Also pushed a copy to working. |
| # | 22:30:01 | gmcharlt | tsbere: looks good, pushed |
| # | 22:30:43 | jeff | gitadmin(s): you've got mail! |
| # | 22:32:33 | tsbere | gmcharlt / dbs / phasefx: Pushed a fix to the "auto version hates slashes" problem to my installer branch. And pushed to working. |
| # | 22:32:43 | dbs | tsbere++ |
| # | 22:32:50 | dbs | will try that out next :) |
| # | 22:33:31 | gmcharlt | jeff: except for legacy commiters, user names take the form of an email address (or email address-like string); any preference for a username knowing that? |
| # | 22:34:07 | jeff | oh? guess i missed that. |
| # | 22:34:17 | gmcharlt | jeff: it's a very, very loose convention |
| # | 22:35:38 | jeff | guess i'll have to think on that a bit. i'll get back to you! |
| # | 22:35:50 | gmcharlt | meh, no reason to hold it up |
| # | 22:35:54 | gmcharlt | 'jeff' it is |
| # | 22:35:58 | jeff | heh |
| # | 22:36:07 | jeff | gmcharlt++ |
| # | 22:36:50 | gmcharlt | jeff: ok, you now have the power |
| # | 22:37:13 | jeff | thanks! |
| # | 22:37:15 | mrpeters-isl has quit IRC |
| # | 22:38:25 | gmcharlt will not stand in front of all of the commits that people are bugging you for ;) |
| # | 22:41:30 | phasefx | gmcharlt++ jeff++ |
| # | 22:51:14 | dbs | tsbere++ worked nicely - committed. thanks! |
| # | 22:57:53 | dbs | gah. okay, so apparently I should rebase local branches to squash "merge branch master..." commits into the actual substantive commit, rather than making that totally uninformative short log message? |
| # | 22:57:56 | tsbere | @later tell eeevil Similar to what dbs ran into for auto-version in the staff client, pushed the same basic thing to my build_version branch. Should help if someone is using, say, local/rel_#_#_# branch when applying. |
| # | 22:57:56 | pinesol_green | tsbere: The operation succeeded. |
| # | 22:58:59 | tsbere | dbs: I rebase local branches instead of pull/merge on master, personally. Until I have pushed them. Building on older work I pull/merge. |
| # | 23:04:34 | phasefx is chagrined to admit he's been cherry-picking to avoid those merge messages |
| # | 23:06:28 | rangi | the merge message is quite useful |
| # | 23:06:33 | rangi | if you ever want to revert a merge |
| # | 23:06:53 | rangi | and its easy to ignore in stats |
| # | 23:06:53 | phasefx | ah |
| # | 23:07:10 | rangi | git log --no-merges |
| # | 23:07:44 | dbs noticed now that the more substantive commits are still shown, doesn't care as much now |
| # | 23:07:55 | rangi may or may not have been doing statistics this morning to facilitate his arguing on the internet |
| # | 23:08:01 | dbs | rangi++ |
| # | 23:08:10 | dbs may or may not have been watching with interest |
| # | 23:08:59 | phasefx may or may not have grinned at certain blog posts |
| # | 23:09:32 | rangi | i thought the comment discussion wasnt going to end :) |
| # | 23:10:43 | dbs | okay, 'git reset --hard' isn't what I want. how do i tell git to destroy all generated files in my repo (files from autoconf / make / etc)? |
| # | 23:10:50 | tsbere | git clean |
| # | 23:11:18 | dbs | or "git clean -f" for me - thanks! |
| # | 23:11:26 | tsbere | you may want -d too |
| # | 23:11:37 | jeff has quit IRC |
| # | 23:11:40 | tsbere | To wipe out entire directories that git isn't tracking |
| # | 23:12:26 | phasefx | rock |
| # | 23:12:50 | jeff has joined #evergreen |
| # | 23:13:16 | jeff | re |
| # | 23:13:35 | rangi | you guys know about stash too eh? |
| # | 23:13:52 | rangi | (for a different use case, but handy as hell) |
| # | 23:13:56 | tsbere stashes on a regular basis |
| # | 23:14:10 | phasefx uses it to get rid of stuff more often than temporarily stashing stuff |
| # | 23:14:15 | tsbere | Especially good when someone says "Oh, I changed that file". Stash, pull, pop, hope nothing conflicted. |
| # | 23:14:33 | rangi | yep |
| # | 23:15:00 | tsbere | I have also reset and stashed entire commits to re-do them. And then decided which version I liked better. |
| # | 23:15:20 | jeff | i'm still cautious whenever i use reset. :) |
| # | 23:16:05 | rangi | and for anyone using debian or ubuntu, now you know git, i can recommend etckeeper |
| # | 23:16:34 | rangi | oh even fedora now |
| # | 23:16:44 | rangi | http://kitenet.net/~joey/code/etckeeper/ |
| # | 23:17:26 | tsbere | That sounds very useful.....if I were constantly messing with /etc |
| # | 23:17:48 | rangi | packages mess with etc too, its interesting to track what they do |
| # | 23:18:14 | tsbere | True. Not interesting enough for me today, though. :P |
| # | 23:21:39 | tsbere departs for the night |
| # | 23:23:40 | dbs | man. 2.0 vs. 2.1 vs trunk conventions are messing with my head |
| # | 23:25:28 | jeff | rangi: i like that, especially for changes made by packages. |
| # | 23:31:21 | dbs | looks like the testing.evergreen-ils.org server lost power or was rebooted harshly and the buildbot was never started up again |
| # | 23:33:34 | dbs | I just restarted the buildbot, it's going to take some time for it to catch up to recent commits (if the slaves even bother hanging around after this many days) |
| # | 23:33:52 | egbuilder has joined #evergreen |
| # | 23:33:53 | egbuilder | build #22 of evergreen-rel_2_1-debian-6.00-x86_64 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_2_1-debian-6.00-x86_64/builds/22 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:34:02 | egbuilder | build #22 of evergreen-rel_2_1-ubuntu-10.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_2_1-ubuntu-10.04-x86/builds/22 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:34:14 | egbuilder | build #570 of evergreen-master-debian-6.00-x86_64 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/570 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:34:19 | egbuilder | build #816 of evergreen-master-ubuntu-10.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-10.04-x86/builds/816 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:34:34 | dbs | oh, hai egbuilder |
| # | 23:34:36 | egbuilder | build #3 of evergreen-rel_1_6_1-debian-6.00-x86_64 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_1_6_1-debian-6.00-x86_64/builds/3 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:34:40 | egbuilder | build #2 of evergreen-rel_1_6_1-ubuntu-10.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_1_6_1-ubuntu-10.04-x86/builds/2 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:35:35 | egbuilder | build #8 of evergreen-rel_2_0-ubuntu-8.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_2_0-ubuntu-8.04-x86/builds/8 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:36:01 | egbuilder | build #22 of evergreen-rel_2_1-ubuntu-8.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_2_1-ubuntu-8.04-x86/builds/22 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:36:26 | egbuilder | build #822 of evergreen-master-ubuntu-8.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-8.04-x86/builds/822 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:36:46 | egbuilder | build #2 of evergreen-rel_1_6_1-ubuntu-8.04-x86 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-rel_1_6_1-ubuntu-8.04-x86/builds/2 blamelist: (no author)@dcc99617-32d9-48b4-a31d-7c20da2025e4 |
| # | 23:37:00 | egbuilder | build #3 of osrf-rel_2_0-ubuntu-10.04-x86_64 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-rel_2_0-ubuntu-10.04-x86_64/builds/3 blamelist: (no author)@9efc2488-bf62-4759-914b-345cdb29e865 |
| # | 23:37:08 | egbuilder | build #139 of osrf-master-ubuntu-10.04-x86_64 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-master-ubuntu-10.04-x86_64/builds/139 blamelist: (no author)@9efc2488-bf62-4759-914b-345cdb29e865 |
| # | 23:37:15 | egbuilder | build #3 of osrf-rel_1_6-ubuntu-10.04-x86_64 is complete: Failure [failed git] Build details are at http://testing.evergreen-ils.org/buildbot/builders/osrf-rel_1_6-ubuntu-10.04-x86_64/builds/3 blamelist: (no author)@9efc2488-bf62-4759-914b-345cdb29e865 |
| # | 23:45:35 | jeff | so what's with the git errors there? "fatal: Could not parse object '447804235769446d52859453a3274e8cd466b290'." |
| # | 23:45:44 | jeff | (from http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-8.04-x86/builds/822/steps/git/logs/stdio ) |
| # | 23:45:52 | egbuilder has quit IRC |
| # | 23:46:19 | egbuilder has joined #evergreen |
| # | 23:47:54 | rangi | holy bad build bataman |
| # | 23:48:05 | rangi | holy bad typing |
| # | 23:48:11 | dbs | jeff: working on it |
| # | 23:48:34 | jeff | dbs: figured -- i'll be interested to hear when you're done. i'm just curious. :) |
| # | 23:49:23 | dbs | basically, it looks like 1) putting the working directories for the git repos into /tmp was a bad idea because 2) the build server that ESI supplied is an Ubuntu machine which 3) has a default policy of deleting /tmp contents on reboot and 4) the server rebooted a day or two ago |
| # | 23:50:00 | rangi | ahhh |
| # | 23:50:13 | dbs | and 5) buildbot tries to do a git reset --hard <commit> in the directory but doesn't notice that the git repo files are all gone, so just errors out |
| # | 23:50:37 | jeff | got it! |
| # | 23:52:19 | dbs | son of a ... |
| # | 23:52:42 | dbs | and with the change of working dirs, we're back to building everything from the dawn of time. AWESOME. |
| # | 23:53:11 | egbuilder has quit IRC |
| # | 23:53:55 | jeff | i'm imagining some Very Important voiceover over a shot of the sun rising over a very barren landscape... |
| # | 23:54:53 | rangi | its the rapture for buildbots |
| # | 23:54:59 | egbuilder has joined #evergreen |
| # | 23:55:37 | dbs nukes that build config, turns off builds so that the bot can chew through the 3000 revisions, and goes to bed |
| # | 23:55:46 | dbs | egbuilder: status |
| # | 23:55:46 | egbuilder | evergreen-master-debian-6.00-x86_64: offline |
| # | 23:55:47 | egbuilder | evergreen-master-ubuntu-10.04-x86: idle |
| # | 23:55:47 | egbuilder | evergreen-master-ubuntu-8.04-x86: idle |
| # | 23:55:47 | egbuilder | evergreen-rel_1_6_1-debian-6.00-x86_64: offline |
| # | 23:55:47 | egbuilder | evergreen-rel_1_6_1-ubuntu-10.04-x86: idle |
| # | 23:55:47 | egbuilder | evergreen-rel_1_6_1-ubuntu-8.04-x86: idle |
| # | 23:55:47 | egbuilder | evergreen-rel_2_0-debian-6.00-x86_64: offline |
| # | 23:55:48 | egbuilder | evergreen-rel_2_0-ubuntu-10.04-x86: idle |
| # | 23:55:48 | egbuilder | evergreen-rel_2_0-ubuntu-8.04-x86: idle |
| # | 23:55:49 | egbuilder | evergreen-rel_2_1-debian-6.00-x86_64: offline |
| # | 23:55:49 | egbuilder | evergreen-rel_2_1-ubuntu-10.04-x86: idle |
| # | 23:55:50 | egbuilder | evergreen-rel_2_1-ubuntu-8.04-x86: idle |
| # | 23:55:50 | egbuilder | osrf-master-ubuntu-10.04-x86_64: offline |
| # | 23:55:51 | egbuilder | osrf-rel_1_6-ubuntu-10.04-x86_64: offline |
| # | 23:55:53 | jeff | "the dawn of time, when buildbots rules the earth..." |
| # | 23:57:39 | dbs | on the bright side, at least buildbot wasn't able to email anyone about its git failures - no email addresses to pick out of the commits |
| # | 23:58:12 | dbs | (which would be a valid reason why we want email addresses associated with committer accounts, actually) |
| # | 23:58:29 | dbs | ... because there were no commits that it could fetch :) |
April 10-13