| Time |
Nick |
Message |
| 01:26 |
|
rjackson_isl_hom joined #evergreen |
| 02:16 |
|
khuckins joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:09 |
|
collum joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 09:24 |
|
dbwells joined #evergreen |
| 09:26 |
|
JBoyer_ joined #evergreen |
| 09:27 |
|
phasefx_ joined #evergreen |
| 09:28 |
|
Dyrcona joined #evergreen |
| 09:29 |
|
terranm joined #evergreen |
| 09:52 |
csharp |
"jub is the feeling you get staring at a sunset, or in the smile of a child..." |
| 09:55 |
Dyrcona |
Heh. Maybe. I'm pretty sure it comes from Jabberwocky, so.... |
| 09:57 |
JBoyer_ |
The real jub was all the code we committed along the way. |
| 09:58 |
terranm |
lol |
| 10:47 |
|
khuckins joined #evergreen |
| 11:03 |
Dyrcona |
So, back to what tlittle and I were discussing in acquisitions yesterday morning: I have done an empty search in Angular acq (master) against an upgraded database with a copy of production data. It does seem to retrieve all the lineitems and it does not appear to lead to a crash. |
| 11:04 |
tlittle |
So since it doesn't crash, that doesn't solve your mystery then, right? |
| 11:06 |
Dyrcona |
Nope. Not in the least. I still have no idea how this happens. |
| 11:06 |
tlittle |
Huh |
| 11:09 |
|
Dyrcona joined #evergreen |
| 11:09 |
Dyrcona |
My IRC client crashed.... |
| 11:10 |
Dyrcona |
I was just trying to paste the reason why acq search doesn't crash in Angular. It does this search: open-ils.cstore.json_query.atomic {"order_by":{"jub":{"id":{}}},"from":{"jub":{}},"offset":0,"select":{"jub":[{"transform":"distinct","column":"id"}]},"where":{"-and":[{"+jub":{"id":{">=":"0"}}}]},"limit":10} |
| 11:10 |
Dyrcona |
The limit is based on the number of rows to view. |
| 11:37 |
|
malexander joined #evergreen |
| 12:08 |
mmorgan |
Question about the Won't Fix Status in Launchpad. If there's a bug in an old, but not deprecated, interface, but it's fixed in the new version of the interface (think staff TPAC vs. Angular staff catalog) should it be marked Won't Fix before the old interface is deprecated? |
| 12:13 |
csharp |
I would think so |
| 12:13 |
|
mantis1 joined #evergreen |
| 12:13 |
csharp |
the bug poster can always object too |
| 12:17 |
|
jihpringle joined #evergreen |
| 12:18 |
|
mmorgan1 joined #evergreen |
| 12:19 |
|
mmorgan2 joined #evergreen |
| 12:22 |
mmorgan |
csharp: Ok, thanks. I assume anyone else that thinks the issue is important enough could object also (hypothetical, no particular bug in mind...) |
| 12:33 |
Dyrcona |
csharp mmorgan: +1 |
| 13:55 |
terranm |
I have marked some TPAC-specific bugs Won't Fix if they are fixed in BooPAC. Nobody has objected yet, but I would not be offended if anyone did! |
| 13:57 |
Dyrcona |
No reason to get offended, but if someone wants to fix 'em that's OK. |
| 13:59 |
|
sandbergja joined #evergreen |
| 14:07 |
mmorgan |
terranm++ |
| 14:07 |
mmorgan |
Dyrcona++ |
| 14:10 |
Dyrcona |
Meh. Waiting on long db upgrades... Some temp function to mess with billings or something.... |
| 14:10 |
pinesol |
[evergreen|Dan Briem] LP#1915323 Angular Staff Client Hamburger Menu Clipped Off Screen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c77bd26> |
| 14:11 |
mmorgan |
Anything to do with billings is bound to take a loooong time. |
| 14:27 |
khuckins |
Does anyone know off the top of their head(or know where the docs exist for) how to enable outgoing email in Evergreen? I'm guessing it's somewhere in eg_vhost but not certain |
| 14:28 |
|
jvwoolf joined #evergreen |
| 14:30 |
Dyrcona |
khuckins: Depends. You want to set the return email address, or is email just not working at all? |
| 14:31 |
khuckins |
Dyrcona: email just not working at all - this is for the icelandic test server, so no need for a return address I would think |
| 14:32 |
Dyrcona |
If it's Debian or Ubuntu, you probably need to install and configure exim. |
| 14:32 |
khuckins |
Ah, I'll look into that, thanks! |
| 14:33 |
Dyrcona |
You can configure a different MTA, but exim is the default for Debian. |
| 14:34 |
pinesol |
[evergreen|Jane Sandberg] LP1873322: Angular Admin Pages default to workstation OU - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6b8adca> |
| 14:35 |
|
mantis1 left #evergreen |
| 14:37 |
|
mantis1 joined #evergreen |
| 15:44 |
rhamby |
terranm lp827356 you're running the upgrade script? |
| 15:50 |
Dyrcona |
The comment makes it look like the script was run twice. |
| 15:50 |
Dyrcona |
Or maybe the schema built from the branch and then the upgrade script run. |
| 15:52 |
rhamby |
yeah that was my thought |
| 15:53 |
rhamby |
I'm going to go back and test it as a fresh upgrade and building with it and I'll see if I can duplicate it |
| 15:53 |
rhamby |
either it ran twice somehow or the error isn't what it describes though usually postgres errors are at least close to the actual cause |
| 15:55 |
rhamby |
but it's late on a friday so who knows what chaos lurks waiting to be unleashed |
| 15:55 |
Dyrcona |
Yeahp. I was just about tot have a look on a test db upgraded to master, but the VPN keeps kicking me out today...... Chaos is already unleashed. |
| 15:55 |
terranm |
I use a script that Chris made for me that basically blows away the entire database and does a fresh install |
| 15:56 |
rhamby |
I'm building from git now so that will give me some indicator in a while |
| 15:57 |
|
mantis1 left #evergreen |
| 15:57 |
Dyrcona |
The rule doesn't exist in master. |
| 15:58 |
rhamby |
yeah, my gut instinct is that something happened with the database rebuild but since I'm not familiar with that script I can't guess what |
| 15:58 |
Dyrcona |
terranm: Sounds like it loads a fresh schema. Did you run the db upgrade script after? |
| 15:59 |
terranm |
No - should I have? |
| 15:59 |
terranm |
Didn't think I needed to since it was loading as part of the install |
| 16:00 |
terranm |
It's not an error I've encountered with anything else I've tried to install using that script |
| 16:00 |
Dyrcona |
Right, if the script from Chris does what I suspect it does, it should have been part of the schema, but maybe Chris's script tried to run it again? |
| 16:01 |
rhamby |
actually I think it is in the script, I think there's a copy / paste error where the acl rule went where the acn rule should be |
| 16:02 |
Dyrcona |
Unrelated, I got an error running the 1257 upgrade: ERROR: duplicate key value violates unique constraint "x_p_b_once" DETAIL: Key (xact, payment, billing)=(37654016, 11059981, 52495988) already exists. |
| 16:02 |
rhamby |
terranm: give me a few minutes and I'll push a fix on that branch |
| 16:03 |
terranm |
Cool beans |
| 16:03 |
Dyrcona |
rhamby++ terranm++ friday-- :) |
| 16:03 |
terranm |
I may not have time to test it until next week though |
| 16:03 |
rhamby |
yeah, that was less a bug and more a "rogan's fingers didn't do what they were supposed to at some point" |
| 16:04 |
terranm |
:) |
| 16:04 |
rhamby |
after ten years I think a few more days won't hurt :) |
| 16:04 |
Dyrcona |
:) |
| 16:04 |
Dyrcona |
Well, it's too late on a Friday for me to worry about my billing error, particularly when we won't be upgrading to that code for some time. |
| 16:17 |
rhamby |
I think it's too late on Friday to worry about much of anything. |
| 16:18 |
rhamby |
terranm btw the fix is pushed if you get time next week to look at it |
| 16:18 |
terranm |
rhamby++ |
| 16:24 |
mmorgan |
When adding to seed data, is it customary to put the additions at the end of the script? |
| 16:31 |
Dyrcona |
mmorgan: Yes, or in a separate YYYY.....sql |
| 16:32 |
Dyrcona |
YYYY.data.whatever.sql I meant. |
| 16:32 |
Dyrcona |
You can't do some things after altering tables, so a separate script is occasionally necessary. |
| 16:35 |
mmorgan |
Dyrcona: I have a XXXX.data.whatever.sql but need to add the same data to 950.data.seed_values.sql, so I think I need to add the data in XXXX to the end of 950.data.seed_values.sql, not do a second upgrade script, right? |
| 16:35 |
mmorgan |
Probably too late on a Friday to think I am making sense. |
| 16:36 |
mmorgan |
These are missing workstation settings. bug 1920253 |
| 16:36 |
pinesol |
Launchpad bug 1920253 in Evergreen "Carousel Admin Pages Grid Settings cannot be saved" [Undecided,New] https://launchpad.net/bugs/1920253 - Assigned to Michele Morgan (mmorgan) |
| 16:38 |
khuckins |
When I insert OU settings, I usually add each piece to the bottom of whichever section of the seed data is relevant |
| 16:42 |
mmorgan |
khuckins: Thanks, I see insert statements at the bottom of 950.data.seed_values.sql, so was wondering if that was the convention, rather than adding the new values to an already existing insert statement. |
| 16:44 |
Dyrcona |
mmorgan: You just put the data inserts in 950.data.seed_values.sql, at the end, or join it to the existing inserts into the same table. |
| 16:45 |
mmorgan |
Dyrcona: Ok, thanks, so either approach is ok. |
| 16:45 |
Dyrcona |
I guess it depends on who does it. There isn't really a convention, thought I think there's a tendency to pile on the existing inserts. At least, that's what I try to do. |
| 16:45 |
Dyrcona |
s/thought/though/ typos-- |
| 16:47 |
mmorgan |
Dyrcona: Adding to existing inserts makes more sense to me, but I've already added the new values to the end, so I might just go with that :) |
| 16:47 |
mmorgan |
Dyrcona++ |
| 16:47 |
mmorgan |
khuckins++ |
| 17:07 |
miker |
mmorgan: all of that is sound -^ ... I tend to append to the one big permission insert for perms, but for A/T related stuff, I keep any new hook, definitions, modules, env and params all together in a block. for library settings, if they drive new db logic, I'll put them near that, or at the end by themselves if they're just UI-impacting. for config-schema inserts, I try to keep those all in one place -- config.metabib_field in one place, for instance |
| 17:10 |
mmorgan |
miker: Ok, thanks! That's helpful. |
| 17:11 |
mmorgan |
Can't push my working branch :-( The working repo must knock off early on Fridays. |
| 17:11 |
miker |
doh! what's the error say? |
| 17:11 |
mmorgan |
No error, just hangs. Might be a timeout on my end. |
| 17:11 |
mmorgan |
Oh wait, now there's an error. |
| 17:12 |
miker |
what's the branch? I see several from you, so, thanks for those! |
| 17:12 |
mmorgan |
It is a timeout. This is for 1920253 |
| 17:13 |
miker |
ah, ok. I see the bucket column tweak, so at least there's that one :) |
| 17:18 |
mmorgan |
Restarting my vm. Sometimes it forgets how to connect to things. |
| 17:19 |
terranm |
So do I, so do I |
| 17:26 |
mmorgan |
terranm++ :) |
| 17:27 |
mmorgan |
Looks like it's my vm that knocked off early. I'll have to try pushing that branch later :-( |
| 17:28 |
terranm |
Even VMs need a weekend |
| 17:30 |
mmorgan |
Oh yeah! Weekend! Would have been nice to get that pushed as the last task on a Friday afternoon, but it wasn't to be. |
| 17:30 |
mmorgan |
Have a good weekend, everyone! |
| 17:30 |
|
mmorgan left #evergreen |
| 17:34 |
terranm |
You too! |
| 17:41 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:32 |
|
dbwells joined #evergreen |
| 20:29 |
|
sandbergja joined #evergreen |
| 21:37 |
|
sandbergja joined #evergreen |
| 22:55 |
|
sandbergja joined #evergreen |
| 23:13 |
|
sandbergja joined #evergreen |
| 23:55 |
|
sandbergja joined #evergreen |
