[Bug 1045963] Review Request: ghc-gtk3 - Binding to the Gtk+ graphical user interface library
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1045963
--- Comment #13 from Jens Petersen <petersen(a)redhat.com> ---
Thanks for following up.
(In reply to Pranav Kant from comment #12)
> * Why the shared object file provided by the base package is unversioned. I
> think there is a bug related to this for all ghc packages, but I can't find
> it, right ?
Right this is currently how ghc names shared libraries.
The filenames are actually "versioned" - it is just that the version
comes before the .so extension.
I am happy to open a bug for that against ghc but I hope it need not
block this review: it is not something we can fix in this package anyway.
But note that ghc does not have the notion of major/minor libraries
versions - every version bumps needs rebuilds anyway.
> If there is nothing like that, we should probably version this, and move the
> unversioned one to the -devel package ?
I think it might be better to patch ghc to change how it names .so files:
need to think a bit more. Basically it is how ghc has named them
since it started supporting shared libraries many releases ago now.
> * Why there is no -debuginfo package ? I think the similar reason as above
> holds here also for ghc packages ?
ghc-7.10 should introduce support for dwarf debuginfo I think,
so I decided to wait with debuginfo until then -
I don't think it is useful currently with ghc-7.8.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1NIr6cYPTR&a=cc_unsubscribe
8 years, 9 months
[Bug 803812] New: FTBS: build failure on PPC64, `IO' is applied to too many type arguments'
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: FTBS: build failure on PPC64, `IO' is applied to too many type arguments'
https://bugzilla.redhat.com/show_bug.cgi?id=803812
Summary: FTBS: build failure on PPC64, `IO' is applied to too
many type arguments'
Product: Fedora
Version: 17
Platform: powerpc
OS/Version: Linux
Status: NEW
Severity: high
Priority: high
Component: ghc-gio
AssignedTo: petersen(a)redhat.com
ReportedBy: karsten(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, fedora-haskell-list(a)redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
[14 of 24] Compiling System.GIO.File.FileInfo (
dist/build/System/GIO/File/FileInfo.hs, dist/build/System/GIO/File/FileInfo.o )
System/GIO/File/FileInfo.chs:269:5:
`IO' is applied to too many type arguments
In the type signature for `fileInfoGetAttributeBool':
fileInfoGetAttributeBool :: FileInfoClass info =>
info -> String -> IO Bool bool
System/GIO/File/FileInfo.chs:278:5:
`IO' is applied to too many type arguments
In the type signature for `fileInfoGetAttributeWord32':
fileInfoGetAttributeWord32 :: FileInfoClass info =>
info -> String -> IO Word32 bool
System/GIO/File/FileInfo.chs:287:5:
`IO' is applied to too many type arguments
In the type signature for `fileInfoGetAttributeInt32':
fileInfoGetAttributeInt32 :: FileInfoClass info =>
info -> String -> IO Int32 bool
System/GIO/File/FileInfo.chs:296:5:
`IO' is applied to too many type arguments
In the type signature for `fileInfoGetAttributeWord64':
fileInfoGetAttributeWord64 :: FileInfoClass info =>
info -> String -> IO Word64 bool
System/GIO/File/FileInfo.chs:305:5:
`IO' is applied to too many type arguments
In the type signature for `fileInfoGetAttributeInt64':
fileInfoGetAttributeInt64 :: FileInfoClass info =>
info -> String -> IO Int64 bool
error: Bad exit status from /var/tmp/rpm-tmp.sEL96Y (%build)
Version-Release number of selected component (if applicable):
ghc-gio-0.12.2-1.fc17
How reproducible:
always
Steps to Reproduce:
1.ppc-koji build --scratch f17 ghc-gio-0.12.2-1.fc17.src.rpm
2.
3.
Actual results:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=439435
Expected results:
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
8 years, 9 months
[Bug 1246594] New: git-annex addurl --file ignores https url proto, fallsback to http silently
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1246594
Bug ID: 1246594
Summary: git-annex addurl --file ignores https url proto,
fallsback to http silently
Product: Fedora EPEL
Version: el6
Component: git-annex
Assignee: mathstuf(a)gmail.com
Reporter: jsherril(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: haskell-devel(a)lists.fedoraproject.org,
mathstuf(a)gmail.com, petersen(a)redhat.com
Description of problem:
when using:
git annex addurl --file somefile https://webserver.example.com/somefile
git annex does not use https, but fallsback to http without any sort of warning
or error.
Version-Release number of selected component (if applicable):
git-annex-3.20120522-2.1.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. in a git repo, download a file 'foo', and run 'git annex add foo'
2. commit this annexed file, push it to a remote
3. in a separate directory checkout the git repo
4. run git-annex addurl --file foo https://server/path/to/foo
Actual results:
git-annex will attempt to download the file over http. If port 80 is blocked,
git annex will error with connection refused. An strace shows it clearly trying
on port 80:
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("192.168.0.127")}, 16) = -1 EINPROGRESS (Operation now in
progress)
if you are monitoring your web server logs (when port 80 is allowed), you will
see it attempt to connect over port 80 and never over port 443.
Expected results:
connects over port 443 via https
Additional info:
oddly enough if you leave out --file foo it will attempt to use ssl.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CxmjULpKym&a=cc_unsubscribe
8 years, 10 months