Re: %py3_install fails to accept arguments
On 08/24/2017 07:48 PM, Juan Orti Alcaine wrote: 2017-08-24 9:54 GMT+02:00 Juan Orti Alcaine : Hi, I'm getting failed builds [1] in rawhide and f27 because the macro %py3_install fails when called with arguments. It was fine until f26. The package is rhythmbox-ampache, and I call the macro like this: %global py_install_args --no-glib-compile-schemas Enquoting the value seems to fix it !? %global py_install_args "--no-glib-compile-schemas" Sorry I missed the initial email on this because the subject didn't seem like there'd be anything rpm-related inside. Previously working macros now reporting "invalid option -- '-'" is a side-effect of macro argument expansion. For the impatient, the solution is NOT to quote, but use a '--' to indicate end of macro options in the caller. This is compatible with older versions of rpm too. Ie use: %py3_install -- %py_install_args The longer version for the less impatient, using a simplified version of %py3_install as an example: --- %define py3_install()\ %{__python3} %{?py_setup_args} install %{?*} %global py_install_args --no-glib-compile-schemas %py3_install %py_install_args --- In older versions of rpm, %py3_install would receive a literal "%py_install_args" as it's first argument, ie %{1}. This would then get expanded *inside* the %py3_install macro via the %{?*}. In the new world order, any macros in the arguments are expanded *before* executing %py3_install, so it's called as if you had written %py3_install --no-glib-compile-schemas ... and now the macro engine thinks --no-glib-compile-schemas is supposed to be an option to the %py3_install macro itself and you get an error about invalid option. Older rpm versions will give the invalid option error in this situation too. As already mentioned, the simple fix that is also compatible with older versions too is to use '--' to indicate end of macro arguments in the caller to remove any ambiguity on whose options these are. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Switch libidn-using applications to IDNA2008
On Fri, Aug 25, 2017 at 08:24:30AM +0200, Jan Kurik wrote: > = Proposed System Wide Change: Switch libidn-using applications to IDNA2008 = > https://fedoraproject.org/wiki/Changes/IDNA2008 > > Change owner(s): > * Nikos Mavrogiannopoulos > * Robert Scheck > > The proposed change is about deprecating libidn, which supports > IDNA2003, and switch all applications using libidn, to libidn2 2.0.0, > which supports IDNA2008. Are the issues with systemd+libidn2 resolved? This is critical chain, after all. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: Switch libidn-using applications to IDNA2008
= Proposed System Wide Change: Switch libidn-using applications to IDNA2008 = https://fedoraproject.org/wiki/Changes/IDNA2008 Change owner(s): * Nikos Mavrogiannopoulos * Robert Scheck The proposed change is about deprecating libidn, which supports IDNA2003, and switch all applications using libidn, to libidn2 2.0.0, which supports IDNA2008. == Detailed Description == Internationalized domain names exist for quite some time (IDNA2003), although the protocols describing them have evolved in an incompatible way (IDNA2008). These incompatibilities will prevent applications written for IDNA2003 to access certain problematic domain names defined with IDNA2008, e.g., faß.de is translated to domain xn--fa-hia.de with IDNA2008, while in IDNA2003 it is translated to fass.de domain. That not only causes incompatibility problems, but may be used as an attack vector to redirect users to different web sites. The proposed change is about deprecating libidn, which supports IDNA2003, and switch all applications using libidn, to libidn2 2.0.0, which supports IDNA2008. The switch should be transparent as the libidn2 library is API compatible. Note that even in the web browsers, field there is much confusion on the topic. Chromium appears to use IDNA2008 transitional (i.e., IDNA2003 mapping for the problematic characters), while Firefox and Safari have already moved to IDNA2008. For more information see: * http://nmav.gnutls.org/2017/04/the-mess-with-internationalized-domain.html * https://www.plesk.com/blog/what-is-the-problem-with-s/ * http://unicode.org/faq/idn.html#6 == Scope == * Proposal owners: The proposal owner is expected to co-ordinate and fill the required bugs on the distribution. * Other developers: Maintainers, should - Verify that their software is linked with the libidn library - Update the software from upstream if it already has been converted to libidn2 - Check the libidn2 instructions on converting a package to libidn2. - Propose patches (trivial task) to convert to libidn2, and notify upstream about it. In short switch software from libidn to libidn2, it is sufficient replacing idna.h header with idn2.h. * Release engineering: This feature requires not action from release engineering. * List of deliverables: This will bring: - An updated libidn2 library <- already in F25 - A switch of all applications to libidn2 - libidn will be deprecated but not removed as applications may explicitly require IDNA2003 support (e.g., for compatibility) * Policies and guidelines: Currently Fedora has no guidelines for IDNA support. With this change the recommended guideline for applications would be to support IDNA2008 by default. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Fri, 2017-08-25 at 06:59 +0200, Remi Collet wrote: > Le 25/08/2017 à 03:31, Adam Williamson a écrit : > > On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote: > > > On 08/24/2017 11:36 AM, Adam Williamson wrote: > > > > Sorry, of course we have to actually build 6.9.9-9. It looks like > > > > you're on this already, thanks. > > > > > > I've also created updates in Bodhi. Please feel free to attach your > > > builds to it. > > > > > > F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f > > > F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31 > > > > I have done nearly all the rebuilds and added them to the updates, just > > waiting on inkscape for f25 to finish up, and buildroot overrides for > > synfig to kick in so I can build synfigstudio. > > Thanks for your work on this. > > About php-pecl-imagick, I think we'll have to apply patch from > > https://github.com/mkoppanen/imagick/pull/186 > > In Fedora 25 / 26, so users will be aware of some removed methods in > Fedora 27 > > Waiting for upstream feedback about this very old PR, and will try to > manage it (probably after the current update will be in stable to not > differ it more than needed) Sure, sounds sensible (assuming we actually wind up sticking with 7.x in F27+; it does seem like quite a bit of work will be needed for that). > > Remi > > > P.S. I also need to manage update of ImageMagick6 and ImageMagick7 for > users of my repository, to not break everything, and push new build at > same time than official updates... The updates have autokarma disabled; I guess Michael and I will try to synchronize with you, and other major third-party repo maintainers, when we're planning to push them stable. Thanks for the note! -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
Le 25/08/2017 à 03:31, Adam Williamson a écrit : > On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote: >> On 08/24/2017 11:36 AM, Adam Williamson wrote: >>> Sorry, of course we have to actually build 6.9.9-9. It looks like >>> you're on this already, thanks. >> >> I've also created updates in Bodhi. Please feel free to attach your builds >> to it. >> >> F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f >> F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31 > > I have done nearly all the rebuilds and added them to the updates, just > waiting on inkscape for f25 to finish up, and buildroot overrides for > synfig to kick in so I can build synfigstudio. Thanks for your work on this. About php-pecl-imagick, I think we'll have to apply patch from https://github.com/mkoppanen/imagick/pull/186 In Fedora 25 / 26, so users will be aware of some removed methods in Fedora 27 Waiting for upstream feedback about this very old PR, and will try to manage it (probably after the current update will be in stable to not differ it more than needed) Remi P.S. I also need to manage update of ImageMagick6 and ImageMagick7 for users of my repository, to not break everything, and push new build at same time than official updates... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote: > On 08/24/2017 11:36 AM, Adam Williamson wrote: > > Sorry, of course we have to actually build 6.9.9-9. It looks like > > you're on this already, thanks. > > I've also created updates in Bodhi. Please feel free to attach your builds to > it. > > F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f > F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31 I have done nearly all the rebuilds and added them to the updates, just waiting on inkscape for f25 to finish up, and buildroot overrides for synfig to kick in so I can build synfigstudio. Note: php-magickwand does not build with PHP 7 and no-one upstream seems terribly inclined to fix it any time soon, so that one's just going to have to stay broken (I doubt the current package is even installable on F25 or F26, so this is not likely a regression) unless someone wants to step up and do the PHP 7 port (I...do not). -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 10:43 -0500, Michael Cronenworth wrote: > On 08/24/2017 10:24 AM, Adam Williamson wrote: > > As Remi said, the changes in 6.9.9 are far less significant than those > > in 7.0.6. As several people pointed out, sending 7.x to stable releases > > is clearly against the updates policy. I'd agree we definitely must > > revert to 6.x for F25 and F26 updates; for those we should send out a > > 6.9.9-9 update with rebuilds of all deps. I don't care if F27 and > > Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon > > at least for F27. > > > > I'm also willing to work on this, but everyone who's interested should > > agree on a plan first, and then we could possibly split the work up > > (e.g. into 6.x and 7.x work). > > I'll compromise with F25/26 with 6.9 and F27+ getting 7.0. > > I'll get an Epoch bump started... when it completes if you want to do > rebuilds for > F25/26 I'll work on F27+. Note, I am rebuilding ImageMagick itself again for F27 and Rawhide, because the versioning was wrong: Moez incorrectly moved the patchlevel from %{version} to %{release}. This is wrong because it is part of the upstream versioning, not the downstream. Note the NEVRs listed in the %changelog were still in the old, correct form, but the *actual* NEVRs of the recent builds were wrong. I have reverted the relevant parts of the spec to exactly how it was before, and corrected the changelog so it gives the real NEVRs for each build. This is significant to rubygem-rmagick.spec , which must specify the exact version (including patchlevel) of ImageMagick it's built against. So I had to go ahead and fix this in order to be able to rebuild rubygem-rmagick correctly (I'm going to do the F27+ rebuilds of it as well as the F25/F26 rebuilds for git consistency reasons). -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is a package providing and requiring the same library in the package normal?
Rex Dieter wrote: > Cheng Ye wrote: > >> Hi, >> This is probably a simple packaging question. > > Yes, per SUBJECT, this is normal and not out of the ordinary. Right. In particular, it happens if the package containing the library libfoo.so.1 also contains an executable or another library linked to libfoo.so.1. Then RPM will produce both an AutoProvides and an AutoRequires for the library. This is not strictly necessary, but harmless (and technically correct). You could use the AutoRequires filtering to filter out the unnecessary Requires, but I would not bother doing that, as the Requires is technically correct and causes no issues, so filtering it out would just be a waste of your time. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modularizing the world fast and iteratively
Matthew Miller wrote: > Core-Extras was a bad ideas because Core was developed inside Red Hat > in a non-open way and did not allow community involvement beyond that > of beta testing. Merging it all together was probably the only > realistic way to fix that (and fixing that was absolutely the best > thing to do), but if we'd kept separate repos, we'd have addressed the > technical problems sooner and had a lot more of the flexibility that we > _really_ need to keep growing. That was only one aspect of the problem. The bigger issue is that packages routinely had to be built without some features because the package was in Core and the feature would have required something from Extras (an issue we are still seeing with RHEL and EPEL nowadays), packages had to be brought from Extras to Core as dependencies, and in some cases, packages actually had to be moved from Core to Extras to be able to use dependencies from Extras. This issue is now coming back with the modules. Some packages also actually had to be split into 2 SRPMs from the same sources, one in Core and one in Extras, instead of using subpackages, due to build-time requirements on Extras packages. (One example was the package I got sponsored with: redhat-artwork-kde, split out from redhat-artwork as part of https://fedoraproject.org/wiki/Archive:UnleashKDE – I maintained that for 2 weeks, then the Core-Extras Merge happened and it was already obsolete. ;-) That was an interesting start of a packager career. ;-) ) Having a unified Everything repository from which individual binary packages can then be picked from is a huge advantage. It is just too common that you have things such as: * optional plugin subpackages requiring extra dependencies to build. You want to build the package with those dependencies, then split the plugins into subpackages so that the main runtime package can be installed without those dependencies. But with the module isolation, you cannot do that anymore. * documentation requiring huge toolchains such as LaTeX to build, but not to view. * dependencies required only for the test suite, as in the autotools case. In addition, having a unified end of life makes system maintenance A LOT easier for the users. I consider the whole concept of modularity fatally flawed by design. You are about to eat the cake and to not realize that you will not have it anymore then. The feature's promise that you can eat your cake and have it too is impossible to fulfill. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On Thu, 24 Aug 2017 21:51:59 +0200, Sandro Mani wrote: > May well be mistaken, but doesn't ABRT work with coredumps, which you can't > get on Windows systems? OK, thanks for showing me the setup. I was still imagining running PE32 binaries by Wine, I did not realize there exist real Windows systems. :-) Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 10:43 -0500, Michael Cronenworth wrote: > > I'll get an Epoch bump started... when it completes if you want to do > rebuilds for > F25/26 I'll work on F27+. BTW, it occurred to me for F27+ it may be worth checking if each project supports a less messy alternative, like GraphicsMagick, which I think seems to be a rather saner option. For F25/F26 of course I won't make such switches. -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20170824.n.0 compose check report
Missing expected images: Server dvd i386 Workstation live i386 Server boot i386 Kde live i386 Failed openQA tests: 29/137 (x86_64), 1/2 (arm) ID: 133935 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/133935 ID: 133942 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/133942 ID: 133944 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/133944 ID: 133948 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/133948 ID: 133956 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/133956 ID: 133958 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/133958 ID: 133962 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/133962 ID: 133970 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/133970 ID: 133975 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/133975 ID: 133979 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/133979 ID: 133983 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/133983 ID: 133984 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/133984 ID: 133988 Test: x86_64 Workstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/133988 ID: 133989 Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/133989 ID: 133990 Test: x86_64 Workstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/133990 ID: 133999 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/133999 ID: 134000 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/134000 ID: 134001 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/134001 ID: 134003 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/134003 ID: 134004 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/134004 ID: 134005 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/134005 ID: 134006 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/134006 ID: 134007 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/134007 ID: 134008 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/134008 ID: 134009 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/134009 ID: 134011 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/134011 ID: 134012 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/134012 ID: 134066 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/134066 ID: 134067 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/134067 ID: 134068 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/134068 Soft failed openQA tests: 2/137 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 133954 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/133954 ID: 134015 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/134015 Passed openQA tests: 94/137 (x86_64) Skipped openQA tests: 9 of 139 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On 24.08.2017 21:42, Jan Kratochvil wrote: On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote: While I'm at it, my current technique for interpreting mingw stacktraces produced without debuginfos is parsing the text and calling addr2line for each stack frame. Is there a neater technique? Unaware of. But then why you do not have the debuginfos? You deploy the application without debuginfos to save space, and then have a crash-handler which attaches gdb to the dying process, produces a stacktrace, and sends it to the developer if the user wants. And also why ABRT does not process it? ABRT has its retrace server infrastructure to do exactly that but I guess ABRT cannot handle PE32. May well be mistaken, but doesn't ABRT work with coredumps, which you can't get on Windows systems? when one has to do live-debugging on without debuginfos. Why? debuginfos are easily available from standard repos. One example: you are at a customers to debug some misbehaviour on a crippled down Windows system where you can't place the *.debug files next to the binaries, and perhaps don't event have internet access... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote: > While I'm at it, my current technique for interpreting mingw stacktraces > produced without debuginfos is parsing the text and calling addr2line for > each stack frame. Is there a neater technique? Unaware of. But then why you do not have the debuginfos? And also why ABRT does not process it? ABRT has its retrace server infrastructure to do exactly that but I guess ABRT cannot handle PE32. > when one has to do live-debugging on without debuginfos. Why? debuginfos are easily available from standard repos. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On 24.08.2017 14:52, Jan Kratochvil wrote: On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote: On 24.08.2017 14:18, Jan Kratochvil wrote: On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: I'm investigating why gdb returns so unreliable backtraces for mingw binaries without debuginfos, They are perfectly reliable. They just do not show the function names. But those can be looked up later from *-debuginfo.rpm. I regularly have the issue that with larger programs, gdb aborts with "Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if the crash happens somewhere deep down, say in some Qt library, and never gets to printing the frames of the caller of the application code I'm interested in. If debugsymbols are available, it prints the all the frames. Hence "unreliable". I supose this might be a bug, but I have no idea how to investigate. In your OP example: : #0 0x0040157d in ?? () : #1 0x004015b5 in ?? () : #2 0x004013f7 in ?? () : #3 0x0040152b in ?? () : #4 0x76af652d in KERNEL32!BaseThreadInitThunk () :from C:\Windows\system32\kernel32.dll : #5 0x76d2c521 in ntdll!RtlUserThreadStart () :from C:\Windows\SYSTEM32\ntdll.dll : #6 0x in ?? () : Backtrace stopped: previous frame inner to this frame (corrupt stack?) : : With strip-debug, gdb reports: : : #0 0x0040157d in foo() () : #1 0x004015b5 in main () You can see the backtrace is the same. I guess you will see that Backtrace stopped: previous frame inner to this frame (corrupt stack?) even with installed *-debuginfo.rpm after you enter: (gdb) set backtrace past-main on (gdb) set backtrace past-entry on The symbols (particularly the "main" symbol) just tell GDB to stop backtracing earlier. But the part that it already backtraced is the same. In some cases *-debuginfo.rpm can really improve the backtrace (even the numerical-only one, ignoring the address->functionname decoration). This is due to .debug_frame sections there when the main binary is missing corresponding .eh_frame. But I have no idea how this works in PE32 and then it is a packaging bug (missing -fasynchronous-unwind-tables) as the numerical-only backtraces should be the same with and without debuginfo. Last difference can be due to inlined functions being shown just with *-debuginfo.rpm but that is not much important (and reconstructable from the numerical-only backtrace). Thanks for your explanations. Actually I wonder if indeed fooled by the "backtrace past-main on" thing. Next time I'll hit some cryptic stacktrace I'll double check. While I'm at it, my current technique for interpreting mingw stacktraces produced without debuginfos is parsing the text and calling addr2line for each stack frame. Is there a neater technique? But these *-debuginfo.rpm differences will not happen with your planned bare functionname symbols (called ELF symbols or PE32 symbols in your case). I'll do a quick size-analysis of some common packages (say gtk, qt) and if the size increase is not prohibitively large, I'll file a change to have these symbols included by default in the mingw binaries. Beyond possible stacktrace quality differences, I'm also interested in making life more pleasant when one has to do live-debugging on without debuginfos. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 11:28 -0700, Moez Roy wrote: > > A rebuild of affected packages would be required regardless, so it made > more sense to just update it directly to v7 which has High Dynamic Range > Imaging by default and more Pixel channels. The problem is that 7.x makes *more*, and more significant, API/ABI changes than 6.9.9. It's very likely some code will rebuild without modification against 6.9.9 but not at all against 7.x. And landing major updates with major behaviour changes in stable releases is just flat out against the updates policy, even if you rebuild dependent packages. -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote: > On 08/24/2017 11:36 AM, Adam Williamson wrote: > > Sorry, of course we have to actually build 6.9.9-9. It looks like > > you're on this already, thanks. > > I've also created updates in Bodhi. Please feel free to attach your builds to > it. > > F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f > F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31 Roger, thanks. I'm also still working on rdma-related rebuilds for Rawhide / F27, so I'll be kinda picking things up through the day. If anyone else wants to help out, feel free - maybe just call out on #fedora-devel what packages you're working on, so we don't duplicate work. -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 11:36 AM, Adam Williamson wrote: Sorry, of course we have to actually build 6.9.9-9. It looks like you're on this already, thanks. I've also created updates in Bodhi. Please feel free to attach your builds to it. F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, Aug 24, 2017 at 11:12 AM, Michael Cronenworth wrote: > On 08/24/2017 11:36 AM, Adam Williamson wrote: > >> Sorry, of course we have to actually build 6.9.9-9. It looks like >> you're on this already, thanks. >> > > The build override has landed. > > Thanks, > Michael > I transferred ownership of ImageMagick to you (mooninite). I don't have the privs to rebuild affected packages as mentioned in notes, so it is better if a proven packager owns this package. A rebuild of affected packages would be required regardless, so it made more sense to just update it directly to v7 which has High Dynamic Range Imaging by default and more Pixel channels. -Moez Roy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 11:36 AM, Adam Williamson wrote: Sorry, of course we have to actually build 6.9.9-9. It looks like you're on this already, thanks. The build override has landed. Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: modularity: (my) expectations vs. reality
On Thu, 24 Aug 2017 08:21:57 +0200 Tomas Tomecek wrote: > We would need to develop a dedicated, non-trivial tooling to enable > this functionality. And honestly, I can't even imagine how this > could be even possible to implement for all ecosystems (compiled > languages, interpreted languages). Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
malloc trace/playback for glibc 2.26 and rawhide...
With glibc 2.26 there's a new per-thread cache in malloc, which improves malloc performance in general, and hopefully, specifically for the apps which each of you are most concerned about. In the event that you feel it doesn't help, or if you have other concerns about malloc performance, there's another part of my malloc performance work that's not in glibc 2.26 - the ability to capture and play back malloc activity. I created these tools to help with the malloc performance testing, since reliably recreating situations I wanted to test was difficult - especially with apps that interacted with the user, like LibreOffice. It's also handy for capturing data from apps that are difficult to configure (think, "requires other hosts to provide services" or "only happens with my /etc/passwd") and the occasional (gasp!) proprietary app that cannot be included in a bug report. Anyway, I've put the patch (suitable for rpmbuild) and tools tarball (they can run on a separate machine), along with a pointer to a COPR repo with F26 and rawhide builds of glibc-2.26.90-5 (x86 32/64 only for F26, ppc64le included for rawhide), here: http://people.redhat.com/dj/glibc/ Instructions for using the tools are also there. The tarball also includes a sample trace (of /bin/ls ;) to play with. So, if you think you have malloc-related performance issues, or want to benchmark a difficult application on different malloc implementations (the simulator is a regular app, you can LD_PRELOAD an interposed malloc), please give this a try. If you think you have an unusual app and want me to consider your malloc performance in future work, please feel free to send me (privately, they're huge) a workload to include in my collection :-) Thanks! DJ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: %py3_install fails to accept arguments
2017-08-24 9:54 GMT+02:00 Juan Orti Alcaine : > Hi, > > I'm getting failed builds [1] in rawhide and f27 because the macro > %py3_install fails when called with arguments. It was fine until f26. > > The package is rhythmbox-ampache, and I call the macro like this: > > > %global py_install_args --no-glib-compile-schemas Enquoting the value seems to fix it !? %global py_install_args "--no-glib-compile-schemas" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On 08/24/2017 05:18 AM, Jan Kratochvil wrote: > But the symbols take less space there as they are compressed. You can check > how it looks like for Linux ELF binaries by: > rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section > .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv > /tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less FWIW, elfutils can read .gnu_debugdata directly: eu-readelf --elf-section -Wa /bin/bash ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Platform Python changes and python3dist tags
On 24.8.2017 03:17, Scott Talbert wrote: On Tue, 22 Aug 2017, Scott Talbert wrote: Hi, I was just trying to build a new package in Rawhide that built fine a few days ago. The failure seems to be occurring because the python3 setuptools_scm module isn't being found. I'm using the new pythonXdist tags: BuildRequires: %{py2_dist py pytest setuptools_scm} BuildRequires: %{py3_dist py pytest setuptools_scm} It seems this is causing several of the recently added platform-python packages to be pulled in: Installing: platform-python-pytestnoarch3.2.1-2.fc28 fedora 438 k platform-python-setuptools_scmnoarch1.15.6-4.fc28 fedora 36 k Both the python3-setuptools_scm and platform-python-setuptools_scm packages have the python3dist tag: $ rpm -q --provides -p platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm warning: platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 9db62fb1: NOKEY platform-python-setuptools_scm = 1.15.6-4.fc28 python3.6dist(setuptools-scm) = 1.15.6 python3dist(setuptools-scm) = 1.15.6 $ rpm -q --provides -p python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm warning: python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 9db62fb1: NOKEY python3-setuptools_scm = 1.15.6-4.fc28 python3.6dist(setuptools-scm) = 1.15.6 python3dist(setuptools-scm) = 1.15.6 [swt2c@rawhide-test ~][PROD]$ It seems that probably the platform-python packages shouldn't have these tags? I'm hearing a lot of crickets. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1484607 against rpm as I didn't see any obvious way for the platform-python packages to exclude themselves from the python3dist provides. I'm just going to stop using the py3_dist stuff for now. Scott This has just been fixed. Thanks for noticing. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 11:36 AM, Adam Williamson wrote: Sorry, of course we have to actually build 6.9.9-9. It looks like you're on this already, thanks. Yes, I've issued builds. Once the buildroot override is available I'll send another email. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 09:27 -0700, Adam Williamson wrote: > On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote: > > On Thu, 24 Aug 2017 10:54:12 -0500 > > Michael Cronenworth wrote: > > > > > On 08/24/2017 10:49 AM, Kevin Fenzi wrote: > > > > Epoch bump? Why? The f25/f26 packages never even got to testing... > > > > Just revert the commits, etc. > > > > > > I thought Koji did an NVR check? Won't let a lower version or is it > > > only when it's been pushed? > > > > koji won't let you build one NVR twice for non-scratch builds > > > > bodhi has some NVR checks, but they are not blocking > > Yep, +1 others, for F25/F26 we don't need to do any new build for > imagemagick itself, just revert the commits in the repo, set up a > buildroot override for the 6.9.9-9 package, and then get to rebuilding > dependencies. Sorry, of course we have to actually build 6.9.9-9. It looks like you're on this already, thanks. -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 06:27 PM, Adam Williamson wrote: > On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote: >> On Thu, 24 Aug 2017 10:54:12 -0500 >> Michael Cronenworth wrote: >> >>> On 08/24/2017 10:49 AM, Kevin Fenzi wrote: Epoch bump? Why? The f25/f26 packages never even got to testing... Just revert the commits, etc. >>> >>> I thought Koji did an NVR check? Won't let a lower version or is it >>> only when it's been pushed? >> >> koji won't let you build one NVR twice for non-scratch builds >> >> bodhi has some NVR checks, but they are not blocking > > Yep, +1 others, for F25/F26 we don't need to do any new build for > imagemagick itself, just revert the commits in the repo, set up a > buildroot override for the 6.9.9-9 package, and then get to rebuilding > dependencies. Yes, agreed. This sounds like the best course of action; latest 6.9 for F25/F26, and 7.0 for F27/F28. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
On 08/24/2017 05:48 PM, Kevin Fenzi wrote: > I was going to look at f25/f26 for a 6.x update, but I haven't had any > time to get to it. ;( Would need a bunch of rebuilds and waiting in > testing a while so 3rd parties could see it and rebuild at the very least. I think we're going to need an ABI compatibility package for the old soname. This serves a two fold purpose: a) if something in F25/F26 fails to rebuild against the new soname, it can keep using the compat package and doesn't block the whole ImageMagick update from going to stable, and b) we won't break 3rd parties code who might be shipping binaries linked with the old soname. I'm happy to help with this too, both with rebuilds and putting together a compat package / reviewing it. -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote: > On Thu, 24 Aug 2017 10:54:12 -0500 > Michael Cronenworth wrote: > > > On 08/24/2017 10:49 AM, Kevin Fenzi wrote: > > > Epoch bump? Why? The f25/f26 packages never even got to testing... > > > Just revert the commits, etc. > > > > I thought Koji did an NVR check? Won't let a lower version or is it > > only when it's been pushed? > > koji won't let you build one NVR twice for non-scratch builds > > bodhi has some NVR checks, but they are not blocking Yep, +1 others, for F25/F26 we don't need to do any new build for imagemagick itself, just revert the commits in the repo, set up a buildroot override for the 6.9.9-9 package, and then get to rebuilding dependencies. -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 24 Aug 2017 10:54:12 -0500 Michael Cronenworth wrote: > On 08/24/2017 10:49 AM, Kevin Fenzi wrote: > > Epoch bump? Why? The f25/f26 packages never even got to testing... > > Just revert the commits, etc. > > I thought Koji did an NVR check? Won't let a lower version or is it > only when it's been pushed? koji won't let you build one NVR twice for non-scratch builds bodhi has some NVR checks, but they are not blocking Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2017-08-25)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2017-08-25 16:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1763 Fedora Modules Guidelines and Process .fesco 1763 https://pagure.io/fesco/issue/1763 #topic #1765 Proposed Fedora 28 schedule .fesco 1765 https://pagure.io/fesco/issue/1765 = New business = #topic #1761 Update of "Fedora Release Live Cycle" and "Changes / Policy" .fesco 1761 https://pagure.io/fesco/issue/1761 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 10:49 AM, Kevin Fenzi wrote: Epoch bump? Why? The f25/f26 packages never even got to testing... Just revert the commits, etc. I thought Koji did an NVR check? Won't let a lower version or is it only when it's been pushed? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
Le 24/08/2017 à 17:43, Michael Cronenworth a écrit : > I'll get an Epoch bump started... when it completes if you want to do > rebuilds for F25/26 I'll work on F27+. I don't think epoch bump is needed (package never go in the repo) Remi > > Thanks, > Michael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 08:43 AM, Michael Cronenworth wrote: > On 08/24/2017 10:24 AM, Adam Williamson wrote: >> As Remi said, the changes in 6.9.9 are far less significant than those >> in 7.0.6. As several people pointed out, sending 7.x to stable releases >> is clearly against the updates policy. I'd agree we definitely must >> revert to 6.x for F25 and F26 updates; for those we should send out a >> 6.9.9-9 update with rebuilds of all deps. I don't care if F27 and >> Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon >> at least for F27. >> >> I'm also willing to work on this, but everyone who's interested should >> agree on a plan first, and then we could possibly split the work up >> (e.g. into 6.x and 7.x work). > > I'll compromise with F25/26 with 6.9 and F27+ getting 7.0. > > I'll get an Epoch bump started... when it completes if you want to do > rebuilds for F25/26 I'll work on F27+. Epoch bump? Why? The f25/f26 packages never even got to testing... Just revert the commits, etc. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
On 08/24/2017 08:19 AM, Adam Williamson wrote: > On Thu, 2017-08-24 at 09:12 +0200, Remi Collet wrote: >> Le 24/08/2017 à 08:58, Adam Williamson a écrit : >>> On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote: Le 24/08/2017 à 02:32, Moez Roy a écrit : > The soname bump requires packages that depend on it need to be rebuilt, so > I updated ImageMagick to 7.0.6-9. Such a version bump in stable branch is not acceptable. ImageMagick 7 removed lot of functions (deprecated in v6) Especially as ImageMagick 6 is still maintained. BTW, latest version 6.9.9-9 also have some API changes - 6.9.6-8 => bump to .3 - 6.9.7-6 => bump to .4 - 6.9.9-0 => bump to .5 Yes, this package is a nightmare. >>> >>> Note the versioning is a bit subtle. What was released upstream was >>> 6.9.9-9 , which in our versioning would be 6.9.9.9 . Upstream *didn't* >>> go from 6.9.8 to 6.9.9, but from 6.9.9-8 to 6.9.9-9. The package in >>> Fedora before all this mess was versioned 6.9.9.3 , which I believe >>> would be upstream's 6.9.9-3 , and I *think* there is no ABI/API >>> incompatibility between 6.9.9-3 and 6.9.9-9. The soname in the 6.9.9.3 >>> packages was already >>> "libMagickCore-6.Q16.so.5()(64bit)". >> >> Yes in F27+ (6.9.9.3) >> >> F25/F26 have 6.9.3.0 (upstream 6.9.3-0) with >> libMagickCore-6.Q16.so.2 >> libMagickWand-6.Q16.so.2 > > Yep, I just looked back and saw that nirik built upstream 6.9.9-3 but > hadn't actually sent it as an update, since it was an soname bump and > all the necessary rebuilds weren't done yet :/ Sigh. Yeah, I didn't want to push 7.x to even rawhide without investigation that all dependent packages were ready to move to it. I was going to look at f25/f26 for a 6.x update, but I haven't had any time to get to it. ;( Would need a bunch of rebuilds and waiting in testing a while so 3rd parties could see it and rebuild at the very least. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 10:24 AM, Adam Williamson wrote: As Remi said, the changes in 6.9.9 are far less significant than those in 7.0.6. As several people pointed out, sending 7.x to stable releases is clearly against the updates policy. I'd agree we definitely must revert to 6.x for F25 and F26 updates; for those we should send out a 6.9.9-9 update with rebuilds of all deps. I don't care if F27 and Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon at least for F27. I'm also willing to work on this, but everyone who's interested should agree on a plan first, and then we could possibly split the work up (e.g. into 6.x and 7.x work). I'll compromise with F25/26 with 6.9 and F27+ getting 7.0. I'll get an Epoch bump started... when it completes if you want to do rebuilds for F25/26 I'll work on F27+. Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 2017-08-24 at 09:47 -0500, Michael Cronenworth wrote: > On 08/24/2017 09:25 AM, Remi Collet wrote: > > I really think we have to revert to 6 in stable branch > > (and perhaps even in F27, which is very close to feature freeze) > > > > - soname bump > > - lot of removed API > > - HDRI enabled by default > > The SONAME is changing in 6.9 as well so I'm not sure reverting is great > either > otherwise I would have done it. > > I'm prepared to perform rebuilds and push updates to get this resolved. > Assuming no > objections in the next day I'll get it rolling. Worst case if there's > negative karma > on the updates I'll push a revert to 6.9. As Remi said, the changes in 6.9.9 are far less significant than those in 7.0.6. As several people pointed out, sending 7.x to stable releases is clearly against the updates policy. I'd agree we definitely must revert to 6.x for F25 and F26 updates; for those we should send out a 6.9.9-9 update with rebuilds of all deps. I don't care if F27 and Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon at least for F27. I'm also willing to work on this, but everyone who's interested should agree on a plan first, and then we could possibly split the work up (e.g. into 6.x and 7.x work). -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: About "debugsource" package and repo layout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-08-24 at 17:04 +0200, Remi Collet wrote: > Hi, > > Since F27, for each package, we have a "debugsource" package. > > Question is about the repository layout > > For now these packages are available in the standard repository > > Ex: > http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Ever > ything/x86_64/os/Packages/y/ > > yajl-2.1.0-8.fc27.x86_64.rpm > yajl-debugsource-2.1.0-8.fc27.x86_64.rpm > yajl-devel-2.1.0-8.fc27.x86_64.rpm > > Shouldn't these packages be in the "debug" repository > > ie: > http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Ever > ything/x86_64/debug/tree/Packages/y/ > > yajl-debuginfo-2.1.0-8.fc27.x86_64.rpm > > > Definitely you are right and those should be there, check: - - https://pagure.io/pungi/issue/684 - - https://pagure.io/koji/pull-request/524 Unfortunately, I think those fixes are still not deployed.. > > Remi > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlme7sAACgkQaVcUvRu8 X0zOzQ//dk9MEgqEkcyX1qfacjXLUmXyiBdUvpNaUMMAp4NyxYqNWWXuQPHpfboM 3ImqnLCBrac2hupA3PlPtRibFIcUKZIMzWf9IIhmyLEhgb9r8ltSY/zfRnALss6B PgrMHl5y0/9nK/nz7Lb66hpcL6nDmRlna+kfdftbDjcMgwN3TyqFmmGFzykT7tjN ZuIWI5F9QwXNOCvY7OvA8M1zCi+29Fvgo4hzNMDO+dAG+kwRyB+S3ImZ1EQcJXmB PghnuSScDBND22Ys7R8VYm3ZJpspV5g9eH+DERgW13k4GAwHhSzumzVX4raPptco DtPqLqkAp0hG7MnCmk3aR5WiW3DND2qPsCgwlF0ROqeUgFIc4NdNDMixypC58zoQ MciWkgSK9DyEaLlk9V/XoHFfUMUZloLGM4WM9yYUF9gmZWy6x/g9NlqhLd7+A3Vt Rso+KP5wcbzFj8S1UuOhU0lfpatX+wjmQzU6rxgmn91toOYiJ9deQ63DpVlul2cC xFRwebTUBQVz+HNhX15E73rAwpO2aRxrQAlwlYFbXFqdrFbg6Tp7rhlv1Q6xBGcI RH/9JkxqVFlnJWdlxTv+0ao/f1BJKPjtlBRju4lqjjQLpUNA2tV6AI1SFhUDD7Di 7VFeJ1JjVkWk7BrE5RrgdC/8uG81Kmy4z0w/UoNdVB/0QXLE4q0= =r1I4 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
On Thu, 2017-08-24 at 09:12 +0200, Remi Collet wrote: > Le 24/08/2017 à 08:58, Adam Williamson a écrit : > > On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote: > > > Le 24/08/2017 à 02:32, Moez Roy a écrit : > > > > > > > The soname bump requires packages that depend on it need to be rebuilt, > > > > so > > > > I updated ImageMagick to 7.0.6-9. > > > > > > > > > Such a version bump in stable branch is not acceptable. > > > > > > ImageMagick 7 removed lot of functions (deprecated in v6) > > > > > > Especially as ImageMagick 6 is still maintained. > > > > > > BTW, latest version 6.9.9-9 also have some API changes > > > > > > - 6.9.6-8 => bump to .3 > > > - 6.9.7-6 => bump to .4 > > > - 6.9.9-0 => bump to .5 > > > > > > Yes, this package is a nightmare. > > > > Note the versioning is a bit subtle. What was released upstream was > > 6.9.9-9 , which in our versioning would be 6.9.9.9 . Upstream *didn't* > > go from 6.9.8 to 6.9.9, but from 6.9.9-8 to 6.9.9-9. The package in > > Fedora before all this mess was versioned 6.9.9.3 , which I believe > > would be upstream's 6.9.9-3 , and I *think* there is no ABI/API > > incompatibility between 6.9.9-3 and 6.9.9-9. The soname in the 6.9.9.3 > > packages was already > > "libMagickCore-6.Q16.so.5()(64bit)". > > Yes in F27+ (6.9.9.3) > > F25/F26 have 6.9.3.0 (upstream 6.9.3-0) with > libMagickCore-6.Q16.so.2 > libMagickWand-6.Q16.so.2 Yep, I just looked back and saw that nirik built upstream 6.9.9-3 but hadn't actually sent it as an update, since it was an soname bump and all the necessary rebuilds weren't done yet :/ -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
About "debugsource" package and repo layout
Hi, Since F27, for each package, we have a "debugsource" package. Question is about the repository layout For now these packages are available in the standard repository Ex: http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/y/ yajl-2.1.0-8.fc27.x86_64.rpm yajl-debugsource-2.1.0-8.fc27.x86_64.rpm yajl-devel-2.1.0-8.fc27.x86_64.rpm Shouldn't these packages be in the "debug" repository ie: http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/debug/tree/Packages/y/ yajl-debuginfo-2.1.0-8.fc27.x86_64.rpm Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
Le 24/08/2017 à 16:47, Michael Cronenworth a écrit : > On 08/24/2017 09:25 AM, Remi Collet wrote: >> I really think we have to revert to 6 in stable branch >> (and perhaps even in F27, which is very close to feature freeze) >> >> - soname bump >> - lot of removed API >> - HDRI enabled by default > > The SONAME is changing in 6.9 as well so I'm not sure reverting is great > either otherwise I would have done it. Yes, but no removed API, and no hdri by default. > > I'm prepared to perform rebuilds and push updates to get this resolved. > Assuming no objections in the next day I'll get it rolling. Worst case > if there's negative karma on the updates I'll push a revert to 6.9. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
Hi, I suspect the confusion between group and module names will lead to strange brittle special cases down the road and (worse) people being over-clever building solutions that rely on those special cases (exactly like the under-specified rpm update quirks which are being blamed nowadays). Why not make the module shorthand specific? package ⊂ @group ⊂ @@module Or am I missing something? Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 08/24/2017 09:25 AM, Remi Collet wrote: I really think we have to revert to 6 in stable branch (and perhaps even in F27, which is very close to feature freeze) - soname bump - lot of removed API - HDRI enabled by default The SONAME is changing in 6.9 as well so I'm not sure reverting is great either otherwise I would have done it. I'm prepared to perform rebuilds and push updates to get this resolved. Assuming no objections in the next day I'll get it rolling. Worst case if there's negative karma on the updates I'll push a revert to 6.9. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16
Hello, For some reason I fail to understand, a non-devel package is conflicting with a devel package :-/ According to dnf it's the only explicit conflict for the package: $ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64 pkgconfig(nspr) >= 4.16 Maybe someone confused Conflicts with BuildConflicts in the spec? Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
Dne 24.8.2017 v 09:00 Marius Vollmer napsal(a): My understanding from playing with Boltron is that "dnf install foo" treats "foo" as a module name. "dnf install" can not install packages The final solution will be: dnf install foo - install rpm package dnf module install foo - install module dnf install @foo - install module (if comps of the same name exists it install comps, otherwise module, or vice versa, somebody from DNF team should clarify). Mirek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR strategy
Dne 24.8.2017 v 13:58 Cheng Ye napsal(a): Hi, Making the builddir accessible for failed build would be helpful. Some test suits will store log in a file in buildir without echoing anything else helpful. Without access to builddir, it could be difficult to debug. However, copying the builddir from mock directory to somewhere accessible could be a cumbersome task. Mock actually support this. https://github.com/rpm-software-management/mock/wiki/Plugin-ChrootScan The question is how to define this in Copr per package? As every package will need different artifacts. Mirek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
Le 24/08/2017 à 14:05, Dan Horák a écrit : > so I've applied a workaround [1] to get ImageMagick built on all arches > again until we have a proper fix, it's in Rawhide now, feel free to > apply it to other branches as well I really think we have to revert to 6 in stable branch (and perhaps even in F27, which is very close to feature freeze) - soname bump - lot of removed API - HDRI enabled by default Remi. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Release Live Cycle
On Thu, Aug 24, 2017 at 01:52:16PM +0200, Jan Kurik wrote: > In the group we had the discussion were no strong opinions whether > these milestones need to be early in the release cycle or just before > the "Beta Freeze". As such, I would like to open a discussion and > collect some opinions on the timing of these key milestones. Any > feedback or pros and cons are welcomed. My proposed draft schedules move the branch later. My theory is that this shorter branch time leads to less divergence and requires less duplicated work during the run-up to the release (both for QA and devel). But I'm definitely willing to try different things to see how they work. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modularizing the world fast and iteratively
On Thu, Aug 24, 2017 at 03:20:12AM +0200, Kevin Kofler wrote: > This is exactly why the separate Core and Extras were such a PITA and why > the Core-Extras Merge was done. Doing the opposite now is a BAD idea. Core-Extras was a bad ideas because Core was developed inside Red Hat in a non-open way and did not allow community involvement beyond that of beta testing. Merging it all together was probably the only realistic way to fix that (and fixing that was absolutely the best thing to do), but if we'd kept separate repos, we'd have addressed the technical problems sooner and had a lot more of the flexibility that we _really_ need to keep growing. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is a package providing and requiring the same library in the package normal?
Thanks. It could be better if it can be documented somewhere in wiki. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is a package providing and requiring the same library in the package normal?
Cheng Ye wrote: > Hi, > This is probably a simple packaging question. Yes, per SUBJECT, this is normal and not out of the ordinary. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Is a package providing and requiring the same library in the package normal?
Hi, This is probably a simple packaging question. Sorry for the noise if the answer already exists somewhere on the internet. I am trying to package the IPC library. The built package installs (using dnf) and functions correctly, but the java-cmu-ipc package's automatic requires and provides include libjavaipc.so at the same time. Python sub packages which also contains a shared library (_IPC.so) doesn't have similar issue. Do I need to filter this pair of require and provide? Does this indicate something went wrong during the build? Build log: https://copr-be.cloud.fedoraproject.org/results/yecheng/cmu-ipc/fedora-rawhide-x86_64/00593636-cmu-ipc/build.log.gz "Processing files: java-cmu-ipc-3.9.1a-1.fc28.x86_64 Provides: java-cmu-ipc = 3.9.1a-1.fc28 java-cmu-ipc(x86-64) = 3.9.1a-1.fc28 libipcjava.so.3.9()(64bit) " "Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libipc.so.3.9()(64bit) libipcjava.so.3.9()(64bit) rtld(GNU_HASH) " Review Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1481237 Thanks, Ye Cheng. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
On 24 August 2017 at 10:33, Peter Robinson wrote: > > On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote: > >> Hello Fedora devels and users, > >> > >> more than three years ago, the same topic started discussion if we > >> want > >> this package in Fedora or not and how [1]. The discussion resulted > >> mostly in flames and in the removal of the dependency on tcp_wrappers > >> from systemd. But it was quite agreed that it is considered as a > >> security layer for some users, if they use it correctly, or something > >> that is or should be replaced by firewalls. > >> > >> So can we discuss it now once more without the affiliation to > >> systemd? > >> The fact is that we still do not have any other replacement except > >> firewalls. But do we need one? > >> > >> The complete removal of the package is probably not a wise step, even > >> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is > >> still available in Arch [3] without other tools depending on it. To > >> be > >> fair, Debian [4] is still building tools (for example openssh) with a > >> build-time support for it. > >> > >> My primary concern is OpenSSH, which upstream dropped support for > >> tcp_wrappers three years ago (late 2014) [5] and since then we are > >> maintaining one more downstream patch. But this effort should be > >> coordinated among other components to simplify the transition for > >> users > >> who insist on using it (using tcpd). > >> > >> Removing the dependency will also allow us to trim the default > >> install for few more Kb. > >> > >> If there will be no significant drawbacks, I will progress with > >> filling > >> a system wide change for Fedora 28 and I will pull the maintainers of > >> other tolls using libwrap into the round and discussion. > > > > Hello, > > In Fedora 26, there is over 50 packages using tcp_wrappers as a build- > > time dependency: > > > > > > Since I'm listed twice in there... > > > > With my packages and the situation with build time options I take the > > position of enable as much as possible since our users don't get to pick > > their compilation options. > > > > However tcp_wrappers is a legacy thing that no longer belongs in today's > > world. > > > > I have no objection to a flag day in F28 development and dropping the > build > > option at some point, preferably before the thing that is no longer an > alpha > > ;) ... ie way before beta. > > With F-27 now branched off this can happen in F-28/rawhide now > ___ > > Indeed ... it's a great time to do so ... but let's carry it out under the auspices of a System Wide Change for F28 :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote: > On 24.08.2017 14:18, Jan Kratochvil wrote: > > On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: > > > I'm investigating why gdb returns so unreliable backtraces for mingw > > > binaries without debuginfos, > > They are perfectly reliable. They just do not show the function names. > > But those can be looked up later from *-debuginfo.rpm. > I regularly have the issue that with larger programs, gdb aborts with > "Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if > the crash happens somewhere deep down, say in some Qt library, and never > gets to printing the frames of the caller of the application code I'm > interested in. If debugsymbols are available, it prints the all the frames. > Hence "unreliable". I supose this might be a bug, but I have no idea how to > investigate. In your OP example: : #0 0x0040157d in ?? () : #1 0x004015b5 in ?? () : #2 0x004013f7 in ?? () : #3 0x0040152b in ?? () : #4 0x76af652d in KERNEL32!BaseThreadInitThunk () :from C:\Windows\system32\kernel32.dll : #5 0x76d2c521 in ntdll!RtlUserThreadStart () :from C:\Windows\SYSTEM32\ntdll.dll : #6 0x in ?? () : Backtrace stopped: previous frame inner to this frame (corrupt stack?) : : With strip-debug, gdb reports: : : #0 0x0040157d in foo() () : #1 0x004015b5 in main () You can see the backtrace is the same. I guess you will see that Backtrace stopped: previous frame inner to this frame (corrupt stack?) even with installed *-debuginfo.rpm after you enter: (gdb) set backtrace past-main on (gdb) set backtrace past-entry on The symbols (particularly the "main" symbol) just tell GDB to stop backtracing earlier. But the part that it already backtraced is the same. In some cases *-debuginfo.rpm can really improve the backtrace (even the numerical-only one, ignoring the address->functionname decoration). This is due to .debug_frame sections there when the main binary is missing corresponding .eh_frame. But I have no idea how this works in PE32 and then it is a packaging bug (missing -fasynchronous-unwind-tables) as the numerical-only backtraces should be the same with and without debuginfo. Last difference can be due to inlined functions being shown just with *-debuginfo.rpm but that is not much important (and reconstructable from the numerical-only backtrace). But these *-debuginfo.rpm differences will not happen with your planned bare functionname symbols (called ELF symbols or PE32 symbols in your case). Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
Hi Jan On 24.08.2017 14:18, Jan Kratochvil wrote: On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: I'm investigating why gdb returns so unreliable backtraces for mingw binaries without debuginfos, They are perfectly reliable. They just do not show the function names. But those can be looked up later from *-debuginfo.rpm. I regularly have the issue that with larger programs, gdb aborts with "Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if the crash happens somewhere deep down, say in some Qt library, and never gets to printing the frames of the caller of the application code I'm interested in. If debugsymbols are available, it prints the all the frames. Hence "unreliable". I supose this might be a bug, but I have no idea how to investigate. This has been implemented for Linux ELF binaries: https://fedoraproject.org/wiki/Features/MiniDebugInfo Yep, that was my inspiration for attempting to get something similar to work for PE binaries. But the symbols take less space there as they are compressed. You can check how it looks like for Linux ELF binaries by: rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv /tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less GDB should be able to extract .gnu_debugdata even from PE32 binaries but I guess nobody has ever tested that. I tired injecting the xz compressed symbols into the PE binary analogously to how find-debuginfo.sh does it, but then windows told me that the binary was invalid. You are right that after the MiniDebugInfo feature has been approved for Fedora (*) it should be ported from find-debuginfo.sh even into mingw-find-debuginfo.sh. Therefore also in the compressed way, not just as plain symbols you suggest. If anyone with some knowledge in the area could help with that, I'd be greatful! Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: > I'm investigating why gdb returns so unreliable backtraces for mingw > binaries without debuginfos, They are perfectly reliable. They just do not show the function names. But those can be looked up later from *-debuginfo.rpm. ... > strip-debug: 46k > strip-unneeded: 21k ... > and it seems to work great, the binary size is 24k, and the stack trace This has been implemented for Linux ELF binaries: https://fedoraproject.org/wiki/Features/MiniDebugInfo But the symbols take less space there as they are compressed. You can check how it looks like for Linux ELF binaries by: rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv /tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less GDB should be able to extract .gnu_debugdata even from PE32 binaries but I guess nobody has ever tested that. You are right that after the MiniDebugInfo feature has been approved for Fedora (*) it should be ported from find-debuginfo.sh even into mingw-find-debuginfo.sh. Therefore also in the compressed way, not just as plain symbols you suggest. Jan (*) Personally I do not agree with that but that does not matter here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Thu, 24 Aug 2017 09:04:51 +0200 Dan Horák wrote: > On Wed, 23 Aug 2017 22:16:40 -0500 > Michael Cronenworth wrote: > > > Hi all, > > > > An ImageMagick update (6.9 => 7.0) with an SONAME bump and other > > breakage has been pushed to F25 and higher. > > > > First, the update introduces regressions on s390x and ppc64 arches. > > - https://bugzilla.redhat.com/show_bug.cgi?id=1484578 > > - https://bugzilla.redhat.com/show_bug.cgi?id=1484579 > > these issues shouldn't have been solved with an ExcludeArch > immediately as there is a risk of breaking buildroots for other > packages and for other teams like modularity. If such problem > happens, please contact us (the alternative-arches team) first, so we > can plan the best action. so I've applied a workaround [1] to get ImageMagick built on all arches again until we have a proper fix, it's in Rawhide now, feel free to apply it to other branches as well It adds one more reason to run a CI on the upstream level that would cover alternative arches, we have already something in progress. [1] http://pkgs.fedoraproject.org/rpms/ImageMagick/c/9d8a0e0d350a8d02ae40b76ea03f70d118798f23?branch=master Dan > > > Thanks > > Dan > > > Secondly, rebuilds are required for: > > > >autotrace-0.31.1-44.fc26.src.rpm > >converseen-0.9.6.2-1.fc27.src.rpm > >dmtx-utils-0.7.4-2.fc27.src.rpm > >drawtiming-0.7.1-20.fc26.src.rpm > > F gtatool-2.2.0-4.fc27.src.rpm > >imageinfo-0.05-25.fc26.src.rpm > >inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm > >kxstitch-1.2.0-7.fc26.src.rpm > >perl-Image-SubImageFind-0.03-11.fc27.src.rpm > >pfstools-2.0.6-1.fc27.src.rpm > > F php-magickwand-1.0.9.2-9.fc24.src.rpm > > F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm > >psiconv-0.9.8-20.fc26.src.rpm > >q-7.11-27.fc27.src.rpm > >ripright-0.11-3.fc26.src.rpm > >rss-glx-0.9.1.p-29.fc26.src.rpm > > F rubygem-rmagick-2.16.0-3.fc26.src.rpm > > F synfig-1.2.0-5.fc27.src.rpm > >(boost issues) > > F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm > >(needs synfig) > >vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm > >vips-8.5.6-1.fc27.src.rpm > >WindowMaker-0.95.8-1.fc27.src.rpm > > F cuneiform > >(some c++ blowup) > >k3d > > > > The ones with F have possible compile issues. > > > > Thirdly, two updates have been created. I've disabled autopush on > > them. > > - https://bodhi.fedoraproject.org/updates/FEDORA-2017-0a1f3de4eb > > - https://bodhi.fedoraproject.org/updates/FEDORA-2017-c276ee400a > > > > It is really late here and I don't have the time to investigate the > > arch issues right now. I'll investigate when I can. > > ___ devel mailing list > > -- devel@lists.fedoraproject.org To unsubscribe send an email to > > devel-le...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Richard Kellner
Hi Richard, On 08/23/2017 05:53 PM, Richard Kellner wrote: my name is Richard Kellner and I am a Python developer. In my free time, I am also a PyCon SK volunteer. Recently I have got this crazy idea to submit some of my packages to Fedora, so here I am. I have just submitted my first package for review: https://bugzilla.redhat.com/show_bug.cgi?id=1484561 hopefully several more will come soon. Looking forward to becoming part of the Fedora community. You're most welcome! You are in good company with many Pythonistas in the project. See you around! Cheers, ~m ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR strategy
Hi, Making the builddir accessible for failed build would be helpful. Some test suits will store log in a file in buildir without echoing anything else helpful. Without access to builddir, it could be difficult to debug. However, copying the builddir from mock directory to somewhere accessible could be a cumbersome task. Thanks, Ye Cheng ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Release Live Cycle
Hi everyone, as you probably noted, one of the significant changes in F27 release is the missing Alpha release. This is based on the "No More alphas" [1] Change. The schedule for F27 release [2] has been put together with the aim not to break any flow during the cycle and with intention to make observations what issues and changes in the flow this Change brings. There are also some minor changes in the schedule caused by sliding milestones for Beta GA and Final GA dates (Target & Rain dates). There were several discussions on mailing lists as well as on private level pointing to some issues related to these changes in scheduling of key milestones. Finally we have two proposals. One put together by my self [3] and the second one prepared by Adam [4]. These proposals are the same starting from "Beta Freeze" milestone but different for milestones preceding the "Beta Freeze". Basically the two proposals differ for these milestones: * Mass rebuild * Branching * Bodhi activation point In the group we had the discussion were no strong opinions whether these milestones need to be early in the release cycle or just before the "Beta Freeze". As such, I would like to open a discussion and collect some opinions on the timing of these key milestones. Any feedback or pros and cons are welcomed. [1] https://fedoraproject.org/wiki/Changes/NoMoreAlpha [2] https://fedoraproject.org/wiki/Releases/27/Schedule [3] https://pagure.io/fesco/issue/1761 [4] https://fedoraproject.org/wiki/User:Adamwill/NoMoreAlpha/Fedora_Release_Life_Cycle Thanks & Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
On Thu, Aug 24, 2017 at 3:02 AM Marius Vollmer wrote: > My understanding from playing with Boltron is that "dnf install foo" > treats "foo" as a module name. "dnf install" can not install packages > anymore. So naively I assume that PackageKit will transparently start > installing modules. (I think PK uses libdnf, and I think I read > somewhere that libdnf doesn't do anything with modules yet, so...) > This is not true. The modularity-aware DNF will first check to see if a module matching the requested name exists and will install that. If it doesn't, it will fall back to packages. That being said, the implementation is still under debate. I'm personally of the opinion that this is the correct behavior (since it requires no adaptation for users), but there are some people who believe that it should be explicit with `dnf module install` instead of `dnf install`. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?
Hi I'm investigating why gdb returns so unreliable backtraces for mingw binaries without debuginfos, and noticed a big improvement if I change strip-unneeded to strip-debug in mingw-find-debuginfo.sh. Currently, mingw-find-debuginfo.sh does the following: mingw-objcopy --only-keep-debug "$binary" "$binary.debug" mingw-objcopy --add-gnu-debuglink=$(basename "$binary.debug") --strip-unneeded "$binary" For a trivial test application (see bottom of email), with strip-unneeded and no debug symbols, gdb reports: #0 0x0040157d in ?? () #1 0x004015b5 in ?? () #2 0x004013f7 in ?? () #3 0x0040152b in ?? () #4 0x76af652d in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll #5 0x76d2c521 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll #6 0x in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) With strip-debug, gdb reports: #0 0x0040157d in foo() () #1 0x004015b5 in main () which is what I'd expect. Downside is the binary size: strip-debug: 46k strip-unneeded: 21k Looking at the native find-debuginfo.sh, I see that some symbols are kept: nm "$debuginfo" --format=sysv --defined-only | awk -F \| '{ if ($4 ~ "FUNC") print $1 }' | sort > "$funcsyms" I tried replicating something similar for mingw, using strip-unneeded but keeping these FUNC symbols: mingw-objcopy --only-keep-debug "$binary" "$binary.debug" x86_64-w64-mingw32-nm "$binary.debug" --format=sysv --defined-only | awk -F \| '{ if ($4 ~ "Function") print $1 }' | sort > "$keep_symbols" mingw-objcopy --add-gnu-debuglink=$(basename "$binary.debug") --strip-unneeded "$binary" --keep-symbols="$keep_symbols" and it seems to work great, the binary size is 24k, and the stack trace #0 0x0040157d in foo() () #1 0x004015b5 in main () is also good. The thing is however that I'm not really too sure of what I'm doing. Does this make any sense? Should/could mingw-find-debuginfo.sh be enhanced this way? Thanks Sandro #include void foo() { std::cout << (*((int*)0)) << std::endl; } int main() { foo(); return 0; } ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
Richard Hughes writes: > On 24 August 2017 at 08:45, Marius Vollmer wrote: > >> One approach is just to put them all into the collection data: > > You can't have two components with the same ID inside a > group with the same origin. Okay, that was my understanding of the spec as well. >> My proposed approach was to encode the exact same data via a spec >> extension: >> >> >>Recommended >> >> >>Nightly builds >>foo-nightly >> > > I'm sorry, but that makes almost no sense. What is the software > center supposed to do with variantsummary? Is the application name the > same between the two variants? The variantsummary is meant to be used in the UI element for selecting a variant. > Should reviews for the different variants be treated as the same thing > or as different things? I would say reviews for all variants should be associated with the single component id. I guess reviews carry information about the version of the component that they were made for already, and the same mechanism could be used to say which variant they apply to. > I don't think it makes any sense at all making projects like GNOME > Software, Apper, Discover, Muon and Cockpit (and others) understand > much about the Fedora modularity stuff when everything seems to have > standardized on AppStream -- including next-generation distributions > methods like Flatpak. This is all optional. I am exploring what happens if a package with AppStream metainfo data appears in a module, and I think I have sketched out a path where we can do something correct/sensible with it that doesn't require any changes to existing AppStream consumers. A better path IMO is to decide that Software Centers don't want to see naked modules when dealing with Applications, just flatpaks or other containers. I wasn't sure that this is an acceptable option, but it looks like it is. >> If a client understands "variants", it can trivially expand them back >> into multiple entries for the same id. Clients that don't understand >> this will continue to just see one. > > They're two different things. Would gnome-software and cockpit show > two search entries for the two variants or one? One. > Would you be able to switch between the variants? Yes. > Can both be installed at the same time, by two different users on the > same system? No. >> Maybe I should emphasize that I am only trying to figure out what >> happens if we subject a modularized repository to the usual AppStream >> treatment. > > Can you provide some specifications on what a modularized repository > should actually look like please? Is a repo going to contain .rpm > packages like firefox-1.23.rpm and also firefox-2.34.rpm or something > completely different? This is a modularized repo, I think: https://kojipkgs.fedoraproject.org/compose/26/Fedora-Modular-26-20170720.0/compose/Server/x86_64/os/ It does contain both nodejs-6.10.3-2.module_9c237b2a.x86_64.rpm and nodejs-8.0.0-1.module_42d8f2a0.x86_64.rpm for example. I hope the modularity people on this list can provide more details. > Has anyone talked to the Fedora or GNOME designers about this? I will talk to our Cockpit designers, of course, once everyone is back from vacation. > I'm trying hard not to get frustrated about questions about XML schema > when I don't think anybody has considered the user experience of > modularity. Well, I have learned a lot already from this discussion, so thanks for that! > From a desktop point of view I'm currently of the opinion that it only > makes sense to show modules that are flatpaks, and continue to use the > appstream branch of the flatpak repository to get information about > the modules. This makes a lot of sense to me. >> I am happy to just say that modularized repositories don't have >> AppStream data, period. > > Why are you happy they don't have AppStream? I'm not sure trying to > antagonize the people involved is a very good idea at all. Sorry, again I should have been clearer: Instead of figuring out how to make AppStream work with modularized repositories, we can also say that we wont be installing applications as RPMs from modularized repositories (only as flatpaks etc), and thus a modularized repository doesn't need any AppStream data (period) and we don't need to figure out how the make that work. However, the general concept of variants of a single applications and letting the user choose between them is a good one, no? Firefox Regular, Firefox Nightly, and Firefox Fatfree _are_ related to each other and we can do better than just showing them next to each other in a list, no? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On 24.8.2017 08:04, Pavel Raiskup wrote: > On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote: >> Do you use Copr for building packages for nightlies? For building packages >> before pull request is merged? > > Yes, not particulary me -- but I helped to guys in pgjdbc project to setup CI: > > https://copr.fedorainfracloud.org/coprs/g/pgjdbc/pgjdbc-travis/ > https://github.com/pgjdbc/pgjdbc/blob/master/packaging/rpm/fedora-image/copr-ci-git > >> Do you have your set up described somewhere? > > No, since it is too complicated. Tito is a burden for distro-agnostic > upstream. > > Since upstream had travis-ci already enabled, my plan was to generate src.rpm > in > travis-ci and submit build into copr (together with other CI tasks). > > Two major problems: > 1. Travis is (or was that time) debian/ubuntu only, so it is actually not very >convenient to install all the necessary tooling there; so the work-around >was to use Fedora docker-image and that image is pulled in for each CI run. > > 2. You need to store your copr credentials into git. You can cipher that, but >at least it is not convenient to store *your own* copr authentication token >into git repo, because always at least other git committers can decipher > it. >You also need to re-generate your API token twice a year (it means you need >to bother the upstream with "useless" commits, but the worst thing is that >you need to regularly go back and pay attention to fixing the CI). > > Being able to specify (a) scm repo, (b) build deps and (c) any (turing > complete) > script within the git repo (to generate the sources) would make setting up the > CI a trivial task. +1 That is something that could help us definitely too. Nowadays we have scripts for packaging in Jenkins, that run tests and prepare SRPM for the COPR, that requires in addition changes in upstream repository itself (e.g. public spec file as part of the repository). More convenient would be (not only for our team, but for me too as packager) a) option to provide script in COPR, that will prepare sources, patches, modified SPEC file, ... on the COPR side. The script would be processed for example when I sent request to COPR for specific repository, with whatever data that will be processed by the script (e.g. commit hash, branch, PR number). b) store the specfile into the COPR repository, so it could be used by the script and it will not be required to be part of the upstream repository (usually the SPEC is not part of the upstream repo or we want different spec than upstream provides) I found now that in COPR is something that b) describes, but I am not sure that it is same. Still, own script that would prepare sources for COPR builds is the most missing feature for me. > > Pavel > >> What is the name of your >> project? >> >> Please let me know. Either here or via private reply. >> It will help me to understand your use of Copr and to make Copr better. >> >> Thanks in advance. >> >> Miroslav Suchy >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Petr Stodulka Core Services (In-place upgrades and migrations) IRC nicks: pstodulk, skytak Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modularizing the world fast and iteratively
Pavel Raiskup wrote: > Ok, I agree that Fedora needs modules for life-cycle separation. I don't. I consider what you call "life-cycle separation" (I'd rather call it "inconsistent EOLs") a bug rather than a feature. This is yet another of those "features" that sound great on paper, but lead to a horrible user experience in practice. Right now, it is easy to know when you have to upgrade, as there is one EOL for the entire distro. With inconsistent per-module EOLs, as soon as you have a non-trivial amount of modules installed, it is impossible to track down when you need to upgrade what. So either you end up with an unsupported version of the module without even noticing, or you get forcefully upgraded at what will often be the worst possible time. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modularizing the world fast and iteratively
On Thursday, August 24, 2017 3:20:12 AM CEST Kevin Kofler wrote: > Adam Samalik wrote: > > all their dependencies, we need to build them. But, for example, a pretty > > commonly needed thing like autotools [3] has pretty crazy build > > dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2, > > python3, etc. > > This is exactly why the separate Core and Extras were such a PITA and why > the Core-Extras Merge was done. Doing the opposite now is a BAD idea. I have similar feelings, unfortunately. Dependencies go here and there, new software version means different dependancy set; that's never-ending iteration in the distro ecosystem. Trying to draw a thick border line (called "circle") in Fedora Everything to separate the working ecosystem into smaller ecosystem (where packages in one set don't see the other sets) is IMO impossible without loosing some part of Fedora functionality (which is not acceptable as we spent too much power on it so far). Why I'm writing is the mentioned "autotools" keyword (for some reason it is privileged soon-to-be module, dunno why). We should first define "what belongs to autotools". But anyways... Making it a self-standing module is not easily possible. All the (build)deps are there for reason. We really don't want to have "language foo" support in Automake without having that tested during build-time (since that's the only testsuite the upstream can maintain). It means that build (and probably runtime) of Automake will depend on "lang foo" forever (and that's noarch, with library deps it is even worse). Why we are making problems from non-problem [4]? Ok, I agree that Fedora needs modules for life-cycle separation. But I don't understand why we start "bottom up" and not the other way around. Why we we start with the base build toolset like autotools, instead of with leaf packages on which (almost) nobody depends on? Good examples are { RHSCL } / { languages } ... Subtract language-collections as modularity doesn't solve "parallel install-ability" so multiple versions of Python versions won't be possible in module world (rhscl allows that). Pavel > Modularity may sound great on paper, but as soon as you actually try to > implement it, it falls apart like a house of cards. > > Kevin Kofler Adam wrote: > >[4] > >https://github.com/fedora-modularity/dependency-report/blob/original-plan/modules/autotools/all/buildtime-binary-packages-short.txt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: About retiring OmegaT from Fedora
On Tue, Aug 22, 2017 at 3:33 AM, Yaakov Selkowitz wrote: > > Then you should orphan it. If nobody takes it up, then it will be > automatically retired. > I thought about it, but it's so hard to update it seems to me to better retire and reduce the noise :-m -- Ismael Olea http://olea.org/diario/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR strategy
Dne 24.8.2017 v 04:10 Rudolf Kastl napsal(a): Hey, I am currently maintaining llvm trunk and mesa git snapshot repos for f25 and f26 at: https://copr.fedorainfracloud.org/coprs/che. One thing i would love to see is the ability to have a buildrepo and a release repo and beeing able to sync from build to release once a complete buildchain successfully built. More thorough description of the problem and a possible solution: * you have a dependency chain of 3 packages to build * you need to regen repos after each package because the next package in the tree depends on the first one. (like clang on llvm) * then after building the first 2 packages the 3rd package breaks ... you end up with a broken dep chain in the repo. You can do that: * go to Settings of project * Check "Create repositories manually" Build your 3 packages. During this stage your new builds will not be in available in project repository, but will be available via special /devel/ repository, which is available during build time in your Copr project. So your users will not see those package, but your builds will see it. You can even test it if it works if you change baseurl and append /devel/ to the end of url. Once finished go to the main page of your project and in right column click on "Regenerate" in "Regenerate Repositories" form. Finally you can go to Settings and uncheck "Create repositories manually". Mirek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
> On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote: >> Hello Fedora devels and users, >> >> more than three years ago, the same topic started discussion if we >> want >> this package in Fedora or not and how [1]. The discussion resulted >> mostly in flames and in the removal of the dependency on tcp_wrappers >> from systemd. But it was quite agreed that it is considered as a >> security layer for some users, if they use it correctly, or something >> that is or should be replaced by firewalls. >> >> So can we discuss it now once more without the affiliation to >> systemd? >> The fact is that we still do not have any other replacement except >> firewalls. But do we need one? >> >> The complete removal of the package is probably not a wise step, even >> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is >> still available in Arch [3] without other tools depending on it. To >> be >> fair, Debian [4] is still building tools (for example openssh) with a >> build-time support for it. >> >> My primary concern is OpenSSH, which upstream dropped support for >> tcp_wrappers three years ago (late 2014) [5] and since then we are >> maintaining one more downstream patch. But this effort should be >> coordinated among other components to simplify the transition for >> users >> who insist on using it (using tcpd). >> >> Removing the dependency will also allow us to trim the default >> install for few more Kb. >> >> If there will be no significant drawbacks, I will progress with >> filling >> a system wide change for Fedora 28 and I will pull the maintainers of >> other tolls using libwrap into the round and discussion. > > Hello, > In Fedora 26, there is over 50 packages using tcp_wrappers as a build- > time dependency: > > > Since I'm listed twice in there... > > With my packages and the situation with build time options I take the > position of enable as much as possible since our users don't get to pick > their compilation options. > > However tcp_wrappers is a legacy thing that no longer belongs in today's > world. > > I have no objection to a flag day in F28 development and dropping the build > option at some point, preferably before the thing that is no longer an alpha > ;) ... ie way before beta. With F-27 now branched off this can happen in F-28/rawhide now ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On 23/08/17 04:46 AM, Miroslav Suchý wrote: > Hi, > I am gathering informations about various use of CI with Copr. Do you > use Copr for building packages for nightlies? For building packages > before pull request is merged? Do you have your set up described > somewhere? What is the name of your project? > > Please let me know. Either here or via private reply. > It will help me to understand your use of Copr and to make Copr better. > > Thanks in advance. > > Miroslav Suchy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Running nightly Scribus. I had to manually set up as I found using scm-2 troublesome for svn repository given the lack of proper documentation. It will be nice to have a mechanism to tarball a svn repository then use the spec file. -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
On 24 August 2017 at 08:45, Marius Vollmer wrote: > If appstream-builder finds two packages that both contain metainfo for > the same component id, what does it do? If I understand correctly, in appstream-builder it's an error, and the "first encountered" component wins. > What should it do? What should > the Software Center do. This isn't described in the AppStream spec > beyond the "merge" and "pripority" attributes for the tag. You have to remember, the AppStream spec was initially designed as a way to map application IDs to package names. AppStream metadata is written by basically every distro and consumed by every software center, and it's not Fedora specific, so you probably shouldn't be super surprised it doesn't map into the Fedora modularity system very well. My personal feeling is that this whole modularity initiative is being pushed hard into all layers of Fedora without actually working out how this is going to work with the various upstream specifications and projects. I'm sure it'll be great for Fedora in the short term, but longer term it's going to hurt being a little island of Fedora-specific schemas and tools. > One approach is just to put them all into the collection data: You can't have two components with the same ID inside a group with the same origin. > This is what they do for Flatpaks if I understand Owen correctly. No, flatpaks components have different names for each different branch. e.g. the org.mozilla.Firefox.Nightly.desktop thing I explained in my last email. > I had assumed that the spec doesn't allow this and I thought that > changing it to allow it would be too drastic. If this is established > practice and we just need to update the spec to catch up with reality, > great! No, please can you re-read mine and Owens previous emails please. > My proposed approach was to encode the exact same data via a spec > extension: > > >Recommended > > >Nightly builds >foo-nightly > I'm sorry, but that makes almost no sense. What is the software center supposed to do with variantsummary? Is the application name the same between the two variants? Should reviews for the different variants be treated as the same thing or as different things? To me a module is a superset of a set of packages, much like a -- so it would make sense to have something like org.fedoraproject.modularity.http2-6 which contains the translated name, the translated description, the SPDX license, and any URL links too. Of course, this is mostly the same as the modulemd metadata as specified https://docs.pagure.org/modularity/development/building-modules/developing.html so you can certainly create AppStream from that pretty easily. I don't think it makes any sense at all making projects like GNOME Software, Apper, Discover, Muon and Cockpit (and others) understand much about the Fedora modularity stuff when everything seems to have standardized on AppStream -- including next-generation distributions methods like Flatpak. > If a client understands "variants", it can trivially expand them back > into multiple entries for the same id. Clients that don't understand > this will continue to just see one. They're two different things. Would gnome-software and cockpit show two search entries for the two variants or one? Would you be able to switch between the variants? Can both be installed at the same time, by two different users on the same system? If the modules are flatpaks then they're two different components with two different AppIDs, that can both be installed at the same time. I'm having a very hard time working out how we'd communicate difficult to understand concepts to the end user using packages, even wrapped up with modulemd metadata. > Maybe I should emphasize that I am only trying to figure out what > happens if we subject a modularized repository to the usual AppStream > treatment. Can you provide some specifications on what a modularized repository should actually look like please? Is a repo going to contain .rpm packages like firefox-1.23.rpm and also firefox-2.34.rpm or something completely different? If both packages contain a metainfo/appdata file with the same component it's just not going to work very well using appstream-builder. > I think we would create broken AppStream collection data right now, or > at least AppStream data that doesn't let us take advantage of the new > features that modularity enables (streams and profiles). Has anyone talked to the Fedora or GNOME designers about this? I'm trying hard not to get frustrated about questions about XML schema when I don't think anybody has considered the user experience of modularity. From a desktop point of view I'm currently of the opinion that it only makes sense to show modules that are flatpaks, and continue to use the appstream branch of the flatpak repository to get information about the modules. > I am happy to just say that modulari
Re: COPR strategy
2017-08-22 5:17 GMT+02:00 Michal Novotny : > Hello, > > we will have soon a planning meeting that should determine a more long-term > strategy and bring us to a team agreement on what COPR currently is and what > it should be in half a year or so. > > I would like to kindly ask for some input here on the devel list to find out > what the actual expectations of COPR are and if there are any ideas about > what could COPR bring to the game. > Hi, I would like to be able to build for more arches, mainly arm. I guess the limitation is because hardware for that architecture is needed. Is not possible to cross-build the packages? It would be great if the noarch packages were available to all architectures. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR strategy
Hello Rudolf, On Thu, Aug 24, 2017 at 4:10 AM, Rudolf Kastl wrote: > Hey, > > I am currently maintaining llvm trunk and mesa git snapshot repos for f25 > and f26 at: https://copr.fedorainfracloud.org/coprs/che. > > One thing i would love to see is the ability to have a buildrepo and a > release repo and beeing able to sync from build to release once a complete > buildchain successfully built. > > More thorough description of the problem and a possible solution: > > * you have a dependency chain of 3 packages to build > * you need to regen repos after each package because the next package in > the tree depends on the first one. (like clang on llvm) > * then after building the first 2 packages the 3rd package breaks ... you > end up with a broken dep chain in the repo. > > Now a workaround would be to do scratch builds first and then final repo > builds. But e.g. for llvm (only the llvm library) that means... over 100 > minutes buildtime using 4 builders (32bit / 64bit for 2 distro versions). > > What i would love to see is to be able to build in one repository and then > send (copy/rsync whatever) the built chain over to a release repository. > This way also testing is possible before pushing the stuff to consumers. > > So, this is interesting. This is something like auto-forking from one project to another after a successful batch build (under development). It actually could work just inside one project if the batch building would be done separately from the main project repo and only be included if successful. Ok, thanks for this input. I think we can do something about this. > kind regards, > Rudolf Kastl > > > > 2017-08-22 17:15 GMT+02:00 Kamil Dudka : > >> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote: >> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka wrote: >> > > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote: >> > > > Hey Kamil, >> > > > >> > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka >> wrote: >> > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote: >> > > > > > - the ability to directly upload srpms; that is, one can store >> spec >> > > > > > >> > > > > > files etc. on the local machine. I'm undecided, if >> integrating a >> > > > > > distgit on copr would solve any issues or would introduce >> more, >> > > >> > > like >> > > >> > > > > > diverging specs. >> > > > > >> > > > > Building packages from dist-git is already possible via 'copr >> > > > > buildfedpkg'. >> > > > > The problem is that the last time I tried, it only worked for the >> > > >> > > official >> > > >> > > > > Fedora branches. All attempts to build something from a >> > > >> > > private-kdudka-* >> > > >> > > > > branch failed with the well known "Could not find the dist from >> branch >> > > > > name" >> > > > > failure of fedpkg. Unless arbitrary dist-git branches are >> suported, >> > > >> > > the >> > > >> > > > > 'copr buildfedpkg' command is pretty useless. >> > > > >> > > > Actually, we already support arbitrary dist-git branches in COPR >> > > >> > > Sounds good. I wanted to check this: >> > > >> > > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url >> > > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp >> > > >> > > Build was added to tmp: >> > > https://copr.fedorainfracloud.org/coprs/build/592748/ >> > > >> > > Created builds: 592748 >> > > Watching build(s): (this may be safely interrupted) >> > > >> > > 16:20:56 Build 592748: importing >> > > >> > > But the task hangs indefinitely in the "importing" state. You can see >> > > that >> > > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log >> still >> > > grows with obvious periodicity. >> > > >> > > Am I doing anything wrong? >> > >> > Uh, not really. fedpkg was not installed on the production machine thus >> the >> > import was failing. >> > Note that this is still slightly under development but it should >> definitely >> > work as a feature in >> > any case. >> >> OK. Thank you for working on it! I am looking forward to use it one >> day... >> >> > > Kamil >> > > >> > > > and we also aim >> > > > to be able to build from any dist-git (at least being based on >> > > > https://src.fedoraproject.org/rpms/dist-git). >> > > > >> > > > Currently we also support building from copr-dist-git in addition to >> > > >> > > Fedora >> > > >> > > > DistGit but >> > > > we need to reflect that in our API and in copr-cli interface by >> renaming >> > > > the subcommand. >> > > > (or providing the new generic one while keeping the old one for some >> > > >> > > time) >> > > >> > > > Then there is actually also the new rpkg client (based on pyrpkg >> lib): >> > > > https://src.fedoraproject.org/rpms/rpkg-client >> > > > that you can use for launching COPR builds from any dist-git repo >> being >> > > > locally checked out. >> > > > >> > > > > Kamil >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To u
%py3_install fails to accept arguments
Hi, I'm getting failed builds [1] in rawhide and f27 because the macro %py3_install fails when called with arguments. It was fine until f26. The package is rhythmbox-ampache, and I call the macro like this: %global py_install_args --no-glib-compile-schemas %install %py3_install %py_install_args This is the error I get: py3_install: invalid option -- '-' error: Unknown option - in py3_install() error: line 31: %py3_install %py_install_args Building target platforms: x86_64 Building for target x86_64 Child return code was: 1 EXCEPTION: [Error()] Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 89, in trace result = func(*args, **kw) File "/usr/lib/python3.5/site-packages/mockbuild/util.py", line 582, in do raise exception.Error("Command failed. See logs for output.\n # %s" % (command,), child.returncode) How should I pass this argument? [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=21417370 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
Richard Hughes writes: > On 23 August 2017 at 13:57, Marius Vollmer wrote: > >> I propose to keep AppStream metainfo data in packages, and map from >> package names to module names during construction of the collection >> data. > > Can you elaborate a bit? At the moment in Fedora we generate the > AppStream metadata from a mirror of all the packages using > appstream-builder. When creating the AppStream collection data for a modularized repository, we might want to insert information about the modules that a package belongs to into the collection data, maybe as a tag. So we need to have a function that takes a package name and returns a list of (module name, stream, profile) tuples. (Alternatively, we could require that the modulemd data for a module contains everything we need for the AppStream collection data. I was proposing not to do this and just keep looking at the packages.) >> - Because of streams and profiles, there can be multiple versions of >>metainfo for a given AppStream component id. These need to be >>merged > > No, I don't think they do. If you have two very different versions of > Firefox (one LTS, one bleeding edge) you want a different description, > different screenshots and different reviews. Sorry, I wasn't clear. I shouldn't have said "merged". If appstream-builder finds two packages that both contain metainfo for the same component id, what does it do? What should it do? What should the Software Center do. This isn't described in the AppStream spec beyond the "merge" and "pripority" attributes for the tag. One approach is just to put them all into the collection data: com.example.foo Foo foo com.example.foo Foo foo-nightly This is what they do for Flatpaks if I understand Owen correctly. I had assumed that the spec doesn't allow this and I thought that changing it to allow it would be too drastic. If this is established practice and we just need to update the spec to catch up with reality, great! My proposed approach was to encode the exact same data via a spec extension: com.example.foo Foo foo Recommended Nightly builds foo-nightly If a client understands "variants", it can trivially expand them back into multiple entries for the same id. Clients that don't understand this will continue to just see one. Maybe I should emphasize that I am only trying to figure out what happens if we subject a modularized repository to the usual AppStream treatment. I think we would create broken AppStream collection data right now, or at least AppStream data that doesn't let us take advantage of the new features that modularity enables (streams and profiles). I am happy to just say that modularized repositories don't have AppStream data, period. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
On Thursday, August 24, 2017 2:32:02 AM CEST Moez Roy wrote: > On Mon, Jul 31, 2017 at 12:13 PM, Kevin Fenzi wrote: > > ok, I rebuilt the following ones. The ones with F next to them failed to > > > > build: > > autotrace-0.31.1-44.fc26.src.rpm > > converseen-0.9.6.2-1.fc27.src.rpm > > dmtx-utils-0.7.4-2.fc27.src.rpm > > drawtiming-0.7.1-20.fc26.src.rpm > > > > F gtatool-2.2.0-4.fc27.src.rpm > > > > imageinfo-0.05-25.fc26.src.rpm > > inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm > > kxstitch-1.2.0-7.fc26.src.rpm > > perl-Image-SubImageFind-0.03-11.fc27.src.rpm > > pfstools-2.0.6-1.fc27.src.rpm > > > > F php-magickwand-1.0.9.2-9.fc24.src.rpm > > F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm > > > > psiconv-0.9.8-20.fc26.src.rpm > > q-7.11-27.fc27.src.rpm > > ripright-0.11-3.fc26.src.rpm > > rss-glx-0.9.1.p-29.fc26.src.rpm > > > > F rubygem-rmagick-2.16.0-3.fc26.src.rpm > > F synfig-1.2.0-5.fc27.src.rpm > > > > (boost issues) > > > > F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm > > > > (needs synfig) > > vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm > > vips-8.5.6-1.fc27.src.rpm > > WindowMaker-0.95.8-1.fc27.src.rpm > > > > F cuneiform > > > > (some c++ blowup) > > k3d > > > > With that I think rawhide should be back on track. > > > > If all looks well for a bit I guess I can try and do f25/f26. > > > > kevin > > The soname bump requires packages that depend on it need to be rebuilt, so > I updated ImageMagick to 7.0.6-9. Why are you updating it in stable Fedora then? Two less serious problems with your changes: - Please consider using commit messages that are useful for others. - Please avoid committing unnecessary white-space changes. If you really think they are necessary, please commit them separately from any functional changes. Thanks! Kamil > I tagged this update now for Updates Testing for f25 & f26 as it is an > urgent fix. > > It is also in build root override so affected packages can now be rebuilt. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
Owen Taylor writes: > The current expectation is that the only way that modules are going to > show up in GNOME Software is when they are safely wrapped up as a > Flatpak. Ah, that's nice. If we follow the same line for Cockpit, we would only show container images. This would certainly simplify things. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
Le 24/08/2017 à 08:58, Adam Williamson a écrit : > On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote: >> Le 24/08/2017 à 02:32, Moez Roy a écrit : >> >>> The soname bump requires packages that depend on it need to be rebuilt, so >>> I updated ImageMagick to 7.0.6-9. >> >> >> Such a version bump in stable branch is not acceptable. >> >> ImageMagick 7 removed lot of functions (deprecated in v6) >> >> Especially as ImageMagick 6 is still maintained. >> >> BTW, latest version 6.9.9-9 also have some API changes >> >> - 6.9.6-8 => bump to .3 >> - 6.9.7-6 => bump to .4 >> - 6.9.9-0 => bump to .5 >> >> Yes, this package is a nightmare. > > Note the versioning is a bit subtle. What was released upstream was > 6.9.9-9 , which in our versioning would be 6.9.9.9 . Upstream *didn't* > go from 6.9.8 to 6.9.9, but from 6.9.9-8 to 6.9.9-9. The package in > Fedora before all this mess was versioned 6.9.9.3 , which I believe > would be upstream's 6.9.9-3 , and I *think* there is no ABI/API > incompatibility between 6.9.9-3 and 6.9.9-9. The soname in the 6.9.9.3 > packages was already > "libMagickCore-6.Q16.so.5()(64bit)". Yes in F27+ (6.9.9.3) F25/F26 have 6.9.3.0 (upstream 6.9.3-0) with libMagickCore-6.Q16.so.2 libMagickWand-6.Q16.so.2 Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
On 18 Aug 2017 4:42 pm, "Jakub Jelen" wrote: On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote: > Hello Fedora devels and users, > > more than three years ago, the same topic started discussion if we > want > this package in Fedora or not and how [1]. The discussion resulted > mostly in flames and in the removal of the dependency on tcp_wrappers > from systemd. But it was quite agreed that it is considered as a > security layer for some users, if they use it correctly, or something > that is or should be replaced by firewalls. > > So can we discuss it now once more without the affiliation to > systemd? > The fact is that we still do not have any other replacement except > firewalls. But do we need one? > > The complete removal of the package is probably not a wise step, even > though we can not find tcp_wrappers in recent SuSE anymore [2]. It is > still available in Arch [3] without other tools depending on it. To > be > fair, Debian [4] is still building tools (for example openssh) with a > build-time support for it. > > My primary concern is OpenSSH, which upstream dropped support for > tcp_wrappers three years ago (late 2014) [5] and since then we are > maintaining one more downstream patch. But this effort should be > coordinated among other components to simplify the transition for > users > who insist on using it (using tcpd). > > Removing the dependency will also allow us to trim the default > install for few more Kb. > > If there will be no significant drawbacks, I will progress with > filling > a system wide change for Fedora 28 and I will pull the maintainers of > other tolls using libwrap into the round and discussion. Hello, In Fedora 26, there is over 50 packages using tcp_wrappers as a build- time dependency: Since I'm listed twice in there... With my packages and the situation with build time options I take the position of enable as much as possible since our users don't get to pick their compilation options. However tcp_wrappers is a legacy thing that no longer belongs in today's world. I have no objection to a flag day in F28 development and dropping the build option at some point, preferably before the thing that is no longer an alpha ;) ... ie way before beta. As for downstream ... well we're Fedora. If Red Hat want it still in RHEL8 that's up to them and they can maintain the downstream patches in their distro still. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ppisar pushed to perl-Shell-Config-Generate (f27). "0.28 bump"
From 6f9f8dfc0e762c2ce44802b3119443ac919de853 Mon Sep 17 00:00:00 2001 From: Petr Písař Date: Aug 24 2017 07:03:18 + Subject: 0.28 bump --- diff --git a/.gitignore b/.gitignore index 756dc05..4e69ac4 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ /Shell-Config-Generate-0.26.tar.gz +/Shell-Config-Generate-0.28.tar.gz diff --git a/.rpmlint b/.rpmlint new file mode 100644 index 000..774a6e6 --- /dev/null +++ b/.rpmlint @@ -0,0 +1,2 @@ +from Config import * +addFilter("spelling-error .* (cmd|csh|exe|Portably)"); diff --git a/perl-Shell-Config-Generate.spec b/perl-Shell-Config-Generate.spec index 8c2c025..af1b1f4 100644 --- a/perl-Shell-Config-Generate.spec +++ b/perl-Shell-Config-Generate.spec @@ -1,5 +1,5 @@ Name: perl-Shell-Config-Generate -Version:0.26 +Version:0.28 Release:1%{?dist} Summary:Portably generate configuration for any shell License:GPL+ or Artistic @@ -18,13 +18,17 @@ BuildRequires: perl(Carp) BuildRequires: perl(Exporter) BuildRequires: perl(Shell::Guess) >= 0.02 # Tests: +BuildRequires: perl(base) BuildRequires: perl(Config) BuildRequires: perl(constant) +BuildRequires: perl(Env) BuildRequires: perl(File::Spec) BuildRequires: perl(File::Temp) BuildRequires: perl(FindBin) # IPC::Open3 not used +BuildRequires: perl(lib) BuildRequires: perl(Test::More) >= 0.94 +BuildRequires: perl(Test2::API) >= 1.302015 Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version)) Requires: perl(Shell::Guess) >= 0.02 @@ -57,5 +61,8 @@ make test %{_mandir}/man3/* %changelog +* Thu Aug 24 2017 Petr Pisar - 0.28-1 +- 0.28 bump + * Fri Jul 21 2017 Petr Pisar 0.26-1 - Specfile autogenerated by cpanspec 1.78. diff --git a/sources b/sources index 99f6efb..6e213c3 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -SHA512 (Shell-Config-Generate-0.26.tar.gz) = 8b37e8054ca3af8670a61672364e9fda397a2d2eeb85bf5ccdd3266714e9fecb8fd7a16812d8990ce676e526c8e76224d5ab1c5aaa8ddeec5e14f551b8cc7f70 +SHA512 (Shell-Config-Generate-0.28.tar.gz) = 429ff8760c7ba7d91b318e97382b2742969e8823bd5561b95f2e000f582964c49a41176cfeaf90bef7916376a91c0d5a05eb01e4598ba703fb4f5c46fdc0f1cf https://src.fedoraproject.org/rpms/perl-Shell-Config-Generate/c/6f9f8dfc0e762c2ce44802b3119443ac919de853?branch=f27 ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Wed, 23 Aug 2017 22:16:40 -0500 Michael Cronenworth wrote: > Hi all, > > An ImageMagick update (6.9 => 7.0) with an SONAME bump and other > breakage has been pushed to F25 and higher. > > First, the update introduces regressions on s390x and ppc64 arches. > - https://bugzilla.redhat.com/show_bug.cgi?id=1484578 > - https://bugzilla.redhat.com/show_bug.cgi?id=1484579 these issues shouldn't have been solved with an ExcludeArch immediately as there is a risk of breaking buildroots for other packages and for other teams like modularity. If such problem happens, please contact us (the alternative-arches team) first, so we can plan the best action. Thanks Dan > Secondly, rebuilds are required for: > >autotrace-0.31.1-44.fc26.src.rpm >converseen-0.9.6.2-1.fc27.src.rpm >dmtx-utils-0.7.4-2.fc27.src.rpm >drawtiming-0.7.1-20.fc26.src.rpm > F gtatool-2.2.0-4.fc27.src.rpm >imageinfo-0.05-25.fc26.src.rpm >inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm >kxstitch-1.2.0-7.fc26.src.rpm >perl-Image-SubImageFind-0.03-11.fc27.src.rpm >pfstools-2.0.6-1.fc27.src.rpm > F php-magickwand-1.0.9.2-9.fc24.src.rpm > F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm >psiconv-0.9.8-20.fc26.src.rpm >q-7.11-27.fc27.src.rpm >ripright-0.11-3.fc26.src.rpm >rss-glx-0.9.1.p-29.fc26.src.rpm > F rubygem-rmagick-2.16.0-3.fc26.src.rpm > F synfig-1.2.0-5.fc27.src.rpm >(boost issues) > F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm >(needs synfig) >vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm >vips-8.5.6-1.fc27.src.rpm >WindowMaker-0.95.8-1.fc27.src.rpm > F cuneiform >(some c++ blowup) >k3d > > The ones with F have possible compile issues. > > Thirdly, two updates have been created. I've disabled autopush on > them. > - https://bodhi.fedoraproject.org/updates/FEDORA-2017-0a1f3de4eb > - https://bodhi.fedoraproject.org/updates/FEDORA-2017-c276ee400a > > It is really late here and I don't have the time to investigate the > arch issues right now. I'll investigate when I can. > ___ devel mailing list -- > devel@lists.fedoraproject.org To unsubscribe send an email to > devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] Modules and AppStream
Richard Hughes writes: > On 23 August 2017 at 13:57, Marius Vollmer wrote: > >> - Metainfo is in packages, but we need to be installing modules. > > How are we going to be installing modules in a modular-system? > PackageKit is only going to be able to install packages so > gnome-software will obviously need to be able to install things. My understanding from playing with Boltron is that "dnf install foo" treats "foo" as a module name. "dnf install" can not install packages anymore. So naively I assume that PackageKit will transparently start installing modules. (I think PK uses libdnf, and I think I read somewhere that libdnf doesn't do anything with modules yet, so...) Bu then again, this all feels quite half baked, so maybe I shouldn't make assumptions based on what Boltron does today. Witness: # docker run --rm -it modularitycontainers/boltron-preview /bin/bash boltron# dnf info guile Name : guile Epoch: 5 Version : 2.0.14 Release : 1.module_39876f37 Arch : x86_64 Size : 3.5 M Source : guile-2.0.14-1.module_39876f37.src.rpm Repo : fedora-modular [...] boltron# dnf install guile No such module: guile Dependencies resolved. Nothing to do. Complete! > [...] > > I don't think you can pretend that applications from different > branches (with different features, bugs and possibly UI) are the > "same" component, especially when you can install zero, one or many at > the same time. With modules, you can not install more than one stream at any time. I think the idea is that module streams provide different versions of packages without having to change the packages in any way. Thus, packages from different streams will mostly likely conflict with each other. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)
On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote: > Le 24/08/2017 à 02:32, Moez Roy a écrit : > > > The soname bump requires packages that depend on it need to be rebuilt, so > > I updated ImageMagick to 7.0.6-9. > > > Such a version bump in stable branch is not acceptable. > > ImageMagick 7 removed lot of functions (deprecated in v6) > > Especially as ImageMagick 6 is still maintained. > > BTW, latest version 6.9.9-9 also have some API changes > > - 6.9.6-8 => bump to .3 > - 6.9.7-6 => bump to .4 > - 6.9.9-0 => bump to .5 > > Yes, this package is a nightmare. Note the versioning is a bit subtle. What was released upstream was 6.9.9-9 , which in our versioning would be 6.9.9.9 . Upstream *didn't* go from 6.9.8 to 6.9.9, but from 6.9.9-8 to 6.9.9-9. The package in Fedora before all this mess was versioned 6.9.9.3 , which I believe would be upstream's 6.9.9-3 , and I *think* there is no ABI/API incompatibility between 6.9.9-3 and 6.9.9-9. The soname in the 6.9.9.3 packages was already "libMagickCore-6.Q16.so.5()(64bit)". -- 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 To unsubscribe send an email to devel-le...@lists.fedoraproject.org