[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de51ed6706 drupal7-uuid-1.3-1.el6 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d5dca753d6 GraphicsMagick-1.3.32-1.el6 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12f1eb1b1f tomcat-7.0.94-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing entr-4.2-2.el6 geolite2-20190618-1.el6 php-paragonie-random-compat-2.0.18-1.el6 php-symfony-2.3.42-2.el6 python-f5-icontrol-rest-1.3.13-1.el6 Details about builds: entr-4.2-2.el6 (FEDORA-EPEL-2019-79499ecd10) Run arbitrary commands when files change Update Information: New package. geolite2-20190618-1.el6 (FEDORA-EPEL-2019-ce9d0f9665) Free IP geolocation databases Update Information: - Latest upstream ChangeLog: * Wed Jun 19 2019 Carl George - 20190618-1 - Latest upstream php-paragonie-random-compat-2.0.18-1.el6 (FEDORA-EPEL-2019-79c1c4190d) PHP 5.x polyfill for random_bytes() and random_int() from PHP 7 Update Information: ## php-paragonie-random-compat ### Version 2.0.18 - 2019-01-03 * If `/dev/urandom` cannot be read on Unix-based operating systems, a Exception with a specific error message will be thrown. * Fixed Psalm nits. * Updated the README to include a reference to the support contract offering by Paragon Initiative Enterprises. ### Version 2.0.17 - 2018-07-04 * Version 2.0.16 failed Psalm checks on PHP v5.6 with Psalm v1. We could not reproduce this failure locally, so we've suppressed the `MissingReturnType` check (that is to say, demoted it to "info"). ### Version 2.0.16 - 2018-07-04 * Fixed type- checking consistencies that forced us to use Psalm in non-strict mode (i.e. `totallyTyped="false"`). * README cleanup, added a header to the Version 9.99.99 section. * If you're confused by `v9.99.99` and it's causing stuff to break, see [this section of the README](https://github.com/paragonie/random_compat#version-9) for the solution to your problem. * Trimmed down and annotated our `psalm.xml` file with explanations for why each assertion is suppressed. ### Version 2.0.15 - 2018-06-08 * A reported, but difficult to reproduce, problem with file inclusion on [some Windows machines](https://github.com/paragonie/random_compat/issues/136) was fixed by [replacing `/` with `DIRECTORY_SEPARATOR`](https://github.com/paragonie/random_compat/pull/141). For most users (i.e. not running Windows) this change should be of zero consequence. For everyone else, it should mean random_compat magically works when it didn't before. ### Version 2.0.14 - 2018-06-06 * Update version information. * Updated README with better instructions, including new information about the `v9.99.99` tag. ### Version 2.0.13 - 2018-06-06 * \#139 - Add `polyfill` keyword to composer.json * Ensure the docblocks are consistent to aid static analysis efforts in other libraries; see https://github.com/para gonie/random_compat/commit/cbe0b11b78140bc62a921fec33a730fdaa6540d6 ### Version 2.0.12 - 2018-04-04 * Minor docblock issue that's breaking Psalm downstream. ### Version 2.0.11 - 2017-09-27 * Minor docblock corrections. * Re-issuing a PHP Archive to attempt to address an issue with the Phar provided. See [#134](https://github.com/paragonie/random_compat/issues/134). ### Version 2.0.10 - 2017-03-13 * Mcrypt can now be used on PHP < 5.3.7 if you're not on Windows. * Minor boyscouting changes. ### Version 2.0.9 - 2017-03-03 * More Psalm integration fixes. ### Version 2.0.8 - 2017-03-03 * Prevent function already declared error for `random_int()` caused by misusing the library (really you should only ever include `lib/random.php` and never anyof the other files). See [#125](https://github.com/paragonie/random_compat/issues/125). ### Version 2.0.6, 2.0.7 - 2017-02-27 * Just updates to psalm.xml to silence false positives. ### Version 2.0.5 - 2017-02-27 * Run random_compat through the static analysis tool, [psalm](https://github.com/vimeo/psalm), as part of our continuous integration process. * Minor readability enhancements ([#122](https://github.com/paragonie/random_compat/issues/122) and
[389-devel] 389 DS nightly 2019-06-20 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/06/20/report-389-ds-base-1.4.1.4-20190619git5c0198d.fc30.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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2019-06-20 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-06-20 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2019-06-20 09:00 PDT US/Pacific 2019-06-20 12:00 EDT --> US/Eastern <-- 2019-06-20 16:00 UTC UTC 2019-06-20 17:00 BST Europe/London 2019-06-20 18:00 CEST Europe/Berlin 2019-06-20 18:00 CEST Europe/Paris 2019-06-20 21:30 IST Asia/Calcutta New Day: Friday - 2019-06-21 00:00 HKT Asia/Hong_Kong 2019-06-21 00:00 +08 Asia/Singapore 2019-06-21 01:00 JST Asia/Tokyo 2019-06-21 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = New business = #topic #899 Need to define ticket policy .fpc 899 https://pagure.io/packaging-committee/issue/899 #topic #901 Golang pkg. review exception for Adopt new Guidelines change .fpc 901 https://pagure.io/packaging-committee/issue/901 #topic #905 Question regarding build flags .fpc 905 https://pagure.io/packaging-committee/issue/905 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
On 6/19/19 1:14 PM, Pavel Raiskup wrote: > Ok, f30 infra is still brokne -- but Mirek submitted regular update for Fixed. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: RHEL 7.7 Beta
On 19. 06. 19 19:22, Kevin Fenzi wrote: On 6/12/19 1:48 AM, Miro Hrončok wrote: On 12. 06. 19 8:14, Thomas Stephen Lee wrote: Hi, Just for your information. https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available Python 3.6 is there in 7.7 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview thanks In that case, let's proceed with: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20 https://src.fedoraproject.org/rpms/python34/pull-request/35 Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633 But we don't want to actually land that until 7.7 is out right? We do. It is designed to work, after 7.7 GA python-rpm-macros package gets retired on EPEL. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora 30 voting is now open
On Wed, Jun 5, 2019 at 8:03 PM 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. > > [1] https://elections.fedoraproject.org > [2] https://communityblog.fedoraproject.org/?p=7774 > This is your final reminder that elections voting is open for about 27 more hours. I checked my calendar this time. As a reminder, if you cannot vote because you only have the "CLA done" group in FAS, please file an issue at https://pagure.io/fedora-project-schedule/new_issue ASAP and I will take care of that for you. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Re: Fedora 30 voting is now open
On Wed, Jun 5, 2019 at 8:03 PM 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. > > [1] https://elections.fedoraproject.org > [2] https://communityblog.fedoraproject.org/?p=7774 > This is your final reminder that elections voting is open for about 27 more hours. I checked my calendar this time. As a reminder, if you cannot vote because you only have the "CLA done" group in FAS, please file an issue at https://pagure.io/fedora-project-schedule/new_issue ASAP and I will take care of that for you. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
On 6/17/19 8:27 PM, Igor Gnatenko wrote: as of today, builders have been updated (thanks to Kevin) and DynamicBuildRequires finally work in Rawhide. Change Page:https://fedoraproject.org/wiki/Changes/DynamicBuildRequires Example of real build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391 Cool! Any long term plans to support C/C++ apps? I know those are all over the map with regards to build tools, but maybe cmake/meson could be supported? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
On Wednesday, June 19, 2019 9:38:40 PM CEST Pavel Raiskup wrote: > On Tuesday, June 18, 2019 3:54:41 PM CEST Miroslav Suchý wrote: > > Dne 18. 06. 19 v 11:42 Igor Gnatenko napsal(a): > > > * COPR -- no idea > > > > Not yet. Koji use patched version of Mock (Igor discovered one issue after > > release). In Copr we will wait for Mock > > 1.4.17 and once it will hit Fedora stable, it will automagically start > > working > > in Copr. > > I think Koji has mock 1.4.16-2 installed from infra tags repo [1]. The only > problem is that Copr uses F30 (koji is F29). Why not to build the same mock > to > the f30 infra tags too, so Copr doesn't have to stay behind...? > > [1] > https://kojipkgs.fedoraproject.org/repos-dist/f29-infra/latest/x86_64/pkglist Ok, f30 infra is still brokne -- but Mirek submitted regular update for F30 [1] so even better (users will have *that* mock as well). Once it reaches stable, it will be propagated to Copr builders automatically. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-efe97323a7 Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
On Tuesday, June 18, 2019 3:54:41 PM CEST Miroslav Suchý wrote: > Dne 18. 06. 19 v 11:42 Igor Gnatenko napsal(a): > > * COPR -- no idea > > Not yet. Koji use patched version of Mock (Igor discovered one issue after > release). In Copr we will wait for Mock > 1.4.17 and once it will hit Fedora stable, it will automagically start working > in Copr. I think Koji has mock 1.4.16-2 installed from infra tags repo [1]. The only problem is that Copr uses F30 (koji is F29). Why not to build the same mock to the f30 infra tags too, so Copr doesn't have to stay behind...? [1] https://kojipkgs.fedoraproject.org/repos-dist/f29-infra/latest/x86_64/pkglist Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide status - 2019-06-19
On Wed, 2019-06-19 at 13:35 -0500, Bruno Wolff III wrote: > On Wed, Jun 19, 2019 at 10:44:41 -0700, > Kevin Fenzi wrote: > > The last rawhide compose that completed was 2019-06-09 (10 days ago now). > > A lot of the incomplete composes are actually usable for updates and I have > been getting systems updated and things have worked reasonably for the most > part. > > If we had enough resources, it would be nice if the part of the compose > needed > for installs was treated differently from the part that people could use > to get updates. The general idea is that if it's broken enough that the images don't compose, we're not confident it's working enough to send out as updates to existing systems either. This would of course work better if we could get a tighter and faster loop from 'change that breaks things' to 'realizing that things are broken' to 'fixing the change', though. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide status - 2019-06-19
On Wed, Jun 19, 2019 at 10:44:41 -0700, Kevin Fenzi wrote: The last rawhide compose that completed was 2019-06-09 (10 days ago now). A lot of the incomplete composes are actually usable for updates and I have been getting systems updated and things have worked reasonably for the most part. If we had enough resources, it would be nice if the part of the compose needed for installs was treated differently from the part that people could use to get updates. (For example kernel-5.2.0-0.rc5.git1.1.fc31 fixes a remote DOS bug and people won't get it by default until there is a successful compose. Though it also seems to have problems on some hardware.) The naive way to do this is to have two seperate repos with hard linked rpms. Hopefully as time goes on, there will be fewer multi-day compose failures. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
On Wednesday, June 19, 2019 6:27:31 PM CEST Philip Kovacs via devel wrote: > I use those macros wherever possible, but sometimes I need a raw `make`in > order to specify uncommon targets. I'll just replace `__make` with `make` > for now. No harm there. $ rpm --eval %make_build /usr/bin/make -O -j8 So you can simply do `%make_build uncommon-target`. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de51ed6706 drupal7-uuid-1.3-1.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d5dca753d6 GraphicsMagick-1.3.32-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing gfal2-2.16.3-1.el6 python-elasticsearch6-6.4.2-1.el6 tio-1.32-1.el6 tomcat-7.0.94-1.el6 Details about builds: gfal2-2.16.3-1.el6 (FEDORA-EPEL-2019-f395fc23f4) Grid file access library 2.0 Update Information: * new upstream release ChangeLog: * Tue Jun 18 2019 Andrea Manzi - 2.16.3-1 - Upgraded to upstream release 2.16.3 * Thu Jan 31 2019 Fedora Release Engineering - 2.16.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild python-elasticsearch6-6.4.2-1.el6 (FEDORA-EPEL-2019-cfbe0bca6d) Client for Elasticsearch Update Information: First release of elasticsearch6 to EPEL 6 and 7 tio-1.32-1.el6 (FEDORA-EPEL-2019-cbe27e7d8d) Simple TTY terminal I/O application Update Information: tio v1.32 =* Update AUTHORS* Minor code style cleanups* Cleanup print macros* Flush output Make sure output is transmitted immediately by flushing the output.* add optional timestamps with `-t` or "C-t T", toggle a timestamp prefix to each line.* Fix typos* Added macOS compatibility* Made `O_NONBLOCK` flag to `open()` call specific to macOS only.* Added macOS-related details.* Added `O_NONBLOCK` flag to `open()` call for macOS (10.13.6) compatibility. tio v1.31 =* Update date* Update AUTHORS* Clarify the input/output variable names (No-op change)* Organize options the same sequence they are mentioned in cmdline help.* Update README.* Map CR->NL locally on output instead of using `tio.c_oflag |= OCRNL`. This mostly is intended to have local echo output exactly what is sent to the remote endpoint. A nice side-effect is, that it also fixes tty-implementations, that can't deal with the `OCRNL` flag on `tio.c_oflag`.* Provide local-echo option. Can be switched on with `-e` on the command line. Can be toggled with Ctrl t e while program is running. * Write to logfile as soon as we have the data, don't buffer. Logfiles are important to see what happened, in particular if something unexpected happened; so we want to make sure that the logfile is flushed to disk. Before this change, the logfile was typically written at the end in a large chunk as the default (large) buffering applied. Now, characters are written out ASAP, so it is possible to get a live-view with a `tail -f ` tio v1.30 = * Update README* Update man page and bash completion* Update AUTHORS * `ONLCRNL`: change the method to map NL to CR-NL tio v1.29 =* Add mapping flags `INLCRNL` and `ODELBS` The following new mapping flags are added: `INLCRNL`: Map NL to CR-NL on input. `ODELBS`: Map DEL to BS on output. tio v1.28 =* Update README* Update AUTHORS* Add snap status to `README.md`* Add `README.md` to prettify GitHub page* Add missing header* Add missing header file under musl-libc Musl's inclusion tree slightly differs from glibc, therefore `TCGETS2` is not reachable through `sys/ioctl.h`, so `asm/ioctls.h` needs to be included too.* Fix grammar and typos ChangeLog: * Tue Jun 18 2019 Robert Scheck 1.32-1 - Upgrade to 1.32 (#1720889) * Sun Feb 3 2019 Fedora Release Engineering - 1.27-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Jul 14 2018 Fedora Release Engineering - 1.27-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Fri Feb 9 2018 Fedora Release Engineering - 1.27-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild References: [ 1 ] Bug #1720889 - tio-1.32 is available https://bugzilla.redhat.com/show_bug.cgi?id=1720889
[389-devel] please review: PR 50456 - Fix Cockpit UI branding
https://pagure.io/389-ds-base/pull-request/50456 ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
rawhide status - 2019-06-19
Greetings everyone. I thought I would send out a rawhide status email to catch everyone up to whats going on there. I should have sent it sooner, but I was on vacation, then in a set of meetings, etc. The last rawhide compose that completed was 2019-06-09 (10 days ago now). There's been a number of reasons for this. In order to accommodate some fedora 31 changes ( dynamic build requires ) and epel8 work we needed a koji with some backported patches as well as newer mock and createrepo_c. So, first step was to get armv7 builders off Fedora 27 where they have been stuck due to a kernel bug. Luckily Peter Robinson and Paul Whalen have been working on isolating that bug and found a kernel/userspace combo that we can use until we fix it. So, all the armv7 builders are up on fedora 29 with a older kernel now. Next I found that python2 koji-builder was no longer installable due to python2 deps going away. I could have just tried to fix that, but I figured it would be a good time to just move everything to python3 and get it oever with. This turned out to be more involved than I had hoped: * koji itself still shipped a python2 script (which we don't use and I ended up just dropping in the fedora builds). * Moving koji-builder over to python3 meant we had to also move over oz and imagefactory (happily something which happened in rawhide) and all the stack of things they use. * I rebuilt (with patches) all the following for our f29 builders: oz imagefactory koji koji-containerbuild (which cverna ported to python3 nice and quickly) python-urlgrabber pycdio (is python2 only in fedora, but we needed python3, need to file a bug on this one) imagefactory-plugins mock After a number of update and find breakage and fix, I got things back working monday all on python3. Then of course since it's been so long since a compose, we are now hitting those things that broke in the mean time. First some kde deps, and now a ppc64le/aarch64 cloud image issue ( https://bugzilla.redhat.com/show_bug.cgi?id=1722181 ) Hopefully that one can be solved soon and we can get back on the composes bandwagon. Gating wouldn't have helped the python3 issues as that was builder side. It would likely have helped with the kde deps and cloud issues however. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: RHEL 7.7 Beta
On 6/12/19 1:48 AM, Miro Hrončok wrote: > On 12. 06. 19 8:14, Thomas Stephen Lee wrote: >> Hi, >> >> Just for your information. >> >> https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available >> >> >> Python 3.6 is there in 7.7 >> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview >> >> >> thanks > > In that case, let's proceed with: > > https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19 > https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20 > https://src.fedoraproject.org/rpms/python34/pull-request/35 > > Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633 But we don't want to actually land that until 7.7 is out right? kevin signature.asc Description: OpenPGP digital signature ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
I use those macros wherever possible, but sometimes I need a raw `make`in order to specify uncommon targets. I'll just replace `__make` with `make` for now. No harm there.On Wednesday, June 19, 2019, 12:06:44 PM EDT, Vitaly Zaitsev via devel wrote: Hello, Philip Kovacs via devel. Wed, 19 Jun 2019 15:28:10 + (UTC) you wrote: > I notice I am still using the `__make` macro in my specs. While they > still work, should we proactively replace them with `make` ? You can use %make_build and %make_install instead. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
Hello, Philip Kovacs via devel. Wed, 19 Jun 2019 15:28:10 + (UTC) you wrote: > I notice I am still using the `__make` macro in my specs. While they > still work, should we proactively replace them with `make` ? You can use %make_build and %make_install instead. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
None that I can tell. Years ago when I was writing my specs to add the packages I now maintain, I recallsomeone recommended to me the use of these macros as Fedora "tribal knowledge." I am happy to remove mine if their use is unnecessary and could lead to breakage. On Wednesday, June 19, 2019, 11:31:24 AM EDT, Christophe de Dinechin wrote: > On 19 Jun 2019, at 17:28, Philip Kovacs via devel > wrote: > > I notice I am still using the `__make` macro in my specs. While they still > work, should we proactively replace them with `make` ? What’s the downside of removing it? > > The additional message I am getting here is that the under-under macros might > be subject to removal. > > Thanks > Phil > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
> On 19 Jun 2019, at 17:28, Philip Kovacs via devel > wrote: > > I notice I am still using the `__make` macro in my specs. While they still > work, should we proactively replace them with `make` ? Is there any downside in replacing it? > > The additional message I am getting here is that the under-under macros might > be subject to removal. > > Thanks > Phil > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
I notice I am still using the `__make` macro in my specs. While they still work, should we proactively replace them with `make` ? The additional message I am getting here is that the under-under macros might be subject to removal. ThanksPhil___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1722166] New: perl-Dancer2-0.208000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722166 Bug ID: 1722166 Summary: perl-Dancer2-0.208000 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Dancer2 Keywords: FutureFeature, Triaged Assignee: dd...@cpan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.208000 Current version/release in rawhide: 0.207000-3.fc31 URL: http://search.cpan.org/dist/Dancer2 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/5847/ -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1722166] perl-Dancer2-0.208000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722166 --- Comment #1 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Orphaned python2-django1.11
Hello, Back when [Django 2.0] was released in Fedora 28, I took over Django 1.11 LTS as some important (to me) packages depended on it. I'm no longer interested in maintaining it, so I've orphaned it. Let me know if you want to take it. If no one does, it may be removed from Rawhide in 6 weeks. Depending packages and their maintainers are: - fts-monitoring (andreamanzi, simonm) - python-oauth2client (mbaldessari, ralph) - cobbler-web (jimi, kwizart, orion, shenson) Let me know if you need help with these packages. [Django 2.0]: https://fedoraproject.org/wiki/Changes/Django20 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Should python3-rpm-macros depend on python3?
On 19. 06. 19 14:36, Neal Gompa wrote: On Wed, Jun 19, 2019 at 8:09 AM Miro Hrončok wrote: On 19. 06. 19 12:24, Neal Gompa wrote: On Wed, Jun 19, 2019 at 6:05 AM Miro Hrončok wrote: We have an interesting request for python3-rpm-macros to depend on python3. See https://bugzilla.redhat.com/show_bug.cgi?id=1563789 Highlights: - users who build for Python 3 are told (in the guidelines) to BR python3-devel (that brings in both python3 and python3-rpm-macros) - the existence of python3-rpm-macros is left as an implementation detail for ^ - in theory, those macros can be used with other Pythons (such as pypy3 or python36, that is most likely not done in practice) Arguments: - to require: the macros are broken without a python3 interpreter - to not: the macros should work with any python3 interpreter Solutions? - declare direct BR of macros without a python3 interpreter unsupported - add dependency on python3. unused if used with another interpreter - add a common virtual provide for all python3 interpreters or require (python3 or pypy3 or python36...) - very tedious Have we ever tried using it with pypy3? Does it even work with that (that is, pypy3-foo packages can be made)? If it does, we should just add a common virtual provide to supported interpreters and require that. Else, just require python3. In practice, I have not. However in theory: $ rpm --define '__python3 /usr/bin/pypy3' --eval '%python3_sitearch' /usr/lib64/pypy3-7.1/site-packages $ rpm --define '__python3 /usr/bin/python3.5' --eval '%python3_sitearch' /usr/lib64/python3.5/site-packages $ rpm --define '__python3 /usr/bin/python3.4' --eval '%python3_sitearch' /usr/lib64/python3.4/site-packages $ rpm --define '__python3 /usr/bin/python3.8' --eval '%python3_sitearch' /usr/lib64/python3.8/site-packages I took a look at pypy3, and I see we already define pypy3 variants of the python3 macros... Do we want to deduplicate them and maybe have a macro switch for flipping the interpreter? In that case, then pypy3-devel should BR python3-rpm-macros... No idea. I don't think that it is needed, I'm just saying it is possible. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On 6/19/19 1:51 PM, Aleš Matěj wrote: At this point, the drpm library is the only blocker for zstd payloads, since createrepo_c needs to be able to handle zstd drpms. I looked into the drpm library and I should be able to add the zstd support (and make sure it works with createrepo_c) Working on it now. FWIW, as drpm links to librpm anyway, it should be possible for drpm to just use the file API from rpm to gain support for everything that rpm does instead of duplicating the effort for all the compression types. If there's something broken or missing that prevents this from working, we could always address that... - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Langpacks and the packages needed to display/input a language
Le 2019-06-19 14:32, Nicolas Mailhot a écrit : Le 2019-06-19 12:48, Jens-Ulrik Petersen a écrit : Hi And yes as Nicolas also said maybe we need: langpacks-ko-fonts and langpacks-ko-input-methods, etc. I's much more than input methods, it's anything you need to read/write a language (input, spell/grammar, fonts, etc) Though the whole concept is difficult to convey in metapackage naming to non-technical users. After thinking about it some more, what would be understandable for everyone involved is langpack-ui-foo Recommends langpack-foo and app-langpack-ui-foo Recommends app-langpack-foo app-langpack-ui-foo Supplements (langpack-ui-foo if app) app-langpack-foo Supplements (langpack-foo if app) since UI is better known than obscure acronyms like i18n or l10n with also app-langpack-ui-foo Requires langpack-ui-foo app-langpack-fooRequires langpack-foo if they can't function without the generic (not app specific) support installed -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Langpacks and the packages needed to display/input a language
Le 2019-06-19 12:48, Jens-Ulrik Petersen a écrit : Hi And yes as Nicolas also said maybe we need: langpacks-ko-fonts and langpacks-ko-input-methods, etc. I's much more than input methods, it's anything you need to read/write a language (input, spell/grammar, fonts, etc) Though the whole concept is difficult to convey in metapackage naming to non-technical users. After thinking about it some more, what would be understandable for everyone involved is langpack-ui-foo Recommends langpack-foo and app-langpack-ui-foo Recommends app-langpack-foo app-langpack-ui-foo Supplements (langpack-ui-foo if app) app-langpack-foo Supplements (langpack-foo if app) since UI is better known than obscure acronyms like i18n or l10n Now UNIX UIs have historically been horrible about all this, with *nix devs deriving UI language from input layout and completely massing up things. Microsoft is much better at it because Office is a major earner for them, and it is used to create documents in many human languages, so they had to learn how to do it properly a long time ago (last millennium, circa ’95) The DEs and Wayland really need to break the UI language/input tie-up once and for all. A user can consider that the localization of its favorite apps sucks loads, and configure his system UI to use another language. That does not mean he can switch the language processing capabilities of his system to this other language, unless he can convince all the people he interacts with in his country to switch too. So that's one major case where UI settings differ from language processing settings. Conversely, a developer will produce material using computer languages, which are English-oriented, so he will often keep the UI in his native human language, but switch the language processing to English. So, the reverse difference exists. Furthermore, anyone who speaks more than a single human language, will want the language processing parts for all those languages. But the UI can be all languages at once, so he'll only need a single UI langpack. Lastly, DE settings (not necessarily the metapackages themselves) need to separate cleanly input method from language processing. No one who writes several languages that share the same script (for example English/French/Italian…) will accept to switch from AZERTY to QWERTY to QWERTZ whenever he switches languages. He will need to switch spellchecking though. So all the language UI = input method = language processing does not exist in the real world and building technical solutions around this false equivalence does not work Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
On Wed, 2019-06-19 at 12:38 +0200, Vít Ondruch wrote: > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > > == How To Test == > > > > This will be tested as part of the upstream crypto-policies > > testsuite. > > I think this section should describe, how I, as a Fedora user, am > supposed to test this. E.g. > > 1) Get this test package > > 2) Modify this file > > 3) Run this command > > 4) And as a result, you can now verify by this command that this new > crypto-policy is applied. As this is self-contained change I am not sure this is necessary. However I might provide test instructions or rather some kind of how-to as part of the crypto-policies documentation. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
On Wed, 2019-06-19 at 12:49 +0200, Vít Ondruch wrote: > Dne 19. 06. 19 v 12:00 Tomas Mraz napsal(a): > > On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote: > > > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > > > > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > > > > > > > == Summary == > > > > This new feature of crypto-policies allows system > > > > administrators > > > > and > > > > third party providers to modify and adjust the existing system- > > > > wide > > > > crypto policies to enable or disable algorithms and protocols. > > > > > > > > == Owner == > > > > * Name: [[User:Tmraz | Tomáš Mráz]] > > > > * Email: tm...@redhat.com > > > > > > > > == Detailed Description == > > > > > > > > The crypto-policies package will be enhanced to allow system > > > > administrators to modify the existing system-wide crypto policy > > > > levels > > > > by removing or adding enabled algorithms and protocols. For > > > > example > > > > it > > > > will be possible to easily modify the existing DEFAULT > > > I just wonder what is the strategy here? Does it means that the > > > "DEFAULT" definition will be store permanently somewhere in /usr/ > > > and > > > I'll be able to copy the DEFAULT into /etc and modify it > > > according to > > > my > > > needs? > > > > > > I am just asking, because AFAIK, currently the crypto policies > > > configuration is stored just in /etc and modifying the "DEFAULT" > > > profile > > > would make the updates problematic, requiring someone to file > > > with > > > .rpmnew files etc. That would be unfortunate. > > The configuration files will be created by a simple python > > application > > (which the update-crypto-policies will transform into). You will > > specify just the modifications that should be done to the base > > policy. > > > > Please see > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies > > > > to get the idea. > > > > We might continue shipping the "unmodified" configurations in > > /usr/share but I do not see much benefit in that except for being > > able > > for the sysadmin to look at how the unmodified individual > > configurations look like without applying the policy to the system. > > > > Looking at "unmodified" configuration is great benefit on itself. Unmodified from what? What I meant above were the unmodified pristine DEFAULT, LEGACY, FUTURE or FIPS configurations, not something like library default configuration without crypto policies. > Being able to `rm -rf /etc/cryptopolicies` (or whatever is the right > folder) to restore the original configuration would be even better. > But > maybe the "update-crypto-policies" creates configuration files for > several cryptolibraries, so this might not be possible without > modification of those libraries, dunno. But no such thing was ever possible since crypto policies were introduced and there is currently no plan to do that. This is certainly out of scope for the Custom Crypto Policies change. I am also not sure what do you mean exactly by "original configuration" - do you mean the configuration if there was no crypto-policies on the system? Then that would require more configuration handling changes on the individual crypto backend libraries/applications. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
On 6/19/19 11:40 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 19, 2019 at 01:21:38AM -0400, Elliott Sales de Andrade wrote: On Wed, 19 Jun 2019 at 01:18, Philip Kovacs via devel wrote: OK, my builds are back in order having removed those macros and replaced them with commands. I expect that many package maintainers will be hit with this. Yes. Let's change the expectation here: I don't see there's any change in expectation involved... if you are a maintainer introducing a change in your package that will impact many other packages, please either a) (preferably) just fix the dependent packages if easy or b) communicate widely at fedora-devel *in advance*. We don't want to have confused packagers on fedora-devel, and we certainly don't want packages failing in the mass rebuilds because of things that are easily avoided. Of course. But "many" is such a relative term. The __auto* macro (ab)use is such a tiny minority that I frankly didn't even remember removing them, much less think of "announcing" that we removed some internal cruft (which it is from rpm POV). The perl and python changes were an entirely different matter, and were communicated and coordinated although clearly mistakes were made there too and it could've gone smoother. Too long since the last major update, routines get rusty. In this case option a) is trivial, so I went ahead an run 'sed -r -i' over the specs Elliot listed, removing __aclocal, __autoconf, __automake, __autoheader, __libtoolize. I pushed the changes directly to git. 8 packages build OK with rpm-4.14.90, OpenIMPI fails for unrelated reasons. slurm was already fixed. Yes, a) is trivial ... if you're a provenpackager. I'm not ;) Anyway, thanks. - Panu - Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Multiple parallel side tags
On Wed, Jun 19, 2019 at 12:48:49AM +0200, Kevin Kofler wrote: > Kevin Fenzi wrote: > > I again completely disagree. There is no reason for weeks of breakage. > > Most of the issues that break composes are unannounced abi bumps where > > just rebuilding dependent packages fixes it. Or broken deps (likewise). > > Or mistakes made in kickstarts/comps. Or something that doesn't even > > run. What good does having everyone broken for weeks do? > > There are several reasons why weeks of breakage are entirely reasonable for > a distribution under development: > > 1. A bump of a library to a new major version. It can take a few weeks for > dependent packages to be ported to the new version. But it is often worth > waiting rather than introducing a compatibility library with all the mess > that comes with it. (Of course, that does not hold for a library like Qt > where getting everything ported to the new version is not realistic even in > a couple weeks. Those are the cases where a compatibility library is needed > basically forever. But there are libraries where it makes sense to just port > everything.) The workflow would be to just bump the library to the new > version in Rawhide immediately and then let dependent packages get fixed > over time as their upstreams, Fedora packagers, or other distros' packagers > port them. > > 2. Vacation. The maintainer of the dependent package may be on vacation (or > even just busy with paid work, in case of volunteers) and therefore unable > to fix their package immediately. So you may have to wait a few weeks for > the broken dependency to get fixed if a simple rebuild is not enough. I think both are valid reasons but I disagree that they should impact the entire Fedora. So rather than breaking rawhide, use a side-tag, take all the time you need and don't affect other people until everything is ready. Whether you are the one doing all the rebuilds or working with other people, the side tag model allows you to go at your own speed without affecting anyone else. > This has all worked just fine in the past, before it was decided to make > basically every single broken dependency fail the entire Rawhide compose. > Soname bumps did not even have to be announced, they would get announced by > the broken dependency report within less than 24 hours anyway, and then > eventually fixed (without somebody unrealistically expecting maintainers to > fix the broken dependency in less than 24 hours to make the next compose > succeed, which is just plain impossible for the average volunteer packager, > especially if source code changes are needed). This is both true and false. Yes this is how it used to be, no it did not work "just fine". It relied on other people doing heroic work to clean up someone's mess. We've had volunteers that were spending hours just rebuilding broken dependencies due to an unannounced soname bumps. I'm sure these people would have preferred to spend this time with their family, playing video games or just contributing to other parts of Fedora. With the new model, you do not impose work on someone else (which may also be in vacation as you point out here, and thus keeping things unfixable for a potentially long period of time), you either fix everything yourself or work with other to fix them and then you can affect the entire distribution. And if you want to bypass the gating mechanism, it is possible, but then it's a concious decision that you are making to make other people's life miserable and you may be asked the reasons for which you made this decision. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Should python3-rpm-macros depend on python3?
On 19. 06. 19 12:24, Neal Gompa wrote: On Wed, Jun 19, 2019 at 6:05 AM Miro Hrončok wrote: We have an interesting request for python3-rpm-macros to depend on python3. See https://bugzilla.redhat.com/show_bug.cgi?id=1563789 Highlights: - users who build for Python 3 are told (in the guidelines) to BR python3-devel (that brings in both python3 and python3-rpm-macros) - the existence of python3-rpm-macros is left as an implementation detail for ^ - in theory, those macros can be used with other Pythons (such as pypy3 or python36, that is most likely not done in practice) Arguments: - to require: the macros are broken without a python3 interpreter - to not: the macros should work with any python3 interpreter Solutions? - declare direct BR of macros without a python3 interpreter unsupported - add dependency on python3. unused if used with another interpreter - add a common virtual provide for all python3 interpreters or require (python3 or pypy3 or python36...) - very tedious Have we ever tried using it with pypy3? Does it even work with that (that is, pypy3-foo packages can be made)? If it does, we should just add a common virtual provide to supported interpreters and require that. Else, just require python3. In practice, I have not. However in theory: $ rpm --define '__python3 /usr/bin/pypy3' --eval '%python3_sitearch' /usr/lib64/pypy3-7.1/site-packages $ rpm --define '__python3 /usr/bin/python3.5' --eval '%python3_sitearch' /usr/lib64/python3.5/site-packages $ rpm --define '__python3 /usr/bin/python3.4' --eval '%python3_sitearch' /usr/lib64/python3.4/site-packages $ rpm --define '__python3 /usr/bin/python3.8' --eval '%python3_sitearch' /usr/lib64/python3.8/site-packages -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: what to do when original upstream recover from death?
Thanks Miro. That's basically what I had in mind. I am waiting now to see how it will be but the most probably we switch to the original upstream. It seems that they will continue with versioning of the currently used upstream, so epocha will not be needed. Currently there is some syncing of repositories so I am waiting for the new release (I guess it is question of several weeks). (Currently, the package is broken now because of changes in the latest version of mercurial, so maybe I will do some fixes before that.) On 06. 06. 19 13:04, Miro Hrončok wrote: > 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. > -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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: Switch RPMs to zstd compression
On Wed, 2019-06-19 at 10:51 +, Aleš Matěj wrote: > > At this point, the drpm library is the only blocker for zstd payloads, > > since createrepo_c needs to be able to handle zstd drpms. > > I looked into the drpm library and I should be able to add the zstd support > (and make sure it works with createrepo_c) > > Working on it now. Nice & thanks in advance! :) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: Issue with building RPMs with ASAN_ON
On Wed, Jun 19, 2019 at 09:20:26AM +0200, William Brown wrote:
>
>
> > On 18 Jun 2019, at 17:45, Viktor Ashirov wrote:
> >
> >
> >
> > On Tue, Jun 18, 2019 at 7:54 AM Viktor Ashirov wrote:
> > On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin wrote:
> > >
> > > Hi team,
> > > I'm in the process of creating a Vagrant file which is close to the
> > > customer's ENV.
> > > It is heavilly based on Viktor's beaker task.
> > > I use it for building and testing my code. And it is pretty important to
> > > build with ASAN.
> > >
> > > Currently, what I do is:
> > > 1. Set 'ASAN_ON = 1' in rpm.mk
> > > 2. Run `make -f rpm.mk srpms` target
> > > 3. Build the RPM using `mock -q my_generated.srpm`
> > > 4. Install it
> > >
> > > Then I've tried running `dscreate` manually or running tests with py.test.
> > > Every time I have the same error here:
> > > /run/dirsrv/ns-slapd-standalone1.asan.X
> > >
> > > ==22487==LeakSanitizer has encountered a fatal error.
> > > ==22487==HINT: For debugging, try setting environment variable
> > > LSAN_OPTIONS=verbosity=1:log_threads=1
> > > ==22487==HINT: LeakSanitizer does not work under ptrace (strace, gdb,
> > > etc)
> > Ludwig also recently had this issue. Looks like you're hitting this
> > bug: https://github.com/google/sanitizers/issues/723
> > We're using posix_memalign() in a few places and LeakSanitizier can't
> > handle it.
> > So, the issue Simon was seeing is not related to the issue above.
> > Turns out, it's just SELinux :)
Thanks, Viktor, once again!
> >
> >
> >
> >
> > time->Tue Jun 18 11:27:24 2019
> >
> >
> > type=AVC msg=audit(1560871644.883:596): avc: denied { ptrace } for
> > pid=3632 comm="ns-slapd" scontext=system_u:system_r:dirsrv_t:s0
> > tcontext=system_u:system_r:dirsrv_t:s0
> > tclass=process permissive=0
> >
> > [root@server ds]# ausearch -m AVC | audit2allow
> >
> >
> >
> >
> >
> >
> >
> >
> > #= dirsrv_t ==
> >
> >
> > allow dirsrv_t self:process ptrace;
>
> Heh, selinux strikes again!
>
> Were you running as a user, not as root?
>
Nope. I was running as root.
Regards,
Simon
signature.asc
Description: PGP signature
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Switch RPMs to zstd compression
> At this point, the drpm library is the only blocker for zstd payloads, > since createrepo_c needs to be able to handle zstd drpms. I looked into the drpm library and I should be able to add the zstd support (and make sure it works with createrepo_c) Working on it now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
Dne 19. 06. 19 v 12:00 Tomas Mraz napsal(a): > On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote: >> Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): >>> https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies >>> >>> == Summary == >>> This new feature of crypto-policies allows system administrators >>> and >>> third party providers to modify and adjust the existing system-wide >>> crypto policies to enable or disable algorithms and protocols. >>> >>> == Owner == >>> * Name: [[User:Tmraz | Tomáš Mráz]] >>> * Email: tm...@redhat.com >>> >>> == Detailed Description == >>> >>> The crypto-policies package will be enhanced to allow system >>> administrators to modify the existing system-wide crypto policy >>> levels >>> by removing or adding enabled algorithms and protocols. For example >>> it >>> will be possible to easily modify the existing DEFAULT >> I just wonder what is the strategy here? Does it means that the >> "DEFAULT" definition will be store permanently somewhere in /usr/ and >> I'll be able to copy the DEFAULT into /etc and modify it according to >> my >> needs? >> >> I am just asking, because AFAIK, currently the crypto policies >> configuration is stored just in /etc and modifying the "DEFAULT" >> profile >> would make the updates problematic, requiring someone to file with >> .rpmnew files etc. That would be unfortunate. > The configuration files will be created by a simple python application > (which the update-crypto-policies will transform into). You will > specify just the modifications that should be done to the base policy. > > Please see > https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies > to get the idea. > > We might continue shipping the "unmodified" configurations in > /usr/share but I do not see much benefit in that except for being able > for the sysadmin to look at how the unmodified individual > configurations look like without applying the policy to the system. > Looking at "unmodified" configuration is great benefit on itself. Being able to `rm -rf /etc/cryptopolicies` (or whatever is the right folder) to restore the original configuration would be even better. But maybe the "update-crypto-policies" creates configuration files for several cryptolibraries, so this might not be possible without modification of those libraries, dunno. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Multiple parallel side tags
On Tue, 18 Jun 2019 at 19:42, Kevin Kofler wrote: > Kevin Fenzi wrote: > > This has all worked just fine in the past, before it was decided to make > basically every single broken dependency fail the entire Rawhide compose. > Soname bumps did not even have to be announced, they would get announced > by > the broken dependency report within less than 24 hours anyway, and then > eventually fixed (without somebody unrealistically expecting maintainers > to > fix the broken dependency in less than 24 hours to make the next compose > succeed, which is just plain impossible for the average volunteer > packager, > especially if source code changes are needed). > > I am having a hard time reconciling the above with all the times you have angrily called out anyone who landed something broken in rawhide which affected what you wanted to do. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Langpacks and the packages needed to display/input a language
On Tue, Jun 18, 2019 at 3:07 AM Jason L Tibbitts III wrote: > > "JP" == Jens-Ulrik Petersen writes: > I install a generic minimal system via kickstart (booted using the > Server PXE images and using the Everything repositories) and then after > the reboot, ansible runs (via ansible-pull) and installs whatever is > needed for the type of system it's configured to be. > Okay I see, thanks: so presumably previously you were installing language support groups. Some time back lang supports groups also pulled in langpacks of translations though. > JP> One can also just try `dnf -n install langpacks-ko` to check what > JP> fonts (and input method) would be pulled in, and you are free to > JP> remove langpacks-ko anyway. > > Yes, though it's simpler to me to just pull the dependencies out of the > langpacks specfile as I'm doing now. Unfortunately that means I have to > periodically recheck if, for example, the recommended font set for > Gujarati happens to change in the future. It's not an undue burden but > it was nice to be able to rely on installing @gujarati-support as was > the case pre-F30. > It sounds like what you probably really want is: `dnf install @fonts @input-methods` That will get you the default-installed system fonts and input methods (as you would get in a standard Workstation install). This kind of problem also becomes more relevant for Toolbox containers, etc, which are also typically minimal installs. JP> I am wondering how you reached 3GB - the Noto CJK fonts we now ship > JP> are not small on disk - that might be a part of the problem perhaps. > > Well, as I wrote previously, it's things like the Libreoffice help files > and the Tesseract recognition data which get pulled in via Supplements:. > These can be quite large. And some of the size difference is certainly > unrelated to this issue. (I was installing a total of twelve > langpacks but I should probably be installing even more.) > Currently it is only really intended for a few (one or two) langpacks-* packages to be installed. Normally just for one's native language say. This may change as the experience evolves. I agree that installing all langpacks-* does not make sense - it will also pull in many locales packages, possibly duplicating locales in the glibc-all-langpacks archive. And yes as Nicolas also said maybe we need: langpacks-ko-fonts and langpacks-ko-input-methods, etc. This needs a little more thought and discussion I feel, but we could consider it for F31 or F32 surely. Jens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > == How To Test == > > This will be tested as part of the upstream crypto-policies testsuite. I think this section should describe, how I, as a Fedora user, am supposed to test this. E.g. 1) Get this test package 2) Modify this file 3) Run this command 4) And as a result, you can now verify by this command that this new crypto-policy is applied. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Should python3-rpm-macros depend on python3?
On Wed, Jun 19, 2019 at 6:05 AM Miro Hrončok wrote: > > We have an interesting request for python3-rpm-macros to depend on python3. > > See https://bugzilla.redhat.com/show_bug.cgi?id=1563789 > > Highlights: > > - users who build for Python 3 are told (in the guidelines) to BR > python3-devel > (that brings in both python3 and python3-rpm-macros) > - the existence of python3-rpm-macros is left as an implementation detail > for ^ > - in theory, those macros can be used with other Pythons > (such as pypy3 or python36, that is most likely not done in practice) > > Arguments: > > - to require: the macros are broken without a python3 interpreter > - to not: the macros should work with any python3 interpreter > > Solutions? > > - declare direct BR of macros without a python3 interpreter unsupported > - add dependency on python3. unused if used with another interpreter > - add a common virtual provide for all python3 interpreters > or require (python3 or pypy3 or python36...) - very tedious > Have we ever tried using it with pypy3? Does it even work with that (that is, pypy3-foo packages can be made)? If it does, we should just add a common virtual provide to supported interpreters and require that. Else, just require python3. -- 真実はいつも一つ！/ Always, there's only one truth! ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote: > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > > > == Summary == > > This new feature of crypto-policies allows system administrators > > and > > third party providers to modify and adjust the existing system-wide > > crypto policies to enable or disable algorithms and protocols. > > > > == Owner == > > * Name: [[User:Tmraz | Tomáš Mráz]] > > * Email: tm...@redhat.com > > > > == Detailed Description == > > > > The crypto-policies package will be enhanced to allow system > > administrators to modify the existing system-wide crypto policy > > levels > > by removing or adding enabled algorithms and protocols. For example > > it > > will be possible to easily modify the existing DEFAULT > > I just wonder what is the strategy here? Does it means that the > "DEFAULT" definition will be store permanently somewhere in /usr/ and > I'll be able to copy the DEFAULT into /etc and modify it according to > my > needs? > > I am just asking, because AFAIK, currently the crypto policies > configuration is stored just in /etc and modifying the "DEFAULT" > profile > would make the updates problematic, requiring someone to file with > .rpmnew files etc. That would be unfortunate. The configuration files will be created by a simple python application (which the update-crypto-policies will transform into). You will specify just the modifications that should be done to the base policy. Please see https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies to get the idea. We might continue shipping the "unmodified" configurations in /usr/share but I do not see much benefit in that except for being able for the sysadmin to look at how the unmodified individual configurations look like without applying the policy to the system. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Should python3-rpm-macros depend on python3?
We have an interesting request for python3-rpm-macros to depend on python3. See https://bugzilla.redhat.com/show_bug.cgi?id=1563789 Highlights: - users who build for Python 3 are told (in the guidelines) to BR python3-devel (that brings in both python3 and python3-rpm-macros) - the existence of python3-rpm-macros is left as an implementation detail for ^ - in theory, those macros can be used with other Pythons (such as pypy3 or python36, that is most likely not done in practice) Arguments: - to require: the macros are broken without a python3 interpreter - to not: the macros should work with any python3 interpreter Solutions? - declare direct BR of macros without a python3 interpreter unsupported - add dependency on python3. unused if used with another interpreter - add a common virtual provide for all python3 interpreters or require (python3 or pypy3 or python36...) - very tedious -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: octave 5.1 coming to rawhide
On Tuesday, 18 June 2019 04.31.35 WEST Orion Poplawski wrote: > Built in rawhide. Modular updates submitted for F30 and F29. > > https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-917b958a40 > https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-fe2f378273 In order to update in Fedora 30 I had to: (the first one was necessary on one machine) # dnf module reset octave (these steps are required) # dnf module enable octave:5.1 # dnf upgrade In the last command I had to use --best --allowerasing to update all octave packages, that lead to the removal of octave-communications and octave- parallel, due to the issues that you described in this thread. Best regards, -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
On Wed, Jun 19, 2019 at 01:21:38AM -0400, Elliott Sales de Andrade wrote: > On Wed, 19 Jun 2019 at 01:18, Philip Kovacs via devel > wrote: > > > > OK, my builds are back in order having removed those macros and replaced > > them with commands. > > > > I expect that many package maintainers will be hit with this. Yes. Let's change the expectation here: if you are a maintainer introducing a change in your package that will impact many other packages, please either a) (preferably) just fix the dependent packages if easy or b) communicate widely at fedora-devel *in advance*. We don't want to have confused packagers on fedora-devel, and we certainly don't want packages failing in the mass rebuilds because of things that are easily avoided. In this case option a) is trivial, so I went ahead an run 'sed -r -i' over the specs Elliot listed, removing __aclocal, __autoconf, __automake, __autoheader, __libtoolize. I pushed the changes directly to git. 8 packages build OK with rpm-4.14.90, OpenIMPI fails for unrelated reasons. slurm was already fixed. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Multiple parallel side tags
On Wed, Jun 19, 2019 at 10:29 AM Vít Ondruch wrote: > > > Dne 18. 06. 19 v 16:54 Aleksandra Fedorova napsal(a): > > On Tue, Jun 18, 2019 at 1:31 PM Neal Gompa wrote: > >> On Tue, Jun 18, 2019 at 5:21 AM Aleksandra Fedorova > >> wrote: > >>> Hi, > >>> On Tue, Jun 18, 2019 at 3:05 AM Neal Gompa wrote: > On Mon, Jun 17, 2019 at 8:53 PM Kevin Fenzi wrote: > > On 6/17/19 4:47 PM, Kevin Kofler wrote: > >> Kevin Fenzi wrote: > >>> I disagree. I think we need gating to block as much stuff that breaks > >>> things from landing as we can and then we should find that keeping > >>> composes going is much easier on all of us. Then things can be fixed > >>> when gating catches them and it's on the person who broke things. > >> And that is going to make development completely cringe to a halt. It > >> is the > >> nature of a distribution branch under development that things will > >> sometimes > >> be completely broken for a couple weeks. There needs to be a place to > >> do > >> development that can cause such temporary breakage. > > I again completely disagree. There is no reason for weeks of breakage. > > Most of the issues that break composes are unannounced abi bumps where > > just rebuilding dependent packages fixes it. Or broken deps (likewise). > > Or mistakes made in kickstarts/comps. Or something that doesn't even > > run. What good does having everyone broken for weeks do? > > > And that comes down to people shouldn't need to have to think about > these things when working in Rawhide. While I don't disagree that > Rawhide should be usable, I fundamentally disagree with making it > harder for people to put things in Rawhide. We should be developing > our tooling to make it _easier_ for stuff to go into Rawhide, and have > Rawhide fix itself when the issues are relatively trivial to fix (such > as reverse dependency rebuilding). > >>> I think this is exactly what gating is supposed to do. > >>> > >>> Let's compare it in this way: > >>> > >>> currently to add a feature which may break Rawhide and some unknown > >>> dependencies of the component you need to write a HEADS-UP e-mail, or, > >>> better, submit a Change request with the analysis of the change. > >>> People who read this e-mail would need to make a guess on whether or > >>> not his change affects them, then they have to fetch it and test it > >>> somehow, then they have to provide the feedback back to you. You need > >>> to wait for feedback, then you get the reports, in best cases - bugs, > >>> which you need to debug, requesting more info. Then you implement the > >>> change, hit the unexpected bug, which was unnoticed, and block others > >>> from building their packages and implementing their changes for > >>> unknown amount of time. > >>> > >>> With gating you can submit a code change, the tooling will take care > >>> of building it, building its dependencies, informing you of possible > >>> breakages, giving you the list of actual issues with all the debug > >>> logs. And then based on this data you can proceed or stop and rework > >>> the change a bit more in collaboration with exactly those people > >>> affected. > >>> > >>> I also think that we need a second point of view here: you were > >>> talking about not driving away the developer, who makes the change. > >>> But there are also other people who we shouldn't drive away. For > >>> example developers who depend on the change. Or QA who need to react > >>> on such changes. These people are have their part in the process. > >>> > >>> > >>> But, to be honest, I think there is a bit of overreacting on the > >>> entire Gating topic. > >>> > >>> It doesn't do a hard block. It is included in the design that gating > >>> can be bypassed. But it supposed to provide better analysis of the > >>> change. Bypassing of the gate can happen, The key here is that it > >>> won't be a surprise, rather informed decision. > >>> > >> I think this is the first time I've heard a coherent description of > >> the intent of this stuff. If it really is intended to work this way, > >> it'd be very helpful. > >> > >> The side tag approach already does not scale, as evidenced by this > >> thread. > > It does. You just need to communicate with others working in the same > > area, IMHO. I don't think we need some technical thing for something > > that happens rarely and can be solved by more communication. > > > Side tags will happen a lot more often because the tooling is pushing > us to do it that way. Don't discount the potential for future > insanity. I'm still not sure side-tags are enough. Could we have a > concept of a "scratch side tag"? Something like a scratch build, but > contains a collection of builds and creates an overlay repo that can > be used to run checks on for auto-merging? If they're good, then it > would get auto-built
Re: RFC: Multiple parallel side tags
Dne 18. 06. 19 v 16:54 Aleksandra Fedorova napsal(a): > On Tue, Jun 18, 2019 at 1:31 PM Neal Gompa wrote: >> On Tue, Jun 18, 2019 at 5:21 AM Aleksandra Fedorova >> wrote: >>> Hi, >>> On Tue, Jun 18, 2019 at 3:05 AM Neal Gompa wrote: On Mon, Jun 17, 2019 at 8:53 PM Kevin Fenzi wrote: > On 6/17/19 4:47 PM, Kevin Kofler wrote: >> Kevin Fenzi wrote: >>> I disagree. I think we need gating to block as much stuff that breaks >>> things from landing as we can and then we should find that keeping >>> composes going is much easier on all of us. Then things can be fixed >>> when gating catches them and it's on the person who broke things. >> And that is going to make development completely cringe to a halt. It is >> the >> nature of a distribution branch under development that things will >> sometimes >> be completely broken for a couple weeks. There needs to be a place to do >> development that can cause such temporary breakage. > I again completely disagree. There is no reason for weeks of breakage. > Most of the issues that break composes are unannounced abi bumps where > just rebuilding dependent packages fixes it. Or broken deps (likewise). > Or mistakes made in kickstarts/comps. Or something that doesn't even > run. What good does having everyone broken for weeks do? > And that comes down to people shouldn't need to have to think about these things when working in Rawhide. While I don't disagree that Rawhide should be usable, I fundamentally disagree with making it harder for people to put things in Rawhide. We should be developing our tooling to make it _easier_ for stuff to go into Rawhide, and have Rawhide fix itself when the issues are relatively trivial to fix (such as reverse dependency rebuilding). >>> I think this is exactly what gating is supposed to do. >>> >>> Let's compare it in this way: >>> >>> currently to add a feature which may break Rawhide and some unknown >>> dependencies of the component you need to write a HEADS-UP e-mail, or, >>> better, submit a Change request with the analysis of the change. >>> People who read this e-mail would need to make a guess on whether or >>> not his change affects them, then they have to fetch it and test it >>> somehow, then they have to provide the feedback back to you. You need >>> to wait for feedback, then you get the reports, in best cases - bugs, >>> which you need to debug, requesting more info. Then you implement the >>> change, hit the unexpected bug, which was unnoticed, and block others >>> from building their packages and implementing their changes for >>> unknown amount of time. >>> >>> With gating you can submit a code change, the tooling will take care >>> of building it, building its dependencies, informing you of possible >>> breakages, giving you the list of actual issues with all the debug >>> logs. And then based on this data you can proceed or stop and rework >>> the change a bit more in collaboration with exactly those people >>> affected. >>> >>> I also think that we need a second point of view here: you were >>> talking about not driving away the developer, who makes the change. >>> But there are also other people who we shouldn't drive away. For >>> example developers who depend on the change. Or QA who need to react >>> on such changes. These people are have their part in the process. >>> >>> >>> But, to be honest, I think there is a bit of overreacting on the >>> entire Gating topic. >>> >>> It doesn't do a hard block. It is included in the design that gating >>> can be bypassed. But it supposed to provide better analysis of the >>> change. Bypassing of the gate can happen, The key here is that it >>> won't be a surprise, rather informed decision. >>> >> I think this is the first time I've heard a coherent description of >> the intent of this stuff. If it really is intended to work this way, >> it'd be very helpful. >> >> The side tag approach already does not scale, as evidenced by this >> thread. > It does. You just need to communicate with others working in the same > area, IMHO. I don't think we need some technical thing for something > that happens rarely and can be solved by more communication. > Side tags will happen a lot more often because the tooling is pushing us to do it that way. Don't discount the potential for future insanity. I'm still not sure side-tags are enough. Could we have a concept of a "scratch side tag"? Something like a scratch build, but contains a collection of builds and creates an overlay repo that can be used to run checks on for auto-merging? If they're good, then it would get auto-built properly into the main rawhide tag (or even stable tag!). >>> Afaik, this is exactly the concept of a dynamic sidetag as Fedora >>> Infra is currently implementing. Sidetag in koji as a sort of >>> pull-request: you create sidetag, get
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > == Summary == > This new feature of crypto-policies allows system administrators and > third party providers to modify and adjust the existing system-wide > crypto policies to enable or disable algorithms and protocols. > > == Owner == > * Name: [[User:Tmraz | Tomáš Mráz]] > * Email: tm...@redhat.com > > == Detailed Description == > > The crypto-policies package will be enhanced to allow system > administrators to modify the existing system-wide crypto policy levels > by removing or adding enabled algorithms and protocols. For example it > will be possible to easily modify the existing DEFAULT I just wonder what is the strategy here? Does it means that the "DEFAULT" definition will be store permanently somewhere in /usr/ and I'll be able to copy the DEFAULT into /etc and modify it according to my needs? I am just asking, because AFAIK, currently the crypto policies configuration is stored just in /etc and modifying the "DEFAULT" profile would make the updates problematic, requiring someone to file with .rpmnew files etc. That would be unfortunate. Vít > policy to > disable the SHA1 support or enable support for a national crypto > algorithm that is supported by the crypto libraries but is disabled in > the policies. System administrator will be able to add a simple > configuration file that will achieve this after calling the > update-crypto-policies command. > > == Benefit to Fedora == > > This will enable advanced users of Fedora to adjust the > crypto-policies of the system to their particular needs and > requirements. > > It will also enable using Fedora where the national crypto algorithms > are required without need to manually tinker with configurations of > various software components to enable the national crypto algorithms. > > == Scope == > * Proposal owners: > The design of the feature and prototype is already finished upstream. > We still need to convert the existing back-end policy generators to > the new framework and convert the existing policy definitions to the > new format. Then the crypto-policies package will be rebased to the > version with the custom crypto policies support included. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > No impact. The crypto policies will continue to work as expected and > worked before if a custom policy is not set. > > == How To Test == > > This will be tested as part of the upstream crypto-policies testsuite. > > == User Experience == > > Unless the user will choose to create and/or apply a custom crypto > policy on the system, there will be no noticeable user experience > change. > > == Dependencies == > > N/A (not a System Wide Change) > > == Contingency Plan == > > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > > == Documentation == > > N/A (not a System Wide Change) > > == Release Notes == > > The crypto-policies package was enhanced to allow system > administrators to modify the existing system-wide crypto policy levels > by removing or adding enabled algorithms and protocols. For example it > is now possible to easily modify the existing DEFAULT policy to > disable the SHA1 support or enable support for a national crypto > algorithm that is supported by the crypto libraries but is disabled in > the policies. This can be achieved by adding a simple configuration > file and calling the update-crypto-policies command. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: Issue with building RPMs with ASAN_ON
> On 18 Jun 2019, at 17:45, Viktor Ashirov wrote:
>
>
>
> On Tue, Jun 18, 2019 at 7:54 AM Viktor Ashirov wrote:
> On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin wrote:
> >
> > Hi team,
> > I'm in the process of creating a Vagrant file which is close to the
> > customer's ENV.
> > It is heavilly based on Viktor's beaker task.
> > I use it for building and testing my code. And it is pretty important to
> > build with ASAN.
> >
> > Currently, what I do is:
> > 1. Set 'ASAN_ON = 1' in rpm.mk
> > 2. Run `make -f rpm.mk srpms` target
> > 3. Build the RPM using `mock -q my_generated.srpm`
> > 4. Install it
> >
> > Then I've tried running `dscreate` manually or running tests with py.test.
> > Every time I have the same error here:
> > /run/dirsrv/ns-slapd-standalone1.asan.X
> >
> > ==22487==LeakSanitizer has encountered a fatal error.
> > ==22487==HINT: For debugging, try setting environment variable
> > LSAN_OPTIONS=verbosity=1:log_threads=1
> > ==22487==HINT: LeakSanitizer does not work under ptrace (strace, gdb,
> > etc)
> Ludwig also recently had this issue. Looks like you're hitting this
> bug: https://github.com/google/sanitizers/issues/723
> We're using posix_memalign() in a few places and LeakSanitizier can't handle
> it.
> So, the issue Simon was seeing is not related to the issue above.
> Turns out, it's just SELinux :)
>
>
>
>
> time->Tue Jun 18 11:27:24 2019
>
>
> type=AVC msg=audit(1560871644.883:596): avc: denied { ptrace } for
> pid=3632 comm="ns-slapd" scontext=system_u:system_r:dirsrv_t:s0
> tcontext=system_u:system_r:dirsrv_t:s0
> tclass=process permissive=0
>
> [root@server ds]# ausearch -m AVC | audit2allow
>
>
>
>
>
>
>
>
> #= dirsrv_t ==
>
>
> allow dirsrv_t self:process ptrace;
Heh, selinux strikes again!
Were you running as a user, not as root?
>
>
> There is a workaround in the last comment. I did the builds for gcc8
> and gcc9 in copr, both internal and fedora one, but they failed (not
> related to the patch).
> So I did a local build with the patch and it worked like a charm. I
> will share the links to the rpms for you to try.
>
> Perhaps we should review our usage of posix_memalign() or convince the
> upstream to implement a proper fix for this.
> >
> > I've tried setting `export LSAN_OPTIONS=verbosity=1:log_threads=1` and run
> > once again.
> > Same issue.
> >
> > Did anybody encountered the issue? Maybe, Viktor or William, could you
> > please check?
> > I'm putting the Vagrantfile to the attachments so you can reproduce.
> > Just run: `ASAN=on vagrant up` from the directory with Vagrantfile.
> >
> > William, I think, libvirt is present on SUSE so you should have no issues
> > with this too...
> >
> > Thanks,
> > Simon
> > ___
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>
>
>
> --
> Viktor
>
>
> --
> Viktor
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Re: libfabric-1.8.0rc1 for fedora rawhide
Have you read the packaging guidelines how to properly set version for pre-release? https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde On Wed, Jun 19, 2019 at 9:08 AM Honggang LI wrote: > > I updated libfabric-1.8.0rc1 for fedora rawhide. please rebuild > packages depends on libfabric, as library version bump. > > thanks > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Any new restriction in Koji added recently in Rawhide?
> Could this ugly hack work?
>
> %{endif __with_rebar3}
>
> Assuming the %endif macro would ignore any parameters.
This won't work... But RPM could "learn" this syntax and let spec
writers add that kind of comment inside the macro.
A bit far-fetched, I won t disagree :)
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rawhide no longer recognizing autotool macros
On 6/19/19 6:59 AM, Neal Gompa wrote:
On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
wrote:
I'm getting new build failures on the autotools macros that had been working
for years. rpmbuild doesn't like
them anymore in rawhide. The macros are (or were) in the file
`/usr/lib/rpm/macros`. The relevant portion
of my spec is here:
-- spec --
%build
%{__aclocal} -I auxdir
%{__autoconf}
%{__automake} --no-force
Is there a new dependency I need to add or is something just broken?
Panu ripped them out for rpm 4.15:
https://github.com/rpm-software-management/rpm/pull/691
You can trivially switch to just calling the commands...
...which is what those packages should've been using in the first place.
This goes to ALL those %__foo macros on random utilities: their raison
d'être is to allow users to change rpm behavior without recompiling.
They're not really intended to be directly used, never were. The two
leading underscores are a hint of that, although one leading underscore
is so widely used for non-internal purposes too that the meaning has
become obscured. Unfortunately.
- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
libfabric-1.8.0rc1 for fedora rawhide
I updated libfabric-1.8.0rc1 for fedora rawhide. please rebuild packages depends on libfabric, as library version bump. thanks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
