| 15:04 |
JBoyer |
ooh, sandbergja++ |
| 15:05 |
terranm |
sandbergja++ |
| 15:05 |
sandbergja |
heya! hope it works :-) |
| 15:06 |
JBoyer |
He or others can test it now and see how things shake out instead of worrying about how to solve it. :D |
| 15:06 |
sandbergja |
and that branch also includes miker's patch for the staff side |
| 15:06 |
|
tlittle joined #evergreen |
| 15:07 |
JBoyer |
Do we have any volunteers to handle the point releases? I believe there should be a 3.7.3 as a final sendoff to the 3.7 series to go along with 3.8.1 |
| 15:45 |
Dyrcona |
jeffdavis++ |
| 15:45 |
JBoyer |
Ok, and an update from phasefx |
| 15:45 |
JBoyer |
#info Live tester update |
| 15:45 |
phasefx |
ha, so speaking of blockers |
| 15:45 |
phasefx |
we should probably start treating the live tester as a blocker |
| 15:46 |
phasefx |
but I disabled it in April for fear that people would become inured to the daily error messages |
| 15:46 |
phasefx |
I confess I haven't had any tuits since then to actually look at what the problem is |
| 15:46 |
phasefx |
http://testing.evergreen-ils.org/~live/archive/2022-04/2022-04-25_16:00:04/test.49.html |
| 15:46 |
sandbergja |
phasefx++ # thanks for bringing that up |
| 15:47 |
shulabear |
phasefx++ |
| 15:47 |
Dyrcona |
phasefx: I think the failing test has to do with missing directories and autogen.sh. It should be resolved now. |
| 15:47 |
JBoyer |
And I've seen that same test work on a local testing rig, though not one that's rebuilt from scratch like the live tester is, which is annoying. |
| 15:47 |
phasefx |
so any love that can be put toward it would be much appreciated; I'm about to go on vacation, but will re-enable it; it picks up from a public repo that any commiter should have access to |
| 15:48 |
sandbergja |
which repo is it, phasefx? |
| 15:48 |
phasefx |
https://git.evergreen-ils.org/?p=working/random.git;a=shortlog;h=refs/heads/collab/phasefx/eg_live_tests |
| 15:48 |
sandbergja |
phasefx++ |
| 15:49 |
phasefx |
EOLI hosts the machine (the test instigator) and the test vm, but in the past we've let community folks into it. I'm sure such can be done again if needed |
| 15:50 |
JBoyer |
And to Dyrcona's point above, I believe the autogen patch (and a followup) were already in master and it was still failing. |
| 15:50 |
Dyrcona |
I think I used to have access to the old tester. I wouldn't mind looking into it. |
| 15:51 |
JBoyer |
I'd also like to find time to redo the entire testing setup, but time to do so has not made itself available to me. |
| 15:53 |
JBoyer |
It looks like Dyrcona and jeff have both had access in the past and still should (though that machine is not where the testing is actually done, just where the data is gathered) but let me know if you have time to look around and need any help |
| 15:55 |
JBoyer |
Ok, any other new business before we wrap up? |
| 15:55 |
Dyrcona |
JBoyer: I'll wager it |
| 15:55 |
Dyrcona |
s my old key. |
| 16:40 |
JBoyer |
Dyrcona++ |
| 17:05 |
|
mmorgan left #evergreen |
| 17:26 |
|
rjackson_isl_hom joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-05/2022-05-10_16:02:07/test.49.html> |
| 15:07 |
|
LBA24 joined #evergreen |
| 16:23 |
Bmagic |
must be a holiday today |
| 16:26 |
|
jvwoolf left #evergreen |
| 16:29 |
bshum |
Does anyone else miss the live test bot warnings? Seems that it hasn't made any new pages to the feed since April 25 or so |
| 16:29 |
bshum |
@dessert Bmagic |
| 16:29 |
* pinesol |
grabs some pineapple chocolate things from New Zealand for Bmagic |
| 16:30 |
Bmagic |
The nightly pinesol compile summary? |
| 16:30 |
bshum |
http://testing.evergreen-ils.org/~live/ <-- only shows last 2022-04-25 |
| 16:31 |
bshum |
Which is the last time something went into the css feed I guess, for the bot to read and spit into the channel |
| 16:32 |
bshum |
I mean I'm pretty sure the live tests are still broken somehow, but I miss when it says "success" :P |
| 16:32 |
Bmagic |
I've never had the privelege of looking at how this works |
| 16:32 |
bshum |
It's probably something wrong with the testing server |
| 16:32 |
Dyrcona |
Bmagic: I didn't say antying about acq for electronic resources because I don't know. The people who would know don't hang out here. Try the general mailing list, or maybe the cataloging list. |
| 16:33 |
Bmagic |
good idea |
| 16:33 |
* Dyrcona |
grumbles..... |
| 16:34 |
Dyrcona |
bshum: I used to have access to the test server, but not sure if I still do. It may have moved.... I never looked at it more than once or twice anyway. |
| 16:39 |
mmorgan |
Also, it is National Lost Sock Memorial Day.... |
| 16:40 |
Bmagic |
mmorgan: lol |
| 16:49 |
Dyrcona |
Well, it's the observance of V-E Day in some countries that still observe these things. |
| 13:11 |
Dyrcona |
OK. I've definitively tracked it down to changes from erlang-p1-xmpp 1.4.4 to erlang-p1-xmpp 1.5.6. The older library included a numeric code in the errors, though I can't find anything about that in the RFCs. |
| 13:11 |
Dyrcona |
Should this be discussed at the next developers' meeting? |
| 13:25 |
Dyrcona |
https://github.com/processone/xmpp/commit/6fc29dce5ef566b9dd6245f0b3619913756a1739 |
| 13:51 |
jeff |
gmcharlt: we rarely use that interface, but I can try testing here to see if we run into the issue (we might not due to the s2s particular you mentioned) |
| 13:51 |
jeff |
amusingly, the "atomic works" is probably the exact opposite of what our 1.x holdshelf experience was. :-) |
| 14:00 |
dluch |
#startmeeting 2022-05-05 - Documentation Interest Group Meeting |
| 14:00 |
pinesol |
Meeting started Thu May 5 14:00:09 2022 US/Eastern. The chair is dluch. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:00 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 14:28 |
dluch |
I'm thinking that perhaps this is a good topic for discussion during the Hackfest. Sound okay? |
| 14:29 |
jihpringle |
works for me |
| 14:30 |
dluch |
Is there any other new business we need to discuss? |
| 14:31 |
jihpringle |
is there anything we want to talk about with 3.9 being released? |
| 14:32 |
jihpringle |
we don't have a test server yet so I haven't had a chance to look at it, but based on the release notes there's at least a few changes that affect docs |
| 14:32 |
jihpringle |
like action triggers now being in angular |
| 14:32 |
dluch |
I also have not had a chance to look at it yet. Good point, though. Definitely some things that will require changes and new screenshots |
| 14:33 |
jihpringle |
might just be that we need to update the re-org spreadsheet with the doc needs from 3.9 |
| 14:33 |
jweston |
good stuff! until we've had a chance to test it post-release, should we delay this topic to June call? |
| 14:33 |
dluch |
jihpringle: That's probably the best way |
| 14:33 |
jihpringle |
do we want to plan to make this a discussion topic for the hackaway? |
| 14:33 |
jweston |
+1 to hackaway topic |
| 13:20 |
miker |
ah! libxml could be it, yes. we've run into other issues with it. I could see it changing from empty string to null... |
| 13:22 |
Dyrcona |
Here's the backtrace: https://pastebin.com/hwZ8z5T9 |
| 13:22 |
Dyrcona |
I configured with --enable-debug. |
| 13:24 |
Dyrcona |
miker: That's possibly the culprit. A little test program doesn't crash when I do x = atoi(""); |
| 13:30 |
Dyrcona |
Ok. If I change line 698 in transport_session.c (get_xml_attr()) to return "" instead of NULL, we don't crash. I'm not sure that's the best fix, however. |
| 13:32 |
miker |
probably better style to test for null. but ... then do we need to protect a free() later on? (not in a position to dig right now, unfortunately) |
| 13:33 |
miker |
Dyrcona++ |
| 13:35 |
miker |
and, entirely unrelated, I've finally uploaded the 3.9 release artifacts to lupin and (thanks to abneiman) the website is pointing at them! (the downloads page could use some love, but changes deserve some thought first) |
| 13:36 |
jonadab |
Dyrcona: Sure, or returning an object that evalutes to 0 in numeric context, false in boolean context, or "Error: empty string is not numeric" in string context :-) |
| 13:36 |
jonadab |
And throws an exception if called as code. |
| 13:38 |
Dyrcona |
No, That's not it, either. :) |
| 13:40 |
Dyrcona |
miker: Yeah, my change to return "" was just to verify a hunch. I'd really like to figure out why this blows up on Ubuntu 22.04 and not 20.04 or 18.04. I've confirmed with a little test program that passing NULL to atoi segfaults on all 3, which I suspected. |
| 13:42 |
Dyrcona |
For the logs, if I do "request math add 2,2" that crashes on 22.04 but says "Received no data from server" on earlier distros, and.... that may be a clue that I'm overlooking. We're getting "something" back on 22.04. |
| 14:01 |
Dyrcona |
Yeah, we're crashing before we get to the point of printing "Received no data from server." It just gets more puzzling the more I look. |
| 15:32 |
Dyrcona |
gdb is not very much fun... |
| 10:01 |
pinesol |
Launchpad bug 1832408 in OpenSRF "Cannot (or should not) use root to register ejabberd users" [Undecided,New] https://launchpad.net/bugs/1832408 |
| 10:02 |
Dyrcona |
jeff: bug 1934508 |
| 10:02 |
pinesol |
Launchpad bug 1934508 in ejabberd (Ubuntu) "Ejabberd fails with latest apparmor profile on Ubuntu 21.04" [Undecided,New] https://launchpad.net/bugs/1934508 |
| 10:02 |
jeff |
The Ansible issue with ejabberd was a bug in the community.general, ejabberd_user collection. My notes on that say: |
| 10:02 |
jeff |
> recent changes broke "exists" and "changed" detection, because it's no longer testing the return value of the ejabberdctl command, so it always thinks that things exist and always thinks that user passwords need to be set, even if they are already set to the chosen value. |
| 10:02 |
jeff |
(so, probably unrelated to your issue) |
| 10:03 |
Dyrcona |
I want to investigate a segfault from testing the other day. I made a typo when doing opensrf.math add and srfsh segfaulted. |
| 10:04 |
Dyrcona |
I'd rather not say, "Reboot the server." in the installation instructions, but if that is what it comes down to, then OK. :) |
| 10:08 |
Dyrcona |
`make check` still works on Debian 9, so I assume it will work everywhere else since I've tested it on all releases of Ubuntu and the other Debian releases are closely related. |
| 10:12 |
Dyrcona |
So, it looks like if you make a request to a non-existent service from srfsh on Ubuntu 22.04, srfsh segfaults. A bogus method called on a real service returns a 404. On Debian 9, the former doesn't crash and says 'No data received from server.' |
| 10:18 |
Dyrcona |
Ok. It looks like the router and some other services also crash. |
| 10:31 |
Dyrcona |
OK. The router, etc., are not crashing now that I'm trying to make them crash. |
| 14:04 |
Dyrcona |
Well, that's nice. Remote site Internet dropped while I was editing a file with vi. |
| 14:30 |
|
Dyrcona joined #evergreen |
| 14:51 |
|
collum joined #evergreen |
| 15:04 |
Dyrcona |
Well, 'make check' in OpenSRF fails with what looks like a compiler error on jammy. I wonder if anyone runs these tests and if they work on earlier releases. I'll have to try it on focal and bionic. |
| 15:05 |
Dyrcona |
make check succeeds in OpenSRF/src/perl/, but looks like make check higher up runs that, too. |
| 15:10 |
Dyrcona |
So, the tests pass on Ubuntu 18.04. I assume this is a compiler change in 22.04. Probably related to a newer C standard. |
| 15:14 |
Dyrcona |
check_osrf_message.c:20:14: error: expected ‘)’ before ‘==’ token |
| 15:14 |
Dyrcona |
20 | fail_if (o == NULL, "osrfMessage not created"); |
| 15:22 |
Dyrcona |
Well, now to figure out what changed in the standards/compiler. |
| 15:28 |
Dyrcona |
It might be changes in libcheck since version 0.10. Jammy has 0.15. |
| 15:40 |
Dyrcona |
Bmagic: Just install OpenSRF master on Ubuntu 20.04/Focal. |
| 15:52 |
|
collum joined #evergreen |
| 16:12 |
Dyrcona |
OK. The errors were about the test themselves. Now, to see if the changes still work on earlier version of the check library. |
| 16:15 |
Dyrcona |
Yeahp. Still work on Focal. |
| 16:25 |
|
jvwoolf left #evergreen |
| 16:32 |
Dyrcona |
bug 1970667 |
