Build weirdness

Hi I've got another weird situation: I wanted to get pjproject building again, rebased and added necessary patches, did the scratch build, and all looked good [1]. So I went ahead and committed the result, fired off the build, but to my surprise that build failed while applying the patches

Re: Review swaps

On 29.08.2017 13:10, Juan Orti Alcaine wrote: 2017-08-29 13:02 GMT+02:00 Sandro Mani <manisan...@gmail.com>: Hi I have https://bugzilla.redhat.com/show_bug.cgi?id=1486278 I'll take svg2svgt, if you create more review requests, just tell me. Thanks, I've started with python-subliminal

Re: Review swaps

Hi I have https://bugzilla.redhat.com/show_bug.cgi?id=1486278 as well as a big load of mingw packages [1]. If you're okay with reviewing mingw stuff I can prepare review requests for them. Thanks Sandro [1] https://github.com/manisandro/fedora-mingw On 29.08.2017 12:31, Juan Orti

Re: Mass package change (python2- binary package renaming)

On 28.08.2017 10:04, Johannes Lips wrote: I would like to add, that apparently the capitalization of subpackages also changed. This broke dependencies for me. I don't know if this was intended. Please see: https://bugzilla.redhat.com/show_bug.cgi?id=1485703 If it was intended, I am happy to

Re: Mysterious build, perhaps tagged to wrong release?

On 28.08.2017 02:03, Kevin Kofler wrote: Sandro Mani wrote: Right, I suppose given the smallish audience affected by this, it's better to violate the update guidelines once than introducing a permanent epoch bump. FYI, there are still ongoing plans to upgrade the native qt5-qtbase in F26

Re: Mysterious build, perhaps tagged to wrong release?

On 26.08.2017 21:33, Adam Williamson wrote: so really, you'd have to stick with 5.8.0 - just do some kinda merge back to the 5.8.0-3 state, then do your bump and rebuild on top of that - or do an epoch-bumped update to go back down to 5.7.1. Right, I suppose given the smallish audience

Mysterious build, perhaps tagged to wrong release?

Hi I've got an odd situation with mingw-qt5-qtbase on f26: in git, I have version 5.7.1, however there is a mingw-qt5-qtbase-5.8.0-3.fc26 in koji [2] which I cannot understand where it came from, considering also that other 5.7.1-x versions have been built since. I'm now in the situation

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

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

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

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

alglib soname bump

Hi I'm updating to alglib-3.12.0 in rawhide and F27, I'll rebuild the following dependent packages: gmsh-3.0.4-1.fc27.src.rpm qmapshack-1.9.0-1.fc27.src.rpm Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Review requests: perl-Regexp-Pattern, perl-Regexp-Pattern-License

Hi I needs these simple perl packages reviewed to fix broken dependencies introduced in licensecheck-3.0.31 (the reason it actually built successfully was that licensecheck-3.0.30 actually provided perl(Regexp::Pattern::License), fact which I missed, but now 3.0.31 can't be installed since

Re: openjpeg-2.2.0

On 10.08.2017 17:42, Richard Shaw wrote: On Thu, Aug 10, 2017 at 10:41 AM, Richard Shaw > wrote: You can check the api compliance with abi-compliance-checker first to be sure... $ abi-compliance-checker -L openjpeg -vnum

openjpeg-2.2.0

Hi openjpeg-2.2.0 was just release, carrying a large number of security fixes. I'd also like to update it for F25 and F26, since it is ABI and API compatible with 2.1.x, there is however the problem that openjpeg2 installs its headers under /usr/include/openjpeg-$major.$minor, so this would

Re: Debuginfo/debugsource: mingw package with mixed host and target debuginfos

A workaround that probably gets you past the build failure for now is to just revert rpm to its old logic by adding the following to your spec file: %undefine _debugsource_packages %undefine _debuginfo_subpackages Thanks, that worked for now. [2]

Debuginfo/debugsource: mingw package with mixed host and target debuginfos

Hi mingw-qt5-qtbase and mingw-qt5-qttools are currently FTBFS [1] due to errors like error: Could not open %files file /builddir/build/BUILD/qtbase-opensource-src-5.9.1/debugsourcefiles.list: No such file or directory Duplicate build-ids

Re: GNU Ring

Hi I periodically give it a try, but so far it was too unstable. My specs are here [1] if you want to give it a try. Sandro [1] https://smani.fedorapeople.org/ring/ On 01.08.2017 19:47, Jos Vos wrote: Hi, Are there any plans to add Ring (https://ring.cx/en) to Fedora? Cheers, -- --

Review swap: qbs - Cross platform build tool

Hi Upstream notified me that the way qbs is currently packaged (as part of qt-creator) is wrong, and that it should live in a separate package with the correct version (instead of using the qt-creator version). The review request for the split-off qbs package is here:

Re: Mingw RPM deps broken [Re: Fedora rawhide compose report: 20170708.n.0 changes]

On 10.07.2017 10:52, Daniel P. Berrange wrote: It appears that the /usr/lib/rpm/mingw-find-{requires,provides}.sh scripts are broken. New builds are ending up with almost no provides lists, which is in turn causing all dependant packages to report broken deps like this.

Re: Review swaps

Hi Ben I'm happy to take the first two in exchange for https://bugzilla.redhat.com/show_bug.cgi?id=1461368 https://bugzilla.redhat.com/show_bug.cgi?id=1465676 which are simple C/C++ MinGW packages. Deal? Thanks Sandro On 03.07.2017 19:58, Ben Rosser wrote: Hi, I have a handful of packages

Re: Review request: mingw-pcre2 - MinGW Windows pcre2 library

On 27.06.2017 17:55, Sandro Mani wrote: Hi I need mingw-pcre2 to update mingw-qt5-* to 5.9.0. Review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=1461368 Happy to review in exchange. And one more: mingw-graphite2 - https://bugzilla.redhat.com/show_bug.cgi?id=1465676

Review request: mingw-pcre2 - MinGW Windows pcre2 library

Hi I need mingw-pcre2 to update mingw-qt5-* to 5.9.0. Review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=1461368 Happy to review in exchange. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send

Re: Orphaned Packages in rawhide (2017-06-25)

On 27.06.2017 02:59, Adam Williamson wrote: On Sun, 2017-06-25 at 00:01 +, t...@fedoraproject.org wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired,

Re: Retiring Packages with Broken Dependencies in branched (2017-06-26)

On 26.06.2017 09:02, t...@fedoraproject.org wrote: qgis volter, bruno, daveisfera, 162 weeks ago orion, rezso I've launched new qgis builds for rawhide and f26 disabling parallel build as a quick workaround for the build failure.

Re: Updates not getting pushed to stable

On 08.06.2017 00:36, Peter Robinson wrote: On Wed, Jun 7, 2017 at 11:22 PM, Sandro Mani <manisan...@gmail.com> wrote: Hi, I've got a couple of updates which are stuck waiting to get pushed to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e46ec0bbe8

Updates not getting pushed to stable

Hi, I've got a couple of updates which are stuck waiting to get pushed to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e46ec0bbe8 https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c1569283 https://bodhi.fedoraproject.org/updates/FEDORA-2017-192daab41c The last two I tried

Re: Koji build failure: OverflowError: long int exceeds XML-RPC limits

On 11.05.2017 16:58, Michael Mraka wrote: Sandro Mani: Hi I've tried a couple of times to build mingw-qt5-qtquick1 [1], but the task consistently fails after the actual build succeded [2], seemingly when moving the rpms or tagging the build, with the following message: Traceback (most

Koji build failure: OverflowError: long int exceeds XML-RPC limits

Hi I've tried a couple of times to build mingw-qt5-qtquick1 [1], but the task consistently fails after the actual build succeded [2], seemingly when moving the rpms or tagging the build, with the following message: Traceback (most recent call last): File

Re: Package with spec name != packagename.spec

On 06.03.2017 17:09, Martin Bříza wrote: On Mon, 06 Mar 2017 17:03:51 +0100, Sandro Mani <manisan...@gmail.com> wrote: Hi I just came across a package (mingw-qt5-qtquickcontrols) whose specfile isn't named .spec (in this case, mingw-qtquickcontrols.spec instead of min

Package with spec name != packagename.spec

Hi I just came across a package (mingw-qt5-qtquickcontrols) whose specfile isn't named .spec (in this case, mingw-qtquickcontrols.spec instead of mingw-qt5-qtquickcontrols.spec). As I understand it this is against the guildelines? (Shouldn't the build actually fail?) Can I just fix it by

Re: ActionNotAllowed: policy violation (build_from_srpm)

On 23.02.2017 01:36, Kevin Fenzi wrote: On Wed, 22 Feb 2017 21:19:52 +0100 Sandro Mani <manisan...@gmail.com> wrote: On 22.02.2017 19:36, Kevin Fenzi wrote: On Wed, 22 Feb 2017 18:52:35 +0100 Sandro Mani <manisan...@gmail.com> wrote: Hi Anyone an idea what's going on her

Re: ActionNotAllowed: policy violation (build_from_srpm)

On 22.02.2017 19:36, Kevin Fenzi wrote: On Wed, 22 Feb 2017 18:52:35 +0100 Sandro Mani <manisan...@gmail.com> wrote: Hi Anyone an idea what's going on here? $ fedpkg build Building mingw-eigen3-3.3.3-1.fc26 for rawhide Created task: 17994713 Task info: https://koji.fedoraproject.or

ActionNotAllowed: policy violation (build_from_srpm)

Hi Anyone an idea what's going on here? $ fedpkg build Building mingw-eigen3-3.3.3-1.fc26 for rawhide Created task: 17994713 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=17994713 Watching tasks (this may be safely interrupted)... 17994713 build (rawhide,

Re: Fedora mass rebuild 2017

On 16.02.2017 13:02, Jonathan Wakely wrote: On 16/02/17 10:15 +, Jonathan Wakely wrote: On 15/02/17 22:53 -0500, Orcan Ogetbil wrote: On 15 February 2017 at 09:12, Jonathan Wakely wrote: A mockchain build of dbus-c++ libffado and sflphone works with this patch. repoquery says nothing

Re: BuildRequire debuginfo for debugging?

On 14.02.2017 12:21, Richard W.M. Jones wrote: On Mon, Feb 13, 2017 at 11:07:05PM +0100, Sandro Mani wrote: On 13.02.2017 21:35, Dan Horák wrote: ask Fedora infra guys for a ppc64/ppc64le VM and debug it locally? Well the debuginfo trick would have been a quick way to get a stacktrace

Re: BuildRequire debuginfo for debugging?

On 13.02.2017 21:35, Dan Horák wrote: ask Fedora infra guys for a ppc64/ppc64le VM and debug it locally? Well the debuginfo trick would have been a quick way to get a stacktrace, but sure, if there are any VMs available that would also work. ___

BuildRequire debuginfo for debugging?

Hi I'm trying to gather a good stacktrace of a qbs crash on aarch64/ppc64/ppc64le and I managed to collect something by prepending gdb -batch -ex "run" -ex "bt full" --args to the qbs calls. So far so good [1], but now I'm wondering if there is a way to get some *-debuginfo packages

Re: HEADS UP: libwebp-0.6.0 soname bumps

On 02.02.2017 22:03, Jonathan Wakely wrote: On 02/02/17 10:02 +0100, Sandro Mani wrote: On 01.02.2017 18:59, Sandro Mani wrote: Hi I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, which include soname bumps. I'm rebuilding all of the dependent packages: A quick

Re: HEADS UP: libwebp-0.6.0 soname bumps

On 01.02.2017 23:58, Björn 'besser82' Esser wrote: Hi Sandro, could you please tell me, when gnuplot has been rebuilt successfully? Gnuplot is now built. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Dependency rebuild order

On 02.02.2017 10:40, Honza Silhan wrote: Hi, my former colleague was investigating how to do it. This task had been already solved by the mach project available at http://thomas.apestaart.org/projects/mach/ and packaged in Fedora under the same name. Interesting bits are inside

