Schedule for Friday's FESCo Meeting (2019-06-07)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-06-07 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2141 Non-responsive maintainer: Frédéric Lepied (flepied) https://pagure.io/fesco/issue/2141 Packages will be retired and/or orphaned (+1, 0, 0) = Followups = #2063 F31 Change: Ibus-typing-booster default for Indian languages .fesco 2063 https://pagure.io/fesco/issue/2063 #2140 F31 System-Wide Change: RPM 4.15 .fesco 2140 https://pagure.io/fesco/issue/2140 #2139 F30: change default stream for avocado module .fesco 2139 https://pagure.io/fesco/issue/2139 #2135 set default module stream for cri-o .fesco 2135 https://pagure.io/fesco/issue/2135 = New business = #2136 F32 Self-Contained Change: Track Changes in Taiga .fesco 2136 https://pagure.io/fesco/issue/2136 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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: Intent to retire why
On Mon, Jun 3, 2019 at 12:24 PM Jerry James wrote: > Noted. I will probably get all these packages built on Wednesday or > Thursday of this week. If that turns out to be a bad time for you, please > let me know and I will postpone the builds. Regards, > I got about half of the builds done. Unfortunately, the alt-ergo build failed on 32-bit ARM with errors that I don't understand: https://koji.fedoraproject.org/koji/buildinfo?buildID=1280684 I ran the build twice just in case it was alpha particles at work, but sadly got the same result, namely lots of errors messages like this: /tmp/camlasm8765df.s: Assembler messages: /tmp/camlasm8765df.s:34184: Error: value of 00035170 too large for field of 2 bytes at ee3e /tmp/camlasm8765df.s:34186: Error: value of 0003356e too large for field of 2 bytes at ee42 /tmp/camlasm8765df.s:34188: Error: value of 0003356e too large for field of 2 bytes at ee46 ... That looks like a 32-bit issue, but the i386 build was successful, so I'm not sure what is going on here. This is with ocaml 4.07, of course, so there is some hope that 4.08 will fix the issue. If this really is due to a code error in alt-ergo, though, it will have to be addressed. Any hints much appreciated. -- Jerry James http://www.jamezone.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: Tagging commit hashes of Koji builds in dist-git
On Thu, Jun 6, 2019 at 3:08 PM Dennis Gilmore wrote: > > On Thu, Jun 6, 2019 at 7:11 AM Neal Gompa wrote: > > > > On Thu, Jun 6, 2019 at 7:53 AM Florian Weimer wrote: > > > > > > Is there a reason why we do not tag dist-git commits, using a name which > > > is derived from the NEVR from a Koji build? > > > > > > How well does Git scale with thousands of tags? > > > > > > > We used to back in the CVS days, because we needed it for plague. Koji > > blocks duplicate submissions anyway, so it stopped being needed when > > we transitioned to Git. > > it was not plague that needed it, using tags was the only way to > cjeckout the intended output, they had the problem that they were not > immutable, if you made a typo you forced in a new tag so you did not > need to bump the nvr > > > We're going to probably introduce it for some automation in the near > > future, though. > > > > Git is not great with thousands of any kind of refs, be it branches or > > tags. It still works, it's just things like 'git log' get kind of > > expensive. > > koji stores the git hash for all builds, writing a script to get the > hash for a given nvr would be trivial. it just means you have to be > online to retrieve the data than being able to get the date while > disconnected, if it was stored in git. Might be worth asking if there's a reason to need this offline. If the exact commit ID is stored in Koji and is authoritative, also tagging it into git might be convenient for offline purposes. The fact that it's not immutable is probably not an issue as long as the authoritative site *is*. (e.g. The same script that gets the hash from Koji could also detect if someone manually changed it in git, which would probably qualify as suspicious behavior.) ___ 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: Tagging commit hashes of Koji builds in dist-git
On Thu, Jun 6, 2019 at 7:11 AM Neal Gompa wrote: > > On Thu, Jun 6, 2019 at 7:53 AM Florian Weimer wrote: > > > > Is there a reason why we do not tag dist-git commits, using a name which > > is derived from the NEVR from a Koji build? > > > > How well does Git scale with thousands of tags? > > > > We used to back in the CVS days, because we needed it for plague. Koji > blocks duplicate submissions anyway, so it stopped being needed when > we transitioned to Git. it was not plague that needed it, using tags was the only way to cjeckout the intended output, they had the problem that they were not immutable, if you made a typo you forced in a new tag so you did not need to bump the nvr > We're going to probably introduce it for some automation in the near > future, though. > > Git is not great with thousands of any kind of refs, be it branches or > tags. It still works, it's just things like 'git log' get kind of > expensive. koji stores the git hash for all builds, writing a script to get the hash for a given nvr would be trivial. it just means you have to be online to retrieve the data than being able to get the date while disconnected, if it was stored in git. Dennis > > > -- > 真実はいつも一つ！/ 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 ___ 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: Tagging commit hashes of Koji builds in dist-git
* Thomas Moschny: > Am Do., 6. Juni 2019 um 14:12 Uhr schrieb Pierre-Yves Chibon > : >> >> On Thu, Jun 06, 2019 at 01:52:20PM +0200, Florian Weimer wrote: >> > Is there a reason why we do not tag dist-git commits, using a name which >> > is derived from the NEVR from a Koji build? >> >> One of the issue is that currently tags are not immutable, ei packagers could >> override them. > > Tags could be signed, and also pagure could reject removal of tags. > Immutability is a feature of the repository, not the tags themselves, > I think. Yes, I think you can have a Git hook which updates certain tag updates, just like you would reject branch updates. It probably makes sense to put the Koji tags into a separate namespace anyway, so filtering it by prefix string should be possible. (It would also stop people from pushing misleading tags that don't correspond to Koji builds, but look that way.) Tagging would have to happen upon successful completion of the build (for a failed build, the NVR can be reused), which is slightly annoying, but still better than having no tags at all, ever. 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
opencv 3.4.6 going to rawhide
Hi, I'd like also update opencv to 3.4.6 on stable branches but due possible ABI breakage [1]. We might should rebuild all dependent software . Personally I think we do not have to follow all the advice of dist.abicheck , opencv have a lot of stuff , if one symbol is removed , doesn't meant that ABI changed I'm using my copr repo [2] I also built and have prepared opencv.spec for 4.1 but breaks a lot of build of dependencies I read somewhere that RHEL 8 have opencv , what version ? Thanks, [1] dist.abicheck FAILED for opencv [2] https://copr.fedorainfracloud.org/coprs/sergiomb/opencv/builds/ -- Sérgio M. B. ___ 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: Tagging commit hashes of Koji builds in dist-git
Am Do., 6. Juni 2019 um 14:12 Uhr schrieb Pierre-Yves Chibon : > > On Thu, Jun 06, 2019 at 01:52:20PM +0200, Florian Weimer wrote: > > Is there a reason why we do not tag dist-git commits, using a name which > > is derived from the NEVR from a Koji build? > > One of the issue is that currently tags are not immutable, ei packagers could > override them. Tags could be signed, and also pagure could reject removal of tags. Immutability is a feature of the repository, not the tags themselves, I think. - Thomas ___ 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 voting is now open
On Thu, Jun 6, 2019 at 5:01 AM Miro Hrončok wrote: > > I remember readingsomething about podcast interviews. Are those available as > well, or was this not implemented after all? > Unfortunately, we ended up not having enough time to do this. For the next cycle, I'm going to work with x3mboy to see how we can give him more time to do those. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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 voting is now open
On Thu, Jun 6, 2019 at 1:55 AM Igor Gnatenko wrote: > > there is some misconfiguration in elections app. For FESCo elections, > it is written "Here are the candidates for the 1 seat(s) open:" while > there are 4 seats. > Fixed! This does not impact how votes are accepted or counted. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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: Tagging commit hashes of Koji builds in dist-git
On Thu, Jun 6, 2019 at 7:53 AM Florian Weimer wrote: > > Is there a reason why we do not tag dist-git commits, using a name which > is derived from the NEVR from a Koji build? > > How well does Git scale with thousands of tags? > We used to back in the CVS days, because we needed it for plague. Koji blocks duplicate submissions anyway, so it stopped being needed when we transitioned to Git. We're going to probably introduce it for some automation in the near future, though. Git is not great with thousands of any kind of refs, be it branches or tags. It still works, it's just things like 'git log' get kind of expensive. -- 真実はいつも一つ！/ 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: Tagging commit hashes of Koji builds in dist-git
On Thu, Jun 06, 2019 at 01:52:20PM +0200, Florian Weimer wrote: > Is there a reason why we do not tag dist-git commits, using a name which > is derived from the NEVR from a Koji build? One of the issue is that currently tags are not immutable, ei packagers could override them. Pierre ___ 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: Tagging commit hashes of Koji builds in dist-git
We actually talked about this on oSC19 with Neal Gompa and Florian Festi. And we'd need it for automation we are planning to work on... Then I spoke to pingou and he told me that tags are easy to delete and you need some special hook to prevent that... I did not have time to look at it though. On Thu, Jun 6, 2019 at 2:02 PM Florian Weimer wrote: > > Is there a reason why we do not tag dist-git commits, using a name which > is derived from the NEVR from a Koji build? > > How well does Git scale with thousands of tags? > > 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 ___ 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
Tagging commit hashes of Koji builds in dist-git
Is there a reason why we do not tag dist-git commits, using a name which is derived from the NEVR from a Koji build? How well does Git scale with thousands of tags? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: what to do when original upstream recover from death?
On 06. 06. 19 12:55, Petr Stodulka wrote: Hi guys, I have one curious question about the current situation around git-remote-hg. To put you into the context, the solution was originally part of the git upstream itself and several years ago has been split into the own upstream [0]. After a time, the upstream[0] did last commit in Sep27 2016 and since the date Jan 24 2018 the account has been no active till this april. After a long time has been started discussion about change to new upstream [1] which was active and responding. Nowadays, this "new upstream" provides the git-remote-hg in pypi and it is marked by Github as "source-repo" - the original one [0] is marked as clone nowadays by Github. I decided to switched into the upstream [1] on Aug 20 2018 from that point as did several other projects. But several days ago the original upstream has started to be active again. I guess that guys will make an agreement to setup the original upstream back to [0], but currently it looks that original upstream[0] do not care about the releases of new upstream that has been done meanwhile and probably will continue with own versioning. I am trying to discuss that to not have mix of same versions for different code. Not sure whether I will be successful from that point. I expect that we will have to move back to the original upstream[0] anyway in Fedora, and in such case probably I will have to raise epoch in case of discontinuation in current versioning. My question is, do you have any related experience to the topic? I already had some exprience with death upstreams, but this is really new to me. As well, I am curious whether I did mistake when I switched to the upstream[1] regarding the situation there was about the project. It's always a tough decision to make. It was not a mistake, you could not have known. I recommend the following: 1. make the upstreams talk to each other 2. make the upstreams talk to each other 3. make the upstreams talk to each other 4. if the above fails, pick the once that would benefit the most users 5. but keep an eye on the other one in case it changes (but don't switch there and back every month) 6. make the upstreams talk to each other Hope that helps. -- 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 to do when original upstream recover from death?
Hi guys, I have one curious question about the current situation around git-remote-hg. To put you into the context, the solution was originally part of the git upstream itself and several years ago has been split into the own upstream [0]. After a time, the upstream[0] did last commit in Sep27 2016 and since the date Jan 24 2018 the account has been no active till this april. After a long time has been started discussion about change to new upstream [1] which was active and responding. Nowadays, this "new upstream" provides the git-remote-hg in pypi and it is marked by Github as "source-repo" - the original one [0] is marked as clone nowadays by Github. I decided to switched into the upstream [1] on Aug 20 2018 from that point as did several other projects. But several days ago the original upstream has started to be active again. I guess that guys will make an agreement to setup the original upstream back to [0], but currently it looks that original upstream[0] do not care about the releases of new upstream that has been done meanwhile and probably will continue with own versioning. I am trying to discuss that to not have mix of same versions for different code. Not sure whether I will be successful from that point. I expect that we will have to move back to the original upstream[0] anyway in Fedora, and in such case probably I will have to raise epoch in case of discontinuation in current versioning. My question is, do you have any related experience to the topic? I already had some exprience with death upstreams, but this is really new to me. As well, I am curious whether I did mistake when I switched to the upstream[1] regarding the situation there was about the project. Thanks for sharing your ideas, [0] https://github.com/felipec/git-remote-hg [1] https://github.com/mnauw/git-remote-hg -- Petr Stodulka OS & Application Modernization IRC nicks: pstodulk, skytak Software Engineer Red Hat Czech s.r.o. 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: LiveOS installs, /dev/loop1 100% CPU
On Wed, Jun 05, 2019 at 10:48:32PM -0600, Chris Murphy wrote: > I've filed a bug about this, but I'm not sure what else to test or add > to demonstrate where the problem is coming from. It's some combination > of squashfs + ext4 overhead I'm guessing, but then also the perf > report output on the pid for loop1 shows lzma is the top consumer by a > long shot. > > So it seems like xz has a considerable performance/resource impact here as > well. Yep, that's reasonable. E.g. on my machine, decompressing code compressed with xz -2 reads the compressed data at ~13MB/s. If the part of the live CD that needs to be read to boot to a graphical environment is on the order of 1GB, just decompressing that is going to take more than a minute of CPU. > https://bugzilla.redhat.com/show_bug.cgi?id=1717728 Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: wpa supplicant using /dev/random
On Wed, 2019-06-05 at 16:38 -0600, Chris Murphy wrote: > Jun 05 15:53:25 fmac.local kernel: random: crng init done > Jun 05 15:53:25 fmac.local kernel: random: 7 urandom warning(s) > missed > due to ratelimiting > Jun 05 15:53:25 fmac.local wpa_supplicant[1000]: random: Cannot read > from /dev/random: Resource temporarily unavailable > Jun 05 15:53:25 fmac.local wpa_supplicant[1000]: random: Got 20/20 > bytes from /dev/random > > > Is this a bug? Should it be using /dev/urandom instead? That's clearly a bug. It should just use OpenSSL which it links to anyway to get random numbers. OpenSSL uses getrandom() to get entropy from the kernel to seed its RNG. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ 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 voting is now open
On 06. 06. 19 2:03, Ben Cotton wrote: Voting is now open for the Fedora 30 election cycle. You can vote in the Elections app[1]. Interviews with candidates are available on the Fedora Community Blog[2], with links available in the Elections app. Voting ends at 23:59 UTC on 20 June. I remember readingsomething about podcast interviews. Are those available as well, or was this not implemented after all? [1] https://elections.fedoraproject.org [2] https://communityblog.fedoraproject.org/?p=7774 -- 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
