Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wstunnel package needs restricted bounds #265

Closed
rwlock404 opened this issue May 5, 2020 · 8 comments
Closed

wstunnel package needs restricted bounds #265

rwlock404 opened this issue May 5, 2020 · 8 comments

Comments

@rwlock404
Copy link

It was suggested to me to come here but I'm not sure if this the right place to report this. Apologies if not!

Please include the following information when filing Hackage package issues

How and when was the maintainer for the package requiring action contacted?

I couldn't find any contacting information... so never

If available, a link to the filed issue in the upstream issue tracker

There is no issue tracker

If not evident from 2., how to reproduce the issue (and if known, how to fix it)

I've recently switched to Ghcup and it's my understanding that cabal install wstunnel-0.3.0.0 should install the package. However, this is what I ended up with

Configuring library for wstunnel-0.3.0.0..
Preprocessing library for wstunnel-0.3.0.0..
Building library for wstunnel-0.3.0.0..
[1 of 7] Compiling Credentials      ( src/Credentials.hs, dist/build/Credentials.o )
[2 of 7] Compiling Logger           ( src/Logger.hs, dist/build/Logger.o )
[3 of 7] Compiling Socks5           ( src/Socks5.hs, dist/build/Socks5.o )
[4 of 7] Compiling Types            ( src/Types.hs, dist/build/Types.o )

src/Types.hs:17:49-62: error:
    Module ‘Network.Socket.Internal’ does not export ‘PortNumber(..)’
   |
17 | import           Network.Socket.Internal       (PortNumber(..))
   |                                                 ^^^^^^^^^^^^^^
cabal: Failed to build wstunnel-0.3.0.0 (which is required by exe:wstunnel
from wstunnel-0.3.0.0). See the build log above for details.

How critical is this, what's the impact of this breakage? E.g. how many dependent packages are affected by this? Which GHC versions are affected?

This is not critical to me.

@phadej
Copy link
Member

phadej commented May 5, 2020

Is there an upstream issue? We hope that maintainers (learn to) make revisions.

The both wstunnel versions are uploaded recently, so I hope that author will respond and knows better what the working configuration is.

@rwlock404
Copy link
Author

Is there an upstream issue? We hope that maintainers (learn to) make revisions.

I couldn't find the upstream. The package points to https://github.com/githubuser/wstunnel but the link gives a 404 not found error.

The both wstunnel versions are uploaded recently, so I hope that author will respond and knows better what the working configuration is.

Is there anything I can do?

@phadej
Copy link
Member

phadej commented May 5, 2020

https://github.com/erebe/wstunnel

@rwlock404
Copy link
Author

upstream bug: erebe/wstunnel#45

@rwlock404
Copy link
Author

the maintainer says he can't reupload the same version to add bounds :-(

@vaibhavsagar
Copy link
Member

It seems like erebe/wstunnel#45 is resolved, can this be closed?

@hvr
Copy link
Contributor

hvr commented May 12, 2020

@vaibhavsagar I don't consider the package in a good shape yet; it's mostly the metdata that's seriously lacking:

  • Majority of dependencies have no bounds
  • Useless Package synopsis
  • Useless Package description
  • Useless Copyright statement
  • Useless Maintainer address
  • Useless Homepage url
  • Useless Version Control url

And last but not least the author isn't aware of metadata revisions and believes you can't fix these things and can only upload new releases (which obviously don't fix the problem since the solver can still backtrack and access the previous releases). Unfortunately, this isn't a single incident; this has become a common theme (To give you a hint of the extent of the problem: 3 years ago I already compiled a list of over 500 packages which suffered from stack-template-prefilled boilerplate description fields) ever since inexperienced package maintainers started using Stack which simply doesn't promote proper Hackage behaviour by default... :-(

@gbaz
Copy link
Contributor

gbaz commented Jun 20, 2021

bearing in mind the above comment, I don't think that's stuff that's directly actionable in this repo, so optimistically (or pessimistically?) closing

@gbaz gbaz closed this as completed Jun 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants