Re: Resources for upstream testing?
On Thu, Sep 3, 2015 at 9:45 AM, Dave Love <d.l...@liverpool.ac.uk> wrote: > Dave Johansen <davejohan...@gmail.com> writes: > > >> We do have docker images that can be used [0] - but we currently don't > >> have a user friendly way to find them. You currently have to look > >> through koji to find them [1]. > >> > >> Hope this helps! > >> > >> [0] > >> > >> > https://kojipkgs.fedoraproject.org//work/tasks/7896/10927896/Fedora-Docker-Base-rawhide-20150902.x86_64.tar.xz > >> [1] > >> > >> > http://koji.fedoraproject.org/koji/tasks?start=0=all=tree=image=-id > >> > > > > Can these be used in a manner similar to mock for building/testing > packages > > (i.e. install packages, do builds, run tests, etc)? If so, are there any > > instructions on how to get an instance setup and start using it? > > > > Thanks, > > Dave > > For what it's worth, you can use vagrant with the > kaorimatz/fedora-rawhide-x86_64 box. A search on the hashicorp atlas > finds it. > Are there any instructions on how to use this for testing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Recommendations for bisecting a test failure?
I'm working on packaging hgsubversion ( https://bugzilla.redhat.com/show_bug.cgi?id=1221459 ) and I've run into some test failures on F23/Rawhide that seem to be caused by the update to subversion 1.9.0. Upstream has recommended that I try and bisect the source of the failure ( https://groups.google.com/d/msg/hgsubversion/q47xvqDDmS0/2nW2Q6PoAwAJ ). Any recommendations on setting up an automated way to do that in Fedora? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
No autocomplete for new package in bodhi 2.0?
I just finished the review for cppformat ( https://bugzilla.redhat.com/show_bug.cgi?id=1216279 ) and went to submit the updates. I noticed that bodhi 2.0 won't autocomplete the names of updates. I believe that would happen before the update to 2.0. Is this a known issue? I didn't find it when looking through the list at https://github.com/fedora-infra/bodhi/issues Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Resources for upstream testing?
On Wed, Sep 2, 2015 at 1:29 PM, Kevin Fenzi <ke...@scrye.com> wrote: > On Tue, 1 Sep 2015 22:52:42 -0700 > Dave Johansen <davejohan...@gmail.com> wrote: > > > I'm working on packaging hgsubversion ( > > https://bugzilla.redhat.com/show_bug.cgi?id=1221459 ) and I've run > > into an issue where some of the tests pass on F22 and F23 but fail on > > Rawhide. I've done some simple debugging, but it would be much easier > > if upstream could do some testing on their own ( > > https://groups.google.com/d/msg/hgsubversion/q47xvqDDmS0/Mk29v2voFAAJ > > ). Are there any machines or docker images that upstream could use to > > debug the issue without having to create a Fedora account, install > > Fedora or jump through any hoops like that? > > I don't know of anything like that for upstreams. Possibly someday we > could do that with beaker. > > For maintainers we have: > > > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > I've used those test machines when playing around with ARM and other issues. It would be nice if there was a way to setup guest access or something along those lines for upstream to be able to help in debugging issues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Resources for upstream testing?
On Wed, Sep 2, 2015 at 2:17 PM, Mike Ruckman <ro...@fedoraproject.org> wrote: > On Tue, Sep 01, 2015 at 10:52:42PM -0700, Dave Johansen wrote: > > I'm working on packaging hgsubversion ( > > https://bugzilla.redhat.com/show_bug.cgi?id=1221459 ) and I've run into > an > > issue where some of the tests pass on F22 and F23 but fail on Rawhide. > I've > > done some simple debugging, but it would be much easier if upstream could > > do some testing on their own ( > > https://groups.google.com/d/msg/hgsubversion/q47xvqDDmS0/Mk29v2voFAAJ ). > > Are there any machines or docker images that upstream could use to debug > > the issue without having to create a Fedora account, install Fedora or > jump > > through any hoops like that? > > Thanks, > > Dave > > Dave, > > We do have docker images that can be used [0] - but we currently don't > have a user friendly way to find them. You currently have to look > through koji to find them [1]. > > Hope this helps! > > [0] > > https://kojipkgs.fedoraproject.org//work/tasks/7896/10927896/Fedora-Docker-Base-rawhide-20150902.x86_64.tar.xz > [1] > > http://koji.fedoraproject.org/koji/tasks?start=0=all=tree=image=-id > Can these be used in a manner similar to mock for building/testing packages (i.e. install packages, do builds, run tests, etc)? If so, are there any instructions on how to get an instance setup and start using it? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Resources for upstream testing?
I'm working on packaging hgsubversion ( https://bugzilla.redhat.com/show_bug.cgi?id=1221459 ) and I've run into an issue where some of the tests pass on F22 and F23 but fail on Rawhide. I've done some simple debugging, but it would be much easier if upstream could do some testing on their own ( https://groups.google.com/d/msg/hgsubversion/q47xvqDDmS0/Mk29v2voFAAJ ). Are there any machines or docker images that upstream could use to debug the issue without having to create a Fedora account, install Fedora or jump through any hoops like that? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Correct way to handle a single failed build on COPR?
On Mon, Jul 13, 2015 at 11:38 PM, Dan Horák d...@danny.cz wrote: On Mon, 13 Jul 2015 22:05:01 -0700 Dave Johansen davejohan...@gmail.com wrote: https://copr.fedoraproject.org/coprs/daveisfera/odb_2.4/build/102224/ What's the correct way to handle a single failed build on COPR? In the above, it failed on F22 ppc64le. Will clicking resubmit rebuild on all of the platforms? Or just the one that failed? in this case it looks like a gcc (packaging?) bug, so a resubmit shouldn't help. And I think Fedora bugzilla is a correct place to report such bug. I open a bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=1256839 ). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packaged fonts? (and regular audits?)
During the review of cppformat, it was pointed out that it contained a font that should be removed because it's packaged with Fedora ( https://bugzilla.redhat.com/show_bug.cgi?id=1216279#c3 ). While working on resolving this, I was looking into what package provided this font so I could add the appropriate Requires to get the font and noticed that quite a few packages also include this font: yum provides */glyphicons-halflings-regular.ttf Is this ok? And if not, then is there some way that a set of fedora-review style audits could be run on existing packages to verify that these sorts of things didn't accidentally slip through the original review or were introduced in an update without being noticed? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Correct way to handle a single failed build on COPR?
https://copr.fedoraproject.org/coprs/daveisfera/odb_2.4/build/102224/ What's the correct way to handle a single failed build on COPR? In the above, it failed on F22 ppc64le. Will clicking resubmit rebuild on all of the platforms? Or just the one that failed? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review Swap?
I have two reviews that have been waiting for a reviewer for a while. I would be willing to do a review swap but I would probably have a slow turn around on my end (I'm currently on vacation and only occasionally get time to do this sort of thing). So if you're willing to swap or do the review, then please let me know. cppformat: https://bugzilla.redhat.com/show_bug.cgi?id=1216279 hgsubversion: https://bugzilla.redhat.com/show_bug.cgi?id=1221459 Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: qmake needed by fedora-review?
On Wed, Jul 8, 2015 at 12:23 PM, Tom Hughes t...@compton.nu wrote: On 08/07/15 20:02, Dave Johansen wrote: I'm trying to run fedora-review. Do I have something setup incorrectly? Or am I doing something wrong? It keeps running into issue with not finding qmake, but isn't everything supossed to be done in mock? The build is done in mock, but that spec is using qmake in macro definitions in the spec file and fedora-review is presumably examining the spec locally before invoking mock. I had just noticed the same thing when manually building the source .rpm manually. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Swap?
On Wed, Jul 8, 2015 at 10:15 AM, Antonio Trande anto.tra...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/08/2015 07:08 PM, Dave Johansen wrote: I have two reviews that have been waiting for a reviewer for a while. I would be willing to do a review swap but I would probably have a slow turn around on my end (I'm currently on vacation and only occasionally get time to do this sort of thing). So if you're willing to swap or do the review, then please let me know. cppformat: https://bugzilla.redhat.com/show_bug.cgi?id=1216279 hgsubversion: https://bugzilla.redhat.com/show_bug.cgi?id=1221459 Thanks, Dave I'm willing to review both your packages. https://bugzilla.redhat.com/show_bug.cgi?id=1231427 It looks like these two lines are unused and are causing problems because qmake isn't available when they're run: %global qtinc %(qmake -query QT_INSTALL_PREFIX)/include %global qtlib %(qmake -query QT_INSTALL_PREFIX)/lib -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: qmake needed by fedora-review?
On Wed, Jul 8, 2015 at 12:02 PM, Dave Johansen davejohan...@gmail.com wrote: I'm trying to run fedora-review. Do I have something setup incorrectly? Or am I doing something wrong? It keeps running into issue with not finding qmake, but isn't everything supossed to be done in mock? Sorry for the noise. It looks like this was being caused by an issue in the .spec file being reviewed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Error running python in mock?
On Wed, Jul 8, 2015 at 5:49 PM, Dave Johansen davejohan...@gmail.com
wrote:
I can bulid a package on my machine (F21 32-bit), but when I try and build
it with mock, I get an error when trying to run python. Here's the output:
RPM build errors:
+ cd durin42-hgsubversion-dde1ade36a49
+ '%{__python2}' setup.py build
/var/tmp/rpm-tmp.N6A81W: line 31: fg: no job control
Stupid user error on my part. I had forgotten to upload .spec with the BR
for python and so the Review Request still didn't work.
Sorry again for the noise,
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Error running python in mock?
I can bulid a package on my machine (F21 32-bit), but when I try and build
it with mock, I get an error when trying to run python. Here's the output:
RPM build errors:
+ cd durin42-hgsubversion-dde1ade36a49
+ '%{__python2}' setup.py build
/var/tmp/rpm-tmp.N6A81W: line 31: fg: no job control
Any ideas on why the issue is?
Thanks,
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
qmake needed by fedora-review?
I'm trying to run fedora-review. Do I have something setup incorrectly? Or
am I doing something wrong? It keeps running into issue with not finding
qmake, but isn't everything supossed to be done in mock?
Here's the output from the process:
[dlj@JohansenDev ~]$ fedora-review -b 1231427
INFO: Processing bugzilla bug: 1231427
INFO: Getting .spec and .srpm Urls from : 1231427
INFO: -- SRPM url:
https://sagitter.fedorapeople.org/COPASI/COPASI-4.16.101-4.20150707git192df4.fc22.src.rpm
INFO: -- Spec url: https://sagitter.fedorapeople.org/COPASI/COPASI.spec
INFO: Using review directory: /home/dlj/1231427-COPASI
INFO: Downloading .spec and .srpm files
sh: qmake: command not found
sh: qmake: command not found
sh: qmake: command not found
sh: qmake: command not found
INFO: Downloading (Source0):
https://github.com/copasi/COPASI/archive/192df43f09810b4416c7c59bec08ed63a2c22186.zip#/COPASI-192df43f09810b4416c7c59bec08ed63a2c22186.zip
INFO: Running checks and generating report
ERROR:
Exception(/home/dlj/1231427-COPASI/srpm/COPASI-4.16.101-4.20150707git192df4.fc22.src.rpm)
Config(fedora-21-i386) 0 minutes 15 seconds
INFO: Results and/or logs in: /home/dlj/1231427-COPASI/results
ERROR: Command failed:
INFO: WARNING: Probably non-rawhide buildroot used. Rawhide should be used
for most package reviews
And here's the output in build.log:
Mock Version: 1.2.10
Mock Version: 1.2.10
Mock Version: 1.2.10
ENTER do(['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target i686
--nodeps /builddir/build/SPECS/COPASI.spec'],
chrootPath='/var/lib/mock/fedora-21-i386/root'shell=FalseprintOutput=Falseenv={'LANG':
'en_US.utf8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock',
'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
\x1b]0;mock-chroot\x07mock-chroot', 'HOME': '/builddir',
'CCACHE_DIR': '/tmp/ccache', 'CCACHE_UMASK':
'002'}gid=135user='mockbuild'timeout=0logger=mockbuild.trace_decorator.getLog
object at 0xb697426cuid=1000)
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs
--target i686 --nodeps /builddir/build/SPECS/COPASI.spec'] with env
{'LANG': 'en_US.utf8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
\x1b]0;mock-chroot\x07mock-chroot', 'HOME': '/builddir',
'CCACHE_DIR': '/tmp/ccache', 'CCACHE_UMASK': '002'} and shell False
sh: qmake: command not found
sh: qmake: command not found
warning: Could not canonicalize hostname: JohansenDev
Building target platforms: i686
Building for target i686
Wrote:
/builddir/build/SRPMS/COPASI-4.16.101-4.20150707git192df4.fc21.src.rpm
Child return code was: 0
LEAVE do --
Mock Version: 1.2.10
Any advice? Thanks,
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best practice for latest package in COPR?
On Jun 28, 2015 11:39 PM, Miroslav Suchý msu...@redhat.com wrote: Dne 29.6.2015 v 06:13 Dave Johansen napsal(a): I would like to start providing the latest version of ODB in a COPR for stable releases of Fedora and RHEL. Is there a best practice for this sort of thing? The main question I have is: Is it better to use a single repo and continue to update it with the latest release? Or is it better to have a repo for version 2.4 and then a separate one for when 2.5 comes out? It'is really up to you. It depends what you want to support. It can be that you have project with latest stable version for all platforms (Fedora and Epel) so you provide 2.4 version where in distribution is just 2.4. And then another project with nightly builds. This is what *I* would choose. So your users can choose their level of stability vs bleeding edge. Ok thanks for the feedback. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Best practice for latest package in COPR?
I would like to start providing the latest version of ODB in a COPR for stable releases of Fedora and RHEL. Is there a best practice for this sort of thing? The main question I have is: Is it better to use a single repo and continue to update it with the latest release? Or is it better to have a repo for version 2.4 and then a separate one for when 2.5 comes out? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL-devel] QGIS 2.8.2 for EPEL 7
I just built QGIS 2.8.2 for RHEL/EPEL 7 ( http://koji.fedoraproject.org/koji/taskinfo?taskID=9997800 ) and it is available in the testing repo ( https://admin.fedoraproject.org/updates/qgis-2.8.2-1.el7 ). I built it without PyQwt because it doesn't support Qwt 6 ( http://lists.osgeo.org/pipermail/qgis-developer/2014-December/036112.html ), so I'm sure that some functionality is disabled and/or won't work but the main application is available for testing. Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: yum for mock in RHEL 6?
On Wed, Jun 3, 2015 at 7:31 AM, Mathieu Bridon boche...@fedoraproject.org wrote: On Wed, 2015-06-03 at 14:19 +0200, Miroslav Suchý wrote: Dne 2.6.2015 v 06:56 Dave Johansen napsal(a): https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_a nd_DNF I just ran into this issue and I was wondering if it's possible for this flag to be add to the default config on RHEL 6/7. Technically yes. Politically no. As stated in refered blog entry: http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not _work_on_el_6_and_el7_and_how_to_fix_it/index.html I decided to go with 3rd option. And you must manually acknowledge that you are creating builds non-standard way and they may differ from builds made on Fedora. I don't mean to start an argument and this is a question out of honest curiosity. I'm not familiar with the details of yum or dnf's requires resolution, but are there really ambiguities in the dependency tree that have multiple resolutions that are valid (like the ruby example you list in the blog post)? Except that builds made on Fedora Koji all use yum to populate the mock chroot, not dnf. As a result, it is the mock default configuration of using dnf which is non-standard. In my mind, non-standard but works is better than standard but broken. Especially, when the error is a bit hard to decipher and tracking down a solution can take a while (at least in my case it did). Basically, I think that one of the following solutions would be helpful: 1) Change EL to default to using yum so it just works, or 2) Change the error message on EL to indicate why it's not working and where more info can be found. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: yum for mock in RHEL 6?
On Wed, Jun 3, 2015 at 8:17 AM, Miroslav Suchý msu...@redhat.com wrote: Dne 3.6.2015 v 17:10 Dave Johansen napsal(a): I don't mean to start an argument and this is a question out of honest curiosity. I'm not familiar with the details of yum or dnf's requires resolution, but are there really ambiguities in the dependency tree that have multiple resolutions that are valid (like the ruby example you list in the blog post)? Yes, there are. Other example can be soft deps (which start to shown up in Fedora). Recommends are ignored by Yum, while DNF install them by default. 2) Change the error message on EL to indicate why it's not working and where more info can be found. *nod* This is something I can work on. Great! That would be very helpful and much appreciated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gcc5 C++11 ABI rebuilds and FTBFS packages
On Wed, May 6, 2015 at 9:10 AM, Dave Johansen davejohan...@gmail.com wrote: On Mon, May 4, 2015 at 4:09 AM, Kalev Lember kalevlem...@gmail.com wrote: iwyu: http://koji.fedoraproject.org/koji/taskinfo?taskID=9651015 A clang/llvm 3.6 compatible version of include-what-you-use (iwyu) hasn't been released yet. Once that's available, I will update iwyu and rebuild. iwyu has been updated to 0.4 and rebuilt: http://koji.fedoraproject.org/koji/taskinfo?taskID=9924511 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
yum for mock in RHEL 6?
https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_and_DNF I just ran into this issue and I was wondering if it's possible for this flag to be add to the default config on RHEL 6/7. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] cmake and cmake28 in RHEL 6?
On Sat, May 16, 2015 at 7:48 PM, Orion Poplawski or...@cora.nwra.com wrote: On 05/15/2015 10:57 PM, Dave Johansen wrote: On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: On 04/21/2015 08:48 PM, Dave Johansen wrote: On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com mailto:or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: On 04/20/2015 09:32 PM, Dave Johansen wrote: I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions: 1) Is the cmake28 a duplicate and need to be removed? Yes. Ok. Is this already being worked on? Or does a bugzilla need to be created for it? A quick search: https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28list_id=3417355 turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351 There is some question as to whether or not it is worth the pain to retire. I suppose you could also consider it pulling things away from EPEL users. If it is kept, it probably should be updated at least. Would it be possible to create a Bugzilla and request that a virtual provide for cmake28 be added to the cmake package in RHEL? I believe that would allow the package in EPEL to be retired without requiring changes to existing .spec files. I'm guessing that a cmake28 symlink might be needed as well, but it still seems possible and a solution that shouldn't have too much headache. Sure, anything is possible :). Although I don't see what the big deal about changing the EPEL packages would be. If anything, it would just bring them back in line with the Fedora branches. My concern would just be the added effort of maintaining both of them and it falling behind like has already happened here. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] cmake and cmake28 in RHEL 6?
On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski or...@cora.nwra.com wrote: On 04/21/2015 08:48 PM, Dave Johansen wrote: On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: On 04/20/2015 09:32 PM, Dave Johansen wrote: I just noticed that the version of cmake that comes with RHEL 6 is currently 2.8.12.2 and the EPEL has a cmake28 package that is at version 2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and updated in a later point release, but I have two questions: 1) Is the cmake28 a duplicate and need to be removed? Yes. Ok. Is this already being worked on? Or does a bugzilla need to be created for it? A quick search: https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28list_id=3417355 turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351 There is some question as to whether or not it is worth the pain to retire. I suppose you could also consider it pulling things away from EPEL users. If it is kept, it probably should be updated at least. Would it be possible to create a Bugzilla and request that a virtual provide for cmake28 be added to the cmake package in RHEL? I believe that would allow the package in EPEL to be retired without requiring changes to existing .spec files. I'm guessing that a cmake28 symlink might be needed as well, but it still seems possible and a solution that shouldn't have too much headache. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: gcc5 C++11 ABI rebuilds and FTBFS packages
On Mon, May 4, 2015 at 4:09 AM, Kalev Lember kalevlem...@gmail.com wrote: iwyu: http://koji.fedoraproject.org/koji/taskinfo?taskID=9651015 A clang/llvm 3.6 compatible version of include-what-you-use (iwyu) hasn't been released yet. Once that's available, I will update iwyu and rebuild. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Overlapping update?
On Tue, Apr 28, 2015 at 8:12 AM, Kalev Lember kalevlem...@gmail.com wrote: On 04/28/2015 05:05 PM, Dave Johansen wrote: I had rebuilt odb for F22 because of a gcc version change (it's a plugin) and submitted an update [1]. Then another build was done and an update submitted [2]. Do I need to revoke my request? Or what's the right way to handle this? Yes, please. bodhi -R obsolete odb-2.3.0-10.fc22 should do the right thing. Also, would be great if you could leave karma for the new build if the deps there look right. Done and done. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Overlapping update?
I had rebuilt odb for F22 because of a gcc version change (it's a plugin) and submitted an update [1]. Then another build was done and an update submitted [2]. Do I need to revoke my request? Or what's the right way to handle this? Thanks, Dave [1]: https://admin.fedoraproject.org/updates/FEDORA-2015-6852/odb-2.3.0-10.fc22 [2]: https://admin.fedoraproject.org/updates/FEDORA-2015-7054/rubygem-moped-1.5.2-5.fc22,zeromq-ada-2.1.0-17.24032011git.fc22,odb-2.3.0-11.fc22,openchange-2.2-6.fc22 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Request to add glibc-static for rhel 7 ppc64 and ppc64le to EPEL
On Tue, Apr 7, 2015 at 9:40 PM, Kaustubh Deorukhkar kaustubh@gmail.com wrote: Hello, I am looking for glibc-static packages for RHEL 7 (ppc64 and ppc64le) but these are not available in EPEL repo. Is it possible to get these in epel repo please? They are available as part of the base OS. The output of yum info glibc-static is the following on my machine: ... Available Packages Name: glibc-static Arch: i686 Version : 2.12 Release : 1.149.el6_6.5 Size: 1.1 M Repo: updates Summary : C library static libraries for -static linking. URL : http://sources.redhat.com/glibc/ License : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ Description : The glibc-static package contains the C library static libraries : for -static linking. You don't need these, unless you link statically, : which is highly discouraged. ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Breathe for phython-sphinx?
Is Breathe for python-sphinx ( https://github.com/michaeljones/breathe ) available for Fedora? My searching with yum and such seems to indicate no, but I just wanted to ask on here in case it was packaged in a way that I didn't expect. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Wed, Apr 1, 2015 at 1:32 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.04.2015 um 06:53 schrieb Dave Johansen: I added the call to mlockall() (it did have to be run as root) on a F21 machine with no swap and the slow down was still visible in the CPU bound task surely, as expected http://serverfault.com/questions/12679/can-anyone-explain-precisely-what-iowait-is I don't get how that is expected. The CPU bound task is now basically guaranteed to not be doing anything that requires disk access, so the iowait should be 0 for the CPU bound task. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Wed, Apr 1, 2015 at 10:39 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.04.2015 um 19:36 schrieb Dave Johansen: On Wed, Apr 1, 2015 at 1:32 AM, Reindl Harald wrote: Am 01.04.2015 um 06:53 schrieb Dave Johansen: I added the call to mlockall() (it did have to be run as root) on a F21 machine with no swap and the slow down was still visible in the CPU bound task surely, as expected http://serverfault.com/questions/12679/can-anyone- explain-precisely-what-iowait-is I don't get how that is expected. The CPU bound task is now basically guaranteed to not be doing anything that requires disk access, so the iowait should be 0 for the CPU bound task the purpose of mlockall() was not to solve the problem, it's intention is only to reduce side-effects in the test scenario Ok, that makes sense. I was just confused about the link to iowait and assumed you were implying that it was expected that the CPU bound task be impacted by iowait. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Wed, Apr 1, 2015 at 8:18 AM, Stephen John Smoogen smo...@gmail.com wrote: On 31 March 2015 at 22:53, Dave Johansen davejohan...@gmail.com wrote: On Tue, Mar 31, 2015 at 3:26 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Mar 31, 2015 at 12:21:55PM -0700, Dave Johansen wrote: You're right that is a problem because my purely CPU bound task was actually writing to disk every 10 seconds, so I've attached an updated version that pre-allocates a vector and stores the results there so they can be dumped when the users presses Ctrl-C. With this update, the CPU bound task should only using CPU and existing memory but I still see the same slow down in the CPU bound task when the disk I/O is happening. For the definitive test, you might want to add a call to mlockall() into your program. It is supposed to lock every page of your process into RAM (just in case it is being swapped out, and hence using I/O). I guess you will also need to run the CPU test program as root. I added the call to mlockall() (it did have to be run as root) on a F21 machine with no swap and the slow down was still visible in the CPU bound task. The slowdown isn't going to go away with mlockall etc. All that is to do is so you can have a better idea of where the slowdown is by removing various noise. There isn't going to be any quick fix for the slowdown. At best you can figure out the points in the kernel that might need fixing.. but realize this is a problem which has been around for at least a decade and a half. It has been looked at in various forms over and over and over again by kernel devels. It isn't going to be fixed quickly or easily so expect that if you are interested in figuring it out and helping the devels that there isn't going to be an quick fix. It is going to be a long hard slog. I'm ok with it taking a while to look into this issue. The kernel is a complex system and this is an issue that seems to touch more than one of the most complex parts, so I imagine that analyzing this and understanding the source of the issue will take quite a bit of time. I'm hoping to be able to help improve the kernel in the long term and that's why I am trying to make as simple of a reproducer as possible. It seems like I'm starting to reach the point where as much of the noise as possible has been removed and the effect is small but the issue is still distinctly reproducible. So my next question would then be, what's next?. Is running the CPU bound task with something like perf record while doing the disk I/O and not doing the disk I/O the right thing? Or is there a better option that can help try and isolate where the issue is happening? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Tue, Mar 31, 2015 at 3:26 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Mar 31, 2015 at 12:21:55PM -0700, Dave Johansen wrote: You're right that is a problem because my purely CPU bound task was actually writing to disk every 10 seconds, so I've attached an updated version that pre-allocates a vector and stores the results there so they can be dumped when the users presses Ctrl-C. With this update, the CPU bound task should only using CPU and existing memory but I still see the same slow down in the CPU bound task when the disk I/O is happening. For the definitive test, you might want to add a call to mlockall() into your program. It is supposed to lock every page of your process into RAM (just in case it is being swapped out, and hence using I/O). I guess you will also need to run the CPU test program as root. I added the call to mlockall() (it did have to be run as root) on a F21 machine with no swap and the slow down was still visible in the CPU bound task. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Mon, Mar 30, 2015 at 10:02 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Mon, Mar 30, 2015 at 3:58 PM, Dave Johansen davejohan...@gmail.com wrote: I noticed on RHEL 6 that when a large amount of disk I/O is happening that CPU bound tasks slow down. I have been able to reproduce it in Fedora 21 as well and here are the instructions of how I can reproduce it with a simple test: Writing to disk is not free. There is overhead in writing the data, especially if the files are being re-arranged and the directory structure revised, and there's overhead in doing it safely to avoid accidental loss of data. There are options to improve such performance, such as using the 'noatime' option, or using well optimized filesystems. But there are certainly limits. I am not familiar with the low level details of disk I/O but I'm sure that they are far more complicated than my basic assumptions, but my concern is how can a disk-bound process steal cycles from a CPU-bound one that is not access the disk at all. The lwn.net articles that drago01 linked to helped shed some light on what's going on, but it sounds like there is still some potential work that could be done to help improve the situation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Tue, Mar 31, 2015 at 10:44 AM, Richard W.M. Jones rjo...@redhat.com
wrote:
On Tue, Mar 31, 2015 at 08:32:16AM -0700, Dave Johansen wrote:
I am not familiar with the low level details of disk I/O but I'm sure
that
they are far more complicated than my basic assumptions, but my concern
is
how can a disk-bound process steal cycles from a CPU-bound one that is
not
access the disk at all. The lwn.net articles that drago01 linked to
helped
shed some light on what's going on, but it sounds like there is still
some
potential work that could be done to help improve the situation.
When you run the cpu load test program, where do you write the
statistics to?
I had been redirecting it directly to disk.
For a fair test you probably want to change the program so it stores
them in preallocated memory and prints them at the end of the test.
You're right that is a problem because my purely CPU bound task was
actually writing to disk every 10 seconds, so I've attached an updated
version that pre-allocates a vector and stores the results there so they
can be dumped when the users presses Ctrl-C. With this update, the CPU
bound task should only using CPU and existing memory but I still see the
same slow down in the CPU bound task when the disk I/O is happening.
#include iostream
#include vector
#include math.h
#include signal.h
#include time.h
#include stdlib.h
struct Stats {
Stats(const timespec t_, const int n_, const double mean_, const double
stdDev) :
t(t_.tv_sec),
n(n_),
mean(mean_),
stdDev(stdDev)
{
}
time_t t;
int n;
double mean, stdDev;
};
long do_work(long pseed)
{
// Just do a bunch of computations to use up CPU
for (int bnum=0; bnum30; ++bnum)
pseed = pseed * 1103515245 + 12345;
return pseed;
}
// Buffer the results
std::vectorStats g_stats;
// Dump the results when Ctrl-C is presssed
void handle_signal(int n)
{
for (std::vectorStats::const_iterator iter = g_stats.begin(); iter !=
g_stats.end(); ++iter)
std::cout iter-t ' ' iter-n ' ' iter-mean ' '
iter-stdDev std::endl;
exit(0);
}
int main()
{
// Track the time between work cycles
timespec t, lastT;
clock_gettime(CLOCK_REALTIME, lastT);
// And the next time an output should happen
time_t nextOutputT = lastT.tv_sec + 10;
// Pre-allocate the buffer for the stats for 1 day
g_stats.reserve(1);
// And create the handler for dumping the stats
signal(SIGINT, handle_signal);
int n = 0;
double mean = 0;
double m2 = 0;
int sum = 0;
// Loop for a long time instead of infinitely so the compiler won't optimize
away anything
while (n 10) {
// Do some work
sum += do_work(lastT.tv_nsec);
// Get the current time
int retVal = clock_gettime(CLOCK_REALTIME, t);
if (retVal == 0) {
// And calculate the statistics of the time between work cycles
long dT = (t.tv_sec - lastT.tv_sec) * 10 +
(t.tv_nsec - lastT.tv_nsec);
++n;
double delta = dT - mean;
mean += delta / n;
m2 += delta * (dT - mean);
} else {
std::cerr Error getting time: retVal
std::endl;
return -1;
}
// If it's time to output the statistics
if (t.tv_sec = nextOutputT) {
// Then output them
if (n 1)
m2 = sqrt(m2 / (n - 1));
g_stats.push_back(Stats(t, n, mean, m2));
// Reset the statisitics
n = 0;
mean = 0;
m2 = 0;
// And record the next time an output should happen
nextOutputT = t.tv_sec + 10;
}
// Save the current time for calculating time between work cycles
lastT = t;
}
// Return the value so the compiler won't optimize away anything
return sum;
}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Why does disk I/O slow down a CPU bound task?
I noticed on RHEL 6 that when a large amount of disk I/O is happening that
CPU bound tasks slow down. I have been able to reproduce it in Fedora 21
as well and here are the instructions of how I can reproduce it with a
simple test:
1) Build the disk_test.cc (the CPU bound task) and run it.
2) Create a large file to copy ( fallocate -l 10G junk ).
3) Copy that file with a one minute delay between copies ( while true; do
cp junk junk2; sleep 60; done )
If you direct the output of disk_test.cc to a file, then you can plot the
results in gnuplot with the following commands to see the change in the
mean time between finishing the work cycle when the file is being copied:
set xdata time
set timefmt %s
plot out.txt using 1:3 with lines
You can also notice that the load average is also going up, so it seems
like something in the kernel/scheduler is getting some sort of exclusive
lock in the disk I/O process and that's causing the CPU bound task to not
be able to execute when it should. Any ideas?
Thanks,
Dave
#include iostream
#include math.h
#include time.h
long do_work(long pseed)
{
// Just do a bunch of computations to use up CPU
for (int bnum=0; bnum30; ++bnum)
pseed = pseed * 1103515245 + 12345;
return pseed;
}
int main()
{
// Track the time between work cycles
timespec t, lastT;
clock_gettime(CLOCK_REALTIME, lastT);
// And the next time an output should happen
time_t nextOutputT = lastT.tv_sec + 10;
int n = 0;
double mean = 0;
double m2 = 0;
int sum = 0;
// Loop for a long time instead of infinitely so the compiler won't optimize
away anything
while (n 10) {
// Do some work
sum += do_work(lastT.tv_nsec);
// Get the current time
int retVal = clock_gettime(CLOCK_REALTIME, t);
if (retVal == 0) {
// And calculate the statistics of the time between work cycles
long dT = (t.tv_sec - lastT.tv_sec) * 10 +
(t.tv_nsec - lastT.tv_nsec);
++n;
double delta = dT - mean;
mean += delta / n;
m2 += delta * (dT - mean);
} else {
std::cerr Error getting time: retVal
std::endl;
return -1;
}
// If it's time to output the statistics
if (t.tv_sec = nextOutputT) {
// Then output them
if (n 1)
m2 = sqrt(m2 / (n - 1));
std::cout t.tv_sec ' ' n ' ' mean ' '
m2 std::endl;
// Rest the statisitics
n = 0;
mean = 0;
m2 = 0;
// And record the next time an output should happen
nextOutputT = t.tv_sec + 10;
}
// Save the current time for calculating time between work cycles
lastT = t;
}
// Return the value so the compiler won't optimize away anything
return sum;
}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why does disk I/O slow down a CPU bound task?
On Mon, Mar 30, 2015 at 3:15 PM, M. Edward (Ed) Borasky zn...@znmeb.net wrote: On Mon, Mar 30, 2015 at 2:43 PM, drago01 drag...@gmail.com wrote: https://lwn.net/Articles/572911/ https://lwn.net/Articles/467328/ Thanks for the info. That's very helpful, but it looks like that discussion didn't come to any sort of resolution. Do you know if it's being picked up anywhere else? Yeah, I vaguely remember that discussion. I went down this rabbit hole in mid-2008, wrote a couple of papers and moved on with my life. There's no software solution - get faster hardware and more RAM and don't design I/O-bound systems. That works for a lot of problems, but some are I/O-bound by definition. Databases are a prime example of a task of that (and the one that started me looking into this). For any non-trivial application, you'll never be able to throw enough CPU/RAM at the problem to make the disk not matter when the system in under heavy use. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Current update policy?
On Wed, Mar 18, 2015 at 6:34 AM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 17 Mar 2015 21:36:41 -0700 Dave Johansen davejohan...@gmail.com wrote: What is the current update policy for EPEL? The stated one seems to be along the lines of no major changes ( http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like whatever the packager is willing to maintain is the actual policy. I ask because a bugzilla was just opened against a package I maintain ( https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know how I should handle it. Does it need to be closed as wontfix? Or should a notice of upcoming major update policy be put in place to handle things like this? Rex already closed it as WONTFIX, however to expand on that: The current policy is to not change the user experence or require manual intervention on updates if at all possible. There are some cases where there's not much choice (like when the version shipped has serious security or data loss bugs and a upgrade to a new version is the only answer), but in those cases theres announcements to the epel-announce list and lots of time in testing. Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Current update policy?
On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi ke...@scrye.com wrote: On Wed, 18 Mar 2015 08:00:35 -0700 Dave Johansen davejohan...@gmail.com wrote: Is that really true? The Qt 5 package in EPEL 6 has been updated several times and I don't recall ever seeing an email/announcement/etc. Were the upgrades incompatible? You have to manually intervene? Honestly, on the machines I'm using, I installed 5.2 and haven't updated since 5.3 was released because I didn't want to rebuild and re-test all of my stuff, but my understanding of the following is that the upgrades are not completely compatible: http://upstream.rosalinux.ru/versions/qt.html ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Current update policy?
What is the current update policy for EPEL? The stated one seems to be along the lines of no major changes ( http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like whatever the packager is willing to maintain is the actual policy. I ask because a bugzilla was just opened against a package I maintain ( https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know how I should handle it. Does it need to be closed as wontfix? Or should a notice of upcoming major update policy be put in place to handle things like this? Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Issue with yum/systemd?
On Wed, Mar 11, 2015 at 6:40 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Mar 10, 2015 at 08:15:38PM -0700, Dave Johansen wrote: On Tue, Mar 10, 2015 at 7:53 PM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Mar 10, 2015 at 5:10 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Here's the contents of the script that it's waiting on: if [ $1 -eq 0 ] ; then # Package removal, not upgrade systemctl --no-reload disable minetest@default.service /dev/null 21 || : systemctl stop minetest@default.service /dev/null 21 || : fi Sorry for the multiple emails. It's stuck on the call to stop the service. When I run status, I prints the following: . minetest@default.service - Minetest multiplayer server w/ default.conf server config Loaded: loaded (/usr/lib/system/system/minetest@.service; disabled) Active: inactive (dead) Any recommendations on what I should do next to diagnose the source of the problem? How long does it stay in this state? systemctl times out connections after a timeout (25s ?), so even if it fails to communicate with PID1 for any reason, rpm should still continue at some point. pstree -ap pid-of-rpm should show a list of processes. If it's systemctl that is hanging, can you post the backtrace? It had been stuck for ~3 days and last night I got sick of my computer being sluggish, so I started trying to see if I could get it to break free. I should have gotten a stacktrace for systemctl first, but didn't think of that and here's what happened: I ran systemctl start minetest@default.service Then after a few seconds, the system went into what I believe was suspend mode (screen went blank and I had to hit the power button to get things to come back). I then hit Ctrl-C after about 30 seconds because it appeared that the service wasn't actually starting (it technically was in the process of being removed after all). After that, the CPU usage of systemd dropped back to being close to 0 and the status output the following: ● minetest@default.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) Mar 10 20:16:19 JohansenDev systemd[1]: Failed to start minetest@default.service. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Issue with yum/systemd?
On Tue, Mar 10, 2015 at 7:53 PM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Mar 10, 2015 at 5:10 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Here's the contents of the script that it's waiting on: if [ $1 -eq 0 ] ; then # Package removal, not upgrade systemctl --no-reload disable minetest@default.service /dev/null 21 || : systemctl stop minetest@default.service /dev/null 21 || : fi Sorry for the multiple emails. It's stuck on the call to stop the service. When I run status, I prints the following: . minetest@default.service - Minetest multiplayer server w/ default.conf server config Loaded: loaded (/usr/lib/system/system/minetest@.service; disabled) Active: inactive (dead) Any recommendations on what I should do next to diagnose the source of the problem? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Issue with yum/systemd?
On Tue, Mar 10, 2015 at 5:10 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/10/2015 03:13 AM, Dave Johansen wrote: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 [...] It looks like yum is waiting on some process. It's waiting for a package scriptlet to finish. Here's the contents of the script that it's waiting on: if [ $1 -eq 0 ] ; then # Package removal, not upgrade systemctl --no-reload disable minetest@default.service /dev/null 21 || : systemctl stop minetest@default.service /dev/null 21 || : fi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Issue with yum/systemd?
I posted this issue on the users mailing list but didn't get a response ( https://lists.fedoraproject.org/pipermail/users/2015-March/459083.html ), so I thought I'd try here. I did a yum remove on F21 and it hung after the 2nd of 8 .rpms and systemd has been using ~40% of the CPU since then. Here's the stacktrace from yum: #0 0xb76debac in __kernel_vsyscall () #1 0xb7510d03 in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0xb6fa4842 in rpmScriptRun () from /lib/librpm.so.3 #3 0xb6f83c53 in runScript () from /lib/librpm.so.3 #4 0xb6f8434f in runInstScript () from /lib/librpm.so.3 #5 0xb6f8531b in rpmpsmRun () from /lib/librpm.so.3 #6 0xb6f9a3cb in rpmteProcess () from /lib/librpm.so.3 #7 0xb6fa1714 in rpmtsRun () from /lib/librpm.so.3 #8 0xb6fd0f0a in rpmts_Run () from /usr/lib/python2.7/site-packages/rpm/_rpm.so #9 0xb758a609 in PyCFunction_Call () from /lib/libpython2.7.so.1.0 #10 0xb754a645 in PyObject_Call () from /lib/libpython2.7.so.1.0 #11 0xb75e6f33 in PyEval_CallObjectWithKeywords () from /lib/libpython2.7.so.1.0 #12 0xb75616c6 in methoddescr_call () from /lib/libpython2.7.so.1.0 #13 0xb754a645 in PyObject_Call () from /lib/libpython2.7.so.1.0 #14 0xb75eb187 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #15 0xb75ecfe1 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #16 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #17 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #18 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #19 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #20 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #21 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #22 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #23 0xb75ecf11 in PyEval_EvalFrameEx () from /lib/libpython2.7.so.1.0 #24 0xb75ee1ea in PyEval_EvalCodeEx () from /lib/libpython2.7.so.1.0 #25 0xb75ee344 in PyEval_EvalCode () from /lib/libpython2.7.so.1.0 #26 0xb76078db in run_mod () from /lib/libpython2.7.so.1.0 #27 0xb7608d70 in PyRun_FileExFlags () from /lib/libpython2.7.so.1.0 #28 0xb760a163 in PyRun_SimpleFileExFlags () from /lib/libpython2.7.so.1.0 #29 0xb760a6c8 in PyRun_AnyFileExFlags () from /lib/libpython2.7.so.1.0 #30 0xb761c911 in Py_Main () from /lib/libpython2.7.so.1.0 #31 0x08048578 in main () It looks like yum is waiting on some process. Is there a way I can tell what the process is and why it hasn't returned yet? Any other ideas on how I can figure out what is going wrong? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 Alpha Freeze
On Tue, Feb 24, 2015 at 11:24 AM, Dennis Gilmore den...@ausil.us wrote: Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. I have a question on how I'm supposed to handle a new package. I was working on packaging iwyu [1] and it built for all of the target releases except for F22 because of some gcc 5.0 issues. It appears that the last one has been resolved [2], so how do I handle this situation? Do I just wait until the alpha freeze is over to build iwyu for F22? Or should I use a buildroot override? Thanks, Dave [1] https://bugzilla.redhat.com/show_bug.cgi?id=1091659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1190329#c2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 Alpha Freeze
On Fri, Feb 27, 2015 at 8:50 AM, Peter Robinson pbrobin...@gmail.com wrote: On Fri, Feb 27, 2015 at 3:23 PM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Feb 24, 2015 at 11:24 AM, Dennis Gilmore den...@ausil.us wrote: Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. I have a question on how I'm supposed to handle a new package. I was working on packaging iwyu [1] and it built for all of the target releases except for F22 because of some gcc 5.0 issues. It appears that the last one has been resolved [2], so how do I handle this situation? Do I just wait until the alpha freeze is over to build iwyu for F22? Or should I use a buildroot override? Build it as per normal, if it's a single package submit it to bodhi as an update for F-22, if you need to build other packages against it you'll need to do a build override as per normal stable releases. http://koji.fedoraproject.org/koji/taskinfo?taskID=9096041 The package doesn't build and needs the gcc update in order to build. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Upstream Release Monitoring Systems
On Tue, Feb 24, 2015 at 9:51 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Tue, Feb 24, 2015 at 10:33:34AM -0600, Michael Catanzaro wrote: This looks cool. On Fri, Feb 20, 2015 at 2:36 PM, Ralph Bean rb...@redhat.com wrote: - Enable the monitoring flag for that Fedora package in pkgdb2[4]. I think this is the step people will forget to do. If there was at least a reminder on the release-monitoring website, that would be helpful. This is now `on` by default for every new package added to pkgdb. For the old one you will have to do it manually (or via a script using the API). Could a one time report be generated and sent to the mailing? Or is the list too long for that to be feasible? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Easiest way to debug build failures on rawhide?
On Mon, Feb 23, 2015 at 8:18 PM, Orion Poplawski or...@cora.nwra.com wrote: On 02/22/2015 10:21 PM, Dave Johansen wrote: On Sun, Feb 22, 2015 at 4:52 PM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: On 02/21/2015 08:07 PM, Dave Johansen wrote: I'm looking into another issue on F22 but there's no .cfg for that. Is that still just coming down the pipeline since the branch just recently happened? Or is there a way I can manually create the .cfg file? Thanks, Dave The just released 1.2.7-1 has the F22 configs. Cool. I just got them in an update. Is there a way to get them for CentOS as well? A couple clicks should get you to (and the answer): https://admin.fedoraproject.org/updates/search/mock Awesome. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Easiest way to debug build failures on rawhide?
On Sun, Feb 22, 2015 at 4:52 PM, Orion Poplawski or...@cora.nwra.com wrote: On 02/21/2015 08:07 PM, Dave Johansen wrote: I'm looking into another issue on F22 but there's no .cfg for that. Is that still just coming down the pipeline since the branch just recently happened? Or is there a way I can manually create the .cfg file? Thanks, Dave The just released 1.2.7-1 has the F22 configs. Cool. I just got them in an update. Is there a way to get them for CentOS as well? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Easiest way to debug build failures on rawhide?
On Thu, Feb 19, 2015 at 8:28 AM, Dave Johansen davejohan...@gmail.com wrote: On Wed, Feb 18, 2015 at 9:54 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: On 18.02.2015 16:31, Miroslav Suchý wrote: On 02/18/2015 04:12 PM, Dave Johansen wrote: I'm running into an issue where odb won't build on rawhide ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 ) and I need to be able to take a look at the config.log file but it's not available from the standard koji output. So what's the easiest way for me to get access to that file? Do I have to install rawhide in a virtual machine and do the build myself? Or is there a simpler way to get access to other outputs from a build? mock -r fedora-rawhide-x86_64 --no-cleanup-after your.src.rpm and then investigate /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/ or mock -r fedora-rawhide-x86_64 --shell and you are inside of that build chroot. For such situations I have simple script: - #!/bin/bash SRCRPM=$1 X=X LC_ALL=C LANG=C mock $SRCRPM \ --resultdir=~mjuszkie/rpmbuild/mock/`basename $SRCRPM` \ --verbose \ --no-cleanup-after \ --uniqueext=$SRCRPM $2 X=Y if [ $X == X ]; then echo mock --shell --uniqueext=$SRCRPM $2 fi mock --clean --uniqueext=$SRCRPM $2 - Use is simple: hrwmock.sh *.src.rpm (to change build target I just add -r fedora-21-aarch64). Using mock did the trick. I'm looking into another issue on F22 but there's no .cfg for that. Is that still just coming down the pipeline since the branch just recently happened? Or is there a way I can manually create the .cfg file? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 12:34 PM, Till Maas opensou...@till.name wrote: On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote: I've never argumented against the goal that web browser or all network aware services should be PIEs, after all, why would we (Ulrich Drepper and myself) add the PIE support into the toolchain otherwise? I'm just not convinced most of the unpriviledged programs should be PIEs. Thanks to e.g. e-mail about any program can be made to run untrusted data, e.g. PDF readers, office suites, image viewers, if you open an attachment of the respective type. Therefore it makes a sane default IMHO. It is also something to attract users that care about security very much to Fedora. https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode https://gcc.gnu.org/ml/gcc/2004-06/msg01956.html From those articles, it sounds like it's a worst case 5-10% hit. I agree that's kind of annoying and a lot of my stuff doesn't even run connected to the internet, but if that 5-10% worst case hit that will usually be imperceptible can prevent my machine from being bitten by some malware that got on the network because someone plugged in a USB drive they shouldn't have, then I'm all for it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Easiest way to debug build failures on rawhide?
On Wed, Feb 18, 2015 at 8:36 AM, Paul Howarth p...@city-fan.org wrote:
On 18/02/15 15:12, Dave Johansen wrote:
I'm running into an issue where odb won't build on rawhide (
http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 ) and I need
to be able to take a look at the config.log file but it's not available
from the standard koji output.
So what's the easiest way for me to get access to that file? Do I have
to install rawhide in a virtual machine and do the build myself? Or is
there a simpler way to get access to other outputs from a build?
Try something like this:
%{configure} || { cat config.log ; exit 1 }
The config.log content would then appear in build.log
That's a nifty trick that I'll definitely keep in my back pocket.
Thanks,
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Easiest way to debug build failures on rawhide?
On Wed, Feb 18, 2015 at 9:54 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: On 18.02.2015 16:31, Miroslav Suchý wrote: On 02/18/2015 04:12 PM, Dave Johansen wrote: I'm running into an issue where odb won't build on rawhide ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 ) and I need to be able to take a look at the config.log file but it's not available from the standard koji output. So what's the easiest way for me to get access to that file? Do I have to install rawhide in a virtual machine and do the build myself? Or is there a simpler way to get access to other outputs from a build? mock -r fedora-rawhide-x86_64 --no-cleanup-after your.src.rpm and then investigate /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/ or mock -r fedora-rawhide-x86_64 --shell and you are inside of that build chroot. For such situations I have simple script: - #!/bin/bash SRCRPM=$1 X=X LC_ALL=C LANG=C mock $SRCRPM \ --resultdir=~mjuszkie/rpmbuild/mock/`basename $SRCRPM` \ --verbose \ --no-cleanup-after \ --uniqueext=$SRCRPM $2 X=Y if [ $X == X ]; then echo mock --shell --uniqueext=$SRCRPM $2 fi mock --clean --uniqueext=$SRCRPM $2 - Use is simple: hrwmock.sh *.src.rpm (to change build target I just add -r fedora-21-aarch64). Using mock did the trick. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does order matter for the rebuilds for the gcc 5.0 C++ ABI change?
On Wed, Feb 18, 2015 at 8:54 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Feb 18, 2015 at 08:04:53AM -0700, Dave Johansen wrote: I rebuilt libcutl the other day and then noticed that later boost was rebuilt. libcutl depends on boost, so is it a problem that it was rebuilt before boost was? Yes. Jakub Jelinek wrote on this list: quote Also, a releng mass rebuild, which I believe is a random package order, would very likely not help very much, due to the ABI changes one needs to rebuild the packages in topological order, non-C++ packages or C++ packages that nothing C++ depends on of course can be left for the mass rebuild, but ideally the rest should be rebuilt manually before the mass rebuild. /quote I had read through the original results of a test mass rebuild and didn't notice anything like that. Sorry for the oversight on my part and thanks for the info. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] include-what-you-use failing tests on PowerPC
On Mon, Feb 16, 2015 at 12:19 PM, Stephen John Smoogen smo...@gmail.com wrote: On 14 February 2015 at 11:00, Dave Johansen davejohan...@gmail.com wrote: I'm working on packaging include-what-you-use and it's failing tests on PowerPC. I don't have access to PowerPC hardware to do the necessary debugging, so I just opened a bugzilla to document it ( https://bugzilla.redhat.com/show_bug.cgi?id=1192723 ). Hopefully, someone can figure out what the problem is and submit a patch. Thanks, Dave I saw a similar problem you had with the arm with a possible fix listed by Peter Robinson. Did that work for PPC64? If not, I would excludearch64 for the time being. For Fedora on ARM, it's failing to build and I haven't had a chance to try the fix yet. For EPEL on PowerPC, it's building but failing during the tests. I'm guessing that ARM will run into the same test failure once it's building. For the time being I've done an ExcludeArch for both. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Does order matter for the rebuilds for the gcc 5.0 C++ ABI change?
I rebuilt libcutl the other day and then noticed that later boost was rebuilt. libcutl depends on boost, so is it a problem that it was rebuilt before boost was? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Easiest way to debug build failures on rawhide?
I'm running into an issue where odb won't build on rawhide ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 ) and I need to be able to take a look at the config.log file but it's not available from the standard koji output. So what's the easiest way for me to get access to that file? Do I have to install rawhide in a virtual machine and do the build myself? Or is there a simpler way to get access to other outputs from a build? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does order matter for the rebuilds for the gcc 5.0 C++ ABI change?
On Wed, Feb 18, 2015 at 12:12 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Feb 18, 2015 at 10:39:16AM -0700, Dave Johansen wrote: On Wed, Feb 18, 2015 at 8:54 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Feb 18, 2015 at 08:04:53AM -0700, Dave Johansen wrote: I rebuilt libcutl the other day and then noticed that later boost was rebuilt. libcutl depends on boost, so is it a problem that it was rebuilt before boost was? Yes. Jakub Jelinek wrote on this list: quote Also, a releng mass rebuild, which I believe is a random package order, would very likely not help very much, due to the ABI changes one needs to rebuild the packages in topological order, non-C++ packages or C++ packages that nothing C++ depends on of course can be left for the mass rebuild, but ideally the rest should be rebuilt manually before the mass rebuild. /quote I had read through the original results of a test mass rebuild and didn't notice anything like that. Sorry for the oversight on my part and thanks for the info. I sound a bit accusatory there. Wasn't meant that way :-) I don't read even a tenth of all the email lists I'm subscribed to either .. No worries. I was very appreciative of the help and the quick response. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Sun, Feb 8, 2015 at 10:17 AM, Marek Polacek pola...@redhat.com wrote: odb-2.3.0-8.fc22.src.rpm build failure because the gcc plugin API has changed. odb has been updated to 2.4.0 which supports the new gcc 5.0 plugin API, but whenever I try to do the rebuild it fails to find libcutl (which I rebuilt last night): http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 Any ideas on what is going on there? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does clang/llvm need to be rebuilt because of the gcc 5.0 upgrade?
n Sat, Feb 14, 2015 at 11:41 AM, Jakub Jelinek ja...@redhat.com wrote: On Sat, Feb 14, 2015 at 11:38:13AM -0700, Dave Johansen wrote: On Sat, Feb 14, 2015 at 11:33 AM, Jakub Jelinek ja...@redhat.com wrote: On Sat, Feb 14, 2015 at 09:25:50AM -0700, Dave Johansen wrote: I'm working on packaging include-what-you-use and it works just fine with Fedora 21, but in rawhide the tests are failing with std::length_error exceptions ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8936112 ). I was thinking that maybe this was because clang/llvm needs to be rebuilt because of the gcc 5.0 upgrade. Is that the issue? Or is something else going on? In F22, C++ packages don't need to be rebuilt, we default to the old ABI for C++. In F23, indeed, everything written in C++ needs to be rebuilt, and there will eventually be a mass rebuild. I remember reading that, but do you have any ideas on why the tests are failing with that exception on rawhide? The ABI of std::string and std::list has changed in F23. Therefore, if you depend on C++ libraries other than libstdc++, they first need to be rebuilt and then your package. Sorry. That was a total brain dead moment on my part. I forgot that F22 had branched and so rawhide is F23. Can I just rebuild llvm/clang? Or is there some mass rebuild that's already in the works that that will conflict with? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review for iwyu?
https://bugzilla.redhat.com/show_bug.cgi?id=1091659 I've been working on packaging include-what-you-use and it's pretty well all ready to go, but just needs a review. Is someone able to do it? I would potentially be able to do a review swap, if needs be. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Source tarball not found?
On Thu, Jan 29, 2015 at 9:50 PM, T.C. Hollingsworth
tchollingswo...@gmail.com wrote:
On Thu, Jan 29, 2015 at 9:30 PM, Dave Johansen davejohan...@gmail.com
wrote:
I'm trying to build llvm after applying a patch and I keep getting an
error
about lldb-3.4.src.tar.gz not being found, but that file has been there
for
previous builds and fedpkg says it has already been uploaded. Any ideas
on
what's wrong?
The build.log can be found at:
https://kojipkgs.fedoraproject.org//work/tasks/8365/8778365/build.log
It's probably because you have:
%if %{with lldb}
Source3:
%{downloadurl_base}/lldb-%{version_base}%{?prerel}.src.tar.gz
%endif
and %{with lldb} evaluates to false during SRPM creation time, so the
tarball is not included in the SRPM and therefore isn't available to
the binary build later on.
Just remove this conditional. You should always include all sources
in the SRPM regardless of what's actually enabled in the build, so
other people who just have the SRPM can turn on options if they want
without having to download extra sources.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8779288
That did the trick.
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Source tarball not found?
I'm trying to build llvm after applying a patch and I keep getting an error about lldb-3.4.src.tar.gz not being found, but that file has been there for previous builds and fedpkg says it has already been uploaded. Any ideas on what's wrong? The build.log can be found at: https://kojipkgs.fedoraproject.org//work/tasks/8365/8778365/build.log Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Questiona regarding c++11 support
On Wed, Jan 14, 2015 at 9:12 PM, Zhiwei Zhu z_...@wargaming.net wrote: Dear all, I am not sure whether this has been discussed before or whether it’s appropriate to discuss this in this list. My question is about c++11 support for the projects on epel (probably more specifically, epel7). Do we have any kind of general policy regarding c++11 support? I am asking this because recently we encountered a problem related to this. The case is that our project is built with option ‘-std=c++11’ while the library used by our project on epel (specifically mongo-cxx-driver) was not built with this option, and our process simply crashes during start. The root cause is the ABI built with c++11 option is actually not compatible with that without it. Please refer to https://gcc.gnu.org/wiki/Cxx11AbiCompatibility. So the ‘-std=c++11’ draws a clear line between binaries/libraries, all of them must be built either with it or without it(C code is probably fine). You cannot mix them togother, otherwise there might be risks. Is there any general policy regarding this c++11 support? Or just maintainers make the decision for specific project? If the question is not approriate to discuss in this list, please ignore it. Or if anyone has any idea about where I can find relevant information, could you please share with me? devtoolset seems to be the right solution for C++11 support because it offers better ABI compatibility ( see section 2.2.2 at https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/3/html/3.0_Release_Notes/DTS3.0_Release.html#Features ). However, having said that, I previously brought up the idea of making the devtoolset available for use in the EPEL ( https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html ) but the conversation never really picked up any traction. I would definitely love to see devtoolset be made available for use when building packages in the EPEL but I'm just not sure how to get that ball rolling. Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
gcc and re-initialization of dynamic libraries?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 https://bugzilla.redhat.com/show_bug.cgi?id=1083292 I know that this isn't directly related to Fedora, but I was wondering if anyone had any recommendations on how to proceed with this. clang and icpc generate code that has the correct behavior (or at least what I believe is the correct behavior), but because of some flags that are set by gcc it doesn't re-initialize the dynamic library as expected. Any ideas/suggestions? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: \n in taskotron's depcheck messages
On Tue, Jan 6, 2015 at 4:12 PM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 6 Jan 2015 16:04:07 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm not sure if this is the right place to post this, but there are \n's in the messages from taskotron's depcheck. The problem is that some email clients (gmail in particular) parse that as part of the URL and make the links incorrect. It's a pretty minor thing, but would make it a lot easier to use and hopefully is an easy fix. Likely related to: https://fedorahosted.org/bodhi/ticket/767 Ya, that looks like the same issue. Good to hear it's already on the radar. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
\n in taskotron's depcheck messages
I'm not sure if this is the right place to post this, but there are \n's in the messages from taskotron's depcheck. The problem is that some email clients (gmail in particular) parse that as part of the URL and make the links incorrect. It's a pretty minor thing, but would make it a lot easier to use and hopefully is an easy fix. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Unknown origin Build error
Yes. That's the error. On Jan 2, 2015 4:15 PM, Moez Roy moez@gmail.com wrote: you mean like this: 8516012 buildSRPMFromSCM (/banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open ( buildhw-03.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin for fedpkg-minimal-0.5.1.0-2.el7.noarch: file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/ 0 free 1 open 0 done 1 failed 8516006 build (epel7-candidate, /banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open ( buildhw-07.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin for fedpkg-minimal-0.5.1.0-2.el7.noarch: file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/ 0 free 0 open 0 done 2 failed On Fri, Jan 2, 2015 at 3:09 PM, Dave Johansen davejohan...@gmail.com wrote: I just tried building llvm on EPEL 7 and received an unknown origin build error ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8516490 ). Is this some temporary issue because of a recent update that will resolve itself? Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Unknown origin Build error
I just tried building llvm on EPEL 7 and received an unknown origin build error ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8516490 ). Is this some temporary issue because of a recent update that will resolve itself? Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Unknown origin Build error
Nevermind, I guess. It appears to be working now. http://koji.fedoraproject.org/koji/taskinfo?taskID=8517009 On Fri, Jan 2, 2015 at 5:00 PM, Dave Johansen davejohan...@gmail.com wrote: Yes. That's the error. On Jan 2, 2015 4:15 PM, Moez Roy moez@gmail.com wrote: you mean like this: 8516012 buildSRPMFromSCM (/banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open ( buildhw-03.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin for fedpkg-minimal-0.5.1.0-2.el7.noarch: file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/ 0 free 1 open 0 done 1 failed 8516006 build (epel7-candidate, /banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open ( buildhw-07.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin for fedpkg-minimal-0.5.1.0-2.el7.noarch: file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/ 0 free 0 open 0 done 2 failed On Fri, Jan 2, 2015 at 3:09 PM, Dave Johansen davejohan...@gmail.com wrote: I just tried building llvm on EPEL 7 and received an unknown origin build error ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8516490 ). Is this some temporary issue because of a recent update that will resolve itself? Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Qwt and QwtPolar for Qt5?
On Sat, Dec 13, 2014 at 7:19 AM, Dave Johansen davejohan...@gmail.com wrote: On Fri, Dec 12, 2014 at 1:29 PM, Rex Dieter rdie...@math.unl.edu wrote: Dave Johansen wrote: I would like to create Qwt and QwtPolar packages for Qt5 and before opening the Bugzilla I wanted to check if there was any feedback on here. I have spec files and source RPMs available at: https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5.spec https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5-6.1.1-3.el6.src.rpm https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5.spec https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5-1.1.1-2.el6.src.rpm I'm primarily interested in the RHEL 6/7 and haven't tested this on Fedora, so if anyone is willing to build it and do some testing, then that would be helpful as well. Qwt-qt5 support is in rawhide, but I was waiting for upstream to decide on a standard naming scheme before building for stable releases. (They previously used the same library sonames for both Qt4 and Qt5, which isn't nice when you want both to be parallel-installable). Will probably have to do the same for qwtpoloar. I didn't realize that had been done in rawhide. Your solution of having a single spec file to build both is probably easier to maintain and seems like the write way to go. I just realized that there's a potential problem for EPEL 6. It currently has qwt 5.1.1 and it's part of the base OS and not an EPEL package, so it's not possible to do the single spec file solution. So what's everyone's thoughts on this? Should it just be a separate package called qwt-qt5 in EPEL 6? Or is there a better solution? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Qwt and QwtPolar for Qt5?
On Fri, Dec 12, 2014 at 1:29 PM, Rex Dieter rdie...@math.unl.edu wrote: Dave Johansen wrote: I would like to create Qwt and QwtPolar packages for Qt5 and before opening the Bugzilla I wanted to check if there was any feedback on here. I have spec files and source RPMs available at: https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5.spec https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5-6.1.1-3.el6.src.rpm https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5.spec https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5-1.1.1-2.el6.src.rpm I'm primarily interested in the RHEL 6/7 and haven't tested this on Fedora, so if anyone is willing to build it and do some testing, then that would be helpful as well. Qwt-qt5 support is in rawhide, but I was waiting for upstream to decide on a standard naming scheme before building for stable releases. (They previously used the same library sonames for both Qt4 and Qt5, which isn't nice when you want both to be parallel-installable). Will probably have to do the same for qwtpoloar. I didn't realize that had been done in rawhide. Your solution of having a single spec file to build both is probably easier to maintain and seems like the write way to go. I took the same approach of adding -qt5 to the .so files and such, but it sounds like it's worth waiting to see what upstream is going to do before committing to anything in EPEL and the Fedora stable releases. Is there any estimate of when that decision will be made? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Qwt and QwtPolar for Qt5?
I would like to create Qwt and QwtPolar packages for Qt5 and before opening the Bugzilla I wanted to check if there was any feedback on here. I have spec files and source RPMs available at: https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5.spec https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5-6.1.1-3.el6.src.rpm https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5.spec https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5-1.1.1-2.el6.src.rpm I'm primarily interested in the RHEL 6/7 and haven't tested this on Fedora, so if anyone is willing to build it and do some testing, then that would be helpful as well. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GCC issue?
I just submitted a re-build of ODB for GCC 4.9.2 in rawhide ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8051892 ) and it ran into an issue ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8051895 ). I don't have access to a machine with rawhide to do any more debugging, but I've included the pertinent output below and what's the recommend path for working on getting this resolved? Thanks, Dave libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I.. -I/usr/lib/gcc/x86_64-redhat-linux/4.9.2/plugin/include -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c validator.cxx -fPIC -DPIC -o .libs/validator.o validator.cxx:1575:1: internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1557 } ^ Please submit a full bug report, with preprocessed source if appropriate. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GCC issue?
On Thu, Nov 6, 2014 at 8:19 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Nov 06, 2014 at 07:58:01AM -0700, Dave Johansen wrote: I just submitted a re-build of ODB for GCC 4.9.2 in rawhide ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8051892 ) and it ran into an issue ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8051895 ). I don't have access to a machine with rawhide to do any more debugging, but I've included the pertinent output below and what's the recommend path for working on getting this resolved? Perhaps http://gcc.gnu.org/PR60871 , but without a preprocessed testcase it is hard to tell. You could either try local mock, or you could hack for a temporary build small *.spec file change that would BuildRequire: sharutils and run: make ... || tar cjf - /tmp/cc*.out | uuencode cc.tar.bz2 (that way you could download build.log and uudecode the tarball with the preprocessed source from it). As a workaround, supposedly -fno-devirtualize or -fno-devirtualize-speculatively options could help. I had actually turned off the use of devirtualization with GCC 4.9.0, but I guess that that is has cropped back up or wasn't fully resolved. http://pkgs.fedoraproject.org/cgit/odb.git/commit/?id=b9ca412b135ea0ef16d3b5428feec1bc42100b76 For ODB, I can continue turning of devirtualization, but I just wanted to make sure that the right thing was done from the GCC end of things and make sure that an issue is left around. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Questions about SCL during meeting (was: Anybody has something for agenda for Env-and-Stacks WG meeting today? (2014-09-09))
On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Sep 10, 2014 at 03:51:00PM +0200, Honza Horak wrote: However, there are and will be cases where somebody would like to create a non-SCL RPM depended on a software collection, which is something not solved properly yet and the solution might be quite different from collection to collection. This makes me kind of scared. I'm all for the first sort of software collection, but I think limiting this helps constrain the problem set. (Although I don't think such packages should be limited from, eg, Fedora Playground.) I'm not sure how/if this matters on Fedora, but for EL, being able to use devtoolset would be a big gain and would allow for inclusion of packages that require a newer compiler than gcc 4.4 that comes with RHEL 6 ( https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html ). ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Can 7 packages depend on Software Collections packages?
On Wed, Aug 27, 2014 at 6:22 AM, Karanbir Singh mail-li...@karan.org wrote: On 08/26/2014 11:07 PM, Eric Smith wrote: On Tue, Aug 26, 2014 at 3:08 PM, Stephen John Smoogen smo...@gmail.com wrote: No they can not. Every package we ship in EPEL must only rely on what is shipped in either EPEL or base RHEL (or CentOS as it doesn't have a ton of confusing channels). OK. I suppose I should ask the collections people whether a collection package for EL is allowed to depend on EPEL. the idea with SCL is that you extend a collection, or inherit another one by building your own collection. Its a oneway street, once you are in the scl lands. It depends on if you're talking about making an SCL or using one (like devtoolset). I previously asked about the concept of using devtoolset in particular ( https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html ) and think that it would be nice because it would allow for support of packages that can't be built with gcc 4.4 that comes with EL. One way to accomplish this would be to have an EPEL-DT repo that was built with the newer version of gcc that comes with devtoolset. It would be nice because it would allow developers to make use of it but wouldn't necessarily require that the user have a devtoolset subscription (which is my understanding of how devtoolset was meant to be used). Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Special mass rebuild
On Thu, Aug 21, 2014 at 10:05 PM, Ralf Corsepius rc040...@freenet.de wrote: On 08/22/2014 06:57 AM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Aug 2014 20:46:05 -0700 Dave Johansen davejohan...@gmail.com wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=7370474 There was a failure building odb during the rebuild. A later rebuild worked, but is this something I should worry about or file a report against? Thanks, Dave If you have fixed it then it should be fine. if its repeatable then you should look into whats broken and file bugs as appropriate It's an ICE (from https://kojipkgs.fedoraproject.org//work/tasks/ 3540/7383540/build.log): validator.cxx:1575:1: internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1556 } ^ I.e. if this breakdown is not deterministically repeatable in an otherwise identical configuration, the cause likely is a HW defect. My guess is that since the second build worked that it's not easily repeatable, if at all, so I'll just let it go. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Special mass rebuild
http://koji.fedoraproject.org/koji/taskinfo?taskID=7370474 There was a failure building odb during the rebuild. A later rebuild worked, but is this something I should worry about or file a report against? Thanks, Dave On Thu, Aug 14, 2014 at 9:47 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, It was requested in https://fedorahosted.org/rel-eng/ticket/5962 that we do a mass rebuild for Fedora 21 and 22 of all archful packages This is due to an ABI issue on s390/x and some gcc issues. we will start the mass rebuild on 2014-08-14. This is a heads up that it will be done in side tags and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7OhEAAoJEH7ltONmPFDRFoIP/3FU2oUlk1wKedi3cXoFPV1k bVbFqaeGLrCFoBXZpaag+Zm8gVrojAWNyXgVzzoLlsLhO+m25lkLsvEVnnCPojxG Ze/D0Lx4hZ1mMQ+PExSXDv9IDrYyjerCcdEaRNxvhOJ3TMw9JyH5MbSlZ5Rm1qPp EwBNKq/phT9POWrHCLI8efTerKJHYhIyAzxwJzektA3OMKLal90GBojWpy3lA5wF XP0Y2DGUDSoIqZcwKtzs1LNQazCy0JINGKm8jjtLG1FgLk0nqvNnC8uTr9nFFhkI J32C2PVq69gPaun1mnq8LNjVCqBwtR7jgqLcvhZzvb5do/i0EVDS0F+176e4eRQC iJJKoGa6sri14VENUQVOfBWqQgj+qKdBGH/NhE3qS6KR4UvpZNNIykVEONfiPCwT lBMtyVYgqnj/7E+MJD0Behe6BSxHPJNTWDi+zHOQBaMAugaXCQaQLizVydZ76hjK 5TJYLInJJ4fl8J5hvVpJTDNOisvTFFHZUtLZUQT79L2xjhc8+oaX0zYQ3cViaYsB wJmz73BdMsdEwKmhBVpTpXeZL4do6XxyACw/uabU3nZ74J58Lj/PFcW26ulTm7m2 Tk3z7zFjR0M0PZIFzzEiDJlaVHFvyxwabjMveRk5v5mgx3Jq6huJhERnZRhpDv5F bWwZzUlfNCYRNL6ZPn3P =tfVC -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1114497] New: odb package missing gcc-plugin
On Tue, Jul 1, 2014 at 10:04 PM, Dave Johansen davejohan...@gmail.com wrote: The simple solution to this is for me to just rebuild against 4.8.3, but upstream said that in Debian they package the GCC plugins in /usr/lib/gcc/.../x.y/plugin instead of /usr/lib/gcc/.../x.y.z/plugin so that it doesn't break when there are minor version upgrades like this. Is doing something like that possible in Fedora as well? Or should I just rebuild when there's a minor version change? Thanks, Dave I just did the rebuild and update request ( https://admin.fedoraproject.org/updates/odb-2.3.0-3.fc20?_csrf_token=7b20acd8c1590c3ef9ee27903c3ab123c6ed6cc3 ). Should I add a Requires for the current version of gcc to odb.spec? If so, is there an easy way to do that other than just hardcoding it in the file? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: [Bug 1114497] New: odb package missing gcc-plugin
The simple solution to this is for me to just rebuild against 4.8.3, but upstream said that in Debian they package the GCC plugins in /usr/lib/gcc/.../x.y/plugin instead of /usr/lib/gcc/.../x.y.z/plugin so that it doesn't break when there are minor version upgrades like this. Is doing something like that possible in Fedora as well? Or should I just rebuild when there's a minor version change? Thanks, Dave -- Forwarded message -- From: bugzi...@redhat.com Date: Mon, Jun 30, 2014 at 2:00 AM Subject: [Bug 1114497] New: odb package missing gcc-plugin To: davejohan...@gmail.com https://bugzilla.redhat.com/show_bug.cgi?id=1114497 Bug ID: 1114497 Summary: odb package missing gcc-plugin Product: Fedora Version: 20 Component: odb Assignee: davejohan...@gmail.com Reporter: steven.c...@gmail.com QA Contact: extras...@fedoraproject.org CC: davejohan...@gmail.com, lemen...@gmail.com Description of problem: Since the update to gcc to version 4.8.3, the gcc plugin that is packaged in odb remains in the 4.8.2 plugin directory and odb cannot be run because it is looking in the 4.8.3 plugin directory. Version-Release number of selected component (if applicable): odb 2.3.0-1 gcc 4.8.3-1 How reproducible: Run yum update This pulls in the latest gcc which breaks odb. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 Changes Freeze in two weeks - 2014-07-08
On Tue, Jun 24, 2014 at 4:34 AM, Jaroslav Reznik jrez...@redhat.com wrote: Greetings! Fedora 21 Changes Freeze is currently scheduled to no earlier than 2014-07-08 [1] and we're getting closer to this date. Btw this is also Fedora 21 Branch from Rawhide date. At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Freeze. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. [2] As Fedora 21 scope is really huge, progress at Changes Freeze will help us to think about where we are and what we can do for this release. This applies not only to change owners but to all other groups - especially from WGs and teams involved in Fedora re-design. Let us know if you're blocked, if you need any help etc. or just to say, hey, we're ready :). Jaroslav [1] https://fedoraproject.org/wiki/Releases/21/Schedule [2] http://bit.ly/f21changesfreeze ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce I'm not very familiar with the Fedora release schedule and how closely related it is with gcc, but in the odb package that I'm the maintainer for there appears to be a bug with the devirtualization that is claimed to be on the roadmap for a fix in 4.9.1 ( http://www.codesynthesis.com/pipermail/odb-users/2014-May/001851.html ). I currently have a workaround in odb that just disables the devirtualization ( http://pkgs.fedoraproject.org/cgit/odb.git/commit/?id=5549f93543ed60a7d2027d0eb932c8cf6737edb5 ), so should I just leave it that way and then remove that when 4.9.1 is finally released for F21 or what's the right way to handle that? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1106637] New: odb: FTBFS in rawhide
On Fri, Jun 13, 2014 at 10:17 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 23:48:10 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 20:01:19 -0700 Dave Johansen davejohan...@gmail.com wrote: On Wed, Jun 11, 2014 at 7:49 PM, Dave Johansen davejohan...@gmail.com wrote: I resolved the issue with ODB not building with gcc 4.9, but it appears that there's something going wrong with the ARM build. I don't have access to a Fedora 21 machine or ARM hardware to debug this issue, so does anyone have any ideas on what I can do to get the ARM build working on Fedora 21? Thanks, Dave Sorry for the multiple emails but I forgot to include the link to the failed build: Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=7038059 Failed ARM Build: https://kojipkgs.fedoraproject.org//work/tasks/8064/7038064/build.log Thanks, Dave /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.9.0/plugin/include/config/arm/arm.h has in it #include config/vxworks-dummy.h which i think either needs to be wrapped in an ifdef or the file needs to be provided. either way it is a gcc bug. gcc has been fixed, and i resubmitted your build, odb is now built Good to hear. Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: [Bug 1106637] New: odb: FTBFS in rawhide
I resolved the issue with ODB not building with gcc 4.9, but it appears that there's something going wrong with the ARM build. I don't have access to a Fedora 21 machine or ARM hardware to debug this issue, so does anyone have any ideas on what I can do to get the ARM build working on Fedora 21? Thanks, Dave -- Forwarded message -- From: bugzi...@redhat.com Date: Mon, Jun 9, 2014 at 9:55 AM Subject: [Bug 1106637] New: odb: FTBFS in rawhide To: davejohan...@gmail.com https://bugzilla.redhat.com/show_bug.cgi?id=1106637 Bug ID: 1106637 Summary: odb: FTBFS in rawhide Product: Fedora Version: rawhide Component: odb Assignee: davejohan...@gmail.com Reporter: den...@ausil.us QA Contact: extras...@fedoraproject.org CC: davejohan...@gmail.com, lemen...@gmail.com Blocks: 1105908 Your package odb failed to build from source in current rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=6972904 For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1105908 [Bug 1105908] Fedora 21 Mass Rebuild FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1106637] New: odb: FTBFS in rawhide
On Wed, Jun 11, 2014 at 7:49 PM, Dave Johansen davejohan...@gmail.com wrote: I resolved the issue with ODB not building with gcc 4.9, but it appears that there's something going wrong with the ARM build. I don't have access to a Fedora 21 machine or ARM hardware to debug this issue, so does anyone have any ideas on what I can do to get the ARM build working on Fedora 21? Thanks, Dave Sorry for the multiple emails but I forgot to include the link to the failed build: Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=7038059 Failed ARM Build: https://kojipkgs.fedoraproject.org//work/tasks/8064/7038064/build.log Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Clang package doesn't work on Amazon Linux
On Mon, Apr 28, 2014 at 1:11 PM, Dave Johansen davejohan...@gmail.comwrote: On Mon, Apr 28, 2014 at 12:46 PM, Tyler Brock tyler.br...@gmail.comwrote: Update: testing packages work as advertised. Just wanted to keep you updated and thank you again. Will this go into the standard EPEL automatically or do we need to do something else at this point? Bodhi (the Fedora/EPEL update publication system) uses karma and delay times for testing of updates. You can read the details here ( http://fedoraproject.org/wiki/How_to_test_updates ), but basically, if the package gets enough karma it can be pushed out sooner but otherwise it can be rolled out to the official repos 14 days after being available in the testing repos. So once that time has passed, I'll put in the request that it be moved to the official repos. This update has been moved to the stable repo. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Amazon Linux and
On Thu, May 8, 2014 at 7:36 PM, Christopher Meng cicku...@gmail.com wrote: On Fri, May 9, 2014 at 9:57 AM, Matthew Miller mat...@fedoraproject.org wrote: Quite a lot; they make no attempt at compatibility. I think I'd respond with that. EPEL packages might work on Amazon Linux, and they might not. Matthew, thanks for your reply. I took the info from the bug, and found that pcre on amazon linux is 8.x, quite fresh, RHEL only has 7.x version for customers. So I believe it's worthwhile to add some notes on EPEL page to alert the incompatibility. The EPEL is designed to support RHEL and its derivatives. Amazon Linux seems to have started with EL6 as a base to at least some extent but has since evolved significantly. They do have a FAQ ( https://aws.amazon.com/amazon-linux-ami/faqs/ ) and it does reference the EPEL and how to use it, but it also talks about how it is updated to include the latest components on a regular basis. It also talks about how there are several packages that are in Amazon Linux that are newer than those in the EL6 and the EPEL. Honestly, I think that the documentation of the issues with the EPEL packages should really go on the Amazon side of things. They're the ones that are deviating from EL and they should be letting their users know about that instead of just saying you can use the packages from EPEL. I guess that doesn't preclude the EL/EPEL community from trying to be good citizens and help users out with a little documentation, but I don't think any significant amount of effort should be put into it. Also, I'm not all that familiar with EC2 but it does appear that they do have a EL offering ( http://aws.amazon.com/partners/redhat/ ) that should be fully compatible with EPEL and that should definitely be proposed to anyone that runs into issues using the EPEL. It also looks like there's options for using CentOS as well ( http://wiki.centos.org/Cloud/AWS ), so I think there are plenty of good options for those wanting to use the EPEL and it just may not be that Amazon Linux is high on that list. Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Clang package doesn't work on Amazon Linux
On Wed, Apr 23, 2014 at 7:28 AM, Tyler Brock tyler.br...@gmail.com wrote: Tested it on the latest amazon linux and it works perfectly. Thank you! What are the next steps to get the change into EPEL? -Tyler I'll add the patch to the git branch of llvm for EPEL6 and do the build. It will then be available in the testing repos and I can then transfer it to the release repos 14 days later. The patch should also be submitted upstream to fix the issue globally and maybe it could even be considered as part of the upcoming 3.4.1 release. Dave ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Clang package doesn't work on Amazon Linux
On Mon, Apr 21, 2014 at 11:40 AM, Tyler Brock tyler.br...@gmail.com wrote: Hey Dave, hope you had a nice weekend. Any update on the rpms? Repos for x86 32-bit and 64-bit can be found at: http://daveisfera.fedorapeople.org/yum/llvm-3.4/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Clang package doesn't work on Amazon Linux
On Tue, Apr 1, 2014 at 1:25 PM, Anssi Johansson e...@miuku.net wrote: 1.4.2014 23.11, Tyler Brock kirjoitti: Thanks so much for looking into this Dave. Yes, libstdc++ was installed. It might be worth mentioning that the Amazon-provided libstdc++-devel is 4.6.3-3.10.amzn1, and it doesn't seem to provide /usr/include/c++/4.4.4/iostream like the CentOS version does. What does running yum provides /usr/include/c++/4.4.4/iostream on one of these Amazon boxes output? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Clang package doesn't work on Amazon Linux
On Tue, Mar 25, 2014 at 2:08 PM, Tyler Brock tyler.br...@gmail.com wrote:
Here is a gist containing the output of attempting to compile the program
after installing the clang package on each platform I mentioned:
https://gist.github.com/TylerBrock/9771402
-Tyler
On Tue, Mar 25, 2014 at 4:54 PM, Tyler Brock tyler.br...@gmail.comwrote:
To my knowledge it was originally based on CentOS but it has since
diverged.
It may be useful to mention that this same issue affects multiple Red Hat
derivatives (including RHEL 6.4 itself) and not just Amazon Linux. I
attempted the same process on Red Hat 6.4, Fedora 20, and Amazon Linux
2013.09, and it fails on all three of these distributions with the same
errors. In fact, the only distribution on which I have been able to get it
to work is CentOS 6.4.
-Tyler
On Tue, Mar 25, 2014 at 1:46 AM, Dave Johansen davejohan...@gmail.comwrote:
On Mon, Mar 24, 2014 at 6:38 PM, Tyler Brock tyler.br...@gmail.comwrote:
Hey Everyone,
I've been trying to use clang package on Amazon linux via EPEL and have
installed version 3.4-9.el6 yet am unable to compile even the simplest of
programs:
#include iostream
int main(){
std::cout Hello World std::endl;
}
Saving the above into a file named test.cpp and compiling with clang++
test.cpp produces the following error:
test.cpp:1:10: fatal error: 'iostream' file not found
#include iostream
^
1 error generated.
When attempting the same with gcc (g++) it works as expected so It
seems like the clang compiler cannot find the required C++ headers and
library files.
I have contacted Amazon AWS support and they verified that the issue is
reproducible by them running the latest version of Amazon Linux with
updated packages from EPEL.
I've tried installing devel headers for clang and multiple versions of
libstd++ which seem to be placed in /usr/include/c++/gcc-version but
which, when used by gcc, do not require the path to them be specified at
all. It just works.
I have a feeling the clang package is not built to work properly with
Amazon Linux as C++ headers and library files (for either for libc++ or
libstdc++) such as iostream should be found by default. Any help in
resolving the matter would be greatly appreciated.
It may also be worth noting that on CentOS the clang package seems to
work fine.
I'm the maintainer of clang in the EPEL, but honestly I know nothing
about Amazon Linux. Is it an EL variant or claim any sort of
compatibility with EL? A known issue even on EL/CentOS with clang is that
much of the C++11/14 support won't work because of the old version of the
standard library that is available on EL. It sounds like this isn't your
issue, but if C++11/14 support is desired, then the devtoolset (
http://rhn.redhat.com/errata/RHEA-2013-1226.html ) is the best route to
follow.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
I've tested on CentOS 6.5, RHEL 6.5 and RHEL 6.4 and all of them work. Do
you have the package libstdc++-devel installed? That package not being
installed is the only thing that I can think of that might be causing this
problem and maybe that package should be listed as a requires in the .spec
for clang.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Clang package doesn't work on Amazon Linux
On Mon, Mar 24, 2014 at 6:38 PM, Tyler Brock tyler.br...@gmail.com wrote:
Hey Everyone,
I've been trying to use clang package on Amazon linux via EPEL and have
installed version 3.4-9.el6 yet am unable to compile even the simplest of
programs:
#include iostream
int main(){
std::cout Hello World std::endl;
}
Saving the above into a file named test.cpp and compiling with clang++
test.cpp produces the following error:
test.cpp:1:10: fatal error: 'iostream' file not found
#include iostream
^
1 error generated.
When attempting the same with gcc (g++) it works as expected so It seems
like the clang compiler cannot find the required C++ headers and library
files.
I have contacted Amazon AWS support and they verified that the issue is
reproducible by them running the latest version of Amazon Linux with
updated packages from EPEL.
I've tried installing devel headers for clang and multiple versions of
libstd++ which seem to be placed in /usr/include/c++/gcc-version but
which, when used by gcc, do not require the path to them be specified at
all. It just works.
I have a feeling the clang package is not built to work properly with
Amazon Linux as C++ headers and library files (for either for libc++ or
libstdc++) such as iostream should be found by default. Any help in
resolving the matter would be greatly appreciated.
It may also be worth noting that on CentOS the clang package seems to work
fine.
I'm the maintainer of clang in the EPEL, but honestly I know nothing about
Amazon Linux. Is it an EL variant or claim any sort of compatibility with
EL? A known issue even on EL/CentOS with clang is that much of the C++11/14
support won't work because of the old version of the standard library that
is available on EL. It sounds like this isn't your issue, but if C++11/14
support is desired, then the devtoolset (
http://rhn.redhat.com/errata/RHEA-2013-1226.html ) is the best route to
follow.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL appdata-tools in EL 7 beta?
I just tried building qt-creator for EPEL 7 beta, but it failed because the appdata-tools package doesn't seem to be available. Is that not part of EL/EPEL 7 beta? Should I just remove the use of it from the .spec? Or is there a better solution? Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 branch requests
On Tue, Mar 11, 2014 at 8:02 AM, Paul Howarth p...@city-fan.org wrote: On 11/03/14 14:59, Dave Johansen wrote: On Sun, Feb 23, 2014 at 10:22 AM, Kevin Fenzi ke...@scrye.com mailto:ke...@scrye.com wrote: On Sun, 23 Feb 2014 18:10:10 +0100 Dominik 'Rathann' Mierzejewski domi...@greysector.net mailto:domi...@greysector.net wrote: Hello everyone, are the EPEL7 branch requests on https://fedoraproject.org/wiki/EPEL/epel7/Requests still being processed or are we back to the standard branch requests in the original review bugs? Yes they are. I'll look at processing it later today if no one beats me to it. I added the packages that I maintain to the list and they've been added, but do I have to kick off the builds on koji? Or is that done automatically? You have to do the builds yourself. Sounds good. Thanks, Dave ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 branch requests
On Sun, Feb 23, 2014 at 10:22 AM, Kevin Fenzi ke...@scrye.com wrote: On Sun, 23 Feb 2014 18:10:10 +0100 Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: Hello everyone, are the EPEL7 branch requests on https://fedoraproject.org/wiki/EPEL/epel7/Requests still being processed or are we back to the standard branch requests in the original review bugs? Yes they are. I'll look at processing it later today if no one beats me to it. I added the packages that I maintain to the list and they've been added, but do I have to kick off the builds on koji? Or is that done automatically? Thanks, Dave ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Issue with koji?
On Fri, Feb 21, 2014 at 7:09 AM, Jeff Sheltren j...@tag1consulting.comwrote: On Thu, Feb 20, 2014 at 7:47 PM, Dave Johansen davejohan...@gmail.comwrote: Yes, waiting did work for that issue ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195156.html), but this is another issue and appears to that the building of the source .rpm isn't working properly for some reason. From root.log in the failed build ( http://kojipkgs.fedoraproject.org//work/tasks/8044/6488044/root.log) : -- DEBUG util.py:281: http://kojipkgs.fedoraproject.org/repo/rhel/rhel-i386-server-6/getPackage/openldap-2.4.23-32.el6_4.1.i686.rpm: [Errno 14] HTTP Error 404 - Not Found DEBUG util.py:281: Trying other mirror. DEBUG util.py:281: Error downloading packages: DEBUG util.py:281:openldap-2.4.23-32.el6_4.1.i686: failed to retrieve openldap-2.4.23-32.el6_4.1.i686.rpm from build DEBUG util.py:281: error was [Errno 14] HTTP Error 404 - Not Found DEBUG util.py:371: Child return code was: 1 -- It had an error installing openldap. There was actually an openldap release for EL6 the day before this build ran, so it may be possible that whatever mirror/RHN Koji uses was syncing when this ran. Pure speculation on my part, not knowing the details of the Koji setup. Do you get the same error if you attempt a rebuild? Doh! The original email in this chain was a copy and paste/stupid user error on my part. No, I no longer get that issue with the llvm build and like Kevin pointed out, just waiting worked. But I sent two emails this month with very similar titles and I accidentally copied the wrong one in the original email. The correct one is https://lists.fedoraproject.org/pipermail/devel/2014-February/195687.htmland the failed build is http://koji.fedoraproject.org/koji/taskinfo?taskID=6542755 with an issue during the creation of the source rpm. Any ideas on what may be causing this? Thanks, Dave ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Issue with koji?
On Thu, Feb 20, 2014 at 10:26 AM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 20 Feb 2014 07:54:07 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm trying to do a build on koji and ran into an error during the mock buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038 ). I posted previously on the Fedora devel mailing list but haven't figured it out yet ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html ). Is this something wrong with koji? Or with the EL6/EPEL packages? I answered you on the devel list: https://lists.fedoraproject.org/pipermail/devel/2014-February/195114.html Did a more recent build also fail? Please resubmit. Yes, waiting did work for that issue ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195156.html), but this is another issue and appears to that the building of the source .rpm isn't working properly for some reason. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Issue with koji?
I'm trying to do a build on koji and ran into an error during the mock buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038 ). I posted previously on the Fedora devel mailing list but haven't figured it out yet ( https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html ). Is this something wrong with koji? Or with the EL6/EPEL packages? Thanks, Dave ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Issue with koji build of qt-creator for EL6?
On Tue, Feb 18, 2014 at 10:57 AM, Dave Johansen davejohan...@gmail.comwrote: On Tue, Feb 18, 2014 at 8:19 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 18 Feb 2014 08:06:53 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm trying to build qt-creator 3.0.1 for EL6 and have successfully done it on my own machine but I'm having an issue when building it with koji. It appears that it's not finding one of the files ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6542755 ), but it's checked into the git branch for EL6 and I can't tell what the problem is. Any suggestions? Thanks, Dave from the root.log DEBUG util.py:281: error: Unable to open /builddir/build/SOURCES/qt-creator-Fedora-privlibs: No such file or directory DEBUG util.py:281: error: query of specfile qt-creator.spec failed, can't parse DEBUG util.py:281: Could not execute sources: Could not parse the spec, exited 1 you forgot to commit the qt-creator-Fedora-privlibs file I believe that I committed, because if I didn't then why does it show up in the git repo? http://pkgs.fedoraproject.org/cgit/qt-creator.git/tree/?h=el6 Yes, it's been committed: [dlj@JohansenDev qt-creator]$ git branch * el6 master [dlj@JohansenDev qt-creator]$ git status # On branch el6 nothing to commit (working directory clean) [dlj@JohansenDev qt-creator]$ ls -lh qt-creator-Fedora-privlibs -rw-r--r--. 1 dlj dlj 2.8K Jan 7 22:56 qt-creator-Fedora-privlibs Any ideas on what the issue could be? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
