Home
release-team@conference.openafs.org
Friday, April 19, 2019< ^ >
Room Configuration
Room Occupants

GMT+0
[12:28:45] meffie joins the room
[12:55:16] meffie leaves the room
[13:20:18] mmeffie joins the room
[13:35:56] mmeffie leaves the room
[13:54:54] meffie joins the room
[14:56:59] <meffie> good afternoon
[14:57:06] <kaduk@jabber.openafs.org/barnowl> greetings
[14:57:24] <kaduk@jabber.openafs.org/barnowl> Thanks for pushing the schedule back this week for me!
[14:57:47] <mvita> hello
[14:58:22] wiesand joins the room
[14:58:34] <wiesand> Hello
[14:59:06] <meffie> you are welcome ben, glad to do it.
[14:59:40] <wiesand> +1
[15:01:39] <wiesand> I just started uploading (preliminary) 1.8.3 tarballs to g.c.o.
[15:01:48] <wiesand> not smoke tested yet though
[15:02:01] <kaduk@jabber.openafs.org/barnowl> cool
[15:03:06] <meffie> great news, thank you
[15:05:26] <wiesand> I'd like to wait with the tag & announcement until after some smoke testing, but that should be really soon now.
[15:06:17] <kaduk@jabber.openafs.org/barnowl> I'm on a plane a few times in the next week, so may have slightly
higher latency than usual for tagging, but I think still sub-day.
[15:07:16] <wiesand> For the announcment & web page I think I'll just reuse what was written for 1.8.3pre, w/o changes
[15:07:31] <wiesand> Ben, I hope to ask you for the tag later today
[15:08:17] <kaduk@jabber.openafs.org/barnowl> Okay, I should still be around then :)
[15:09:49] <wiesand> I see the elfutils-devel requirement of the redhat rpm is on RHEL8 beta
[15:10:32] <wiesand> (RT # 134900)
[15:11:21] <meffie> yes. it is needed to build any kernel module on rhel8 (beta)
[15:12:13] <meffie> cheyenne submitted a bug report to bugzilla, and we can work around it if they dont fix it i suppose.
[15:13:04] <wiesand> I tend to think this should be fixed in their kernel-devel package, but have no problem adding a %if %rhel >= 8" build dependency to our packaging
[15:13:39] <kaduk@jabber.openafs.org/barnowl> Indeed.
[15:13:45] <wiesand> NB they made Cheyenne's BZ private :-[
[15:13:52] <meffie> ok, sounds like a plan.
[15:14:03] <meffie> oh, rats.
[15:14:31] <meffie> i'll let him know. we can put the same info in rt if we have to.
[15:14:43] <meffie> (e.g. how to reproduce)
[15:15:07] <wiesand> no worries, I think I have a good idea of what's in there ;-)
[15:16:17] <mvita> what are the implications of the BZ being private?
[15:16:48] <mvita> (why "oh, rats" ?)
[15:16:49] <meffie> you just need a redhat account to see it i think.
[15:16:57] <mvita> oh
[15:17:12] <meffie> it's not convenient
[15:17:13] <wiesand> it's not visible to anyone not explicitly allowed to see it
[15:17:31] <wiesand> you need a redhat account *and* the extra permission
[15:18:31] <wiesand> "You are not authorized to access bug #1701282.
Most likely the bug has been restricted for internal development processes and we cannot grant access."
[15:19:07] <kaduk@jabber.openafs.org/barnowl> Seems kind of questionable given the contents of the bug.
[15:19:36] <kaduk@jabber.openafs.org/barnowl> But perhaps they kicked off some wide-reaching architectural
discussion that then revealed some vulnerability in the build process;
we can't know for certain.
[15:19:57] <mvita> or it's simply that RH8 is still beta
[15:20:18] <mvita> (it is, isn't it?)
[15:20:42] <wiesand> It is.
[15:20:47] <meffie> yes
[15:21:18] <mvita> plenty of good business reasons to keep that info closely held
[15:21:34] <wiesand> RHBZ used to be a very useful source of information. But lately almost all BZs I'm interested in are private :-(
[15:21:47] <wiesand> I'd even call it a change in culture
[15:22:07] <wiesand> that's about it from my side today -  want to go on to master while I bake the SRPM?
[15:22:19] <mvita> Oracle also found them a very useful source of information ;-)
[15:22:54] <kaduk@jabber.openafs.org/barnowl> Not a huge amount to say about master from my end -- I have gotten a
couple things in over the past hour but had no other time this week to
do much
[15:23:20] <kaduk@jabber.openafs.org/barnowl> rxgk-phase1 remains near the top of the priority list, of course
[15:24:19] <kaduk@jabber.openafs.org/barnowl> Oh, and I did also take a look at the libuafs CFLAGS thing that Andrew
wanted to cherry-pick to 1.8.x (for 32-bit RPM builds on EL5 or
something like that), which still does look okay
[15:24:57] <meffie> thank you
[15:24:59] <mvita> oh, that reminds me of something else I wanted to mention to you about debug flags, Ben
[15:25:34] <mvita> -DRX_REFCOUNT_CHECK is intended to be on in master and 1.8.x after your rxevent refactoring
[15:25:44] <mvita> but rx is actually built in multiple places
[15:25:48] <mvita> in tree
[15:25:58] <kaduk@jabber.openafs.org/barnowl> true
[15:26:05] <mvita> so not all places see -DRX_REFCOUNT_CHECK
[15:26:13] <mvita> including most of the server binaries
[15:26:21] <mvita> since they use libafsrpc
[15:26:27] <mvita> no refcount check there
[15:26:47] <mvita> I was going to submit something to gerrit
[15:26:55] <mvita> since I fixed it here for some of my own dev work
[15:27:02] <mvita> but I didn't get to it yet
[15:27:43] <kaduk@jabber.openafs.org/barnowl> Hmm, the librx_pic build doesn't pick up the MODULE_CFLAGS?
[15:28:35] <mvita> I don't remember the reason off the top of my head
[15:28:46] <mvita> looking for my patches...
[15:28:54] <kaduk@jabber.openafs.org/barnowl> Okay. Well, I'll take a look when something hits gerrit :)
[15:28:59] <mvita> yup
[15:29:19] <meffie> heh
[15:30:49] <meffie> time for the buildbot update?
[15:32:26] <kaduk@jabber.openafs.org/barnowl> go for it
[15:32:45] <meffie> thanks.
[15:33:14] <meffie> 1. ssl/tls seems to be working well for me still. thank you ben!
[15:33:46] <mvita> <huzzah!>
[15:34:02] <meffie> 2. the new macos workers were having some trouble, but marcio figured out the issue. (energy save mode was not disabled)
[15:34:35] <meffie> (so they would sleep at random times and tended to drop)
[15:34:48] <kaduk@jabber.openafs.org/barnowl> I remember running into some annoying energy save issues elsewhere,
yeah.  Kind of annoying
[15:34:57] <mvita> why not let them sleep and use wake-on-lan?
[15:35:19] <meffie> because they seem would do that in the middle of a gerrit build!
[15:35:31] <meffie> any way.
[15:35:35] <mvita> <sadness>
[15:36:10] <kaduk@jabber.openafs.org/barnowl> I think they maybe want to see "interactive" processes in order to
avoid sleeping, or something like that; triggered builds probably
don't reach that threshold
[15:36:10] <meffie> 3. i fixed the master config so pushing to openafs-web on gerrit no longer triggers builds of openafs
[15:36:50] <wiesand> nice
[15:37:37] <kaduk@jabber.openafs.org/barnowl> agreed, quite nice -- thank you!
[15:37:37] <meffie> i'll be looking next on how to improve gerrit builder resilience. offline builders should not hold up verifications from the ones still online.
[15:37:50] <meffie> that's all. thanks.
[15:38:04] <mvita> that's pretty good, Mike, thanks
[15:38:24] <mvita> you da man
[15:38:30] <wiesand> btw, the web change for 1.8.3 will have a path conflict with at least one of your web fixes unless we merge them all before - how should we handle this?
[15:38:34] <meffie> since openafs-web no longer triggers builds of the openafs code, i've started pushing updates / cleanups  to openafs-web.
[15:38:59] <meffie> i can rebase after your update if you like.
[15:39:35] <wiesand> ok, thanks
[15:39:45] <meffie> the changes i made did no change anything in releases, i was waiting to hear back before messing with those files.
[15:39:57] <meffie> s/did no/did not/
[15:40:21] <wiesand> yes, the clash is in main.html
[15:40:39] <meffie> ok. i'll rebase. any chance of getting the tidy fixes merged after the release?
[15:43:16] <wiesand> It's a lot to review… I wonder whether that's a case of "merge sfiftly and fix fallout later"?
[15:44:24] <kaduk@jabber.openafs.org/barnowl> quite possibly
[15:44:34] <meffie> yes, i think so. the changes were made manually and cheyenne already reviewed.
[15:44:51] <meffie> html tidy reports clean results after them.
[15:45:19] <wiesand> They all have a +1… shall I just merge them before I create the web change for 1.8.3? (saves a bit of Mike's time)
[15:45:30] <meffie> woot!
[15:45:59] <kaduk@jabber.openafs.org/barnowl> no objection here
[15:46:09] <meffie> i promise to send fixes if any problems are noticed.
[15:46:15] <kaduk@jabber.openafs.org/barnowl> (not that I looked at the changes themselves, just the titles...)
[15:46:56] <wiesand> I glanced over them, partially
[15:47:22] <meffie> thank you.
[15:47:36] <meffie> boring stuff. just broken tags and such.
[15:48:01] <kaduk@jabber.openafs.org/barnowl> Sure.  Thank you for doing the work (and Cheyenne for reviewing it)!
[15:48:01] <wiesand> I'll have a quick look before hitting the submit button, but don't expect to find anything I'd object to. Let's just do it then.
[15:48:12] <mvita> boring is good
[15:48:14] <meffie> YAY
[15:50:16] <wiesand> I should have a 1.8.3 client running on an EL7 test system in a few minutes…
[15:50:21] <wiesand> (or not ;-)
[15:51:07] <mvita> <stands by with fire extinquisher>
[15:56:40] <mvita> any other business?
[15:58:07] <wiesand> client works - I'd like to ask for the tag now
[15:58:12] <meffie> back on the topic of openafs-web; wiesand and kaduk, any reply on the questions about /realease/* would be helpful.
[15:58:33] <kaduk@jabber.openafs.org/barnowl> I think I missed the questions, whoops
[15:59:00] <meffie> also, i did not get reply from cmu about the ht_export scripts
[15:59:15] <wiesand> Ben: could you please tag ad37d5b186c7ea62c874546472a807310acf0e75 as openafs-stable-1_8_3 ?
[16:01:20] <kaduk@jabber.openafs.org/barnowl> Done.
[16:01:29] <wiesand> Thanks
[16:01:37] <mvita> cool
[16:02:01] <kaduk@jabber.openafs.org/barnowl> (Where were the questions about openafs-web release/* that I need to
look at?)
[16:02:57] <wiesand> somehow i must have missed those too
[16:03:21] <meffie> I've pushed a series of commits for the openafs-web git repo.  These are meant
to just fix obsolete and broken tags, based on the results of the html `tidy`
tool.  No content changes have been made. I've skipped the files under the
release directory for now. This clean up is the first step to getting the site
in shape.
There are a number of symlinks in the release directory for releases. Some html
files in release are regular files and others are symlinks to
<version-number>/index.html. Is this inconsistency necessary?  Would a patch to
fix this be acceptable?  As is, it will make the html generation more
difficult.
[16:04:03] <wiesand> ah, right
[16:04:06] <kaduk@jabber.openafs.org/barnowl> Ah, they were in mail, and my inbox is a disaster.
I kind of remember noticing something like that in the deluge as it
went by :(
[16:04:11] <wiesand> the answer is "I don't know"
[16:04:36] <meffie> valid answer!
[16:05:10] <kaduk@jabber.openafs.org/barnowl> I think we wanted to do symlinks generically but that was probably not
the universal historical practice, and we're probably not fully
consistent about it
[16:05:44] <meffie> seems plausible.
[16:07:41] <meffie> when changes like gerrit 13518 are done, are those just made manually some how?
[16:08:09] <kaduk@jabber.openafs.org/barnowl> There's a make_www_release.pl script that Stephan and I have local
versions of
[16:08:17] <meffie> ah!!
[16:08:44] <kaduk@jabber.openafs.org/barnowl> There is probably even a gerrit change sitting around that tries to
update the in-tree version to something more usable, but if so it
stalled for lack of love :(
[16:09:12] <wiesand> it creates the release/ subdirectory (but not the symlink)
[16:09:29] <meffie> it's the make_www_release in git://git.openafs.org/tools.git ??
[16:09:47] <kaduk@jabber.openafs.org/barnowl> derived from it, yes
[16:09:58] <meffie> ok
[16:10:38] <wiesand> 11122 was meant to be a start to get my local changes in
[16:10:39] <meffie> my evil plan is to try to migrate to jekyll (or some other tool if you prefer)
[16:10:53] <wiesand> you mentioned that
[16:12:02] <meffie> that means, you'd need to run jekyll build or some such instead of make_www_release. obviously i dont want to make things worse or more difficult.
[16:12:04] <wiesand> I'd prefer to get rid of the generated files lists on the release pages alltogether
[16:13:16] <wiesand> jekyll is python, right?
[16:13:22] <meffie> oh? wouldn't that break links? which files?
[16:14:33] <meffie> jekyll is acually ruby, but i've never needed to look at the source. hugo looks like a nice one too. it's in go and has pre-built packages of binaries.
[16:15:29] <meffie> at any rate, i feel we can migrate incrementally and not worry about structure or content changes yet.
[16:18:16] <wiesand> I meant the links to the actual files generated by the make_www_release script.
[16:18:31] <meffie> the symlinks?
[16:18:39] <wiesand> html links
[16:19:08] <wiesand> have a look at https://www.openafs.org/release/openafs-1.6.7.html
[16:19:29] <meffie> looking...
[16:19:46] <kaduk@jabber.openafs.org/barnowl> In your statement, is make_www_release generating links or files?
[16:20:03] <wiesand> I'd rahter have the files indexed dynamically than having  a static page with links like openafs-1.6.7-src.tar.gz <https://www.openafs.org/dl/openafs/1.6.7/openafs-1.6.7-src.tar.gz>
[16:20:53] <wiesand> static html files with html links to the tarballs etc.
[16:20:54] <meffie> ah, you mean like how apache makes indexes with mod_index?
[16:21:11] <wiesand> exactly
[16:21:56] <meffie> that makes sense, but would require some apache configuration changes, no?
[16:22:49] <wiesand> especially since everybody wants me to upload linux packages - I feel no urge to run jekyll build every time there's an EL kernel update
[16:23:38] <wiesand> and I'd rather have the uploaded files signed properly, instead of the checksums on the web pages
[16:25:17] <wiesand> anyway, looking at my backlog, web beautification and other changes in this area are not my top priority
[16:25:53] <meffie> the point being, we should let apache provide the file indexes, and not need to regenerate files, push to gerrit, and merge.
[16:26:35] <wiesand> that would help, yes
[16:26:44] <kaduk@jabber.openafs.org/barnowl> I'll try to remember to puster jhutz/Chaskiel if I see them.
I suppose they'll be around in June at least...
[16:27:18] <meffie> thanks kaduk.
[16:27:51] <meffie> (also, i think just providing dkms should be good enough :)
[16:28:09] <kaduk@jabber.openafs.org/barnowl> :)
[16:28:45] <wiesand> one of the two sites still looking for our binaries will require the kmods…
[16:29:29] <meffie> oh, sadness.
[16:30:24] <wiesand> anyway, when I upload EL binaries next time I'll resrict it to the dkms package
[16:30:32] <meffie> here's your indexes :)
https://www.openafs.org/dl/
[16:31:08] <wiesand> Yes, something *like* that ;-)
[16:31:43] <meffie> why dont we just html link to the directory and not the files? e.g. https://www.openafs.org/dl/1.8.2/
[16:31:44] <wiesand> Ben: could you mail me your local version of make_www_release?
[16:31:52] <kaduk@jabber.openafs.org/barnowl> sure
[16:32:22] <wiesand> Mike: because this lacks the link to the license and the other boiler plate stuff
[16:32:41] <meffie> oh, ok.
[16:33:26] <meffie> sorry for wasting everyone's time on this. thanks for listening and explaining
[16:35:36] <wiesand> It's getting late here, and I'd like to get the remaining work on 1.8.3 done (and the web fixes merged) today… anything else that can't be deferred to next week?
[16:35:47] <kaduk@jabber.openafs.org/barnowl> not from me
[16:36:04] <meffie> not from me. sorry for the diversion. thank you.
[16:36:25] <wiesand> thanks a lot everybody!
[16:36:44] <kaduk@jabber.openafs.org/barnowl> thanks everyone!
[16:36:59] <meffie> have a good weekend.
[16:37:17] <mvita> so long
[16:37:20] wiesand leaves the room
[16:40:49] meffie leaves the room