Proposal to (formally/easily) allowing multiple versions of the same library installable
> > > Who will review the new packages of these multiple versions? If we don't review it I think it's horrible to carry obsolete stuffs. Maintaining several version of the same library is not easy as you think, basically once a developer wants to install version X while then another people want to deploy things based on version Y, how to crack this nut? You can't just care about runtime. And, not all upstream use symbol versioning, and I don't think enforcing this could bring in any improvement for some upstream as they even don't care about this. I only see Gentoo and it's derivatives give users choice to install different versions they want, but Gentoo has different concept while Fedora releases precompiled binaries, you can't control this actually. -- Yours sincerely, Christopher Meng http://cicku.me -- 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: Proposal to (formally/easily) allowing multiple versions of the same library installable
On 02/14/2015 09:38 AM, Christopher Meng wrote: Who will review the new packages of these multiple versions? The process having been applied so far is the "adding a compat-package". In most cases this basically means to fork-off a package from an existing package and have this package reviewed. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 22 Branched 20150214 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 22 Branched 20150214. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: lorax - 20150207: 22.4-2, 20150214: 22.5-2 python-blivet - 20150207: 0.76-1, 20150214: 1.0-1 anaconda - 20150207: 22.18-1, 20150214: 22.19-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/22 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Base https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Server https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_22_Branched_20150214_Download Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: 3 days without pushes ?
On Thu, Feb 12, 2015 at 7:53 PM, Sérgio Basto wrote: > On Qui, 2015-02-12 at 14:41 -0500, Corey Sheldon wrote: >> Aka patience and to be totally honest and blunt, if you have a >> alpha/beta tester group and or a solid forum/mailing list with updates >> to status this should seriously not be a setback 3 weeks on the other >> hand might qualify.Appreciate the eagerness to partake in >> development /packaging but things happen from time to time learn to >> roll with the tides as they say > > yeah, but we should have some regularity, I don't like waiting without > knowing the delay, in this case is pushing to stable, is just for my > organization, to see what is in stable and what let in testing, and I > have been patient. Ultimately packages have to be signed, for that to happen the key needs to be unlocked by a human so it's a manual process for security reasons. We generally try and push updates daily but at times travel/sickness and issues with infrastructure cause this to be delayed. This is regrettable but it's a fact of life. There's no SLA as to when and why the updates happen it is after all a community distro. > But when someone else send a package to testing and I want test it, if > we don't have a push to testing, force me download packages manually . > The point here is push to testing should be more quickly than push to > stable . The updates whether to testing or to stable is a manual process to unlock the signing key. It also has to be synced out to mirrors, it's not the quickest process and the team of people that do them aren't paid to do it as their only job hence the reason it happens daily. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
taskotron failiure
Updates seem to have been pushed out now, thanks!. But I see a different problem with my update. Taskotron failure which I don't understand: not ok - depcheck for Bodhi update systemd-216-20.fc21 # FAIL --- arch: x86_64 details: output: |- Build systemd-216-20.fc21 failed depcheck package libgudev1-216-20.fc21.i686 requires systemd = 216-20.fc21, but none of the providers can be installed systemd-216-20.fc21.i686 has inferior architecture systemd-216-20.fc21.i686 has inferior architecture package systemd-python-216-20.fc21.i686 requires systemd = 216-20.fc21, but none of the providers can be installed systemd-216-20.fc21.i686 has inferior architecture systemd-216-20.fc21.i686 has inferior architecture package systemd-compat-libs-216-20.fc21.i686 requires systemd-libs = 216-20.fc21, but none of the providers can be installed systemd-libs-216-20.fc21.i686 has inferior architecture systemd-libs-216-20.fc21.i686 has inferior architecture package systemd-216-20.fc21.i686 requires systemd-libs = 216-20.fc21, but none of the providers can be installed systemd-libs-216-20.fc21.i686 has inferior architecture systemd-libs-216-20.fc21.i686 has inferior architecture package libgudev1-devel-216-20.fc21.i686 requires libgudev1 = 216-20.fc21, but none of the providers can be installed libgudev1-216-20.fc21.i686 has inferior architecture libgudev1-216-20.fc21.i686 has inferior architecture package systemd-devel-216-20.fc21.i686 requires systemd = 216-20.fc21, but none of the providers can be installed systemd-216-20.fc21.i686 has inferior architecture systemd-216-20.fc21.i686 has inferior architecture item: systemd-216-20.fc21 outcome: FAILED summary: systemd-216-20.fc21 into F21 stable type: bodhi_update ... I agree i686 is inferior, but I thought we still allow it :) A related problem is that I don't see any way to override this taskotron failure (let's say that I was certain that this is not an issue). Status is 'testing', Requested 'stable', but the message says that the automatic push was disabled, so the update seems to be stuck in a limbo. [1] https://admin.fedoraproject.org/updates/FEDORA-2015-1793/systemd-216-20.fc21 -- 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: rawhide report: 20150210 changes
> > ghc-7.8.4-41.fc22 > > - > > Oh dear - gcc5 changes all the ghc library ABI hashes. Sorry my initial hunch seems incorrect. AFAICT now the ABI changes are due to -40 having been built with make -j16 on i686 and x86_64. In future I will use -j4 or less again. Jens -- 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: rawhide report: 20150210 changes
Am 14.02.2015 um 17:02 schrieb Jens Petersen: ghc-7.8.4-41.fc22 - Oh dear - gcc5 changes all the ghc library ABI hashes. Sorry my initial hunch seems incorrect. AFAICT now the ABI changes are due to -40 having been built with make -j16 on i686 and x86_64. In future I will use -j4 or less again don't get me wrong but if the number of threads of the complier changes ABI of the result the problem is way larger - the only thing which is allowed to happen by -j16 or higher is a failed build caused by ressource constraints and OOM signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Does clang/llvm need to be rebuilt because of the gcc 5.0 upgrade?
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? 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
include-what-you-use not building on ARM
I'm working on packaging include-what-you-use and it's not building on ARM. I don't have access to ARM hardware to do the necessary debugging, so I just opened a bugzilla to document it ( https://bugzilla.redhat.com/show_bug.cgi?id=1192713 ). Hopefully, someone can figure out what the problem is and submit a patch. 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: [Test-Announce] Fedora 22 Branched 20150214 nightly compose nominated for testing
adamw...@fedoraproject.org composed on 2015-02-14 04:21 (UTC-0800): > Announcing the creation of a new nightly release validation test event > for Fedora 22 Branched 20150214. Please help run some tests for this > nightly compose if you have time. For more information on nightly > release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > Notable package version changes: > lorax - 20150207: 22.4-2, 20150214: 22.5-2 > python-blivet - 20150207: 0.76-1, 20150214: 1.0-1 > anaconda - 20150207: 22.18-1, 20150214: 22.19-1 > Test coverage information for the current release can be seen at: > https://www.happyassassin.net/testcase_stats/22 > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Summary Maybe I've been blinded by the mass of data those pages contain and the low contrast/legibility[1] of the links, but I didn't spot any image download links. Maybe others have them committed to memory, but I don't. http://mirrors.kernel.org/fedora/development/22/i386/os/images/ has only boot.iso. Where else should I be looking? [1] http://juicystudio.com/services/luminositycontrastratio.php The contrast ratio is: 4.38:1 Passed at Level AA for large text only: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours (#fff and #337ACC). [2] Font size in P/links is 15.2px, 57.8% of my browser default if not zoomed, so not large text, via the 76% CSS rule on body. http://fm.no-ip.com/Auth/area76.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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: [Test-Announce] Fedora 22 Branched 20150214 nightly compose nominated for testing
On Sat, 2015-02-14 at 13:04 -0500, Felix Miata wrote: > adamw...@fedoraproject.org composed on 2015-02-14 04:21 (UTC-0800): > > > Announcing the creation of a new nightly release validation test > > event for Fedora 22 Branched 20150214. Please help run some tests > > for this nightly compose if you have time. For more information on > > nightly release validation testing, see: > > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > > Notable package version changes: > > lorax - 20150207: 22.4-2, 20150214: 22.5-2 > > python-blivet - 20150207: 0.76-1, 20150214: 1.0-1 > > anaconda - 20150207: 22.18-1, 20150214: 22.19-1 > > > Test coverage information for the current release can be seen at: > > https://www.happyassassin.net/testcase_stats/22 > > > You can see all results, find testing instructions and image > > download locations, and enter results on the Summary page: > > > https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150214_Summary > > > > Maybe I've been blinded by the mass of data those pages contain and > the low > contrast/legibility[1] of the links, but I didn't spot any image > download > links. Ah, I need to change the text in the email - I forgot the Summary page doesn't include the instructions section. You can find the instructions, including a table of download links, on any of the individual pages. It would be easy to have the Summary page include the same section, but I think the original idea of the Summary page was to be 'just the data'. I could look at including it in a 'collapsed-by-default' section, I guess. Do note my follow-up email about this compose being DOA, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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?
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. Jakub -- 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?
On Sat, Feb 14, 2015 at 11:33 AM, Jakub Jelinek 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? 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 clang/llvm need to be rebuilt because of the gcc 5.0 upgrade?
On Sat, Feb 14, 2015 at 11:38:13AM -0700, Dave Johansen wrote: > On Sat, Feb 14, 2015 at 11:33 AM, Jakub Jelinek 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. Jakub -- 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: another dnf kernel issue?
- Original Message - > From: "James Antill" > To: "Radek Holy" > Cc: ndbeck...@gmail.com, "Development discussions related to Fedora" > > Sent: Friday, February 13, 2015 8:28:44 PM > Subject: Re: another dnf kernel issue? > > On Tue, 2015-02-10 at 04:01 -0500, Radek Holy wrote: > > > TBH, I don't know whether we should extend the forms of package > > specifications to support your case. The current behaviour seems to be > > safer to me. I mean, if we improve it, user wouldn't be able to query > > just package names as easily as now. > > Safer? I can't think how. > FWIW, in yum we did it the other way and added install-n, remove-n for > just operating on the names of packages. Seemed less confusing if you > want to force it, and did what people expected. YMMV. With the current syntax, you can limit the globs to package names and still you can append version or architecture specifications (globs or not). So there is lower probability that you select packages that you didn't want to select (e.g. packages containing numbers in their name). That's why I consider it safer. So with our syntax you can more easily express yourself and so far I don't know about anything that can be expressed via YUM's globs but not via DNF's. And also we don't need yet another command. Anyway, I'm not trying to defend the current DNF syntax. This is just my opinion. And TBH I didn't think about it too much. I don't think this discussion is very much needed. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- 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: another dnf kernel issue?
- Original Message - > From: "Radek Holy" > To: "James Antill" > Cc: "Development discussions related to Fedora" > > Sent: Saturday, February 14, 2015 7:53:50 PM > Subject: Re: another dnf kernel issue? > > - Original Message - > > From: "James Antill" > > To: "Radek Holy" > > Cc: ndbeck...@gmail.com, "Development discussions related to Fedora" > > > > Sent: Friday, February 13, 2015 8:28:44 PM > > Subject: Re: another dnf kernel issue? > > > > On Tue, 2015-02-10 at 04:01 -0500, Radek Holy wrote: > > > > > TBH, I don't know whether we should extend the forms of package > > > specifications to support your case. The current behaviour seems to be > > > safer to me. I mean, if we improve it, user wouldn't be able to query > > > just package names as easily as now. > > > > Safer? I can't think how. > > FWIW, in yum we did it the other way and added install-n, remove-n for > > just operating on the names of packages. Seemed less confusing if you > > want to force it, and did what people expected. YMMV. > > With the current syntax, you can limit the globs to package names and still > you can append version or architecture specifications (globs or not). So > there is lower probability that you select packages that you didn't want to > select (e.g. packages containing numbers in their name). That's why I > consider it safer. > > So with our syntax you can more easily express yourself and so far I don't > know about anything that can be expressed via YUM's globs but not via DNF's. > And also we don't need yet another command. > > Anyway, I'm not trying to defend the current DNF syntax. This is just my > opinion. And TBH I didn't think about it too much. I don't think this > discussion is very much needed. Feel free to correct me and explain me why this issue is important. It's definitely possible that I've missed something. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
what is, regarding to std::string and std::list, plan to rebuild packages and better procedures?
In my case, I was updating coin-or packages when one of then started failing at link time, only on i686, like this: undefined reference to `CoinMessageHandler::operator<<(std::__cxx11::basic_string, std::allocator > const&)' I tried to, temporarily fix it by, only on i686 building with "-D_GLIBCXX_USE_CXX11_ABI=0" in CXXFLAGS. It did work on a clean mock chroot, but would fail with a core dump during %check in koji. So, I reverted it as it looked bad, and started "bootstraping" again all packages, but now, the second package in the bootstrap process fails its %check like this: Testing OsiRowCut with OsiTestSolverInterface *** Error in `/builddir/build/BUILD/Osi-0.107.2/test/.libs/lt-unitTest': munmap_chunk(): invalid pointer: 0x7fbc26a144f0 *** === Backtrace: = /usr/lib64/libc.so.6(+0x7a00d)[0x7fbc2611600d] /usr/lib64/libc.so.6(cfree+0x1a8)[0x7fbc26122568] /builddir/build/BUILD/Osi-0.107.2/test/.libs/lt-unitTest(_ZN9CoinErrorD1Ev+0x1d)[0x416b1d] /usr/lib64/libstdc++.so.6(+0x8d66f)[0x7fbc26a1266f] /usr/lib64/libCoinUtils.so.3(_ZN16CoinPackedVector15gutsOfSetVectorEiPKiPKdbPKc+0x65c)[0x7fbc271fc34c] /builddir/build/BUILD/Osi-0.107.2/src/OsiCommonTest/.libs/libOsiCommonTests.so.1(_Z17OsiRowCutUnitTestPK18OsiSolverInterfaceRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x34b0)[0x7fbc276f3600] Thanks, Paulo -- 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 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 > 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
Re: include-what-you-use not building on ARM
On Sat, 14 Feb 2015 09:27:44 -0700 Dave Johansen wrote: > I'm working on packaging include-what-you-use and it's not building > on ARM. I don't have access to ARM hardware to do the necessary > debugging, so I just opened a bugzilla to document it ( > https://bugzilla.redhat.com/show_bug.cgi?id=1192713 ). Hopefully, > someone can figure out what the problem is and submit a patch. > Thanks, > Dave Not sure it is the complete problem warning: unknown platform, assuming -mfloat-abi=soft warning: unknown platform, assuming -mfloat-abi=soft we build everything with -mfloat-abi=hard so things will be incompatible Dennis -- 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: Un-retiring ice and mumble?
Carlos O'Donell wrote: > Devel, > > I would like to un-retire mumble, but that requires ice. > > I've just fixed ice to compile on f21 without much effort. > So I think I'll un-retire ice and mumble and maintain them > unless anyone objects. > > Is there any reason ice was orphaned and retired other than > lack of interest? > > Cheers, > Carlos. I can confirm that mumble builds on F21 and the client seems to work (I haven't really exercised it fully, or anything else at all) after updating it to the current release 1.2.8. The patch is a bit long to include inline, so it's here: https://gist.github.com/kythyria/a7474d32daa994a781c2 I disregarded the retiring commit, changed the version to 1.2.8, and removed a patch that was already merged upstream and thus causing patch(1) to complain. -- 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: [Test-Announce] Fedora 22 Branched 20150214 nightly compose nominated for testing
On Sat, Feb 14, 2015 at 10:21 AM, Adam Williamson wrote: > Do note my follow-up email about this compose being DOA, though. Dang! Any ETA for a live one? I have a gcc "bug" I want to troubleshoot. I've got a huge compile that works with F21 but died painfully with Rawhide a few days back. -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- 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: rawhide report: 20150210 changes
> Am 14.02.2015 um 17:02 schrieb Jens Petersen: > > AFAICT now the ABI changes are due to -40 having > > been built with make -j16 on i686 and x86_64. > > > > In future I will use -j4 or less again > > don't get me wrong but if the number of threads of the complier changes > ABI of the result the problem is way larger It is a ghc buildsystem issue not a compiler issue. But yes it would be good to fix this upstream. -- 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: F-22 Branched report: 20150214 changes
[i686] > requires ghc(base-4.7.0.2-6d16fd65767daf67b7606bd63b471328) [x86_64] > requires ghc(base-4.7.0.2-cb23b5265b6e147094c0cd9ac819acb1) I fixed the ghc ABI hash breakage (caused by ghc-7.8.4-40 -> ghc-7.8.4-41) for F22 and F23 so the next reports should be better, and also got bustle to build. Jens -- 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: [Test-Announce] Fedora 22 Branched 20150214 nightly compose nominated for testing
On Sat, 2015-02-14 at 18:30 -0800, M. Edward (Ed) Borasky wrote: > On Sat, Feb 14, 2015 at 10:21 AM, Adam Williamson < > adamw...@fedoraproject.org> wrote: > > > Do note my follow-up email about this compose being DOA, though. > > Dang! Any ETA for a live one? I have a gcc "bug" I want to > troubleshoot. I've got a huge compile that works with F21 but died > painfully with Rawhide a few days back. 02-10 was the last good nightly. I happen to have a download table for it for...reasons... https://stg.fedoraproject.org/wiki/Template:Fedora_22_Rawhide_20150210_Download you can just install that and update. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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 or dnf in the Fedora 22 Docker base image?
Right now, the fedora:rawhide image on Docker Hub uses yum instead of dnf, as does the Fedora 21 release. Is there any plan to switch this release over to dnf? I'm in the process of refactoring my remix - big pieces of it are going into Docker images. I'm wondering if it's worth porting the main workstation to dnf if the Docker pieces will still be on yum. -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