Re: HEADS UP: libwebp-0.6.0 soname bumps

On 02.02.2017 08:49, Kalev Lember wrote: On 02/02/2017 08:12 AM, Kalev Lember wrote: Hi Sandro, Thanks for working on this! The number of packages affected by the soname bump is quite big though and I think it needs a compat package. We probably wouldn't have to keep it around for a long

Re: HEADS UP: libwebp-0.6.0 soname bumps

On 01.02.2017 18:59, Sandro Mani wrote: Hi I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, which include soname bumps. I'm rebuilding all of the dependent packages: A quick status update here on the packages not yet rebuilt: - Packages which are stuck due to depending

Dependency rebuild order

Hi Wondering if someone has some neat script which outputs the rebuild order of a set of packages, say after a library these depend on bumped its soname. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

HEADS UP: libwebp-0.6.0 soname bumps

Hi I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, which include soname bumps. I'm rebuilding all of the dependent packages: darktable-2.2.2-1.fc26.src.rpm efl-1.18.4-2.fc26.src.rpm freeimage-3.17.0-8.fc26.src.rpm gd-2.2.4-1.fc26.src.rpm gdal-2.1.2-6.fc26.src.rpm

Updates in testing for EOL releases stuck forever in Bodhi?

Hi Just wondering: is there any way to get rid of the entries of updates stuck in testing for EOL releases in bodhi.fedoraproject.org/updates/?user==testing ? Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: Packages owned by epienbro (Packages now looking for new points of contact!)

Per https://pagure.io/fesco/issue/1661 I have orphaned their packages: Point of contact: rpms/mingw-SDL -- MinGW Windows port of SDL cross-platform multimedia library ( master f25 f24 epel7 ) rpms/mingw-SDL2 -- MinGW Windows port of SDL2 cross-platform multimedia library ( master

Re: Orphaning python-sphinx-theme-better

On 02.01.2017 21:28, Igor Gnatenko wrote: On Mon, Jan 2, 2017 at 9:14 PM, Sandro Mani <manisan...@gmail.com> wrote: Hi I've orphaned python-sphinx-theme-better. It was briefly used by python-pillow for its documentation in the past, but that's not the case anymore and python-sphinx

Orphaning python-sphinx-theme-better

Hi I've orphaned python-sphinx-theme-better. It was briefly used by python-pillow for its documentation in the past, but that's not the case anymore and python-sphinx-theme-better hasn't seen any activity upstream since 2013. As far as I can tell [1] no other package in fedora requires it.

Packages owned by epienbro

Given the sad news of the passing of Erik van Pienbroek, I suppose at this stage his packages should be orphaned. I've had a look at what packages he's marked as point of contact in pkgdb [1], in particular the following are packages without comaintainers: mingw-webkitgtk mingw-gtkhtml3

Review swaps

Hi For the upgrade to python-pillow-4.0.0, I need these two packages reviewed: - https://bugzilla.redhat.com/show_bug.cgi?id=1409647 - libimagequant - Palette quantization library - https://bugzilla.redhat.com/show_bug.cgi?id=1409648 - python-olefile - Python package to parse, read and write

Re: pkgdb: Could not save the request for branch: master, has it already been requested?

On 21.12.2016 23:52, Till Maas wrote: On Wed, Dec 21, 2016 at 11:34:16PM +0100, Sandro Mani wrote: Side-note: the new package request allows either full url or just BZ ticket number. Perhaps the unretirement form could be made to also accept both inputs. Yes, a fix is already queued

Re: pkgdb: Could not save the request for branch: master, has it already been requested?

On 21.12.2016 23:28, Till Maas wrote: On Wed, Dec 21, 2016 at 02:02:03PM -0600, Jason L Tibbitts III wrote: This is the kind of thing that should probably be in an infrastructure ticket instead of the mailing list, but I happened to see your message. As far as I can tell, you're correct in

pkgdb: Could not save the request for branch: master, has it already been requested?

