| # | Time | Nick | Message |
|---|
| # | 00:01:49 | denials | miker_++ # speedups |
| # | 00:02:08 | denials | berick++ # going into the dojo dnd where others (ME) fear to tread |
| # | 00:02:56 | denials | sleep++ |
| # | 01:40:57 | youdonotexist has quit IRC |
| # | 01:59:06 | jamesrf has quit IRC |
| # | 03:03:33 | magnusenger has joined #evergreen |
| # | 05:17:25 | atz_ has joined #evergreen |
| # | 05:20:23 | atz__ has quit IRC |
| # | 07:41:54 | kmlussier has joined #evergreen |
| # | 08:01:23 | sfortin has joined #evergreen |
| # | 08:15:39 | alxp has joined #evergreen |
| # | 08:30:46 | Dyrcona has joined #evergreen |
| # | 08:52:36 | gdunbar has joined #evergreen |
| # | 08:55:05 | dbs has joined #evergreen |
| # | 09:00:08 | StephenGWills_ has joined #evergreen |
| # | 09:01:24 | mck9 | dbs: you have upgrade scripts 0380, 0381, and 0382 in trunk. Should they be applied to v2.0? |
| # | 09:02:18 | StephenGWills has quit IRC |
| # | 09:02:18 | StephenGWills_ is now known as StephenGWills |
| # | 09:02:21 | dbs | mck9: only if the corresponding updates to the rest of the code are backported to v2.0 |
| # | 09:04:00 | mck9 | That's what I'm asking. I'm building an upgrade script for 1.6 -> 2.0, and I need to know what to include. Do you plan to apply them to the 2.0 branch? |
| # | 09:05:26 | dbs | Sorry. You asked if the upgrade scripts should be applied to v2.0, and I responded that right now they shouldn't be because the corresponding changes to the rest of the code have not been backported to 2.0. |
| # | 09:06:25 | dbs | If you meant to ask "Are you going to backport your currently trunk-only changes to v2.0?' then I would respond that yes, I plan to at some point. I can always update your 1.6-2.0 upgrade script at that point. |
| # | 09:06:55 | Meliss has joined #evergreen |
| # | 09:07:15 | bshum has joined #evergreen |
| # | 09:07:21 | dbs | mck9++ # for tackling the upgrade script |
| # | 09:08:09 | mck9 | My upgrade script is still aborning. In general I'll try to include whatever upgrade scripts show up in the 2.0 branch. I just don't want anything to fall between the stools. |
| # | 09:09:48 | gmcharlt | mck9: I suggest just writing the script to handle updates up to the state of rel_2_0 as it exists this morning - tacking on updates for stuff that gets merged into rel_2_0 later should be simple in comparison |
| # | 09:11:41 | r123 has joined #evergreen |
| # | 09:30:36 | StephenGWills has quit IRC |
| # | 09:31:44 | StephenGWills has joined #evergreen |
| # | 09:44:25 | jenny has joined #evergreen |
| # | 09:50:11 | tsbere is looking through the changes that phasefx made to the rel_2_0 staff client (that change how he does things with his tabs) and likes the number of things removed that he didn't want to touch before |
| # | 09:51:38 | dbs | removing_cruft++ |
| # | 09:54:27 | tsbere | Figuring out how the set_tab function changed from my diff file is difficult, though. It broke it up funny. |
| # | 09:56:07 | tsbere | Oh, so that is what he did with the augment content params. He just jammed it into set_tab. <_< |
| # | 10:08:50 | tsbere re-implements something phasefx removed in a slightly different manner because he will need it later |
| # | 10:15:32 | mrpeters-isl has joined #evergreen |
| # | 10:23:43 | yboston has joined #evergreen |
| # | 10:33:39 | tsbere | I just realized that I have no clue how to access staff.chrome.menu_frame_overlay.tab#.accesskey via javascript. |
| # | 10:34:27 | tildeequals has quit IRC |
| # | 10:35:13 | senator | tsbere: i don't believe you can, but for i18n-able strings accessible from javascript, there are the .properties files (for use in a XUL context, i think they're called "message catalogs") or dojo stringbundles for a html context |
| # | 10:37:57 | tsbere | So either I hardcode the access keys as 1-9 or 1-0, or I need a different way to get access to them to assign them. |
| # | 10:39:50 | phasefx | document.getElementById('some_tab').setAttribute('accesskey','1'); ? |
| # | 10:41:01 | tsbere | I see three things I don't like or know won't work in that. 1 - I don't assign ids to the dynamic tabs. 2 - I just use .accesskey=. 3 - I was trying to avoid hardcoding the '1' as the current ones are potentially changable with the translation files. |
| # | 10:41:03 | phasefx | document.getElementById('some_tabbox').tabs[1].setAttribute('accesskey','1'); |
| # | 10:41:53 | senator | tsbere: re your point #3 you can replace '1' with document.getElementById("your_string_bundle").getString("your.accesskey.1") |
| # | 10:42:01 | phasefx | as to how well accesskeys work if mucked with dynamically, I'm not sure |
| # | 10:43:11 | senator | assuming you have <messagecatalog id="your_string_bundle" src="/your/path" /> somewhere in your XUL |
| # | 10:43:23 | senator | better still to stick in it an existing stringbundle rather than add a new one though, really |
| # | 10:43:44 | senator | s/stringbundle/messagecatalog/; # potato, po-tah-toe |
| # | 10:43:44 | phasefx | offline.properties is what I've been using for chrome side stuff, I think |
| # | 10:44:27 | tsbere | Well, dynamic accesskeys are fine, I already tested that. |
| # | 10:44:38 | phasefx | cool deal |
| # | 10:45:59 | tsbere | As for what to use, the existing access keys are defined already in lang.dtd as staff.chrome.menu_frame_overlay.tab#.accessKey. Although the "tab names" being there makes no sense to me as I don't think they are ever used. |
| # | 10:48:38 | youdonotexist has joined #evergreen |
| # | 10:49:58 | jamesrf has joined #evergreen |
| # | 10:50:54 | tsbere | I *think* that every translation just uses the 1-9 digits, though |
| # | 10:59:30 | tsbere | Looks like they all use &# or have a blank translation |
| # | 11:01:43 | tsbere goes the hardcode route for now |
| # | 11:02:03 | tsbere | The numbers themselves were hardcoded anyway. |
| # | 11:02:19 | phasefx | tsbere: you don't need to worry about other translations if you just want to put translatable strings in the en-US locale |
| # | 11:03:14 | tsbere | the issue is I don't know how to *read* the translated strings out from the javascript side in any quick and easy way. Nor does this seem like something that should ever have been in the translation files to begin with to me. |
| # | 11:04:10 | phasefx | are you working in menu.js or elsewhere? |
| # | 11:05:29 | tsbere | At this point in menu.js. For the record, the numbers themselves were always just a hardcode of the index value + 1 anyway, so if we are intending to translate the access keys we need to translate the numbers themselves too, IMO. Which I think is stupid. :P |
| # | 11:05:57 | tsbere | Especially as my code could theoretically allow hundreds of tabs |
| # | 11:06:28 | phasefx | don't think of it as necessarily translating, but localizing |
| # | 11:06:30 | tsbere is thinking about manually specifying a limit of 50 or something for sanity purposes |
| # | 11:07:00 | phasefx | for example, some folks may want to use Alt+Numberpad to enter weird characters, and not have those keys jump between tabs |
| # | 11:07:02 | dbs | Start assigning Unicode codepoints as access keys. CTRL+SHIFT+U 2603 |
| # | 11:07:37 | dbs | Those folks certainly exist at Laurentian |
| # | 11:07:53 | dbs | ALT+0030 |
| # | 11:08:01 | tsbere | So what changes do I have to make to files to get access to those lang.dtd values from menu.js? |
| # | 11:08:11 | phasefx | and if we made the first 10 tabs have localizable accesskeys, Laurentian could use some key shortcuts and retain the tab-jumping functionality |
| # | 11:08:41 | phasefx | tsbere: you remove them from lang.dtd, and put them in locale/en-US/offline.properties |
| # | 11:08:43 | senator | ☃. Love it. |
| # | 11:09:18 | atz_ | http://unicodesnowmanforyou.com/ |
| # | 11:09:19 | phasefx | then in menu.js, since offlineStrings is already defined, you can just do offlineStrings.getString('identifier_here') to reference the strings in offline.properties |
| # | 11:10:01 | gmcharlt | atz_: it's part of the feature that ties into the weather.com API and lets library staff know to close the library because it's a snow day |
| # | 11:10:37 | senator guesses it'd have to be a heck of snow day by his standards to close laurentian |
| # | 11:11:42 | tsbere | So phasefx, if I add to offline.properties, is that going to break the translation scripts until someone updates those too? |
| # | 11:12:13 | dbs | no, the translation scripts are pretty hardy (hahahahaha) |
| # | 11:12:29 | dbs | tsbere: seriously, though, go ahead and add strings as necessary |
| # | 11:12:31 | phasefx | tsbere: it won't. folks are supposed to go through a certain build process if they want to use locales other than en-US, and that process will copy the English strings over if no translations have been made |
| # | 11:12:42 | tsbere | ok |
| # | 11:12:52 | phasefx | dbs++ # making it low-barrier |
| # | 11:13:46 | phasefx | remote_xul-- # for making us implement messagecat as a replacement to xul's native stringbundle |
| # | 11:14:18 | phasefx | we could use stringbundle in chrome, but no reason not to keep exercising messagecat |
| # | 11:15:49 | tsbere | What happens if I getString for a value that doesn't exist? |
| # | 11:16:39 | phasefx | it'll throw up an alert dialog I believe, or an exception at the very least |
| # | 11:17:13 | phasefx | the implementation for <messagecat> can be found in bindings.xml |
| # | 11:18:24 | phasefx | an alert, Failed to get string <key> in bundle: <filename.properties> |
| # | 11:18:55 | phasefx | there's also a .getFormattedString if you want to use variable data within the string |
| # | 11:19:44 | tsbere looks at bindings.xml and finds the potentially excessively useful testString method |
| # | 11:22:12 | phasefx | so you want to potentially have accesskeys for as many tabs as folks are willing to localize for |
| # | 11:22:20 | tsbere | Yep. |
| # | 11:22:24 | phasefx | cool deal |
| # | 11:22:26 | tsbere | Makes the code easier too, actually. |
| # | 11:32:37 | afterl has joined #evergreen |
| # | 11:33:58 | tsbere dislikes that the close button for tabs in a tabbox was removed in 1.9.2 xulrunner |
| # | 11:40:23 | LBA has joined #evergreen |
| # | 11:48:00 | atz_ is now known as atz |
| # | 12:05:17 | jeff | printing-- |
| # | 12:05:43 | tsbere tests his tabs code by making 600 tabs in a window, then closing them from various points |
| # | 12:05:43 | jeff | reports from patrons that receipts are fading after a day or two. very odd. i wonder if we just started using different paper. |
| # | 12:05:55 | atz | lol tsbere |
| # | 12:07:03 | tsbere | I much prefer being able to make large numbers of tabs over being limited to 9. :D |
| # | 12:07:31 | branflakes has quit IRC |
| # | 12:17:10 | tsbere | Hey, what code was it that supposedly just overwrote tabs as it felt it needed to? |
| # | 12:22:20 | leed has quit IRC |
| # | 12:26:28 | phasefx | ? |
| # | 12:27:02 | tsbere | I recall someone saying at some point that some function that opened multiple tabs would loop around and start overwriting existing tabs. Might have been something experimental itself, though. |
| # | 12:31:24 | phasefx never wrote anything intending that behavior, so doesn't know |
| # | 12:32:14 | phasefx | maybe it was from some race condition with dom manipulation and lot of async new_tab invocations? |
| # | 12:45:02 | leed has joined #evergreen |
| # | 12:55:25 | sfortin has quit IRC |
| # | 13:02:28 | kmlussier has quit IRC |
| # | 13:04:09 | tsbere | I decided that hardcoding a max tabs amount of 50 or any other number was a bad idea. |
| # | 13:04:26 | tsbere | But I threw in a check for a open-ils.window_max_tabs pref. |
| # | 13:05:15 | tsbere | (which defaults to 0 in my code if it isn't there, and 0 means "no limit") |
| # | 13:07:47 | kmlussier has joined #evergreen |
| # | 13:08:41 | jenny has left #evergreen |
| # | 13:11:11 | tsbere really should have worked with a copy of his code that didn't have the cli changes already in it when doing this |
| # | 13:15:30 | tsbere | phasefx: Should I just build a new cli.patch with all of these changes in it (some of which would conflict with the changes in cli.patch) or should I try and make a new patch? |
| # | 13:16:18 | dbs | we should move to a gitbzrhg repo to make it easier for people to maintain parallel branches |
| # | 13:16:48 | tsbere | I am waiting on someone who is on vacation before attempting to get a git repo going here. <_< |
| # | 13:18:07 | dbs | then fulfillment and evergreen could just be branches of one other, rather than completely separate repos |
| # | 13:20:36 | phasefx | tsbere: oy, I'm not sure. Don't have much experience with patch wrangling. Ideally I'd just be testing/committing one feature at a time, but if stuff is getting mingled, I could adapt |
| # | 13:26:25 | rsoulliere has joined #evergreen |
| # | 13:26:26 | berick | dbs: even if FF/EG are different repos (which makes sense to me), w/ gitbzrhg you can do cross-repo merging, almost as if they were branches |
| # | 13:26:38 | phasefx | tsbere: if you don't want to wait for that vacationer, you could setup a bazaar branch on launchpad |
| # | 13:27:06 | berick | git remote add Fulfillment |
| # | 13:27:10 | tsbere | Getting git going will slow me down too. Need to learn it. :P |
| # | 13:27:22 | senator | buy some aspirin :-) |
| # | 13:27:29 | berick | hah |
| # | 13:27:50 | berick | true, it's not w/o it's own brand of pain |
| # | 13:27:59 | dbs | berick: okay. I've found it kind of kludgy using *-svn compared to working with one of the native gitbzrhgs and usually end up working without a local repo as a result |
| # | 13:28:24 | phasefx | weirdest thing with git for me (having come from svn) is re-using the same physical directories when jumping between branches |
| # | 13:29:33 | berick | dbs: oh, i agree. i was trying to add some points on the side of dropping svn entirely, just not on the side of making FF an EG branch |
| # | 13:30:00 | berick also has pain with *-svn |
| # | 13:30:19 | berick | phasefx: it does feel odd ;) |
| # | 13:30:24 | phasefx has adapted to git-svn, no issues there anymore |
| # | 13:30:42 | dbs | berick: ah, cool. I like that. |
| # | 13:31:04 | dbs | it's been 3 or 4 years since we switched to svn, just about time to move again :) |
| # | 13:31:05 | phasefx | berick: as a downside, it's harder to use not-repository aware tools that I might be tempted to use otherwise, like vimdiff (and the DirDiff plugin) |
| # | 13:31:28 | phasefx | an Evergreen expansion pack :) |
| # | 13:31:40 | phasefx | about time for cataclysm |
| # | 13:32:25 | dbs | cool, I need more MTG keywords in my blog to steal more traffic from the real Dan Scott |
| # | 13:32:29 | tsbere uploaded a new patch |
| # | 13:36:58 | rsoulliere has quit IRC |
| # | 13:38:57 | jenny1 has joined #evergreen |
| # | 14:02:07 | jenny1 has quit IRC |
| # | 14:14:37 | jenny has joined #evergreen |
| # | 14:34:11 | rsoulliere has joined #evergreen |
| # | 14:42:51 | rsoulliere has left #evergreen |
| # | 14:49:45 | tildeequals has joined #evergreen |
| # | 14:53:56 | StephenGWills thinks that some days are just better than others! :) |
| # | 14:54:49 | tildeequals has quit IRC |
| # | 14:55:10 | tildeequals has joined #evergreen |
| # | 15:02:02 | magnusenger has quit IRC |
| # | 15:02:50 | StephenGWills_ has joined #evergreen |
| # | 15:04:15 | mrpeters-isl has quit IRC |
| # | 15:05:54 | StephenGWills has quit IRC |
| # | 15:05:54 | StephenGWills_ is now known as StephenGWills |
| # | 15:15:56 | jenny has quit IRC |
| # | 15:19:51 | zigo_ has joined #evergreen |
| # | 15:20:38 | dbs has quit IRC |
| # | 15:21:23 | zigo_ | Hi there! |
| # | 15:21:40 | zigo_ | I heard about Evergreen in the FLOSS weekly podcast. |
| # | 15:21:46 | zigo_ | I'm a Debian Developer. |
| # | 15:21:49 | jeff | zigo_: greetings! |
| # | 15:21:59 | zigo_ | And I was wondering if you still need help for doing the packaging ... |
| # | 15:22:09 | jeff | I think we'd welcome any help we can get. |
| # | 15:22:26 | zigo_ | I can teach / help / advise if you need. |
| # | 15:22:50 | jeff | One of the challenges with packaging is that we have several third party dependencies that are not packaged in Debian, or the most recent package is too old for Evergreen. |
| # | 15:22:50 | zigo_ | Jeff: Is that you that answered the questions of Randalf? |
| # | 15:23:13 | zigo_ | Well, in that case, you need to package them. |
| # | 15:23:18 | zigo_ | No choice ! |
| # | 15:23:19 | jeff | zigo_: I was in the IRC channel during the podcast and answered a question or two. |
| # | 15:23:44 | jenny has joined #evergreen |
| # | 15:23:49 | zigo_ | How many dependencies are we talking about here? |
| # | 15:24:06 | zigo_ | And what kind of packages? CPAN perl stuff? |
| # | 15:25:45 | jeff | zigo_: there is OpenSRF and Evergreen. Evergreen is built on OpenSRF. They both have their own dependencies. There are Makefiles for installing those deps, both via package (when available) and source or CPAN: |
| # | 15:25:49 | jeff | http://svn.open-ils.org/trac/OpenSRF/browser/trunk/src/extras/Makefile.install |
| # | 15:26:23 | jeff | http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/extras/Makefile.install |
| # | 15:26:27 | zigo_ | Have you guys sent an RFA to Debian? |
| # | 15:26:35 | zigo_ | RFA = Request For Packaging |
| # | 15:26:38 | jeff | I do not know. |
| # | 15:26:50 | phasefx | not that I'm aware of |
| # | 15:26:51 | zigo_ | That would be the first step. |
| # | 15:27:13 | jeff | Also, we use libdbi, and require 0.8.3 -- 0.8.2 is the latest packaged in debian |
| # | 15:27:14 | zigo_ | Then maybe contact the Perl team at Debian, and see what they would be up to. |
| # | 15:27:18 | zigo_ | Tell about your issue. |
| # | 15:27:25 | zigo_ | Oh, I'm the maintainer of libdbi ! :) |
| # | 15:27:31 | berick | whoa! |
| # | 15:27:31 | pmplett has joined #evergreen |
| # | 15:27:41 | zigo_ | I am DD only since last June. |
| # | 15:27:44 | jeff | Hah! That's an amusing coincidence! |
| # | 15:27:46 | zigo_ | That's the issue... |
| # | 15:27:59 | zigo_ | I needed to updated many packages, but libdbi couldn't get in. |
| # | 15:28:04 | moodaepo | amusing_coincidences++ |
| # | 15:28:12 | zigo_ | It would have need a transition. |
| # | 15:28:22 | zigo_ | So I had no time to do it before Squeeze... |
| # | 15:28:26 | zigo_ | Sorry for that. |
| # | 15:28:32 | zigo_ | But I got a new version of the package. |
| # | 15:28:42 | zigo_ | It's ready in my laptop just right here. |
| # | 15:29:03 | zigo_ | Oh, and forgot to say: we can't upgrade because of an ABI that upstream made. |
| # | 15:29:05 | jeff | "DD only"? |
| # | 15:29:13 | zigo_ | Debian Developer |
| # | 15:29:22 | zigo_ | tmd tla ... :P |
| # | 15:29:24 | jeff | aha |
| # | 15:29:48 | zigo_ | So, upstream changed the enum for error codes without changing his so name ... |
| # | 15:30:03 | zigo_ | Said otherwise: we got stucked. |
| # | 15:30:29 | zigo_ | Now, I'm waiting for upstream to release a new version of libdbi with a new soname so that I can upload 0.8.4 in Experimental. |
| # | 15:30:55 | zigo_ | If you guys want, I can give you the current 0.8.3 version of libdbi ... |
| # | 15:31:08 | jeff | yeah, i was just reading the bug on that abi issue... |
| # | 15:31:11 | zigo_ | But extra care should be made when using it, because anything that needs it has to be rebuilt. |
| # | 15:32:40 | zigo_ | So, appart from libdbi, it's mainly some perl packages? |
| # | 15:32:43 | zigo_ | How many of them? |
| # | 15:32:55 | kmlussier has quit IRC |
| # | 15:34:27 | phasefx | zigo_: take a peek at that URL jeff pasted |
| # | 15:35:28 | jamesrf has quit IRC |
| # | 15:36:26 | phasefx | over 20 it looks like |
| # | 15:36:28 | zigo_ | DateTime::Format::ISO8601 RHANDOM/Net-Server-0.90.tar.gz JSON::XS |
| # | 15:36:31 | zigo_ | Oh ! |
| # | 15:36:42 | zigo_ | I don't know much about Perl, unfortunately. |
| # | 15:36:58 | zigo_ | But really, you should get in touch with the perl packaging team in Debian. |
| # | 15:37:07 | zigo_ | Or ... I teach you the basics of Debian packaging. |
| # | 15:37:15 | zigo_ | Maybe: both ! |
| # | 15:38:37 | zigo_ | Also, not having some missing dependencies doesn't mean you can't start the packaging work. |
| # | 15:38:47 | zigo_ | Do you guys have some kind of DESTDIR= support? |
| # | 15:39:29 | zigo_ | I mean, normally, you got to install the app in the debian/opensrf/usr/share folder ... |
| # | 15:41:27 | phasefx | there's been work to autotoolsify the build. I'm not familiar with how it works, but I think DESTDIR comes with that |
| # | 15:41:45 | zigo_ | Do you have such a "make install DESTDIR=debian/opensrs support? |
| # | 15:41:55 | zigo_ | Oh ok. |
| # | 15:42:09 | zigo_ | That would be the first thing to try! :) |
| # | 15:42:34 | jeff | there's the ability to speficy --prefix with ./configure, but i don't know how well-tested anything other than /openils is. |
| # | 15:43:04 | zigo_ | No, the --prefix has nothing to do with what I'm talking about. |
| # | 15:43:10 | jeff | k. |
| # | 15:43:12 | zigo_ | Here, the --prefix would still be /usr |
| # | 15:43:48 | zigo_ | It's just that instead of installing in / (the root of the filesystem), you got to install in debian/package-name so that later on, dh_* tools can build the binary package. |
| # | 15:43:57 | jeff | you're talking about the temporary buildroot/fakeroot/something -- yeah, right. |
| # | 15:44:00 | jeff | got it. |
| # | 15:44:20 | zigo_ | There's many ways to build a package, but most of the time, we use "debheper" |
| # | 15:44:30 | zigo_ | It's a set of scripts to build it... |
| # | 15:44:46 | zigo_ | Do: apt-get install build-essential devscripts |
| # | 15:44:46 | atz | debhelper |
| # | 15:44:57 | zigo_ | Then do dh_[TAB] to see them all ... |
| # | 15:45:08 | zigo_ | yup sorry |
| # | 15:45:10 | zigo_ | debhelper |
| # | 15:47:53 | atz | one problem we have is that we don't actually move everything through the make install process... the support-scripts for example are still called from their uninstalled repo location |
| # | 15:49:48 | phasefx | are they? |
| # | 15:49:58 | zigo_ | Hum... That's your internal stuff that I shouldn't care too much about, isn't it? :) |
| # | 15:52:48 | jamesrf has joined #evergreen |
| # | 15:54:48 | eby has quit IRC |
| # | 15:55:11 | phasefx | zigo_: how easy is it to automate and maintain things once implemented? |
| # | 15:55:32 | zigo_ | What do you mean? |
| # | 15:55:42 | alxp has quit IRC |
| # | 15:56:16 | jeff | zigo_: what is involved in packaging a new version of Evergreen for debian? What tooks are available to automate that process, what concerns are there in terms of sid, then testing, etc? |
| # | 15:56:20 | eby has joined #evergreen |
| # | 15:56:57 | zigo_ | You will be packaging for SID until the next release of Debian. |
| # | 15:57:06 | phasefx | zigo_: for example, I assume our project would need someone empowered/willing to maintain things as the software changes, the surrounding environment changes, etc. How much effort might such a person expect to exert an ongoing basis? |
| # | 15:57:07 | zigo_ | As Squeeze is currently frozen, you can't target it. |
| # | 15:57:33 | zigo_ | In Debian, each package is normally maintain by a unique person. |
| # | 15:57:47 | zigo_ | It could be by a team though ... |
| # | 15:58:04 | tsbere | Anyone mention the "ejabberd needs config messed with" part of this yet? |
| # | 15:58:09 | zigo_ | But there has to be an email and some identified individuals behind an email. |
| # | 15:58:20 | jeff | tsbere: shh! ;-) |
| # | 15:58:25 | StephenGWills_ has joined #evergreen |
| # | 15:58:43 | zigo_ | If you want to do the maintainership of the package yourself, then you got to have a PGP key in the web of trust in Debian. |
| # | 15:59:03 | phasefx whispers, and how do we apt-get install across a cluster of machines and get them all to sync up :D |
| # | 15:59:11 | zigo_ | That means that you have to see a Debian Developer in real life so that he checks your passport / ID card and sign your PGP key. |
| # | 15:59:31 | zigo_ | Where are you guys living in? USA mostly? |
| # | 15:59:41 | jeff | zigo_: so if we have a requirement that an erlang config file be modified in order for opensrf to run -- can debconf help with that, or do we just call an external script to make the changes to /etc/ejabberd/ejabberd.cfg? |
| # | 16:00:30 | zigo_ | Every files in /etc are considered config files. |
| # | 16:00:41 | zigo_ | No config files can be installed somewhere else than /etc |
| # | 16:00:50 | zigo_ | Files in /etc can be configured by debconf, that's not a problem. |
| # | 16:00:51 | tsbere | Not what was asked. |
| # | 16:00:56 | tsbere | That was what was asked |
| # | 16:01:07 | zigo_ | But if you edit /etc by hand, then debconf has to see the change and take it into account. |
| # | 16:01:19 | shadowspar | re: perl module packaging -- one of the debhelper scripts gets you >90% of the way there |
| # | 16:01:23 | shadowspar | dh-make-perl |
| # | 16:01:23 | tsbere thinks we knew that stuff in /etc was config files, but just realized that opensrf doesn't keep config files in /etc |
| # | 16:01:51 | zigo_ | Also, you got to take care that debconf can be ran in non-interactive mode. |
| # | 16:01:56 | zigo_ | So there has to be good default values. |
| # | 16:02:07 | zigo_ | (or a way to live without them being configured) |
| # | 16:02:21 | shadowspar | is having one package modify another packages config files allowed, though? |
| # | 16:02:31 | shadowspar | or do we have to work around that...? |
| # | 16:02:34 | zigo_ | It's NOT allowed. |
| # | 16:02:36 | StephenGWills has quit IRC |
| # | 16:02:36 | StephenGWills_ is now known as StephenGWills |
| # | 16:02:40 | shadowspar | maybe with a separate ejabberd instance then |
| # | 16:02:49 | zigo_ | The workaround is to have a shell script in userland to do it. |
| # | 16:02:52 | zigo_ | But it's quite ugly. |
| # | 16:03:17 | zigo_ | What would you need to modify for example? |
| # | 16:03:30 | phasefx | zigo_: for software that can run in clusters, I imagine it's common to just install a single-server configuration by default and let folks change things manually if they want otherwise? |
| # | 16:03:37 | jeff | various max-user max-stanza size settings in ejabberd.cfg |
| # | 16:03:44 | tsbere | And disabling offline messages |
| # | 16:03:45 | sfortin has joined #evergreen |
| # | 16:04:16 | jeff | zigo_: documented in step 6 here: http://evergreen-ils.org/dokuwiki/doku.php?id=opensrf:1.2:install |
| # | 16:04:31 | jeff | zigo_: also, there are things like creating ejabberd accounts, etc. |
| # | 16:05:07 | jeff | zigo_: basically, everything in http://evergreen-ils.org/dokuwiki/doku.php?id=opensrf:1.2:install and http://evergreen-ils.org/dokuwiki/doku.php?id=server:1.6.0:install needs to be done. see any other "gotchas" where "you can't do that within debian policy"? |
| # | 16:05:09 | Meliss has quit IRC |
| # | 16:05:17 | zigo_ | Another workaround would be to have a specific package for yourself with different config files... |
| # | 16:05:53 | zigo_ | Well, I read that document, but it doesn't really tell what "make -f src/extras/Makefile.install squeeze" does ... |
| # | 16:06:08 | shadowspar | I'd actually be very interested in going through the process to become a DM/DD myself, but I have to see if my new job will support the time investment needed |
| # | 16:06:41 | zigo_ | shadowspar: The first step is to create a PGP key and have it signed. |
| # | 16:06:53 | zigo_ | It can't hurt to do it even if you will change your mind... |
| # | 16:06:57 | jeff | zigo_: for that, you'd need to read the Makefiles, which I pasted links to earlier: |
| # | 16:07:06 | jeff | http://svn.open-ils.org/trac/OpenSRF/browser/trunk/src/extras/Makefile.install |
| # | 16:07:12 | jeff | http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/extras/Makefile.install |
| # | 16:07:17 | shadowspar | zigo_: apt-get install <many packages>; then run the perl CPAN installer to install perl modules, plus other tweaks iirc |
| # | 16:07:33 | shadowspar | zigo_: good point, I should see if I know anyone in the debian web of trust =) |
| # | 16:08:13 | zigo_ | http://db.debian.org |
| # | 16:08:16 | zigo_ | take your pick ... |
| # | 16:08:20 | zigo_ | Find a DD nearby. |
| # | 16:08:59 | zigo_ | There's a page especially for key signing process, but I can't find it... :( |
| # | 16:09:15 | jeff | http://wiki.debian.org/Keysigning/Offers#US |
| # | 16:09:46 | zigo_ | http://wiki.debian.org/Keysigning |
| # | 16:09:51 | zigo_ | Yes. |
| # | 16:11:08 | zigo_ | shadowspar: I would suggest you to remove all these "apt-get install <many-package" from the install target and put that in another name. |
| # | 16:11:16 | zigo_ | install should just install, nothing more ... |
| # | 16:11:31 | zigo_ | make install-debian-depends |
| # | 16:11:35 | zigo_ | for example ... |
| # | 16:11:47 | zigo_ | And that until you got a Debian package in shape. |
| # | 16:11:51 | tsbere | Those makefiles are part of the prereq step. The top level makefile still needs to be configured/run. |
| # | 16:12:04 | zigo_ | Oh ok. |
| # | 16:12:17 | zigo_ | I have to admit I didn't try to install ... :) |
| # | 16:12:35 | zigo_ | I'm willing to help, but I don't really need to run a library myself ... :) |
| # | 16:13:04 | sylvar | I've been wanting to add Facebook 'Like' buttons to rdetail.xml pages, but Facebook doesn't wait for dojo to fetch the metadata. I'm open to suggestions. |
| # | 16:13:40 | tsbere | sylvar: Add the like buttons via the dojo metadata filling functions, however that is working? |
| # | 16:13:50 | zigo_ | Question: what is opensrf exactly? |
| # | 16:14:22 | sylvar | tsbere: Hmm. That might work. |
| # | 16:14:50 | jeff | sylvar: you'll probably want to use one of the unapi urls as the canonical url |
| # | 16:15:45 | jeff | sylvar: and i think it's worth considering linking to the metarecord instead of the record. i don't recall if there's an unapi link for that readily available where you'd want it, though. |
| # | 16:16:51 | dbs has joined #evergreen |
| # | 16:17:05 | dbs jumps in, waves excitedly at zigo_ |
| # | 16:17:24 | zigo_ | :) |
| # | 16:17:36 | sylvar is going to be learning unapi, it seems :) |
| # | 16:17:43 | jeff | sylvar: also, i'm fairly certain the default implementation of the Like button leaks your patron's browsing habits to facebook. If that can be worked around, great. Otherwise, need a way for libraries and patrons to turn if off. :P |
| # | 16:17:50 | zigo_ | Oh, another suggestion: it would be good if your tarball was doing opensrf-1.2.2 and not OpenSRF-1.2.2 ... |
| # | 16:18:05 | zigo_ | Otherwise, we got to repack it to build the Debian package. |
| # | 16:18:31 | dbs | zigo_: I've been building the OpenSRF releases recently, I'll be happy to change the naming conventions |
| # | 16:19:15 | phasefx | zigo_: re: opensrf, it's a framework that services run on top of, and it handles message passing between those services |
| # | 16:19:32 | dbs | zigo_: we started adding DESTDIR support but it's still flaky. It would probably make sense to start with a goal of packaging OpenSRF first, as the footprint is smaller; then we can apply what we've learned to Evergreen |
| # | 16:19:47 | jeff | sylvar: i'm not certain if the opengraph meta tags can be used dynamically with the like button, or if they rely on unique server-generated content for urls: http://developers.facebook.com/docs/opengraph |
| # | 16:20:29 | dbs | zigo_: having somebody who's been through the packaging process a few times willing to provide guidance like this is a godsend, thanks for dropping by |
| # | 16:21:03 | sylvar | jeff: yeah, my first attempt is using createElement/setAttribute/appendChild to retroactively add meta tags to head. |
| # | 16:21:34 | zigo_ | dbs: I know how painful it can be, because I had to go through it... |
| # | 16:21:38 | tsbere | sylvar: I don't think that works |
| # | 16:22:00 | sylvar | tsbere: I think you're correct. :) |
| # | 16:22:36 | jeff | sylvar: that probably works, as long as you don't see facebook request the url after you Like it. i believe all of the Like button implementations just fetch the og: meta tags from the dom. |
| # | 16:25:01 | dbs | sylvar: SSI is an ugly but practical way of ensuring that everything you need is in the initial HTML, before JavaScript runs; that's how we get the unAPI links in place |
| # | 16:25:15 | sylvar | hm |
| # | 16:26:37 | jeff | zigo_: oh, and how does debian feel about us taking over apache and changing it to run as our own user/group? ;-) |
| # | 16:26:41 | jeff ducks |
| # | 16:27:06 | zigo_ | jeff: We'd ask: why do you think you need to do that? |
| # | 16:27:32 | jeff | that's what I'd expect. :) |
| # | 16:28:31 | jeff | dbs: but the SSI doesn't currently pay attention to or have knowledge of the bib content or even record id, right? |
| # | 16:28:53 | dbs | Setting an explicit goal of "create a debian package that meets debian packaging standards" for 2.1 would let us at least find out all of the challenges we need to tackle and list them all as bugs |
| # | 16:29:41 | dbs | jeff: mod_rewrite sets an env var that can be used in the SSI |
| # | 16:30:29 | dbs | See 'RewriteRule - - [E=OILS_OPAC_RID:%2]' in eg_vhost.conf |
| # | 16:30:49 | dbs | (RID = record ID) |
| # | 16:30:53 | jeff | ah. thanks! |
| # | 16:31:05 | jeff | seen, forgot. |
| # | 16:32:26 | dbs | A product of Access 2008 hackfest |
| # | 16:35:42 | zigo_ is writing a start of a debian package for opensrf |
| # | 16:36:00 | phasefx | zigo_++ |
| # | 16:36:18 | zigo_ | I see "ntpdate" in your deps. Why that? |
| # | 16:36:44 | jeff | (eww) |
| # | 16:36:49 | zigo_ | Isn't it up to the admin to decide? |
| # | 16:37:02 | zigo_ | Isn't "ntp" better? |
| # | 16:37:21 | zigo_ | Shit, no batteries in my keyboard .. |
| # | 16:38:16 | yitznewton has joined #evergreen |
| # | 16:38:31 | phasefx bets that was an overzealous entry in Makefile.install |
| # | 16:39:09 | gmcharlt | zigo_: it's cruft, AFAICT; EG requires that the clock be accurate, but OpenSRF doesn't use either ntpdate or ntp directly |
| # | 16:41:08 | ksclarke has joined #evergreen |
| # | 16:41:33 | zigo_ | Is "python-setuptools" a build dependency, or runtime? |
| # | 16:41:53 | tsbere | Probably a prereq for building another prereq. |
| # | 16:42:22 | tsbere | Unless I missed an optional python opensrf lib in there somewhere |
| # | 16:45:47 | dbs | python-setuptools gets invoked at "make install" time |
| # | 16:46:08 | zigo_ | Only |
| # | 16:46:10 | zigo_ | ? |
| # | 16:46:21 | dbs | (assuming one has used the --enable-python switch) |
| # | 16:46:22 | dbs | yep |
| # | 16:46:41 | zigo_ | Ok, so it goes in Build-Depends. |
| # | 16:46:46 | tsbere apparently did miss said lib |
| # | 16:50:31 | gmcharlt | zigo_: I've commited a patch to drop the ntpdate (and ntp) dependencies from Makefile.install |
| # | 16:51:31 | jeff | gmcharlt++ |
| # | 16:51:35 | gmcharlt | there may be a bunch of deps specified there that are not actually required by OpenSRF proper (historical note: I think OpenSRF was orignally distributed in the Evergreen tarball) |
| # | 16:51:52 | moodaepo | gmcharlt++ |
| # | 16:52:57 | tsbere | Some of the stuff required on the database server is in the opensrf makefile.install there. Don't know if that is because opensrf needs it or just legacy there instead of the openils/evergreen makefile.install. |
| # | 16:53:02 | moodaepo wonders why our action.aged_circulation is empty |
| # | 16:53:14 | jeff | moodaepo: nothing populates it by default. |
| # | 16:53:34 | tsbere | There is another good point, though. Probably want a "database server" package too. |
| # | 16:53:34 | jeff | moodaepo: iirc, it can be populated at migration or by some not-enabled or not-finished processes. |
| # | 16:53:59 | zigo_ | Would opensrf build more than one binary package? |
| # | 16:54:06 | moodaepo | Should we be running a cron script.. |
| # | 16:54:08 | moodaepo | some not-enabled or not-finished processes? |
| # | 16:54:18 | dbs has quit IRC |
| # | 16:55:19 | moodaepo | Well I've been digging around to figure out why some holds don't get fulfilled during checkin...the vast amount do get captured |
| # | 16:55:22 | jeff | moodaepo: i don't recall which. others here may know offhand, or you could dig some. :) |
| # | 16:55:44 | moodaepo | jeff++ # no worries as long as it's not something EG requires |
| # | 16:56:05 | jeff | lack of aged circs should not have any bearing on your op-capture issue. |
| # | 16:56:06 | gmcharlt | moodaepo: look to trunk-land for stuff that actually populates aged_circulation |
| # | 16:56:29 | moodaepo | gmcharlt: Will do |
| # | 16:56:46 | gmcharlt | specifically, it's populated via a delete trigger on action.circulation |
| # | 16:58:08 | moodaepo | jeff: No I noticed that it was empty (again) via the view action.all_circulation which is pulling data from aged.. |
| # | 16:58:39 | moodaepo | gmcharlt: Makes sense...is that a 2.0 feature? |
| # | 16:58:45 | gmcharlt | yep |
| # | 17:01:09 | bshum has quit IRC |
| # | 17:03:35 | gmcharlt | zigo_: if I understand your question correctly, just one binary package per platform (OpenSRF has C code, of course) |
| # | 17:04:27 | zigo_ | No. |
| # | 17:04:43 | zigo_ | How many .deb should it build? |
| # | 17:04:59 | zigo_ | Just opensrf_version_arch.deb ? |
| # | 17:05:17 | zigo_ | Oh, ok... |
| # | 17:05:19 | zigo_ | :) |
| # | 17:05:25 | zigo_ | Just one... |
| # | 17:05:31 | gmcharlt | :) |
| # | 17:05:55 | afterl has quit IRC |
| # | 17:11:31 | zigo_ | http://dtc.xen650901.gplhost.com/debian.tar.gz |
| # | 17:12:36 | zigo_ | Get that, extrat in your source folder, review carefully each files and fill what's missing... |
| # | 17:13:23 | zigo_ | Then when dpkg-buildpackage does something send it back to me at zigo@debian.org |
| # | 17:13:51 | zigo_ | DO NOT include it in your upstream tarball ... |
| # | 17:13:55 | zigo_ | Ok ? |
| # | 17:14:10 | zigo_ | Time for me to go sleep ... |
| # | 17:14:41 | gmcharlt | zigo_: thanks! |
| # | 17:15:37 | zigo_ | The most important bit is debian/rules |
| # | 17:16:12 | zigo_ | (and debian/copyright for legal reasons...) |
| # | 17:16:37 | moodaepo | zigo_++ |
| # | 17:16:49 | atz_ has joined #evergreen |
| # | 17:16:49 | zigo_ | bye |
| # | 17:16:55 | moodaepo | debian++ |
| # | 17:17:00 | zigo_ has quit IRC |
| # | 17:20:35 | atz has quit IRC |
| # | 17:21:20 | ksclarke has left #evergreen |
| # | 17:27:10 | Dyrcona has quit IRC |
| # | 17:28:15 | pmplett has quit IRC |
| # | 17:29:34 | yitznewton has left #evergreen |
| # | 17:42:22 | jamesrf | apologies to anyone on the bug list just trying to tidy up a bit |
| # | 17:58:45 | agJohn | Is the pg_loader/parallel_pg_loader step for authority data supposed to create a file to populate the auth.rec_descriptor table? |
| # | 17:59:30 | agJohn | The most recent thing I found said to use these switches with it: -or are -or afr -a afr |
| # | 17:59:32 | agJohn | And that does not give anything for that table.... |
| # | 18:00:06 | jenny has left #evergreen |
| # | 18:01:44 | sfortin has quit IRC |
| # | 18:09:12 | StephenGWills_ has joined #evergreen |
| # | 18:13:11 | StephenGWills has quit IRC |
| # | 18:13:11 | StephenGWills_ is now known as StephenGWills |
| # | 18:15:31 | r123 has quit IRC |
| # | 18:16:57 | pmplett has joined #evergreen |
| # | 18:31:13 | yboston has quit IRC |
| # | 18:49:00 | lisppaste | moodaepo pasted "No suitable holds. But why?" at http://paste.lisp.org/display/114093 |
| # | 18:49:48 | phasefx_ | jamesrf++ # bug maintenance |
| # | 18:50:11 | phasefx_ | scared me half to death though, seeing my inbox :) |
| # | 18:50:12 | moodaepo | So I'm trying to see why a title hold (hold_type = T) that was placed was not fulfilled when the item was checked in earlier today. |
| # | 18:51:02 | phasefx_ | this may not be it, but there's a scenario where you can place a hold on a title, add a new item to the title, and that item won't be on the eligible copy list for the hold until retargeting, and thus won't be captured if scanned through check-in |
| # | 18:51:06 | youdonotexist has quit IRC |
| # | 18:53:15 | moodaepo | phasefx: Sadly I don't that's what is happening...this has happened earlier on some check-ins, they just go to reshelving. This is the one from earlier today > http://ecrl.mnpals.net/opac/en-US/skin/craftsman/xml/rdetail.xml?r=139784 |
| # | 18:53:17 | agJohn | phasefx_: Do you know what the story is on generating data for auth.rec_descriptor? (As per my question above....) |
| # | 18:53:20 | tildeequals has quit IRC |
| # | 18:53:57 | moodaepo | s/Sadly I don't that's what/Sadly I don't think that's what |
| # | 18:54:01 | phasefx_ | agJohn: I'm not familiar with that table |
| # | 18:55:17 | agJohn | moodaepo; lisppaste: We had this hold-not-capturing problem at one of the sites I work with. It turned out the main issue was missing entries in actor.org_unit_proximity--but if it's not that, we never figured out anything beyond there. I'm suspicious that there's some gap in the logic, but I have not found it.... |
| # | 18:55:43 | moodaepo | agJohn++ |
| # | 18:56:32 | moodaepo gives me hope that I'm not as insane as it has seemed the last week or so staring at this goat : ) |
| # | 18:57:06 | agJohn | phasefx_: Thanks anyhow. |
| # | 18:58:02 | agJohn | moodaepo: I should have said "some *other* gap in the logic"--you gotta have the proximity values or it no workie at all. If that's not it, then I can perhaps point you to some spots in the code to look--if I can find the notes we made as we were drilling down.... |
| # | 18:58:10 | phasefx_ | agJohn: it's been forever since I imported records like that, and I've never done authorities, alas |
| # | 18:58:54 | agJohn | Not many people have.... So the instructions I find are sketchy. |
| # | 18:58:56 | moodaepo | agJohn: Yea mail me the notes if/when you get a chance. Also I haven't done any of the authority loads. |
| # | 18:59:43 | moodaepo | Well then again the hold was from a patron of the library which own the item and checked-in at the same library. |
| # | 19:00:10 | moodaepo | Still worth looking at your notes |
| # | 19:00:14 | phasefx_ | agJohn: if you get a good handle on it, please do write something up for folks to learn from |
| # | 19:01:01 | agJohn | I had planned to do that, but when we figured out that we hadn't run autogen.sh w/ the -u switch I was mostly just embarrassed :~\ |
| # | 19:04:49 | agJohn | Or were you talking about authority loading? |
| # | 19:09:16 | agJohn | moodaepo: The heart of the matter for figuring out why the items were not getting captured, in our situation, was this bit of info from the redoubtable jeff: |
| # | 19:09:18 | agJohn | OpenILS/Application/Storage/Publisher/action.pm in the subroutine "nearest_hold". the SQL is there. |
| # | 19:14:27 | agJohn | By taking apart the SQL in that subroutine, we figured out what was wrong in our case. All the drilling down through the Perl code hadn't provided an answer. So, I'd start there. If you find the hold_request.id value then plug in the values for the from_org and the target_copy and some appropriate value for the CAST( ? as interval ) spot, then start stripping out the various JOIN clauses and... |
| # | 19:14:29 | agJohn | ...WHERE conditions until it comes back, you'll have identified the problem spot. |
| # | 19:16:13 | agJohn | As far as we could tell, there really is not much to the logic on the Perl side--in our situation at least, it all came down to whether the query in action.pm's nearest_hold was giving a rational answer or not. If you find that this subroutine is finding the right request, then you've got a different kettle of fish. |
| # | 19:17:37 | agJohn | That's the summary of pages of printouts and lots of debug statements added to code and various scribblings--so we'll call that "the notes." If you want to talk to me about it directly, feel free to fire me off an email. |
| # | 19:21:28 | phasefx_ | moodaepo: it's also worth checking that the copy, the copy location, and copy status all have their holdable flags set to true |
| # | 19:21:35 | youdonotexist has joined #evergreen |
| # | 19:22:35 | phasefx_ | and for copy status, include the copy status that came before Reshelving |
| # | 19:34:59 | tildeequals has joined #evergreen |
| # | 19:36:16 | moodaepo | agJohn++ phasefx++ # was on the phone |
| # | 19:36:32 | moodaepo runs to walk the dog |
| # | 20:22:21 | dbs has joined #evergreen |
| # | 20:23:55 | dbs_ has joined #evergreen |
| # | 20:27:56 | dbs has quit IRC |
| # | 20:28:36 | tildeequals_ has joined #evergreen |
| # | 20:29:32 | tildeequals has quit IRC |
| # | 20:32:41 | agJohn | moodaepo: There is also a patch relating to hold request capture that came up in our digging. The email from gmcharlt to the dev list on 10 Aug with this subject heading: Patch to 1.6.0 branch's 110.hold_matrix.sql indicates that the patch was put into the 1.6.0 and 1.6.1 branches. I do not know if this could possibly be part of the issue or not. (I'd forgotten about the fact that we... |
| # | 20:32:43 | agJohn | ...uncovered this, because it was actually unrelated to what was happening at our site.) |
| # | 20:33:48 | tildeequals has joined #evergreen |
| # | 20:34:55 | tildeequals_ has quit IRC |
| # | 20:37:30 | tildeequals_ has joined #evergreen |
| # | 20:38:24 | tildeequals has quit IRC |
| # | 21:00:29 | lisppaste | gmcharlt pasted "EG & OpenSRF trunk patchers" at http://paste.lisp.org/display/114096 |
| # | 21:01:00 | gmcharlt | ^^ list of individuals I was able to derive from the svn logs of trunk for EG and OpenSRF |
| # | 21:01:08 | gmcharlt | if I've missed any individuals, please let me know |
| # | 21:03:46 | dbs_ | gmcharlt++ |
| # | 21:08:04 | jeff | gmcharlt++ #and (everyone on that list)++ |
| # | 21:12:38 | tildeequals_ has quit IRC |
| # | 21:15:12 | tsbere | gmcharlt++ |
| # | 21:15:20 | tsbere | Got me and my boss, so :D |
| # | 21:17:46 | dbs_ | gmcharlt: getting all of the translators could be a bit of a challenge, as launchpad doesn't seem to be well set up for retrieving that info |
| # | 21:23:28 | gmcharlt | dbs_: and considering how strings are shared by projects on launchpad, ultimately an impossible task |
| # | 21:24:05 | jamesrf has quit IRC |
| # | 21:25:00 | gmcharlt | as far as direct updaters of translations, at the moment the only way I see to do it is manually checking each language's page |
| # | 21:28:12 | jeff | we might consider adding the (apparently special/magical) translators-credit message ... see the last comment here: https://bugs.launchpad.net/rosetta/+bug/589391 |
| # | 21:28:46 | StephenGWills | I'm trying to change some usr.profile s. should "UPDATE actor.usr SET actor.usr.profile = 12 WHERE actor.usr.profile > 21;" work? I am getting an error from psql doing it. |
| # | 21:29:09 | gmcharlt | and that error is? |
| # | 21:29:27 | StephenGWills | column "actor" of relation "usr" does not exist |
| # | 21:29:55 | StephenGWills | select * from actor.usr works fine, however. |
| # | 21:30:03 | jeff | too much specificity. drop actor.usr on all but the FROM |
| # | 21:30:06 | gmcharlt | you don't need to qualify every column |
| # | 21:30:10 | gmcharlt | snap |
| # | 21:30:19 | jeff | UPDATE actor.usr set profile = 12 where profile > 21; |
| # | 21:31:51 | jeff | in a column name, postgresql doesn't expect to see the schema. UPDATE actor.usr SET usr.profile = 12 WHERE usr.profile > 21; should also work |
| # | 21:32:06 | StephenGWills | kk. hopefuly I didn't just wipe out half my patrons :) |
| # | 21:32:27 | StephenGWills | thanks |
| # | 21:33:47 | jeff | (make backup, try on test datbase, etc, and/or) BEGIN; UPDATE actor.usr SET profile = 12 WHERE profile > 21; [check on things here with some sql, verify the # of updates seems to be what you expect, etc and if good...] COMMIT; |
| # | 21:35:37 | StephenGWills | np. looks like it worked. a couple of my libraries got carried away with permission groups and were moving them back to "Patron" by hand. |
| # | 21:35:41 | StephenGWills | thanks again. |
| # | 21:39:53 | jamesrf has joined #evergreen |
| # | 21:58:15 | StephenGWills_ has joined #evergreen |
| # | 22:01:27 | StephenGWills has quit IRC |
| # | 22:01:27 | StephenGWills_ is now known as StephenGWills |
| # | 22:19:50 | StephenGWills has quit IRC |
| # | 22:50:20 | dbs_ has quit IRC |
| # | 23:01:58 | dbs_ has joined #evergreen |
| # | 23:11:07 | dbs_ has quit IRC |
| # | 23:36:59 | LBA has quit IRC |
| # | 23:40:09 | joe___ has joined #evergreen |
| # | 23:41:13 | joe___ | ok ive downloaded evergreen any clue on how to get it to work? |
| # | 23:43:38 | joe___ has quit IRC |
April 10-13