[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c1577dae55 singularity-3.1.1-1.1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-2f5f6c5ba9 libmediainfo-19.04-1.el6 mediainfo-19.04-1.el6 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-612bab5fc3 drupal7-7.67-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing drupal7-entity-1.9-1.el6 php-webmozart-assert-1.4.0-1.el6 zchunk-1.1.2-2.el6 Details about builds: drupal7-entity-1.9-1.el6 (FEDORA-EPEL-2019-5ff064965f) Extends the entity API to provide a unified way to deal with entities Update Information: - https://www.drupal.org/project/entity/releases/7.x-1.9 - https://www.drupal.org/sa-contrib-2018-013 ChangeLog: * Sun May 19 2019 Shawn Iwinski - 1.9-1 - Update to 1.9 (RHBZ #1545456) - https://www.drupal.org/project/entity/releases/7.x-1.9 - https://www.drupal.org/sa-contrib-2018-013 * Thu Jan 31 2019 Fedora Release Engineering - 1.8-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Jul 12 2018 Fedora Release Engineering - 1.8-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Wed Feb 7 2018 Fedora Release Engineering - 1.8-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 1.8-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Fri Feb 10 2017 Fedora Release Engineering - 1.8-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild References: [ 1 ] Bug #1545456 - drupal7-entity-1.9 is available https://bugzilla.redhat.com/show_bug.cgi?id=1545456 php-webmozart-assert-1.4.0-1.el6 (FEDORA-EPEL-2019-0ccbfb4996) Assertions to validate method input/output with nice error messages Update Information: ## 1.4.0 (2018-12-25) ### Added * added `Assert::ip()` * added `Assert::ipv4()` * added `Assert::ipv6()` * added `Assert::notRegex()` * added `Assert::interfaceExists()` * added `Assert::isList()` * added `Assert::isMap()` * added polyfill for ctype ### Fixed * Special case when comparing objects implementing `__toString()` ChangeLog: * Sun May 19 2019 Shawn Iwinski - 1.4.0-1 - Update to 1.4.0 * Sat Feb 2 2019 Fedora Release Engineering - 1.3.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Oct 19 2018 Remi Collet - 1.3.0-3 - fix autoloader, use PSR-4 to avoid duplicated definition - prepend autoloader to ensure we use current version in tests - fix FTBFS #1605449 * Fri Oct 19 2018 Remi Collet - 1.3.0-2 - fix autoloader, use PSR-4 to avoid duplicated definition - prepend autoloader to ensure we use current version in tests - fix FTBFS #1605449 - bootstrap build * Fri Jul 13 2018 Fedora Release Engineering - 1.3.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild zchunk-1.1.2-2.el6 (FEDORA-EPEL-2019-4a2b8de42e) Compressed file format that allows easy deltas Update Information: Fix multipart range handling to work with quotes, allowing zchunk downloads to work through proxies that wrap their ranges in quotes. ChangeLog: * Sun May 19 2019 Jonathan Dieter - 1.1.2-2 - Fix multipart range handling to work with quotes, fixes #1706627 - Fix file creation permissions so they respect umask - Actually push new sources * Tue Apr 16 2019 Adam Williamson - 1.1.1-3 - Rebuild with Meson fix for #1699099 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-05-20 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/20/report-389-ds-base-1.4.1.2-20190519git31c89d3.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
On Sun, May 19, 2019 at 3:28 PM Kevin Fenzi wrote: > > On 5/19/19 10:53 AM, Nico Kadel-Garcia wrote: > > On Sun, May 19, 2019 at 12:14 PM Kevin Fenzi wrote: > >> In cloud-init land, the user can set a password by using their "sudo" > > privileges, and can set it for the "root" user and for the "ec2puser" > > or other cloud user. I don't think that Fedora should try to outsmart > > all the different use cased cases for cloud deployment by selecting > > sshd_config. > > Sure, I wasn't suggesting we change the cloud case by messing with > sshd_config. I was suggesting we stop making a 'fedora' non-root user, +1 > but I guess I should just go back to grumbling and repoint the thread to > the topic at hand. +1 :) > > > ...snip... ___ 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: Attempting to contact unresponsive maintainers: dkaspar flaper87
Please feel free to set default dstat BZ assignment to me in this case, Kevin. On Tue, May 14, 2019 at 5:21 PM Lukas Nykryn wrote: > > Hi, > sorry for late answer I was on PTO, > > David no longer works in Red HAt and he is not interested in maintaining > those packages anymore. > Could you please set the main admin of initscripts to me? And I don't think > we are interested in the rest of those packages. > > Lukas > > út 7. 5. 2019 v 23:18 odesílatel Kevin Fenzi napsal: >> >> I'd like to appologize for the delay in this email. >> >> The notices I get were being filtered and I didn't realize I wasn't >> seeing them for a while. ;( >> >> >> We've been told that the email addresses for these package maintainers >> are no longer valid. I'm starting the unresponsive maintainer policy to >> find out if they are still interested in maintaining their packages (and >> if so, have them update their email addresses in FAS). >> >> If they're not interested in maintaining or we can't locate them in 1 >> week, I'll have FESCo orphan the packages so that others can take them >> over. >> >> If you have a way to contact these maintainers, please let them know >> that we'd appreciate knowing what to do with their packages. Thanks! >> >> dkaspar: >> >> "dstat": "dkaspar", >> "initscripts": "dkaspar", >> "mtools": "dkaspar", >> "tcsh": "dkaspar", >> >> flaper87: >> >> "redis": "flaper87", >> >> >> Thanks, >> >> 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 ___ 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
Planned Outage - Fedora Staging Services 2019-05-20 21:00 UTC
There will be an outage starting at 2019-05-20 21:00 UTC , which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2019-05-20 21:00UTC' Reason for outage: There have been a number of kernel and low level library updates which require a system reboot to put into place. We will be rebooting staging and several non-PHX2 servers which do not require a full outage due to redundancy or low service level expectations. Affected Services: *.stg.fedoraproject.org *.stg.phx2.fedoraproject.org osuosl02.fedoraproject.org pagure-stg01.fedoraproject.org osuosl02.fedoraproject.org proxy09.fedoraproject.org osuosl02.fedoraproject.org smtp-mm-osuosl01.fedoraproject.org osuosl02.fedoraproject.org unbound-osuosl01.fedoraproject.org Ticket Link: https://pagure.io/fedora-infrastructure/issue/7808 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Planned Outage - Fedora Proxies and Remote Servers Updates/Reboots - 2019-05-21 21:00 UTC
There will be an outage starting at 2019-05-21 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2019-05-21 21:00UTC' Reason for outage: We have come to chew gum and reboot servers, and we have all run out of gum. There have been a number of kernel and low level library updates which require a system reboot to put into place. We will be rebooting staging and non-PHX2 servers which do not require a full outage due to redundancy or low service level expectations. Affected Services: proxy05.fedoraproject.org coloamer01.fedoraproject.org:proxy08.fedoraproject.org:running:1 dedicatedsolutions01.fedoraproject.org:proxy11.fedoraproject.org:running:1 ibiblio01.fedoraproject.org:download-ib01.fedoraproject.org:running:1 ibiblio01.fedoraproject.org:noc02.fedoraproject.org:running:1 ibiblio01.fedoraproject.org:pagure-proxy01.fedoraproject.org:running:1 ibiblio01.fedoraproject.org:proxy04.fedoraproject.org:running:1 ibiblio05.fedoraproject.org:ns02.fedoraproject.org:running:1 ibiblio05.fedoraproject.org:people02.fedoraproject.org:running:1 ibiblio05.fedoraproject.org:proxy12.fedoraproject.org:running:1 ibiblio05.fedoraproject.org:smtp-mm-ib01.fedoraproject.org:running:1 ibiblio05.fedoraproject.org:torrent02.fedoraproject.org:running:1 ibiblio05.fedoraproject.org:unbound-ib01.fedoraproject.org:running:1 internetx01.fedoraproject.org:ns05.fedoraproject.org:running:1 internetx01.fedoraproject.org:proxy02.fedoraproject.org:running:1 osuosl01.fedoraproject.org:pagure01.fedoraproject.org:running:1 osuosl01.fedoraproject.org:proxy06.fedoraproject.org:running:1 osuosl01.fedoraproject.org:repospanner-osuosl01.fedoraproject.org:running:1 osuosl02.fedoraproject.org:keys01.fedoraproject.org:running:1 osuosl02.fedoraproject.org:pagure-stg01.fedoraproject.org:running:1 osuosl02.fedoraproject.org:proxy09.fedoraproject.org:running:1 osuosl02.fedoraproject.org:smtp-mm-osuosl01.fedoraproject.org:running:1 osuosl02.fedoraproject.org:unbound-osuosl01.fedoraproject.org:running:1 virthost-cc-rdu01.fedoraproject.org:ci-cc-rdu01.fedoraproject.org:running:1 virthost-cc-rdu01.fedoraproject.org:proxy14.fedoraproject.org:running:1 virthost-cc-rdu01.fedoraproject.org:smtp-mm-cc-rdu01.fedoraproject.org:running:1 virthost-cc-rdu02.fedoraproject.org:infinote.fedoraproject.org:running:1 virthost-cc-rdu02.fedoraproject.org:proxy03.fedoraproject.org:running:1 virthost-cc-rdu02.fedoraproject.org:repospanner-cc-rdu01.fedoraproject.org:running:1 virthost-cc-rdu02.fedoraproject.org:unbound-cc-rdu01.fedoraproject.org:running:1 virthost-cc-rdu03.fedoraproject.org:download-cc-rdu01.fedoraproject.org:running:1 virthost-cc-rdu03.fedoraproject.org:ipv6-test.fedoraproject.org:running:1 virthost-rdu01.fedoraproject.org:bastion13.fedoraproject.org:running:1 virthost-rdu01.fedoraproject.org:batcave13.rdu2.fedoraproject.org:running:1 virthost-rdu01.fedoraproject.org:ns13.rdu2.fedoraproject.org:running:1 virthost-rdu01.fedoraproject.org:proxy13.fedoraproject.org:running:1 data-analysis01.phx2.fedoraproject.org dl.fedoraproject.org (service has multiple front ends so outages should be short per) Ticket Link: https://pagure.io/fedora-infrastructure/issue/7809 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Planned Outage - Fedora Core Services 2019-04-10 21:00 UTC
There will be an outage starting at 2019-04-10 21:00 UTC , which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2019-04-10 21:00UTC' Reason for outage: There have been a number of kernel and low level library updates which require a system reboot to put into place. We will be rebooting productions servers which do require a full outage and downtime. Affected Services: koji.fedoraproject.org src.fedoraproject.org *.phx2.fedoraproject.org Ticket Link: https://pagure.io/fedora-infrastructure/issue/7810 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1711712] perl-Mojolicious-8.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1711712 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mojolicious-8.16-1.fc3 ||1 Resolution|--- |RAWHIDE Last Closed||2019-05-19 22:40:18 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1269152 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1711712] New: perl-Mojolicious-8.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1711712 Bug ID: 1711712 Summary: perl-Mojolicious-8.16 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com, yan...@declera.com Target Milestone: --- Classification: Fedora Latest upstream release: 8.16 Current version/release in rawhide: 8.15-1.fc31 URL: https://metacpan.org/release/Mojolicious Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5966/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: orphaning bleachbit
On 5/19/19 1:58 PM, Andrew Toskin wrote: >> I'm already a packager, and I'd be willing to take over BleachBit. This way >> you >> don't have to wait for Silvia to learn the ropes before handing off control. > Oops, I'm used to having my email client do the signature for me, but I > responded here in HyperKitty... > > Name: Andrew Toskin > FAS: terrycloth Thanks. I have transferred the package over to you and removed myself. 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: packaging bootstrap example, ideally with golang
On Sunday, 19 May 2019 16:44:16 CEST Brian (bex) Exelbierd wrote: > On Sun, May 19, 2019 at 2:23 PM Robert-André Mauchin > wrote: > > > > > > Hello, > > > > > > > > golang(github.com/jacobsa/ogletest) is only needed for tests by oglemock. > > So you just need to bootstrap oglemock with tests disabled then build > > ogletest then rebuild oglemock unboostrapped. > > > Thank you for the quick reply! > > This makes sense, and I had a feeling this would be the case. > > I appreciate the spec files you sent in your second email. > > I am not seeing a document that explains how I submit the entire app > for build/update. > > I know I can do `fedpkg build` in the various repos, but how do I get > them to all see each other? in other words, I need oglemock to be > built without tests, build ogletest, then rebuild oglemock and then > build the other dependencies then build the actual app and have this > happen when they all have access to the various dependent files. I > have not had to package something this complex before. > > I don't see a section in the Packaging guide that addresses the > command sequence for this. Perhaps it is buried in the wiki on a page > that isn't obvious to me? > > Can you point me at a document? Not sure I understand the problem. You build each package independently as usual, doing `fedpkg build` in each repo. Once the package is build in Rawhide, it is available to others (might have a delay up to 20mn). For the bootstrap, you just switch for bcond_without to bcond_with bootstrap, then commit and rebuild. No need to bump the Release, we have ~bootstrap autodetected for Release. If you build in branched, you do fedpkg build fedpkg update Then do a buildroot override so that the build is available to other: fedpkg override create --duration 15 --notes "Buildroot override for X" Then wait repo for the build: koji wait-repo f30-build --build=foo-1.1.1-1.fc30 And then continue with your next builds > > I am assuming I can just submit the package and all dependencies in > teh same BZ for review so I am more thinking about the build stage. > No. 1 package = 1 review. You'll need a Review Request for each deps. ___ 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 31 System-Wide Change proposal: Disable Root Password Login in SSH
On 5/19/19 10:53 AM, Nico Kadel-Garcia wrote: > On Sun, May 19, 2019 at 12:14 PM Kevin Fenzi wrote: >> In cloud-init land, the user can set a password by using their "sudo" > privileges, and can set it for the "root" user and for the "ec2puser" > or other cloud user. I don't think that Fedora should try to outsmart > all the different use cased cases for cloud deployment by selecting > sshd_config. Sure, I wasn't suggesting we change the cloud case by messing with sshd_config. I was suggesting we stop making a 'fedora' non-root user, but I guess I should just go back to grumbling and repoint the thread to the topic at hand. > ...snip... >> As noted, the cloud-init case has no passwords, only keys. > > You forgot "ec2puser". let me rephrase: By default out of the box, our Fedora Cloud images have no passwords, only keys for access. You can of course change this after the fact in any number of ways. >> If I am using ssh keys, I don't care about people trying to brute force >> passwords. Forcing the root account closed and having to use a 'user' >> account to login and sudo just seems like a pointless hoop. > > It provides tracking of which user's credentials have been abused. No it does not. Once the abuser logs in and does sudo to root, all local tracking is now useless and suspect. The abuser can erase/tamper/change any logs you might look at later. By default there's no remote logging or the like in Fedora Cloud. >> root account with key -> login as root with key >> user account with key / root locked -> login as user, sudo >> >> Thats another shell running, another sudo process, etc. > > Yes, and for precisely the reasons above. Which reasons? I'm afraid I still don't see anything compelling. Anyhow, sorry for hyjacking the thread away from the topic to cloud-init. :( I'll stop now. :) 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: packaging bootstrap example, ideally with golang
On 19. 05. 19 16:44, Brian (bex) Exelbierd wrote: On Sun, May 19, 2019 at 2:23 PM Robert-André Mauchin wrote: Hello, golang(github.com/jacobsa/ogletest) is only needed for tests by oglemock. So you just need to bootstrap oglemock with tests disabled then build ogletest then rebuild oglemock unboostrapped. Thank you for the quick reply! This makes sense, and I had a feeling this would be the case. I appreciate the spec files you sent in your second email. I am not seeing a document that explains how I submit the entire app for build/update. I know I can do `fedpkg build` in the various repos, but how do I get them to all see each other? You do build + wait + build + wait + build. Use this for waiting: $ koji wait-repo f31-build --build=foo-1.1.1-1.fc31 -- 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: Licence tag in spec files for final binaries or initial source code?
On Sun, May 19, 2019 at 11:26 AM Felix Schwarz wrote: > > > Am 19.05.19 um 17:23 schrieb Yaakov Selkowitz: > > Based on your example, yes: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ > > > > "The License: field refers to the licenses of the contents of the > > *binary* rpm." > > Thank you - somehow I missed that part. > > Felix Shouldn't that depend on the license? The source code is normally contained in the SRPM. Would it make sense to segregate that source code into a different package with a distinct license, if possible? ___ 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 bleachbit
> I'm already a packager, and I'd be willing to take over BleachBit. This way > you > don't have to wait for Silvia to learn the ropes before handing off control. Oops, I'm used to having my email client do the signature for me, but I responded here in HyperKitty... Name: Andrew Toskin FAS: terrycloth ___ 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 bleachbit
> I intend to orphan bleachbit soon. If anyone is interested please let me > know and I will transfer the package. > > https://src.fedoraproject.org/rpms/bleachbit > > Mukundan. I'm already a packager, and I'd be willing to take over BleachBit. This way you don't have to wait for Silvia to learn the ropes before handing off control. ___ 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 31 System-Wide Change proposal: Disable Root Password Login in SSH
On Sun, May 19, 2019 at 12:14 PM Kevin Fenzi wrote: > > On 5/19/19 8:48 AM, Christopher wrote: > > On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi wrote: > >> > >> On 5/17/19 5:23 AM, Stephen Gallagher wrote: > >> > >> ...snip... > >> > >>> 3) Force Anaconda to require the creation of a non-root user that is a > >>> member of the `wheel` group, so that this user can be used to SSH in > >>> and administer the system. Essentially, remove the root user creation > >>> spoke as an option from the interactive install. > >> > >> So, this is basically the old cloud-init makes a user that can sudo to > >> root thing. Can anyone explain in small words how this is more secure? > >> > > > > If you've ever examined your audit logs for failed authentications, > > you'll notice the difference is substantial. The root user is under > > non-stop attack over ssh, by countless bots and malicious users. Other > > users are not so frequently targeted. The attack surface is > > dramatically reduced when disabling access for the the root user over > > ssh, and replacing that with a different user. This is not perfect > > security, but it reduces the attack surface that can be automatically > > targeted by automated attack tools. > > I guess this is not the old cloud-init thing, since the proposed action > here leaves the non-root user with a password. In cloud-init land, > there's no passwords, the non-root user has a key. In that case I cannot > see any difference between root having a key and the non-root user > having a key and being able to sudo to root. In cloud-init land, the user can set a password by using their "sudo" privileges, and can set it for the "root" user and for the "ec2puser" or other cloud user. I don't think that Fedora should try to outsmart all the different use cased cases for cloud deployment by selecting sshd_config. > One objection to this proposal last time this came up was that the > device was going to join a ipa domain or the like, and a local non-root > user was not desired. I suppose in that case they could delete the user > after the initial setup. Yup, along with /etc/ssh/ssh_config, /etc/ssh/ssshd_config, and $HOME/.ssh/config, and the way cloud-init blocks direct root SSH logins, by manipulationg $HOME/.ssh/authorized_keys. There are too many options to try and outsmart them via sshd_config policy. > Sure, and it can also not make one and leave root, but in practice I > don't know too many people that do this. If you looked for 'fedora', > 'centos' and 'rhel' and 'ubuntu' you would get most of them. > > As noted, the cloud-init case has no passwords, only keys. You forgot "ec2puser". > If I am using ssh keys, I don't care about people trying to brute force > passwords. Forcing the root account closed and having to use a 'user' > account to login and sudo just seems like a pointless hoop. It provides tracking of which user's credentials have been abused. > root account with key -> login as root with key > user account with key / root locked -> login as user, sudo > > Thats another shell running, another sudo process, etc. Yes, and for precisely the reasons above. > Anyhow, thats not this case, so I should move along. > > At this point I think I am ok with the change, but I would really like > to hear from some folks that didn't like it the last time it was > proposed to see if we missed any cases. > > kevin That seems a very thoughtful suggestion. ___ 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 31 System-Wide Change proposal: Disable Root Password Login in SSH
On 5/19/19 8:48 AM, Christopher wrote: > On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi wrote: >> >> On 5/17/19 5:23 AM, Stephen Gallagher wrote: >> >> ...snip... >> >>> 3) Force Anaconda to require the creation of a non-root user that is a >>> member of the `wheel` group, so that this user can be used to SSH in >>> and administer the system. Essentially, remove the root user creation >>> spoke as an option from the interactive install. >> >> So, this is basically the old cloud-init makes a user that can sudo to >> root thing. Can anyone explain in small words how this is more secure? >> > > If you've ever examined your audit logs for failed authentications, > you'll notice the difference is substantial. The root user is under > non-stop attack over ssh, by countless bots and malicious users. Other > users are not so frequently targeted. The attack surface is > dramatically reduced when disabling access for the the root user over > ssh, and replacing that with a different user. This is not perfect > security, but it reduces the attack surface that can be automatically > targeted by automated attack tools. I guess this is not the old cloud-init thing, since the proposed action here leaves the non-root user with a password. In cloud-init land, there's no passwords, the non-root user has a key. In that case I cannot see any difference between root having a key and the non-root user having a key and being able to sudo to root. One objection to this proposal last time this came up was that the device was going to join a ipa domain or the like, and a local non-root user was not desired. I suppose in that case they could delete the user after the initial setup. > >> I mean, in this case the attacker would need to guess the username in >> addition to the password (where in the cloud cause this is known), but >> otherwise why not just keep root password access ? >> > > The other user is not necessarily known, even in the cloud case. At > least on Amazon EC2, cloud-init can be used to parse user-data passed > in to add a user dynamically at launch time, rather than have the > default user well-known in the cloud image. Sure, and it can also not make one and leave root, but in practice I don't know too many people that do this. If you looked for 'fedora', 'centos' and 'rhel' and 'ubuntu' you would get most of them. As noted, the cloud-init case has no passwords, only keys. > >> I always found that cloud default anoying and useless and haven't yet >> seen a good argument to not do it. > > Cloud default users are, from my limited experience on AWS and looking > at my own audit logs, are nearly as often targeted by attackers as the > root user. So, I find these defaults annoying, too. The secure > position shouldn't be to admit defeat and leave password-based login > for the root user open on SSH... the secure position should be to > immediately create a new user during setup (either via kickstart, > anaconda, or cloud-init) that isn't a built-in default user (either > built-in to the OS, as "root" is, or built-in to the cloud image, as > "fedora" and "centos", etc. users are). If I am using ssh keys, I don't care about people trying to brute force passwords. Forcing the root account closed and having to use a 'user' account to login and sudo just seems like a pointless hoop. root account with key -> login as root with key user account with key / root locked -> login as user, sudo Thats another shell running, another sudo process, etc. Anyhow, thats not this case, so I should move along. At this point I think I am ok with the change, but I would really like to hear from some folks that didn't like it the last time it was proposed to see if we missed any cases. 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
[Bug 1711566] perl-YAML-LibYAML-0.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1711566 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-YAML-LibYAML-0.78-1.fc ||31 Resolution|--- |RAWHIDE Assignee|jples...@redhat.com |p...@city-fan.org Last Closed||2019-05-19 16:11:33 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=34934498 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH
On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi wrote: > > On 5/17/19 5:23 AM, Stephen Gallagher wrote: > > ...snip... > > > 3) Force Anaconda to require the creation of a non-root user that is a > > member of the `wheel` group, so that this user can be used to SSH in > > and administer the system. Essentially, remove the root user creation > > spoke as an option from the interactive install. > > So, this is basically the old cloud-init makes a user that can sudo to > root thing. Can anyone explain in small words how this is more secure? > If you've ever examined your audit logs for failed authentications, you'll notice the difference is substantial. The root user is under non-stop attack over ssh, by countless bots and malicious users. Other users are not so frequently targeted. The attack surface is dramatically reduced when disabling access for the the root user over ssh, and replacing that with a different user. This is not perfect security, but it reduces the attack surface that can be automatically targeted by automated attack tools. > I mean, in this case the attacker would need to guess the username in > addition to the password (where in the cloud cause this is known), but > otherwise why not just keep root password access ? > The other user is not necessarily known, even in the cloud case. At least on Amazon EC2, cloud-init can be used to parse user-data passed in to add a user dynamically at launch time, rather than have the default user well-known in the cloud image. > I always found that cloud default anoying and useless and haven't yet > seen a good argument to not do it. Cloud default users are, from my limited experience on AWS and looking at my own audit logs, are nearly as often targeted by attackers as the root user. So, I find these defaults annoying, too. The secure position shouldn't be to admit defeat and leave password-based login for the root user open on SSH... the secure position should be to immediately create a new user during setup (either via kickstart, anaconda, or cloud-init) that isn't a built-in default user (either built-in to the OS, as "root" is, or built-in to the cloud image, as "fedora" and "centos", etc. users are). > > 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
Re: Licence tag in spec files for final binaries or initial source code?
Am 19.05.19 um 17:23 schrieb Yaakov Selkowitz: > Based on your example, yes: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ > > "The License: field refers to the licenses of the contents of the > *binary* rpm." Thank you - somehow I missed that part. Felix ___ 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
[EPEL-devel] Re: EPEL 7 in RHEL 8
On Sat, 18 May 2019 at 19:58, Kevin Fenzi wrote: > On 5/18/19 12:58 AM, TG Servers wrote: > > Hi, > > > > as RHEL 8 was released it was clear to us that due to the new > > infrastructure requirements there will be some more work to do for EPEL > > 8 to be released. > > Iirc form reading your plans it will be at least 8-10 weeks until there > > will be an EPEL 8, unclear if it is really stable at that point. > > Right. > > > Is there anything, aside from older versions, which holds one back from > > using EPEL 7 for the time being with RHEL 8 in production? > > We don't really need that much from EPEL directly but are using repos in > > production which depend on EPEL. > > Or is this considered that unsafe we have to wait until EPEL 8 is done? > > I don't think it would have any chance of working. The libraries in > rhel8 are completely different from rhel7. I don't think any epel7 rpms > will install, and if they do, I doubt they would work at all. > > I tried this at one point during the beta. Yes you can get some things to install. Very few of them worked. If you are needing applications to work on RHEL-8, your best bet to get things to install will be Fedora-28. Many of these packages will install without problems and mostly work. [There are of course some ABI differences which rpm can't determine but you may find.] > kevin > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Licence tag in spec files for final binaries or initial source code?
On Sun, 2019-05-19 at 17:15 +0200, Felix Schwarz wrote: > I have a question regarding license tags in spec files for software under > multiple licenses (bundled libraries): > - The main software is licensed under a 3-clause BSD. > - The software bundles a library under ASL 2 in subfolder /foo > > As far as I know the correct license tag for the Fedora package is > License:BSD and ASL 2.0 > > If I do > rm -rf <...>/foo > in %prep the ASL-licensed code is never executed, compiled and not present in > the final binary. Can I change the license tag to "BSD" in that case? Based on your example, yes: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ "The License: field refers to the licenses of the contents of the *binary* rpm." > (I could also clean the source code before importing it for Fedora but I like > using unmodified upstream archives.) That is only necessary when the sources contain legally encumbered code, which doesn't sound like the case here. -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Licence tag in spec files for final binaries or initial source code?
I have a question regarding license tags in spec files for software under multiple licenses (bundled libraries): - The main software is licensed under a 3-clause BSD. - The software bundles a library under ASL 2 in subfolder /foo As far as I know the correct license tag for the Fedora package is License:BSD and ASL 2.0 If I do rm -rf <...>/foo in %prep the ASL-licensed code is never executed, compiled and not present in the final binary. Can I change the license tag to "BSD" in that case? (I could also clean the source code before importing it for Fedora but I like using unmodified upstream archives.) Felix ___ 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 bootstrap example, ideally with golang
On Sun, May 19, 2019 at 2:23 PM Robert-André Mauchin wrote: > > Hello, > > golang(github.com/jacobsa/ogletest) is only needed for tests by oglemock. So > you just need to bootstrap oglemock with tests disabled then build ogletest > then rebuild oglemock unboostrapped. Thank you for the quick reply! This makes sense, and I had a feeling this would be the case. I appreciate the spec files you sent in your second email. I am not seeing a document that explains how I submit the entire app for build/update. I know I can do `fedpkg build` in the various repos, but how do I get them to all see each other? in other words, I need oglemock to be built without tests, build ogletest, then rebuild oglemock and then build the other dependencies then build the actual app and have this happen when they all have access to the various dependent files. I have not had to package something this complex before. I don't see a section in the Packaging guide that addresses the command sequence for this. Perhaps it is buried in the wiki on a page that isn't obvious to me? Can you point me at a document? I am assuming I can just submit the package and all dependencies in teh same BZ for review so I am more thinking about the build stage. thanks, bx > > In the new macros we will have easier tools to deal with more complex cyclic > dependencies, see my guide: https://eclipseo.fedorapeople.org/guidelines/ > packaging-guidelines/Golang_advanced/#_dealing_with_cyclic_dependencies > > ___ > 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 -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: orphaning bleachbit
On 5/19/19 5:05 AM, Silvia Sánchez wrote: > > Hello, > > Yes, I know Python 2 will be soon removed, but I can't just let > Bleachbit die. It's too useful for that. > Finding a sponsor seems to be the hard bit. I've been looking for one > for ages. > Thanks for the answer. > > Kind regards, > Silvia > FAS: Lailah > > Silvia, I am a sponsor. Can you provide me a list of packages you have reviewed? I can probably help you becoming a packager. 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: Where are armv7hl, i686 and ppc64le Container tar.xz files?
I am suggesting a new feature "podman buildx" like "docker buildx" that makes a better multi arch build experience. See below URL if you are interested in it. Supporting building multi-platform images (podman buildx) https://github.com/containers/buildah/issues/1590 -- Jun Aruga / He - His - Him ___ 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 bootstrap example, ideally with golang
I'm attaching the two SPEC for ogle{mock,test}# Generated by go2rpm
%bcond_without check
# https://github.com/jacobsa/ogletest
%global goipath github.com/jacobsa/ogletest
%global commit 80d50a735a1108a2aeb7abc4a988d183f20c5292
%gometa
%global common_description %{expand:
Ogletest is a unit testing framework for Go with the following features:
- An extensive and extensible set of matchers for expressing expectations.
- Automatic failure messages; no need to say t.Errorf("Expected %v, got %v"...)
- Clean, readable output that tells you exactly what you need to know.
- Built-in support for mocking through the oglemock package.
- Style and semantics similar to Google Test and Google JS Test.
It integrates with Go's built-in testing package, so it works with the go test
command, and even with other types of test within your package. Unlike the
testing package which offers only basic capabilities for signalling failures, it
offers ways to express expectations and get nice failure messages
automatically.}
Name: %{goname}
Version:0
Release:0.1%{?dist}
Summary:Go unit testing framework
# Upstream license specification: Apache-2.0
License:ASL 2.0
URL:%{gourl}
Source0:%{gosource}
BuildRequires: golang(github.com/jacobsa/oglematchers)
BuildRequires: golang(github.com/jacobsa/oglemock)
BuildRequires: golang(github.com/jacobsa/reqtrace)
BuildRequires: golang(golang.org/x/net/context)
%description
%{common_description}
%package devel
Summary: %{summary}
BuildArch: noarch
%description devel
%{common_description}
This package contains library source intended for
building other packages which use import path with
%{goipath} prefix.
%prep
%forgeautosetup -p1
%install
%goinstall
%if %{with check}
%check
%gochecks
%endif
%files devel -f devel.file-list
%license LICENSE
%doc README.md
%changelog
* Sun May 19 14:24:21 CEST 2019 Brian (bex) Exelbierd - 0-0.1.20190519git80d50a7
- Initial package
# Generated by go2rpm
%bcond_without check
%bcond_without bootstrap
# https://github.com/jacobsa/oglemock
%global goipath github.com/jacobsa/oglemock
%global commit e94d794d06ffc6de42cb19d0dab3c219efdd6dcf
%gometa
%global common_description %{expand:
Oglemock is a mocking framework for the Go programming language with the
following features:
- An extensive and extensible set of matchers for expressing call expectations
(provided by the oglematchers package).
- Clean, readable output that tells you exactly what you need to know.
- Style and semantics similar to Google Mock and Google JS Test.
- Seamless integration with the ogletest unit testing framework.
It can be integrated into any testing framework (including Go's testing
package), but out of the box support is built in to ogletest and that is the
easiest place to use it.}
Name: %{goname}
Version:0
Release:0.1%{?dist}
Summary:Mocking framework for Go
# Upstream license specification: Apache-2.0
License:ASL 2.0
URL:%{gourl}
Source0:%{gosource}
BuildRequires: golang(github.com/jacobsa/oglematchers)
%if %{without bootstrap}
%if %{with check}
# Tests
BuildRequires: golang(github.com/jacobsa/ogletest)
%endif
%endif
%description
%{common_description}
%package devel
Summary: %{summary}
BuildArch: noarch
%description devel
%{common_description}
This package contains library source intended for
building other packages which use import path with
%{goipath} prefix.
%prep
%forgeautosetup -p1
%install
%goinstall
%if %{without bootstrap}
%if %{with check}
%check
%gochecks
%endif
%endif
%files devel -f devel.file-list
%license LICENSE
%doc README.md sample/README.markdown
%changelog
* Sun May 19 14:24:15 CEST 2019 Brian (bex) Exelbierd - 0-0.1.20190519gite94d794
- Initial package
___
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 bootstrap example, ideally with golang
Hello, golang(github.com/jacobsa/ogletest) is only needed for tests by oglemock. So you just need to bootstrap oglemock with tests disabled then build ogletest then rebuild oglemock unboostrapped. In the new macros we will have easier tools to deal with more complex cyclic dependencies, see my guide: https://eclipseo.fedorapeople.org/guidelines/ packaging-guidelines/Golang_advanced/#_dealing_with_cyclic_dependencies ___ 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
packaging bootstrap example, ideally with golang
Hi, I am trying to package gocryptfs. It has a pair of dependencies that have a circular dependency: golang-github-jacobsa-oglemock golang-github-jacobsa-ogletest I think I am supposed to make one of them have a bootstrap configuration so it can be built without the other and then build the other and then rebuild the first one. If this is right, can someone point me to an example of this, ideally done with golang, so I can work it out? thanks, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: orphaning bleachbit
Hello, Yes, I know Python 2 will be soon removed, but I can't just let Bleachbit die. It's too useful for that. Finding a sponsor seems to be the hard bit. I've been looking for one for ages. Thanks for the answer. Kind regards, Silvia FAS: Lailah On Sun, 19 May 2019 at 10:16, Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 18/05/19 10:47, Silvia Sánchez ha scritto: > > > > Hello, > > > > I don't have experience maintaining packages but I'm willing to > > maintain Bleachbit as I use it a lot, it's the first programme I > > install when I do a fresh install. Let me know what I need to do and > > I'll take care. > > > > Kind regards, > > Silvia > > > > > Usually, to become a package maintainer you should get sponsored by > creating your first package and by commenting to some reviews: > > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join > > Since you don't have any new package to add, you could just start doing > some informal reviews to get acquainted with the Fedora Packaging > Guidelines and to find some sponsor that will let you join the packager > group: > > > https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer > > Be advised that Python2 will soon be removed from Fedora and from what I > can see Bleachbit requires Python2... unless upstream switches to > support Python3, this could be the wrong package to start with as it > will be retired as well. > > Mattia > > ___ > 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: Provides: bundled(...) for libraries not present in Fedora?
Am 19.05.19 um 10:26 schrieb Miro Hrončok: >> I have a question about declaring bundled libraries in spec files: >> >> I think I need to add a "Provides: bundled(...)" tag in my spec file even for >> libraries which are not part of Fedora. Is that corrent? > > Yes, it's correct. Thanks for the quick response :-) Felix ___ 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: Provides: bundled(...) for libraries not present in Fedora?
On 19. 05. 19 10:23, Felix Schwarz wrote: Hi, I have a question about declaring bundled libraries in spec files: I think I need to add a "Provides: bundled(...)" tag in my spec file even for libraries which are not part of Fedora. Is that corrent? Yes, it's correct. -- 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
Stewardship SIG Report #1
After some weeks of initial setup and sorting through the chaos of Java packages
in rawhide, the Stewardship SIG has finally started to operate as it was
originally intended. You've probably noticed that I started the process of
trying to redistribute some of the SIG packages three weeks ago.
## Package clean-up procedure
The purpose of our SIG was to prevent massive problems caused by package mass
orphanings and retirements, as you know. However, since we don't have the
resources to keep all our packages updated and only provide basic maintenance
(primarily fixing FTBFS issues and CVEs), we're looking to incrementally
redistribute some of our packages to new, permanent maintainers.
The process we agreed upon consists of the following steps:
1. identify the set of packages that none of our other packages depend on ("SIG
leaf packages")
2. notify maintainers of directly dependent packages that the package needs
a permanent maintainer
3. if there is a response within two weeks, reassign the package
4. otherwise, orphan the package again after two weeks - unless the dependency
tree of the package contains important things
These steps give maintainers of dependent packages more than 8 weeks to react
to the retirement of one of their packages' dependencies (in addition to the
6 weeks of notices before our SIG took the package temporarily!).
There are also some exceptions to this process, namely packages that are
critical for some software stacks (for example, maven, gradle, and dependencies
of the Dogtag PKI stack), which are not subject to re-orphaning.
## Current status (round 1)
Since it looks like the dust has settled around orphaned and retired packages
now, I started this procedure about 20 days ago with the first iteration of our
procedure for finding new maintainers for packages.
### New maintainer
The following packages found a new maintainer (thanks, tomh!):
- nodejs-array-union
- nodejs-arrify
- nodejs-bluebird
- nodejs-clean-css
- nodejs-grunt-known-options
- nodejs-path-exists
- nodejs-set-immediate-shim
- nodejs-sinon
- nodejs-supports-color
### No responses
There was no response from any dependent maintainers for these packages:
- apache-commons-discovery
- checkstyle (re-orphaned)
- json_simple (re-orphaned)
- nodejs-array-uniq
After checking their dependency trees I already re-orphaned checkstyle and
json_simple, as you can see.
More details and a list of dependent packages for the not yet orphaned packages
can be found here: https://www.pagure.io/stewardship-sig/issue/25
We're still evaluating the dependencies of apache-commons-discovery and
nodejs-array-uniq before we orphan them too. If you depend on either of these
packages, consider opening an adoption request ticket with the stewardship SIG.
Fabio (decathorpe), for the Stewardship SIG
___
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
Provides: bundled(...) for libraries not present in Fedora?
Hi, I have a question about declaring bundled libraries in spec files: I think I need to add a "Provides: bundled(...)" tag in my spec file even for libraries which are not part of Fedora. Is that corrent? This interpretation was derived from: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > To indicate an instance of bundling, first determine the name and version of > the bundled library: > > - If the bundled package also exists separately in the distribution, use the > name of that package. Otherwise consult the Naming Guidelines to determine > an appropriate name for the library as if it were entering the > distribution as a separate package. Felix ___ 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 bleachbit
Il 18/05/19 10:47, Silvia Sánchez ha scritto: > > Hello, > > I don't have experience maintaining packages but I'm willing to > maintain Bleachbit as I use it a lot, it's the first programme I > install when I do a fresh install. Let me know what I need to do and > I'll take care. > > Kind regards, > Silvia > > Usually, to become a package maintainer you should get sponsored by creating your first package and by commenting to some reviews: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join Since you don't have any new package to add, you could just start doing some informal reviews to get acquainted with the Fedora Packaging Guidelines and to find some sponsor that will let you join the packager group: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer Be advised that Python2 will soon be removed from Fedora and from what I can see Bleachbit requires Python2... unless upstream switches to support Python3, this could be the wrong package to start with as it will be retired as well. Mattia ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 277 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 85 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 53 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 45 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 19 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 17 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04c7455f6a singularity-3.1.1-1.1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d44655ca3 mediaconch-18.03.2-7.el7 libmediainfo-19.04-1.el7 mediainfo-19.04-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1605b73a09 drupal7-7.67-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d96aef0d8f rust-1.34.2-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing MUMPS-5.1.2-10.el7 dkms-2.7.1-1.el7 Details about builds: MUMPS-5.1.2-10.el7 (FEDORA-EPEL-2019-49b7c72447) A MUltifrontal Massively Parallel sparse direct Solver Update Information: - Require scalapack explicity ChangeLog: * Fri May 17 2019 Antonio Trande - 5.1.2-10 - Require scalapack explicity (rhbz #1711291 #1711289) - Disable tests with OpenMPI-4 * Thu Feb 14 2019 Orion Poplawski - 5.1.2-9 - Rebuild for openmpi 3.1.3 * Thu Jan 31 2019 Fedora Release Engineering - 5.1.2-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Jul 19 2018 Sandro Mani - 5.1.2-7 - Rebuild (scotch) * Thu Jul 12 2018 Fedora Release Engineering - 5.1.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Feb 15 2018 Antonio Trande - 5.1.2-5 - Use %ldconfig_scriptlets * Wed Feb 7 2018 Fedora Release Engineering - 5.1.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Wed Jan 31 2018 Antonio Trande - 5.1.2-3 - Rebuild for GCC-8 References: [ 1 ] Bug #1711289 - Need to require scalapack explicitly https://bugzilla.redhat.com/show_bug.cgi?id=1711289 dkms-2.7.1-1.el7 (FEDORA-EPEL-2019-ff90097f82) Dynamic Kernel Module Support Framework Update Information: Update to 2.7.1. ChangeLog: * Wed May 15 2019 Simone Caronni - 2.7.1-1 - Update to 2.7.1. * Thu Jan 31 2019 Fedora Release Engineering - 2.6.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Jul 12 2018 Fedora Release Engineering - 2.6.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild References: [ 1 ] Bug #1709083 - dkms-2.7.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1709083 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