Hi I filed the request to unretire eigen2, but I accidentally specified only the rhbz ticket number instead of the full URL so it got denied with "Invalid review BZ". I now tried filing a new unretirement request with the full ticket url, but now I'm getting Could not save the request for

Retire mingw-openjpeg (and native openjpeg status)

Hi I'm planing to retire mingw-openjpeg next week unless there are objections. It is superseeded by mingw-openjpeg2 and no package depends on it anymore. The openjpeg-1.x series is obsolete and has multiple unfixed security issues. Though not its maintainer, as a curiosity I've had a look

Re: ppc64le: error: declaration does not declare anything

On 17.12.2016 16:09, Jakub Jelinek wrote: On Sat, Dec 17, 2016 at 04:03:22PM +0100, Sandro Mani wrote: Hi I'm having some difficulties understanding the following error on ppc64le (scratch build [1], build log [2]): PackMath.h: 191 template<> inline v4f ei_pset1(const float&

ppc64le: error: declaration does not declare anything

Hi I'm having some difficulties understanding the following error on ppc64le (scratch build [1], build log [2]): PackMath.h: 191 template<> inline v4f ei_pset1(const float& from) 192 { 193// Taken from http://developer.apple.com/hardwaredrivers/ve/alignment.html 194float

Re: HEADS UP: eigen-3.3.0 update

On 11.12.2016 22:44, Kevin Kofler wrote: Hmmm, what will that do to Kalzium, which currently uses both Avogadro and Eigen3? I think that will have to move back to Eigen2 as well, which might require actually reverting upstream porting patches. Uhm, or I could add a compat-eigen32 subpackage

Re: HEADS UP: shapelib soname bump

On 11.12.2016 12:54, Igor Gnatenko wrote: On Sun, Dec 11, 2016 at 11:54 AM, Sandro Mani <manisan...@gmail.com> wrote: Hi I'm preparing the shapelib-1.4.0 update, which bumped the soname. There are no API changes, it was just to synchronize with the debian soname. Dependent pa

Re: HEADS UP: eigen-3.3.0 update

Actually, given the dependency on eigen headers in the public avogadro headers, I suppose the only way forward is indeed to revive eigen2. Anyone care to swap review with https://bugzilla.redhat.com/show_bug.cgi?id=1403554? Thanks Sandro ___ devel

HEADS UP: shapelib soname bump

Hi I'm preparing the shapelib-1.4.0 update, which bumped the soname. There are no API changes, it was just to synchronize with the debian soname. Dependent packages are: gpsbabel-0:1.5.3-4.fc24 grads-0:2.0.2-18.fc26 librecad-0:2.1.0-1.fc25 marble-widget-qt5-1:16.08.3-1.fc26

Re: Missing heads up for gmsh SONAME bump

On 11.12.2016 11:27, Igor Gnatenko wrote: Looks like there was no announcement nor rebuild of dependent packages. getdp has broken dependencies in the rawhide tree: On x86_64: getdp-2.10.0-2.fc26.x86_64 requires libGmsh.so.2.14()(64bit) On armhfp: getdp-2.10.0-2.fc26.armv7hl

Re: Contact Björn Esser (Re: HEADS UP: eigen-3.3.0 update)

: Hi Sandro, I've contacted him via Facebook and told him that you're trying to contact him. I think he'll response soon. Greetings, Christian On 11/25/2016 01:00 PM, Sandro Mani wrote: I've seen that the mails to shogun-ow...@fedoraproject.org aka fed...@besser82.io are bouncing back

Contact Björn Esser (Re: HEADS UP: eigen-3.3.0 update)

I've seen that the mails to shogun-ow...@fedoraproject.org aka fed...@besser82.io are bouncing back because the besser82.io domain isn't valid anymore. Does anyone know another way to contact him? ___ devel mailing list --

Re: HEADS UP: eigen-3.3.0 update

