Re: Where did res_querydomain go in f24??
On 09/02/2016 01:00 AM, Steve Dickson wrote: Hello, This is regard to bz1372136... as the bz says From Koji logs : - x86_64 and armv7hl have an issue in configure : checking for res_querydomain in -lresolv... no - i686 works : checking for res_querydomain in -lresolv... yes This is strange, since the symbol in present in /lib/libresolv-2.23.so. Here was has res_querydomain or even res_nquerydomain moved to to?? > Why can't I find it with a AC_CHECK_FUNC() or a AC_CHECK_LIB() macros? The function symbol has always been __res_querydomain. The autoconf test is invalid. You need to include the header first and then use the function in some way that makes it into the binary (you cannot declare your own prototype, like many autoconf tests do). This, in turn, causes libresolv to be dropped from the static link, and the resulting DSO is invalid, for two reasons: There is no DT_NEEDED entry for libresolv.so.2 (leading to undefined symbols), and the symbol references are unversioned (which means the dynamic linker will potentially bind them to a compatibility symbol). Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
On 08/31/2016 02:10 PM, Charalampos Stratakis wrote: > Hello all, > > While checking out the SPEC file of python, it seems there were some packages > that, while separate at some point, they got included in python's stdlib and > then obsoleted as standalone packages (thus to cope with the change, python > was obsoleting these packages and providing them as well in the SPEC). So > every package that currently (Build)Requires any of these packages will > essentially drag python with it. > > I will remove these provides soon, since the packages were orphaned long time > ago, but the packages that still require them, will need to be fixed and > (Build)Require python instead. My suggestion would be to request provenpackager access and just fix all those packages yourself in rawhide. If you file bugs, these are probably going to take quite a bit of time to get fixed and you won't be able to drop the compatibility provides for several Fedora releases. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
On 09/02/2016 06:44 AM, Kalev Lember wrote: > On 08/31/2016 02:10 PM, Charalampos Stratakis wrote: >> Hello all, >> >> While checking out the SPEC file of python, it seems there were some >> packages that, while separate at some point, they got included in python's >> stdlib and then obsoleted as standalone packages (thus to cope with the >> change, python was obsoleting these packages and providing them as well in >> the SPEC). So every package that currently (Build)Requires any of these >> packages will essentially drag python with it. >> >> I will remove these provides soon, since the packages were orphaned long >> time ago, but the packages that still require them, will need to be fixed >> and (Build)Require python instead. > > My suggestion would be to request provenpackager access and just fix all > those packages yourself in rawhide. If you file bugs, these are probably > going to take quite a bit of time to get fixed and you won't be able to > drop the compatibility provides for several Fedora releases. > Or just prep the patches and ask a provenpackager to apply them for you, which is probably faster than getting access yourself. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
There are already some bugzillas open for some of the packages, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1249129 Of course I could prepare the patches and ask a proven packager for a rebuild, but maybe that would be too invasive so I want to get some feedback first on what could be the best course of action in this case. Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Stephen Gallagher" To: devel@lists.fedoraproject.org Sent: Friday, September 2, 2016 12:56:30 PM Subject: Re: BuildRequires on obsoleted packages provided by Python On 09/02/2016 06:44 AM, Kalev Lember wrote: > On 08/31/2016 02:10 PM, Charalampos Stratakis wrote: >> Hello all, >> >> While checking out the SPEC file of python, it seems there were some >> packages that, while separate at some point, they got included in python's >> stdlib and then obsoleted as standalone packages (thus to cope with the >> change, python was obsoleting these packages and providing them as well in >> the SPEC). So every package that currently (Build)Requires any of these >> packages will essentially drag python with it. >> >> I will remove these provides soon, since the packages were orphaned long >> time ago, but the packages that still require them, will need to be fixed >> and (Build)Require python instead. > > My suggestion would be to request provenpackager access and just fix all > those packages yourself in rawhide. If you file bugs, these are probably > going to take quite a bit of time to get fixed and you won't be able to > drop the compatibility provides for several Fedora releases. > Or just prep the patches and ask a provenpackager to apply them for you, which is probably faster than getting access yourself. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unversioned and >/=/>= obsoletes
All guidelines mandate the use of 292 binary rpms) with
unversioned Obsoletes or with >/=/>= Obsoletes.
It is causing problems with upgrade (if package is getting re-added)
or with 3rd-party repositories. Older package is obsoleting new
package.
Problem categories (in following text by "never" I mean latest N-2 releases):
* Package/SubPackage was never built in Fedora
Package "python" has "Obsoletes: python2" which was never built ->
drop Obsoletes
SubPackage "qpid-proton-c" of "qpid-proton" has "Obsoletes:
qpid-proton" which was not the package for long time -> drop Obsoletes
* Package replacement
Package "storaged" has "Obsoletes: udisks2" -> take latest version
from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2
storaged is not simple use-case as it replaces udisks2, but latter is
still not retired.
* "=" Obsoletes
"rubygem-vte" has "Obsoletes: ruby-vte = 3.0.9-1.fc26" (probably it's
macro in spec) which seems really weird as it will not obsolete
F24/F25 with such version
* Obsoletes by Provides
It doesn't work to prevent undefined behavior. Imagine you have
installed "A" and "B", both providing "C". Package "D" has "Obsoletes:
C", it should not remove "A" and "B".
** %{?_isa}
"glibc-headers" has "Obsoletes: glibc-headers(i686)". %{?_isa} is just
text, it's not part of architecture or something else.
** Other provides
"rubygem-http_connection" has "Obsoletes:
rubygem(right_http_connection)". Latter is virtual provides.
* Weird obsoletes (broken)
"krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686".
Basically it will not obsolete anything because it's threated as
package name (and we definitely don't have such package name).
* >/>= Obsoletes
"vdsm" has "Obsoletes: vdsm-infra >= 4.16.0". It's almost same as
unversioned Obsoletes. So it must not be used.
Table of affected packages/maintainers:
https://ignatenkobrain.fedorapeople.org/broken-obsoletes/2016-09-02/broken-obsoletes.txt
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 07:14 AM, Igor Gnatenko wrote: > All guidelines mandate the use of have some number of packages (179 source rpms -> 292 binary rpms) with > unversioned Obsoletes or with >/=/>= Obsoletes. > > It is causing problems with upgrade (if package is getting re-added) > or with 3rd-party repositories. Older package is obsoleting new > package. > > Problem categories (in following text by "never" I mean latest N-2 releases): > > * Package/SubPackage was never built in Fedora > Package "python" has "Obsoletes: python2" which was never built -> > drop Obsoletes > SubPackage "qpid-proton-c" of "qpid-proton" has "Obsoletes: > qpid-proton" which was not the package for long time -> drop Obsoletes > > * Package replacement > Package "storaged" has "Obsoletes: udisks2" -> take latest version > from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2 > storaged is not simple use-case as it replaces udisks2, but latter is > still not retired. > Right, the official plan on this is to retire udisks2 immediately prior to Beta Freeze[1] That said, the Obsoletes *should* be versioned. That way if we opted down the line to re-add it (or change storaged's name, etc.) it could be done. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LDF3UVM65RRF4WWF243RWQNLEQKFQJLQ/#LDF3UVM65RRF4WWF243RWQNLEQKFQJLQ > * Weird obsoletes (broken) > "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686". > Basically it will not obsolete anything because it's threated as > package name (and we definitely don't have such package name). > This definitely looks odd... Robbie? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
Dne 31.8.2016 v 14:10 Charalampos Stratakis napsal(a): > glacier-cli Fixed. This was meant only for el6, but the %if was incorrectly constructed. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ppisar set the monitor flag of perl-Getopt-Lucid to nobuild
ppisar set the monitor flag of perl-Getopt-Lucid to nobuild -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 02, 2016 at 01:14:13PM +0200, Igor Gnatenko wrote: > Table of affected packages/maintainers: > https://ignatenkobrain.fedorapeople.org/broken-obsoletes/2016-09-02/broken-obsoletes.txt I fixed open-vm-tools, only in dist-git. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, 2016-09-02 at 13:14 +0200, Igor Gnatenko wrote: > * Package replacement > Package "storaged" has "Obsoletes: udisks2" -> take latest version > from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2 > storaged is not simple use-case as it replaces udisks2, but latter is > still not retired. Everyone OK if I retire it in rawhide now? I think if we were going to have any issue that would cause us to switch back to udisks, it would have manifested by now. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 07:55 AM, Michael Catanzaro wrote: > On Fri, 2016-09-02 at 13:14 +0200, Igor Gnatenko wrote: >> * Package replacement >> Package "storaged" has "Obsoletes: udisks2" -> take latest version >> from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2 >> storaged is not simple use-case as it replaces udisks2, but latter is >> still not retired. > > Everyone OK if I retire it in rawhide now? I think if we were going to > have any issue that would cause us to switch back to udisks, it would > have manifested by now. Makes sense to me. Do we want to do F25 at the same time or wait until closer to Beta Freeze (2016-09-27)? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 02:36 PM, Stephen Gallagher wrote: > On 09/02/2016 07:55 AM, Michael Catanzaro wrote: >> On Fri, 2016-09-02 at 13:14 +0200, Igor Gnatenko wrote: >>> * Package replacement >>> Package "storaged" has "Obsoletes: udisks2" -> take latest version >>> from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2 >>> storaged is not simple use-case as it replaces udisks2, but latter is >>> still not retired. >> >> Everyone OK if I retire it in rawhide now? I think if we were going to >> have any issue that would cause us to switch back to udisks, it would >> have manifested by now. > > Makes sense to me. Do we want to do F25 at the same time or wait until closer > to > Beta Freeze (2016-09-27)? Please do it now if you plan to do it for F25, so that if there's any fallout we get to find out about it now and have time to fix things. If it lands close to a freeze there probably won't be any time to fix things up before the freeze hits us. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 08:44 AM, Kalev Lember wrote: > On 09/02/2016 02:36 PM, Stephen Gallagher wrote: >> On 09/02/2016 07:55 AM, Michael Catanzaro wrote: >>> On Fri, 2016-09-02 at 13:14 +0200, Igor Gnatenko wrote: * Package replacement Package "storaged" has "Obsoletes: udisks2" -> take latest version from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2 storaged is not simple use-case as it replaces udisks2, but latter is still not retired. >>> >>> Everyone OK if I retire it in rawhide now? I think if we were going to >>> have any issue that would cause us to switch back to udisks, it would >>> have manifested by now. >> >> Makes sense to me. Do we want to do F25 at the same time or wait until >> closer to >> Beta Freeze (2016-09-27)? > > Please do it now if you plan to do it for F25, so that if there's any > fallout we get to find out about it now and have time to fix things. If > it lands close to a freeze there probably won't be any time to fix > things up before the freeze hits us. > Well, if there was fallout during the Beta period, there would still be Final to revert it, but in general I agree: let's do it sooner rather than later, while we have more time to react. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, 2 Sep 2016 13:14:13 +0200, Igor Gnatenko wrote: > All guidelines mandate the use of have some number of packages (179 source rpms -> 292 binary rpms) with > unversioned Obsoletes or with >/=/>= Obsoletes. > > It is causing problems with upgrade (if package is getting re-added) > or with 3rd-party repositories. Older package is obsoleting new > package. Good luck with trying to get some packagers to fix such issues! I appreciate the effort as I've reported similar things many times before, but some packagers just don't respond in bugzilla or overwrite changes applied to git after waiting months for a reply. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 2, 2016 at 3:34 PM, Michael Schwendt wrote: > On Fri, 2 Sep 2016 13:14:13 +0200, Igor Gnatenko wrote: > >> All guidelines mandate the use of > have some number of packages (179 source rpms -> 292 binary rpms) with >> unversioned Obsoletes or with >/=/>= Obsoletes. >> >> It is causing problems with upgrade (if package is getting re-added) >> or with 3rd-party repositories. Older package is obsoleting new >> package. > > Good luck with trying to get some packagers to fix such issues! > I appreciate the effort as I've reported similar things many times before, > but some packagers just don't respond in bugzilla or overwrite changes > applied to git after waiting months for a reply. Isn't this is a guidelines, so if packager ignores them - he should be punished? > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Intel Vulkan driver status
We need Vulkan loader which is now on review. I will take care of it ASAP. On Fri, Sep 2, 2016 at 3:56 PM, Michael Cronenworth wrote: > Why is the Vulkan driver being left out right now? > > Here's the RFE[1] from July asking for it to be enabled. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1356229 > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Intel Vulkan driver status
Why is the Vulkan driver being left out right now? Here's the RFE[1] from July asking for it to be enabled. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1356229 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Intel Vulkan driver status
On 09/02/2016 08:59 AM, Igor Gnatenko wrote: We need Vulkan loader which is now on review. I will take care of it ASAP. I see it[1] now. Thanks, Igor. If there is anything I can do to help with the review just let me know. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1308985 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 2, 2016 at 7:21 PM, Igor Gnatenko wrote: > On Fri, Sep 2, 2016 at 3:34 PM, Michael Schwendt wrote: >> On Fri, 2 Sep 2016 13:14:13 +0200, Igor Gnatenko wrote: >> >>> All guidelines mandate the use of >> have some number of packages (179 source rpms -> 292 binary rpms) with >>> unversioned Obsoletes or with >/=/>= Obsoletes. >>> >>> It is causing problems with upgrade (if package is getting re-added) >>> or with 3rd-party repositories. Older package is obsoleting new >>> package. >> >> Good luck with trying to get some packagers to fix such issues! >> I appreciate the effort as I've reported similar things many times before, >> but some packagers just don't respond in bugzilla or overwrite changes >> applied to git after waiting months for a reply. > Isn't this is a guidelines, so if packager ignores them - he should be > punished? No, packager's sponsor will be contacted and he will guide the packager for the correct usage of packaging guidelines. Regards, Parag -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 2, 2016 at 9:51 AM, Igor Gnatenko wrote: > On Fri, Sep 2, 2016 at 3:34 PM, Michael Schwendt wrote: >> On Fri, 2 Sep 2016 13:14:13 +0200, Igor Gnatenko wrote: >> >>> All guidelines mandate the use of >> have some number of packages (179 source rpms -> 292 binary rpms) with >>> unversioned Obsoletes or with >/=/>= Obsoletes. >>> >>> It is causing problems with upgrade (if package is getting re-added) >>> or with 3rd-party repositories. Older package is obsoleting new >>> package. >> >> Good luck with trying to get some packagers to fix such issues! >> I appreciate the effort as I've reported similar things many times before, >> but some packagers just don't respond in bugzilla or overwrite changes >> applied to git after waiting months for a reply. > Isn't this is a guidelines, so if packager ignores them - he should be > punished? We have no recourse for punishment. Frankly, that's not a great plan anyway. We should focus on collaboration and education, not punitive actions. I would rather focus on fixing the packages. If the primary contact can't or won't do it, then a provenpackager should be able to fix it instead. If there's a persistent issue with reverts of those kinds of changes or something, we can figure it out later. josh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
There is the Non-responsive Maintainer Policy [0] however it takes way too long, and in the end you will get ownership of the package, so if you want to do a minor fix to a package (and the maintainer is not responding), you will either need to wait 3+ weeks and then get the package and do it yourself, or bug provenpackagers to do the change for you. Then of course people will either complain that they didn't see the bugzilla's for x,y reasons or that they didn't want the change from a proven packager. Not sure if there is a perfect solution that would satisfy everyone for this case. [0] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Igor Gnatenko" To: "Development discussions related to Fedora" Sent: Friday, September 2, 2016 3:51:54 PM Subject: Re: Unversioned and >/=/>= obsoletes On Fri, Sep 2, 2016 at 3:34 PM, Michael Schwendt wrote: > On Fri, 2 Sep 2016 13:14:13 +0200, Igor Gnatenko wrote: > >> All guidelines mandate the use of > have some number of packages (179 source rpms -> 292 binary rpms) with >> unversioned Obsoletes or with >/=/>= Obsoletes. >> >> It is causing problems with upgrade (if package is getting re-added) >> or with 3rd-party repositories. Older package is obsoleting new >> package. > > Good luck with trying to get some packagers to fix such issues! > I appreciate the effort as I've reported similar things many times before, > but some packagers just don't respond in bugzilla or overwrite changes > applied to git after waiting months for a reply. Isn't this is a guidelines, so if packager ignores them - he should be punished? > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Where did res_querydomain go in f24??
On 09/02/2016 02:59 AM, Florian Weimer wrote: > On 09/02/2016 01:00 AM, Steve Dickson wrote: >> Hello, >> >> This is regard to bz1372136... as the bz says >> >> From Koji logs : >> - x86_64 and armv7hl have an issue in configure : checking for >> res_querydomain in -lresolv... no >> - i686 works : checking for res_querydomain in -lresolv... yes >> This is strange, since the symbol in present in /lib/libresolv-2.23.so. >> >> Here was has res_querydomain or even res_nquerydomain moved to to?? >> Why can't I find it with a AC_CHECK_FUNC() or a AC_CHECK_LIB() macros? > > The function symbol has always been __res_querydomain. The autoconf test is > invalid. You need to include the header first and then use the > function in some way that makes it into the binary (you cannot declare your > own prototype, like many autoconf tests do). > > This, in turn, causes libresolv to be dropped from the static link, and the > resulting DSO is invalid, for two reasons: There is no DT_NEEDED entry for > libresolv.so.2 (leading to undefined symbols), and the symbol references are > unversioned (which means the dynamic linker will potentially bind them to a > compatibility symbol). > I got it... thanks! steved. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160902.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 26/89 (x86_64), 3/17 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20160831.n.0): ID: 31786 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/31786 ID: 31837 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/31837 Old failures (same test failed in Rawhide-20160831.n.0): ID: 31739 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31739 ID: 31742 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31742 ID: 31749 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31749 ID: 31752 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31752 ID: 31754 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31754 ID: 31761 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/31761 ID: 31764 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31764 ID: 31766 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31766 ID: 31774 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/31774 ID: 31777 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/31777 ID: 31789 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/31789 ID: 31793 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/31793 ID: 31804 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/31804 ID: 31806 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/31806 ID: 31807 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/31807 ID: 31808 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/31808 ID: 31809 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/31809 ID: 31810 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/31810 ID: 31811 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/31811 ID: 31812 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/31812 ID: 31813 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/31813 ID: 31814 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/31814 ID: 31815 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/31815 ID: 31821 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31821 ID: 31824 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/31824 ID: 31825 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/31825 ID: 31844 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31844 ID: 31845 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31845 Passed openQA tests: 63/89 (x86_64), 14/17 (i386) New passes (same test did not pass in Rawhide-20160831.n.0): ID: 31741 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/31741 ID: 31743 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/31743 ID: 31744 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/31744 ID: 31745 Test: x86_64 Workstation-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/31745 ID: 31746 Test: x86_64 Workstation-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/31746 ID: 31747 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/31747 ID: 31748 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31748 ID: 31750 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/31750 ID: 31751 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31751 ID: 31772 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/317
Last DNF-1 version, DNF-2 coming to rawhide
Hi, DNF-1.1.10 and DNF-PLUGINS-CORE-0.1.21 has been released. Note this will be the last version and only critical bug fixes will be backported into DNF-1. Look into release notes [1][2] for more details. DNF-2 (current DNF upstream) will be actively developed and take the lead. DNF-2 release candidate will land into rawhide. It will bring many new features and bug fixes. DNF-2 is using libdnf instead of hawkey or libhif. Unfortunately it brings some incompatibilities with previous version which were either needed to preserve compatibility with yum CLI or where bigger redesigns were needed (parsing command line arguments). If you own any DNF plugin or component depending on DNF, please, see the DNF-1 and DNF-2 changes [3] and adjust your package accordingly. Moreover bump the DNF requirement as DNF honors semantic versioning [4] to prevent future breakage when another major version is deployed. To majority of components requiring DNF in Fedora repository were sent patches to adapt them to DNF-2. Thanks, Honza [1] http://dnf.baseurl.org/2016/08/22/dnf-1-1-10-and-dnf-plugins-core-0-1-21-3-released/ [2] http://dnf.readthedocs.io/en/latest/release_notes.html#release-notes [3] http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html [4] http://dnf.readthedocs.io/en/latest/api.html#versioning -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On Fri, Sep 02, 2016 at 05:04:40PM +0200, Honza Silhan wrote: > > DNF-2 release candidate will land into rawhide. It will bring many new > features and bug fixes. DNF-2 is using libdnf instead of hawkey or > libhif. Unfortunately it brings some incompatibilities with previous > version which were either needed to preserve compatibility with yum > CLI or where bigger redesigns were needed (parsing command line > arguments). If you own any DNF plugin or component depending on DNF, > please, see the DNF-1 and DNF-2 changes [3] and adjust your package > accordingly. Moreover bump the DNF requirement as DNF honors semantic > versioning [4] to prevent future breakage when another major version > is deployed. To majority of components requiring > DNF in Fedora repository were sent patches to adapt them to DNF-2. > Sounds like this scope would warrant a Change? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160902.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Failed openQA tests: 11/89 (x86_64), 3/17 (i386), 1/2 (arm) New failures (same test did not fail in 25-20160901.n.0): ID: 31885 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/31885 ID: 31893 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/31893 ID: 31894 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/31894 ID: 31930 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/31930 ID: 31945 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/31945 Old failures (same test failed in 25-20160901.n.0): ID: 31860 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31860 ID: 31869 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/31869 ID: 31912 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/31912 ID: 31926 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/31926 ID: 31931 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/31931 ID: 31932 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/31932 ID: 31933 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/31933 ID: 31934 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31934 ID: 31952 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31952 ID: 31953 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31953 Passed openQA tests: 78/89 (x86_64), 14/17 (i386) New passes (same test did not pass in 25-20160901.n.0): ID: 31850 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31850 ID: 31856 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31856 ID: 31857 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31857 ID: 31858 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/31858 ID: 31859 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31859 ID: 31881 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/31881 ID: 31882 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/31882 ID: 31883 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/31883 ID: 31884 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/31884 ID: 31886 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/31886 ID: 31928 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/31928 ID: 31929 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31929 ID: 31955 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/31955 ID: 31956 Test: x86_64 Workstation-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/31956 ID: 31957 Test: x86_64 Workstation-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/31957 ID: 31958 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/31958 ID: 31959 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/31959 ID: 31960 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/31960 Skipped openQA tests: 1 of 108 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, 2016-09-02 at 08:47 -0400, Stephen Gallagher wrote: > Well, if there was fallout during the Beta period, there would still > be Final to > revert it, but in general I agree: let's do it sooner rather than > later, while > we have more time to react. OK, done. Hopefully nothing breaks. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On Fri, Sep 2, 2016 at 5:20 PM, Tomasz Torcz wrote: > On Fri, Sep 02, 2016 at 05:04:40PM +0200, Honza Silhan wrote: >> >> DNF-2 release candidate will land into rawhide. It will bring many new >> features and bug fixes. DNF-2 is using libdnf instead of hawkey or >> libhif. Unfortunately it brings some incompatibilities with previous >> version which were either needed to preserve compatibility with yum >> CLI or where bigger redesigns were needed (parsing command line >> arguments). If you own any DNF plugin or component depending on DNF, >> please, see the DNF-1 and DNF-2 changes [3] and adjust your package >> accordingly. Moreover bump the DNF requirement as DNF honors semantic >> versioning [4] to prevent future breakage when another major version >> is deployed. To majority of components requiring >> DNF in Fedora repository were sent patches to adapt them to DNF-2. >> > > Sounds like this scope would warrant a Change? The components should be already prepared for DNF-2 and the changes are not huge. There's the FESCO ticket [5]. If it is not accepted then we will submit a Change. Honza [5] https://fedorahosted.org/fesco/ticket/1625 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, 2016-09-02 at 08:36 -0400, Stephen Gallagher wrote: > Makes sense to me. Do we want to do F25 at the same time or wait > until closer to > Beta Freeze (2016-09-27)? I just did both rawhide and F25. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2016-09-02)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-08-12 16:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1609Fedora 26 schedule proposal .fesco 1609 https://fedorahosted.org/fesco/ticket/1609 #topic #1614FHS exception for /snap .fesco 1614 https://fedorahosted.org/fesco/ticket/1614 #topic #1617Council update on Third Party Software policy .fesco 1617 https://fedorahosted.org/fesco/ticket/1617 #topic #1620Decide what to do when package is retired and nothing replaces it directly .fesco 1620 https://fedorahosted.org/fesco/ticket/1620 = New Business = #topic #1622F26 System Wide Change: Python 3.6 .fesco 1622 https://fedorahosted.org/fesco/ticket/1622 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/02/2016 11:52 AM, Honza Silhan wrote: > On Fri, Sep 2, 2016 at 5:20 PM, Tomasz Torcz wrote: >> On Fri, Sep 02, 2016 at 05:04:40PM +0200, Honza Silhan wrote: >>> >>> DNF-2 release candidate will land into rawhide. It will bring many new >>> features and bug fixes. DNF-2 is using libdnf instead of hawkey or >>> libhif. Unfortunately it brings some incompatibilities with previous >>> version which were either needed to preserve compatibility with yum >>> CLI or where bigger redesigns were needed (parsing command line >>> arguments). If you own any DNF plugin or component depending on DNF, >>> please, see the DNF-1 and DNF-2 changes [3] and adjust your package >>> accordingly. Moreover bump the DNF requirement as DNF honors semantic >>> versioning [4] to prevent future breakage when another major version >>> is deployed. To majority of components requiring >>> DNF in Fedora repository were sent patches to adapt them to DNF-2. >>> >> >> Sounds like this scope would warrant a Change? > > The components should be already prepared for DNF-2 and the changes > are not huge. There's the FESCO ticket [5]. If it is not accepted then > we will submit a Change. > Actually, the preferred approach would be for this to come to FESCo *as* a Change. Mostly because the Change Process requires you to explain the situation fully and establish a contingency plan. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 12:54 PM, Robbie Harwood wrote: > Stephen Gallagher writes: > >> On 09/02/2016 07:14 AM, Igor Gnatenko wrote: >>> >>> * Weird obsoletes (broken) >>> "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686". >>> Basically it will not obsolete anything because it's threated as >>> package name (and we definitely don't have such package name). >> >> This definitely looks odd... Robbie? > > This is part of something I was requested to add (from the RHEL > packaging where we have lines like `Obsoletes: > krb5-server-1.11.3-49.el7.i686`, added by a previous maintainer) wherein > the 64-bit versions of packages need to obsolete the 32-bit versions > because we run into problems if both are installed. > > If what's in the spec file is not the correct way to accomplish that, > what is? I am unable to find documentation for any of this. > Is that because some machines at one point did have both installed? That's kind of a mess. I'd recommend taking that discussion to packag...@lists.fedoraproject.org and see what they recommend. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 06:57 PM, Stephen Gallagher wrote: > On 09/02/2016 12:54 PM, Robbie Harwood wrote: >> Stephen Gallagher writes: >> >>> On 09/02/2016 07:14 AM, Igor Gnatenko wrote: * Weird obsoletes (broken) "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686". Basically it will not obsolete anything because it's threated as package name (and we definitely don't have such package name). >>> >>> This definitely looks odd... Robbie? >> >> This is part of something I was requested to add (from the RHEL >> packaging where we have lines like `Obsoletes: >> krb5-server-1.11.3-49.el7.i686`, added by a previous maintainer) wherein >> the 64-bit versions of packages need to obsolete the 32-bit versions >> because we run into problems if both are installed. >> >> If what's in the spec file is not the correct way to accomplish that, >> what is? I am unable to find documentation for any of this. >> > > Is that because some machines at one point did have both installed? That's > kind > of a mess. I'd recommend taking that discussion to > packag...@lists.fedoraproject.org and see what they recommend. I think the issue here is just that the syntax is wrong. Instead of what's right now, Obsoletes: krb5-server-1.11.3-49.el7.i686 it should be: Obsoletes: krb5-server <= 1.11.3-49.el7.i686 ... or something along those lines. Right now the problem is that dnf considers the whole string "krb5-server-1.11.3-49.el7.i686" to be a package name while the package name is really "krb5-server". This makes the obsoletes just plain not do anything right now since they don't match any package name. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On 09/02/2016 01:28 PM, Kalev Lember wrote: > On 09/02/2016 06:57 PM, Stephen Gallagher wrote: >> On 09/02/2016 12:54 PM, Robbie Harwood wrote: >>> Stephen Gallagher writes: >>> On 09/02/2016 07:14 AM, Igor Gnatenko wrote: > > * Weird obsoletes (broken) > "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686". > Basically it will not obsolete anything because it's threated as > package name (and we definitely don't have such package name). This definitely looks odd... Robbie? >>> >>> This is part of something I was requested to add (from the RHEL >>> packaging where we have lines like `Obsoletes: >>> krb5-server-1.11.3-49.el7.i686`, added by a previous maintainer) wherein >>> the 64-bit versions of packages need to obsolete the 32-bit versions >>> because we run into problems if both are installed. >>> >>> If what's in the spec file is not the correct way to accomplish that, >>> what is? I am unable to find documentation for any of this. >>> >> >> Is that because some machines at one point did have both installed? That's >> kind >> of a mess. I'd recommend taking that discussion to >> packag...@lists.fedoraproject.org and see what they recommend. > > I think the issue here is just that the syntax is wrong. > > Instead of what's right now, > > Obsoletes: krb5-server-1.11.3-49.el7.i686 > > it should be: > > Obsoletes: krb5-server <= 1.11.3-49.el7.i686 > > ... or something along those lines. Right now the problem is that dnf > considers the whole string "krb5-server-1.11.3-49.el7.i686" to be a > package name while the package name is really "krb5-server". This makes > the obsoletes just plain not do anything right now since they don't > match any package name. > Well, that's not all of it. It is explicitly trying to obsolete the multilib version of the package as well. I'm not sure this works for that. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
DNF-2 release candidate will land into rawhide. It will bring many new features and bug fixes. DNF-2 is using libdnf instead of hawkey or libhif. Unfortunately it brings some incompatibilities with previous version which were either needed to preserve compatibility with yum CLI or where bigger redesigns were needed (parsing command line arguments). If you own any DNF plugin or component depending on DNF, please, see the DNF-1 and DNF-2 changes [3] and adjust your package accordingly. Moreover bump the DNF requirement as DNF honors semantic versioning [4] to prevent future breakage when another major version is deployed. To majority of components requiring DNF in Fedora repository were sent patches to adapt them to DNF-2. >>> >>> Sounds like this scope would warrant a Change? >> >> The components should be already prepared for DNF-2 and the changes >> are not huge. There's the FESCO ticket [5]. If it is not accepted then >> we will submit a Change. >> > > Actually, the preferred approach would be for this to come to FESCo *as* a > Change. Mostly because the Change Process requires you to explain the > situation > fully and establish a contingency plan. Completely agree, we (rel-eng and I'm sure others) don't want to find out one day everything is broken due to this change and the compose is up the spout. Core components such as dnf need to follow the process properly and communicate far and wide so people are aware of the changes in flight that could affect everything from builds to users updating. Peter -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
firewalld transaction model
Hello, the transaction model that has been introduced with firewalld-0.4.2 makes it possible to group rules together and to apply them at once and quick. For this the restore commands of iptables, ip6tables and ebtables are used as long as they are available. At the moment the transaction model is only used inside of firewalld. It applies all the generated and provided rules in a small amount of transactions. This speeds up load and reload times of firewalld drastically. There is no external interface to add transaction by services or applications right now. Because of this I'd like to get feedback from the D-Bus interface and command line consumers: Is there interest in using transactions at all? What are the needs and wishes? With this information it should then be possible to get to a good and stable interface. This will most likely an iterative process with some test and proof of concept implementations. Please provide information about your needs and wishes. Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Friday, 02 September 2016 at 18:57, Stephen Gallagher wrote: > On 09/02/2016 12:54 PM, Robbie Harwood wrote: > > Stephen Gallagher writes: > > > >> On 09/02/2016 07:14 AM, Igor Gnatenko wrote: > >>> > >>> * Weird obsoletes (broken) > >>> "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686". > >>> Basically it will not obsolete anything because it's threated as > >>> package name (and we definitely don't have such package name). > >> > >> This definitely looks odd... Robbie? > > > > This is part of something I was requested to add (from the RHEL > > packaging where we have lines like `Obsoletes: > > krb5-server-1.11.3-49.el7.i686`, added by a previous maintainer) wherein > > the 64-bit versions of packages need to obsolete the 32-bit versions > > because we run into problems if both are installed. Why were there both versions of the krb5-server package in the repos in the first place? What problems occured? > > If what's in the spec file is not the correct way to accomplish that, > > what is? I am unable to find documentation for any of this. I'd add something like this: %ifarch x86_64 Obsoletes: krb5-server <= last version that caused issues %endif so that this doesn't end up in all arches. If I understand correctly, this affects only x86_64 due to it being multilib. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 2, 2016 at 7:28 PM, Kalev Lember wrote: > On 09/02/2016 06:57 PM, Stephen Gallagher wrote: >> On 09/02/2016 12:54 PM, Robbie Harwood wrote: >>> Stephen Gallagher writes: >>> On 09/02/2016 07:14 AM, Igor Gnatenko wrote: > > * Weird obsoletes (broken) > "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686". > Basically it will not obsolete anything because it's threated as > package name (and we definitely don't have such package name). This definitely looks odd... Robbie? >>> >>> This is part of something I was requested to add (from the RHEL >>> packaging where we have lines like `Obsoletes: >>> krb5-server-1.11.3-49.el7.i686`, added by a previous maintainer) wherein >>> the 64-bit versions of packages need to obsolete the 32-bit versions >>> because we run into problems if both are installed. >>> >>> If what's in the spec file is not the correct way to accomplish that, >>> what is? I am unable to find documentation for any of this. >>> >> >> Is that because some machines at one point did have both installed? That's >> kind >> of a mess. I'd recommend taking that discussion to >> packag...@lists.fedoraproject.org and see what they recommend. > > I think the issue here is just that the syntax is wrong. > > Instead of what's right now, > > Obsoletes: krb5-server-1.11.3-49.el7.i686 > > it should be: > > Obsoletes: krb5-server <= 1.11.3-49.el7.i686 > > ... or something along those lines. Right now the problem is that dnf > considers the whole string "krb5-server-1.11.3-49.el7.i686" to be a > package name while the package name is really "krb5-server". This makes > the obsoletes just plain not do anything right now since they don't > match any package name. DNF has nothing to do with Obsoletes. It's up to RPM how to handle it. tl;dr You can't replace i686 with x86_64 package. > > -- > Kalev > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 02, 2016 at 09:24:10PM +0200, Igor Gnatenko wrote: > DNF has nothing to do with Obsoletes. It's up to RPM how to handle it. DNF might not, but Yum did. Hence https://bugzilla.redhat.com/show_bug.cgi?id=1261034 -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
On Fri, Sep 2, 2016 at 10:34 PM, Matthew Miller wrote: > On Fri, Sep 02, 2016 at 09:24:10PM +0200, Igor Gnatenko wrote: >> DNF has nothing to do with Obsoletes. It's up to RPM how to handle it. > > DNF might not, but Yum did. Hence > https://bugzilla.redhat.com/show_bug.cgi?id=1261034 It's different problem than what we are discussing here. From all those use-cases only one doesn't work and we are working on fixing that. > > > -- > Matthew Miller > > Fedora Project Leader > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
Charalampos Stratakis wrote: > The plan for renaming python is only for rawhide, while removing the > Obsoletes/Provides might as well go in F25 as well, depending on the time > frame that maintainers will be able to fix their packages. Why can't those simple Provides just stay in forever? I really don't see the point of removing them. It only breaks things. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
review swap
I would like to swap reviews with someone if they could take a look at hyperscan: https://bugzilla.redhat.com/show_bug.cgi?id=1372866 Thanks in advance! JT -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: review swap
Il 03/09/2016 03:53, jason taylor ha scritto: I would like to swap reviews with someone if they could take a look at hyperscan: https://bugzilla.redhat.com/show_bug.cgi?id=1372866 Thanks in advance! JT -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org hi take! can you take this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1372429 for me ? thanks regards .g -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unversioned and >/=/>= obsoletes
Michael Catanzaro wrote: > Everyone OK if I retire it in rawhide now? I think if we were going to > have any issue that would cause us to switch back to udisks, it would > have manifested by now. Actually, there is this one: http://www.spinics.net/linux/fedora/fedora-kde/msg18000.html Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: review swap
On Sat, 2016-09-03 at 04:13 +0200, gil wrote: > > Il 03/09/2016 03:53, jason taylor ha scritto: > > > > I would like to swap reviews with someone if they could take a look > > at > > > > hyperscan: https://bugzilla.redhat.com/show_bug.cgi?id=1372866 > > > > Thanks in advance! > > > > JT > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproje > > ct.org > hi > take! > can you take this > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1372429 for me ? > thanks > regards > .g > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject > .org I just grabbed it, I should have it done in the next couple days. JT -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
