January 2017 - Golang-updates - Fedora mailing-lists

[Bug 1401985] New: golang: net/http: multipart ReadForm close file after copy
by Red Hat Bugzilla 03 Aug '18

03 Aug '18

https://bugzilla.redhat.com/show_bug.cgi?id=1401985 Bug ID: 1401985 Summary: golang: net/http: multipart ReadForm close file after copy Product: Security Response Component: vulnerability Keywords: Security Severity: medium Priority: medium Assignee: security-response-team(a)redhat.com Reporter: amaris(a)redhat.com CC: admiller(a)redhat.com, amurdaca(a)redhat.com, aortega(a)redhat.com, apevec(a)redhat.com, ayoung(a)redhat.com, bleanhar(a)redhat.com, ccoleman(a)redhat.com, chrisw(a)redhat.com, cvsbot-xmlrpc(a)redhat.com, dedgar(a)redhat.com, dmcphers(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jcajka(a)redhat.com, jgoulding(a)redhat.com, jialiu(a)redhat.com, jkeck(a)redhat.com, joelsmith(a)redhat.com, jokerman(a)redhat.com, jschluet(a)redhat.com, kbasil(a)redhat.com, kseifried(a)redhat.com, lemenkov(a)gmail.com, lhh(a)redhat.com, lmeyer(a)redhat.com, lpeer(a)redhat.com, markmc(a)redhat.com, mmccomas(a)redhat.com, rbryant(a)redhat.com, renich(a)woralelandia.com, rhs-bugs(a)redhat.com, sclewis(a)redhat.com, sgirijan(a)redhat.com, sisharma(a)redhat.com, smohan(a)redhat.com, srevivo(a)redhat.com, ssaha(a)redhat.com, s(a)shk.io, storage-qa-internal(a)redhat.com, tdawson(a)redhat.com, tdecacqu(a)redhat.com, vbatts(a)redhat.com, vbellur(a)redhat.com The net/http package's Request.ParseMultipartForm method starts writing to temporary files once the request body size surpasses the given "maxMemory" limit. It was possible for an attacker to generate a multipart request crafted such that the server ran out of file descriptors. Upstream bug: https://github.com/golang/go/issues/17965 Upstream patch: https://go-review.googlesource.com/#/c/30410/ External Reference: https://groups.google.com/forum/#!msg/golang-dev/4NdLzS8sls8/uIz8QlnIBQAJ -- You are receiving this mail because: You are on the CC list for the bug.

2 17

[Bug 1401987] New: golang: net/http: multipart ReadForm close file after copy [fedora-all]
by Red Hat Bugzilla 01 Aug '18

01 Aug '18

https://bugzilla.redhat.com/show_bug.cgi?id=1401987 Bug ID: 1401987 Summary: golang: net/http: multipart ReadForm close file after copy [fedora-all] Product: Fedora Version: 25 Component: golang Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: vbatts(a)redhat.com Reporter: amaris(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, amurdaca(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jcajka(a)redhat.com, lemenkov(a)gmail.com, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Blocks: 1401985 This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1401985 [Bug 1401985] golang: net/http: multipart ReadForm close file after copy -- You are receiving this mail because: You are on the CC list for the bug.

2 11

[Bug 1401988] New: golang: net/http: multipart ReadForm close file after copy [epel-all]
by Red Hat Bugzilla 01 Aug '18

01 Aug '18

https://bugzilla.redhat.com/show_bug.cgi?id=1401988 Bug ID: 1401988 Summary: golang: net/http: multipart ReadForm close file after copy [epel-all] Product: Fedora EPEL Version: el6 Component: golang Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: admiller(a)redhat.com Reporter: amaris(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, amurdaca(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jcajka(a)redhat.com, s(a)shk.io Blocks: 1401985 This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora EPEL. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora EPEL. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1401985 [Bug 1401985] golang: net/http: multipart ReadForm close file after copy -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1416129] New: can't run iscsid in a docker container
by Red Hat Bugzilla 22 Jun '18

22 Jun '18