On 25.11.2016 03:44, Kevin Kofler wrote: Sandro Mani wrote: AFAICS avogadro can still be built against eigen2, so sure, that would also be a plan. Not sure if reviving the package is better than bundling though, since eigen2 is completely unsupported upstream and its use not recommended [1

Re: HEADS UP: eigen-3.3.0 update

On 24.11.2016 12:56, Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 23 November 2016 at 22:45, Sandro Mani wrote: Hi eigen-3.3.0 was released a a couple of weeks ago, and I've investigated the consequences of updating in rawhide in this [1] COPR repo. The detailed analysis is below

HEADS UP: eigen-3.3.0 update

Hi eigen-3.3.0 was released a a couple of weeks ago, and I've investigated the consequences of updating in rawhide in this [1] COPR repo. The detailed analysis is below, the summary is: - five dependent packages fail to build due to the eigen3 update: avogadro, ceres-solver, kalzium, shogun

Re: fedpkg build fails: Could not auth with koji. Login failed: [('SSL routines', 'SSL_shutdown', 'shutdown while in init')]

On 09.11.2016 22:54, Sandro Mani wrote: On 09.11.2016 22:49, Kevin Fenzi wrote: What versions of python2-cryptography and pyOpenSSL do you have? I'm using: python2-cryptography-1.5.3-1.fc26.x86_64 python2-pyOpenSSL-16.2.0-1.fc26.noarch Aha! It looks like indeed python2-cryptography

Re: fedpkg build fails: Could not auth with koji. Login failed: [('SSL routines', 'SSL_shutdown', 'shutdown while in init')]

On 09.11.2016 22:49, Kevin Fenzi wrote: What versions of python2-cryptography and pyOpenSSL do you have? I'm using: python2-cryptography-1.5.3-1.fc26.x86_64 python2-pyOpenSSL-16.2.0-1.fc26.noarch Thanks Sandro ___ devel mailing list --

fedpkg build fails: Could not auth with koji. Login failed: [('SSL routines', 'SSL_shutdown', 'shutdown while in init')]

Hi I've noticed today that I'm unable to submit builds anymore. I get $ fedpkg build /usr/lib/python2.7/site-packages/pyrpkg/__init__.py:314: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 for (_, _, ssl_reason) in error.message: You might want to run

Re: noarch debuginfo packages missing from repo?

On 25.10.2016 20:02, Till Maas wrote: On Tue, Oct 25, 2016 at 05:44:49PM +0200, Sandro Mani wrote: rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is found). I suspect that perhaps noarch debuginfo packages are missing from AFAIK debuginfo packages are not generated

Re: noarch debuginfo packages missing from repo?

On 25.10.2016 18:14, Kevin Fenzi wrote: On Tue, 25 Oct 2016 17:44:49 +0200 Sandro Mani <manisan...@gmail.com> wrote: Hi Just noticed that dnf (or yum-deprecated for the matter) won't find any mingw{32,64}-XXX-debuginfo packages to install (even though rawhide-debuginfo is e

noarch debuginfo packages missing from repo?

Hi Just noticed that dnf (or yum-deprecated for the matter) won't find any mingw{32,64}-XXX-debuginfo packages to install (even though rawhide-debuginfo is enabled, and indeed i.e. qt5-qtbase-debuginfo is found). I suspect that perhaps noarch debuginfo packages are missing from the repo?

Re: HEADS UP: update to podofo-0.9.4

The rawhide build is now complete. On 18.09.2016 13:05, Sandro Mani wrote: Hi I'll be updating to podofo-0.9.4 in rawhide next weekend. This update includes a soname bump, and the following packages will need to be rebuilt: calibre fontmatrix krename scribus I don't have commit access

HEADS UP: update to podofo-0.9.4

Hi I'll be updating to podofo-0.9.4 in rawhide next weekend. This update includes a soname bump, and the following packages will need to be rebuilt: calibre fontmatrix krename scribus I don't have commit access to any of those packages, so I need help from the maintainers or a proven

Review request: perl-Path-Iterator-Rule, perl-Number-Range

Hi I need the following packages reviewed to update licensecheck and perl-String-Copyright: perl-Path-Iterator-Rule - https://bugzilla.redhat.com/show_bug.cgi?id=1373244 perl-Number-Range - https://bugzilla.redhat.com/show_bug.cgi?id=1374642 Happy to review in exchange. Sandro -- devel

