Fedora 29-20181020.n.0 compose check report
No missing expected images. Failed openQA tests: 10/133 (x86_64), 1/2 (arm) ID: 298826 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/298826 ID: 298847 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/298847 ID: 298883 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/298883 ID: 298915 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/298915 ID: 298917 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/298917 ID: 298925 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/298925 ID: 298932 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/298932 ID: 298942 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/298942 ID: 298943 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/298943 ID: 298949 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/298949 ID: 298954 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/298954 Soft failed openQA tests: 3/133 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 298845 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/298845 ID: 298846 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/298846 ID: 298851 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/298851 ID: 298872 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/298872 ID: 298941 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/298941 Passed openQA tests: 120/133 (x86_64), 22/24 (i386) Skipped openQA tests: 1 of 159 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 133 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a unrtf-0.21.9-8.el7 83 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7 67 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 39 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896 myrepos-1.20180726-1.el7 30 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc87c43cdd libbson-1.3.5-6.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e8e2e2acac strongswan-5.7.1-1.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a9ac6a18d2 libgit2-0.26.7-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aa66b877bb mosquitto-1.5.3-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d46b0aab32 lighttpd-1.4.51-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing bindfs-1.13.10-1.el7 duperemove-0.11-3.el7 libmodsecurity-3.0.2-3.el7 python-pycryptodomex-3.6.6-2.el7 Details about builds: bindfs-1.13.10-1.el7 (FEDORA-EPEL-2018-e725b24f61) Fuse filesystem to mirror a directory Update Information: - update to new version 1.13.10 ChangeLog: * Sat Oct 20 2018 Filipe Rosset - 1.13.10-1 - update to new version 1.13.10 * Sun Sep 9 2018 Filipe Rosset - 1.13.9-3 - rebuilt to fix FTBFS on rawhide, fixes rhbz #1603487 * Thu Jul 12 2018 Fedora Release Engineering - 1.13.9-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild duperemove-0.11-3.el7 (FEDORA-EPEL-2018-42fb33cb1b) Tools for deduping file systems Update Information: Fix build for EPEL References: [ 1 ] Bug #1638987 - Review Request: duperemove - Simple tool for finding duplicated extents and submitting them for deduplication https://bugzilla.redhat.com/show_bug.cgi?id=1638987 libmodsecurity-3.0.2-3.el7 (FEDORA-EPEL-2018-47a9249868) A library that loads/interprets rules written in the ModSecurity SecRules Update Information: Back-port of modsecurity.pc for the devel sub-package. ChangeLog: * Fri Oct 19 2018 Dridi Boukelmoune - 3.0.2-3 - Back-port of modsecurity.pc python-pycryptodomex-3.6.6-2.el7 (FEDORA-EPEL-2018-740cf16670) A self-contained cryptographic library for Python Update Information: This update provides the python-pycryptodomex package for EPEL. References: [ 1 ] Bug #1640753 - python-pycryptodomex: build for EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1640753 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Fedora 29 compose report: 20181020.n.0 changes
OLD: Fedora-29-20181018.n.1 NEW: Fedora-29-20181020.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-29-20181020.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : Virtual FAD for Python3
Dear all, You are kindly invited to the meeting: Virtual FAD for Python3 on 2018-10-23 from 00:00:00 to 00:00:00 UTC At freenode@epel The meeting will be about: This will be a virtual activity day to update all python packages ot the latest python wanted. Source: https://apps.fedoraproject.org/calendar/meeting/9357/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Unretiring rudeconfig
On Sat, Oct 20, 2018 21:21:33 +0200, Robert-André Mauchin wrote: > On samedi 20 octobre 2018 18:13:20 CEST Ankur Sinha wrote: > > Hello, > > > > I would like to un-retire rudeconfig[1,2]. In line with the documented > > policy[3], I have submitted a new review ticket here[4]. > > > > Would someone like to swap reviews please? > > > > I have reviewed and approved the package. Thanks very much. I've made the required updates and opened a ticket with releng to unretire the package: https://pagure.io/releng/issue/7879 > All my owns package reviews are assigned so far. Please feel free to ping me when you are looking for a reviewer in the future :) -- Thanks again, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Sat, Oct 20, 2018 at 2:30 PM, Chris Adams wrote: > So, my opinion on email vs. web forum is that it is comes down to > freedom vs. lock-in. Right. What does migration out of Discourse look like? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
So, my opinion on email vs. web forum is that it is comes down to freedom vs. lock-in. With mailing lists (and Usenet), messages are distributed in a more-or-less well-defined format, and users are able to choose clients, filtering, etc. to suit their use patterns. Sometimes people do novel things that help them handle volume, find and track topics they are interested in, etc. With a web forum, users are limited to consuming content in the way the forum developer created, as chosen to be applied by the system managers. Rarely do users have any control over how they access the content, and they still only can control it in the way the developers thought of, implemented, tested, and continue to support. I've used web forums where a function I used regularly went away with an upgrade because the developers didn't think enough people used them and didn't want to support them anymore. Now, that freedom to do as you please has kind of fallen by the wayside on the Internet in general; personal blogs went to hosted blogs (with more uniform interfaces) and then on to mass-hosted social media (with an interface decided entirely by the company running it). So maybe I'm just old-fashioned that way and not enough other people care. I'll admit up front that I haven't checked out Discourse yet. However, I haven't seen before anything that handles the way I consume email, especially mailing lists. I'll keep selected messages of a thread around for later reference, flag messages so they'll be highlighted when I open a folder in the future, filter out certain keywords or posters on rare occasions, and more - and that's just off the top of my head. Also, I follow a bunch of different mailing lists. If they all were web forums, I'd have a bunch of different interfaces to deal with, sites to visit, functionality to learn, etc., instead of my single mail client that I can tweak to my personal use patterns and can bring it all together. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
> If this is, why has the project chosen to not document that in their > code/docs? That would, it seems, help contributors stay focused on > the goal. > https://wiki.list.org/DEV/Home?action=show=DEV I went to list.org, clicked on developer wiki, it's on the front page. This is veering a bit off topic now and I smell unnecessary snark. Something, btw, I'm sure happens on Discourse. ~m ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Cannot find -latomic when building for epel7 aarch64
On Sat, 2018-10-20 at 11:17 -0400, Todd Zullinger wrote: > Jonathan Dieter wrote: > > On Fri, 2018-10-19 at 21:37 -0700, Josh Stone wrote: > > > For aarch64, libatomic comes from the gcc-libraries source package, > > > which I believe only exists to provide runtime support for devtoolset. > > > It does not have libatomic.so, only libatomic.so.1 and .so.1.2.0. You > > > probably need to use devtoolset gcc to actually build+link it. > > > (Were those SCLs ever enabled for EPEL?) > > They were enabled in koji for EPEL-7. (In mock, they are > enabled for EPEL-6 as well.) > > > Ok, thanks for the explanation. Unless there's an easy BuildRequires I > > can add, I think I'll just leave duperemove out of EPEL. > > An example of using devtoolset in a spec file is here: > > > http://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dts-in.html > > I don't know if that will work out easily for your situation > or not. That did the job perfectly! Thanks for the pointer. Builds have just finished for EPEL. Jonathan signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27
https://bugzilla.redhat.com/show_bug.cgi?id=1640572 --- Comment #6 from Fedora Update System --- perl-Test-PostgreSQL-1.27-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9709d3a8fa -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1401482] biber-2.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1401482 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #29 from Fedora Update System --- biber-2.11-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-129b020cb7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1639640] Biber and texlive-biblatex versions are incompatible
https://bugzilla.redhat.com/show_bug.cgi?id=1639640 Fedora Update System changed: What|Removed |Added Status|RELEASE_PENDING |ON_QA --- Comment #5 from Fedora Update System --- biber-2.11-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-129b020cb7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Unretiring rudeconfig
On samedi 20 octobre 2018 18:13:20 CEST Ankur Sinha wrote: > Hello, > > I would like to un-retire rudeconfig[1,2]. In line with the documented > policy[3], I have submitted a new review ticket here[4]. > > Would someone like to swap reviews please? > I have reviewed and approved the package. All my owns package reviews are assigned so far. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Cannot find -latomic when building for epel7 aarch64
Sérgio Basto wrote: > I had checked mock-core-config [1] , which are in use in copr (I guess) > and can't enable developer tools . > But on koji runs well , can you review this ? please . > > I could build azureus [4] on koji [2] which need eclipse-swt , but not > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >= 3.5` > Unfortunately I didn't have much time to dig it ... Packages from the SCL repos in mock-core-configs are restricted via the following config entry¹: includepkgs=devtoolset* That limit was not included in the initial koji configuration, but my understanding was that was going to be corrected. The only packages allowed to be used (or more specifically, BuildRequired) from the SCL repos in EPEL are devtoolset*. (Feel free to follow up on epel-devel on that, as that's where the folks who know best are.) ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-core-configs/etc/mock/epel-7-x86_64.cfg#L62 -- Todd ~~ Absurdity, n. A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce, "The Devil's Dictionary" signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Cannot find -latomic when building for epel7 aarch64
On Sat, 2018-10-20 at 11:17 -0400, Todd Zullinger wrote: > Jonathan Dieter wrote: > > On Fri, 2018-10-19 at 21:37 -0700, Josh Stone wrote: > > > On 10/19/18 6:19 PM, Robert-André Mauchin wrote: > > > > On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote: > > > > > I'm trying to build duperemove[1] for epel7[2], and it's > > > > > building on > > > > > all the arches except aarch64. > > > > > > > > > > I'm BR'ing libatomic, but the error it gives in build.log[3] > > > > > for > > > > > aarch64 is: > > > > > /usr/bin/ld: cannot find -latomic > > > > > > > > > > All current Fedora release builds were fine. > > > > > > > > > > I'm sure I'm missing something obvious, but does anyone have > > > > > an idea > > > > > what's going on? > > > > > > > > > > > > > libatomic is 4.8.5 like the gcc version for other arches. > > > > On aarch64, libatomic is 8.2.1 whereas gcc is still 4.8.5. > > > > Maybe this causes some issues. > > > > > > For aarch64, libatomic comes from the gcc-libraries source > > > package, > > > which I believe only exists to provide runtime support for > > > devtoolset. > > > It does not have libatomic.so, only libatomic.so.1 and > > > .so.1.2.0. You > > > probably need to use devtoolset gcc to actually build+link it. > > > (Were those SCLs ever enabled for EPEL?) > > They were enabled in koji for EPEL-7. (In mock, they are > enabled for EPEL-6 as well.) > > > Ok, thanks for the explanation. Unless there's an easy > > BuildRequires I > > can add, I think I'll just leave duperemove out of EPEL. > > An example of using devtoolset in a spec file is here: > > http://smoogespace.blogspot.com/2018/03/using-red-hat-developer-too > lset-dts-in.html > > I don't know if that will work out easily for your situation > or not. Hi, I had checked mock-core-config [1] , which are in use in copr (I guess) and can't enable developer tools . But on koji runs well , can you review this ? please . I could build azureus [4] on koji [2] which need eclipse-swt , but not on copr `Error: No Package found for rh-eclipse46-eclipse-swt >= 3.5` Unfortunately I didn't have much time to dig it ... Many thanks, [1] https://github.com/rpm-software-management/mock/pull/222 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=29875958 [3] https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Rele ases/build/802448/ [4] https://github.com/sergiomb2/azureus/commits/master -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Sat, Oct 20, 2018 at 6:09 AM Stephen J. Turnbull wrote: > Dominik 'Rathann' Mierzejewski writes: > > Gerald B. Cox writes: > > > > Regardless, as I mentioned above, if they have a bug, then it > > > should be reported for them to address. > > > > I wouldn't call it a bug, just bad UX for a minority(?) target > > audience. > > I'm pretty sure the Discourse developers would concede that bad UX for > email users is undesirable. I'm *not* sure they would concede that > it's bad UX. We know how to render HTML to plain text, to RTF, and so > on; Discourse deliberately chose not to do so, but rather chose a > format of their own or perhaps some existing format (this is the first > I've heard of BBcode, so I can't judge). > It is not a format of their own, but it's not appropriate for plaintext, so it sounds like a bug to me. https://en.wikipedia.org/wiki/BBCode -Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unretiring rudeconfig
Hello, I would like to un-retire rudeconfig[1,2]. In line with the documented policy[3], I have submitted a new review ticket here[4]. Would someone like to swap reviews please? [1] http://rudeserver.com/config/ [2] https://src.fedoraproject.org/rpms/rudeconfig/ [3] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package [4] https://bugzilla.redhat.com/show_bug.cgi?id=1641264 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
stan writes: > So, you are really gung-ho for Discourse. IMO, that's not nasty, but it wasn't necessary and could be taken badly in context. Just, "as a proponent, I'd like to ask you" is good when things are getting heated. Your questions are important[1], and I'd like to gloss them: > What is your personal experience of using it on a project, before > and after? It would be helpful to specify the project. It's also really important to be specific about what was merely comfortable, and what directly contributed to solving problems of developing the project's software. > Did you actually see more engagement? And by whom? Developers? Users with requirements? Randos who engaged in controversy but in the end contributed neither code nor to refining requirements, specifications, or design? Did you see *less* engagement (especially of the rando type)? > Did the process of development run smoother than it had before? And if so, what aspects of the software contributed to smoothness, and how? Which parts of the process (requirements, specification, design, coding, testing, documentation) benefited specifically? Were there any aspects that were less smooth? > Did new contributors join the project you were working on? > Did experienced contributors keep contributing? > Did it help build community spirit? How did "channel culture" change? Were people more or less polite? Were experienced participants more or less likely to help on-boarding newcomers? Mentor new contributors? > Did it make *your* life easier? And for others? How might these things generalize to this list? Steve GNU Mailman Project Footnotes: [1] To Fedora in deciding to move or not, but also to Mailman to learn requirements to improve our product. "required disclosure" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
Kevin Fenzi writes: > On 10/19/18 6:43 AM, Neal Gompa wrote: > > You know why the usage numbers bear that out? Because the upgrade to > > HyperKitty was mishandled and delayed over and over. We were screwed > > over by the fact that our infrastructure doesn't run on Fedora, so > > that made it harder to get it working. The initial deployment was very > > slow and unoptimized. Bugs in the UI remained unfixed in Fedora's > > installation even though upstream fixed them. I would not be surprised > > if upstream ignores us because we don't seem to be upgrading. > > Huh, you do realize that things take as long as they take, and there's > no magic wand for 'it's magically done'. mailman3 was a massive > undertaking with a very small group of developers, many of whom were > wanting things to be really done before releasing them. Yeah, as a core Mailman developer I was really disappointed when the whole crew of Fedora/RH-supported developers just disappeared without leaving behind successors. I understand why that happens, but I wish I'd known they were able to participate only as long as they were assigned to it. Unfortunately, it's clear from the current installation supporting this list that no, they didn't get things "really done", or at least they were restricted to their direct relationship with HyperKitty -- in Fedora Postorius, even the explanatory blurbs in the user config screens are frequently incomplete (eg, lack information about current, default, and inherited values) and at least one is outright confusing (the semantics of the associated variable are the reverse of the option name). Again, I understand why such things happen, but *somebody* is going to have to commit to better care and feeding of the channel, whatever software is supporting it. We at Mailman are very happy to help. We're also a small crew of part-timers, so that's going to be limited, but at least we're aware that Fedora's is one of the most heavily-used Mailman 3 installations, so we have a strong interest in it working well! Máirín's mail to our dev list got immediate and enthusiastic reaction. But we can't help if you have no support for upgrading to upstream current release; that's not our job (unless paid, and I'm not even sure that would break our developers loose from other responsibilities and core work). I'm not sure you can count on such support from Discourse, but I have said more about that elsewhere in the thread, so I won't belabor it here. > You can always ask why we aren't upgrading. In this case it's because we > are moving stuff to python36 from 34. If these fixes are urgent let us > know and we can re-evaluate and try and get things faster. I was under > the impression that the fixes were pretty minor. HyperKitty is a fairly complex piece of software. I never did make head or tail of it (most of my time is devoted to core Mailman, especially email security such as DMARC and crypto), and there's nobody associated with the Mailman project to teach me about it anymore. To me it's not surprising that the only things people are willing to touch are minor. And even the original developers are unlikely to be familiar with the current state of upstream, as upstream has changes, some significant I think. Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Cannot find -latomic when building for epel7 aarch64
Jonathan Dieter wrote: > On Fri, 2018-10-19 at 21:37 -0700, Josh Stone wrote: >> On 10/19/18 6:19 PM, Robert-André Mauchin wrote: >>> On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote: I'm trying to build duperemove[1] for epel7[2], and it's building on all the arches except aarch64. I'm BR'ing libatomic, but the error it gives in build.log[3] for aarch64 is: /usr/bin/ld: cannot find -latomic All current Fedora release builds were fine. I'm sure I'm missing something obvious, but does anyone have an idea what's going on? >>> >>> libatomic is 4.8.5 like the gcc version for other arches. >>> On aarch64, libatomic is 8.2.1 whereas gcc is still 4.8.5. >>> Maybe this causes some issues. >> >> For aarch64, libatomic comes from the gcc-libraries source package, >> which I believe only exists to provide runtime support for devtoolset. >> It does not have libatomic.so, only libatomic.so.1 and .so.1.2.0. You >> probably need to use devtoolset gcc to actually build+link it. >> (Were those SCLs ever enabled for EPEL?) They were enabled in koji for EPEL-7. (In mock, they are enabled for EPEL-6 as well.) > Ok, thanks for the explanation. Unless there's an easy BuildRequires I > can add, I think I'll just leave duperemove out of EPEL. An example of using devtoolset in a spec file is here: http://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dts-in.html I don't know if that will work out easily for your situation or not. -- Todd ~~ The best leaders inspire by example. When that's not an option, brute intimidation works pretty well, too. -- Demotivators (www.despair.com) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On Fri, Oct 19, 2018, 18:30 Neal Gompa wrote: > On Fri, Oct 19, 2018 at 12:00 PM Gerald B. Cox wrote: > > > > On Fri, Oct 19, 2018 at 8:31 AM Chris Adams wrote: > >> > >> Once upon a time, R P Herrold said: > >> > This seems very tone deaf and lacking in introspection, Matt > >> > > >> > perhaps by reading the subject line you chose to start this > >> > thread with > >> > >> Matt didn't choose that - that subject was set by Gerald B. Cox. > >> > > As I previously mentioned with all the top-posting, excerpts and > hyperbole interjected by others people > > get lost and run with mis-quotes - perhaps Discourse could help with > that. ;-) > > > > Software is a tool for me. I don't get emotionally attached to it - as > some people apparently are. It's a bit telling that > > many people seem to be afraid that Discourse will be a success. > > > > I'm more afraid that it'll be a success with casualties. In other > words, it'll be a failure but not look like one at a glance. Driving > people away and making it harder to keep track of topics of import is > going to necessarily constrain how much people are able and willing to > do. It doesn't get simpler than that. And I have *not* seen a > Discourse instance be successful in that with large teams, much less > large groups like the development groups within Fedora. > Actually, Rust ecosystem is using discourse quite well. Both for development discussions and for user discussions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
On Sat, Oct 20, 2018 at 4:19 PM Máirín Duffy wrote: > > Check my blog, where there are even scans of the napkin sketches. Or Google > "hyperkitty ux" my blog and my outreachy interns blog pop up. Is this in response to my question? For some reason many of your emails have no quoting or context. If this is, why has the project chosen to not document that in their code/docs? That would, it seems, help contributors stay focused on the goal. regards, bex > > ~m > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
Oh and I should also point out - you shouldn't have to read all of that, the point was to make our mailing lists accessible to folks who aren't mailing list users, who are less technical, younger, etc., to be more conclusive. Same reason Discourse is being peddled here. Big diff is we keep the mail interface up for exisiting users rather than dropping them as a target!! This is why folks are trying to point out here, you may get new users w discourse but they will be different and you may lose who you have now. ~m ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Attention Gmail users, please turn off HTML mail
Check my blog, where there are even scans of the napkin sketches. Or Google "hyperkitty ux" my blog and my outreachy interns blog pop up. ~m ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Cannot find -latomic when building for epel7 aarch64
On Fri, 2018-10-19 at 21:37 -0700, Josh Stone wrote: > On 10/19/18 6:19 PM, Robert-André Mauchin wrote: > > On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote: > > > I'm trying to build duperemove[1] for epel7[2], and it's building on > > > all the arches except aarch64. > > > > > > I'm BR'ing libatomic, but the error it gives in build.log[3] for > > > aarch64 is: > > > /usr/bin/ld: cannot find -latomic > > > > > > All current Fedora release builds were fine. > > > > > > I'm sure I'm missing something obvious, but does anyone have an idea > > > what's going on? > > > > > > > libatomic is 4.8.5 like the gcc version for other arches. > > On aarch64, libatomic is 8.2.1 whereas gcc is still 4.8.5. > > Maybe this causes some issues. > > For aarch64, libatomic comes from the gcc-libraries source package, > which I believe only exists to provide runtime support for devtoolset. > It does not have libatomic.so, only libatomic.so.1 and .so.1.2.0. You > probably need to use devtoolset gcc to actually build+link it. > (Were those SCLs ever enabled for EPEL?) Ok, thanks for the explanation. Unless there's an easy BuildRequires I can add, I think I'll just leave duperemove out of EPEL. Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Building Steam Proton on Fedora
On Fri, Oct 19, 2018 at 5:15 PM Kamil Paral wrote: > > I don't know how to build Proton and the people who reported Proton works for > them on Fedora are simply referring to the bundled Proton in Steam > installation, I believe. Makes sense! And this is exactly what I'm trying to avoid... Non-free RPM downloading more code to run off the internet. > However, it should be possible to use Steam-bundled Proton to run arbitrary > Windows executables, not just those provided by Steam, if you don't mind some > tinkering: > > https://www.reddit.com/r/SteamPlay/comments/99z9o9/running_games_standalone_via_proton/e4rr7rv/ > https://www.reddit.com/r/Steam/comments/99fjzw/steam_proton_for_non_steam_applications/ > https://www.reddit.com/r/SteamPlay/comments/9bhvxh/how_do_i_run_a_non_steam_game_with_proton/ > https://www.reddit.com/r/SteamPlay/comments/9anque/steamplayprotonlutris_cheat_sheet/ > https://github.com/ValveSoftware/Proton/issues/260#issuecomment-427607859 > https://forum.level1techs.com/t/windows-games-on-steam-for-linux-proton-client-testing-grounds/131219/71 > > I haven't personally tried that. The new README and docker-based setup got me further but still nowhere. I'm surprised that after installing the docker package there is no group of the eponymous persuasion. That makes the whole privileges awkward and with no surprise (being Debian-based) the build system is not SELinux-friendly. I'll let a couple weeks pass and revisit this again, thanks for the links. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
Required disclosure: Mailman dev, and my sympathies are with the list advocates for this channel both for that reason, and for more objective ones. I don't really argue against a move to Discourse here, but I do know a bit about the problem space, and I'd like to discuss *some* aspects here. I expect it's clear which I prefer, but there are a lot of arguments "for" that I don't deal with. Dominik 'Rathann' Mierzejewski writes: > Gerald B. Cox writes: > > Regardless, as I mentioned above, if they have a bug, then it > > should be reported for them to address. > > I wouldn't call it a bug, just bad UX for a minority(?) target > audience. I'm pretty sure the Discourse developers would concede that bad UX for email users is undesirable. I'm *not* sure they would concede that it's bad UX. We know how to render HTML to plain text, to RTF, and so on; Discourse deliberately chose not to do so, but rather chose a format of their own or perhaps some existing format (this is the first I've heard of BBcode, so I can't judge). Thus, I doubt that reporting an issue against Discourse's email functionality would get action any time soon from the developers, and might get a lot of pushback. Given that support from Red Hat/Fedora community for Mailman development has decreased dramatically, I don't see why they would want to pick up responsibility for patching up Discourse instead. So I see years of annoyance for those who have really effective email workflows, being constrained to Discourse's. I suspect that the number of people who really want email is at least as big as those who really want a forum, and they probably contribute more code and admin (which are typically communication-intensive, multicast activities), though forum-oriented users may contribute greatly in other ways (user support has been mentioned, and I wouldn't be surprised if that's easier both for the OP and responders in forum format -- synchronous communication does a lot of work to avoid redundancy, and editing out mistaken information is a real feature for user support). And I suppose there are a lot of people in the middle who don't care much either way (ignoring costs of moving to a new channel, which are significant in the short run but not really in the long run IMO), probably a majority. Gerald's personal anecdotes suggest that people who are weakly attached to the channel (jumping into threads in the middle, signing up for their one issue, etc) are going to find the forum format more convenient. I find his discussion persuasive on that, as I have no problem with the forum format when I have a drive-by interest in some channel. This is *not* a put-down, it's simply a statement that a certain group of users would probably be happier with a forum. (I'm not sure user support is a goal of this channel, but I've seen many threads devoted to issues of system configuration that have zero likelihood of inducing development of Fedora.) > > Mailing list mode has been out for several years now - seems to > > me if this were a pervasive issue with a published standardize > > solution, they should take care of it. Email doesn't have a standardized solution or standardized format for content. That's why people like HTML email -- it's a quasi-standard mess that browsers and browser-derived messaging clients have huge code bases for handling, and 25 years on have gotten pretty good at it. Most clients' outgoing messages now are pretty close to HTML 5 conformant, but there's still a huge mismatch with "traditional" email clients because email standards use a different mechanism from HTML for embedding objects in the data stream. (That may not be a big problem with Discourse depending on how it handles such media, and how the lists are configured.) The standards that have been referred to are SMTP (RFC 5321, which basically requires that if you accept a connection at the TCP level, you should say you're refusing to accept mail rather than dropping it silently), the Internet message format (RFC 5322, which basically defines email as an ASCII text stream divided into a header containing various metadata and a body), and the Multimedia Mail Extensions (MIME, with a plethora of RFCs starting with the 2045-2049 series) which define ways to encode non-ASCII data (both text and non-text), ways to include non-text data, and ways to mix various media, in a message body. Among the latter is the multipart/alternative body part (defined in RFC 2046, IIRC), which allows catering to various user agents, and does require that the alternatives have as close to the same semantics as the media make possible. This provision of RFC 2046 is violated by a lot of HTML-oriented clients, which embed attachments in the HTML where they can't easily be accessed by non-HTML clients, or even provide a plain text alternative that says "use an HTML client", rather than a plain text version of the HTML content. I don't think that's a problem with
Re: Attention Gmail users, please turn off HTML mail
On Sat, Oct 20, 2018 at 12:29 AM Máirín Duffy wrote: > > > > I just couldn't use it for day-to-day communication. Not necessarily any > > single thing, but lots and lots of fundamentals. How do I get a list of new > > threads? How do I get a list of threads I've read but which have new > > responses, and ideally show only the new responses? How can I mute a thread > > I don't want to be alerted on? How do I get to the next thread from the > > *bottom* of a thread I just read? How can I search... usefully at all? My > > point isn't to rag on HyperKitty, but I could definitely go on. > > Please do. Neal and I are starting up an effort. I reached out to Abhilash, > the upstream lead, last night on the devel list and he was very responsive to > this idea. He's already created a gitlab subproject for our efforts upstream. > > > I tried for a while to file suggestions and bug reports, but especially > > after the extra two years it took to even get deployed, it was *very* clear > > there were no resources for ongoing development from Red Hat, no significant > > non-RH Fedora development, and no meaningful outside development either. > > Basic things like https://gitlab.com/mailman/hyperkitty/issues/64 didn't > > even get *responses*. So, I stuck with my previous email client setup. > > > > And the thing is, it's *not just me*. Take a look at > > > > It is the 19th of the month. Not a single vote on our most busy mailing > > list. The same is true for every other list I looked at. People just aren't > > using this. > > Matthew, the target user for Hyperkitty isn't a devel-list reader. Can you share more information about the target audience? I read through the non-install docs at hyperkitty.readthedocs.io which is where the Gitlab project sent me. I could only find statements about the shortcomings with Pipermail the project was trying to fix. I did not see a target user statement or find one for Pipermail. Thanks, bex > > ~m > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
Gerald B. Cox wrote:
> On Fri, Oct 19, 2018 at 8:31 AM Chris Adams wrote:
> > Once upon a time, R P Herrold said:
> > > perhaps by reading the subject line you chose to start this
> > > thread with
> >
> > Matt didn't choose that - that subject was set by Gerald B. Cox.
> >
> > As I previously mentioned with all the top-posting, excerpts and hyperbole
> interjected by others people
> get lost and run with mis-quotes - perhaps Discourse could help with that.
Moments before I read this I checked for myself who had changed the
subject line. It took me about five seconds to scroll up in the tree
view, find the point where the subject changed, and read the name on
the same line. Having just done that so easily, I can really appreciate
how utterly misdirected your remark is.
If it's difficult for you to check who wrote a subject line, then your
problem is that you're trying to read a mailing list through a user
agent that isn't up to the task. And, speaking of misquotes, the
misattributed line that can be seen above ("As I previously ...") is a
visible indication that you're not using one of the better Mail User
Agents.
Humans will always misremember things, and not bother to check because
they think they remember. No technology is going to help with that
until we get direct neural interfaces.
Björn Persson
pgp8_Oolc_3BC.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