https://bugzilla.redhat.com/show_bug.cgi?id=1416129 Bug ID: 1416129 Summary: can't run iscsid in a docker container Product: Red Hat Enterprise Linux 7 Version: 7.3 Component: docker Keywords: Reopened Severity: medium Assignee: dwalsh(a)redhat.com Reporter: jhunsaker(a)redhat.com QA Contact: atomic-bugs(a)redhat.com CC: abeausol(a)redhat.com, admiller(a)redhat.com, amurdaca(a)redhat.com, berthiaume_wayne(a)emc.com, borgan(a)redhat.com, cleech(a)redhat.com, david.barnhill(a)emc.com, dwalsh(a)redhat.com, fsimonce(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jkeck(a)redhat.com, jsafrane(a)redhat.com, jslagle(a)redhat.com, lsm5(a)redhat.com, mattdm(a)redhat.com, mgoldman(a)redhat.com, pedro(a)aguatechnologies.com, rvykydal(a)redhat.com, s(a)shk.io, vaibhav.khanduja(a)emc.com, vbatts(a)redhat.com Depends On: 1100000 Blocks: 1102911 +++ This bug was initially created as a clone of Bug #1100000 +++ Description of problem: Can't start iscsid in a docker container Version-Release number of selected component (if applicable): # rpm -q docker-io docker-io-0.11.1-3.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. use the published fedora image, docker pull fedora 2. start the container, docker run -t -i fedora /bin/bash 3. install iscsi-initiator-utils 4. try to start iscsid: bash-4.2# iscsid -f iscsid: can not bind NETLINK_ISCSI socket strace also attached --- Additional comment from James Slagle on 2014-05-21 14:45:57 EDT --- To give a little more context into what I'm doing, I'm trying to run OpenStack nova compute configured to use the nova-baremetal driver inside a container. when nova-baremetal provisions a machine it acts as an iscsi initiator and logs into a target that has been created on the machine that is being provisioned. It then dd's the requested image onto the disk. therefore, aiui, iscsid must be running inside the container where you are also running iscsiadm. This same thing has also been tried in lxc, with what I expect is the same issue: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855 --- Additional comment from Daniel Walsh on 2014-05-28 12:29:35 EDT --- Was SELinux involved? If you put the machine into permissive mode does it work? Or try this as a privleged image. Might be something that we are doing to lock the system down. --- Additional comment from Daniel Walsh on 2014-05-28 12:33:18 EDT --- What are the permissions on /opt/hello ls -ld /opt ls -ld /opt/hello --- Additional comment from James Slagle on 2014-05-28 15:01:53 EDT --- SELinux is already in permissive mode on the Docker host. I did try in a privileged container, and I get something slightly different. iscsid -f just hangs forever on the command line. An strace shows (attached) it polling forever on a fd, i had to ctrl-c it in both cases. --- Additional comment from James Slagle on 2014-05-28 15:02:26 EDT --- --- Additional comment from James Slagle on 2014-05-28 15:03:16 EDT --- i think comment 3 was for another bug maybe? anyway, if not: bash-4.2# ls -ld /opt drwxr-xr-x. 2 root root 4096 Aug 7 2013 /opt bash-4.2# ls -ld /opt/hello ls: cannot access /opt/hello: No such file or directory --- Additional comment from James Slagle on 2014-05-28 15:08:58 EDT --- ah....actually, i suspect iscsid running forever in the foreground may indicate it *is* working. sorry, i wasn't thinking that -f was telling it to run in the foreground. i will see if i can actually connect to a target from the privileged container and report back --- Additional comment from James Slagle on 2014-05-29 09:34:32 EDT --- I'm using a privileged container running sshd as the process (so that I can login with a couple of different shells), I had to add this to my Dockerfile for the container, otherwise iscsid won't start: VOLUME ["/var/lock/iscsi"] i start the conatiner with: docker run --privileged -ti --name initiator -p 8022:22 -d iscsi-initiator then ssh in, and i start iscsid: iscsid -d 8 -f that appears to start fine then ssh in another session, and i can discover the target (target is actually on the container host): [root@bcf697cb8673 ~]# iscsiadm -m discovery -t st -p 192.168.122.1 192.168.122.1:3260,1 iqn.2013-07.com.example.storage.ssd1 but when i try to login to the target, iscsid exits (or crashes, hard to tell): [root@bcf697cb8673 ~]# iscsiadm -m node --targetname iqn.2013-07.com.example.storage.ssd1 --portal 192.168.122.1 --login Logging in to [iface: default, target: iqn.2013-07.com.example.storage.ssd1, portal: 192.168.122.1,3260] (multiple) iscsiadm: got read error (0/0), daemon died? iscsiadm: Could not login to [iface: default, target: iqn.2013-07.com.example.storage.ssd1, portal: 192.168.122.1,3260]. iscsiadm: initiator reported error (18 - could not communicate to iscsid) iscsiadm: Could not log into all portals from the ssh session where iscsid is running i see: iscsid: mgmt_ipc_write_rsp: rsp to fd 5 iscsid: poll result 1 iscsid: mgmt_ipc_write_rsp: rsp to fd 5 iscsid: poll result 1 iscsid: in read_transports iscsid: Adding new transport tcp iscsid: Matched transport tcp iscsid: sysfs_attr_get_value: open '/class/iscsi_transport/tcp'/'handle' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/class/iscsi_transport/tcp/handle' iscsid: sysfs_attr_get_value: add to cache '/sys/class/iscsi_transport/tcp/handle' iscsid: sysfs_attr_get_value: cache '/sys/class/iscsi_transport/tcp/handle' with attribute value '18446744072107593760' iscsid: sysfs_attr_get_value: open '/class/iscsi_transport/tcp'/'caps' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/class/iscsi_transport/tcp/caps' iscsid: sysfs_attr_get_value: add to cache '/sys/class/iscsi_transport/tcp/caps' iscsid: sysfs_attr_get_value: cache '/sys/class/iscsi_transport/tcp/caps' with attribute value '0x39' iscsid: Allocted session 0x7f38ceb4f9b0 iscsid: no authentication configured... iscsid: resolved 192.168.122.1 to 192.168.122.1 iscsid: setting iface default, dev , set ip , hw , transport tcp. iscsid: get ev context 0x7f38ceb5c470 iscsid: set TCP recv window size to 524288, actually got 425984 iscsid: set TCP send window size to 524288, actually got 425984 iscsid: connecting to 192.168.122.1:3260 iscsid: sched conn context 0x7f38ceb5c470 event 2, tmo 0 iscsid: thread 0x7f38ceb5c470 schedule: delay 0 state 3 iscsid: Setting login timer 0x7f38ceb578e0 timeout 15 iscsid: thread 0x7f38ceb578e0 schedule: delay 60 state 3 iscsid: exec thread 7f38ceb5c470 callback iscsid: put ev context 0x7f38ceb5c470 iscsid: connected local port 37259 to 192.168.122.1:3260 iscsid: in kcreate_session iscsid: in __kipc_call iscsid: in kwritev iscsid: sendmsg: bug? ctrl_fd 4 Maybe the lines with sysfs_attr_get_value are indicative of something that's needed from /sys still? These exact same discovery and login commands work fine running from a libvirt vm connecting to the same target. On my container host, i do have the correct iscsi kernel modules, and I also see these in the container: on the host: [root@teletran-1 docker]# lsmod | grep iscsi iscsi_tcp 18333 0 libiscsi_tcp 24176 1 iscsi_tcp libiscsi 54750 2 libiscsi_tcp,iscsi_tcp scsi_transport_iscsi 97405 4 iscsi_tcp,libiscsi on the container: [root@bcf697cb8673 ~]# lsmod | grep iscsi iscsi_tcp 18333 0 libiscsi_tcp 24176 1 iscsi_tcp libiscsi 54750 2 libiscsi_tcp,iscsi_tcp scsi_transport_iscsi 97405 4 iscsi_tcp,libiscsi i'll attach an strace of the iscsid process that's exiting, if that helps. i can also attach an strace of an iscsid process that shows it working from a libvirt VM, if you think that would be helpful to compare. --- Additional comment from James Slagle on 2014-05-29 09:37:12 EDT --- strace of iscsid generated with: strace -f -o iscsid.strace iscsid -d 12 -f the iscsid process exits when you try to login to an iscsi target from the container. --- Additional comment from James Slagle on 2014-05-29 10:08:33 EDT --- note that the output i'm now seeing seems to match very closely what was reported in https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855 when this same thing was tried with lxc-tools instead of Docker. --- Additional comment from Daniel Walsh on 2014-05-29 15:32:31 EDT --- So this looks to be more specific to iscsid and namespacing then to docker. I think you should open the bug with them and see if they can help. --- Additional comment from Chris Leech on 2014-06-04 19:44:37 EDT --- It looks like the iSCSI netlink control interface isn't namespace aware, and the kernel side of the iSCSI initiator rejects messages that don't come from the default network namespace. I suppose it might make sense to track active sessions per netns. --- Additional comment from James Slagle on 2014-06-05 07:51:06 EDT --- --- Additional comment from Radek Vykydal on 2015-03-30 08:50:41 EDT --- FYI I was playing with running iscsid in superprivileged container: https://github.com/rvykydal/dockerfile-iscsid/tree/master/rhel7 --- Additional comment from Chris Leech on 2015-04-23 13:30:38 EDT --- I've spent some more time looking at running iscsid in a network namespace container, and there are a number of kernel issues that need to be worked out. The kernel side of the iSCSI netlink family only listens in the initial network namespace (just like some other storage related netlink families). It's easy enough to add per-namespace kernel sockets, a bit more work to associate network namespaces to iSCSI objects in order to route async event notifications to the right place. iSCSI makes heavy use of sysfs as well, and many of the iSCSI sysfs devices will need network namespace tags for filtered views of sysfs. I think that makes sense for iscsi_host, iscsi_session, and iscsi_connection. Certainly not for iscsi_transport. Possibly for iscsi_endpoint and iscsi_iface. Without growing some way to assign an iscsi_host to a net namespace like is done for network devices, this will probably work for dynamically generated hosts (iscsi_tcp) but not for offload hardware. I can imagine use cases where it might be nice to have multiple iscsid instances in their own containers managing their own set of iSCSI sessions. I've got some work started, but it's not ready for review and testing just yet. Without that, I don't see how we can get to multiple working iscsid processes or even a single iscsid running without --net=host --- Additional comment from Fedora End Of Life on 2015-05-29 07:55:11 EDT --- This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Vaibhav Khanduja on 2015-07-09 16:29:41 EDT --- (In reply to Chris Leech from comment #15) > I've spent some more time looking at running iscsid in a network namespace > container, and there are a number of kernel issues that need to be worked > out. > > The kernel side of the iSCSI netlink family only listens in the initial > network namespace (just like some other storage related netlink families). > It's easy enough to add per-namespace kernel sockets, a bit more work to > associate network namespaces to iSCSI objects in order to route async event > notifications to the right place. > > iSCSI makes heavy use of sysfs as well, and many of the iSCSI sysfs devices > will need network namespace tags for filtered views of sysfs. I think that > makes sense for iscsi_host, iscsi_session, and iscsi_connection. Certainly > not for iscsi_transport. Possibly for iscsi_endpoint and iscsi_iface. > > Without growing some way to assign an iscsi_host to a net namespace like is > done for network devices, this will probably work for dynamically generated > hosts (iscsi_tcp) but not for offload hardware. > > I can imagine use cases where it might be nice to have multiple iscsid > instances in their own containers managing their own set of iSCSI sessions. > > I've got some work started, but it's not ready for review and testing just > yet. > > Without that, I don't see how we can get to multiple working iscsid > processes or even a single iscsid running without --net=host do you have working patch? I wanted to test this out to check the working? --- Additional comment from Chris Leech on 2015-07-13 14:09:21 EDT --- (In reply to Vaibhav Khanduja from comment #17) > do you have working patch? I wanted to test this out to check the working? In progress patches sent via email. --- Additional comment from paguayo on 2016-04-11 14:39:46 EDT --- (In reply to Chris Leech from comment #18) > (In reply to Vaibhav Khanduja from comment #17) > > do you have working patch? I wanted to test this out to check the working? > > In progress patches sent via email. Any progress on this patch? --- Additional comment from Fedora End Of Life on 2016-07-19 07:32:46 EDT --- Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. --- Additional comment from Daniel Walsh on 2016-07-19 10:18:03 EDT --- Is this something we should continue to care about? --- Additional comment from Jan Kurik on 2016-07-26 00:08:27 EDT --- This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1100000 [Bug 1100000] can't run iscsid in a docker container https://bugzilla.redhat.com/show_bug.cgi?id=1102911 [Bug 1102911] can't run iscsid in a docker container -- You are receiving this mail because: You are on the CC list for the bug.

