Re: packages provides Re: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)
On Fri, Mar 8, 2019 at 8:20 PM Sérgio Basto wrote:
>
> Hello,
>
> :P I just found a weird bug :
>
> dnf repoquery --available --whatrequires python2-mlt
> flowblade-0:1.16.0-2.gitd2f153f.fc28.noarch
> flowblade-0:2.0-1.fc28.noarch
>
> dnf repoquery --disablerepo='*' --enablerepo=rawhide
> --enablerepo=rpmfusion-{,non}free-rawhide --available --requires flowblade
> (...)
> mlt-python
> (...)
>
> dnf repoquery --disablerepo='*' --enablerepo=rawhide
> --enablerepo=rpmfusion-{,non}free-rawhide --available --whatrequires
> python2-mlt
>
> None !!! ???
I do get flowblade, the only difference is that I don't use the
rpmfusion nonfree repository.
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rpmfusion-free-rawhide --available --whatrequires
python2-mlt
Last metadata expiration check: 0:02:03 ago on Sat 09 Mar 2019 08:12:08 AM CET.
flowblade-0:2.0-2.fc30.noarch
Dridi
___
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: Fedora rawhide compose report: 20190306.n.1 changes
On 3/8/19 5:11 PM, Miro Hrončok wrote: > On 08. 03. 19 18:39, Miro Hrončok wrote: >> On 08. 03. 19 18:26, Kevin Fenzi wrote: >>> On 3/7/19 12:30 PM, Miro Hrončok wrote: On 07. 03. 19 21:19, Kevin Fenzi wrote: > On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: >> On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report >> wrote: >>> >>> OLD: Fedora-Rawhide-20190217.n.0 >>> NEW: Fedora-Rawhide-20190306.n.1 >>> >>> = SUMMARY = >>> Added images: 13 >>> Dropped images: 7 >>> Added packages: 128 >>> Dropped packages: 174 >>> Upgraded packages: 1745 >>> Downgraded packages: 165 >> >> Looks like it is second or third time when after report about release >> some batch of the packages nothing hit the ground/public repos. >> My understanding is that it is some glitch in release infrastructure. >> May we know what is the current situation? > > What ground/public repos do you mean here? The master mirror is > definitely updated. It's a large pile of changes, so other mirrors may > take a bit longer than normal to sync. > > There's no glitch I am aware of, so more information would be helpful. This seems quite OK: https://admin.fedoraproject.org/mirrormanager/propgation Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 >>> >>> Well, perhaps you looked at it too soon? >>> >>> Right now it's slowly showing mirrors catching up over the last 12 hours >>> or so. >> >> Perhaps. I see the progress now, thanks! > > I also wonder if no new composes even starting is a deliberate choice or > some kind of error: > > https://kojipkgs.fedoraproject.org/compose/rawhide/ The rawhide compose is in a cron job, set to fire at 5:15UTC. However, if there's already one running it will just exit and not launch a new one. Yesterday at that time the completed one wasn't finished, so the cron didn't start a new one. The rawhide compose job at the end cleans up old composes older than 2 weeks, and last nights was the first one to finish in a long time, so it had a lot of old composes to clean up. We should probably move that cleanup to a separate job, but we haven't yet. kevin 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: Koji Build Failure Due To Dependency EPEL Dependency Issue
On 3/8/19 6:01 PM, Chris wrote: > Hi guys, > > I apologize if this is a bit premature to revisit this subject. The thing > is, the releng ticket Stephen created (https://pagure.io/releng/issue/8185) > based on my Bugzilla ticket ( > https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed and marked > resolved, but the build process still continues to fail. > > Recent Koji Build Fail Source: > https://koji.fedoraproject.org/koji/taskinfo?taskID=33310604 > > I sat on this for a week thinking maybe it just took time for this change > to propagate, but now that this was week #2 and it was still failing... i > should bother you all again :). > > Is this a RedHat issue? Perhaps just waiting for the Bugzilla issue to > close will actually rectify my issue? i realize this can take months; but > it's a perfectly acceptable answer. I guess i'm just looking for closure > at this point. I'd love to share my app with the rest of the fedora > community. > > Thanks in advance! Sorry this has been a pain. ;( Anyhow, it did get blocked but there was still a version of the package tagged into epel7 so that was messing things up. I untagged that one and (I hope you don't mind) resubmitted your scratch build... and now it completes. :) So, you should be all good now I hope. kevin 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: What pulls in weak dependencies?
Vít Ondruch wrote on 2019/03/09 8:03: Hi, Running `dnf update`, it tries to install: Installing weak dependencies: mkpasswd x86_64 5.4.1-3.fc31 rawhide 39 k Trying to query for weak dependencies, nothing requires it: $ sudo dnf repoquery --whatrecommends mkpasswd Last metadata expiration check: 0:07:13 ago on Fri Mar 8 23:51:51 2019. $ sudo dnf repoquery --supplements mkpasswd Last metadata expiration check: 0:07:53 ago on Fri Mar 8 23:51:51 2019. So I wonder how I am supposed to know, why DNF is trying to install such packages. $ dnf repoquery --disablerepo=\* --enablerepo=koji-31 --provides mkpasswd 2>/dev/null | while read f ; do echo -n -e "$f\t" ; dnf repoquery --disablerepo=\* --enablerepo=koji-31 --whatrecommends "$f" 2>/dev/null ; echo ; done mkpasswd = 5.4.1-3.fc31 mkpasswd(x86-64) = 5.4.1-3.fc31 whois-mkpasswd = 5.4.1-3.fc31 libxcrypt-0:4.4.4-1.fc31.x86_64 So libxcrypt-0:4.4.4-1.fc31.x86_64 Recommends whois-mkpasswd , which is provided by mkpasswd . Regards, Mamoru ___ 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: Koji Build Failure Due To Dependency EPEL Dependency Issue
Hi guys, I apologize if this is a bit premature to revisit this subject. The thing is, the releng ticket Stephen created (https://pagure.io/releng/issue/8185) based on my Bugzilla ticket ( https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed and marked resolved, but the build process still continues to fail. Recent Koji Build Fail Source: https://koji.fedoraproject.org/koji/taskinfo?taskID=33310604 I sat on this for a week thinking maybe it just took time for this change to propagate, but now that this was week #2 and it was still failing... i should bother you all again :). Is this a RedHat issue? Perhaps just waiting for the Bugzilla issue to close will actually rectify my issue? i realize this can take months; but it's a perfectly acceptable answer. I guess i'm just looking for closure at this point. I'd love to share my app with the rest of the fedora community. Thanks in advance! Chris On Sat, Mar 2, 2019 at 4:46 PM Stephen John Smoogen wrote: > I have created https://pagure.io/releng/issue/8185 for the releng > ticket and referenced the bugzilla. > > On Sat, 2 Mar 2019 at 16:23, Chris wrote: > > > > > Can you file a releng ticket to retire the epel7 one? > > > Thats what needs to happen here. > > > > Thank you (and everyone else) very much for your fast responses and > help! I created https://bugzilla.redhat.com/show_bug.cgi?id=1684830 > which hopefully covers what was requested of me. :) > > > > Chris > > > > > > On Sat, Mar 2, 2019 at 3:00 PM Kevin Fenzi wrote: > >> > >> On 3/2/19 10:22 AM, Chris wrote: > >> > Hi everyone, > >> > > >> > I just wanted to see if anyone had any idea why the EPEL7 repository > would > >> > not identify python2-oauthlib package correctly? It almost appears as > >> > though the EPEL repository is broken (has been for at least a week - > maybe > >> > longer) 'with respect to the this package specifically'. > >> > > >> > Here is a failed koji build: > >> > https://koji.fedoraproject.org/koji/taskinfo?taskID=33139296 > >> > > >> > If i build using COPR (link: > >> > https://copr.fedorainfracloud.org/coprs/build/861900/) everything > works > >> > fantastic; so it's very specific to how the EPEL7 repositories are > sourced > >> > via Koji. > >> > > >> > The Koji error i get is: > >> > > >> > DEBUG util.py:490: BUILDSTDERR: No matching package to install: > >> > 'python2-oauthlib' > >> > DEBUG util.py:490: BUILDSTDERR: Not all dependencies satisfied > >> > DEBUG util.py:490: BUILDSTDERR: Error: Some packages could not be > found. > >> > > >> > > >> > Fedora and RedHat based repositories seem unaffected and correctly > identify > >> > python2-oauthlib and python3-oauthlib in their respected repositories. > >> > > >> > Any thoughts or advice? > >> > >> This is because python-oauthlib is in both epel7 and rhel7 base repo. > >> > >> Koji operates on source packages, so when both epel7 and rhel7 have the > >> same package name, epel7 wins. The epel7 python-oauthlib package does > >> not provide a python2-oauthlib subpackage (it only has python-ouathlib). > >> Because it's using the epel7 one, it ignores everything the rhel7 one > >> creates, so you don't get the python2-oauthlib from there either. > >> > >> In Copr the newest package wins, so you get the rhel7 one because it's > >> much newer than the old epel7 one. > >> > >> Can you file a releng ticket to retire the epel7 one? > >> Thats what needs to happen here. > >> > >> kevin > >> > >> ___ > >> 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 > > > > -- > 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 > ___ 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
Re: Fedora rawhide compose report: 20190306.n.1 changes
On 08. 03. 19 18:39, Miro Hrončok wrote: On 08. 03. 19 18:26, Kevin Fenzi wrote: On 3/7/19 12:30 PM, Miro Hrončok wrote: On 07. 03. 19 21:19, Kevin Fenzi wrote: On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report wrote: OLD: Fedora-Rawhide-20190217.n.0 NEW: Fedora-Rawhide-20190306.n.1 = SUMMARY = Added images: 13 Dropped images: 7 Added packages: 128 Dropped packages: 174 Upgraded packages: 1745 Downgraded packages: 165 Looks like it is second or third time when after report about release some batch of the packages nothing hit the ground/public repos. My understanding is that it is some glitch in release infrastructure. May we know what is the current situation? What ground/public repos do you mean here? The master mirror is definitely updated. It's a large pile of changes, so other mirrors may take a bit longer than normal to sync. There's no glitch I am aware of, so more information would be helpful. This seems quite OK: https://admin.fedoraproject.org/mirrormanager/propgation Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 Well, perhaps you looked at it too soon? Right now it's slowly showing mirrors catching up over the last 12 hours or so. Perhaps. I see the progress now, thanks! I also wonder if no new composes even starting is a deliberate choice or some kind of error: https://kojipkgs.fedoraproject.org/compose/rawhide/ -- 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: Allowing Epoch to be reset between releases
> "MH" == Miro Hrončok writes: MH> One thing to consider here is other packages that have Requires MH> etc. on something like "foo > 1:1.2", so if it is automated, this MH> part needs to be automated as well. Indeed. And of course this breaks any such dependency outside of Fedora as well. (Either in COPR repositories, RPMFusion, or local packages.) I should have mentioned this as a potential downside, since it was part of previous discussions. MH> If we do this, we might have a "flag day" but not automated for all MH> 756 packages, but opt in. Sure, maybe at first. Stage it in over a couple of releases if necessary, or having a couple of flag days. Though it's not quite as many if you exclude the Epoch: 0 ones. (Though I recall that there is some subtlety between Epoch: 0 and no epoch at all.) But that's an implementation detail; the fundamental question is whether there is any general support for dropping epochs, and more specifically if FESCo would accept it on principle. And I can understand why they may not, because while epochs are annoying, we've certainly been living with them for quite some time. MH> Aka we create a window on rawhide, and packagers would sign up for MH> this, we announce the window, let them do it, and we close the MH> window... ? The issue is that if a compose happens while the window is open, we have more than one rawhide update where distro-sync is needed. I think it's worth spending a bit of effort to minimize the issues for those running rawhide. MH> However I'm not sure it's worth the effort. Yes, that's basically the problem. History has shown that we can live with epochs. But even if it's a limited effort, it would be nice to give packagers who want to get rid of epochs a way to do so. - J< ___ 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: Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
On 08. 03. 19 23:19, Jason L Tibbitts III wrote: "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... MH> Let's do a Fedora change? Coordinate with FPC? We (FPC) have talked about this before but I don't think it's really up to FPC. The change process isn't really the right way to do it, either, since this is really a policy revision. I just think FESCo needs to decide whether or not it would like to relax the policy, and if so, how. Here are the relevant points as I see them (unless I'm forgetting something): * dnf system-upgrade generally handles versions going backward without issue. The specific case of epoch being reset is not an issue. * dnf upgrade would not handle this, causing problems for those running rawhide or using unsupported methods of upgrading between releases. * Those running rawhide would have to run distro-sync in order to upgrade (which would of course reset any locally built updated packages and such). They would have to do this every time any installed package drops epoch. * Those using an unsupported method of upgrading would need to incorporate distro-sync. * Dropping epoch outside of rawhide would generally be bad. * Koji and the compose process do handle things "going backwards", as this has happened multiple times in the past without things dying. What's important there is which version was most recently tagged. * Bodhi shouldn't be involved here as this would be restricted to rawhide. Personally I'm in support of relaxing the restriction in some form, but I prefer a single "drop Epoch: day" where epochs in rawhide are _automatically_ removed and the packages rebuilt. This gives a single point in time where rawhide users need to do a distro-sync in order to properly track updates. Allowing epochs to be dropped without coordination seems to me to be a burden on rawhide users, but I don't think a single flag day would be problematic. I would expect the first flag day to be busy. I see 756 Epoch: tags currently, though 161 are set to 0 for whatever reason. Afterwards I would expect no more than a small number of packages per cycle to acquire Epoch: tags. One thing to consider here is other packages that have Requires etc. on something like "foo > 1:1.2", so if it is automated, this part needs to be automated as well. If we do this, we might have a "flag day" but not automated for all 756 packages, but opt in. Aka we create a window on rawhide, and packagers would sign up for this, we announce the window, let them do it, and we close the window... ? This needs a lot of consideration for sure, but I think it can be done somehow. However I'm not sure it's worth the effort. -- 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
What pulls in weak dependencies?
Hi, Running `dnf update`, it tries to install: ~~~ ... snip ... Installing weak dependencies: mkpasswd x86_64 5.4.1-3.fc31 rawhide 39 k ... snip ... ~~~ Trying to query for weak dependencies, nothing requires it: ~~~ $ sudo dnf repoquery --whatrecommends mkpasswd Last metadata expiration check: 0:07:13 ago on Fri Mar 8 23:51:51 2019. $ sudo dnf repoquery --supplements mkpasswd Last metadata expiration check: 0:07:53 ago on Fri Mar 8 23:51:51 2019. ~~~ So I wonder how I am supposed to know, why DNF is trying to install such packages. Vít ___ 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
Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
> "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: >> I really wish we'd allow Epochs to be reset on distribution upgrades. >> With dnf distro-sync (which is used by system-upgrade) Epochs don't >> really matter and upgrades work as intended anyway... MH> Let's do a Fedora change? Coordinate with FPC? We (FPC) have talked about this before but I don't think it's really up to FPC. The change process isn't really the right way to do it, either, since this is really a policy revision. I just think FESCo needs to decide whether or not it would like to relax the policy, and if so, how. Here are the relevant points as I see them (unless I'm forgetting something): * dnf system-upgrade generally handles versions going backward without issue. The specific case of epoch being reset is not an issue. * dnf upgrade would not handle this, causing problems for those running rawhide or using unsupported methods of upgrading between releases. * Those running rawhide would have to run distro-sync in order to upgrade (which would of course reset any locally built updated packages and such). They would have to do this every time any installed package drops epoch. * Those using an unsupported method of upgrading would need to incorporate distro-sync. * Dropping epoch outside of rawhide would generally be bad. * Koji and the compose process do handle things "going backwards", as this has happened multiple times in the past without things dying. What's important there is which version was most recently tagged. * Bodhi shouldn't be involved here as this would be restricted to rawhide. Personally I'm in support of relaxing the restriction in some form, but I prefer a single "drop Epoch: day" where epochs in rawhide are _automatically_ removed and the packages rebuilt. This gives a single point in time where rawhide users need to do a distro-sync in order to properly track updates. Allowing epochs to be dropped without coordination seems to me to be a burden on rawhide users, but I don't think a single flag day would be problematic. I would expect the first flag day to be busy. I see 756 Epoch: tags currently, though 161 are set to 0 for whatever reason. Afterwards I would expect no more than a small number of packages per cycle to acquire Epoch: tags. - J< ___ 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: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, 2019-03-08 at 15:07 -0500, Kaleb Keithley wrote: > The epoch was inadvertently bumped (not by me) when ceph was rebased to > 14.x in f30/rawhide. > > I reset it to 1 in subsequent builds. Now adamwill is running builds with > it bumped to 2 again. > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > even I think) where they have epoch=2. I see this as a feature that lets > someone install Ceph's epoch=2 packages on a system and not risk > inadvertently updating with the Fedora Ceph packages. > > Is there really no other way to get rid of the one or two "bad builds" > where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds > perhaps? I did send you an email about this to explain. The builds with epoch 2 made multiple Rawhide composes and the first Fedora 30 compose. This means anyone who installed 30 or Rawhide with ceph packages during those periods will never get ceph updated when they do 'dnf update', because they will have a package installed with epoch 2 and dnf will not see the package with epoch 1 as an update. Untagging the builds does not help anyone who got them installed while they were in Rawhide or Fedora 30 (in fact Fedora 30 still contains an epoch 2 build right now, so anyone installing it at present is getting epoch-2 ceph). We can talk about potentially allowing epoch down bumps at a distro upgrade boundary (though this rather hangs Rawhide users out to dry), but even if we were to start allowing that, since an epoch 2 build made it into a Fedora 30 compose, we can never bump the epoch down to 1 for Fedora 30's lifetime. -- 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: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On 08. 03. 19 21:16, Neal Gompa wrote: On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote: The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x in f30/rawhide. I reset it to 1 in subsequent builds. Now adamwill is running builds with it bumped to 2 again. I would prefer that it not be bumped. Ceph has their own builds (for Fedora even I think) where they have epoch=2. I see this as a feature that lets someone install Ceph's epoch=2 packages on a system and not risk inadvertently updating with the Fedora Ceph packages. Is there really no other way to get rid of the one or two "bad builds" where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? As of right now, no. Once it goes out in a compose, that's the way it goes... I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... Let's do a Fedora change? Coordinate with FPC? -- 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: Fedora 30 Beta blocker status mail #3
On Fri, Mar 8, 2019 at 1:38 PM Chris Murphy wrote: > > On Fri, Mar 8, 2019 at 12:56 PM wrote: > > > > On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson > > wrote: > > > I requested testing on desktop@ and test@ lists earlier this week; so > > > far that seems to suggest that this is failing for a lot of people on > > > a > > > lot of hardware...but it also fails the same way on F29 in most cases, > > > suggesting we shipped F29 broken as well. I don't think we've yet had > > > feedback from a system where nomodeset is actually *needed*, which > > > would be interesting. > > > > Please also consider that the target audience for Fedora Workstation is > > not going to know about nomodeset or how to modify the kernel command > > line. So unless we have some specific release criterion referencing > > nomodeset, I'm not sure why it would be a blocker. > > The installation media, netinstaller and Live, on both UEFI and BIOS, > contains a boot menu with a Troubleshooting submenu, which contains a > boot entry to boot using Basic Video, and that in turn has the > nomodeset parameter already set. I'd say in order of preference: 1. Basic video menu entry should work 2. If basic video menu entry is chosen, but can't work, it should fail better than it does now. Even if some things were to crash, just to break out of the black screen and get the user to a prompt, is better than the current behavior. 3. Basic video menu entry should be removed 2 and 3 might seem reversed, and maybe they are, but I'm cutting us some slack to offer a chance of booting with basic video as a fallback option. But yeah, if the fallback option -- 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: Builders with different Mock version and different results
On 3/8/19 12:47 PM, Vít Ondruch wrote: > > Dne 08. 03. 19 v 21:27 Kevin Fenzi napsal(a): >> On 3/8/19 12:19 PM, Vít Ondruch wrote: >>> I wonder why different builders has different version of mock and why >>> the build result differs? >>> >>> The scratch build passes: >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459 >>> >>> While the official fails: >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270 >> All the armv7 builders are stuck on f27 due to >> https://bugzilla.redhat.com/show_bug.cgi?id=1576593 >> (newer kernels cause some builds to pause the builder or crash the builds). >> >> I don't think mock version has anything do to with this, it sounds to me >> like it doesn't build correctly on armv7? > > > It finally build: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33304182 > > > on armv7 ... > > > I don't understand it ... Only the top level task is on armv7... the actual build happened on buildvm-ppc64le-10.ppc.fedoraproject.org When you do a build, koji starts a parent task that takes care of making the src.rpmm, starting any other arch builds (or noarch) and tagging when it's done. The actual build(s) are done in a child of that parent. kevin 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
PySide2: 64bit builds fail but 32bit builds succeed (Clang issue?)
I'm working on getting PySide2 into Fedora which gives you python bindings for Qt5. It uses some code specific to Clang so I can't use gcc. I've got everything building but for some reason the 64bit builds fail for two binaries which rpmbuild can't link back to build-ids. BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-rcc As far as I can tell -g is being passed to clang for these binaries... But the 32bit builds complete. I'm pretty much at a loss at this point and it's difficult to troubleshoot because I can't build locally. Mock even with --enablerepo=local is (was?) missing gcc-9.0.1. (no more mirrors to try). https://bugzilla.redhat.com/show_bug.cgi?id=1634658 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
[Test-Announce] 2019-03-11 @ ** 16:00 ** UTC - Fedora 30 Blocker Review Meeting
# F30 Blocker Review meeting # Date: 2019-03-11 # Time: ** 16:00 ** UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 3 proposed Beta blockers and 3 proposed Beta FEs to review, so let's have a Fedora 30 blocker review meeting on Monday! Please note that the meeting time is changing to 16:00 UTC this time, as North America (along with some but not all other places) starts daylight savings time on Sunday. If your region observes DST and you are setting your clocks forward on Sunday, the meeting will be at the same local time as usual. If DST starts later in your region or it does not observe DST at all, the meeting will be *one hour earlier* in your local time. If you're unsure, you can run 'date -u' to see what UTC time it is right now, and you can use a site like timeanddate.com to figure out what local time 2019-03-11 16:00 UTC is :) If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F30 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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
[Test-Announce] 2019-03-11 @ ** 15:00 ** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2019-03-11 # Time: ** 15:00 ** UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't get through the whole agenda last week, so let's meet up again this week and finish it off. Please note that the meeting time is changing to 15:00 UTC this time, as North America (along with some but not all other places) starts daylight savings time on Sunday. If your region observes DST and you are setting your clocks forward on Sunday, the meeting will be at the same local time as usual. If DST starts later in your region or it does not observe DST at all, the meeting will be *one hour earlier* in your local time. If you're unsure, you can run 'date -u' to see what UTC time it is right now, and you can use a site like timeanddate.com to figure out what local time 2019-03-11 15:00 UTC is :) If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 30 status 3. Fedora 31 Change review: Rawhide package gating https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates 4. Release criteria / test case proposal status 5. Test Day / community event status 6. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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: Builders with different Mock version and different results
Dne 08. 03. 19 v 21:27 Kevin Fenzi napsal(a): > On 3/8/19 12:19 PM, Vít Ondruch wrote: >> I wonder why different builders has different version of mock and why >> the build result differs? >> >> The scratch build passes: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459 >> >> While the official fails: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270 > All the armv7 builders are stuck on f27 due to > https://bugzilla.redhat.com/show_bug.cgi?id=1576593 > (newer kernels cause some builds to pause the builder or crash the builds). > > I don't think mock version has anything do to with this, it sounds to me > like it doesn't build correctly on armv7? It finally build: https://koji.fedoraproject.org/koji/taskinfo?taskID=33304182 on armv7 ... I don't understand it ... V. > > kevin > > > > ___ > 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 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: Builders with different Mock version and different results
On vendredi 8 mars 2019 21:19:57 CET Vít Ondruch wrote: > I wonder why different builders has different version of mock and why > the build result differs? > > The scratch build passes: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459 > > While the official fails: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270 > > > Also, I wonder what is this "BUILDSTDERR:" I don't think the output goes > to stderr nor it makes the output more readable :/ > > > Vít > When it works in scratch and not in official, my guess would be that the error does not happen all the time: a race condition for example. Try running the official again, it may work. ___ 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: Fedora 30 Beta blocker status mail #3
On Fri, Mar 8, 2019 at 12:56 PM wrote: > > On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson > wrote: > > I requested testing on desktop@ and test@ lists earlier this week; so > > far that seems to suggest that this is failing for a lot of people on > > a > > lot of hardware...but it also fails the same way on F29 in most cases, > > suggesting we shipped F29 broken as well. I don't think we've yet had > > feedback from a system where nomodeset is actually *needed*, which > > would be interesting. > > Please also consider that the target audience for Fedora Workstation is > not going to know about nomodeset or how to modify the kernel command > line. So unless we have some specific release criterion referencing > nomodeset, I'm not sure why it would be a blocker. The installation media, netinstaller and Live, on both UEFI and BIOS, contains a boot menu with a Troubleshooting submenu, which contains a boot entry to boot using Basic Video, and that in turn has the nomodeset parameter already set. -- 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: Builders with different Mock version and different results
On 3/8/19 12:19 PM, Vít Ondruch wrote: > I wonder why different builders has different version of mock and why > the build result differs? > > The scratch build passes: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459 > > While the official fails: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270 All the armv7 builders are stuck on f27 due to https://bugzilla.redhat.com/show_bug.cgi?id=1576593 (newer kernels cause some builds to pause the builder or crash the builds). I don't think mock version has anything do to with this, it sounds to me like it doesn't build correctly on armv7? kevin 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: Builders with different Mock version and different results
There is probably also different version of DNF used to install the buildroot or otherwise I don't understand the differences in the root.log. V. Dne 08. 03. 19 v 21:19 Vít Ondruch napsal(a): > I wonder why different builders has different version of mock and why > the build result differs? > > The scratch build passes: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459 > > While the official fails: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270 > > > Also, I wonder what is this "BUILDSTDERR:" I don't think the output goes > to stderr nor it makes the output more readable :/ > > > Vít > > ___ > 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
Builders with different Mock version and different results
I wonder why different builders has different version of mock and why the build result differs? The scratch build passes: https://koji.fedoraproject.org/koji/taskinfo?taskID=33303459 While the official fails: https://koji.fedoraproject.org/koji/taskinfo?taskID=33303270 Also, I wonder what is this "BUILDSTDERR:" I don't think the output goes to stderr nor it makes the output more readable :/ Vít ___ 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: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x > in f30/rawhide. > > I reset it to 1 in subsequent builds. Now adamwill is running builds with it > bumped to 2 again. > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > even I think) where they have epoch=2. I see this as a feature that lets > someone install Ceph's epoch=2 packages on a system and not risk > inadvertently updating with the Fedora Ceph packages. > > Is there really no other way to get rid of the one or two "bad builds" where > epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? > As of right now, no. Once it goes out in a compose, that's the way it goes... I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... And EVR games like this are really annoying. :( -- 真実はいつも一つ！/ 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: Packaging Question - Building the Binaries of my package
On Thu, Mar 07, 2019 at 06:49:12PM +, Michael Zhang wrote: > So after tinkering around, I can incorporate the building of the > openliberty.zip into the Travis CI build but I cannot directly add it > into the %install phase of the rpm spec file. Would that be fine? It should be in the %build section, not %install, but that's a detail. Can you elaborate on why you can build it in Travis CI but not in the RPM build itself? That might help us help you better. We have a proposal and some interesting work focused on going from source to RPM in a more automated way — see https://github.com/packit-service/packit. This doesn't solve your problem today, but perhaps could make things easier and better for you in the future. -- Matthew Miller Fedora Project Leader ___ 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
On not bumping the epoch in ceph-14, f30 and f31/rawhide
The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x in f30/rawhide. I reset it to 1 in subsequent builds. Now adamwill is running builds with it bumped to 2 again. I would prefer that it not be bumped. Ceph has their own builds (for Fedora even I think) where they have epoch=2. I see this as a feature that lets someone install Ceph's epoch=2 packages on a system and not risk inadvertently updating with the Fedora Ceph packages. Is there really no other way to get rid of the one or two "bad builds" where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? Thanks, -- Kaleb ___ 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: Fedora 30 Beta blocker status mail #3
On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson wrote: I requested testing on desktop@ and test@ lists earlier this week; so far that seems to suggest that this is failing for a lot of people on a lot of hardware...but it also fails the same way on F29 in most cases, suggesting we shipped F29 broken as well. I don't think we've yet had feedback from a system where nomodeset is actually *needed*, which would be interesting. Please also consider that the target audience for Fedora Workstation is not going to know about nomodeset or how to modify the kernel command line. So unless we have some specific release criterion referencing nomodeset, I'm not sure why it would be a blocker. ___ 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
packages provides Re: HEADS UP: python2-sphinx is going away on Monday (2019-03-11)
Hello,
:P I just found a weird bug :
dnf repoquery --available --whatrequires python2-mlt
flowblade-0:1.16.0-2.gitd2f153f.fc28.noarch
flowblade-0:2.0-1.fc28.noarch
dnf repoquery --disablerepo='*' --enablerepo=rawhide
--enablerepo=rpmfusion-{,non}free-rawhide --available --requires flowblade
(...)
mlt-python
(...)
dnf repoquery --disablerepo='*' --enablerepo=rawhide
--enablerepo=rpmfusion-{,non}free-rawhide --available --whatrequires
python2-mlt
None !!! ???
On Fri, 2019-03-08 at 19:29 +0100, Miro Hrončok wrote:
> Due to https://fedoraproject.org/wiki/Changes/Sphinx2 we will be
> removing
> python2-sphinx and other related packages on Monday (2019-03-11).
>
> If you are Bcc'ed, your package still uses python2-sphinx on build
> time and will
> start to FTBFS. A fix is to stop BuildRequiring it. For your
> documentation,
> there are several options:
>
> 1) stop using Python 2 entirely (preferred), drop python2 subpackages
>(if not dependent upon by other packages)
> 2) switch to python3-sphinx for building the documentation
> 3) stop building the documentation
>
> If you need help, please explicitly ask for it, we will not do this
> for you
> automatically unless it would block something else.
>
> (The query is based on the latest rawhide compose and does not
> entirely reflect
> the state of your spec in dist-git.)
>
> Maintainers by package:
> BEDTools verdurin
> ViTables tnorth zbyszek
> alot ttomecek
> apiextractor fschwarz hobbes1069 jreznik rdieter than
> autotest-framework cleber dzickus mkrizek
> aws landgraf rombobeorn
> beaker dcallagh greghellings herlo
> bpython maxamillion terjeros
> bro fab mildew pemensik
> bugzilla eseyman itamarjp
> bzr hno pstodulk vvitek
> catkin orphan rmattes thofmann
> extra-cmake-modules cicku dvratil heliocastro lkundrak rdieter
> fedmsg bowlofeggs
> gdeploy ramkrsna sac
> gnuradio jskarvad mmahut
> idriscodeblock petersen
> libmypaint nphilipp
> mirrorbrain averi
> mod_wsgi jdornak jkaluza jorton lmacken mrunge
> moksha johnp lmacken ralph
> mp pcpa sagitter
> nextcloud-client germano nonamedotc
> nordugrid-arc-nagios-plugins ellert jonkni
> offlineimap cicku dodji notting teuf
> owncloud-client anvil comzeradd elsupergomez nb
> percona-xtrabackup pmackinn
> petscsagitter
> pyparsingapevec jamatos sharkcz terjeros
> python-Bottleneckbesser82
> python-arc cleber
> python-breathe daveisfera
> python-case mrunge
> python-catkin_pkgankursinha cottsay rmattes
> python-cloudservers clalance imcleod
> python-dulwich fab
> python-eventlet abbot ignatenkobrain kevin
> python-factory-boy jorti
> python-fedorabowlofeggs codeblock ricky
> python-feedparserhguemar lmacken louizatakk mcepl
> python-flask codeblock fcami hguemar hushan ianweller
> puiterwijk
> python-funcsigs hguemar ralph
> python-gabbi apevec chandankumar
> python-genmsgorphan rmattes thofmann
> python-genpy orphan rmattes thofmann
> python-gunicorn dcallagh
> python-hacking mrunge social
> python-hardware flepied
> python-hl7 ankursinha
> python-htmlmin jujens
> python-jenkins-job-builder ignatenkobrain ktdreyer pabelanger
> python-jsonpath-rw-ext apevec hguemar pkilambi
> python-kazoo apevec nsaje
> python-kitchen pingou ralph
> python-larch salimma
> python-mpd2 ankursinha
> python-mpmathjussilehtola zbyszek
> python-netaddr jcholast jeckersb jhrozek
> python-ngram besser82
> python-nose_fixesbesser82
> python-nss jdennis
> python-numpydoc orion tomspur
> python-olefile rebus robert smani
> python-osrf-pycommon cottsay rmattes
> python-parsley ishcherb lbazan
> python-pathlib apevec carlwgeorge hguemar
> python-pbr apevec mrunge
> python-pika icheishvili ngompa silas
> python-pillowmiminar smani
> python-pint mrunge
> python-plaster bowlofeggs
> python-pwntools mikep
> python-pycares fantom
> python-pygments smilner
> python-pyperclip hguemar
> python-pypumpralph
> python-pyramid bowlofeggs lmacken ralph rossdylan tdabasin
> python-requests-cache codeblock hobbes1069
> python-rosdepcottsay rmattes thofmann
> python-rosdistro cottsay rmattes thofmann
> python-rosinstallrmattes
> python-rospkgcottsay rmattes
> python-sane smani
> python-scripttestchurchyard mbacovsk
> python-slixmpp fantom louizatakk
> python-testtools abompard kumarpraveen salimma
> python-tracing salimma
> python-txaio jujens
> python-txsocksx lim
Re: Fedora 30 Beta blocker status mail #3
On Fri, 2019-03-08 at 13:49 -0500, Ben Cotton wrote: > > Accepted blockers > - > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1656509 - libdnf - POST > F29 to Rawhide (F30) upgrades fail, seems to be modularity-related > > Reassigned to DNF. Patch merged upstream to fix the issue. This is not really true - see my comment #31. We need more clarity on this from modularity and DNF folks. It is not POST any more, it is ASSIGNED, I changed this three days ago to reflect the fact that the supposed 'fix' doesn't actually seem to be a full practical fix. > 4. https://bugzilla.redhat.com/show_bug.cgi?id=1683197 - gdm - NEW > gdm Fails to load with "nomodeset" > > Boot process hangs when nomodeset is used as a boot parameter. No > further information available yet. I requested testing on desktop@ and test@ lists earlier this week; so far that seems to suggest that this is failing for a lot of people on a lot of hardware...but it also fails the same way on F29 in most cases, suggesting we shipped F29 broken as well. I don't think we've yet had feedback from a system where nomodeset is actually *needed*, which would be interesting. -- 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
HEADS UP: python2-sphinx is going away on Monday (2019-03-11)
Due to https://fedoraproject.org/wiki/Changes/Sphinx2 we will be removing python2-sphinx and other related packages on Monday (2019-03-11). If you are Bcc'ed, your package still uses python2-sphinx on build time and will start to FTBFS. A fix is to stop BuildRequiring it. For your documentation, there are several options: 1) stop using Python 2 entirely (preferred), drop python2 subpackages (if not dependent upon by other packages) 2) switch to python3-sphinx for building the documentation 3) stop building the documentation If you need help, please explicitly ask for it, we will not do this for you automatically unless it would block something else. (The query is based on the latest rawhide compose and does not entirely reflect the state of your spec in dist-git.) Maintainers by package: BEDTools verdurin ViTables tnorth zbyszek alot ttomecek apiextractor fschwarz hobbes1069 jreznik rdieter than autotest-framework cleber dzickus mkrizek aws landgraf rombobeorn beaker dcallagh greghellings herlo bpython maxamillion terjeros bro fab mildew pemensik bugzilla eseyman itamarjp bzr hno pstodulk vvitek catkin orphan rmattes thofmann extra-cmake-modules cicku dvratil heliocastro lkundrak rdieter fedmsg bowlofeggs gdeploy ramkrsna sac gnuradio jskarvad mmahut idriscodeblock petersen libmypaint nphilipp mirrorbrain averi mod_wsgi jdornak jkaluza jorton lmacken mrunge moksha johnp lmacken ralph mp pcpa sagitter nextcloud-client germano nonamedotc nordugrid-arc-nagios-plugins ellert jonkni offlineimap cicku dodji notting teuf owncloud-client anvil comzeradd elsupergomez nb percona-xtrabackup pmackinn petscsagitter pyparsingapevec jamatos sharkcz terjeros python-Bottleneckbesser82 python-arc cleber python-breathe daveisfera python-case mrunge python-catkin_pkgankursinha cottsay rmattes python-cloudservers clalance imcleod python-dulwich fab python-eventlet abbot ignatenkobrain kevin python-factory-boy jorti python-fedorabowlofeggs codeblock ricky python-feedparserhguemar lmacken louizatakk mcepl python-flask codeblock fcami hguemar hushan ianweller puiterwijk python-funcsigs hguemar ralph python-gabbi apevec chandankumar python-genmsgorphan rmattes thofmann python-genpy orphan rmattes thofmann python-gunicorn dcallagh python-hacking mrunge social python-hardware flepied python-hl7 ankursinha python-htmlmin jujens python-jenkins-job-builder ignatenkobrain ktdreyer pabelanger python-jsonpath-rw-ext apevec hguemar pkilambi python-kazoo apevec nsaje python-kitchen pingou ralph python-larch salimma python-mpd2 ankursinha python-mpmathjussilehtola zbyszek python-netaddr jcholast jeckersb jhrozek python-ngram besser82 python-nose_fixesbesser82 python-nss jdennis python-numpydoc orion tomspur python-olefile rebus robert smani python-osrf-pycommon cottsay rmattes python-parsley ishcherb lbazan python-pathlib apevec carlwgeorge hguemar python-pbr apevec mrunge python-pika icheishvili ngompa silas python-pillowmiminar smani python-pint mrunge python-plaster bowlofeggs python-pwntools mikep python-pycares fantom python-pygments smilner python-pyperclip hguemar python-pypumpralph python-pyramid bowlofeggs lmacken ralph rossdylan tdabasin python-requests-cache codeblock hobbes1069 python-rosdepcottsay rmattes thofmann python-rosdistro cottsay rmattes thofmann python-rosinstallrmattes python-rospkgcottsay rmattes python-sane smani python-scripttestchurchyard mbacovsk python-slixmpp fantom louizatakk python-testtools abompard kumarpraveen salimma python-tracing salimma python-txaio jujens python-txsocksx limb python-vcstools cottsay rmattes python-werkzeug abompard codeblock hguemar ianweller python-whooshmstuchli rkuska sgallagh python-wrapt chandankumar ralph python-wsgi_intercept apevec chandankumar python-wstoolankursinha cottsay rmattes python-yaql mflobo python-zope-component abompard ralph tdabasin python-zope-schema abompard ralph tdabasin python2-django1.11 pviktori python2-docs bkabrda churchyard cstratak pviktori rkuska torsava python2-matplotlib ellert tibbs scipycstratak jspaleta orion tomspur ttomecek seqan2 sagitter shiboken fschwarz hobbes1069 jreznik rdieter than swift-lang tachoknight the-new-hotness jcline tortoisehg
Re: Fedora rawhide compose report: 20190306.n.1 changes
On 08. 03. 19 18:26, Kevin Fenzi wrote: On 3/7/19 12:30 PM, Miro Hrončok wrote: On 07. 03. 19 21:19, Kevin Fenzi wrote: On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report wrote: OLD: Fedora-Rawhide-20190217.n.0 NEW: Fedora-Rawhide-20190306.n.1 = SUMMARY = Added images: 13 Dropped images: 7 Added packages: 128 Dropped packages: 174 Upgraded packages: 1745 Downgraded packages: 165 Looks like it is second or third time when after report about release some batch of the packages nothing hit the ground/public repos. My understanding is that it is some glitch in release infrastructure. May we know what is the current situation? What ground/public repos do you mean here? The master mirror is definitely updated. It's a large pile of changes, so other mirrors may take a bit longer than normal to sync. There's no glitch I am aware of, so more information would be helpful. This seems quite OK: https://admin.fedoraproject.org/mirrormanager/propgation Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 Well, perhaps you looked at it too soon? Right now it's slowly showing mirrors catching up over the last 12 hours or so. Perhaps. I see the progress now, thanks! -- 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
Orphaning rubygem-multipart
Hi, I don't have any use for rubygem-multipart, therefore I orpahned the package. There was no upstream change past 10 years and nobody is probably using the package. Vít ___ 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: Fedora rawhide compose report: 20190306.n.1 changes
On 3/7/19 12:30 PM, Miro Hrončok wrote: > On 07. 03. 19 21:19, Kevin Fenzi wrote: >> On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: >>> On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report >>> wrote: OLD: Fedora-Rawhide-20190217.n.0 NEW: Fedora-Rawhide-20190306.n.1 = SUMMARY = Added images: 13 Dropped images: 7 Added packages: 128 Dropped packages: 174 Upgraded packages: 1745 Downgraded packages: 165 >>> >>> Looks like it is second or third time when after report about release >>> some batch of the packages nothing hit the ground/public repos. >>> My understanding is that it is some glitch in release infrastructure. >>> May we know what is the current situation? >> >> What ground/public repos do you mean here? The master mirror is >> definitely updated. It's a large pile of changes, so other mirrors may >> take a bit longer than normal to sync. >> >> There's no glitch I am aware of, so more information would be helpful. > > This seems quite OK: > > https://admin.fedoraproject.org/mirrormanager/propgation > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 Well, perhaps you looked at it too soon? Right now it's slowly showing mirrors catching up over the last 12 hours or so. kevin 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: Scratch build uploads to koji VERY SLOW
I guess this depends on the status of the Apache httpd workers. Like are they stuck in IO to the /mnt/koji scratch location, or something else? Unfortunately it's not secure to publicly display Koji's in-flight HTTP requests with mod_status, since the URLs contain the authenticated session information, but that's where I'd go for the next level of investigation if this happens frequently. Maybe we need a separate utility in kojiweb to sanitize the hub's mod_status' output for the public and display "what's the hub doing now". - Ken On Thu, Mar 7, 2019, 12:08 PM Richard Shaw wrote: > On Wed, Mar 6, 2019 at 6:39 PM Kevin Fenzi wrote: > >> On 3/6/19 4:14 PM, Richard Shaw wrote: >> > >> > New since the last couple of weeks but I've been more active working on >> > FTBFS issues so can't say exactly when it started. It's never been super >> > speedy but also never been this painful. >> >> Odd. I can't think of anything on the server end that has changed >> recently that might cause this. It's just as fast as always for me. >> >> Has curl been updated on your machine(s) around the time it started? >> >> Does koji --debug build scratch tag src.rpm >> > > Hah... just tried it and the srpm uploaded at >1MB/sec... > > 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 > ___ 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: Orphaning Fog (most of rubygem-fog* packages)
Dne 08. 03. 19 v 16:57 Vít Ondruch napsal(a): > Hi, > > I have orphaned most of the Fog stack [1, 2]. Fog is the Ruby cloud > services library, top to bottom, collections provide a simplified > interface, making clouds easier to work with and switch between. > > Fog was originally introduced into Fedora just as a dependency of > Vagrant. Since that time, fog-libvirt, which used to be integral part of > Fog was extracted into independent package, which is enough for Vagrant. > Since I don't have any use case for the Fog itself, I have orphaned it, > which means I have orphaned following packages: > > rubygem-fog > rubygem-fog-atmos > rubygem-fog-aws I just found out that this one ^^ is surprisingly required by rubygem-sitemap_generator, so I'm going to pick it up again 🙈 Vít > rubygem-fog-brightbox > rubygem-fog-ecloud > rubygem-fog-profitbricks > rubygem-fog-radosgw > rubygem-fog-riakcs > rubygem-fog-sakuracloud > rubygem-fog-serverlove > rubygem-fog-softlayer > rubygem-fog-storm_on_demand > rubygem-fog-terremark > rubygem-fog-vmfusion > rubygem-fog-voxel > > I'll keep the following for Vagrant: > > rubygem-fog-libvirt > rubygem-fog-core > rubygem-fog-json > rubygem-fog-xml > > All the packages are up to date. The upstream is nice and helpful. > > > Vít > > > [1] http://fog.io/ > > [2] https://github.com/fog/fog > > ___ > 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
Orphaning Fog (most of rubygem-fog* packages)
Hi, I have orphaned most of the Fog stack [1, 2]. Fog is the Ruby cloud services library, top to bottom, collections provide a simplified interface, making clouds easier to work with and switch between. Fog was originally introduced into Fedora just as a dependency of Vagrant. Since that time, fog-libvirt, which used to be integral part of Fog was extracted into independent package, which is enough for Vagrant. Since I don't have any use case for the Fog itself, I have orphaned it, which means I have orphaned following packages: rubygem-fog rubygem-fog-atmos rubygem-fog-aws rubygem-fog-brightbox rubygem-fog-ecloud rubygem-fog-profitbricks rubygem-fog-radosgw rubygem-fog-riakcs rubygem-fog-sakuracloud rubygem-fog-serverlove rubygem-fog-softlayer rubygem-fog-storm_on_demand rubygem-fog-terremark rubygem-fog-vmfusion rubygem-fog-voxel I'll keep the following for Vagrant: rubygem-fog-libvirt rubygem-fog-core rubygem-fog-json rubygem-fog-xml All the packages are up to date. The upstream is nice and helpful. Vít [1] http://fog.io/ [2] https://github.com/fog/fog ___ 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: Fedora rawhide compose report: 20190306.n.1 changes
On Fri, 8 Mar 2019 at 02:42, Tomasz Kłoczko wrote: > > On Fri, 8 Mar 2019 at 00:37, Stephen John Smoogen wrote: > [..] > > We don't push to mirrors. They sync from either our main servers or a > > tier 1 or tier 2 mirror which also pull/rsync from the master mirrors. > > This means it will take time to get stuff down and out. So like I > > said.. do not expect various mirrors to be in sync until Monday at the > > latest. The more people trying to get stuff which isn't there just > > makes this longer as they are usually getting resource limitations. > > I must be somehow extremely unlucky because after checking +two dozens > of the mirrors from > https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora/development OK what you are seeing is a bug. That page is showing all mirrors whether they are sync'd or not and whether they offer development or not. I need to find where that is getting linked on from the main pages and remove it as the informaiton is no different from https://admin.fedoraproject.org/mirrormanager/mirrors Try download-ib02.fedoraproject.org for the time being and see if that works for you. > available over rsync in UK, Poland, Netherlands, France and US I dd > not found even one synced :/ > Interesting only is that they are all stopped synchronisation in the > middle of the Aug 2018 or 17 Feb 2019. > Can someone help and point on mirror accessible over rsync which is > up-to-date? > > Today after clean dnf caches again and rerun upgrade seems like at > least indexes are propagated correctly however: > > Transaction Summary > = > Install 42 Packages > Upgrade489 Packages > Remove 3 Packages > > Total download size: 841 M > DNF will only download packages for the transaction. > Downloading Packages: > [MIRROR] gdm-3.31.91-1.fc31.x86_64.rpm: Status code: 404 for > https://mirror.vorboss.net/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/g/gdm-3.31.91-1.fc31.x86_64.rpm > [FAILED] gdm-3.31.91-1.fc31.x86_64.rpm: No more mirrors to try - All > mirrors were already tried without success > (2-3/582): gdm-devel-3.31.91-1.fc31.x86_64.rpm 0% > [] 103 > kB/s | 509 kB139:10 ETA > The downloaded packages were saved in cache until the next successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: Error downloading packages: > Cannot download Packages/g/gdm-3.31.91-1.fc31.x86_64.rpm: All > mirrors were tried > Loaded plugins: builddep, changelog, config-manager, copr, debug, > debuginfo-install, download, generate_completion_cache, > needs-restarting, playground, repoclosure, repodiff, repograph, > repomanage, reposync > DNF version: 4.1.0 > > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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: Downgrading glibc from Rawhide removed /bin/sh (!)
On 3/8/19 2:52 PM, Panu Matilainen wrote:
On 3/8/19 2:29 PM, Panu Matilainen wrote:
On 3/8/19 1:54 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 5:52 PM, Florian Weimer wrote:
* Panu Matilainen:
On 3/7/19 1:13 PM, Florian Weimer wrote:
* Richard W. M. Jones:
$ sudo dnf install glibc-headers.i686
…
Downgrading:
That looks like a bug in itself.
The last time I looked at something similar, I saw this: RPM
would not
adjust a pre-existing symbolic link to a new target very late in the
transaction. Like deleting old files which are gone in an update or
downgrade, this does *not* happen when the unpacking of the
replacement
package happens, but towards the conclusion of the transaction.
In the
meantime, scriptlets run with the broken file system.
In your case, maybe one of the scriptlet errors prevented the
final step
with the adjustment of the symbolic link by RPM.
(Just to be clear, the symbolic link is regularly packaged, it's not
something that we manage using scripts.)
IIRC the issue is that at when ldconfig runs from the package
scripts,
on downgrade the newer file is still on disk and thus ldconfig leaves
the link the way it is, but at the end of transaction it'll be gone
and symlinks can be broken.
Is there a chance that RPM will be changed to run more scriptlets with
the final disk contents?
There's %transfiletriggerin, %transfiletriggerpostun and %posttrans
that run after the entire transaction, and then the individual
postun-type scripts/triggers. What is it that you're missing?
Correct symbolic links.
If the symbolic links are not installed as they are in the packaged
contents before running scriptlets (any scriptlets), we need to bring
back the ldconfig scriptlets. This is not just a problem for glibc.
Ehm? Symlinks are installed just like any other content, and rpm has
no reason to mess with them. Like I said above, the problem is almost
certainly a mistimed ldconfig causing the links changed back to the
version that is about to get removed.
Hmm, except that in this particular there shouldn't be any mistimed
ldconfigs present. Perhaps I should take a closer look.
It's glibc's own %post own scripts that are somehow breaking it. I've a
minimal reproducer here with glibc 2.29 in /srv/root chroot. The bash
version is just to show whether bash is alive or not:
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
[root@sopuli glibc]# rpm -Uv --oldpackage --root /srv/test
glibc-2.28-26.fc29.x86_64.rpm glibc-common-2.28-26.fc29.x86_64.rpm
glibc-minimal-langpack-2.28-26.fc29.x86_64.rpm
Verifying packages...
Preparing packages...
glibc-common-2.28-26.fc29.x86_64
glibc-minimal-langpack-2.28-26.fc29.x86_64
glibc-2.28-26.fc29.x86_64
glibc-2.29-8.fc30.x86_64
glibc-minimal-langpack-2.29-8.fc30.x86_64
glibc-common-2.29-8.fc30.x86_64
error: failed to exec scriptlet interpreter /bin/sh: No such file or
directory
warning: %triggerpostun(glibc-common-2.28-26.fc29.x86_64) scriptlet
failed, exit status 127
error: failed to exec scriptlet interpreter /bin/sh: No such file or
directory
warning: %triggerin(glibc-common-2.28-26.fc29.x86_64) scriptlet failed,
exit status 127
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
chroot: failed to run command ‘bash’: No such file or directory
So, exactly the same as the original posting. Now, lets go back to the
original scenario, and run the same downgrade with --nopost:
[root@sopuli glibc]# rpm -U --root /srv/test
glibc-2.29-8.fc30.x86_64.rpm glibc-common-2.29-8.fc30.x86_64.rpm
glibc-minimal-langpack-2.29-8.fc30.x86_64.rpm
warning: glibc-2.29-8.fc30.x86_64.rpm: Header V3 RSA/SHA256 Signature,
key ID cfc659b9: NOKEY
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
[root@sopuli glibc]# rpm -Uv --oldpackage --nopost --root /srv/test
glibc-2.28-26.fc29.x86_64.rpm glibc-common-2.28-26.fc29.x86_64.rpm
glibc-minimal-langpack-2.28-26.fc29.x86_64.rpm
Verifying packages...
Preparing packages...
glibc-common-2.28-26.fc29.x86_64
glibc-minimal-langpack-2.28-26.fc29.x86_64
glibc-2.28-26.fc29.x86_64
glibc-2.29-8.fc30.x86_64
glibc-minimal-langpack-2.29-8.fc30.x86_64
glibc-common-2.29-8.fc30.x86_64
[root@sopuli glibc]# chroot /srv/test bash --version|head -1
GNU bash, version 4.4.23(1)-release (x86_64-redhat-linux-gnu)
[root@sopuli glibc]#
glibc's %post is /usr/sbin/glibc_post_upgrade., so that's what's
doing something bad here. When straced through forks and all, guess
what? It's running ldconfig:
22611 execve("/usr/sbin/glibc_post_upgrade.x86_64",
["/usr/sbin/glibc_post_upgrade.x86"...], 0x7ffc249bfc00 /* 50 vars */) = 0
22611 arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd33d5ed40) = -1 EINVAL
(Invalid argument)
22611 brk(NULL) = 0x7f42ba93
22611 brk(0x7f42ba9311c0) = 0x7f42ba9311c0
22611 arch_prctl(ARCH_SET_FS, 0x7f4
Re: Downgrading glibc from Rawhide removed /bin/sh (!)
On Thu, Mar 7, 2019, at 10:53 AM, Florian Weimer wrote:
>
> > The %transfiletriggerpostun would've probably fixed it if it used -p
> > instead of shell.
>
> We switched to the shell for the benefit of rpm-ostree.
Short answer:
https://github.com/projectatomic/rpm-ostree/issues/749#issuecomment-470926180
(Let me know if that would help something, here or in the issue; it wouldn't be
hard for us to implement)
Slightly longer answer: There are *multiple* layers of defenses in rpm-ostree
against exactly this sort of problem. The reason we don't implement Lua is (as
the later linked issue spells out in more detail) is to ensure we can reliably
construct a *new* root filesystem in a transactional model without having any
potential effects on your running filesystem.
The fact that with rpm-ostree you always have a "base image" that is
constructed on the server side is the first primary line of defense; we won't
ship you a new image (ostree commit) that isn't known good.
The second line of defense is that *client side* rpm-ostree always runs a
"sanity check" in the new deployment:
https://github.com/projectatomic/rpm-ostree/pull/892
The third line of defense is that somehow even if you do get a broken tree, you
always have the previous one in the bootloader.
But we do support both layering and overrides - you can engage the package
system side.
Now personally if I wanted to test a new glibc I'd first do it in a disposable
clone of my development podman container, rather than replacing the one on the
root filesystem of my host.But let's assume for whatever reason we do need
to test an updated glibc on the host system; rpm-ostree supports that too:
[root@localhost ~]# rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-atomic:fedora/29/x86_64/atomic-host
Version: 29.20190306.2 (2019-03-06T23:32:07Z)
Commit:
57297da7779ed8b7b7b9a0f39f6f12a703000a40cf451770fe23749a5558f60d
GPGSignature: Valid signature by
5A03B4DD8254ECA02FDA1637A20AA56B429476B4
ostree://fedora-atomic:fedora/29/x86_64/atomic-host
Version: 29.20190219.0 (2019-02-19T04:52:26Z)
Commit:
d00adf110907f93f6cdd05deda0e2878c9bd71c74e0c4c2e9a5250d2f4cc8868
GPGSignature: Valid signature by
5A03B4DD8254ECA02FDA1637A20AA56B429476B4
[root@localhost ~]# rpm -q glibc
glibc-2.28-26.fc29.x86_64
(Here I browse to https://koji.fedoraproject.org/koji/packageinfo?packageID=57
and find the previous glibc built for f29):
[root@localhost ~]# rpm-ostree override replace
https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-{common-,}2.28-25.fc29.x86_64.rpm
Downloading
'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-common-2.28-25.fc29.x86_64.rpm'...
done!
Downloading
'https://kojipkgs.fedoraproject.org//packages/glibc/2.28/25.fc29/x86_64/glibc-2.28-25.fc29.x86_64.rpm'...
done!
Checking out tree 57297da... done
Enabled rpm-md repositories: updates fedora fahc
rpm-md repo 'updates' (cached); generated: 2019-03-07T20:40:34Z
rpm-md repo 'fedora' (cached); generated: 2018-10-24T22:20:15Z
rpm-md repo 'fahc' (cached); generated: 2019-03-07T05:41:31Z
Importing rpm-md... done
Resolving dependencies... done
error: Could not depsolve transaction; 2 problems detected:
Re: Downgrading glibc from Rawhide removed /bin/sh (!)
On 3/8/19 2:29 PM, Panu Matilainen wrote: On 3/8/19 1:54 PM, Florian Weimer wrote: * Panu Matilainen: On 3/7/19 5:52 PM, Florian Weimer wrote: * Panu Matilainen: On 3/7/19 1:13 PM, Florian Weimer wrote: * Richard W. M. Jones: $ sudo dnf install glibc-headers.i686 … Downgrading: That looks like a bug in itself. The last time I looked at something similar, I saw this: RPM would not adjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update or downgrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In the meantime, scriptlets run with the broken file system. In your case, maybe one of the scriptlet errors prevented the final step with the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.) IIRC the issue is that at when ldconfig runs from the package scripts, on downgrade the newer file is still on disk and thus ldconfig leaves the link the way it is, but at the end of transaction it'll be gone and symlinks can be broken. Is there a chance that RPM will be changed to run more scriptlets with the final disk contents? There's %transfiletriggerin, %transfiletriggerpostun and %posttrans that run after the entire transaction, and then the individual postun-type scripts/triggers. What is it that you're missing? Correct symbolic links. If the symbolic links are not installed as they are in the packaged contents before running scriptlets (any scriptlets), we need to bring back the ldconfig scriptlets. This is not just a problem for glibc. Ehm? Symlinks are installed just like any other content, and rpm has no reason to mess with them. Like I said above, the problem is almost certainly a mistimed ldconfig causing the links changed back to the version that is about to get removed. Hmm, except that in this particular there shouldn't be any mistimed ldconfigs present. Perhaps I should take a closer look. Note that the scenario with ldconfig is very real though, as long as *any* package runs ldconfig in middle of a transaction involving downgrades, the links can get misadjusted to version(s) that will be removed, and unless ldconfig is run again after that removal, things will be broken. Back when each and every library package ran ldconfig in its post and postun, things also got fixed right away. Now that some do and others dont, its more of a mixed bag. Either ldconfig should only run once at the very end, or it should run after each library package. - Panu - - Panu - ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
On 3/8/19 1:54 PM, Florian Weimer wrote: * Panu Matilainen: On 3/7/19 5:52 PM, Florian Weimer wrote: * Panu Matilainen: On 3/7/19 1:13 PM, Florian Weimer wrote: * Richard W. M. Jones: $ sudo dnf install glibc-headers.i686 … Downgrading: That looks like a bug in itself. The last time I looked at something similar, I saw this: RPM would not adjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update or downgrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In the meantime, scriptlets run with the broken file system. In your case, maybe one of the scriptlet errors prevented the final step with the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.) IIRC the issue is that at when ldconfig runs from the package scripts, on downgrade the newer file is still on disk and thus ldconfig leaves the link the way it is, but at the end of transaction it'll be gone and symlinks can be broken. Is there a chance that RPM will be changed to run more scriptlets with the final disk contents? There's %transfiletriggerin, %transfiletriggerpostun and %posttrans that run after the entire transaction, and then the individual postun-type scripts/triggers. What is it that you're missing? Correct symbolic links. If the symbolic links are not installed as they are in the packaged contents before running scriptlets (any scriptlets), we need to bring back the ldconfig scriptlets. This is not just a problem for glibc. Ehm? Symlinks are installed just like any other content, and rpm has no reason to mess with them. Like I said above, the problem is almost certainly a mistimed ldconfig causing the links changed back to the version that is about to get removed. - Panu - ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
* Panu Matilainen: > On 3/7/19 5:52 PM, Florian Weimer wrote: >> * Panu Matilainen: >> >>> On 3/7/19 1:13 PM, Florian Weimer wrote: * Richard W. M. Jones: > $ sudo dnf install glibc-headers.i686 … > Downgrading: That looks like a bug in itself. The last time I looked at something similar, I saw this: RPM would not adjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update or downgrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In the meantime, scriptlets run with the broken file system. In your case, maybe one of the scriptlet errors prevented the final step with the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.) >>> >>> IIRC the issue is that at when ldconfig runs from the package scripts, >>> on downgrade the newer file is still on disk and thus ldconfig leaves >>> the link the way it is, but at the end of transaction it'll be gone >>> and symlinks can be broken. >> >> Is there a chance that RPM will be changed to run more scriptlets with >> the final disk contents? > > There's %transfiletriggerin, %transfiletriggerpostun and %posttrans > that run after the entire transaction, and then the individual > postun-type scripts/triggers. What is it that you're missing? Correct symbolic links. If the symbolic links are not installed as they are in the packaged contents before running scriptlets (any scriptlets), we need to bring back the ldconfig scriptlets. This is not just a problem for glibc. 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
Help us test FedoraReview on Python 3
There is a FedoraReview port to Python 3 that needs real word testing by packagers. When you use FedoraReview, please use the Python 3 port instead to help us find bugs. Instructions are at https://pagure.io/FedoraReview/pull-request/312 -> the first comment of my Pull Request is updated with up to date instructions. Thanks, -- 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: Introducing packit
On 07/03/19 17:36, Tomas Tomecek wrote: Hi Miro, sorry for a late reply: I wanted to think it through. Comments inline. On Tue, Feb 26, 2019 at 4:43 PM Miro Hrončok wrote: On 20. 02. 19 23:24, Tomas Tomecek wrote: Hello, at DevConf.cz, we have introduced a new project: packit [1] [2]. [1] https://www.youtube.com/watch?v=KpF27v6K4Oc [2] https://github.com/packit-service/packit From the ticket: >> FESCo is concerned that the presented idea of how this automation >> should work is only applicable to a very limited set of packages and >> would rather see a focus on automating stuff for greater >> audience. > > Yes and no. With source-git [3] this is applicable to any project. > > [3] https://github.com/packit-service/packit#ehm-whats-source-git This sounds like it is only applicable to projects: - controlled by Fedora AND - not concerned by the separation of concerns between upstream and downstream. That's correct. Our short-term plan for packit is that people who are upstreams (or are interested in the source-git workflow) would use it to land their releases into Fedora. For other project that don't want to have spec file in upstream we could use release-monitoring.org, which will create PR in dist-git (these are plans for future, right now we are only creating bug in bugzilla) without the need to bother upstream developer. It's than on package maintainer to look at the changes and approve or reject them. However it says something about source-git only projects as well. This seems like it is adding one extra level of complexity. Care to elaborate how this works exactly? A) for the package maintain who deliberately chose to do this Such packager would only work in the source-git/upstream repository and would NOT need to touch dist-git in any way: packit would handle everything. Basically: do work in the upstream repo, make a release and packit would propose a PR in Fedora dist-git to update to the upstream release. Very similar steps for source-git. B) for a provenpackager doing a mass change (e.g. removing py2 subpackages) Just do it. We plan for packit to sync spec file changes back to upstream/source-git (listen to fedmsg events from dist-git). So that they are equal in both places. C) for releng doing a mass rebuild ^ it's the same I understand that the workflow is not suitable for a bunch of projects. Right now we have a set of goals to fulfill. Once they are done (by Flock), we can start talking about how to make it suitable for everyone. If that makes sense. Tomas ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
On Fri, Mar 8, 2019 at 3:21 AM Panu Matilainen wrote: > > On 3/7/19 5:52 PM, Florian Weimer wrote: > > * Panu Matilainen: > > > >> On 3/7/19 1:13 PM, Florian Weimer wrote: > >>> * Richard W. M. Jones: > >>> > $ sudo dnf install glibc-headers.i686 > >>> … > Downgrading: > >>> > >>> That looks like a bug in itself. > >>> > >>> The last time I looked at something similar, I saw this: RPM would not > >>> adjust a pre-existing symbolic link to a new target very late in the > >>> transaction. Like deleting old files which are gone in an update or > >>> downgrade, this does *not* happen when the unpacking of the replacement > >>> package happens, but towards the conclusion of the transaction. In the > >>> meantime, scriptlets run with the broken file system. > >>> > >>> In your case, maybe one of the scriptlet errors prevented the final step > >>> with the adjustment of the symbolic link by RPM. > >>> > >>> (Just to be clear, the symbolic link is regularly packaged, it's not > >>> something that we manage using scripts.) > >> > >> IIRC the issue is that at when ldconfig runs from the package scripts, > >> on downgrade the newer file is still on disk and thus ldconfig leaves > >> the link the way it is, but at the end of transaction it'll be gone > >> and symlinks can be broken. > > > > Is there a chance that RPM will be changed to run more scriptlets with > > the final disk contents? > > There's %transfiletriggerin, %transfiletriggerpostun and %posttrans that > run after the entire transaction, and then the individual postun-type > scripts/triggers. What is it that you're missing? > > > > >> $ rpm -q --filetriggers glibc-common > >> transfiletriggerin scriptlet (using /bin/sh) -- /lib, /lib64, > >> /usr/lib, /usr/lib64 > >> /sbin/ldconfig > >> transfiletriggerpostun scriptlet (using /bin/sh) -- /lib, /lib64, > >> /usr/lib, /usr/lib64 > >> /sbin/ldconfig > >> > >> The %transfiletriggerpostun would've probably fixed it if it used -p > >> instead of shell. > > > > We switched to the shell for the benefit of rpm-ostree. > > > > Sigh... Will this be the motivator for rpm-ostree to finally support Lua scriptlets[1]? [1]: https://github.com/projectatomic/rpm-ostree/issues/749 -- 真実はいつも一つ！/ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
On 3/7/19 5:52 PM, Florian Weimer wrote: * Panu Matilainen: On 3/7/19 1:13 PM, Florian Weimer wrote: * Richard W. M. Jones: $ sudo dnf install glibc-headers.i686 … Downgrading: That looks like a bug in itself. The last time I looked at something similar, I saw this: RPM would not adjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update or downgrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In the meantime, scriptlets run with the broken file system. In your case, maybe one of the scriptlet errors prevented the final step with the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.) IIRC the issue is that at when ldconfig runs from the package scripts, on downgrade the newer file is still on disk and thus ldconfig leaves the link the way it is, but at the end of transaction it'll be gone and symlinks can be broken. Is there a chance that RPM will be changed to run more scriptlets with the final disk contents? There's %transfiletriggerin, %transfiletriggerpostun and %posttrans that run after the entire transaction, and then the individual postun-type scripts/triggers. What is it that you're missing? $ rpm -q --filetriggers glibc-common transfiletriggerin scriptlet (using /bin/sh) -- /lib, /lib64, /usr/lib, /usr/lib64 /sbin/ldconfig transfiletriggerpostun scriptlet (using /bin/sh) -- /lib, /lib64, /usr/lib, /usr/lib64 /sbin/ldconfig The %transfiletriggerpostun would've probably fixed it if it used -p instead of shell. We switched to the shell for the benefit of rpm-ostree. Sigh... - Panu - ___ 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