Review request: perl-Test-Filename, perl-Path-Iterator-Rule

Hi No idea why licensecheck keeps adding dependencies, but here we go again... perl-Test-Filename - https://bugzilla.redhat.com/show_bug.cgi?id=1373243 perl-Path-Iterator-Rule - https://bugzilla.redhat.com/show_bug.cgi?id=1373244 Happy to review in exchange. Sandro -- devel mailing list

Review request: perl-String-Copyright

Hi Another new licensecheck dependency: https://bugzilla.redhat.com/show_bug.cgi?id=1366511 - perl-String-Copyright - Representation of text-based copyright statements Happy to review in exchange. Sandro -- devel mailing list devel@lists.fedoraproject.org

Re: Unexplained build failure?

On 20.07.2016 21:25, Igor Gnatenko wrote: Yes, FPC ticket is not needed, but this automatic unblocking works somehow with delay (I had to wait around one day) Aha, ok. Thanks Sandro -- devel mailing list devel@lists.fedoraproject.org

Re: Unexplained build failure?

On 20.07.2016 21:19, Igor Gnatenko wrote: You have to request unretirement in pkgdb and wait some time. That was done, but I forgot to file a fpc ticket to unblock the package (or should unblocking happen automatically when unretiring? Cause the f24 build worked, though f23 and rawhide

Re: Unexplained build failure?

On 20.07.2016 21:09, Michal Srb wrote: Hi Sandro, On 07/20/2016 09:01 PM, Sandro Mani wrote: Hi Can anyone explain why this build is failing after creating the src.rpm? http://koji.fedoraproject.org/koji/taskinfo?taskID=14960410 See the parent task: http://koji.fedoraproject.org/koji

Unexplained build failure?

Hi Can anyone explain why this build is failing after creating the src.rpm? http://koji.fedoraproject.org/koji/taskinfo?taskID=14960410 I've scanned the logs, but can't find any error messages in them. Thanks Sandro -- devel mailing list devel@lists.fedoraproject.org

Review request: twinkle

Hi I'd like to revive the twinkle package, it now as a new active upstream, which ported it to Qt5. Review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=1357483 Happy to review in exchange. Thanks Sandro -- devel mailing list devel@lists.fedoraproject.org

ARM, inlining failed in call to always_inline '[...]': target specific option mismatch

Hi libwebp-0.5.1 fails to build on ARM with error messages such as gcc -DHAVE_CONFIG_H -I. -I../../src/webp -DNDEBUG -fvisibility=hidden -Wall -Wdeclaration-after-statement -Wextra -Wfloat-conversion -Wformat -Wformat-nonliteral -Wformat -Wformat-security -Wmissing-declarations

licensecheck split-off from devscripts-minimal

Hi Upstream has moved licensecheck to a new stand-alone package and removed it from devscripts-2.16.6 onwards. I've packaged licensecheck, along with a dependency, review requests are here: - https://bugzilla.redhat.com/show_bug.cgi?id=1352666 : perl-Pod-Constants - Include constants from

%python_provide question

Hi I'm looking at modernizing the python-pillow spec and have a question about %python_provide: The python{2,3}-pillow also provide the legacy python{,2,3}-imaging names, how should this be handled with %python_provide? I.e. %package -n python2-pillow %{?python_provide:%python_provide

Re: Orphaned Packages in branched (2016-05-03)

On 03.05.2016 18:23, opensou...@till.name wrote: uriparser orphan, fcami 1 weeks ago Taken. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Unretiring libkml: rel-eng ticket?

Hi I want to unretire libkml, the review is already done and approved, and now I guessed that the next step was to file a rel-eng ticket to unblock the branches [1], things have been pretty silent there though. Is this still the correct procedure and are people simply busy, or is this the

Review swap: libkml

Hi I'd like to reintroduce the libkml package, review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=1324367 Happy to review in exchange. Thanks Sandro -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: FreeCAD Fedora 24 packages missing all library dependencies.

On 05.04.2016 17:09, Michael Schwendt wrote: On Mon, 4 Apr 2016 15:33:02 -0500, Richard Shaw wrote: I recently got a rash of bug report that FreeCAD on f24 was segfaulting. After looking at a few things I noticed that the f24 builds seem to be missing all library based dependencies. Has

qt-creator license change to GPLv3 with exceptions

Hi Starting with qt-creator 4.0.0-beta1 (landing in rawhide very soon), qt-creator will be licensed GPLv3 with exceptions. Previous releases were LGPLv2 with exceptions or LGPLv3 with exceptions. See also [1]. Sandro [1] http://blog.qt.io/blog/2016/03/23/qt-creator-4-0-beta-released/ --

buildSRPMFromSCM: remote error: access denied or repository not exported: //qt-creator (Was: Re: fedpkg new-sources: Could not execute new_sources: Error checking for [...])

On 17.03.2016 23:22, Sandro Mani wrote: On 17.03.2016 17:35, Kevin Fenzi wrote: Neither. :) It's likely a fedpkg/pyrpkg bug. ;) What versions of those do you have installed? I think: pyrpkg-1.42-1.fc25.noarch fedpkg-1.22-2.fc25.noarch should work, but pyrpkg versions 1.41* were broken