2 22

[Bug 1367740] New: golang-github-go-fsnotify-fsnotify FTBFS due to failing tests on aarch64 d
by Red Hat Bugzilla 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1367740 Bug ID: 1367740 Summary: golang-github-go-fsnotify-fsnotify FTBFS due to failing tests on aarch64 d Product: Fedora Version: 25 Component: golang-github-go-fsnotify-fsnotify Assignee: fpokorny(a)redhat.com Reporter: pbrobinson(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: fpokorny(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jchaloup(a)redhat.com Blocks: 922257 (ARM64,F-ExcludeArch-aarch64) http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3677865 golang-github-go-fsnotify-fsnotify-1.2.0-0.4.git96c060f.fc25 Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.1pPWD0 + umask 022 + cd /builddir/build/BUILD + cd fsnotify-96c060f6a6b7e0d6f75fddd10efeaca3e5d1bcb0 + export GOPATH=/builddir/build/BUILDROOT/golang-github-go-fsnotify-fsnotify-1.2.0-0.4.git96c060f.fc25.aarch64//usr/share/gocode:/usr/share/gocode + GOPATH=/builddir/build/BUILDROOT/golang-github-go-fsnotify-fsnotify-1.2.0-0.4.git96c060f.fc25.aarch64//usr/share/gocode:/usr/share/gocode + go test -compiler gc -ldflags '' github.com/go-fsnotify/fsnotify --- FAIL: TestPollerWithBadFd (0.14s) inotify_poller_test.go:70: Expected EBADF, got: function not implemented --- FAIL: TestPollerWithData (0.14s) inotify_poller_test.go:62: Failed to create poller: function not implemented --- FAIL: TestPollerWithWakeup (0.14s) inotify_poller_test.go:62: Failed to create poller: function not implemented --- FAIL: TestPollerWithClose (0.14s) inotify_poller_test.go:62: Failed to create poller: function not implemented --- FAIL: TestPollerWithWakeupAndData (0.14s) inotify_poller_test.go:62: Failed to create poller: function not implemented --- FAIL: TestPollerConcurrent (0.14s) inotify_poller_test.go:62: Failed to create poller: function not implemented --- FAIL: TestInotifyCloseRightAway (0.14s) inotify_test.go:20: Failed to create watcher --- FAIL: TestInotifyCloseSlightlyLater (0.14s) inotify_test.go:34: Failed to create watcher --- FAIL: TestInotifyCloseSlightlyLaterWithWatch (0.14s) inotify_test.go:52: Failed to create watcher --- FAIL: TestInotifyCloseAfterRead (0.14s) inotify_test.go:71: Failed to create watcher --- FAIL: TestInotifyCloseCreate (0.00s) inotify_test.go:117: Failed to create watcher: function not implemented --- FAIL: TestInotifyStress (0.00s) inotify_test.go:162: Failed to create watcher: function not implemented --- FAIL: TestInotifyRemoveTwice (0.00s) inotify_test.go:269: Failed to create watcher: function not implemented --- FAIL: TestFsnotifyMultipleOperations (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyMultipleCreates (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyDirOnly (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyDeleteWatchedDir (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifySubDir (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyRename (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyRenameToCreate (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyRenameToOverwrite (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestRemovalOfWatch (0.09s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyAttrib (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyClose (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestFsnotifyFakeSymlink (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented --- FAIL: TestClose (0.00s) integration_test.go:50: NewWatcher() failed: function not implemented FAIL FAIL github.com/go-fsnotify/fsnotify 1.466s RPM build errors: Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=922257 [Bug 922257] Tracker for ARM64 support -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 1378972] New: golang fails openshift origin 1.3.0 build for armv7hl
by Red Hat Bugzilla 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1378972 Bug ID: 1378972 Summary: golang fails openshift origin 1.3.0 build for armv7hl Product: Fedora Version: rawhide Component: golang Assignee: vbatts(a)redhat.com Reporter: admiller(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, amurdaca(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jcajka(a)redhat.com, lemenkov(a)gmail.com, renich(a)woralelandia.com, s(a)shk.io, vbatts(a)redhat.com Description of problem: Mock Version: 1.2.21 Mock Version: 1.2.21 ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target armv7hl --nodeps /builddir/build/SPECS/origin.spec'], gid=425timeout=172800env={'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'LANG': 'en_US.UTF-8', 'PS1': '<mock-chroot> \\s-\\v\\$ '}uid=1000chrootPath='/var/lib/mock/f26-build-6492446-642185/root'logger=<mockbuild.trace_decorator.getLog object at 0xb5e6ffd0>printOutput=Falseuser='mockbuild'shell=False) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target armv7hl --nodeps /builddir/build/SPECS/origin.spec'] with env {'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'LANG': 'en_US.UTF-8', 'PS1': '<mock-chroot> \\s-\\v\\$ '} and shell False warning: Could not canonicalize hostname: arm02-builder15.arm.fedoraproject.org Building target platforms: armv7hl Building for target armv7hl Wrote: /builddir/build/SRPMS/origin-1.3.0-2.fc26.src.rpm Child return code was: 0 ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target armv7hl --nodeps /builddir/build/SPECS/origin.spec'], gid=425timeout=172800uid=1000shell=Falseprivate_network=TruechrootPath='/var/lib/mock/f26-build-6492446-642185/root'logger=<mockbuild.trace_decorator.getLog object at 0xb5e6ffd0>printOutput=Falseenv={'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'LANG': 'en_US.UTF-8', 'PS1': '<mock-chroot> \\s-\\v\\$ '}user='mockbuild') Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target armv7hl --nodeps /builddir/build/SPECS/origin.spec'] with env {'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'LANG': 'en_US.UTF-8', 'PS1': '<mock-chroot> \\s-\\v\\$ '} and shell False Building target platforms: armv7hl Building for target armv7hl Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.ORHkve + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf origin-d45151824821195c9d3db7e5d2da0a1c982a614c + /usr/bin/gzip -dc /builddir/build/SOURCES/origin-1.3.0.tar.gz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd origin-d45151824821195c9d3db7e5d2da0a1c982a614c + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #0 (origin-1.3.0-build-platform.patch):' Patch #0 (origin-1.3.0-build-platform.patch): + /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0 patching file Makefile patching file hack/build-platform.sh patching file origin.spec + chmod +x hack/build-platform.sh + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.knwheP + umask 022 + cd /builddir/build/BUILD + cd origin-d45151824821195c9d3db7e5d2da0a1c982a614c + OS_GIT_TREE_STATE=clean + OS_GIT_VERSION=v1.3.0 + OS_GIT_COMMIT=d451518 + OS_GIT_MAJOR=1 + OS_GIT_MINOR=3 + hack/build-platform.sh ++ Building go targets for linux/arm: cmd/openshift cmd/oc ++ Building go targets for linux/arm: images/pod cmd/dockerregistry cmd/gitserver examples/hello-openshift examples/deployment ++ Placing binaries ++ ERROR: No release type defined for linux/arm ++ Placing binaries ++ ERROR: No release type defined for linux/arm hack/build-platform.sh took 934 seconds + OS_GIT_TREE_STATE=clean + OS_GIT_VERSION=v1.3.0 + OS_GIT_COMMIT=d451518 + OS_GIT_MAJOR=1 + OS_GIT_MINOR=3 + hack/build-go.sh test/extended/extended.test ++ Building go targets for linux/arm: test/extended/extended.test ++ Placing binaries hack/build-go.sh took 515 seconds + OS_GIT_TREE_STATE=clean + OS_GIT_VERSION=v1.3.0 + OS_GIT_COMMIT=d451518 + OS_GIT_MAJOR=1 + OS_GIT_MINOR=3 + hack/update-generated-docs.sh ++ Building go targets for linux/arm: tools/gendocs tools/genman ++ Placing binaries /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/hack/build-go.sh took 626 seconds Assets generated in /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c//docs/generated panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x7ab4c] goroutine 1 [running]: panic(0x297b3a0, 0x15928008) /usr/lib/golang/src/runtime/panic.go:500 +0x33c encoding/gob.newTypeObject(0x25f3a18, 0x8, 0x1599f7c0, 0x456f8c0, 0x2ba8918, 0x2ba8918, 0x456f8c0, 0x2ba8918, 0x246a0f4) /usr/lib/golang/src/encoding/gob/type.go:448 +0x24 encoding/gob.getType(0x25f3a18, 0x8, 0x1599f7c0, 0x456f8c0, 0x2ba8918, 0x0, 0x0, 0x0, 0x0) /usr/lib/golang/src/encoding/gob/type.go:608 +0xc0 encoding/gob.getBaseType(0x25f3a18, 0x8, 0x456f8c0, 0x2ba8918, 0x0, 0x0, 0x0, 0x0) /usr/lib/golang/src/encoding/gob/type.go:595 +0x78 encoding/gob.buildTypeInfo(0x1599f7c0, 0x456f8c0, 0x2ba8918, 0x0, 0x0, 0x0) /usr/lib/golang/src/encoding/gob/type.go:725 +0xe8 encoding/gob.getTypeInfo(0x1599f7c0, 0x2ba8918, 0x0, 0x0) /usr/lib/golang/src/encoding/gob/type.go:712 +0xa4 encoding/gob.mustGetTypeInfo(0x456f8c0, 0x2ba8918, 0x456f8c0) /usr/lib/golang/src/encoding/gob/type.go:776 +0x34 encoding/gob.init() /usr/lib/golang/src/encoding/gob/type.go:269 +0x1be0 net/rpc.init() /usr/lib/golang/src/net/rpc/server.go:713 +0x50 github.com/openshift/origin/vendor/github.com/ugorji/go/codec.init() /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/vendor/github.com/ugorji/go/codec/time.go:234 +0x9c github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/runtime/serializer… /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/runtime/serializer/json/meta.go:62 +0x58 github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/runtime/serializer… /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/runtime/serializer/protobuf_extension.go:53 +0x54 github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/api.init() /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/api/types.go:3076 +0xa4 github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/kubectl/cmd.init() /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/pkg/kubectl/cmd/version.go:56 +0x6c github.com/openshift/origin/pkg/cmd/admin.init() /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/pkg/cmd/admin/oadm_bashcomp_func.go:17 +0x58 main.init() /builddir/build/BUILD/origin-d45151824821195c9d3db7e5d2da0a1c982a614c/_output/local/go/src/github.com/openshift/origin/tools/genman/gen_man.go:198 +0x60 [ERROR] PID 896: hack/common.sh:910: `${cmd} "${tmpdir}" "${cmdName}"` exited with status 2. [INFO] Stack Trace: [INFO] 1: hack/common.sh:910: `${cmd} "${tmpdir}" "${cmdName}"` [INFO] 2: hack/update-generated-docs.sh:41: os::build::gen-man [INFO] Exiting with code 2. error: Bad exit status from /var/tmp/rpm-tmp.knwheP (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.knwheP (%build) Child return code was: 1 EXCEPTION: [Error()] Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 88, in trace result = func(*args, **kw) File "/usr/lib/python3.5/site-packages/mockbuild/util.py", line 562, in do raise exception.Error("Command failed. See logs for output.\n # %s" % (command,), child.returncode) mockbuild.exception.Error: Command failed. See logs for output. # bash --login -c /usr/bin/rpmbuild -bb --target armv7hl --nodeps /builddir/build/SPECS/origin.spec Version-Release number of selected component (if applicable): golang.armv7hl 1.7.1-1.fc26 How reproducible: Always Steps to Reproduce: 1. Rebuild this package in koji or mock for armv7hl https://maxamillion.fedorapeople.org/origin-1.3.0-2.fc24.src.rpm 2. Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=15770239 -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1413669] New: README.md included in all subpackages
by Red Hat Bugzilla 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1413669 Bug ID: 1413669 Summary: README.md included in all subpackages Product: Fedora Version: rawhide Component: gofed Assignee: jchaloup(a)redhat.com Reporter: fkluknav(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fale(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jchaloup(a)redhat.com Description of problem: spec file generated by gofed contains "%doc README.md" in all subpackages. Fedora packaging guidelines state that: MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations) If I understand it correctly, this is in conflict. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1416829] New: golang-googlecode-google-api-client: update to a recent version
by Red Hat Bugzilla 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1416829 Bug ID: 1416829 Summary: golang-googlecode-google-api-client: update to a recent version Product: Fedora Version: rawhide Component: golang-googlecode-google-api-client Assignee: fpokorny(a)redhat.com Reporter: fkluknav(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: eparis(a)redhat.com, fpokorny(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jchaloup(a)redhat.com, lsm5(a)redhat.com, vbatts(a)redhat.com Description of problem: Upstream git repo contains code which is not present in Fedora yet. Updating will allow to unbundle 'golang(google.golang.org/api/iterator)' and 'golang(google.golang.org/api/option)' Version-Release number of selected component (if applicable): 0-0.16.gite6294e6 -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1360748] New: update for s390x support
by Red Hat Bugzilla 27 May '18

27 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1360748 Bug ID: 1360748 Summary: update for s390x support Product: Fedora Version: rawhide Component: golang-github-golang-sys Assignee: fpokorny(a)redhat.com Reporter: dan(a)danny.cz QA Contact: extras-qa(a)fedoraproject.org CC: fpokorny(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jchaloup(a)redhat.com Blocks: 467765 (ZedoraTracker) Please update to a recent snapshot to gather s390x support - https://github.com/golang/sys/commit/33267e036fd93fcd26ea95b7bdaf2d8306cb74… Version-Release number of selected component (if applicable): golang-github-golang-sys-0-0.4.git9c60d1c.fc25 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=467765 [Bug 467765] Fedora for System z (s390): Bug Tracker -- You are receiving this mail because: You are on the CC list for the bug.

2 62

[Bug 1365467] New: Tracker for golang-github-Azure-azure-sdk-for-go
by Red Hat Bugzilla 26 Apr '18

26 Apr '18

https://bugzilla.redhat.com/show_bug.cgi?id=1365467 Bug ID: 1365467 Summary: Tracker for golang-github-Azure-azure-sdk-for-go Product: Fedora Version: rawhide Component: golang-github-Azure-azure-sdk-for-go Assignee: fpokorny(a)redhat.com Reporter: jchaloup(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fpokorny(a)redhat.com, golang-updates(a)lists.fedoraproject.org, jchaloup(a)redhat.com Tracker for async updates of golang-github-Azure-azure-sdk-for-go for rawhide and other fedora distribution. As golang devel packages are used only as a build-time dependency at the moment, this tracker keeps updates and other information about this package, e.g. broken dependencies, exceptions, important pieces of information and other issues. -- You are receiving this mail because: You are on the CC list for the bug.

2 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

Golang-updates January 2017