Re: dnf history - change in how rpmdb checksum is computed
Jeff Johnson: > This simply is not true. What is not true? Could you please include sentence you are referring to? > Whatever "rpm format" means, historically RPM itself has always gone to some > lengths not to expose E: to users to simplify the endless fog of dependency > hell clutter. Rpm does not print epoch in in standard --query output only in --info mode. $ rpm -q bind-libs bind-libs-9.9.4-61.el7.x86_64 $ rpm -qi bind-libs Name: bind-libs Epoch : 32 Version : 9.9.4 Release : 61.el7 Architecture: x86_64 ... It understands N-V-R.A or N-E:V-R.A as an argument but not E:N-V-R.A. $ rpm -q bind-libs-9.9.4-61.el7.x86_64 bind-libs-32:9.9.4-61.el7.x86_64 32:bind-libs-9.9.4-61.el7.x86_64 bind-libs-9.9.4-61.el7.x86_64 bind-libs-9.9.4-61.el7.x86_64 package 32:bind-libs-9.9.4-61.el7.x86_64 is not installed -- Michael Mráka System Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4LNMWBXTPGWDYQCE2LJIVG6QCPDUH6FL/
Re: dnf history - change in how rpmdb checksum is computed
Neal Gompa: > > Regarding these two questions: > > > >>> Are there any concerns about such change? > >>> I believe that >90% users wouldn't notice anything as it's related to the > >>> history database only. > > > >> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko > >> wrote: > >> Since we've changed the database entirely, what's the point of keeping > >> same algorithm for calculating checksum? > > > >> On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé > >> wrote: > >> What's the benefit in changing to be compatible with YUM as opposed > >> to stickin with current alogorithm ? > >> > >> Surely if we don't change it, even fewer users will notice that DNF's > >> behaviour is different from YUM's, since DNF has been the default for > >> many releases now. > >> > >> I could understand the motiviation to stay compatible with YUM if we > >> were only just about to switch Fedora from YUM to DNF, but time is > >> way in the past now. Shouldn't we optimize for the fact that DNF is > >> the more widely deployed & used tool, and thus not worry about > >> YUM compatibility in respect of the history DB ? > > > > It is true that going forward in the Fedora world it matters less. It is > > more of an impact for yum-3 compatibility as yum4/dnf is being considered > > in the RHEL7/CentOS7 userspace environments as described at > > https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/ > > > > Currently yum version 3 and what the proof-of-concept project is calling > > yum4 work very well together side by side. Users can safely switch back > > and forth. The major problem is yum/dnf histories being different and the > > rpmdb checksum difference is a blocker for resolving the history > > compatibility. > > > > So think of this as an effort to bring package management parity between > > Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead > > of them. > > > > Is there a reason why we can't change YUM to match the DNF behavior? > IMO, the YUM behavior is nonsense and isn't even a valid package > identifier. Actually E:N-V-R.A is yum-ism no one else understand while N-E:V-R.A is correct rpm format. $ rpm -q bind-libs bind-libs-9.9.4-61.el7.x86_64 $ rpm -q 32:bind-libs-9.9.4-61.el7.x86_64 package 32:bind-libs-9.9.4-61.el7.x86_64 is not installed $ rpm -q bind-libs-32:9.9.4-61.el7.x86_64 bind-libs-9.9.4-61.el7.x86_64 So if you want make world a better place stick with current dnf format. -- Michael Mráka System Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXLUGD7446XWI4TS2ITKQ2JPUAGHEF5S/
Re: Koji build failure: OverflowError: long int exceeds XML-RPC limits
Sandro Mani: > > > On 11.05.2017 16:58, Michael Mraka wrote: > >Sandro Mani: > >>Hi > >> > >>I've tried a couple of times to build mingw-qt5-qtquick1 [1], but > >>the task consistently fails after the actual build succeded [2], > >>seemingly when moving the rpms or tagging the build, with the > >>following message: > >> > >>Traceback (most recent call last): > >... > >>OverflowError: long int exceeds XML-RPC limits > >> > >>Any ideas? > >I've seen similar errors when size of (s)rpm in the build exceeded 2GB. > > > Mhh, a local build gives me: > > 1.3Mmingw32-qt5-qtquick1-5.8.0-0.2.git9bf0edd.fc27.noarch.rpm > 45M mingw32-qt5-qtquick1-debuginfo-5.8.0-0.2.git9bf0edd.fc27.noarch.rpm > 1.4Mmingw64-qt5-qtquick1-5.8.0-0.2.git9bf0edd.fc27.noarch.rpm > 44M mingw64-qt5-qtquick1-debuginfo-5.8.0-0.2.git9bf0edd.fc27.noarch.rpm That looks fine. Maybe there is any other number / size which exceeds long int? E.g. something in rpm header, size of file inside rpm (rpm -qlp mingw64-qt5-qtquick1-debuginfo-5.8.0-0.2.git9bf0edd.fc27.noarch.rpm), etc. -- Michael Mráka System Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Koji build failure: OverflowError: long int exceeds XML-RPC limits
Sandro Mani: > Hi > > I've tried a couple of times to build mingw-qt5-qtquick1 [1], but > the task consistently fails after the actual build succeded [2], > seemingly when moving the rpms or tagging the build, with the > following message: > > Traceback (most recent call last): ... > OverflowError: long int exceeds XML-RPC limits > > Any ideas? I've seen similar errors when size of (s)rpm in the build exceeded 2GB. > Thanks > Sandro -- Michael Mráka System Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: DNF package upgrade availability/discovery blocked by versionlocks
Felix Miata: > [mc-4.8.18 has been broken since release, so I locked 4.8.17] > > # grep RETT /etc/os-release > PRETTY_NAME="Fedora 26 (Twenty Six)" > # dnf versionlock list > Last metadata expiration check: 1:33:30 ago on Thu Mar 23 16:44:17 2017 EDT. > mc-1:4.8.17-2.fc25.* > # dnf list mc > Last metadata expiration check: 1:33:33 ago on Thu Mar 23 16:44:17 2017 EDT. > Installed Packages > mc.x86_64 1:4.8.17-2.fc25 @System > # dnf check-update mc > Last metadata expiration check: 1:33:35 ago on Thu Mar 23 16:44:17 2017 EDT. > # > # dnf versionlock delete mc > Last metadata expiration check: 1:41:52 ago on Thu Mar 23 16:44:17 2017 EDT. > Deleting versionlock for: mc-1:4.8.17-2.fc25.* > # dnf list mc > Last metadata expiration check: 1:41:58 ago on Thu Mar 23 16:44:17 2017 EDT. > Installed Packages > mc.x86_64 1:4.8.17-2.fc25 @System > Available Packages > mc.x86_64 1:4.8.18-4.fc26 fedora > # dnf check-update mc > Last metadata expiration check: 1:42:08 ago on Thu Mar 23 16:44:17 2017 EDT. > mc.x86_64 1:4.8.18-4.fc26 fedora > # > > How is one expected to discover via dnf when (18 day old) 4.8.19 > finally becomes available and time to delete the lock has arrived? > Is this a bug in the versionlock plugin? DNF itself? Expected > behavior? If you locked 4.8.17 then dnf ignores all other versions. That's how versionlock is supposed to work, i.e. expected behavior. If you want to ignore broken version it's better to put just this one to exclude. -- Michael Mráka System Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: debuginfo updates: RFE for dnf?
Przemek Klosowski: > Easy access to debug information is very well done in Fedora, and is > one of its most empowering features. It's very easy to trace ... > Once the debuginfo is installed, however, we have a little bit of a > stalemate, because the regular updates do not update the debuginfo > files, so the symbols and sources get out of synch with the actual > installed software. It's not a big problem---all that's required is > to enable the appropriate debuginfo repos for the update, but I > haven't found a really nice way of doing it. Currently I use > > dnf update --enablerepo *debuginfo ... > What do y'all think? Hi Przemek, Is this what you are looking for? https://dnf-plugins-core.readthedocs.io/en/latest/debuginfo-install.html Configuration /etc/dnf/plugins/debuginfo-install.conf The minimal content of conf file should contain main sections with enabled and autoupdate parameter. autoupdate A boolean option which controls updates of debuginfo packages. If options is enabled and there are debuginfo packages installed it automatically enables all configured debuginfo repositories. (Disabled by default.) Regards, -- Michael Mráka Software Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 has been released
DNF 2.0.0 and DNF-PLUGINS-CORE 1.0.0 has been released. [1] This major version update of DNF brings many user experience improvements and underlying code changes. This release has been focused on improving yum compatibility and fixes over 60 bugs. Because this release is not fully compatible with previous DNF-1 [2] it has been released only in rawhide. Authors of dnf plugins will need to check compatibility of their plugins [3]. More information in release notes [4]. [1] http://dnf.baseurl.org/2016/12/20/dnf-2-0-0-and-dnf-plugins-core-1-0-0-has-been-released/ [2] http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html [3] http://dnf.readthedocs.io/en/latest/use_cases.html#plugins-cli-api [4] http://dnf.readthedocs.io/en/latest/release_notes.html#release-notes -- Michael Mráka Software Management Engineering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: best approach for cleaning package metadata cache for old versions on upgrade?
Rex Dieter wrote: % yum includes arch/release subdirs under /var/cache/yum, the important part % is the "release" part. So, it is theoretically easy to identify which parts % are worth keeping and which ones are not (ie, does the release/ subdir match % the current release or not). ie, % $ ls -F /var/cache/yum/x86_64/ % 24/ % % PackageKit seems to follow that practice at least partially: % $ ls -F /var/cache/PackageKit/ % 24/ downloads/ metadata/ % % dnf seems to not do that, but I'd suggest adding that could help. Dnf left releasever out intentionally. See https://bugzilla.redhat.com/show_bug.cgi?id=1173107 -- Michael Mráka Software Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Dnf untagging and unpushing of updates
Brian C. Lane wrote: % % This code was in a top level module and was not marked with _ as is % the python convention for private methods. Whether or not you document % the api is immaterial. If you expose a method it is going to eventually % get used by someone. What exactly mean "top level module"? I'd consider dnf to be top level not dnf.arch. % See % https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces % for the correct way to manage exposing public methods (eg. use of % __all__ and _) Public and internal interfaces ... Documented interfaces are considered public, unless the documentation explicitly declares them to be provisional or internal interfaces exempt from the usual backwards compatibility guarantees. All *undocumented* interfaces should be assumed to be internal. % Also, it is pretty clear that this method is in use by dnf users. It % would be far better if you added arch.py with a deprecation warning % instead of insisting that all your users rewrite their code across 4 % releases. -- Michael Mráka Software Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: nothing provides /bin/python needed by mercurial-3.5-1.fc23.x86_64
Neal Becker wrote: % I'm stuck on this (again). According to advice here: % % https://lists.fedoraproject.org/pipermail/devel/2015-June/211666.html % % I just needed to use % Requires: /usr/bin/python % % But I tried changing % % Requires: python % % to % % Requires: /usr/bin/python % % and it doesn't work. Somehow I still get: % ... % Requires: /bin/python /usr/bin/env libc.so.6()(64bit) libc.so.6(GLIBC_2.14) % (64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) % libc.so.6(GLIBC_2.4)(64bit) libpthread.so.0()(64bit) % libpthread.so.0(GLIBC_2.2.5)(64bit) libpython2.7.so.1.0()(64bit) python(abi) % = 2.7 rtld(GNU_HASH) % % I don't know where this is coming from or how to fix it. Hi Neal, It looks like an autogenerated provide. I guess there's a script starting with '#!/usr/bin/env python' and /bin is before /usr/bin in your PATH. In this case either replacing '#!/usr/bin/env python' with '#!/usr/bin/python' or fixing PATH should help. Regards, -- Michael Mráka Software Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Yum-utils and DNF
Hi developers, I'm trying to finish port of yum-utils scritps to DNF and I came across couple of scripts I'm not sure whether they are just legacy stuff or someone still uses them. Do you need them? If so raise your voice and tell us your use case so we can find the best way to support it. I'm talking about: show-changed-rco, show-installed - just a different dependency list formats, anyone uses it? yum-groups-manager, verifytree - these are not client tool but rather repo group manipulation and checks so if needed at all they should be better a part of createrepo or similar package (librepo?) Thanks for your feedback, -- Michael Mráka Software Management Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Net-IPv4Addr] Created tag perl-Net-IPv4Addr-0.10-19.el7
The unsigned tag 'perl-Net-IPv4Addr-0.10-19.el7' was created. Tagger: Michael Mraka michael.mr...@redhat.com Date: Wed Sep 3 10:38:02 2014 +0200 Perl 5.20 rebuild Changes since the last tag 'perl-Net-IPv4Addr-0_10-8_fc14': Dennis Gilmore (6): - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild Fedora Release Engineering (1): dist-git conversion Jitka Plesnikova (1): Perl 5.20 rebuild Marcela Mašláňová (2): - 661697 rebuild for fixing problems with vendorach/lib Perl mass rebuild Petr Písař (2): Perl 5.16 rebuild Perl 5.18 rebuild -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
