Default LDFLAGS in build system - possible problems
Hi! I, as Fedora's vim co-maintainer, encountered the issue with default LDFLAGS. I tried to manually run configure script for Vim, with ruby support enabled, but it always failed with error message about missing ncurses (ncurses-devel was installed though). When I looked into config.log, I saw: configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux -lncurses >&5 conftest.c: In function 'main': conftest.c:67:26: warning: implicit declaration of function 'tgetent' [-Wimplicit-function-declaration] char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); ^~~ /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status Adding -fPIC actually solved it, but why does the script want it in the first place? Then I ran configure without ruby support enabled and it passed... again from config.log I found out that script wants ruby's LDFLAGS, because script needs them for compilation of ruby support and Ruby LDFLAGS are: -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic , where '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' causes the issue. I talked with Vita Ondruch, Fedora's ruby maintainer, and he explained Ruby embeds LDFLAGS from the machine, where Ruby was built - in our case in our building system, and Ruby's upstream are not willing to change this behavior. To sum it up, I would like to ask if there is way how to solve it in our build system, not in Vim or Ruby projects themselves - because at least Ubuntu does not have this issue... and python+perl seem to have it solved too. (I can patch Vim downstream in the worst scenario...) Thank you for reading the email and answers in advance! Zdenek -- 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 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
Re: Default LDFLAGS in build system - possible problems
On 28/02/2019 08:30, Zdenek Dohnal wrote: I tried to manually run configure script for Vim, with ruby support enabled, but it always failed with error message about missing ncurses (ncurses-devel was installed though). When I looked into config.log, I saw: configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux -lncurses >&5 conftest.c: In function 'main': conftest.c:67:26: warning: implicit declaration of function 'tgetent' [-Wimplicit-function-declaration] char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); ^~~ /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status Adding -fPIC actually solved it, but why does the script want it in the first place? Then I ran configure without ruby support enabled and it passed... again from config.log I found out that script wants ruby's LDFLAGS, because script needs them for compilation of ruby support and Ruby LDFLAGS are: You don't need -fPIC but you need -fPIE at least. The simple rule is that if you're going to link with Fedora's linker flags (which you are doing here) then you need to compile with Fedora's compiler flags, which would have included -fPIE if you didn't already specify -fPIE or -fPIC on the command line. So make sure you tell configure to use $RPM_OPT_FLAGS when compiling - if you use %configure and the configure script is not too silly then that should happen automatically. There is a reasonable argument here that the pkgconfig file that our ruby package installs is broken, because it embeds our linker flags without embedding our compiler flags. So "pkg-config --libs ruby" tells you to link with those flags but "pkg-config --cflags ruby" doesn't give you matching compiler flags. That said, the ruby.pc file may be assuming that it will be used for building ruby extensions, which would be .so files and hence use -fPIC anyway... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Re: doxygen crash on aarch64
Hello, On Tue, Feb 19, 2019 11:56:33 +, Ankur Sinha wrote: > On Tue, Feb 19, 2019 11:51:25 +, Ankur Sinha wrote: > > On Tue, Feb 19, 2019 11:38:15 +, Peter Robinson wrote: > > > Hi, > > > > > > > For one of my packages, doxygen is crashing on aarch64 (and not on any > > > > other arch). Any ideas/tips on how to fix this? > > > > > > Is the package name secret? More details are always good here. There's > > > generally no issues with doxygen in general on aarch64. > > > > No, it isn't "secret", it's "auryn" ;) > > Here is the spec too if you'd like to have a look. I have temporarily > disabled dev doc generation with doxygen with a conditional: > > https://src.fedoraproject.org/rpms/auryn/blob/master/f/auryn.spec#_11 > > Doxygen is used later in the spec here: > https://src.fedoraproject.org/rpms/auryn/blob/master/f/auryn.spec#_162 Any ideas anyone? -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
Donate 1 minute of your time to test upgrades from F29 to F30
Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run: sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the real upgrade. Upgrades will be fine for you. But very likely you get some dependency problem now. In that case please report it against appropriate package. Thank you Miroslav ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thursday, 28 February 2019 at 10:22, Miroslav Suchý wrote: > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync Is "dnf system-upgrade" not recommended anymore? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
Re: qt4 rebuild
On Wed, 27 Feb 2019 at 16:27, Richard Shaw wrote: > > On Wed, Feb 27, 2019 at 10:18 AM Rex Dieter wrote: >> >> Richard Shaw wrote: >> >> > So I'm pretty much out of my league at this point. I can commit the >> > Q_FOREACH patch if needed. >> >> please do commit (or at least submit pull request). > > > Pull request submitted, but it looks like pagure is having issues: > > Internal Server Error > The server encountered an internal error or misconfiguration and was unable > to complete your request. > > Please contact the server administrator at webmas...@fedoraproject.org to > inform them of the time this error occurred, and the actions you performed > just before this error. > > More information about this error may be available in the server error log. > I think you did this during a planned outage in Fedora Infrastructure. Sorry for the inconvenience and please try again. > Thanks, > Richard > ___ > 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 -- Stephen J Smoogen. ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 2/28/19 11:08, Dominik 'Rathann' Mierzejewski wrote: On Thursday, 28 February 2019 at 10:22, Miroslav Suchý wrote: Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run: sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync Is "dnf system-upgrade" not recommended anymore? It is. What Miroslav is asking is to just test dependency resolving using a custom command (not to do an actual upgrade) and file bugs. Kalev ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
W dniu 28.02.2019 o 10:22, Miroslav Suchý pisze: > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the real upgrade. > Upgrades will be fine for you. > > But very likely you get some dependency problem now. In that case please > report it against appropriate package. Worth doing 'sudo dnf update' first as some of issues could be already solved. Also check bugzilla before reporting. ___ 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
Re: Orphaned packages that will be retired
On 25/02/19 21:49, Miro Hrončok wrote: > bonzini: plexus-utils I have no idea what this is and how I became the maintainer. :) Paolo ___ 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
Re: Orphaned packages that will be retired
On 28. 02. 19 11:50, Paolo Bonzini wrote: On 25/02/19 21:49, Miro Hrončok wrote: bonzini: plexus-utils I have no idea what this is and how I became the maintainer. :) Grep the full https://churchyard.fedorapeople.org/orphans-2019-02-25.txt report for your FAS name. qemu (maintained by: ... bonzini ...) qemu-2:3.1.0-4.fc30.src requires systemtap = 4.1-0.20190207git4e76869512d2.fc30 That leads to: systemtap (maintained by: ...) systemtap-runtime-java-4.1-0.20190207git4e76869512d2.fc30.i686 requires byteman = 4.0.5-2.fc30 And that leads to: byteman (maintained by: ...) byteman-rulecheck-maven-plugin-4.0.5-2.fc30.noarch requires mvn(org.codehaus.plexus:plexus-utils) = 3.1.0 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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
Re: Default LDFLAGS in build system - possible problems
* Zdenek Dohnal: > I, as Fedora's vim co-maintainer, encountered the issue with default > LDFLAGS. > > I tried to manually run configure script for Vim, with ruby support > enabled, but it always failed with error message about missing ncurses > (ncurses-devel was installed though). When I looked into config.log, I saw: > > configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector > -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux > -lncurses >&5 > conftest.c: In function 'main': > conftest.c:67:26: warning: implicit declaration of function 'tgetent' > [-Wimplicit-function-declaration] > char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); > ^~~ > /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against > `.rodata.str1.1' can not be used when making a PIE object; recompile > with -fPIC > /usr/bin/ld: final link failed: nonrepresentable section on output > collect2: error: ld returned 1 exit status This is a bug in the configure script. It needs to pass the original CFLAGS when compiling link tests. The command is set correctly initially: | ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' So something appears to reset CFLAGS in the script. Thanks, Florian ___ 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
Re: Orphaned packages that will be retired (and everything will most likely burn)
Hi, First time here and concerned Java citizen. Who or how can I contact regarding the maven package maintenance? I want to either maintain or co-maintain it if there's someone already doing it. Regards, Ingo ___ 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
Re: Orphaned packages that will be retired (and everything will most likely burn)
Hi, I submitted a ticket to take over the maven package, https://pagure.io/releng/issue/8179. -- Ingo ___ 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
Re: Orphaned packages that will be retired
On Wed, 27 Feb 2019 at 14:35, Miro Hrončok wrote: > > > > On 27. 02. 19 15:34, Robert-André Mauchin wrote: > > On lundi 25 février 2019 21:49:32 CET you wrote: > >> The following packages are orphaned and will be retired when they > >> are orphaned for six weeks, unless someone adopts them. If you know for > >> sure > >> that the package should be retired, please do so now with a proper reason: > >> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > >> > >> Note: If you received this mail directly you (co)maintain one of the > >> affected packages or a package that depends on one. Please adopt the > >> affected package or retire your depending package to avoid broken > >> dependencies, otherwise your package will be retired when the affected > >> package gets retired. > >> > >> Full dependencies breakdown at > >> https://churchyard.fedorapeople.org/orphans-2019-02-25.txt > >> Grep it for your FAS name. > >> > >> eclipseo: google-gson > > > > That's not mine, I was never ever involved with google-gson. Is it a bug in > > the script? > > The script analyzes transitive dependencies (you will get hit by those as > well). > > To try and make this clearer: The script is looking for chains of orphans. If X is orphaned and your package currently (build)requires it.. your package will be affected when it gets dropped. Either you have to help someone take over that package, take that package over yourself, fix the package to not require it, or drop your package. [I am probably missing an option or two but those look like the major ones.] The issue is that we have a tragedy of the commons where the grazing land of deep down packages are burnt out. We either need to take better care of them or all our pasture grazing will fall apart. -- Stephen J Smoogen. ___ 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
Re: Default LDFLAGS in build system - possible problems
On 2/28/19 9:46 AM, Tom Hughes wrote: > On 28/02/2019 08:30, Zdenek Dohnal wrote: > >> I tried to manually run configure script for Vim, with ruby support >> enabled, but it always failed with error message about missing ncurses >> (ncurses-devel was installed though). When I looked into config.log, >> I saw: >> >> configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector >> -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux >> -lncurses >&5 >> conftest.c: In function 'main': >> conftest.c:67:26: warning: implicit declaration of function 'tgetent' >> [-Wimplicit-function-declaration] >> char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); >> ^~~ >> /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against >> `.rodata.str1.1' can not be used when making a PIE object; recompile >> with -fPIC >> /usr/bin/ld: final link failed: nonrepresentable section on output >> collect2: error: ld returned 1 exit status >> >> Adding -fPIC actually solved it, but why does the script want it in the >> first place? Then I ran configure without ruby support enabled and it >> passed... again from config.log I found out that script wants ruby's >> LDFLAGS, because script needs them for compilation of ruby support and >> Ruby LDFLAGS are: > > You don't need -fPIC but you need -fPIE at least. > > The simple rule is that if you're going to link with Fedora's > linker flags (which you are doing here) then you need to compile > with Fedora's compiler flags, That was it :) - configure script was using LDFLAGS embedded in ruby, but it did not use CFLAGS. Thank you for the hint! > which would have included -fPIE if > you didn't already specify -fPIE or -fPIC on the command line. > > So make sure you tell configure to use $RPM_OPT_FLAGS when > compiling - if you use %configure and the configure script is > not too silly then that should happen automatically. > > There is a reasonable argument here that the pkgconfig file > that our ruby package installs is broken, because it embeds > our linker flags without embedding our compiler flags. > > So "pkg-config --libs ruby" tells you to link with those > flags but "pkg-config --cflags ruby" doesn't give you matching > compiler flags. > > That said, the ruby.pc file may be assuming that it will be > used for building ruby extensions, which would be .so files > and hence use -fPIC anyway... > > Tom > -- 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 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
Re: Default LDFLAGS in build system - possible problems
On 2/28/19 12:04 PM, Florian Weimer wrote: > * Zdenek Dohnal: > >> I, as Fedora's vim co-maintainer, encountered the issue with default >> LDFLAGS. >> >> I tried to manually run configure script for Vim, with ruby support >> enabled, but it always failed with error message about missing ncurses >> (ncurses-devel was installed though). When I looked into config.log, I saw: >> >> configure:12069: gcc -o conftest -g -O2 -L. -Wl,-z,relro -Wl,-z,now >> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector >> -rdynamic -Wl,-export-dynamic -L/usr/local/lib conftest.c -lselinux >> -lncurses >&5 >> conftest.c: In function 'main': >> conftest.c:67:26: warning: implicit declaration of function 'tgetent' >> [-Wimplicit-function-declaration] >> char s[1]; int res = tgetent(s, "thisterminaldoesnotexist"); >> ^~~ >> /usr/bin/ld: /tmp/ccivPtT5.o: relocation R_X86_64_32 against >> `.rodata.str1.1' can not be used when making a PIE object; recompile >> with -fPIC >> /usr/bin/ld: final link failed: nonrepresentable section on output >> collect2: error: ld returned 1 exit status > This is a bug in the configure script. It needs to pass the original > CFLAGS when compiling link tests. > > The command is set correctly initially: > > | ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS > conftest.$ac_ext $LIBS >&5' > > So something appears to reset CFLAGS in the script. Actually it was like Tom wrote - Fedora specific linker flags were used, but compiler flags were not. When I added including Fedora specific compiler flags to configure script, it started to work. Now let's hope upstream will take it. Thank you for the hint too though :) . > > Thanks, > Florian > ___ > 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 -- 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 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
Miroslav Suchý wrote: > Do you want to make Fedora 30 better? Please spend 1 minute of your time > and try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the real upgrade. > Upgrades will be fine for you. > > But very likely you get some dependency problem now. In that case please > report it against appropriate package. > > Thank you > > Miroslav > ___ > 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 Error: Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be installed - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 Problem 2: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 1.57-6.fc29, but none of the providers can be installed - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade repository - problem with installed package python2-rpkg-1.57-6.fc29.noarch Problem 3: package rpmfusion-free-release-29-1.noarch requires system- release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 4: package system-config-date-1.10.9-2.fc24.noarch requires python- slip >= 0.2.21, but none of the providers can be installed - python2-slip-0.6.4-12.fc29.noarch does not belong to a distupgrade repository - problem with installed package system-config-date-1.10.9-2.fc24.noarch Problem 5: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf- lite.so.15()(64bit), but none of the providers can be installed - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 Problem 6: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 5.4.1-1.fc29, but none of the providers can be installed - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 Problem 7: package fedora-release-29-7.noarch requires fedora-repos(29) >= 1, but none of the providers can be installed - package rpmfusion-nonfree-release-29-1.noarch requires system- release(29), but none of the providers can be installed - fedora-repos-29-3.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-nonfree-release-29-1.noarch Problem 8: package python3-flake8-3.6.0-2.fc30.noarch requires python3.7dist(pycodestyle) < 2.5.0, but none of the providers can be installed - problem with installed package python3-flake8-3.5.0-6.fc29.noarch - python3-pycodestyle-2.4.0-3.fc29.noarch does not belong to a distupgrade repository - python3-flake8-3.5.0-6.fc29.noarch does not belong to a distupgrade repository Problem 9: package dbus-common-1:1.12.12-2.fc30.noarch conflicts with fedora-release < 30-0.2 provided by fedora-release-29-7.noarch - package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - problem with installed package dbus-common-1:1.12.12-1.fc29.noarch - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free- release, but none of the providers can be installed - dbus-common-1:1.12.12-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package fedy-plugins-4.0.5-1.fc22.noarch Problem 10: package dnf-yum-4.1.0-1.fc30.noarch conflicts with yum provided by yum-3.4.3-521.fc30.noarch - package yumex-3.0.17-2.fc23.noarch requires yum >= 3.2.23, but none of the providers can be installed - problem with installed package dnf-yum-4.1.0-1.fc29.noarch - yum-3.4.3-518.fc29.noarch does not belong to a distupgrade repository - dnf-yum-4.1.0-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package yumex-3.0.17-2.fc23.noarch Problem 11: package rpmfusion-free-release-29-1.noarch requires system- release(29), but none of the providers can be installed - package dbus-daemon-1:1.12.12-2.fc30.x86_64 conflicts with fedora- release < 30-0.2 provided by fedora-release-29-7.noarch - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free- release, but none of the providers can be installed - problem with installed packa
Re: Orphaned packages that will be retired
On Thu, Feb 28, 2019 at 1:00 PM Stephen John Smoogen wrote: > To try and make this clearer: The script is looking for chains of > orphans. If X is orphaned and your package currently (build)requires > it.. your package will be affected when it gets dropped. Either you > have to help someone take over that package, take that package over > yourself, fix the package to not require it, or drop your package. [I > am probably missing an option or two but those look like the major > ones.] One other solution (IMHO the best): work towards making modules available in "ursine" buildroots. plexus-utils is a modular package and I will continue to maintain it as part of modules. Making it possible to use modular packages as build dependencies will allow plexus-utils (and hundreds of other packages) to be safely retired without affecting other packages. -- Mikolaj Izdebski ___ 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
Re: doxygen crash on aarch64
On Thu, 28 Feb 2019, Ankur Sinha wrote: Hi, For one of my packages, doxygen is crashing on aarch64 (and not on any other arch). Any ideas/tips on how to fix this? Is the package name secret? More details are always good here. There's generally no issues with doxygen in general on aarch64. No, it isn't "secret", it's "auryn" ;) Here is the spec too if you'd like to have a look. I have temporarily disabled dev doc generation with doxygen with a conditional: https://src.fedoraproject.org/rpms/auryn/blob/master/f/auryn.spec#_11 Doxygen is used later in the spec here: https://src.fedoraproject.org/rpms/auryn/blob/master/f/auryn.spec#_162 Any ideas anyone? Could just be a bug in doxygen - you might just bring it up with upstream. I found a couple of those in 1.8.15 that caused one of my packages to FTBFS. Upstream was pretty responsive. Scott ___ 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
HEADS UP: dhcp will ship bunded bind libraries
All, tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring dhcp-libs-static with bundled version of libisc/libdns/etc As ISC dropped support of single thread build of BIND libraries [1] and dhcp requires one we decided to not patch dhcp/bind build scripts anymore and ship bundled bind libraries just like upstream (ISC) does it. It will allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be expected in rawhide/F31 soon! I'm aware of FPG recommendation to avoid shipping of bundled libraries due to its maintenance cost but maintaining of heavy patched build sctipts and inability to ship newer versions are even worse. I have not find any application in Fedora repository which link with libdhcp/libomapi. Please let me know if you aware of any. [1] https://ftp.isc.org/isc/bind9/9.13.3/RELEASE-NOTES-bind-9.13.3.html -- Pavel ___ 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
Re: HEADS UP: dhcp will ship bunded bind libraries
On Thu, Feb 28, 2019 at 8:58 AM Pavel Zhukov wrote: > > All, > tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring > dhcp-libs-static with bundled version of libisc/libdns/etc > > As ISC dropped support of single thread build of BIND libraries [1] and dhcp > requires one we decided to not patch dhcp/bind build scripts anymore and ship > bundled bind libraries just like upstream (ISC) does it. It will allow to > update BIND in Fedora to newest version. So dhcp 4.4.1 can be expected in > rawhide/F31 soon! > I'm aware of FPG recommendation to avoid shipping of bundled libraries due to > its maintenance cost but maintaining of heavy patched build sctipts and > inability to ship newer versions are even worse. > > I have not find any application in Fedora repository which link with > libdhcp/libomapi. Please let me know if you aware of any. > Just add the bundled() Provides if it's building with bundled copies, per the policy: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: Orphaned packages that will be retired (and everything will most likely burn)
On Thu, 28 Feb 2019 at 06:11, Ingo Hoffmann wrote: > > Hi, > > First time here and concerned Java citizen. Who or how can I contact > regarding the maven package maintenance? I want to either maintain or > co-maintain it if there's someone already doing it. > Note there are 2 different maven's. There is maven in a RPM module set which isn't going away. And then there is a non-modular maven set. You might find that the things you need are in the module set. I would also work with the rest of the java packaging team to see what they are doing and why they are doing it. One of the side effects of modules is that people need to work more together on packages to see if their needs can be better organized and grouped together. > Regards, > Ingo > ___ > 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 -- Stephen J Smoogen. ___ 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
Re: EXTERNAL: Donate 1 minute of your time to test upgrades from F29 to F30
On 2/28/19 4:23 AM, Miroslav Suchý wrote: > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the real upgrade. > Upgrades will be fine for you. > > But very likely you get some dependency problem now. In that case please > report it against appropriate package. > > Thank you > > Miroslav > ___ > 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 HTH: Error: Problem 1: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 2: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf-lite.so.15()(64bit), but none of the providers can be installed - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 Problem 3: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 5.4.1-1.fc29, but none of the providers can be installed - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 Problem 4: problem with installed package digikam-libs-5.9.0-2.fc29.x86_64 - package digikam-libs-5.9.0-2.fc29.x86_64 requires libexiv2.so.26()(64bit), but none of the providers can be installed - exiv2-libs-0.26-12.fc29.x86_64 does not belong to a distupgrade repository Problem 5: problem with installed package digikam-5.9.0-2.fc29.x86_64 - package digikam-5.9.0-2.fc29.x86_64 requires libexiv2.so.26()(64bit), but none of the providers can be installed - cannot install both exiv2-libs-0.27.0-3.fc30.x86_64 and exiv2-libs-0.26-12.fc29.x86_64 - package exiv2-0.27.0-3.fc30.x86_64 requires exiv2-libs(x86-64) = 0.27.0-3.fc30, but none of the providers can be installed - package exiv2-0.27.0-3.fc30.x86_64 requires libexiv2.so.27()(64bit), but none of the providers can be installed - problem with installed package exiv2-0.26-12.fc29.x86_64 - exiv2-0.26-12.fc29.x86_64 does not belong to a distupgrade repository Problem 6: problem with installed package digikam-doc-5.9.0-2.fc29.noarch - package digikam-doc-5.9.0-2.fc29.noarch requires digikam = 5.9.0-2.fc29, but none of the providers can be installed - package digikam-5.9.0-2.fc29.x86_64 requires libexiv2.so.26()(64bit), but none of the providers can be installed - cannot install both exiv2-libs-0.27.0-3.fc30.x86_64 and exiv2-libs-0.26-12.fc29.x86_64 - package gnome-color-manager-3.30.0-3.fc30.x86_64 requires libexiv2.so.27()(64bit), but none of the providers can be installed - problem with installed package gnome-color-manager-3.30.0-1.fc29.x86_64 - gnome-color-manager-3.30.0-1.fc29.x86_64 does not belong to a distupgrade repository -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@leidos.com ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
[root@localhost ~]# sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB 00:04 Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B 00:03 Fedora 30 - x86_64 - Test Updates67 B/s | 257 B 00:03 Fedora 30 - x86_64 - Updates 62 B/s | 257 B 00:04 Fedora 30 - x86_64 7.4 MB/s | 61 MB 00:08 Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB 00:02 Failed to synchronize cache for repo 'virtualbox' Ignoring repositories: virtualbox Error: Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be installed - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 Problem 2: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 5.4.1-1.fc29, but none of the providers can be installed - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 (try to add '--skip-broken' to skip uninstallable packages) [root@localhost ~]# On Thu, Feb 28, 2019 at 4:34 AM Neal Becker wrote: > Miroslav Suchý wrote: > > > Do you want to make Fedora 30 better? Please spend 1 minute of your time > > and try to run: > > > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > > --enablerepo=updates-testing distro-sync > > > > If you get this prompt: > > > > ... > > Total download size: XXX M > > Is this ok [y/N]: > > > > you can answer N and nothing happens, no need to test the real upgrade. > > Upgrades will be fine for you. > > > > But very likely you get some dependency problem now. In that case please > > report it against appropriate package. > > > > Thank you > > > > Miroslav > > ___ > > 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 > Error: > Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires > libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be > installed > - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade > repository > - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 > Problem 2: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = > 1.57-6.fc29, but none of the providers can be installed > - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade > repository > - problem with installed package python2-rpkg-1.57-6.fc29.noarch > Problem 3: package rpmfusion-free-release-29-1.noarch requires system- > release(29), but none of the providers can be installed > - fedora-release-29-7.noarch does not belong to a distupgrade repository > - problem with installed package rpmfusion-free-release-29-1.noarch > Problem 4: package system-config-date-1.10.9-2.fc24.noarch requires > python- > slip >= 0.2.21, but none of the providers can be installed > - python2-slip-0.6.4-12.fc29.noarch does not belong to a distupgrade > repository > - problem with installed package system-config-date-1.10.9-2.fc24.noarch > Problem 5: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf- > lite.so.15()(64bit), but none of the providers can be installed > - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade > repository > - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 > Problem 6: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls > = > 5.4.1-1.fc29, but none of the providers can be installed > - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade > repository > - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 > Problem 7: package fedora-release-29-7.noarch requires fedora-repos(29) > >= > 1, but none of the providers can be installed > - package rpmfusion-nonfree-release-29-1.noarch requires system- > release(29), but none of the providers can be installed > - fedora-repos-29-3.noarch does not belong to a distupgrade repository > - problem with installed package rpmfusion-nonfree-release-29-1.noarch > Problem 8: package python3-flake8-3.6.0-2.fc30.noarch requires > python3.7dist(pycodestyle) < 2.5.0, but none of the providers can be > installed > - problem with installed package python3-flake8-3.5.0-6.fc29.noarch > - python3-pycodestyle-2.4.0-3.fc29.noarch does not belong to a > distupgrade > repository > - python3-flake8-3.5.0-6.fc29.noarch does not belong to a distupgrade > repository > Pr
Re: Donate 1 minute of your time to test upgrades from F29 to F30
$ sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync [14:51:21] [sudo] password for iweiss: Copr repo for better_fonts owned by dawid 222 B/s | 341 B 00:01 Failed to synchronize cache for repo 'dawid-better_fonts' Docker CE Stable - x86_64 464 B/s | 577 B 00:01 Failed to synchronize cache for repo 'docker-ce-stable' Fedora 30 openh264 (From Cisco) - x86_64 183 B/s | 543 B 00:02 Fedora 30 openh264 (From Cisco) - x86_64 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0xCFC659B9: Userid : "Fedora (30) " Fingerprint: F1D8 EC98 F241 AAF2 0DF6 9420 EF3C 111F CFC6 59B9 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-30-x86_64 Is this ok [y/N]: y Fedora 30 openh264 (From Cisco) - x86_64 1.2 kB/s | 5.1 kB 00:04 Fedora Modular 30 - x86_64 534 kB/s | 2.4 MB 00:04 Fedora Modular 30 - x86_64 - Updates 63 B/s | 257 B 00:04 Fedora Modular 30 - x86_64 - Test Updates 65 B/s | 257 B 00:03 Fedora 30 - x86_64 - Test Updates 66 B/s | 257 B 00:03 Fedora 30 - x86_64 - Updates 66 B/s | 257 B 00:03 Fedora 30 - x86_64 6.2 MB/s | 61 MB 00:09 RPM Fusion for Fedora 30 - Free - Test Updates 321 kB/s | 71 kB 00:00 Failed to synchronize cache for repo 'rpmfusion-free-updates-testing' RPM Fusion for Fedora 30 - Free - Updates 56 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-free-updates' RPM Fusion for Fedora 30 - Free 63 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-free' RPM Fusion for Fedora 30 - Nonfree - Test Updates 59 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-nonfree-updates-testing' RPM Fusion for Fedora 30 - Nonfree - Updates 44 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-nonfree-updates' RPM Fusion for Fedora 30 - Nonfree 61 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-nonfree' tlp RPM packages 211 B/s | 242 B 00:01 Failed to synchronize cache for repo 'tlp-updates' tlp RPM packages 205 B/s | 234 B 00:01 Failed to synchronize cache for repo 'tlp' Ignoring repositories: dawid-better_fonts, docker-ce-stable, rpmfusion-free-updates-testing, rpmfusion-free-updates, rpmfusion-free, rpmfusion-nonfree-updates-testing, rpmfusion-nonfree-updates, rpmfusion-nonfree, tlp-updates, tlp Error: Problem 1: package chromium-libs-media-freeworld-71.0.3578.98-1.fc29.x86_64 requires chromium-libs(x86-64) = 71.0.3578.98-1.fc29, but none of the providers can be installed - chromium-libs-71.0.3578.98-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package chromium-libs-media-freeworld-71.0.3578.98-1.fc29.x86_64 Problem 2: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 3: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 5.4.1-1.fc29, but none of the providers can be installed - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 Problem 4: package fedora-release-29-7.noarch requires fedora-repos(29) >= 1, but none of the providers can be installed - package rpmfusion-nonfree-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-repos-29-3.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-nonfree-release-29-1.noarch (try to add '--skip-broken' to skip uninstallable packages) ___ 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: ht
Re: Donate 1 minute of your time to test upgrades from F29 to F30
I removed package problems that were obviously due to RPM Fusion not having branched yet... Ignoring repositories: local, hobbes1069-JS8Call, hobbes1069-NBEMS, hobbes1069-WSJT, hobbes1069-mingw, rpmfusion-free-updates, rpmfusion-free, rpmfusion-nonfree-updates, rpmfusion-nonfree, virtualbox Error: Problem 3: package python2-gdal-2.3.2-1.fc29.x86_64 requires gdal-libs(x86-64) = 2.3.2-1.fc29, but none of the providers can be installed - gdal-libs-2.3.2-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-gdal-2.3.2-1.fc29.x86_64 Problem 4: package python2-pyproj-1.9.5.1-16.fc29.x86_64 requires libproj.so.12()(64bit), but none of the providers can be installed - proj-4.9.3-6.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-pyproj-1.9.5.1-16.fc29.x86_64 Problem 5: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 1.57-6.fc29, but none of the providers can be installed - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade repository - problem with installed package python2-rpkg-1.57-6.fc29.noarch Problem 6: package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonColorPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonComputationalGeometryPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonCorePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonDataModelPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonExecutionModelPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonMathPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonMiscPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonSystemPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonTransformsPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersCorePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersGeneralPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersGeometryPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersSourcesPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersTexturePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkRenderingCorePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkRenderingFreeTypePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkRenderingLabelPython27D.so.1()(64bit), but none of the providers can be installed - python2-vtk-7.1.1-12.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-vtk-qt-7.1.1-12.fc29.x86_64 Problem 9: package blender-1:2.79b-10.fc30.x86_64 requires libboost_locale.so.1.66.0()(64bit), but none of the providers can be installed - problem with installed package blender-1:2.79b-9.fc29.x86_64 - boost-locale-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository - blender-1:2.79b-9.fc29.x86_64 does not belong to a distupgrade repository Problem 13: package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be installed - package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be installed - package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires ImageMagick-libs(x86-64) = 1:6.9.10.28-1.fc30, but none of the providers can be installed - cannot install both ImageMagick-libs-1:6.9.10.28-1.fc30.x86_64 and ImageMagick-libs-1:6.9.9.38-3.fc29.x86_64 - problem with installed package ImageMagick-1:6.9.9.38-3.fc29.x86_64 - package python3-libopenshot-0.2.2-1.fc29.x86_64 requires libMagickCore-6.Q16.so.5()(64bit), but none of the providers can be installed - package python3-libopenshot-0.2.2-1.fc29.x86_64 requires libMagickWand-6.Q16.so.5()(64bit), but none o
Planned Outage - Fedora Build Services 2019-03-01 20:00 UTC
Planned Outage - Fedora Build Services 2019-03-01 20:00 UTC There will be an outage starting at 2019-03-01 20:00 UTC, which will last approximately 4-6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2019-03-01 20:00UTC' Reason for outage: Fedora Infrastructure would like to update and reboot all QA and build systems and services. This will update kernels, glibc, and systemd plus many other services on the affected systems. Affected Services: All build and QA systems under fedoraproject.org will be affected. Friday Hosts to Update/Reboot: buildhw-01.phx2 - buildhw-02.phx2 - buildhw-03.phx2 - buildhw-04.phx2 - buildhw-05.phx2 - buildhw-06.phx2 - buildhw-07.phx2 - buildhw-08.phx2 - buildhw-09.phx2 - buildhw-10.phx2 - buildvmhost-01.phx2 - buildvmhost-02.phx2 - buildvmhost-03.phx2 - buildvmhost-04.phx2 - bvirthost01.phx2 - bvirthost04.phx2 - bvirthost05.phx2 - bvirthost08.phx2 - bvirthost12.phx2 - bvirthost13.phx2 - bvirthost14.phx2 - bvirthost15.phx2 - ppc8-01.ppc - ppc8-02.ppc - ppc8-03.ppc - ppc8-04.ppc - aarch64-c01n1.arm - aarch64-c02n1.arm - aarch64-c03n1.arm - aarch64-c04n1.arm - aarch64-c05n1.arm - aarch64-c06n1.arm - aarch64-c07n1.arm - aarch64-c08n1.arm - aarch64-c09n1.arm - aarch64-c10n1.arm - aarch64-c11n1.arm - aarch64-c12n1.arm - aarch64-c13n1.arm - aarch64-c14n1.arm - aarch64-c15n1.arm - aarch64-c16n1.arm - aarch64-c17n1.arm - aarch64-c18n1.arm - aarch64-c19n1.arm - aarch64-c20n1.arm - aarch64-c21n1.arm - aarch64-c22n1.arm - aarch64-c23n1.arm - aarch64-c24n1.arm - aarch64-c25n1.arm - buildhw-aarch64-01.arm - buildhw-aarch64-02.arm - buildhw-aarch64-03.arm - buildhw-aarch64-04.arm - buildhw-aarch64-05.arm - buildhw-aarch64-06.arm - buildhw-aarch64-07.arm - buildhw-aarch64-08.arm - buildhw-aarch64-10.arm - buildvm-s390x-01.s390 - buildvm-s390x-01.stg.s390 - buildvm-s390x-02.s390 - buildvm-s390x-03.s390 - buildvm-s390x-04.s390 - buildvm-s390x-05.s390 - buildvm-s390x-06.s390 - buildvm-s390x-07.s390 - buildvm-s390x-08.s390 - buildvm-s390x-09.s390 - buildvm-s390x-10.s390 - buildvm-s390x-11.s390 - buildvm-s390x-12.s390 - buildvm-s390x-13.s390 - buildvm-s390x-14.s390 - sign-vault03.phx2 - sign-vault04.phx2 - sign-vault05.phx2 - sign-vault06.phx2 - bkernel01.phx2 - bkernel02.phx2 - bkernel03.phx2 - bkernel04.phx2 - qa05.qa - qa07.qa - qa09.qa - qa10.qa - qa11.qa - qa12.qa - qa13.qa - qa14.qa - virthost-comm01.qa - virthost-comm03.qa - virthost-comm04.qa - aarch64-c26n1-oqa.arm - aarch64-c27n1-oqa.arm - aarch64-c28n1-oqa.arm - aarch64-c29n1-oqa.arm - aarch64-c30n1-oqa.arm - kernel01.qa - kernel02.qa - retrace01.qa - retrace02.qa - Ticket Link: https://pagure.io/fedora-infrastructure/issue/7602 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On jeudi 28 février 2019 10:22:51 CET Miroslav Suchý wrote: > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync It seems most of my problems come from the retirement of Python 2. Gofed requires Python 2 packages and I think the maintainer jchaloup is too busy elsewhere now. Error: Problem 1: problem with installed package gofed-infra-1.0.0-0.21.rc1.fc29.noarch - gofed-infra-1.0.0-0.21.rc1.fc29.noarch does not belong to a distupgrade repository - nothing provides python2.7dist(git) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(hglib) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(koji) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(python-gitdb) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(tarfile) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(urllib2) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch Problem 2: problem with installed package gofed-gofedlib-1.0.0-0.21.rc1.fc29.x86_64 - gofed-gofedlib-1.0.0-0.21.rc1.fc29.x86_64 does not belong to a distupgrade repository - nothing provides python2.7dist(jinja2) = 2.8 needed by gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 - nothing provides python2.7dist(markupsafe) = 0.23 needed by gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 Problem 3: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 1.57-6.fc29, but none of the providers can be installed - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade repository - problem with installed package python2-rpkg-1.57-6.fc29.noarch Problem 4: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 5: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf-lite.so.15()(64bit), but none of the providers can be installed - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 Problem 6: package fedora-release-29-7.noarch requires fedora-repos(29) >= 1, but none of the providers can be installed - package rpmfusion-nonfree-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-repos-29-2.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-nonfree-release-29-1.noarch Problem 7: problem with installed package gofed-1.0.0-0.21.rc1.fc29.x86_64 - package gofed-1.0.0-0.22.rc1.fc30.x86_64 requires gofed-infra = 1.0.0-0.22.rc1.fc30, but none of the providers can be installed - gofed-1.0.0-0.21.rc1.fc29.x86_64 does not belong to a distupgrade repository - nothing provides python2.7dist(git) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(hglib) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(koji) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(python-gitdb) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(tarfile) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch - nothing provides python2.7dist(urllib2) needed by gofed-infra-1.0.0-0.22.rc1.fc30.noarch Problem 8: problem with installed package gofed-resources-1.0.0-0.21.rc1.fc29.noarch - package gofed-resources-1.0.0-0.22.rc1.fc30.noarch requires gofed-gofedlib = 1.0.0-0.22.rc1.fc30, but none of the providers can be installed - gofed-resources-1.0.0-0.21.rc1.fc29.noarch does not belong to a distupgrade repository - nothing provides python2.7dist(jinja2) = 2.8 needed by gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 - nothing provides python2.7dist(markupsafe) = 0.23 needed by gofed-gofedlib-1.0.0-0.22.rc1.fc30.x86_64 Problem 9: problem with installed package pyexiv2-0.3.2-34.fc29.x86_64 - package pyexiv2-0.3.2-36.fc30.x86_64 requires libboost_python.so.1.66.0()(64bit), but none of the providers can be installed - pyexiv2-0.3.2-34.fc29.x86_64 does not belong to a distupgrade repository - boost-python2-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository Problem 10: problem with installed package nomacs-3.8.1-0.3.20180223git9b305e2.fc29.x86_64 - package nomacs-3.8.1-0.3.20180223git9b305e2.fc29.x86_64 requires libexiv2.so.26()(64bit), but none of the providers can be installed - exiv2-libs-0.26-12.fc29.x86_64 does not belong to a distupgrade repository Problem 11: cannot install both rpkg-common-1.57-6.fc30.noarch and rpkg-common-1.57-6.fc29.noarch - package python3-rpkg-1.57-6.fc30.noarch requires rpkg-common = 1.57-6.fc30, but none of the providers can be installed - package python2-r
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thu, Feb 28, 2019 at 10:24 AM Miroslav Suchý wrote: > > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync (Some are related to missing RPM Fusion). Error: Problem 1: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 2: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf-lite.so.15()(64bit), but none of the providers can be installed - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 Problem 3: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 5.4.1-1.fc29, but none of the providers can be installed - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 Problem 4: package blender-1:2.79b-10.fc30.x86_64 requires libboost_locale.so.1.66.0()(64bit), but none of the providers can be installed - problem with installed package blender-1:2.79b-9.fc29.x86_64 - boost-locale-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository - blender-1:2.79b-9.fc29.x86_64 does not belong to a distupgrade repository Problem 5: package fedora-release-29-7.noarch requires fedora-repos(29) >= 1, but none of the providers can be installed - package rpmfusion-nonfree-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-repos-29-3.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-nonfree-release-29-1.noarch Problem 6: problem with installed package freecad-1:0.17-2.fc29.x86_64 - package freecad-1:0.17-2.fc30.x86_64 requires libboost_atomic.so.1.66.0()(64bit), but none of the providers can be installed - freecad-1:0.17-2.fc29.x86_64 does not belong to a distupgrade repository - boost-atomic-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository Problem 7: package freecad-data-1:0.17-2.fc30.noarch requires freecad = 1:0.17-2.fc30, but none of the providers can be installed - problem with installed package freecad-data-1:0.17-2.fc29.noarch - package freecad-1:0.17-2.fc30.x86_64 requires libboost_chrono.so.1.66.0()(64bit), but none of the providers can be installed - freecad-data-1:0.17-2.fc29.noarch does not belong to a distupgrade repository - boost-chrono-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository Thanks, Jaroslav > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the real upgrade. > Upgrades will be fine for you. > > But very likely you get some dependency problem now. In that case please > report it against appropriate package. > > Thank you > > Miroslav > ___ > 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 -- Jaroslav Řezník Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 Red Hat, Inc. http://www.redhat.com/ ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 28. 02. 19 16:03, Richard Shaw wrote: I removed package problems that were obviously due to RPM Fusion not having branched yet... Ignoring repositories: local, hobbes1069-JS8Call, hobbes1069-NBEMS, hobbes1069-WSJT, hobbes1069-mingw, rpmfusion-free-updates, rpmfusion-free, rpmfusion-nonfree-updates, rpmfusion-nonfree, virtualbox Error: Problem 3: package python2-gdal-2.3.2-1.fc29.x86_64 requires gdal-libs(x86-64) = 2.3.2-1.fc29, but none of the providers can be installed - gdal-libs-2.3.2-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-gdal-2.3.2-1.fc29.x86_64 Problem 4: package python2-pyproj-1.9.5.1-16.fc29.x86_64 requires libproj.so.12()(64bit), but none of the providers can be installed - proj-4.9.3-6.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-pyproj-1.9.5.1-16.fc29.x86_64 Problem 5: package python2-rpkg-1.57-6.fc29.noarch requires rpkg-common = 1.57-6.fc29, but none of the providers can be installed - rpkg-common-1.57-6.fc29.noarch does not belong to a distupgrade repository - problem with installed package python2-rpkg-1.57-6.fc29.noarch Problem 6: package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonColorPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonComputationalGeometryPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonCorePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonDataModelPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonExecutionModelPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonMathPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonMiscPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonSystemPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkCommonTransformsPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersCorePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersGeneralPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersGeometryPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersSourcesPython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkFiltersTexturePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkRenderingCorePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkRenderingFreeTypePython27D.so.1()(64bit), but none of the providers can be installed - package python2-vtk-qt-7.1.1-12.fc29.x86_64 requires libvtkRenderingLabelPython27D.so.1()(64bit), but none of the providers can be installed - python2-vtk-7.1.1-12.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-vtk-qt-7.1.1-12.fc29.x86_64 Problem 9: package blender-1:2.79b-10.fc30.x86_64 requires libboost_locale.so.1.66.0()(64bit), but none of the providers can be installed - problem with installed package blender-1:2.79b-9.fc29.x86_64 - boost-locale-1.66.0-14.fc29.x86_64 does not belong to a distupgrade repository - blender-1:2.79b-9.fc29.x86_64 does not belong to a distupgrade repository Problem 13: package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be installed - package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be installed - package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires ImageMagick-libs(x86-64) = 1:6.9.10.28-1.fc30, but none of the providers can be installed - cannot install both ImageMagick-libs-1:6.9.10.28-1.fc30.x86_64 and ImageMagick-libs-1:6.9.9.38-3.fc29.x86_64 - problem with installed package ImageMagick-1:6.9.9.38-3.fc29.x86_64 - package python3-libopenshot-0.2.2-1.fc29.x86_64 requires libMagickCore-6.Q16.so.5()(64bit), but none of the p
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thu, 2019-02-28 at 06:46 -0800, Tom London wrote: > [root@localhost ~]# sudo dnf --releasever=30 > --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing > distro-sync > Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB > 00:04 > Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B > 00:03 > Fedora 30 - x86_64 - Test Updates67 B/s | 257 B > 00:03 > Fedora 30 - x86_64 - Updates 62 B/s | 257 B > 00:04 > Fedora 30 - x86_64 7.4 MB/s | 61 MB > 00:08 > Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB > 00:02 > Failed to synchronize cache for repo 'virtualbox' > Ignoring repositories: virtualbox > Error: > Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires > libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be > installed > - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade > repository > - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 https://koji.fedoraproject.org/koji/taskinfo?taskID=33105158 ought to fix this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thu, 2019-02-28 at 07:51 -0800, Adam Williamson wrote: > On Thu, 2019-02-28 at 06:46 -0800, Tom London wrote: > > [root@localhost ~]# sudo dnf --releasever=30 > > --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing > > distro-sync > > Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB > > 00:04 > > Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B > > 00:03 > > Fedora 30 - x86_64 - Test Updates67 B/s | 257 B > > 00:03 > > Fedora 30 - x86_64 - Updates 62 B/s | 257 B > > 00:04 > > Fedora 30 - x86_64 7.4 MB/s | 61 MB > > 00:08 > > Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB > > 00:02 > > Failed to synchronize cache for repo 'virtualbox' > > Ignoring repositories: virtualbox > > Error: > > Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires > > libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be > > installed > > - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade > > repository > > - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33105158 ought to fix > this. More generally, the *flood* of Python 2 dep issues here is something I was definitely concerned about with the Python 2 retirement policy explicitly deciding not to say anything about obsoleting Python 2 subpackages :( -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora 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
Re: Orphaned packages that will be retired (and everything will most likely burn)
On to, 28 helmi 2019, Stephen John Smoogen wrote: On Thu, 28 Feb 2019 at 06:11, Ingo Hoffmann wrote: Hi, First time here and concerned Java citizen. Who or how can I contact regarding the maven package maintenance? I want to either maintain or co-maintain it if there's someone already doing it. Note there are 2 different maven's. There is maven in a RPM module set which isn't going away. And then there is a non-modular maven set. You might find that the things you need are in the module set. I would also work with the rest of the java packaging team to see what they are doing and why they are doing it. One of the side effects of modules is that people need to work more together on packages to see if their needs can be better organized and grouped together. Unfortunately, this forces other packages to go to modules. For example, FreeIPA in Fedora doesn't like to be in a module but this change (removal of maven, ant, etc) forces our dependency to disappear and the only way for us is to be in a module. This doesn't sound good at all. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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
Re: Orphaned packages that will be retired (and everything will most likely burn)
On Thu, Feb 28, 2019 at 5:03 PM Alexander Bokovoy wrote: > > On to, 28 helmi 2019, Stephen John Smoogen wrote: > >On Thu, 28 Feb 2019 at 06:11, Ingo Hoffmann wrote: > >> > >> Hi, > >> > >> First time here and concerned Java citizen. Who or how can I contact > >> regarding the maven package maintenance? I want to either maintain or > >> co-maintain it if there's someone already doing it. > >> > > > >Note there are 2 different maven's. There is maven in a RPM module set > >which isn't going away. And then there is a non-modular maven set. You > >might find that the things you need are in the module set. I would > >also work with the rest of the java packaging team to see what they > >are doing and why they are doing it. > > > >One of the side effects of modules is that people need to work more > >together on packages to see if their needs can be better organized and > >grouped together. > Unfortunately, this forces other packages to go to modules. For example, > FreeIPA in Fedora doesn't like to be in a module but this change > (removal of maven, ant, etc) forces our dependency to disappear and the > only way for us is to be in a module. This doesn't sound good at all. Said differently, the above mass-orphaning is equivalent to a unannounced change ( https://fedoraproject.org/wiki/Releases/30/ChangeSet ). Note that I do not blame the original maintainer's for orphaning: I'm just stating that if modules are not accepted in buildroots the impact is worse than any unannounced, self-contained change. This is the shortcoming that should be addressed. François > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ > 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 ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 28. 02. 19 16:55, Adam Williamson wrote: On Thu, 2019-02-28 at 07:51 -0800, Adam Williamson wrote: On Thu, 2019-02-28 at 06:46 -0800, Tom London wrote: [root@localhost ~]# sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB 00:04 Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B 00:03 Fedora 30 - x86_64 - Test Updates67 B/s | 257 B 00:03 Fedora 30 - x86_64 - Updates 62 B/s | 257 B 00:04 Fedora 30 - x86_64 7.4 MB/s | 61 MB 00:08 Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB 00:02 Failed to synchronize cache for repo 'virtualbox' Ignoring repositories: virtualbox Error: Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be installed - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 https://koji.fedoraproject.org/koji/taskinfo?taskID=33105158 ought to fix this. More generally, the *flood* of Python 2 dep issues here is something I was definitely concerned about with the Python 2 retirement policy explicitly deciding not to say anything about obsoleting Python 2 subpackages :( I wanted the py3 packages to obsolte the py2, but i was outvoted. I now manually add those to fedora-obsoelte-packages, but I do it in batches. I wait for a compose now to make another batch (fora rawhide and f30). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
[root@ossus Survey2]# sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync Fedora Modular 30 - x86_64 522 kB/s | 2.4 MB 00:04 Fedora Modular 30 - x86_64 - Updates 99 B/s | 257 B 00:02 Fedora 30 - x86_64 - Test Updates 207 B/s | 257 B 00:01 Fedora 30 - x86_64 - Updates131 B/s | 257 B 00:01 Fedora 30 - x86_64 20 MB/s | 61 MB 00:03 RPM Fusion for Fedora 30 - Free - Updates52 kB/s | 71 kB 00:01 Failed to synchronize cache for repo 'rpmfusion-free-updates' RPM Fusion for Fedora 30 - Free 194 kB/s | 71 kB 00:00 Failed to synchronize cache for repo 'rpmfusion-free' RPM Fusion for Fedora 30 - Nonfree - Updates194 kB/s | 71 kB 00:00 Failed to synchronize cache for repo 'rpmfusion-nonfree-updates' RPM Fusion for Fedora 30 - Nonfree 193 kB/s | 71 kB 00:00 Failed to synchronize cache for repo 'rpmfusion-nonfree' Ignoring repositories: rpmfusion-free-updates, rpmfusion-free, rpmfusion-nonfree-updates, rpmfusion-nonfree Error: Problem 1: package libibcm-16.2-3.fc28.x86_64 requires rdma-core(x86-64) = 16.2-3.fc28, but none of the providers can be installed - rdma-core-16.2-3.fc28.x86_64 does not belong to a distupgrade repository - problem with installed package libibcm-16.2-3.fc28.x86_64 Problem 2: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-free-release-29-1.noarch Problem 3: package vlc-core-1:3.0.6-16.fc29.x86_64 requires libprotobuf-lite.so.15()(64bit), but none of the providers can be installed - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 Problem 4: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires whois-nls = 5.4.1-1.fc29, but none of the providers can be installed - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64 Problem 5: package fedora-release-29-7.noarch requires fedora-repos(29) >= 1, but none of the providers can be installed - package rpmfusion-nonfree-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-repos-29-3.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-nonfree-release-29-1.noarch Problem 6: package eclipse-cdt-2:9.6.0-5.fc30.x86_64 requires hamcrest, but none of the providers can be installed - problem with installed package eclipse-cdt-2:9.6.0-4.fc29.x86_64 - package hamcrest-1.3-25.fc30.noarch requires hamcrest-core = 1.3-25.fc30, but none of the providers can be installed - hamcrest-1.3-24.fc29.noarch does not belong to a distupgrade repository - eclipse-cdt-2:9.6.0-4.fc29.x86_64 does not belong to a distupgrade repository - package hamcrest-core-1.3-25.fc30.noarch is excluded Problem 7: package eclipse-epp-logging-2.0.7-6.fc30.noarch requires osgi(org.apache.httpcomponents.httpclient-cache), but none of the providers can be installed - problem with installed package eclipse-epp-logging-2.0.7-5.fc29.noarch - package httpcomponents-client-cache-4.5.6-3.fc30.noarch requires mvn(org.apache.httpcomponents:httpclient) = 4.5.6, but none of the providers can be installed - httpcomponents-client-cache-4.5.5-5.fc29.noarch does not belong to a distupgrade repository - eclipse-epp-logging-2.0.7-5.fc29.noarch does not belong to a distupgrade repository - package httpcomponents-client-4.5.6-3.fc30.noarch is excluded Problem 8: package eclipse-recommenders-2.5.4-3.fc30.noarch requires maven-resolver-transport-file, but none of the providers can be installed - package eclipse-recommenders-2.5.4-3.fc30.noarch requires osgi(org.apache.maven.resolver.transport.file), but none of the providers can be installed - problem with installed package eclipse-recommenders-2.5.4-2.fc29.noarch - package maven-resolver-transport-file-1:1.3.1-2.fc30.noarch requires mvn(org.apache.maven.resolver:maven-resolver-spi) = 1.3.1, but none of the providers can be installed - maven-resolver-transport-file-1:1.1.1-3.fc29.noarch does not belong to a distupgrade repository - eclipse-recommenders-2.5.4-2.fc29.noarch does not belong to a distupgrade repository - package maven-resolver-spi-1:1.3.1-2.fc30.noarch is excluded Problem 9: problem with installed package maven-resolver-transport-http-1:1.1.1-3.fc29.noarch - package maven-resolver-transport-http-1:1.3.1-2.fc30.noarch requires mvn(org.apache.maven.resolver:maven-resolver-util) = 1.3.1, but none of the providers can be installed - maven-resolver-transport-http-1:1.1.1-3.fc29.noarch does not belong to a distupgrade repository - package maven-resolve
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 2/28/19 18:05, Miro Hrončok wrote:
> On 28. 02. 19 16:55, Adam Williamson wrote:
>> More generally, the *flood* of Python 2 dep issues here is something I
>> was definitely concerned about with the Python 2 retirement policy
>> explicitly deciding not to say anything about obsoleting Python 2
>> subpackages :(
>
> I wanted the py3 packages to obsolte the py2, but i was outvoted.
I completely agree with you. I think you should have gone to FESCo and
ask them to overrule the FPC in this case.
It's difficult to obsolete subpackages correctly from
fedora-obsolete-packages when F29 keeps moving and bumping package
versions; the versioned obsoletes in fedora-obsolete-packages
don't stay current for very long like this. It would be much easier and
much more correct to do "Obsoletes: python2-blah < %{version}-%{release}"
from the same package spec file.
Kalev
___
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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 2/28/19 6:55 PM, Kalev Lember wrote: On 2/28/19 18:05, Miro Hrončok wrote: On 28. 02. 19 16:55, Adam Williamson wrote: More generally, the *flood* of Python 2 dep issues here is something I was definitely concerned about with the Python 2 retirement policy explicitly deciding not to say anything about obsoleting Python 2 subpackages :( I wanted the py3 packages to obsolte the py2, but i was outvoted. I completely agree with you. I think you should have gone to FESCo and ask them to overrule the FPC in this case. With all due respect, this would be an utter act of violence. You can not obsolete packages which are still used by other packages nor can you obsolete packages which do not functionally replace other packages. Ralf ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 2/28/19 19:15, Ralf Corsepius wrote: On 2/28/19 6:55 PM, Kalev Lember wrote: On 2/28/19 18:05, Miro Hrončok wrote: On 28. 02. 19 16:55, Adam Williamson wrote: More generally, the *flood* of Python 2 dep issues here is something I was definitely concerned about with the Python 2 retirement policy explicitly deciding not to say anything about obsoleting Python 2 subpackages :( I wanted the py3 packages to obsolte the py2, but i was outvoted. I completely agree with you. I think you should have gone to FESCo and ask them to overrule the FPC in this case. With all due respect, this would be an utter act of violence. You can not obsolete packages which are still used by other packages nor can you obsolete packages which do not functionally replace other packages. It's also not OK to not do anything and make F29 to F30 upgrades fail. Kalev ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thu, 2019-02-28 at 18:05 +0100, Miro Hrončok wrote: > On 28. 02. 19 16:55, Adam Williamson wrote: > > On Thu, 2019-02-28 at 07:51 -0800, Adam Williamson wrote: > > > On Thu, 2019-02-28 at 06:46 -0800, Tom London wrote: > > > > [root@localhost ~]# sudo dnf --releasever=30 > > > > --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing > > > > distro-sync > > > > Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB > > > > 00:04 > > > > Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B > > > > 00:03 > > > > Fedora 30 - x86_64 - Test Updates67 B/s | 257 B > > > > 00:03 > > > > Fedora 30 - x86_64 - Updates 62 B/s | 257 B > > > > 00:04 > > > > Fedora 30 - x86_64 7.4 MB/s | 61 MB > > > > 00:08 > > > > Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB > > > > 00:02 > > > > Failed to synchronize cache for repo 'virtualbox' > > > > Ignoring repositories: virtualbox > > > > Error: > > > > Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires > > > > libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be > > > > installed > > > >- libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade > > > > repository > > > >- problem with installed package python2-blockdev-2.21-1.fc29.x86_64 > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33105158 ought to fix > > > this. > > > > More generally, the *flood* of Python 2 dep issues here is something I > > was definitely concerned about with the Python 2 retirement policy > > explicitly deciding not to say anything about obsoleting Python 2 > > subpackages :( > > I wanted the py3 packages to obsolte the py2, but i was outvoted. > > I now manually add those to fedora-obsoelte-packages, but I do it in batches. > I wait for a compose now to make another batch (fora rawhide and f30). I think where the upgrade fails because the python2 package is a subpackage and has a version-specific dependency on another subpackage from the same source package, that other subpackage should obsolete it. That's what I did for blockdev: python2-blockdev requires libblockdev of the same version, so to me it makes sense for libblockdev to obsolete python2-blockdev in builds where python2-blockdev is not built: https://src.fedoraproject.org/rpms/libblockdev/c/46c87cc14b2e4783555221d49fbdff7138fb6c0f?branch=master do you see any issues with that? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thu, 2019-02-28 at 19:15 +0100, Ralf Corsepius wrote: > On 2/28/19 6:55 PM, Kalev Lember wrote: > > On 2/28/19 18:05, Miro Hrončok wrote: > > > On 28. 02. 19 16:55, Adam Williamson wrote: > > > > More generally, the *flood* of Python 2 dep issues here is something I > > > > was definitely concerned about with the Python 2 retirement policy > > > > explicitly deciding not to say anything about obsoleting Python 2 > > > > subpackages :( > > > > > > I wanted the py3 packages to obsolte the py2, but i was outvoted. > > > > I completely agree with you. I think you should have gone to FESCo and > > ask them to overrule the FPC in this case. > > With all due respect, this would be an utter act of violence. > > You can not obsolete packages which are still used by other packages nor > can you obsolete packages which do not functionally replace other packages. Sure you can. It is clearly semantically incorrect for 'foo' to *provide* 'bar' if foo does not, in fact, do whatever bar did. But it is not at all incorrect for 'foo' to *obsolete* 'bar' in this case - if 'foo' does in some sense render 'bar' obsolete. Since libblockdev dropped its python2 subpackage, the new version of libblockdev clearly *does* render python2-libblockdev 'obsolete', because the two cannot co-exist. It cannot be said to 'provide' python2-libblockdev, but it certainly *obsoletes* it. Note that *not* doing explicit obsoletes forces people upgrading their systems to do a much more "violent act" if they want the upgrade to work: either manually remove all not-properly-obsoleted packages, or use --allowerasing , which can easily cause much worse problems in many cases of packaging issues. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
Miroslav wrote: > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: # dnf --skip-broken --allowerasing -b --assumeno --releasever=30 --setopt=module_platform_id=platform:f30 distro-sync https://paste.fedoraproject.org/paste/Bxyko5K7Okrzst4k8Qn6bw Transaction Summary Install 61 Packages Upgrade3628 Packages Remove 23 Packages Downgrade34 Packages Total download size: 3.9 G Operation aborted. ___ 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
Stepping back from FESCo
Hi friends, Brian[0] made me think about my commitments and I realized that it is time to step back from my FESCo seat. Thank you for your confidence in electing me last year! Kind regards Till [0] https://www.winglemeyer.org/ramblings/2019/01/07/cookie-cleanup.html ___ 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
Re: Stepping back from FESCo
On Thu, 2019-02-28 at 20:00 +0100, Till Maas wrote: > Brian[0] made me think about my commitments and I realized that it is > time to step back from my FESCo seat. > > Thank you for your confidence in electing me last year! I am sad to hear that you are stepping down, we will miss you. It was an honor to serve with you Till! signature.asc Description: This is a digitally signed message part ___ 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
Re: Stepping back from FESCo
On Thu, Feb 28, 2019 at 2:00 PM Till Maas wrote: > Hi friends, > > Brian[0] made me think about my commitments and I realized that it is > time to step back from my FESCo seat. > > Thank you for your confidence in electing me last year! > > Kind regards > Till > > [0] https://www.winglemeyer.org/ramblings/2019/01/07/cookie-cleanup.html I am sad to hear this, but I hope you will find more time to do more cool stuff. > ___ > 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 > ___ 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
Re: Proposal: Abandon v8 package
On Wed, Feb 27, 2019 at 7:02 PM Elliott Sales de Andrade wrote: > > Let's try this again, but CC'ing the package owners. > > On 2019-02-17 9:12 p.m., Elliott Sales de Andrade wrote: > > Hi, > > > > Sorry for resurrecting a long-dead thread, but a few things happened > > recently: > > 1. v8 was just retired last week or so, > > 2. R-V8 just ported itself from v8-314 to v8 LTS 6/7. > > > > Currently, R-V8 supports both v8-314 and v8, but as the latter fixes > > several downstream package issues, it is the recommended build target. I > > expect that eventually they will stop supporting 314 as well. This leaves > > me in a bit of a pickle as it does not bundle v8 and neither I nor upstream > > have any plans to build it ourselves. > > > >> For all of these same reasons, the Node.js SIG opted to carry a bundled > >> copy of v8 in that package as well. I think we should move to have v8 > >> considered to be a copylib for all reasonable purposes within Fedora. > > > > In Debian, the nodejs package provides a stable *shared* v8 library, and > > the recommended install is against libnode-dev. Unfortunately, in Fedora, > > while nodejs-devel provides v8.h, it does *not* provide any shared library. > > > > Is this something we can also do in Fedora, i.e., split out a nodejs-libs > > subpackage, or similar? > > I've been keeping the Node.js packages in Fedora alive, but on life-support, for a couple years now. I don't have the cycles to look into a significant rework of how they're designed. If you have ideas for how to do what you're asking, I will happily review a pull request to http://src.fedoraproject.org/rpms/nodejs ___ 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
Re: Blocking criteria proposal for F30+: Printing
I just realized I only responded to Zdenek the other day. Re-sending my response now. On Tue, Feb 12, 2019 at 9:13 AM Zdenek Dohnal wrote: > > Hi, > > comments are in the text: > > On 2/11/19 9:17 PM, Stephen Gallagher wrote: > > On Mon, Feb 11, 2019 at 2:24 PM Chris Murphy > > wrote: > >> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher > >> wrote: > >>> Sorry that it's taken me so long to get back to this. > >>> > >>> I think the feedback on this has been mostly positive on the Beta > >>> criteria, but I'd like to tweak the phrasing a bit and see if this > >>> comes off more favorable: > >>> > >>> I'd like to propose that we add the following criteria to Beta for Fedora > >>> 30+: > >>> * Printing must work on at least one printer available to Fedora QA. > >>> "Work" is defined as the output from the device matching a preview > >>> shown on the GNOME print preview display. (Note that differences in > >>> color reproduction are not considered "non-working".) > >> Does the criterion pply strictly to the printing of text and line > >> art, or does it also apply to gross departures in photographs? If the > >> latter: > >> > >> ^minor differences in color reproduction are not considered "non-working"; > >> or > >> ^only major differences in color reproduction are considered "non-working" > >> > >> Major defined as any of: > >> obvious and grossly incorrect scaling (e.g. +/- 20%) > >> color inversion, torqued primaries (white becomes black, black becomes > >> white; red becomes blue, blue becomes green, etc) > >> tone reproduction that obliterates relevant identifying detail in two > >> or more test images > >> > >> With that language I'm trying to carve out only remarkable, WTF level, > >> bugs as blockers. > >> > > I think we can *probably* leave this as a thing to be decided at a > > blocker bug review. I really want to avoid trying to set a hard line > > on a topic that is inherently subjective. In general, I think we can > > just rely on the "last blocker at Go/No-Go" test for this. > I agree with Stephen - such topics can be really subjective and even the > fault does not have to be on Fedora side (f.e. when you catch the file > which goes to the printer, you look into it and it looks fine, but > output paper has 'slightly' different colors, scale etc... - so there > can be issues in the printer itself). > > > >> Next question is what applications to use for printing, since the > >> initiating application matters. What if there's a bug in just one > >> application? That shouldn't be a printing blocker (it might be a basic > >> functionality blocker for that application if it's included in default > >> installations). So I'd say pick two. Firefox and LibreOffice? Firefox > >> and evince? > >> > > How about "Desktop environment's 'test page' functionality" and > > whichever basic text editor comes with it. > > IMHO it is not correct blocker criteria for printing as itself, but it > is more like blocker for these applications. AFAIK blocker is the issue, > which can not be worked around - if the file is printable by CUPS CLI > commands 'lp'/'lpr', but not from a app, IMHO it is not blocker for > printing. > > IMO issues like 'not being able to print from X application' should be > blocking/release criteria for some common/widely used apps like > Firefox/evince/libreoffice, not for printing itself. (If the issue would > be actually connected to CUPS, I'll cooperate with them to fix the issue). > Well, we don't have to be that specific in the release criteria, honestly. We're talking about blocker criteria specifically for blocking desktops, so in my opinion it's okay to have "test page" and "basic text editor" as the stand-ins for this. (This is similar to how we have "package manager must be able to download and apply updates" as a stand-in for "the network must not be totally broken".) I'd be fine if we wanted to add a corollary that either of these are not blockers if it can be shown that other applications can print successfully. I just wanted to suggest those as the basic litmus test. > > > >> Next question, test document(s). European Color Initiative has several > >> test PDFs already prepared, perhaps the most applicable for our > >> purposes is the visual test (and a subset of it).And for font scaling > >> and reproduction, Ghent Working Group has test GWG 9.1 which tests > >> various encodings of TrueType, PostScript, and OpenType rendering. > >> Also, there's a suite of LibreOffice test files, and while I haven't > >> gone through it, I'm willing to bet there's one or two that'd serve as > >> a decent sanity tester (in any case I'm not proposing printing out > >> entire test suites): > >> https://github.com/freedesktop/libreoffice-test-files > > Chris, would you mind elaborating more on the topic of these test files > and tests from these sources? Martin (mosvald in CC) currently does only > comparing sample file and output file in ghostscript and I'm on my way > to do it the similar
Re: Donate 1 minute of your time to test upgrades from F29 to F30
No updates-testing installed on this system: $ sudo dnf --disablerepo=fedora-cisco-openh264 --skip-broken --allowerasing -b --assumeno --releasever=30 --setopt=module_platform_id=platform:f30 distro-sync ... Transaction Summary Install 82 Packages Upgrade2710 Packages Remove 15 Packages Downgrade 2 Packages Total download size: 2.3 G Operation aborted. Up to date with updates-testing on this machine: Transaction Summary Install 77 Packages Upgrade2197 Packages Remove7 Packages Downgrade12 Packages Total download size: 1.9 G Operation aborted. On Thu, Feb 28, 2019 at 1:36 PM Xose Vazquez Perez wrote: > > Miroslav wrote: > > > Do you want to make Fedora 30 better? Please spend 1 minute of your time > > and try to run: > > > # dnf --skip-broken --allowerasing -b --assumeno --releasever=30 > --setopt=module_platform_id=platform:f30 distro-sync > > https://paste.fedoraproject.org/paste/Bxyko5K7Okrzst4k8Qn6bw > > Transaction Summary > > Install 61 Packages > Upgrade3628 Packages > Remove 23 Packages > Downgrade34 Packages > > Total download size: 3.9 G > Operation aborted. > ___ > 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 -- Garry Williams ___ 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
modular repositories in mock configs: please don't
Hi everybody, Recently, modular repositories were enabled in the mock configs for fedora 29+. Now, I can't build at least one of my packages (elementary-music) in fedora 29 chroots, due to dependency issues within modules. dnf just gives up with this rather unhelpful message: Problem: cannot install the best candidate for the job - package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded I don't want or need modules installed for this package to build. See: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-901551 IMO it was a mistake to enable modular repositories in mock configs by default. Now dnf only downloads even more metadata for no benefit (or, it even breaks dependency resolution, as in this case). Do I really have to manually edit mock's config files to disable modular repos, to get builds equivalent to koji (where modules aren't available / usable either)? I want to test builds locally, before I push them to koji builders ... Any insights why this was done? Can it be fixed please? Or am I the only one having problems? Fabio ___ 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
Re: modular repositories in mock configs: please don't
On 01. 03. 19 0:05, Fabio Valentini wrote: Hi everybody, Recently, modular repositories were enabled in the mock configs for fedora 29+. Now, I can't build at least one of my packages (elementary-music) in fedora 29 chroots, due to dependency issues within modules. dnf just gives up with this rather unhelpful message: Problem: cannot install the best candidate for the job - package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded I don't want or need modules installed for this package to build. See: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-901551 IMO it was a mistake to enable modular repositories in mock configs by default. Now dnf only downloads even more metadata for no benefit (or, it even breaks dependency resolution, as in this case). Do I really have to manually edit mock's config files to disable modular repos, to get builds equivalent to koji (where modules aren't available / usable either)? I want to test builds locally, before I push them to koji builders ... Any insights why this was done? Can it be fixed please? Or am I the only one having problems? No you are not. Rawhide mock is broken for the very same reason. Mock should IMHO bring the exact same (or at least the most similar) results as building in koji. I don't want to get different packages in mock and Koji just because the configurations are different. Let's make the defaults the sme as Koji (currently, that means no modular repos). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On 28. 02. 19 19:29, Adam Williamson wrote: On Thu, 2019-02-28 at 18:05 +0100, Miro Hrončok wrote: On 28. 02. 19 16:55, Adam Williamson wrote: On Thu, 2019-02-28 at 07:51 -0800, Adam Williamson wrote: On Thu, 2019-02-28 at 06:46 -0800, Tom London wrote: [root@localhost ~]# sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync Fedora Modular 30 - x86_64 536 kB/s | 2.4 MB 00:04 Fedora Modular 30 - x86_64 - Updates 71 B/s | 257 B 00:03 Fedora 30 - x86_64 - Test Updates67 B/s | 257 B 00:03 Fedora 30 - x86_64 - Updates 62 B/s | 257 B 00:04 Fedora 30 - x86_64 7.4 MB/s | 61 MB 00:08 Fedora 30 - x86_64 - VirtualBox 3.2 kB/s | 6.9 kB 00:02 Failed to synchronize cache for repo 'virtualbox' Ignoring repositories: virtualbox Error: Problem 1: package python2-blockdev-2.21-1.fc29.x86_64 requires libblockdev(x86-64) = 2.21-1.fc29, but none of the providers can be installed - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-blockdev-2.21-1.fc29.x86_64 https://koji.fedoraproject.org/koji/taskinfo?taskID=33105158 ought to fix this. More generally, the *flood* of Python 2 dep issues here is something I was definitely concerned about with the Python 2 retirement policy explicitly deciding not to say anything about obsoleting Python 2 subpackages :( I wanted the py3 packages to obsolte the py2, but i was outvoted. I now manually add those to fedora-obsoelte-packages, but I do it in batches. I wait for a compose now to make another batch (fora rawhide and f30). I think where the upgrade fails because the python2 package is a subpackage and has a version-specific dependency on another subpackage from the same source package, that other subpackage should obsolete it. That's what I did for blockdev: python2-blockdev requires libblockdev of the same version, so to me it makes sense for libblockdev to obsolete python2-blockdev in builds where python2-blockdev is not built: https://src.fedoraproject.org/rpms/libblockdev/c/46c87cc14b2e4783555221d49fbdff7138fb6c0f?branch=master do you see any issues with that? I don't. I completely agree with this approach. According to the package guidelines, you should stick with a hardcoded version-release here. However if you update the package in previous Fedoras, you need to raise the hardcoded version. I consider that a great PITA. See the entire discussion in https://pagure.io/packaging-committee/issue/754 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
Il giorno gio, 28/02/2019 alle 10.22 +0100, Miroslav Suchý ha scritto: > But very likely you get some dependency problem now. In that case > please report it against appropriate package. This is my result: Errore: Problema 1: problem with installed package rubygem-rhc-1.38.7- 6.fc29.noarch - rubygem-rhc-1.38.7-6.fc29.noarch does not belong to a distupgrade repository - nothing provides (rubygem(commander) >= 4.0 with rubygem(commander) < 4.3.0) needed by rubygem-rhc-1.38.7- 7.fc30.noarch - nothing provides (rubygem(httpclient) >= 2.4.0 with rubygem(httpclient) < 2.7.0) needed by rubygem-rhc-1.38.7- 7.fc30.noarch Problema 2: package amule-2.3.2-16.fc29.x86_64 requires libwx_baseu-2.8.so.0()(64bit), but none of the providers can be installed - package amule-2.3.2-16.fc29.x86_64 requires libwx_baseu- 2.8.so.0(WXU_2.8)(64bit), but none of the providers can be installed - package amule-2.3.2-16.fc29.x86_64 requires libwx_baseu_net- 2.8.so.0()(64bit), but none of the providers can be installed - package amule-2.3.2-16.fc29.x86_64 requires libwx_baseu_net- 2.8.so.0(WXU_2.8)(64bit), but none of the providers can be installed - wxBase-2.8.12-31.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package amule-2.3.2- 16.fc29.x86_64 Problema 3: package amule-nogui-2.3.2-16.fc29.x86_64 requires libreadline.so.7()(64bit), but none of the providers can be installed - readline-7.0-12.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package amule-nogui- 2.3.2-16.fc29.x86_64 Problema 4: package libopenshot-0.2.2- 1.fc29.x86_64 requires libMagickCore-6.Q16.so.5()(64bit), but none of the providers can be installed - package libopenshot-0.2.2- 1.fc29.x86_64 requires libMagickWand-6.Q16.so.5()(64bit), but none of the providers can be installed - ImageMagick-libs-1:6.9.9.38- 3.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package libopenshot-0.2.2-1.fc29.x86_64 Problema 5: package python2-blockdev-2.21-1.fc29.x86_64 requires libblockdev(x86- 64) = 2.21-1.fc29, but none of the providers can be installed - libblockdev-2.21-1.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python2-blockdev-2.21- 1.fc29.x86_64 Problema 6: package rpmfusion-free-release-29-1.noarch requires system-release(29), but none of the providers can be installed - fedora-release-29-7.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion- free-release-29-1.noarch Problema 7: package vlc-core-1:3.0.6- 16.fc29.x86_64 requires libprotobuf-lite.so.15()(64bit), but none of the providers can be installed - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64 Problema 8: package fedora- release-29-7.noarch requires fedora-repos(29) >= 1, but none of the providers can be installed - package rpmfusion-nonfree-release-29- 1.noarch requires system-release(29), but none of the providers can be installed - fedora-repos-29-3.noarch does not belong to a distupgrade repository - problem with installed package rpmfusion-nonfree-release- 29-1.noarch Problema 9: package rubygem-commander-4.3.0-8.fc30.noarch requires (rubygem(highline) >= 1.6.11 with rubygem(highline) < 1.7), but none of the providers can be installed - problem with installed package rubygem-commander-4.3.0-7.fc29.noarch - rubygem-highline- 1.6.21-7.fc29.noarch does not belong to a distupgrade repository - rubygem-commander-4.3.0-7.fc29.noarch does not belong to a distupgrade repository Problema 10: package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be installed - package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be installed - package ImageMagick-1:6.9.10.28-1.fc30.x86_64 requires ImageMagick-libs(x86-64) = 1:6.9.10.28-1.fc30, but none of the providers can be installed - cannot install both ImageMagick-libs- 1:6.9.10.28-1.fc30.x86_64 and ImageMagick-libs-1:6.9.9.38- 3.fc29.x86_64 - problem with installed package ImageMagick-1:6.9.9.38- 3.fc29.x86_64 - package python3-libopenshot-0.2.2-1.fc29.x86_64 requires libMagickCore-6.Q16.so.5()(64bit), but none of the providers can be installed - package python3-libopenshot-0.2.2-1.fc29.x86_64 requires libMagickWand-6.Q16.so.5()(64bit), but none of the providers can be installed - ImageMagick-1:6.9.9.38-3.fc29.x86_64 does not belong to a distupgrade repository - problem with installed package python3-libopenshot-0.2.2-1.fc29.x86_64 Problema 11: package dnf-yum- 4.1.0-1.fc30.noarch conflicts with yum provided by yum-3.4.3- 521.fc30.noarch - problem with installed package yum-3.4.3- 518.fc29.noarch - problem with installed package dnf-yum-4.1.0- 1.fc29.noarch - yum-3.4.3-518.fc29.noarch does not belong to a distupgrade repository - dnf-y
Orphaned: sphinxbase, sphinxtrain, and cmusphinx3
I have orphaned three projects, and thus they need a new maintainer: sphinxbase, a common library for CMU Sphinx voice recognition products. sphinxtrain, Carnegie Mellon University's open source acoustic model trainer. It contains the scripts and instructions necessary for building models for the CMU Sphinx Recognizer. cmusphinx3, CMU's state-of-the-art large vocabulary speech recognition system. The latter two packages will likely need to be updated to newer upstream versions which are compatible with sphinxbase. This will involve discarding or updating a few of the patches used to build the packages. I updated sphinxbase to 5prealpha last August. Here are the outstanding bug reports related to these: https://bugzilla.redhat.com/show_bug.cgi?id=1630840, phinxtrain: Remove (sub)packages from Fedora 30+: python2-sphinxtrain https://bugzilla.redhat.com/show_bug.cgi?id=1630836, cmusphinx3: Remove (sub)packages from Fedora 30+: python2-cmusphinx3 https://bugzilla.redhat.com/show_bug.cgi?id=1676022, sphinxtrain: FTBFS in Fedora rawhide/f30 https://bugzilla.redhat.com/show_bug.cgi?id=1674747, cmusphinx3: FTBFS in Fedora rawhide/f30 https://bugzilla.redhat.com/show_bug.cgi?id=1637176, sphinxtrain not installable in F29 or Rawhide -- Mike :wq ___ 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
Re: modular repositories in mock configs: please don't
On Thu, 28 Feb 2019, Miro Hrončok wrote: > On 01. 03. 19 0:05, Fabio Valentini wrote: >> Hi everybody, >> >> Recently, modular repositories were enabled in the mock configs for fedora >> 29+. >> >> Now, I can't build at least one of my packages (elementary-music) in >> fedora 29 chroots, due to dependency issues within modules. dnf just >> gives up with this rather unhelpful message: >> >>Problem: cannot install the best candidate for the job >> - package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is >> excluded >> >> I don't want or need modules installed for this package to build. >> >> See: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-901551 >> >> IMO it was a mistake to enable modular repositories in mock configs by >> default. Now dnf only downloads even more metadata for no benefit (or, >> it even breaks dependency resolution, as in this case). >> >> Do I really have to manually edit mock's config files to disable >> modular repos, to get builds equivalent to koji (where modules aren't >> available / usable either)? I want to test builds locally, before I >> push them to koji builders ... >> >> Any insights why this was done? >> >> Can it be fixed please? >> >> Or am I the only one having problems? > > No you are not. Rawhide mock is broken for the very same reason. As is RHEL8 public beta 1. I think this is actually the bug https://bugzilla.redhat.com/show_bug.cgi?id=1673851 with 2 related rhel8 bugs https://bugzilla.redhat.com/show_bug.cgi?id=1677583 https://bugzilla.redhat.com/show_bug.cgi?id=1678911 in which case you can probably work around it by setting best=0 in the relevant file in /etc/mock (or you could take a copy of the file and edit that, then select the edited copy with the -r option of mock). Michael Young ___ 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
Re: abrt auto deleting problem dirs
Any suggestion on how to prevent abrt from deleting its own problem directories? I assume it's doing this because the package isn't signed? Feb 28 17:44:44 flap.local abrt-server[5743]: Package 'firefox' isn't signed with proper key Feb 28 17:44:44 flap.local abrt-server[5743]: 'post-create' on '/var/spool/abrt/ccpp-2019-02-28-17:44:43.780754-5103' exited with 1 Feb 28 17:44:44 flap.local abrt-server[5743]: Deleting problem directory '/var/spool/abrt/ccpp-2019-02-28-17:44:43.780754-5103' -- Chris Murphy ___ 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
Re: F30 Self-Contained Change proposal: Retire YUM 3
I have an update on the koji end. The 1.17 release will not only drop the yum dependency, it will also have full python 3 support (except for image building that uses oz / imagefactory). Unfortunately, there is only medium confidence that the 1.17 release will be ready by the F30 devel freeze on Tuesday. It depends on whether QE uncovers any issues in its final testing. If we're not able to land the release on Tuesday, what is the backup plan? On Sat, Feb 2, 2019 at 4:33 PM Dennis Gregorovic wrote: > I chatted with the Koji team and they are planning on having the yum > dependency removed in the upcoming 1.17 release and getting that release > finished before F30 code freeze. > > On Sat, Feb 2, 2019 at 3:35 PM Michal Domonkos > wrote: > >> On Mon, Jan 28, 2019 at 6:29 PM Ben Cotton wrote: >> > https://fedoraproject.org/wiki/Changes/Retire_YUM_3 >> > >> > == Summary == >> > Remove yum (v3) and all related packages from Fedora. >> >> Just a heads-up that I have updated the proposal so that it does >> *not*[2] include python2-urlgrabber, given how much it is still used >> within our infra. >> >> This should make it easier to consider the whole change proposal >> self-contained and thus more realistic towards Fedora 30. However, >> note that we still need that koji DNF port merged. >> >> [1] >> https://fedoraproject.org/wiki/Changes/Retire_YUM_3#Detailed_Description >> [2] https://fedoraproject.org/wiki/Changes/Retire_YUM_3#Dependencies >> -- >> Michal Domonkos >> Software Engineer, Software Mgmt Subsystem >> Red Hat, Inc. >> ___ >> 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 >> > > > -- > Dennis Gregorovic > Manager, PnT DevOps > Red Hat > dgre...@redhat.comT: +1-978.392.3112M: +1-617.901.9799 > -- Dennis Gregorovic Manager, PnT DevOps Red Hat dgre...@redhat.comT: +1-978.392.3112M: +1-617.901.9799 ___ 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
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Thu, Feb 28, 2019 at 8:23 PM Dennis Gregorovic wrote: > > I have an update on the koji end. The 1.17 release will not only drop the > yum dependency, it will also have full python 3 support (except for image > building that uses oz / imagefactory). Unfortunately, there is only medium > confidence that the 1.17 release will be ready by the F30 devel freeze on > Tuesday. It depends on whether QE uncovers any issues in its final testing. > If we're not able to land the release on Tuesday, what is the backup plan? > I'm not sure. Honestly, I'd rather take a snapshot of git master that's going to be Koji 1.17 in Python 3 form for F30+ so that we can iterate and get to the final release. None of the Koji components are shipped on any of the media, it's only accessed through the repositories, so there's a very low risk there. Moreover, releng redeploys post-GA for prod, so that gives us a long window to suss out issues. We could even have staging upgraded early to "kick the tires" if need be. The worst thing that could happen if 1.17.0 goes out and there's a problem is that 1.17.1 has to be issued. In the grand scheme of things, that's really not that bad. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
On Thu, Feb 28, 2019 at 5:23 PM Miroslav Suchý wrote: > > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync > > If you get this prompt: > > ... > Total download size: XXX M > Is this ok [y/N]: > > you can answer N and nothing happens, no need to test the real upgrade. > Upgrades will be fine for you. > > But very likely you get some dependency problem now. In that case please > report it against appropriate package. Tested on Fedora 28: Problem 1: problem with installed package python2-pungi-4.1.32-3.fc28.noarch - python2-pungi-4.1.32-3.fc28.noarch does not belong to a distupgrade repository - nothing provides python2.7dist(dict.sorted) needed by python2-pungi-4.1.33-2.fc30.noarch ... Problem 3: package python-cephfs-1:12.2.10-1.fc28.x86_64 requires libcephfs2 = 1:12.2.10-1.fc28, but none of the providers can be installed - libcephfs2-1:12.2.10-1.fc28.x86_64 does not belong to a distupgrade repository - problem with installed package python-cephfs-1:12.2.10-1.fc28.x86_64 Problem 4: package python-rados-1:12.2.10-1.fc28.x86_64 requires librados2 = 1:12.2.10-1.fc28, but none of the providers can be installed - librados2-1:12.2.10-1.fc28.x86_64 does not belong to a distupgrade repository - problem with installed package python-rados-1:12.2.10-1.fc28.x86_64 Problem 5: package python-rbd-1:12.2.10-1.fc28.x86_64 requires librbd1 = 1:12.2.10-1.fc28, but none of the providers can be installed - librbd1-1:12.2.10-1.fc28.x86_64 does not belong to a distupgrade repository - problem with installed package python-rbd-1:12.2.10-1.fc28.x86_64 Problem 6: package python-rgw-1:12.2.10-1.fc28.x86_64 requires librgw2 = 1:12.2.10-1.fc28, but none of the providers can be installed - librgw2-1:12.2.10-1.fc28.x86_64 does not belong to a distupgrade repository - problem with installed package python-rgw-1:12.2.10-1.fc28.x86_64 ... Problem 8: package python2-pylint-1.7.5-1.fc28.noarch requires python2-isort, but none of the providers can be installed - python2-isort-4.3.4-2.fc28.noarch does not belong to a distupgrade repository - problem with installed package python2-pylint-1.7.5-1.fc28.noarch Problem 9: package python2-rpkg-1.57-6.fc28.noarch requires rpkg-common = 1.57-6.fc28, but none of the providers can be installed - rpkg-common-1.57-6.fc28.noarch does not belong to a distupgrade repository - problem with installed package python2-rpkg-1.57-6.fc28.noarch Problem 10: package python3-PyXB-1.2.6-2.fc28.noarch requires python(abi) = 3.6, but none of the providers can be installed - python3-3.6.8-2.fc28.x86_64 does not belong to a distupgrade repository - problem with installed package python3-PyXB-1.2.6-2.fc28.noarch ... Problem 13: problem with installed package pungi-legacy-4.1.32-3.fc28.noarch - package pungi-legacy-4.1.33-2.fc30.noarch requires python2-pungi = 4.1.33-2.fc30, but none of the providers can be installed - pungi-legacy-4.1.32-3.fc28.noarch does not belong to a distupgrade repository - nothing provides python2.7dist(dict.sorted) needed by python2-pungi-4.1.33-2.fc30.noarch Problem 14: package dnf-yum-4.1.0-1.fc30.noarch conflicts with yum provided by yum-3.4.3-521.fc30.noarch - problem with installed package yum-3.4.3-517.fc28.noarch - problem with installed package dnf-yum-2.7.5-12.fc28.noarch - yum-3.4.3-517.fc28.noarch does not belong to a distupgrade repository - dnf-yum-2.7.5-12.fc28.noarch does not belong to a distupgrade repository > > Thank you > > Miroslav > ___ > 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 ___ 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
Re: Stepping back from FESCo
On Thu, Feb 28, 2019 at 08:00:06PM +0100, Till Maas wrote: > Hi friends, > > Brian[0] made me think about my commitments and I realized that it is > time to step back from my FESCo seat. Till, sad to hear this. Thank you for your FESCo work. Zbyszek ___ 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
Re: Donate 1 minute of your time to test upgrades from F29 to F30
Dne 28. 02. 19 v 18:55 Kalev Lember napsal(a):
> It's difficult to obsolete subpackages correctly from
> fedora-obsolete-packages when F29 keeps moving and bumping package
> versions; the versioned obsoletes in fedora-obsolete-packages
The rule of versioned obsolete is that the version is the last known version of
obsoleted version.
But in this case the obsoleted version is still moving so it is worth to look
*why* the obsolete should be versioned.
It is because you have package bar-2.0, which become obsolete by package
foo-1.0. So we want to obsolete only bar <
2.1-1 because some time in future somebody can resurect package bar and create
version 3.0. This is unlikely, but can
happen.
In the case of massively obsoleting python2-* packages it is *very* unlikely
that somebody will come in near future and
resurect package named python2-foo. Ergo - I do not think that in this specific
case we need to obsolete the package using:
Obsoletes: python2-blah < %{version}-%{release}
but you can use fairly big number of version instead. Like current version plus
two.
That will get you rid of the "moving target". It is very unlikely that it will
cause an issue in near future and at the
same time it will allows somebody to resurect that package in far future (which
is hard to predict).
Miroslav
___
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
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Fri, Mar 1, 2019 at 1:23 AM Dennis Gregorovic wrote: > > I have an update on the koji end. The 1.17 release will not only drop the > yum dependency, it will also have full python 3 support (except for image > building that uses oz / imagefactory). Unfortunately, there is only medium > confidence that the 1.17 release will be ready by the F30 devel freeze on > Tuesday. It depends on whether QE uncovers any issues in its final testing. > If we're not able to land the release on Tuesday, what is the backup plan? The oz 0.17 snapshot that landed yesterday has a bunch of work to support python3 but I've no idea what the state of imagefactory is. > On Sat, Feb 2, 2019 at 4:33 PM Dennis Gregorovic wrote: >> >> I chatted with the Koji team and they are planning on having the yum >> dependency removed in the upcoming 1.17 release and getting that release >> finished before F30 code freeze. >> >> On Sat, Feb 2, 2019 at 3:35 PM Michal Domonkos wrote: >>> >>> On Mon, Jan 28, 2019 at 6:29 PM Ben Cotton wrote: >>> > https://fedoraproject.org/wiki/Changes/Retire_YUM_3 >>> > >>> > == Summary == >>> > Remove yum (v3) and all related packages from Fedora. >>> >>> Just a heads-up that I have updated the proposal so that it does >>> *not*[2] include python2-urlgrabber, given how much it is still used >>> within our infra. >>> >>> This should make it easier to consider the whole change proposal >>> self-contained and thus more realistic towards Fedora 30. However, >>> note that we still need that koji DNF port merged. >>> >>> [1] https://fedoraproject.org/wiki/Changes/Retire_YUM_3#Detailed_Description >>> [2] https://fedoraproject.org/wiki/Changes/Retire_YUM_3#Dependencies >>> -- >>> Michal Domonkos >>> Software Engineer, Software Mgmt Subsystem >>> Red Hat, Inc. >>> ___ >>> 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 >> >> >> >> -- >> Dennis Gregorovic >> Manager, PnT DevOps >> Red Hat >> dgre...@redhat.comT: +1-978.392.3112M: +1-617.901.9799 > > > > -- > Dennis Gregorovic > Manager, PnT DevOps > Red Hat > dgre...@redhat.comT: +1-978.392.3112M: +1-617.901.9799 > ___ > 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 ___ 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
Re: F30 Self-Contained Change proposal: Retire YUM 3
> > I have an update on the koji end. The 1.17 release will not only drop the > > yum dependency, it will also have full python 3 support (except for image > > building that uses oz / imagefactory). Unfortunately, there is only medium > > confidence that the 1.17 release will be ready by the F30 devel freeze on > > Tuesday. It depends on whether QE uncovers any issues in its final > > testing. If we're not able to land the release on Tuesday, what is the > > backup plan? > > > > I'm not sure. Honestly, I'd rather take a snapshot of git master > that's going to be Koji 1.17 in Python 3 form for F30+ so that we can > iterate and get to the final release. Who is the royal "we" in this context? In the lead up to release both infra and rel-eng are extremely busy and generally the last thing needed is more things to do and more problems to debug. > None of the Koji components are shipped on any of the media, it's only > accessed through the repositories, so there's a very low risk there. I'm more concerned about the stability of the server side components and the extra stress put on them and the team that supports them 24*7 > Moreover, releng redeploys post-GA for prod, so that gives us a long > window to suss out issues. We could even have staging upgraded early > to "kick the tires" if need be. I think upgrading staging early is a fantastic idea. > The worst thing that could happen if 1.17.0 goes out and there's a > problem is that 1.17.1 has to be issued. In the grand scheme of > things, that's really not that bad. The problem is having the developers available to deal with the issues to make 1.17.1 with the required fixes ___ 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
Re: abrt auto deleting problem dirs
Dne 01. 03. 19 v 1:51 Chris Murphy napsal(a): > Any suggestion on how to prevent abrt from deleting its own problem > directories? I assume it's doing this because the package isn't > signed? > > Feb 28 17:44:44 flap.local abrt-server[5743]: Package 'firefox' isn't > signed with proper key > Feb 28 17:44:44 flap.local abrt-server[5743]: 'post-create' on > '/var/spool/abrt/ccpp-2019-02-28-17:44:43.780754-5103' exited with 1 > Feb 28 17:44:44 flap.local abrt-server[5743]: Deleting problem > directory '/var/spool/abrt/ccpp-2019-02-28-17:44:43.780754-5103' This might help: https://abrt.github.io/faf/container/openshift/ureport/unpackaged/2017/11/01/report-unpackaged-problems/ Miroslav ___ 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
