Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
Hi, On Sun, 2018-02-18 at 18:09 +0100, Igor Gnatenko wrote: > If you fixed package(s), found false positive, found missing packages > in list > or anything else -- please let me know. Done: boost-gdb-printers cppunit libabw libcdr libcmis libcss libe-book libeot libepubgen libetonyek libexttextcat libfreehand libgltf libhubbub libixion libmspub libmwaw libodfgen liborcus libpagemaker libparserutils libqxp librevenge librvngabw libstaroffice libvisio libwapcaplet libwpd libwpg libwps libzmf mdds writerperfect D. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Tue, Feb 20, 2018 at 07:21:43PM -0500, Stephen John Smoogen wrote: > > List of packages and respective maintainers: > > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > So this may not be all the packages which would need a > BuildRequires:gcc in them. I had two packages without > Buildrequires:gcc not on the list but definitely using a gcc compiler. > I am guessing something else in the buildrequires is pulling them in > as a dependency. > > I don't know if that will be a problem later on but wanted to mention it. The same as with any other missing dependency: if the package that your package depends on at some point loses *its* dependency, your package will FTBFS. Not a problem now, but something to fix in the long term. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass Rebuild for Fedora 28
On Tue, Feb 13, 2018 at 4:36 AM, Dennis Gilmore wrote: > Hi All, > > We have now completed the automated part of the Fedora 28 mass rebuild, > The details for the scheduled mass rebuild for Fedora 28 can be found > here[1]. The failure page for the rebuilds can be found here[3] and the > full list of packages that are needing rebuilding can be found here[4]. > The needs rebuild list includes packages that failed to get submitted > to koji for various reasons, things like the spec bumping failing due > to incomplete or incorrect retirement > > Please quickly clean up all build failures as the schedule[5] has us > branching next Tuesday, on the 20th of February and enabling Bodhi on > the 6th of March, So expect to see a 28 branched compose in about a > week from now. > > Many Thanks > > Dennis > > [1] https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild > [2] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-failures.html > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-need-rebuild.ht > ml I think its better as releng already have above need-rebuild package list so they can run mass-rebuild script and build all the missed packages. Are there still any plans to use mass-rebuild script or its upto individual maintainers to rebuild their packages for Fedora 28? Regards, Parag ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Wednesday's FPC Meeting (2018-02-21 18:00 UTC)
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-02-21 18:00 UTC in #fedora-meeting-2 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Wednesday =
2018-02-21 10:00 PST US/Pacific
2018-02-21 13:00 EST --> US/Eastern <--
2018-02-21 18:00 GMT Europe/London
2018-02-21 18:00 UTC UTC
2018-02-21 19:00 CET Europe/Berlin
2018-02-21 19:00 CET Europe/Paris
2018-02-21 23:30 IST Asia/Calcutta
--- New Day: Thursday
2018-02-22 02:00 HKT Asia/Hong_Kong
2018-02-22 02:00 +08 Asia/Singapore
2018-02-22 03:00 JST Asia/Tokyo
2018-02-22 04:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
= Followups =
#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691
#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693
#topic #694 Packaging guidelines for application independence
.fpc 694
https://pagure.io/packaging-committee/issue/694
#topic #702 C/C++ guidelines should say using clang needs an exception
.fpc 702
https://pagure.io/packaging-committee/issue/702
#topic #708 Allocating a static uid and gid for openvswitch
.fpc 708
https://pagure.io/packaging-committee/issue/708
#topic #710 Ruby packaging guidelines update
.fpc 710
https://pagure.io/packaging-committee/issue/710
#topic #713 Forward-looking conditionals by default
.fpc 713
https://pagure.io/packaging-committee/issue/713
#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714
#topic #715 Separately building package documentation
.fpc 715
https://pagure.io/packaging-committee/issue/715
#topic #719 Simplify packaging of forge-hosted projects
.fpc 719
https://pagure.io/packaging-committee/issue/719
#topic #723 Guidelines for handling deprecated dependencies during
review
.fpc 723
https://pagure.io/packaging-committee/issue/723
#topic #726 Review for SELinux Independent Policy packaging Draft
.fpc 726
https://pagure.io/packaging-committee/issue/726
#topic #738 Mangling shebangs
.fpc 738
https://pagure.io/packaging-committee/issue/738
#topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
.fpc
743
https://pagure.io/packaging-committee/issue/743
= New business =
#topic #741 Clarify the PyPI URL template
.fpc 741
https://pagure.io/pack
aging-committee/issue/741
#topic #745 Don't use %{__python}, %{python_sitelib/arch} unredefined
.fpc 745
https://pagure.io/packaging-committee/issue/745
#topic #751 Packaging:Guidelines#Noarch_with_Unported... is outdated
.fpc 751
https://pagure.io/packaging-committee/issue/751
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee
, 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
Fedora 28 Mass Branching
Hi All, Fedora 28 has now been branched, please be sure to do a git pull --rebase to pick up the new branch, as an additional reminder rawhide/f29 has been completely isolated from previous releases, so this means that anything you do for f28 you also have to do in the master branch and do a build there. There will be a Fedora 28 compose ASAP and it'll appear http://dl.fedoraproject.org/pub/fedora/linux/development/28/ once complete. Please be sure to check it out. Bodhi is currently not active for Fedora 28, it will be enabled in a weeks time when we hit Beta change freeze point in the Fedora 28 schedule[1]. Mohan Boddu. [1] https://fedoraproject.org/wiki/Releases/28/Schedule ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] No more gnupg2 in buildroot
On 20 February 2018 at 13:11, Igor Gnatenko wrote: [..] > today I've split⁰ librpmsign from rpm-build-libs into its own subpackage rpm- > sign-libs. [root@tin ~]# rpm -e rpm-build-libs error: Failed dependencies: librpmbuild.so.8()(64bit) is needed by (installed) python3-rpm-4.14.1-6.fc28.1.x86_64 librpmsign.so.8()(64bit) is needed by (installed) python3-rpm-4.14.1-6.fc28.1.x86_64 [root@tin ~]# rpm -e rpm-build-libs python3-rpm error: Failed dependencies: python3-rpm >= 4.13.0-0.rc1.29 is needed by (installed) python3-dnf-2.7.5-8.fc28.noarch [root@tin ~]# rpm -e rpm-build-libs python3-rpm python3-dnf error: Failed dependencies: python3-dnf >= 2.7.0 is needed by (installed) python3-dnf-plugins-core-2.1.5-4.fc28.noarch python3-dnf < 3.0 is needed by (installed) python3-dnf-plugins-core-2.1.5-4.fc28.noarch python3-dnf = 2.7.5-8.fc28 is needed by (installed) dnf-2.7.5-8.fc28.noarch I'm only pointing to the fact that now package which name suggests that it has something to do with the building packages is required by @Core On top above now both (rpm-build-libs and rpm-sign-libs) still are required by the minimal set of packages. In other words, this and prev change introduces negative simplification factor. Maybe it would be good to review the content of the python3-rpm .. *maybe*. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 18 February 2018 at 12:09, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Over this weekend I've performed scratch-mass-rebuild without having gcc and > gcc-c++ in buildroot of all Fedora packages, many of which failed due to > random > reasons and I grepped all logs for some common errors found by analyzing > hundreds of build logs. > > Guidelines: > https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire > s_and_Requies > > The grep output is located here: > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt > > Some packages might be missed due to short koji outage, broken dependencies > and > so on, but majority of real failures is below. > > If you fixed package(s), found false positive, found missing packages in list > or anything else -- please let me know. > > Note to packages which use CMake buildsystem. When you have project(xxx) in > CMakeLists.txt it checks both for C and CXX compilers. So you might encounter > packages where you have BuildRequires: gcc and it fails on CXX compiler (even > you think you don't need it). Solution for this is to send patch to upstream > switching to something like project(xxx C), or if problem is opposite to > project(xxx CXX). > > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > So this may not be all the packages which would need a BuildRequires:gcc in them. I had two packages without Buildrequires:gcc not on the list but definitely using a gcc compiler. I am guessing something else in the buildrequires is pulling them in as a dependency. I don't know if that will be a problem later on but wanted to mention it. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Wed, 2018-02-21 at 00:03 +0100, Nils Philippsen wrote: > On Sun, 2018-02-18 at 18:09 +0100, Igor Gnatenko wrote: > > List of packages and respective maintainers: > > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > > nphilipp babl dcraw gegl gimp gpsdrive gtick gtkimageview > > hydrogen beanstalkd and clamsmtp are done ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote: > If you fixed package(s) -- please let me know. Fixed: util-linux-2.32-0.2.fc29 Karel -- Karel Zak http://karelzak.blogspot.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
On Tue, Feb 20, 2018 at 11:10 PM, Rex Dieter wrote:
> Alexander Ploumistos wrote:
>> I am asking because the rpm documentation leaves quite a lot to be
>> desired. If I went and changed all my "Requires: foo" to "Requires:
>> foo%{_isa}" in all my non-noarch packages, would I be plain wrong, or
>> is it justifiable - albeit an overkill?
>
> the only place I recall seeing recommendation to use %{_isa} is in subpkg
> dependencies.
>
> IMO, It's wrong to use in general, unless you have good reason to do so. Do
> you?
Well, if I did, I'd know why it was a good reason and we wouldn't be
having this conversation :)
> Another alternative: don't make -devel depend on the main package (which is
> ok for headers-only situations like this)
That's a good point to discuss with the upstream developer as well,
because I think he intends the libraries to be shipped (and work) that
way.
Thank you for all that Rex!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, 2018-02-18 at 18:09 +0100, Igor Gnatenko wrote: > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > nphilipp babl dcraw gegl gimp gpsdrive gtick gtkimageview hydrogen jaaa lensfun libgnomecanvasmm26 libiec61883 liblo liblrdf libltc libraw1394 libsamplerate pngcrush python-sqlalchemy sane-backends sane- frontends suitesparse ufraw uucp widelands xsane Done where others didn't beat me to it. Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
libsamplerate license change
Hi there, version 0.1.9 of libsamplerate which I've recently built in all branches changed its license from GPLv2+ to BSD (2-clause). Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Alexander Ploumistos wrote:
> Well, with some delay, the waiver worked and I was able to push the
> f26 package to batched.
>
>
> On Tue, Feb 20, 2018 at 8:47 PM, Rex Dieter wrote:
>> Alexander Ploumistos wrote:
>>> OpenBabel is a runtime dependency for some optional features of
>>> Molsketch. The %{_isa} macro got added during the review
>>
>> I think the reviewer in this case was wrong to suggest that, just use
>> Requires: openbabel
>
> I am asking because the rpm documentation leaves quite a lot to be
> desired. If I went and changed all my "Requires: foo" to "Requires:
> foo%{_isa}" in all my non-noarch packages, would I be plain wrong, or
> is it justifiable - albeit an overkill?
the only place I recall seeing recommendation to use %{_isa} is in subpkg
dependencies.
IMO, It's wrong to use in general, unless you have good reason to do so. Do
you?
> We had some long discussions with the reviewer and the upstream
> developer as to what could/should be in the -devel subpackage and I
> ended up with what's there. I was wondering why the subpackage was not
> to be noarch, but then I found this in our guidelines:
>
> Do not use noarch
>
> It may be tempting to make the header library package noarch, since
> the header files themselves are simply text. However, a library should
> have tests which should be run on all architectures. Also, the install
> process may modify the installed headers depending on the build
> architecture. For these reasons, header-only packages must not be
> marked noarch.
>
>
> Upstream is working on a testsuite, so at some point down the road I
> will (probably) need it as it is.
That's fair.
Another alternative: don't make -devel depend on the main package (which is
ok for headers-only situations like this)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Well, with some delay, the waiver worked and I was able to push the
f26 package to batched.
On Tue, Feb 20, 2018 at 8:47 PM, Rex Dieter wrote:
> Alexander Ploumistos wrote:
>> OpenBabel is a runtime dependency for some optional features of
>> Molsketch. The %{_isa} macro got added during the review
>
> I think the reviewer in this case was wrong to suggest that, just use
> Requires: openbabel
I am asking because the rpm documentation leaves quite a lot to be
desired. If I went and changed all my "Requires: foo" to "Requires:
foo%{_isa}" in all my non-noarch packages, would I be plain wrong, or
is it justifiable - albeit an overkill?
>
> FYI, the package is multilib'd because it has a -devel subpkg, which depends
> on the main one (-devel pkgs are automatically multilib). the -devel subpkg
> is headers only, you could consider either making it noarch, or drop it
> altogether.
We had some long discussions with the reviewer and the upstream
developer as to what could/should be in the -devel subpackage and I
ended up with what's there. I was wondering why the subpackage was not
to be noarch, but then I found this in our guidelines:
Do not use noarch
It may be tempting to make the header library package noarch, since
the header files themselves are simply text. However, a library should
have tests which should be run on all architectures. Also, the install
process may modify the installed headers depending on the build
architecture. For these reasons, header-only packages must not be
marked noarch.
Upstream is working on a testsuite, so at some point down the road I
will (probably) need it as it is.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] No more gnupg2 in buildroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-02-20 at 19:11 +, Peter Robinson wrote: > On Tue, Feb 20, 2018 at 1:11 PM, Igor Gnatenko > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Hey, > > > > today I've split⁰ librpmsign from rpm-build-libs into its own subpackage > > rpm- > > sign-libs. > > Does this mean that the python bindings no longer depend on > rpm-build-libs and hence won't be pulled for a standard minimal > install and similar artifacts anymore? Nope, it means that python bindings will depend *also* on rpm-sign-libs 😉 Since bindings are monolitic, it's not possible to split them easily. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqMgdAACgkQaVcUvRu8 X0wE4A//dtpjcv0oNDygoZjZvhWmyL+61Y1OmkuwjRxcMKccDNQ4XurA6pPogM8u Ph2jAUsjEk7wmDKzrq/CcLnBhF4JCTHFQO5A57cRXhw8+Ztr9osDDP0boqbp6l/c W0I2+PSfTHwIu80rfuL7Pb2HxM7Rfof2an64l75X16bZn3IYTJ8i+QznrePur60+ njPP6u6lHEA5e+mTHd1UyIR+eaxra1/72QSzMLKUWlE3THr68qSWI7Z2CjN3ybzS Kfq3jk2lSY16aEpsJF6MNSfZukCnra6cxE3qKrYPPjzRyYy0b6wil2ncrbWHjv2Q Na+/BkKwakQJtWLHnFb+pdzdzcCojVb/Edp1I5HK4jVsvQnBm+bCrK4h7+oMkj5A TuKaaStVENT3Gv3Dz2MeOpgEeIYq0mdH3YHgVCqrOpiu+AtS28tkcXj8QIb6nyRz MbaUsrWtpXq35LXaCgLBFOqBNIgA0l/POPOqJln9wjRylUF0J+H6S4b02/KDaUnq FJ+LngmhT7KMaOjXutYytPDOUnysIAiOoYYqS9hlWXPzBjT4LdOPwNb+bNLZq3rQ z7yeQw8yKhekeosgH8uWL54tJLhCCFKimxoEEQlI8oEJBqSPO9hC55jBoESsMN57 tu0DIDp0x5SP/4pPp8dhLFPwXOjdKrNJi1cjR6wsXawIz9E+/hM= =o5FQ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Alexander Ploumistos wrote:
> OpenBabel is a runtime dependency for some optional features of
> Molsketch. The %{_isa} macro got added during the review
I think the reviewer in this case was wrong to suggest that, just use
Requires: openbabel
FYI, the package is multilib'd because it has a -devel subpkg, which depends
on the main one (-devel pkgs are automatically multilib). the -devel subpkg
is headers only, you could consider either making it noarch, or drop it
altogether.
-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: gc-7.6.4 to rawhide, *no* abi bump
Yaakov Selkowitz wrote: > On 2018-02-20 11:21, Rex Dieter wrote: >> Been putting it off, but finally going to work to bring gc-7.6.2 to >> rawhide, includes a soname bump affecting > > The soname bump appears to have been a mistake; 7.6.4 reverts it. That's very good news, thanks! -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] No more gnupg2 in buildroot
On Tue, Feb 20, 2018 at 1:11 PM, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hey, > > today I've split⁰ librpmsign from rpm-build-libs into its own subpackage rpm- > sign-libs. Does this mean that the python bindings no longer depend on rpm-build-libs and hence won't be pulled for a standard minimal install and similar artifacts anymore? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Vim: removing %{_libdir}/vim from vim-filesystem
On 02/20/2018 05:40 PM, Zdenek Dohnal wrote:
> I want to have vim-filesystem subpackage as noarch (as most packages
> with *-filesystem subpackage have), but dir mentioned above is
> architecture specific, so I want to remove it.
>
> This dir was added in bugzilla #1193230 as dir for plugins .so files. I
> made repo queries, if any package puts files there - none package from
> official Fedora repositories puts files in %{_libdir}/vim, so its
> removal shouldn't influence anyone.
Are vim plugins supposed to be multilib? If not, not you make
vim-filesystem own %{_prefix}/lib and put plugins there.
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Dynamically-generated C stored in SVN is breaking our distribution because life is awful (was Re: F28 System Wide Change: GCC8)
> "NM" == Nicolas Mailhot writes: NM> BTW dovecot is broken by all the compiler and crypto changes, both NM> for the two last rebuilds (that failed) and the build before (that NM> succeeded but has broken auth which is sort of needed for an imap NM> server) Interestingly enough, cyrus-imapd is also broken. Technically it compiles fine and mostly runs fine, but the extensive test suite (which we now run at build time) causes the xapian-based search indexing component to segfault deep down in the bowels of some tests. In what is surely a plan to make me lose the rest of my hair, the failures _only_ happen when run in mock. In a clean rawhide VM or docker container with enough build deps to run fedpkg local, things build fine. So far the only thing resembling a backtrace I've been able to get out of anything is just this which coredumpctl saves: #0 0x0120 n/a (n/a) #1 0x7ffd8745b720 n/a (n/a) #2 0x7fb063abac80 _ZTVNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEE (libstdc++.so.6) That makes me wonder if I'm hitting a libstdc++ bug. If I do coredumpctl gdb and then to a backtrace, I just get: (gdb) bt #0 0x0120 in ?? () #1 0x7fb06352881e in ?? () #2 0x7ffd8745b7b0 in ?? () #3 0x7ffd8745b528 in ?? () #4 0x in ?? () which obviously isn't helpful. And this was obtained by running mock on a rawhide VM where I've made sure that the environment inside and outside of the chroot have the same packages, all debuginfo is installed and the test suite is run in %install instead of %check so that the unstripped binaries are executed. I can't figure out a way to get more useful information out. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: gc-7.6.2 to rawhide, abi bump
On 2018-02-20 11:21, Rex Dieter wrote: > Been putting it off, but finally going to work to bring gc-7.6.2 to rawhide, > includes a soname bump affecting The soname bump appears to have been a mistake; 7.6.4 reverts it. -- Yaakov Selkowitz Software Engineer - Platform Enablement Group Red Hat, Inc. 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: Test gating enabled in Bodhi
On Tue, 2018-02-20 at 19:15 +0100, Alexander Ploumistos wrote:
> On Tue, Feb 20, 2018 at 5:13 PM, Rex Dieter wrote:
> > Alexander Ploumistos wrote:
> > > First question, why "arch" and "scenario" are x86_64, but the error
> > > concerns the 32-bit build? Since OpenBabel exists on all arches, why
> > > do I get this particular error message?
> >
> > Your package is multilib'd?
>
> No, I don't think it is.
>
>
> > > I have removed and reinstalled molsketch on both i686 and x86_64 with
> > > no errors from dnf
> >
> > and openbable is not multilib'd, that's the problem.
> >
> > Why do you have an explicit dep? Why is it arch'd?
> >
> > If you sure it's still needed, a simple:
> > Requires: openbabel
> >
> > should suffice.
>
> OpenBabel is a runtime dependency for some optional features of
> Molsketch. The %{_isa} macro got added during the review, I had asked
> about it, but completely forgot it while we were trying to figure out
> some other stuff. Is this technically wrong or is dist.rpmdeplint
> being overzealous here?
We did have a similar case of cross-arch oddness in rpmdeplint which I
think turned out to be something extremely non-obvious:
https://pagure.io/taskotron/task-rpmdeplint/issue/9
CCing kparal.
--
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: Test gating enabled in Bodhi
On Tue, Feb 20, 2018 at 5:13 PM, Rex Dieter wrote:
> Alexander Ploumistos wrote:
>> First question, why "arch" and "scenario" are x86_64, but the error
>> concerns the 32-bit build? Since OpenBabel exists on all arches, why
>> do I get this particular error message?
>
> Your package is multilib'd?
No, I don't think it is.
>> I have removed and reinstalled molsketch on both i686 and x86_64 with
>> no errors from dnf
>
> and openbable is not multilib'd, that's the problem.
>
> Why do you have an explicit dep? Why is it arch'd?
>
> If you sure it's still needed, a simple:
> Requires: openbabel
>
> should suffice.
OpenBabel is a runtime dependency for some optional features of
Molsketch. The %{_isa} macro got added during the review, I had asked
about it, but completely forgot it while we were trying to figure out
some other stuff. Is this technically wrong or is dist.rpmdeplint
being overzealous here?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf: Can't tell me what is pulling in a dependency?
On Tue, 2018-02-20 at 07:08 -0600, Richard Shaw wrote: > On Sun, Feb 18, 2018 at 12:14 PM, Sérgio Basto > wrote: > > On Sun, 2018-02-18 at 08:10 -0600, Richard Shaw wrote: > > > I was updating my mythtv box and I saw that it was pulling in > > > some mysql community packages as a dependency but I looked > > > through the options and I couldn't find ANYTHING that would tell > > > me what was pulling in those packages. Nov "-v" and not " > > > --debugsolver". > > > Is it really not possible? > > > > it is debugsolver : > > > > dnf --debugsolver upgrade -b > > > > > > > > > > but it is my fault I added > > Requires: mysql-compat-server >= 5 > > Requires: mysql >= 5 > > That was my first thought but mythtv was not updated on that > transaction so I thought maybe it was something else pulling it in... > > > > maybe we need added > > Suggests: mariadb-server mariadb > > But I already had those installed, it shouldn't have needed to pull > in the mysql packages... With what Fedora release ? 27 , 26 , 28 or el7 ? -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: GCC8
On Mon, 2018-02-19 at 22:57 -0800, Adam Williamson wrote: > On Tue, 2018-01-09 at 21:51 +0100, Jakub Jelinek wrote: > > On Tue, Jan 09, 2018 at 07:50:10PM +, Stephen Gallagher wrote: > > > > Well, true, but then just like every year, we'll wind up doing > > > > a lot of > > > > the spadework of fixing things to build with the new GCC. And > > > > probably > > > > at first some critical things will fail to build and that'll > > > > mess up > > > > the stability of the distro for a couple of weeks. I guess if > > > > everyone > > > > else is still loving that grind, hey. > > > > > > > > > > > > > This is the cost of being "First". Fedora has long enjoyed a > > > tight coupling > > > with the GCC upstream. It's a symbiosis: they use our mass- > > > rebuild to help > > > identify any issues before GCC goes stable and in turn Fedora > > > gets to have > > > the newest compiler features before anyone else. > > > > To be fair, Ubuntu (or Debian or both, dunno) has already performed > > test mass > > rebuilds with GCC 8 prerelease some time ago and OpenSUSE usually > > performs them > > roughly at the same time as we do. We are likely the first one or > > one of > > the first ones to deploy it as a stable compiler in the distro and > > it is > > mutually beneficial both for the distro and for GCC. > > Just for the record, it is now 11pm the day before we are supposed to > branch Fedora 28, and I have spent the whole evening fixing > OpenColorIO's Python bindings to build with GCC 8: pdftex Segmentation fault in arches i686 and amrv7 when build gdal [1] gdal build fails and have broken deps, which makes openv broken deps , which make mlt broken. So I have a big chain of packages with broken deps and I can't do nothing [1] https://bugzilla.redhat.com/show_bug.cgi?id=1546913 Best regards, > https://github.com/imageworks/OpenColorIO/pull/518 > > only to find that it fails to build on i686 because since pdftex got > rebuilt with GCC 8 (OK, haven't confirmed that yet, but it's the most > obvious suspect), it's segfaulting: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=25176488 > > Also noted by QuLogic trying to build R-htmltools: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=25173683 > > So now I am running the build in an i686 mock so I can shell into the > mock and hopefully get a traceback of the pdftex crash and try to do > *something* about fixing it. > > This is the kind of 'spadework' I was talking about. (And I haven't > even mentioned any of the *other* cases we've hit). > -- > 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 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, Feb 18, 2018 at 12:09 PM, Igor Gnatenko wrote: > If you fixed package(s), found false positive, found missing packages in list > or anything else -- please let me know. I've added the missing BuildRequires to the following packages: elog gfm hyperrogue ocaml-mccs spasm-ng tfdocgen tilp2 Ben Rosser ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
gc-7.6.2 to rawhide, abi bump
Been putting it off, but finally going to work to bring gc-7.6.2 to rawhide, includes a soname bump affecting $ dnf repoquery --whatrequires gc --repoid=rawhide ... Macaulay2-0:1.9.2-8.fc28.x86_64 aisleriot-1:3.22.4-3.fc28.x86_64 asymptote-0:2.41-1.fc27.x86_64 autogen-0:5.18.12-6.fc28.x86_64 bigloo-0:4.3a-3.fc28.x86_64 bigloo-libs-0:4.3a-3.fc28.x86_64 clover2-0:3.6.1-1.D20180216gitb392824.fc28.x86_64 denemo-0:2.2.0-2.fc28.x86_64 ecl-0:16.1.3-5.fc28.x86_64 flint-0:2.5.2-18.fc28.x86_64 freehoo-0:3.5.3-25.20100314cvs.fc28.x86_64 gc-devel-0:7.6.0-8.fc28.i686 gc-devel-0:7.6.0-8.fc28.x86_64 gdb-headless-0:8.1-8.fc28.x86_64 geda-gattrib-1:1.8.2-10.fc28.x86_64 geda-gnetlist-1:1.8.2-10.fc28.x86_64 geda-gschem-1:1.8.2-10.fc28.x86_64 geda-gsymcheck-1:1.8.2-10.fc28.x86_64 geda-utils-1:1.8.2-10.fc28.x86_64 gnotime-0:2.4.1-14.fc28.x86_64 gnubik-0:2.4.2-8.fc28.x86_64 gnucash-0:2.6.18-2.fc28.x86_64 gnutls-guile-0:3.6.2-1.fc28.x86_64 graphviz-guile-0:2.40.1-20.fc28.x86_64 guile-5:2.0.14-5.fc28.x86_64 guile-cairo-0:1.4.0-21.fc28.x86_64 guile22-0:2.2.2-1.fc27.x86_64 hop-0:3.1.0-0.1.pre2.fc28.x86_64 inkscape-0:0.92.2-6.fc28.x86_64 inkscape-view-0:0.92.2-6.fc28.x86_64 libgeda-1:1.8.2-10.fc28.x86_64 make-1:4.2.1-6.fc28.x86_64 maxima-runtime-ecl-0:5.41.0-5.fc28.x86_64 mdk-0:1.2.9-5.fc27.x86_64 nekovm-0:2.2.0-3.fc28.x86_64 synopsis-0:0.12-20.fc28.1.x86_64 w3m-0:0.5.3-37.git20180125.fc28.x86_64 weechat-0:2.0.1-2.fc28.x86_64 xbindkeys-0:1.8.5-13.fc28.x86_64 xs-0:1.1-4.git22afec1.fc28.x86_64 zile-0:2.4.13-5.fc28.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, 2018-02-18 at 18:09 +0100, Igor Gnatenko wrote: > If you fixed package(s), found false positive, found missing packages in list > or anything else -- please let me know. Fixed in rawhide: aspell exempi gpxsee groff joe jpilot libcgroup libpng12 libpng15 libtiff man-db pilot-link Also fixed the following unlisted packages: libjpeg-turbo libpipeline libpng mailx uClibc Thanks, Nikola ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20180220.n.0 compose check report
Missing expected images: Workstation live i386 Kde live i386 Failed openQA tests: 30/129 (x86_64), 8/22 (i386), 1/2 (arm) ID: 194274 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/194274 ID: 194275 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/194275 ID: 194289 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/194289 ID: 194297 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/194297 ID: 194299 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/194299 ID: 194300 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/194300 ID: 194301 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/194301 ID: 194302 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/194302 ID: 194304 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/194304 ID: 194305 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/194305 ID: 194307 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/194307 ID: 194315 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/194315 ID: 194318 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/194318 ID: 194319 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/194319 ID: 194320 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/194320 ID: 194321 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/194321 ID: 194322 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/194322 ID: 194323 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/194323 ID: 194324 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/194324 ID: 194334 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/194334 ID: 194346 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/194346 ID: 194357 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/194357 ID: 194358 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/194358 ID: 194360 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/194360 ID: 194363 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/194363 ID: 194364 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/194364 ID: 194366 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/194366 ID: 194369 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/194369 ID: 194374 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/194374 ID: 194382 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/194382 ID: 194390 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/194390 ID: 194402 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/194402 ID: 194405 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/194405 ID: 194406 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/194406 ID: 194407 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/194407 ID: 194410 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/194410 ID: 194412 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/194412 ID: 194418 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/194418 ID: 194425 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/194425 Soft failed openQA tests: 59/129 (x86_64), 14/22 (i386) (Tests completed, but using a workaround for a known bug) ID: 194277 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/194277 ID: 194278 Test: x86_64 Server-dvd-iso install_repository_nfs_graphic
Re: Vim: removing %{_libdir}/vim from vim-filesystem
Zdenek Dohnal wrote:
> Hi,
>
> I want to have vim-filesystem subpackage as noarch (as most packages
> with *-filesystem subpackage have), but dir mentioned above is
> architecture specific, so I want to remove it.
>
> This dir was added in bugzilla #1193230 as dir for plugins .so files. I
> made repo queries, if any package puts files there - none package from
> official Fedora repositories puts files in %{_libdir}/vim, so its
> removal shouldn't influence anyone.
FYI, it's still possible to own that dir from a noarch package (just
requires a little extra work, ie, you can't use %%_libdir macro )
-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Vim: removing %{_libdir}/vim from vim-filesystem
Hi,
I want to have vim-filesystem subpackage as noarch (as most packages
with *-filesystem subpackage have), but dir mentioned above is
architecture specific, so I want to remove it.
This dir was added in bugzilla #1193230 as dir for plugins .so files. I
made repo queries, if any package puts files there - none package from
official Fedora repositories puts files in %{_libdir}/vim, so its
removal shouldn't influence anyone.
I'm writing this email to just let you know - if this removal will cause
problems for someone, please let me know/file a bugzilla.
--
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Exclude paths for elfdeps dependency generator
Hi all, I have a question regarding the the RPM dependency generator scripts. I'm working on packaging the ROS stack [1,2] and I'm currently dealing with the dependency generation. My goal is to wrap all Provides and Requires for sonames because ROS does not use proper sonames (and therefore they shouldn't be in the ld cache), but I still want to use the information for ROS packages. This means I want to replace: Provides: librosconsole.so()(64bit) => Provides: ros(librosconsole.so()(64bit)) [or possibly ros-kinetic(librosconsole.so()(64bit))] and similarly for Requires. I have a working solution [3] that wraps all ROS Provides and Requires and generates other Provides and Requirest just as elfdeps does, but it uses an (imho ugly) hack: As I don't want to have the normal Provides generated by elfdeps, I have: %__ros_path ^/usr/lib.*/ros/.*$ %__elf_exclude_path %__ros_path in /usr/lib/rpm/fileattrs/ros.attr. I see two problems: If %__elf_exclude_path is set by something else, it is overridden, because I couldn't figure out how to append to the exclude path. Second, %__elf_exclude_path should not be set at all in ros.attr, the doc [4] says: "NAME needs to be replaced by the name choosen for the file attribute and needs to be the same as the file name of the macro file itself" It still works, but shouldn't according to the documentation. So my question: Is there any other way to exclude the ROS dir to be checked by elfdeps? I cannot just use %__requires_exclude_from because I want my dependency generator to run on the directory. Thanks for any hints. Kind regards, Till [1] https://pagure.io/ros [2] https://copr.fedorainfracloud.org/coprs/thofmann/ros/ [3] https://pagure.io/ros-rpm-macros [4] http://rpm.org/user_doc/dependency_generators.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Alexander Ploumistos wrote:
> Hi,
>
> I've been having a problem with dist.rpmdeplint checks for one of my
> packages (molsketch).
> This is a new package and it has a run-time dependency on OpenBabel:
>
> Requires: openbabel%{?_isa}
>
> The failure is the same on both f26 & f27:
>
> results:
> - arch: x86_64
> item: molsketch-0.5.1-7.fc26
> outcome: FAILED
> scenario: x86_64
> type: koji_build
>
>
> nothing provides openbabel(x86-32) needed by molsketch-0.5.1-7.fc26.i686
> nothing provides openbabel(x86-32) needed by molsketch-0.5.1-7.fc26.i686
>
> First question, why "arch" and "scenario" are x86_64, but the error
> concerns the 32-bit build? Since OpenBabel exists on all arches, why
> do I get this particular error message?
Your package is multilib'd?
> I have removed and reinstalled molsketch on both i686 and x86_64 with
> no errors from dnf
and openbable is not multilib'd, that's the problem.
Why do you have an explicit dep? Why is it arch'd?
If you sure it's still needed, a simple:
Requires: openbabel
should suffice.
-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Add link to cvedetail.com in CVE bugs?
I'm probably in the minority, but I wasn't even aware of this sight and I found it very helpful in addressing some CVE's for one of my packages. It provides links to bug trackers, links to other distros, and links to commits that address the CVE. It would be really helpful to provide a link in the CVE bugs. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Modularity Working Group IRC Meeting Minutes (2018-02-20)
= #fedora-meeting-3: Meeting of the Modularity Working Group (once every two weeks) = Meeting started by nils at 15:00:10 UTC. Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-02-20/modularity_wg.2018-02-20-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2018-02-20/modularity_wg.2018-02-20-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-02-20/modularity_wg.2018-02-20-15.00.log.html Meeting summary --- * Roll Call (nils, 15:00:17) * Agenda (nils, 15:02:04) * [contyk] f28 modular composes (nils, 15:02:35) * f28 modular composes (nils, 15:04:53) * LINK: https://pagure.io/releng/issue/7227 relevant releng ticket (nils, 15:08:48) * ACTION: dgilmore get back to langdon (contyk) about the status of pungi making modular & rpm composes (nils, 15:38:35) * ACTION: mboddu get back to langdon (contyk) about the status of pungi making modular & rpm composes (nils, 15:38:41) * LINK: https://pagure.io/releng/issue/7227 discussing the prior link and the status led to the actions (nils, 15:45:41) Meeting ended at 15:47:55 UTC. Action Items * dgilmore get back to langdon (contyk) about the status of pungi making modular & rpm composes * mboddu get back to langdon (contyk) about the status of pungi making modular & rpm composes Action Items, by person --- * contyk * dgilmore get back to langdon (contyk) about the status of pungi making modular & rpm composes * mboddu get back to langdon (contyk) about the status of pungi making modular & rpm composes * dgilmore * dgilmore get back to langdon (contyk) about the status of pungi making modular & rpm composes * langdon * dgilmore get back to langdon (contyk) about the status of pungi making modular & rpm composes * mboddu get back to langdon (contyk) about the status of pungi making modular & rpm composes * mboddu * mboddu get back to langdon (contyk) about the status of pungi making modular & rpm composes * **UNASSIGNED** * (none) People Present (lines said) --- * nils (58) * langdon (53) * zodbot (16) * jkaluza (13) * dgilmore (13) * contyk (10) * tflink (4) * mboddu (4) * mikedep333 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Test gating enabled in Bodhi
Hi,
I've been having a problem with dist.rpmdeplint checks for one of my
packages (molsketch).
This is a new package and it has a run-time dependency on OpenBabel:
Requires: openbabel%{?_isa}
The failure is the same on both f26 & f27:
results:
- arch: x86_64
item: molsketch-0.5.1-7.fc26
outcome: FAILED
scenario: x86_64
type: koji_build
nothing provides openbabel(x86-32) needed by molsketch-0.5.1-7.fc26.i686
nothing provides openbabel(x86-32) needed by molsketch-0.5.1-7.fc26.i686
First question, why "arch" and "scenario" are x86_64, but the error
concerns the 32-bit build? Since OpenBabel exists on all arches, why
do I get this particular error message?
I have removed and reinstalled molsketch on both i686 and x86_64 with
no errors from dnf, with the correct version of openbabel getting
pulled in every time, so I decided to submit waivers for the failing
results. That worked for the f27 package, but not for the f26 one. I
do get a "Created waiver 24 for result 19678515" from waiverdb-cli,
but even though the packages has spent a week in testing, I do not
have the option to push it to batched or stable and I do not think
this is a matter of time, since the f26 package got pushed to testing
earlier than that for f27.
I'd really appreciate any insights.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
REMINDER: F28 Software String Freeze in one week
According to the Fedora 28 schedule [1] we are going to reach the "Software String Freeze" deadline in one week on 2018-Feb-27. Beyond this deadline there should not be any changes in strings, ideally. If you want to help with translations then, please check the packages that follow Fedora release cycle (Main projects): https://fedora.zanata.org/version-group/view/main The time limit for the translations is according to the schedule [1] planned on 2018-Mar-06 (Software Translation Deadline). [1] https://fedorapeople.org/groups/schedule/f-28/f-28-trans-tasks.html Thanks for all translated strings and 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: new pagure repo is not accepted due to different e-mail addresses.
* Martin Gansser [20/02/2018 14:17] : > > It may be that I have 2 Bugzilla accounts, but the email address > mgansser (at) alice.de does not exist anymore. > How can I delete this old email account? You can file a bug against the Bugzilla product: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla I doubt the account will be deleted (that would break the database) but the Bugzilla admins might be able to merge the two accounts or disable the alice.de one. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new pagure repo is not accepted due to different e-mail addresses.
> * Martin Gansser [20/02/2018 13:30] : > > When I hover over your name in bug #1377631, I see mgansser (at) alice.de > in the tooltip. Are you sure you don't have two Bugzilla accounts? > > Emmanuel It may be that I have 2 Bugzilla accounts, but the email address mgansser (at) alice.de does not exist anymore. How can I delete this old email account? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 Change Checkpoint: Completion deadline (testable)
Greetings! Today, on 2018-Feb-20, we have reached Fedora 28 Change Checkpoint:Completion deadline (testable) [1]. At this point, all accepted changes [2] should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes [3] will be reported to FESCo on 2018-Feb-23 meeting. Contingency plan for System Wide Changes in case of serious doubts regarding Change completion, will be activated. [1] https://fedoraproject.org/wiki/Releases/28/Schedule [2] https://fedoraproject.org/wiki/Releases/28/ChangeSet [3] http://red.ht/2BEyQt0 -- 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
rpm-ostree v2018.3 and ostree v2018.2
A new release of rpm-ostree, a hybrid transactional image/package system is now available: https://bodhi.fedoraproject.org/updates/ostree-2018.2-1.fc27%20rpm-ostree-2018.3-1.fc27 Direct link to main release notes: https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.2 In this release we also updated the README.md with ASCII-art to clarify some how rpm-ostree links to both libdnf and libostree: https://github.com/projectatomic/rpm-ostree#rpm-ostree-a-true-hybrid-imagepackage-system ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] No more gnupg2 in buildroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, today I've split⁰ librpmsign from rpm-build-libs into its own subpackage rpm- sign-libs. This resulted into 8 packages disappearing from buildroot¹². This should not be a problem, but still useful to know. ⁰ https://src.fedoraproject.org/rpms/rpm/c/99d6687a36647cb307b789d19921a34154e9 c671 ¹ gnupg2, gnutls, ima-evm-utils, libassuan, libksba, libusbx, nettle, npth ² 171 → 163 packages - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqMHnsACgkQaVcUvRu8 X0wmUhAAtx5N4EQ+ulMHDkWyi1p96RGojp0H0xMudlai54sJOU/0FvNe8y0e0o6H ZERhdDKDgl7KtNEhSS/KsL+8Siog2PCSDv3SbwGrfeqegCRz/qOq4gqPsdLdkgCu dNtUNpvVIBwrTcNSU7igVnlnz5b9Su3TcCBunca3vCEEU5MKtEWQTYqFIjxOAjBX NGkuvmoY3hj07IP9Vh0q0VNyHCBfsXmVHruN9b8VFZx9IcEJ2OguQ6cFVzoeyeeI p4dlKza3znXeS53GtDA7WMGBEl/EI8Czh2/5JXgBZrshshfCY84pa2kZo0igC/3m lAbTCvGtqt8V4HW2RPttQsEtvTrRseuXWRXvNIcrXXiTaB6XyRaf58tY3jWerK5k 3KlDyMSNvD6neSrk7ujykX5Wh4qQAvmvSrjEeYAPpwIoBh1uAH1yKQJ1THPSxwff 9u/kU7bnGfJOIMAi0AQR3jNBxFVWZzEZisA/k6M5RwKLdb+Lvcxpz39wTSzqd0SE 0dMP5VWZ50P9JGh+xmWPtYWId7qzbYsXxzLBTwtbDZNfoUGxawF8jsxLN35tsgw9 Mojw9R34uq1ytPYcg6tIX2tryDW2oBm9AhKPC6+WKCjJeQIZze1YzL+cdFsd0aba 9+smUVTWBRaXI6CL9luXkjSG4jzu7C2Fb7Fvb4/PZ0bM0ZtNhUk= =wlgf -END PGP SIGNATURE- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new pagure repo is not accepted due to different e-mail addresses.
* Martin Gansser [20/02/2018 13:30] : > > the email address is already mgansser(a)online.de on the top of page see: When I hover over your name in bug #1377631, I see mgansser (at) alice.de in the tooltip. Are you sure you don't have two Bugzilla accounts? Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new pagure repo is not accepted due to different e-mail addresses.
> * Martin Gansser [20/02/2018 12:30] : > > You can see it in the banner (the red bar at the very top) of that page. > > Emmanuel the email address is already mgansser(a)online.de on the top of page see: https://martinkg.fedorapeople.org/Pictures/bugzilla.png ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf: Can't tell me what is pulling in a dependency?
On Sun, Feb 18, 2018 at 12:14 PM, Sérgio Basto wrote: > On Sun, 2018-02-18 at 08:10 -0600, Richard Shaw wrote: > > I was updating my mythtv box and I saw that it was pulling in some mysql > community packages as a dependency but I looked through the options and I > couldn't find ANYTHING that would tell me what was pulling in those > packages. Nov "-v" and not "--debugsolver". > > Is it really not possible? > > > it is debugsolver : > > dnf --debugsolver upgrade -b > > but it is my fault I added > Requires: mysql-compat-server >= 5 > Requires: mysql >= 5 > That was my first thought but mythtv was not updated on that transaction so I thought maybe it was something else pulling it in... > maybe we need added > Suggests: mariadb-server mariadb > But I already had those installed, it shouldn't have needed to pull in the mysql packages... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
On 01/05/2018 02:50 PM, Jan Kurik wrote: = System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault Change owner(s): * Pavel Březina Replace authconfig with authselect and make authselect a default tool to configure PAM and nsswitch.conf. A compatibility tool will help with transition period from authconfig to authselect. Authselect is a tool to select system authentication and identity sources from a list of supported profiles and it is available to users since Fedora 27. Authselect is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the pam stack with a tool (which may potentially end up with a broken configuration), it ships several tested stacks (profiles) that solve primary supported use cases and are well tested and supported. At the same time, some obsolete features of authconfig are not supported by authselect. Additionally, authselect is written in C and has a small footprint which allows it to be also part of minimal installations. I pushed authselect-0.3 to rawhide. Realmd is converted to authselect and was pushed as well. Anaconda, fprintd will be available soon and ipa changes are still under development, but they all should work now through compatibility tool. There is a new package: authselect-compat, which provides "authconfig". It is a python script that provides minimum level of compatibility with authconfig. Its purpose it not to reimplement all authconfig features, but it translates it to authselect calls and writes few configuration files in order to allow authentication. But not all authconfig options are supported. It prints a loud deprecation warning. Please, test it. There is a authselect-migration(7) manual page that will help users with the migration process. As requested on this list, custom profile directory has been moved to /etc/authselect/custom. Authselect cli has unified and documented return codes so it can be used in users scripts. I also implemented new template engine, which is not backwards compatible but this is acceptable for this release since it is still in a testing phase. Now the templates are clear and reads very good, see: https://raw.githubusercontent.com/pbrezina/authselect/master/profiles/sssd/smartcard-auth There is now authselect-devel package that allows you to use our API in C. We also plan to provide python bindings and ansible module in future versions (F29 scope). We already have one external contributor, I'm happy to see there is interest in this project from community. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/20/2018 01:02 PM, Zdenek Dohnal wrote: On 02/18/2018 06:09 PM, Igor Gnatenko wrote: List of packages and respective maintainers: https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt Done in packages where I am admin. TY! J. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new pagure repo is not accepted due to different e-mail addresses.
* Martin Gansser [20/02/2018 12:30] : > > where can I see in bugzilla the wrong email address ? > https://bugzilla.redhat.com/userprefs.cgi?tab=email You can see it in the banner (the red bar at the very top) of that page. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Remove GCC from BuildRoot
On 18/02/18 16:22 +, Zbigniew Jędrzejewski-Szmek wrote: Fedora decided to use gcc as *the* compiler [1], and frankly, we have enough trouble getting packages to compile without trying to support more than one compiler (vide the lass mass rebuild). Also a *lot* of core GCC devs work on Fedora, and only a small number of LLVM/Clang people are involved. Unless we're suddenly going to get a lot more Clang expertise, I don't think support for building packages with Clang will be a good use of Fedora's resources. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new pagure repo is not accepted due to different e-mail addresses.
> * Martin Gansser [20/02/2018 10:02] : > > Your FAS account has the email mgansser(a)online.de but > your bugzilla account uses mgansser(a)alice.de . > > Emmanuel where can I see in bugzilla the wrong email address ? https://bugzilla.redhat.com/userprefs.cgi?tab=email ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/18/2018 06:09 PM, Igor Gnatenko wrote: > > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > zdohnalc2esp cups cups-filters enscript foomatic hplip jbigkit mgetty > openobex pnm2ppa ptouch-driver python-cups python-smbc qpdf sane-backends > sane-frontends splix system-config-printer vim xsane Done in packages where I am the main admin. -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C 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: Re: Dynamically-generated C stored in SVN is breaking our distribution because life is awful (was Re: F28 System Wide Change: GCC8)
BTW dovecot is broken by all the compiler and crypto changes, both for the two last rebuilds (that failed) and the build before (that succeeded but has broken auth which is sort of needed for an imap server) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Dynamically-generated C stored in SVN is breaking our distribution because life is awful (was Re: F28 System Wide Change: GCC8)
On Feb 20, 2018 08:54, "Adam Williamson" wrote: On Mon, 2018-02-19 at 22:57 -0800, Adam Williamson wrote: > On Tue, 2018-01-09 at 21:51 +0100, Jakub Jelinek wrote: > > On Tue, Jan 09, 2018 at 07:50:10PM +, Stephen Gallagher wrote: > > > > Well, true, but then just like every year, we'll wind up doing a lot of > > > > the spadework of fixing things to build with the new GCC. And probably > > > > at first some critical things will fail to build and that'll mess up > > > > the stability of the distro for a couple of weeks. I guess if everyone > > > > else is still loving that grind, hey. > > > > > > > > > > > > > This is the cost of being "First". Fedora has long enjoyed a tight coupling > > > with the GCC upstream. It's a symbiosis: they use our mass-rebuild to help > > > identify any issues before GCC goes stable and in turn Fedora gets to have > > > the newest compiler features before anyone else. > > > > To be fair, Ubuntu (or Debian or both, dunno) has already performed test mass > > rebuilds with GCC 8 prerelease some time ago and OpenSUSE usually performs them > > roughly at the same time as we do. We are likely the first one or one of > > the first ones to deploy it as a stable compiler in the distro and it is > > mutually beneficial both for the distro and for GCC. > > Just for the record, it is now 11pm the day before we are supposed to > branch Fedora 28, and I have spent the whole evening fixing > OpenColorIO's Python bindings to build with GCC 8: > > https://github.com/imageworks/OpenColorIO/pull/518 > > only to find that it fails to build on i686 because since pdftex got > rebuilt with GCC 8 (OK, haven't confirmed that yet, but it's the most > obvious suspect), it's segfaulting: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=25176488 > > Also noted by QuLogic trying to build R-htmltools: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=25173683 > > So now I am running the build in an i686 mock so I can shell into the > mock and hopefully get a traceback of the pdftex crash and try to do > *something* about fixing it. So, here lies a hilarious tale of dynamic generation of entirely undocumented C code using single-character variable names by a ridiculously arcane build system tracked in Subversion: Wow, that's exceptionally awful. You're a hero for tracking down and fixing those things. Really. Thank you. Fabio https://bugzilla.redhat.com/show_bug.cgi?id=1546964 Excuse me while I go break some stuff. -- 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: to batch or not to batch?
On Mon, Feb 19, 2018 at 04:02:56PM +0100, Kalev Lember wrote: > On 02/19/2018 03:40 PM, Randy Barlow wrote: > > On 02/19/2018 06:34 AM, Vít Ondruch wrote: > >> But anyway, why don't we > >> have "updates-testing", "updates-batched" and "updates" repositories? > >> "updates-batched" could be enabled by default while "updates" could be > >> enabled manually if one wishes. > > > > When we talked about this in the past I believe resources were the > > concern, both on the Fedora infrastructure side and on the mirroring side. > > I think a new, additional repo with batched contents should solve a lot > of problems here: we'd have both side of the fence happy (regular users: > batched updates, developers: continuous stream of updates), and it would > also make it possible to actually QA the batched set before it hits the > mirrors. Those are good points. I'd also add that since this removes the reason why developers were overriding batched to push to stable, hopefully we would see more packages go to batched. > Right now there's no way for QA to only extract batched updates without > getting all the rest of updates-testing; if we had that we could > actually have people test the batched set of updates before they are > pushed out to stable. That answer another doubt that people had. Zbyszek > P.S. Those who were at the Atomic Workstation call that ended a few > minutes ago, I believe this is what we need to solve the split updates > problem that we talked about. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: new pagure repo is not accepted due to different e-mail addresses.
* Martin Gansser [20/02/2018 10:02] : > > I am not aware that the email addresses are different. Your FAS account has the email mgans...@online.de but your bugzilla account uses mgans...@alice.de . Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
new pagure repo is not accepted due to different e-mail addresses.
i get this message from limb in the pagure ticket [1] The Bugzilla review bug creator could not be found in FAS. Make sure your FAS email address is the same as in Bugzilla. I am not aware that the email addresses are different. [1] pagure ticket: https://pagure.io/releng/fedora-scm-requests/issue/4602 [2] https://bugzilla.redhat.com/userprefs.cgi?tab=email ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: F29 System Wide Change: Remove GCC from BuildRoot
Le mardi 20 février 2018 à 09:01 +0100, Nicolas Mailhot a écrit : > Le mardi 20 février 2018 à 08:44 +0100, Vít Ondruch a écrit : > > > > Dne 19.2.2018 v 17:16 Dennis Gilmore napsal(a): > > > redhat-rpm-config taht is needed has grown dependencies, as > > > language > > > specifc macros have moved into their own space > > > > So we removed Perl from buildroot, but there is already something > > which > > consumes the saved DL and install size of Perl and on top of that it > > adds additional 10 MB to DL and 50 MB to installation? Well done ... > > That just means language specific macros need more work. > > The language-srpm-macros package that should be in the build root now, > should not require the compiler and lots of heavy packages, but just > provide a language-specific macro that inserts a > BuildRequires: language-rpm-macros > > with language-rpm-macros doing the heavy lifting and not present in > the > build root by default. (the language-srpm-macros macro can of course do a lot more stuff, such as mapping the language-specific identifier to an rpm-friendly lowercase name with the right prefix and separator, as long as it does not need the whole compiler suite) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Remove GCC from BuildRoot
Le mardi 20 février 2018 à 08:44 +0100, Vít Ondruch a écrit : > > Dne 19.2.2018 v 17:16 Dennis Gilmore napsal(a): > > redhat-rpm-config taht is needed has grown dependencies, as language > > specifc macros have moved into their own space > > So we removed Perl from buildroot, but there is already something > which > consumes the saved DL and install size of Perl and on top of that it > adds additional 10 MB to DL and 50 MB to installation? Well done ... That just means language specific macros need more work. The language-srpm-macros package that should be in the build root now, should not require the compiler and lots of heavy packages, but just provide a language-specific macro that inserts a BuildRequires: language-rpm-macros with language-rpm-macros doing the heavy lifting and not present in the build root by default. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