fedpkg new-sources: Could not execute new_sources: Error checking for [...]

Hi I'm getting $ fedpkg new-sources qt-creator-opensource-src-3.6.1.tar.gz Could not execute new_sources: Error checking for qt-creator-opensource-src-3.6.1.tar.gz at https://pkgs.fedoraproject.org/repo/pkgs/upload.cgi and same for another source tarball I've tried. When I open

Re: fedpkg new-sources: Could not execute new_sources: Error checking for [...]

On 17.03.2016 17:35, Kevin Fenzi wrote: Neither. :) It's likely a fedpkg/pyrpkg bug. ;) What versions of those do you have installed? I think: pyrpkg-1.42-1.fc25.noarch fedpkg-1.22-2.fc25.noarch should work, but pyrpkg versions 1.41* were broken in this way. Correct, works after updating

Re: GCC6: implicit casting triggers error

On 04.02.2016 13:45, Jonathan Wakely wrote: On 04/02/16 13:36 +0100, Sandro Mani wrote: Hi Med builds are failing with medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector<double, std::allocator >::erase(SwigValueWrapper<__gnu_cxx::__normal_iterat

GCC6: implicit casting triggers error

Hi Med builds are failing with medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector::erase(SwigValueWrapper<__gnu_cxx::__normal_iterator > >&)' result = (arg1)->erase(arg2); A standalone

Re: GCC6: implicit casting triggers error

On 04.02.2016 13:40, Jakub Jelinek wrote: On Thu, Feb 04, 2016 at 01:36:50PM +0100, Sandro Mani wrote: Med builds are failing with medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector<double, std::allocator >::erase(SwigValueWrapper<__gnu_cxx::__normal

GCC6: failure with -isystem /usr/include

Hi qt-creator builds have started to fail, I've reduced the failure down to having "-isystem /usr/include" in the command line: $ cat test.cpp #include $ g++ -isystem /usr/include -c -o test.o test.cpp In file included from /usr/include/c++/6.0.0/bits/stl_algo.h:59:0, from

Re: GCC6: failure with -isystem /usr/include

On 02.02.2016 13:38, Jakub Jelinek wrote: On Tue, Feb 02, 2016 at 01:32:17PM +0100, Sandro Mani wrote: Hi qt-creator builds have started to fail, I've reduced the failure down to having "-isystem /usr/include" in the command line: Don't use -isystem /usr/include for C++, unles

koji-waitrepo too early?

Hi Just noticed twice today that koji wait-repo rawhide --build <...> reported that the build (specifically, leptonica-1.72-1.fc24 and mingw-leptonica-1.72-1.fc24) appeared in the repo, but builds fired immediately afterwards still used the previous version of the package in question.

<    1   2   3   4   5   6   7   >