Evergreen ILS Website

IRC log for #evergreen, 2017-03-21

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to the server's local time.

Time Nick Message
02:18 dbwells_ joined #evergreen
04:46 gsams joined #evergreen
04:55 gsams joined #evergreen
05:02 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
06:40 rlefaive joined #evergreen
06:53 agoben joined #evergreen
07:12 rjackson_isl joined #evergreen
08:01 Dyrcona joined #evergreen
08:20 kmlussier joined #evergreen
08:40 mmorgan joined #evergreen
08:49 bos20k joined #evergreen
08:49 * kmlussier wonders when we should change the 2.next milestone to 3.next. :D
08:56 Dyrcona Or just "next?"
08:56 kmlussier Speaking of 3.0, /me fills out Doodle poll at http://doodle.com/poll/dhsdx4vdr3qw2r2z
08:56 JBoyer 3.boom
08:56 Dyrcona 2.13 could be fun. :)
08:57 gmcharlt We shall release it on a Friday, and its code name shall be Black Cat Under Ladder
08:59 Dyrcona JBoyer: We're going to put your branch from Lp 1611818 in production on Monday.
08:59 pinesol_green Launchpad bug 1611818 in NCIPServer "Return a Barcode in RequestItemResponse if a copy is targeted" [Low,New] https://launchpad.net/bugs/1611818
09:00 JBoyer Dyrcona, good to hear, I hope its helpful. (Given how SHAREit works, it's mostly eliminated the need for anyone to enter barcodes into requests.)
09:00 Dyrcona Yeah, that's what I expect it to do. I'll push it to master in a week or two if there aren't any issues.
09:02 JBoyer ++
09:04 * mmorgan 's ears perk up.
09:04 gmcharlt now cutting OpenSRF 2.5.0
09:04 kmlussier gmcharlt++
09:04 Dyrcona Maybe at the hackfest, I'll do a README for NCIPServer.
09:05 mmorgan Dyrcona: JBoyer: So that magically put the item barcode in the SHAREit request instead of a record number?
09:06 Dyrcona mmorgan: Yes.
09:06 Dyrcona It pulls the barcode from the copy targeted at the hold if any.
09:06 Dyrcona If not, then you get the record number.
09:07 Dyrcona gmcharlt++
09:09 mmorgan So if a different copy is captured and sent, the barcode would need to be changed?
09:10 Dyrcona Yes, I think so.
09:11 mmorgan Ok, thanks. Sounds like a great improvement overall.
09:11 mmorgan JBoyer++
09:11 Dyrcona JBoyer++
09:11 mmorgan Dyrcona++
09:16 kmlussier Thinking more on a release 2.13, if we delay the next release for a month, there is a Friday the 13th in October.
09:19 Dyrcona Well, I was thinking 3.0 would be the one where xul is removed, but if the consensus lies elsewhere, I'm OK with that.
09:20 gmcharlt yeah, my joking aside, I'm in favor of 3.0 as marking production support for web client
09:20 gmcharlt (which, by the way, I think means a _deprecation_ of XUL but not yet a removal in 3.0, although obviously that's up for discussion)
09:27 kmlussier My recollection from the hack-a-way was that the consensus was to have a deprecated XUL for two releases. Of course, it's always a good idea to reaffirm that decision.
09:38 pinesol_green [opensrf|Ben Shum] LP#1672926: Disable/remove default nginx config in REAMDE steps - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=47bafe1>
09:40 Dyrcona Yeah, I was just hoping for a definitive break in 3.0, rather than waiting for 3.2, but whatevs.... :)
09:40 Dyrcona It would likely mean two more 2.x releases.
09:49 bshum gmcharlt++ # opensrf 2.5.0 goodies
09:50 pinesol_green [evergreen|Bill Erickson] LP#1670512 Apply focus/select model udpates via timeout - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=014fc6a>
09:55 gmcharlt https://evergreen-ils.org/opensrf-2-5-0-released/
09:57 kmlussier gmcharlt++
09:58 csharp @band add BlackCat UnderLadder
09:58 pinesol_green csharp: Evergreen Command Center http://apod.nasa.gov/apod/image/1204​/EndeavourFlightDeck_cooper_1050.jpg
10:00 Dyrcona Hmm... Black Cat Under A Ladder would make a nice album cover image.
10:00 Dyrcona And don't "title" the album, just use the artwork for the name.
10:01 Dyrcona csharp: We should get into the music business while there's still one left. ;)
10:02 * csharp hooks USB mic to workstation and uses audacity to record album
10:02 Dyrcona Well, I didn't necessarily mean as performers. ;)
10:23 berick hey, chuck, you know that sound you been lookin for...  *blasts ukulele through usb mic through audacity*
10:24 Dyrcona heh.
10:25 berick and +1 to (permanently) renaming 2.next  -- or dropping it.  having a pullrequest and no target kind of implies 'next'
10:26 Dyrcona Well, some of us (not necessarily me) have been managing bugs by target.
10:26 Dyrcona So having no target may make some bugs "disappear."
10:27 berick Dyrcona: interesting.  aren't you missing a lot of bugs that way?
10:27 berick or do you mean just those w/ pullrequests?
10:27 Dyrcona I'm not doing it so much, but I know one or two others are, and targets help when you're RM.
10:28 Dyrcona And, yeah, its mainly for bug with pullrequests.
10:28 Dyrcona bugs....
10:28 * berick certainly doesn't want to make the RM's job more difficult
10:30 kmlussier In general, if I'm looking at bugs for the next release, I'm looking at ones with the 2.12 target rather than the 2.next target. But I guess the 2.next target serves as a placeholder until the new target is available?
10:30 Dyrcona Yes.
10:31 Dyrcona Even after, because not all bugs get updated with the new target right away.
10:31 kmlussier Now that I think about it, I asked people to assign the 2.next target to bugs if they wanted them to be considered for the release. But I would be up to reconsidering processes if we wanted to get rid of the .next target.
10:31 Dyrcona I had scripts for that but they stopped working a couple of years ago.
10:32 Dyrcona I never got around to figuring out why. Something to do with launchpadlib and Python.
10:32 kmlussier I generally don't update a bug to the target with the real release number unless I'm somewhat certain it's being considered for that release. Because the 2.next target does save a lot of churn for bug wranglers.
10:32 Dyrcona Well, these scripts were mainly for moving bugs around at release time.
10:33 kmlussier If you update it to 2.12, it the target then needs to be removed if it doesn't make it into the release. And then it needs to be re-added when the new target is available. With the .next target, it can just sit in the target until the code is merged.
10:34 Dyrcona They were always kind of clunky and seemed like Lp had some limits on how many you could move at once....
10:35 Dyrcona The point is that I think the .next target serves a useful purpose, but that can always be revisited.
10:35 berick Dyrcona: well then you've answered my question
10:36 kmlussier If we do keep it, though, I agree with Dyrcona that we might want to name it .next so that we don't need to rename it every time we make a big jump in release numbers.
10:36 berick i guess the rule is when you add a pullrequest for a wishlist/feature bug, you have to set a milestone of 'next' or it will likley be ignored ?
10:36 berick yes, definitely needs renaming
10:38 kmlussier berick: I've always followed that rule when submitting my own code because I was told it would be more likely to get attention if it was targeted. In general, when looking for code to test, I usually just look for the pullrequest tag.
10:39 bshum One of the old ideas was to rename 2.next into 2.actualnumber-alpha but that got tiresome to keep reshuffling bugs away from the actual milestones.  So we ended up leaving 2.next as is as a general placeholder to target future dev
10:40 bshum I'd prefer to keep a target around for next dev just cause I do find that untargeted bugs can easily get lost in the mire of open tickets depending on how you set your search scopes
10:40 berick kmlussier: same here, i just look for the tag
10:42 kmlussier Overall, I think it would be good practice to try to go through all those bugs with pullrequest tags, merge the ones that are ready, and actively remove the pullrequest tags, possibly adding a needsrepatch tag, for ones that aren't ready.
10:42 kmlussier But now I'm living in the land of dreams.
10:43 kmlussier I do find that many of the bugs that sit without a pullrequest tag are there because we're reluctant to remove the pullrequest if it's not ready or needs a test.
10:43 kmlussier OK, now I'm just talking gibberish. /s/without/with
10:45 berick that's consistent w/ my lp-world view
10:46 berick pullrequest means merge me as soon as possible, if I don't have a milestone, put me in master.
10:46 * berick is not pushing for anything, just like knowing how people work
10:47 bshum I think the other reason I like doing a milestone is just that it's not so easy to filter for bugs without one specifically.  Easier to say, with milestone X instead of without any milestone whatsoever vs. the ones with it
10:48 bshum I just like manageable segments I guess.  Looking at the 1300+ open bugs makes me sad
10:49 berick bshum: tag=pullrequest status!=fix-released ?
10:50 bshum berick: Right... but how do you only focus on the ones with no milestone currently assigned?
10:50 bshum Vs. ones that are attached to existing ones?
10:50 bshum Maybe I only want to find the stragglers
10:50 mmorgan Seems to me like removing pullrequests as kmlussier suggests would make it easier to filter without considering milestones.
10:50 bshum Just being devil's advocate
10:51 bshum Bug triaging hasn't always been awesome in LP land
10:51 Dyrcona No, it kind of stinks.
10:51 gmcharlt csharp: bshum: do eiher of you have cycles to look at bug 1669868 today?
10:51 pinesol_green Launchpad bug 1669868 in Evergreen ""make check" failure" [High,Confirmed] https://launchpad.net/bugs/1669868
10:51 Dyrcona That's why I wrote the scripts in the first place.
10:54 berick bshum: i see.. so there's just no easy way in the UI to search for un-targeted?
10:54 maryj joined #evergreen
10:55 kmlussier What is the use case for finding pullrequest bugs that are untargeted?
10:55 bshum berick: Not that I can find yet
10:56 bshum kmlussier: Orphaned bugs that need love, basically.
10:56 mmorgan Not everyone who can add a pullrequest can set a target?
10:56 berick mmorgan: exactly
10:56 kmlussier mmorgan: Yeah, that's a problem.
10:56 bshum mmorgan: Which is also a problem, yeah
10:57 mmorgan Let's just fix them all, that'll solve it. ;-)
10:57 bshum This is one of the reasons why we used to mark every bug that was "new" with a status of "confirmed" or "triaged" by a bug team member and assign an initial review target, etc.  But that also hasn't been a great maintainable workflow too.
10:57 kmlussier If I do a search for bugs with a pullrequest tag with a status of new, confirmed, triaged, in progress or incomplete (LP defaults with Fix Committed removed), I get 70.
10:58 kmlussier I keep thinking that if each core committer took 2 of those bugs per month to review, and either merge or remove the pullrequest tag, we could get through those in short order.
10:58 berick so in other words if you don't have access to set a target, your bug is by default less likely to get attention.  that don't seem right.
11:00 kmlussier I also think a lot of developers submitting code don't think they're in a position where they should be asking for that access. They're under the impressions that you need to be special to be upgraded to bug wrangler and bug driver status.
11:01 Dyrcona You only need to be on the wrangler team to set targets, IIRC.
11:01 Dyrcona And, a few of us can add people. I generally add anyone who requests whose name I recognize from the community.
11:01 kmlussier But you need to be a driver to add a series. As a wrangler, you can only nominate a bug for a series.
11:02 kmlussier So if somebody wants to be able to assign backport targets, they really need to be a driver.
11:03 kmlussier bshum: Another method for finding orphaned bugs is to sort by oldest first.
11:03 Dyrcona I basically don't have time to spend much of it on Launchpad, I'm afraid.
11:03 Dyrcona I think the situation is the same the majority of core committters.
11:04 bshum kmlussier: So the proposal is to not assign any bug targets initially then?  And widen our searches to include only bugs tagged pullrequest, and remove pullrequest and add needsrepatch to bugs that need more work?
11:04 kmlussier bshum: I'm not proposing anything. I'm just participating in discussion. :)
11:04 bshum kmlussier: Right, I'm just trying to summarize
11:04 kmlussier But I do think we should remove pullrequests and replace with needsrepatch when warranted.
11:04 berick bshum: that's essentially what I was proposing
11:04 bshum The new direction
11:05 * bshum shrugs, works either way I guess
11:05 berick bshum: ... to avoid having 2 classes of untargeted pullrequests, those w/ no target, and those w/ a virtual target.
11:05 berick as to me they are the same thing
11:05 bshum As long as bugs get worked on, I think that's the key goal :D
11:06 berick very diplomatic ;)
11:06 bshum gmcharlt: Speaking of, sorry I saw your question... but got distracted, lol.  So uh, my answer is maybe
11:06 bshum gmcharlt: I didn't get to play with it directly myself yet
11:06 bshum But I'm always happy to test and merge stuff that people push my way
11:07 kmlussier Yeah, if I were proposing anything, it's probably that bugs get worked on. :) I know core committers are busy, but one or two bugs a month seems reasonable to me.
11:30 csharp gmcharlt: I'll take a look
11:33 gmcharlt csharp: great!
11:41 pinesol_green [evergreen|Kathy Lussier] LP#1673891: Fix untranslatable strings in metarecord sibling links - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=943f2e8>
11:49 khuckins__ joined #evergreen
12:06 Bmagic joined #evergreen
12:09 berick dbwells++
12:10 jihpringle joined #evergreen
12:13 sandbergja joined #evergreen
12:14 csharp gmcharlt: https://bugs.launchpad.net/eve​rgreen/+bug/1669868/comments/3
12:14 pinesol_green Launchpad bug 1669868 in Evergreen ""make check" failure" [High,Confirmed]
12:29 kmlussier csharp++
12:30 * dbs wanders in, wonders if migrating launchpad processes to a more laissez-faire github-or-similar system might be an option to avoid the whole targeting etc mess
12:30 dbs but really just a drive-by thought
12:34 jvwoolf1 joined #evergreen
12:34 * kmlussier thinks dbs just volunteered for something. ;)
12:36 dbs heh let's discuss it during the Reds game
12:38 * dbs bookmarks https://github.com/johnf/github-issue-importer
12:42 Dyrcona moving to github would make use more visible.
12:42 Dyrcona s/use/us/
12:43 Dyrcona If I could stop making typos, I'd actually get something done. ;)
12:44 csharp ugh - so adding an LDFLAG to fix 'make check' on 16.04 breaks it on 14.04
12:45 kmlussier :(
12:45 csharp /usr/bin/ld: cannot find -lsubunit
12:46 csharp it's possible adding these flags also breaks make check on jessie
12:49 csharp okay - time for a new deb dependency :-)
12:51 Dyrcona csharp: I was thinking of looking at that while I wait on a db dump to copy. Any particular distro?
12:51 Dyrcona I have vms for jessie, wheezy, trusty, and xenial ready.
12:53 csharp Dyrcona: jessie and wheezy (if we're still keeping wheezy alive)
12:53 Dyrcona csharp: We are keeping wheezy alive for now.
12:54 csharp I just updated the branch with a new dependency for ubuntu-trusty - probably necessary in wheezy too, but I don't know
12:54 bshum He's more machine now than man.
12:54 Dyrcona OK. Should I try without the branch and then with?
12:55 * Dyrcona checks if he has enough free ram to start a vm locally.
12:55 Dyrcona I forget, now...does everything have to be configured for make check?
12:56 Dyrcona Wheezy is fresh, I don't even have a git clone on it.
12:57 tspindler joined #evergreen
13:01 csharp bshum++
13:01 csharp Dyrcona: I've been doing configure, make, then make check
13:02 csharp (with 'make clean's as root in between runs)
13:03 Dyrcona csharp: OK.
13:16 kmlussier If anyone on the web team has tuits available, I've noticed that Jetpack is no longer publishing new blog posts to the Evergreen Google+ page. I looked at it a couple of weeks ago, but nothing obvious jumped out at me.
13:23 Dyrcona FYI: make check for OpenSRF succeeds.
13:34 Dyrcona csharp: Evergreen make check just works on Wheezy without the patch. I'll try with the patch.
13:34 csharp Dyrcona: excellent
13:35 miker berick: you have some time to talk about some aspects of offline+hatch?
13:37 Dyrcona csharp: with the branch I get: /usr/bin/ld: cannot find -lsubunit
13:37 Dyrcona Which makes sense, since subunit-dev is only installed on trusty.
13:37 tspindler left #evergreen
13:39 berick miker: i do
13:39 * dbs hums "service workers + IndexedDB (https://developer.mozilla.org/en-US/docs/Web/​API/Service_Worker_API/Using_Service_Workers)"
13:40 miker berick: sweet.  topic for today: offline block list
13:41 miker jumping right into the deep end, I think it's a bad idea for the browser itself to download the block list if hatch is available
13:42 miker and, the access pattern for the block list in the offline interface won't match the {get|set}Item pattern that exists today
13:43 miker so, I'd like hatch to grow 2 new things: 1) an API to be told to download the block list for itself (seem simple enough? just "GET /whatever") and 2) a fast access mechanism for "is this barcode blocked, and how?" ... SQLite?
13:44 csharp Dyrcona: that's with jessie?
13:44 Dyrcona Wheezy.
13:45 Dyrcona I reverted the two two commits and make check works with just the additional flags, or without.
13:45 Dyrcona I am going to comment on the bug.
13:45 csharp good
13:46 Dyrcona Well, I think we're going to need distro-specific changes for make check.
13:46 berick miker: wading a little slower into the deep end, is the assumption that offline use requires hatch?  or that hatch will improve the process?
13:46 miker btw, I am planning to make use of the append() API to store offline xacts ... and, ideally, hatch would learn how to upload them itself and move them out of the way after doing so
13:46 miker berick: well, I'm starting with a hatch-first mentality, because we have IndexedDB (as dbs mentioned :) ) for the block list in the worst case
13:48 dbs Why not just let service workers do their job of syncing up once online access is restored?
13:49 miker though offline file upload without hatch is looking ... unfriendly, at least in terms of unmediated upload (without some server rewriting)
13:49 berick dbs: i was thinking about that too - offload the process by letting service workers do it in the background
13:49 miker dbs: because in chrome, having a local network connection is the same as being "online"
13:49 * berick can't comment on indexeddb yet -- need to read more
13:50 miker "evergreen server down" is not "offline" to the browser, IOW
13:51 berick i'm talking about service workers for fetching the offline file, not for uploading
13:51 miker that's an option, sure
13:53 miker in that case, hatch would still need some new API to insert new entries read by the browser into some searchable structure
13:53 berick yeah, agreed there
13:54 miker that would be a good abstraction for hatch/indexeddb
13:54 berick yeah
13:57 dbs miker: uh, the service worker intercepts network requests; and if a given request fails, then it can do something different (like store that request)
13:57 dbs It has nothing to do with being online or offline
13:57 dbs (other than when you're offline, your network requests are pretty much guaranteed to fail)
13:58 berick miker: for append-able data, we probably need a way to tell hatch that a set of data (a given key, for example) should be treated as a stream / collection instead of a single JSON thing
13:59 miker dbs: are you suggesting using a manifest to make everything that exists now offline-ready? that's not where I'm planning to go today
14:00 miker berick: right, we could use a map keyed by barcode, or an sqlite table, or something similar. hidden behind a set of new message types
14:01 * berick nods
14:01 miker my thought with having hatch to the heavy lifting was to encapsulate everything there, only shove the block list into local storage if hatch wasn't available
14:02 dbs miker: while it would be great to make everything offline-ready (and thus not having to have a separate offline interface at all), that's a pretty huge undertaking
14:02 miker dbs: 'zackly :)
14:03 dbs but if an offline-specific interface stored its requests in IndexedDB until such time as the service worker was successful in uploading them to the server, that would sense to me
14:04 kmlussier rhamby: Do you think we could make the GPLS and GRPL jobs on our jobs board expired? http://evergreen-ils.org/jobs/
14:04 berick dbs: uploading them to the server is (with the current offline code) requries more coordination than just pushing the files, though.
14:04 miker well, there's benefit in having a human involved, especially for multi-site libraries
14:04 rhamby kmlussier: probably, let me look real quick
14:05 berick i'm not worried about the uploading.  i expect that will be pretty similar to how it works now.
14:05 miker /especially/ especially for multi-day offline use (migrations, etc)
14:06 berick dbs: does indexeddb require special permissions?  is it available to any site?
14:07 dbs berick: service workers require https
14:07 miker berick: are you imagining creation of a blob and $http.post()?
14:08 berick miker: yeah, somethign like that.  hadn't gotten that far, I just assumed it would be do-able without to much fuss.
14:08 rhamby kmlussier: done. I expired the GA PINES one for today but I think someone else deleted the other two.
14:08 kmlussier Two?
14:09 berick dbs: but it doesn't require an extension, app, configuration, etc.  you just write some js and plop it into a service worker?
14:09 berick and have the service worker relay data to the page script via dom messaging?
14:10 dbs berick: pretty much
14:10 dbs http://caniuse.com/#feat=indexeddb
14:11 berick 50M limit on chrome
14:12 berick ditto firefox
14:12 berick wonder how resilient the data is
14:13 dbs https://developer.mozilla.org/en-US/​docs/Web/API/IndexedDB_API/Browser_s​torage_limits_and_eviction_criteria
14:14 dbs https://developers.google.com/web/fundamentals/​instant-and-offline/web-storage/offline-for-pwa for Chrome deets
14:15 dbs ""Persistent" storage is not automatically cleared when storage is low. The user needs to manually clear this storage (via browser settings). Chrome has been experimenting with support for Persistent Storage under an origin trial, and the latest news suggests it will be shipping in Chrome 55." (guess we'll see what happened now that we're at Chrome 56)
14:16 berick and when it clears, it uses least-recently-used, so don't leave offline data in the db for weeks, i guess
14:16 dbs Yeah, hook that bookmobile up once in a while
14:17 jeff chrome's experimentation required that you have no fewer than 5 sites bookmarked, and the site wanting to use persistent storage had to be one of them...
14:18 jeff with Chrome 55, the permission is denied unless the site is bookmarked (and the user has 5 or fewer bookmarks); the site has "high site engagement"; the site has been added to the home screen; or the site has push notifications enabled.
14:18 jeff last one is probably the most reliable / sane.
14:19 jeff https://developers.google.com/web/​updates/2016/06/persistent-storage has more detail.
14:20 jeff some discussion from last year on this subject: http://irc.evergreen-ils.org/​evergreen/2016-11-03#i_274645
14:21 berick miker: as i've said before, my default will always be to avoid using hatch when reasonable to do so.  if using indexeddb is a sane way to handle non-hatch sites, my preference would be to start there, then add hatch support as needed.
14:21 berick as always, though, if we need hatch, we need it
14:22 berick just looking at our offline block list, it's 7.2M today
14:22 miker well, we need it for printing at the circ desk (nominally), right?
14:22 berick that's a decent chunk of the 50M limit
14:22 berick miker: if you only need 1 printer, not necessarily
14:22 berick you can configure the browser to auto print and set it up how you want
14:22 miker without headers/footers or popups?
14:23 berick can those things not be controlled with the browser's print configuration?
14:23 miker I don't see a "without the user intervening" option
14:24 miker I may just not know how to make that happen, though
14:24 miker looks like you have to start chrome with a couple flags
14:25 miker it's unclear if you can do it without also being in kiosk mode (fullscreen)
14:26 miker ok, looks like you might be able to, with --kiosk-printing
14:27 miker so, maybe set up headers/footers by printing once, then add --kiosk-printing to the shortcut
14:28 miker but, if you need to print to a receipt printer and also a full printer, you have to use the dialog, or hatch
14:28 berick right
14:29 berick arg, i have to step away for a bit.  will return.
14:29 pinesol_green [evergreen|Jillianne Presley] Docs: replacing XUL booking module screenshots with browser client ones - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c67fd7e>
14:40 alynn26 joined #evergreen
14:56 Christineb joined #evergreen
15:03 mmorgan1 joined #evergreen
15:03 berick it's raining RM's!  gmcharlt++
15:06 csharp gmcharlt++
15:07 csharp dbwells++ # I'm reading reverse chronologically :-)
15:07 jeffdavis dbwells++ gmcharlt++ rings_with_hats_in_them++
15:08 berick booting_up_the_thunderdome++
15:09 berick (it runs on windows 98)
15:09 csharp https://www.youtube.com/watch?v=tajDxBaPBBM
15:09 berick you've got mail!
15:10 kmlussier joined #evergreen
15:11 berick miker: another thought, assuming a non-hatch version of offline is viable, starting there lowers the barrier to entry for broader testing.
15:12 miker it does, certainly. (sans printing stuff above)
15:36 hbrennan joined #evergreen
15:39 Jillianne joined #evergreen
15:40 Dyrcona gmcharlt | csharp: https://bugs.launchpad.net/eve​rgreen/+bug/1669868/comments/9
15:40 pinesol_green Launchpad bug 1669868 in Evergreen ""make check" failure" [High,Confirmed]
15:40 Dyrcona I developed that on Ubuntu 16.04. I'll test on wheezy, jessie, and trusty next.
15:41 gmcharlt Dyrcona: thanks
15:48 Dyrcona Works for me on jessie.
15:51 Dyrcona Works on wheezy.
15:52 Dyrcona Really? that only took 3 minutes?
15:53 Dyrcona trusty will take longer. I have to install prereqs and OpenSRF.
16:01 khuckins_ joined #evergreen
16:08 Dyrcona It would probably go a bit faster if cpan hadn't decided to use a mirror in Indonesia.
16:14 bshum Dyrcona: Your fix worked for me on Xenial and Trusty
16:15 Dyrcona Thanks for checking. You could signoff if you feel so inclined. :)
16:15 bshum I could sign off and push it, sure
16:16 Dyrcona Well, I think gmcharlt wants to look at it, maybe. I know the release is tomorrow and he's building it.
16:16 bshum Gotcha
16:16 bshum I'll just sign it then :)
16:16 gmcharlt yeah, I glanced at the patch but will push it tomorrow
16:17 Dyrcona I think it's the right thing. Basically a copy and paste from OpenSRF's configure.ac.
16:17 sandbergja joined #evergreen
16:26 bshum joined #evergreen
16:27 mmorgan joined #evergreen
16:52 bshum Taco time :)  See you guys later...
17:00 Dyrcona I ..am.. outta here!
17:00 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:09 mmorgan left #evergreen
17:10 khuckins joined #evergreen
17:11 * kmlussier heads out to get pizza.
17:12 csharp Dyrcona++
18:07 gsams joined #evergreen
20:12 pinesol_green [evergreen|Ben Shum] Docs: README to include Debian for changing ownership of /var/lock/apache2 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=81a57b2>
21:36 bshum Hmm
21:36 bshum Random thoughts
21:36 bshum 1)  in responsive design, there's no filter for changing locales
21:36 bshum It's hidden
21:37 bshum So that needs to get added somewhere, somehow, someday
21:37 bshum Well, it'd be nice
21:39 bshum 2) might need something to handle the adv_filter_results_group direction for RTL vs. LTR to organize the content accordingly to the direction the text flows.
21:39 bshum As is, it always presents filter type and content as LTR
21:41 bshum 3) after doing an advanced search in one locale and then clicking a locale swap, we get a bad ARRAY(xxxxx) search that results in zero hits, instead of just swapping languages
21:41 bshum And you lose your original parameters, of course
21:41 bshum I'll type some of this stuff up into relevant LP
21:51 bshum Ah, yup, locale_picker_form is set to display: none; in mobile CSS. Hmm, guess we'll have to think of somewhere good to put that.
21:58 bshum I think I'm really starting to enjoy the nginx proxy :)
23:56 bshum joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary