Dependency issue? Build fails src/github.com/rclone/rclone/backend/ftp/ftp.go:401:37: undefined: ftp.DialWithForceListHidden

Dev Discussions
1

Hi,
I'm trying to update the Debian package of rclone, to 1.160. Having packaged up a bunch of the newer build-dependencies, I'm almost there, but the build is failing:

src/github.com/rclone/rclone/backend/ftp/ftp.go:401:37: undefined: ftp.DialWithForceListHidden

Now I've pulled in GitHub - rclone/ftp: FTP client package for Go (and, indeed, DialWithForceListHidden isn't defined there); I notice that is a fork of GitHub - jlaffaye/ftp: FTP client package for Go and that does have DialWithForceListHidden introduced in a later commit - Add forceListHidden dial option to force the use of 'LIST -a' command… · jlaffaye/ftp@99be063 · GitHub

So what should I be trying to do here? get that commit applied to GitHub - rclone/ftp: FTP client package for Go, using jlaffaye/ftp instead, or something else?

Thanks!

2

I think you've probably got the wrong branch of rclone/ftp - the commit ID is in the go.mod file

3

Ah, yes, sorry, I looked at the tip of master and the version in Debian (v1.0.0-210902h). If I make a new library package based on e44dedbc76c6 which is the tip of dev-rclone-160 (and the commit has mentioned in go.mod) then it builds OK.

Would you be up for tagging that commit as a new version, please? It's sort of a de facto release, but it'll be easier to get the package in Debian updated to a new tagged version rather than just a commit hash...

Thanks :slight_smile:

4

I pushed a tag v1.0.0-220913-160 hopefully that will work for you!

This repo is a temporary for while we get stuff upstream so hopefully not needed for much longer.

1 Like
5

Not sure we're doing the forking of upstream in the best way here...

When we rebase on upstream we create a new branch then cherry pick our unmerged commits onto that branch, so dev-rclone-160 for the rclone v1.60 release - now with tag v1.0.0-220913-160.

Does that seem sensible to you?

I guess we could be doing it with merge commits on master however I'm not a big fan of non-linear history...

6

Thanks, that should be just the ticket :slight_smile:

7

Much ink has been spilled on this topic!
I tend to use a merging sort of workflow myself, especially if I expect my upstream to take all or nearly all of my changes (it's less work than new-branch-and-cherry-pick), but I think if you dislike nonlinear history and don't mind the extra work your process works fine :slight_smile: Debian does have some tooling for the latter (git-debrebase) to do a bunch of the work for you, but it's quite Debian-specific and also not entirely straightforward!

1 Like
8

Thank you for your sage words. I should probably try the merging workflow on the next thing I have to fork temporary.

9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.