exp-run-k# make MASTER_SITE_BACKUP=NOT_FOUND/// checksum ===> License MIT accepted by the user ===> zephyr-3.0.1_3 depends on file: /usr/local/sbin/pkg - found => zephyr-3.0.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch http://zephyr.1ts.org/export/2642/distribution/zephyr-3.0.1.tar.gz fetch: http://zephyr.1ts.org/export/2642/distribution/zephyr-3.0.1.tar.gz: No address record => Attempting to fetch NOT_FOUND///zephyr-3.0.1.tar.gz fetch: NOT_FOUND///zephyr-3.0.1.tar.gz: Invalid URL scheme => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop. make: stopped in /usr/ports/net-im/zephyr exp-run-k#
Upstream is now at https://github.com/zephyr-im/zephyr , though given how github works I expect the tarball with the checksums in FreeBSD ports subversion to not be available there. Probably this means I should take this PR as a stimulus to package a newer version.
We can do github. See security/krb5-devel. Instead of a hash we can use a tag. I can help out or post a patch here. Either works for me.
Right, the makefile infrastructure has lots of support for making porting github projects easy. My point was more that github is not really a drop-in replacement for the current master site, since the old master site had a fixed tarball which differs from the way github does tarballs.
Yes, the tarball will have a different name but it is 100% reproducible, distinfo works.
Created attachment 207340 [details] USE_GITHUB for Zephyr Hi Ben, Github is used for loads of ports, and the tarball is still in distinfo, so it will never change without notice. This patch shows it fetching from Github (the newest version), though I've not build or run tested it. Do you think you would be able to update it from here? Chris
Mind if I commit this Ben?
(In reply to Chris Rees from comment #6) Please go ahead Chris, and thanks for checking back about it. I seem to have missed the traffic from September :(
Any news? This port expired on 2020-05-05.
Sorry René, that's me missing Ben thanking me after missing my email...
Hi Ben, Frustratingly it appears Heimdal has moved on a bit... or it is supposed to be with MIT... or something, I'm not a Kerberos expert :) René I'm sure won't mind holding off the removal for a week or two if you have a chance to look at it? Or are you happy for it to drop off? Patch linked below. ZMkAuth.c:131:32: error: no member named 'contents' in 'struct EncryptionKey' memcmp(Z_keys_head->keyblock->contents, keyblock->contents, ~~~~~~~~~~~~~~~~~~~~~ ^ ZMkAuth.c:131:52: error: no member named 'contents' in 'struct EncryptionKey' memcmp(Z_keys_head->keyblock->contents, keyblock->contents, ~~~~~~~~ ^ ZMkAuth.c:132:19: error: no member named 'length' in 'struct EncryptionKey' keyblock->length) == 0) { ~~~~~~~~ ^ https://www.bayofrum.net/~crees/patches/zephyr-still-not-working.diff
I will try to take a look this week; sorry for not following up on this on my own. The codebase was originally developed against MIT krb5, and gets pretty confused in an environment where both are present. (I run a build with local patches and have to uninstall krb5 in order to do my build ... if I net-im/zephyr updated more often I'd probably end up setting up poudriere to avoid that hassle.)
Created attachment 215121 [details] patch to use github as master site and fix build This patch should build and install using github as the master site, assuming that I didn't bungle it copying bits around. It turns out that upstream really did regress and incorporate MIT-krb5-specific code; see https://github.com/zephyr-im/zephyr/pull/133, though my approach is slightly different. (I may have to try to join upstream's team and help out, it seems...) Chris, are you still interested in testing/reviewing, or should I seek help elsewhere?
Sure, I'll take a look. By the way, you can't patch configure, as it's generated from configure.ac, so you need to patch configure.ac instead. I'm happy to deal with that.
Thanks for taking a look. I should be removing all of the patchfiles currently in the tree (including patch-configure), only to drop some new ones in that touch different files.
(In reply to Benjamin Kaduk from comment #14) Any updates, Chris? I don't mind setting up a review and getting a different ports committer reviewer if you want to step away from it.
Hm, sorry, the ball was indeed in my court. It's confusing because they use autoconf but not automake, but you still need the automake support files. I think I'll hand hack around that. Should be able to look over the next day or two.
(In reply to Chris Rees from comment #16) Indeed, the autoconf-but-not-automake-but-with-support files situation is quite odd. I have gained some privileges upstream in the intervening period, if you have thoughts about a good way to address the issue there.
Managed to find time for this- your latest patch unfortunately still fails to build. Is it still an MIT issue do you think? https://www.bayofrum.net/pkg/121amd64-system/latest/logs/errors/zephyr-3.1.2_4.log
Hi, is there any news on this port?
Just realised the link above broke when I ran poudriere again. It failed still for me: https://www.bayofrum.net/pkg/121amd64-system/2020-07-07_18h18m18s/logs/errors/zephyr-3.1.2_4.log I wonder if we should let René expire the port for now and resurrect it if we manage to get it fixed?
Probably.
I'll remove the port, feel free to re-add a working copy.
Okay. I still am confused by Chris's build results, as they indicate that parts of MIT krb5 were present for some steps of the build but absent at others. (And the patch I produced worked fine for me on a pristine "bare metal" (i.e., VM) system.)