Release monitoring for COPR
What's the best way to monitor for new releases on a package in copr? I know the release-monitoring.org has "COPR" as a distribution that it knows about, but I'm not sure if that's the same as the copr repositories we have available. I'm also not sure how to tell it which package in which project (nor where it will put its bugs). Does anyone have guidance on this, or their favorite tool to use? --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for Wednesday's FPC Meeting (2018-03-21 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Wednesday at 2018-03-21 17:00 UTC in #fedora-meeting-2 on irc.freenode.net. Local time information (via. uitime): = Day: Wednesday = 2018-03-21 10:00 PDT US/Pacific 2018-03-21 13:00 EDT --> US/Eastern <-- 2018-03-21 17:00 GMT Europe/London 2018-03-21 17:00 UTC UTC 2018-03-21 18:00 CET Europe/Berlin 2018-03-21 18:00 CET Europe/Paris 2018-03-21 22:30 IST Asia/Calcutta --- New Day: Thursday 2018-03-22 01:00 HKT Asia/Hong_Kong 2018-03-22 01:00 +08 Asia/Singapore 2018-03-22 02:00 JST Asia/Tokyo 2018-03-22 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #691 noarch *sub*packages with arch-specific dependencies .fpc 691 https://pagure.io/packaging-committee/issue/691 #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #694 Packaging guidelines for application independence .fpc 694 https://pagure.io/packaging-committee/issue/694 #topic #702 C/C++ guidelines should say using clang needs an exception .fpc 702 https://pagure.io/packaging-committee/issue/702 #topic #708 Allocating a static uid and gid for openvswitch .fpc 708 https://pagure.io/packaging-committee/issue/708 #topic #710 Ruby packaging guidelines update .fpc 710 https://pagure.io/packaging-committee/issue/710 #topic #713 Forward-looking conditionals by default .fpc 713 https://pagure.io/packaging-committee/issue/713 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #715 Separately building package documentation .fpc 715 https://pagure.io/packaging-committee/issue/715 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #723 Guidelines for handling deprecated dependencies during review .fpc 723 https://pagure.io/packaging-committee/issue/723 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 #topic #743 Add link to C/C++ build flag documentation in redhat-rpm-config .fpc 743 https://pagure.io/packaging-committee/issue/743 = 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&tags=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, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Dropping python2-xcffib
Hey, y'all. As far as I know, qtile is the only package that depends on python3-xcffib, and nothing depends on the python2- subpackage. Accordingly, I am have dropped the python2-subpackage in Rawhide. -- Dulaney. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swaps
Ok..I'll do json one when I get home On Mar 20, 2018 5:19 PM, "Jared K. Smith" wrote: > On Tue, Mar 20, 2018 at 5:02 PM, Jared K. Smith > wrote: > >> I have done all of them except for golang-github-ncw-dropbox-sdk- >> unofficial and golang-github-bitly-simplejson . >> > > I've now finished golang-github-ncw-dropbox-sdk-unofficial as well. > > -Jared > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28-20180320.n.0 compose check report
No missing expected images. Failed openQA tests: 10/137 (x86_64), 5/23 (i386), 1/2 (arm) ID: 208287 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/208287 ID: 208323 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/208323 ID: 208324 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/208324 ID: 208325 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/208325 ID: 208326 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208326 ID: 208338 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/208338 ID: 208342 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/208342 ID: 208343 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208343 ID: 208344 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/208344 ID: 208357 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/208357 ID: 208391 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/208391 ID: 208404 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/208404 ID: 208430 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/208430 ID: 208438 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/208438 ID: 208439 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/208439 ID: 208480 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/208480 Soft failed openQA tests: 10/137 (x86_64), 2/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 208301 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/208301 ID: 208302 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/208302 ID: 208307 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/208307 ID: 208308 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208308 ID: 208318 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/208318 ID: 208321 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208321 ID: 208330 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/208330 ID: 208367 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/208367 ID: 208393 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/208393 ID: 208395 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/208395 ID: 208415 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/208415 ID: 208418 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/208418 Passed openQA tests: 101/137 (x86_64), 16/23 (i386) Skipped openQA tests: 16 of 162 -- 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 Rawhide-20180320.n.0 compose check report
No missing expected images. Failed openQA tests: 14/137 (x86_64), 6/23 (i386), 1/2 (arm) ID: 208077 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/208077 ID: 208085 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/208085 ID: 208086 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/208086 ID: 208087 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/208087 ID: 208088 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208088 ID: 208092 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/208092 ID: 208100 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/208100 ID: 208104 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/208104 ID: 208105 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208105 ID: 208106 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/208106 ID: 208146 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/208146 ID: 208147 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/208147 ID: 208153 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/208153 ID: 208157 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/208157 ID: 208158 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/208158 ID: 208166 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/208166 ID: 208180 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/208180 ID: 208192 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/208192 ID: 208197 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/208197 ID: 208200 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/208200 ID: 208201 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/208201 Soft failed openQA tests: 8/137 (x86_64), 4/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 208049 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/208049 ID: 208063 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/208063 ID: 208064 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/208064 ID: 208069 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/208069 ID: 208070 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208070 ID: 208080 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/208080 ID: 208083 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/208083 ID: 208084 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/208084 ID: 208129 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/208129 ID: 208156 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/208156 ID: 208184 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/208184 ID: 208199 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/208199 Passed openQA tests: 108/137 (x86_64), 13/23 (i386) Skipped openQA tests: 7 of 162 -- 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
Re: Review swaps
On Tue, Mar 20, 2018 at 5:02 PM, Jared K. Smith wrote: > I have done all of them except for golang-github-ncw-dropbox-sdk- > unofficial and golang-github-bitly-simplejson . > I've now finished golang-github-ncw-dropbox-sdk-unofficial as well. -Jared ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swaps
On Tue, Mar 20, 2018 at 4:38 PM, djb djb wrote: > Jared, which ones have you so far? > I have done all of them except for golang-github-ncw-dropbox-sdk-unofficial and golang-github-bitly-simplejson . > I would like to do: > > Review Request: golang-github-bitly-simplejson - Go package to interact > with arbitrary JSON > https://bugzilla.redhat.com/s > how_bug.cgi?id=1555345 > > if you have not done that one so far. > Please go ahead! -Jared ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Review swaps
Jared, which ones have you so far? I would like to do: Review Request: golang-github-bitly-simplejson - Go package to interact with arbitrary JSON https://bugzilla.redhat.com/ show_bug.cgi?id=1555345 if you have not done that one so far. Thanks On Sat, Mar 17, 2018 at 4:28 AM, Nicolas Mailhot < nicolas.mail...@laposte.net> wrote: > Le vendredi 16 mars 2018 à 17:33 -0400, Jared K. Smith a écrit : > > On Fri, Mar 16, 2018 at 12:53 PM, Robert-André Mauchin > com> wrote: > > > I'm looking for some help to review some Golang packages. These are > > > all renamed packages to conform with the new Golang guidelines which > > > standardizes package names. These are super simple devel only > > > package and shouldn't pose any issue. > > > > I've done about half of these, and will try to get to the rest of them > > by early next week. > > Thanks a lot! > (I'll try to look at it too but I'm still mass-rebuilding and mass- > fixing other Go specs) > > Please fill issues about anything broken you find out in the new macros. > I'll prioritize those if they can be fixed at my level. > > Regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On Tue, 2018-03-20 at 10:09 +0100, Dan Horák wrote: > All the tests can be green if the "important" ones are missing, they > > don't show :( > > I suspect the problem of missing tests is that dist.rpmdeplint is > run on x86_64 only, but my update is for s390x only. So bodhi shouldn't > rely on a result of a test that is intentionally skipped/omitted. That sounds entirely plausible, and very like a case no-one had considered till now. Can you file it somewhere? I think probably greenwave would be the best place, at least for starters; it's hard to think offhand how we'd ultimately choose to fix this. Thanks! -- 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
'endless' stream of "greenwave is a GO on glusterfs-4.0.0-2...." emails
I've rec'd about 30 of these in the last hour or so, fedora-28, fedora-27, fedora-26, and fedora-28-modular. Would someone please make them stop Thanks -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 compose report: 20180320.n.0 changes
OLD: Fedora-28-20180319.n.0 NEW: Fedora-28-20180320.n.0 = SUMMARY = Added images:2 Dropped images: 3 Added packages: 2 Dropped packages:0 Upgraded packages: 122 Downgraded packages: 0 Size of added packages: 1.97 MiB Size of dropped packages:0 B Size of upgraded packages: 1.47 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -19.56 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: AtomicHost qcow2 aarch64 Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180320.n.0.aarch64.qcow2 Image: AtomicHost raw-xz aarch64 Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180320.n.0.aarch64.raw.xz = DROPPED IMAGES = Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-28-20180319.n.0.s390x.qcow2 Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-28-20180319.n.0.s390x.tar.xz Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-28-20180319.n.0.s390x.raw.xz = ADDED PACKAGES = Package: gnome-tweaks-3.28.0-1.fc28 Summary: Customize advanced GNOME 3 options RPMs:gnome-tweaks Size:326.83 KiB Package: gnome-usage-3.28.0-1.fc28 Summary: A GNOME app to view information about use of system resources RPMs:gnome-usage Size:1.65 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: PackageKit-1.1.9-2.fc28 Old package: PackageKit-1.1.9-1.fc28 Summary: Package management service RPMs: PackageKit PackageKit-command-not-found PackageKit-cron PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin PackageKit-gtk3-module Size: 8.45 MiB Size change: 11.80 KiB Changelog: * Mon Mar 12 2018 Kalev Lember - 1.1.9-2 - Don't abort on daemon startup for invalid .repo files Package: adwaita-icon-theme-3.28.0-1.fc28 Old package: adwaita-icon-theme-3.27.90-1.fc28 Summary: Adwaita icon theme RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel Size: 12.06 MiB Size change: 1.04 KiB Changelog: * Wed Mar 14 2018 Kalev Lember - 3.28.0-1 - Update to 3.28.0 Package: aisleriot-1:3.22.5-1.fc28 Old package: aisleriot-1:3.22.4-3.fc28 Summary: A collection of card games RPMs: aisleriot Size: 41.33 MiB Size change: 8.26 KiB Changelog: * Mon Mar 12 2018 Kalev Lember - 1:3.22.5-1 - Update to 3.22.5 Package: anaconda-28.22.2-4.fc28 Old package: anaconda-28.22.2-3.fc28 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 22.45 MiB Size change: 6.78 KiB Changelog: * Thu Mar 15 2018 Martin Kolman - 28.22.2-4 - Don't autoquit by default if the last hub is empty (#1553935) (mkolman) Package: anjuta-1:3.28.0-1.fc28 Old package: anjuta-1:3.26.0-5.fc28 Summary: GNOME IDE for various programming languages (including C/C++, Python, Vala and JavaScript) RPMs: anjuta anjuta-devel Size: 41.77 MiB Size change: 156.20 KiB Changelog: * Sun Mar 11 2018 Kalev Lember - 1:3.28.0-1 - Update to 3.28.0 - Remove ldconfig scriptlets Package: at-spi2-atk-2.26.2-1.fc28 Old package: at-spi2-atk-2.26.1-1.fc28 Summary: A GTK+ module that bridges ATK to D-Bus at-spi RPMs: at-spi2-atk at-spi2-atk-devel Size: 743.48 KiB Size change: 7.17 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 2.26.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Tue Mar 13 2018 Kalev Lember - 2.26.2-1 - Update to 2.26.2 Package: at-spi2-core-2.28.0-1.fc28 Old package: at-spi2-core-2.27.1-1.fc28 Summary: Protocol definitions and daemon for D-Bus at-spi RPMs: at-spi2-core at-spi2-core-devel Size: 2.12 MiB Size change: 7.04 KiB Changelog: * Tue Dec 19 2017 Kalev Lember - 2.27.1-2 - Drop unused buildrequires * Wed Feb 07 2018 Fedora Release Engineering - 2.27.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Mon Mar 12 2018 Kalev Lember - 2.27.92-1 - Update to 2.27.92 * Tue Mar 13 2018 Kalev Lember - 2.28.0-1 - Update to 2.28.0 Package: atk-2.28.1-1.fc28 Old package: atk-2.27.1-2.fc28 Summary: Interfaces for accessibility support RPMs: atk atk-devel Size: 3.15 MiB Size change: 6.40 KiB Changelog: * Wed Feb 07 2018 Fedora Release Engineering - 2.27.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Mon Mar 12 2018 Kalev Lember - 2.28.0-1 - Update to 2.28.0 * Tue Mar 13 2018 Kalev Lember - 2.28.1-1 - Update to 2.28.1 Package: baobab-3.28.0-1.fc28 Old package: baobab-3.27.90-1.fc28 Summary: A graphical directory tree analyzer RPMs: baobab Size: 2.81 MiB Size change: 35.20 KiB Changelog: * Mon Mar 12 2018 Ka
[Test-Announce] Fedora 28 Branched 20180320.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 28 Branched 20180320.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20180314.n.2: anaconda-28.22.2-3.fc28.src, 20180320.n.0: anaconda-28.22.2-4.fc28.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/28 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180320.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Python 3.7
Congratulations! signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora rawhide compose report: 20180320.n.0 changes
OLD: Fedora-Rawhide-20180319.n.0
NEW: Fedora-Rawhide-20180320.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 30
Dropped packages:3
Upgraded packages: 107
Downgraded packages: 0
Size of added packages: 169.85 MiB
Size of dropped packages:57.34 MiB
Size of upgraded packages: 4.15 GiB
Size of downgraded packages: 0 B
Size change of upgraded packages: -91.41 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: Container_Minimal_Base docker s390x
Path:
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180320.n.0.s390x.tar.xz
Image: Python_Classroom raw-xz armhfp
Path:
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20180320.n.0-sda.raw.xz
= DROPPED IMAGES =
= ADDED PACKAGES =
Package: R-AUC-0.3.0-1.fc29
Summary: Threshold independent performance measures for probabilistic
classifiers
RPMs:R-AUC
Size:55.38 KiB
Package: R-R.methodsS3-1.7.1-2.fc29
Summary: S3 Methods Simplified
RPMs:R-R.methodsS3
Size:77.16 KiB
Package: R-RcppCCTZ-0.2.3-2.fc29
Summary: 'Rcpp' Bindings for the 'CCTZ' Library
RPMs:R-RcppCCTZ
Size:604.24 KiB
Package: R-bindr-0.1.1-1.fc29
Summary: Parametrized Active Bindings
RPMs:R-bindr
Size:22.33 KiB
Package: R-coda-0.19.1-1.fc29
Summary: Output Analysis and Diagnostics for MCMC
RPMs:R-coda
Size:226.93 KiB
Package: R-debugme-1.1.0-1.fc29
Summary: Debug R Packages
RPMs:R-debugme
Size:976.00 KiB
Package: R-dichromat-2.0.0-1.fc29
Summary: Color Schemes for Dichromats
RPMs:R-dichromat
Size:154.05 KiB
Package: R-fortunes-1.5.4-1.fc29
Summary: R Fortunes
RPMs:R-fortunes
Size:204.85 KiB
Package: R-iterators-1.0.9-1.fc29
Summary: Provides Iterator Construct for R
RPMs:R-iterators
Size:318.21 KiB
Package: R-lazyeval-0.2.1-1.fc29
Summary: Lazy (Non-Standard) Evaluation
RPMs:R-lazyeval
Size:884.05 KiB
Package: R-pdftools-1.5-2.fc29
Summary: Text Extraction, Rendering and Converting of PDF Documents
RPMs:R-pdftools
Size:563.37 KiB
Package: R-polyclip-1.6.1-1.fc29
Summary: Polygon Clipping
RPMs:R-polyclip
Size:526.72 KiB
Package: R-rematch-1.0.1-1.fc29
Summary: Match Regular Expressions with a Nicer 'API'
RPMs:R-rematch
Size:20.22 KiB
Package: R-rstudioapi-0.7-1.fc29
Summary: Safely Access the RStudio API
RPMs:R-rstudioapi
Size:129.61 KiB
Package: R-rversions-1.0.3-1.fc29
Summary: Query 'R' Versions, Including 'r-release' and 'r-oldrel'
RPMs:R-rversions
Size:23.39 KiB
Package: R-scatterplot3d-0.3.41-2.fc29
Summary: 3D Scatter Plot
RPMs:R-scatterplot3d
Size:320.45 KiB
Package: R-selectr-0.3.2-1.fc29
Summary: Translate CSS Selectors to XPath Expressions
RPMs:R-selectr
Size:179.01 KiB
Package: R-stringdist-0.9.4.7-1.fc29
Summary: Approximate String Matching and String Distance Functions
RPMs:R-stringdist
Size:899.42 KiB
Package: R-whisker-0.3.2-1.fc29
Summary: {{mustache}} for R, logicless templating
RPMs:R-whisker
Size:56.92 KiB
Package: glusterd2-4.0.0-2.fc29
Summary: The GlusterFS management daemon (preview)
RPMs:glusterd2
Size:37.74 MiB
Package: perl-Graphics-ColorUtils-0.17-1.fc29
Summary: Easy-to-use color space conversions and more
RPMs:perl-Graphics-ColorUtils
Size:29.08 KiB
Package: perl-Spreadsheet-ParseXLSX-0.27-1.fc29
Summary: Parse XLSX files
RPMs:perl-Spreadsheet-ParseXLSX
Size:30.88 KiB
Package: python-astropy-healpix-0.2-1.fc29
Summary: HEALPix for Astropy
RPMs:python3-astropy-healpix
Size:1.40 MiB
Package: python-pytest-arraydiff-0.2-1.fc29
Summary: The py.test arraydiff plugin
RPMs:python3-pytest-arraydiff
Size:20.89 KiB
Package: python-pytest-astropy-0.2.1-1.fc29
Summary: The py.test astropy plugin
RPMs:python3-pytest-astropy
Size:11.38 KiB
Package: python-pytest-doctestplus-0.1.2-1.fc29
Summary: The py.test doctestplus plugin
RPMs:python3-pytest-doctestplus
Size:27.78 KiB
Package: python-pytest-openfiles-0.2.0-1.fc29
Summary: The py.test openfiles plugin
RPMs:python3-pytest-openfiles
Size:15.56 KiB
Package: python-pytest-remotedata-0.2.0-1.fc29
Summary: The py.test remotedata plugin
RPMs:python3-pytest-remotedata
Size:19.25 KiB
Package: python2-astropy-2.0.5-2.fc29
Summary: A Community Python Library for Astronomy
RPMs:python2-astropy python2-astropy-doc
Size:123.17 MiB
Package: safetyblanket-1.01-2.fc29
Summary: Creepy blanket simulator
RPMs:safetyblanket
Size:1.28 MiB
= DROPPED PACKAGES =
Package: ardour4-4.7.0-11.fc29
Summary: Digital Audio Workstation
RPMs:ardour4 ardour4-audiobackend-alsa ardour4-audiobackend-dummy
ardour4-audiobackend-jack
Size:56.83 MiB
Package: jackson-dataformat-yaml-2.7.6-3.fc27
Summary: Jackson module to add YAML back-end (parser/generator adapters)
RPMs:jackson-dataformat-yaml-javado
Re: COPR src.fp.o auto-rebuilds
On Tue, Mar 20, 2018 at 2:54 PM, Miro Hrončok wrote: > On 20.3.2018 14:33, Michal Novotny wrote: >> >> Hello, >> >> On Tue, Mar 20, 2018 at 1:55 PM, Miro Hrončok wrote: >>> >>> On 27.2.2018 00:04, Michal Novotny wrote: Hello, you can now very easily setup auto-rebuilds for your src.fp.o package: 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork (please, use the https:// cloning option) 2) make sure "Webhook Rebuild" checkbox is checked when you are creating the package 3) Go to settings for your package at src.fp.o and almost at the bottom in Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update" button. >>> >>> >>> >>> This is awesome! Thanks. >>> >>> I've pushed several commits at once and copr triggered a build for every >>> one >>> of them. It would make sense in my POV to only trigger once per push. Is >>> there a technical reason for current behavior, or is it intentional? >> >> >> This is probably not intentional. I would need to check the fedmsgs >> that triggered the >> builds. If there was just a single originating message, then it is a >> bug. Otherwise, something >> on DistGit side would need to be optimized. >> > > https://apps.fedoraproject.org/datagrepper/raw?user=churchyard > see 2018-03-20 12:51:50 git.receive messages Right, I think these were mostly pushed to the main (not-forked) DistGit repos? For main repos, the original DistGit fedmsg is generated (e.g. https://apps.fedoraproject.org/datagrepper/id?id=2018-4121a27f-c72b-43d7-92b2-044095bb67e7&is_raw=true&size=extra-large) and the original DistGit fedmsgs are always just for a single commit (stored in rev field). Whereas if you push to a fork, a pagure fedmsg is generated and that fedmsg can group several commits together (related message fields are start_commit and end_commit). We would need to e.g. allow sending pagure fedmsgs even for pushes into the main repos to be able to build just once per a push event. However, (while it is not exactly necessary) it's not that bad to have ever single commit build in COPR, I think :). clime > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Tue, Mar 20, 2018 at 3:18 PM, Kamil Paral wrote: > On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza wrote: > >> Your tool can use good old buildsys.build.state.change fedmsg with the >> well known name/version/release fields like this: >> >> https://apps.stg.fedoraproject.org/datagrepper/raw?topic= >> org.fedoraproject.stg.buildsys.build.state.change >> > > Initially I was very concerned about the idea of having to query Koji for > each module to get NSVC, because in Taskotron we run ten thousand tasks per > day and every unnecessary network request means slower execution, higher > risk of failure and more logs to debug. We try to minimize the number of > network requests as much as we can. However, if the structured metadata > is/will be available in fedmsgs, I think I don't have a use case at hand > that I could use to object to this. I still think it's a bad idea, though, > and will bite us in the long run. > > >> >> That's staging, because it's easier for me to find the module builds >> there :). >> >> Unfortunatelly, Koji does not add "type" field there, so you cannot find >> out if that's module or not. >> > > Is that something that will get resolved soon? Because it seems like a big > blocker to any automated processing. If we want to run some tasks just on > rpms and some tasks just on modules, how do we distinguish that? > You can query the Koji for build id and check the type of a build. I don't think that feature request is even reported to Koji upstream, because nobody needed that and I found that yesterday. It is however not new situation. There is the same "issue" for "images". If you want to run some tasks just for RPMs and not for images, you have to do the filtering like this anyway. Therefore I don't really consider this as real blocker which needs fix urgently. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny wrote: > The question here is why don't we actually implement the modularity > the simple way. > > Let's suppose I would like to make nodejs-8 available in EPEL7. > > The most effortless way would be to create subdirectory called 8 at > src.fedoraproject.org/rpms/nodejs > with the updated spec file and sources for the bumped major version of > the nodejs package. > What if your module contains packages coming from multiple SRPMs and they depend on each other? Jan Kaluza > > For fedpkg to be able to upload and download sources for that > subdirectory (submodule), the attached > single-line patch is needed in python-rpkg. There are a few more > changes needed to make srpm > importing work but it should be basically almost done as well. > > Koji then just needs to learn how to build DistGit repositories > containing submodules where > submodule is any subdirectory containing a spec file. When Koji > discovers all the submodules > in a repository, it can start an srpm and a consequent rpm build for > each of them. > > It is a very similar approach to what find_packages from python > setuptools implements. It > recognizes subpackages based on the presence of __init__.py file. The > only difference here > is that we will be recognizing subpackages (=submodules) by the > presence of *.spec file. > > Everything else should be pretty much the same otherwise. Koji builds > nodejs-6 and nodejs-8 rpms > both with el7 disttag and both of these can go through the Bodhi > update process separately. > > Of course, the question is if you can actually build and run nodejs-8 > in EL7 successfully but > I think that will always be a problem no matter what the implementation is. > > clime > > On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza wrote: > > > > > > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson > > wrote: > >> > >> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote: > >> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote: > >> > > So you think having to send a request to a web service instead of > just > >> > > parsing a string locally with one line of code is a good trade-off > for > >> > > allowing dashes? > >> > > >> > This has been mentioned several times in this thread and I think > there's > >> > a misunderstanding around this. > >> > > >> > So: When your tool/whatever works with modules it will have to have > >> > module metadata available in some form. > >> > >> What if I don't want to work with modules at all, just with information > >> about modules? > >> > >> What if I just want to write a tool that parses fedmsgs about module > >> builds in Koji and does something that depends on module names, streams > >> and versions? (e.g. some sort of changelog thing) > > > > > > Your tool can use good old buildsys.build.state.change fedmsg with the > well > > known name/version/release fields like this: > > > > https://apps.stg.fedoraproject.org/datagrepper/ > raw?topic=org.fedoraproject.stg.buildsys.build.state.change > > > > That's staging, because it's easier for me to find the module builds > there > > :). > > > > Unfortunatelly, Koji does not add "type" field there, so you cannot find > out > > if that's module or not. But in case your tool is doing general changelog > > per Koji build, it will work quite well with modules without you even > > noticing you are working with modules. > > > > In case of tools, you can even query koji using its api and pass the > > name/version/release there, instead of NVR. > > > > If you query Koji for the module build, you will actually find whole > module > > metadata in "extra" part of the build. > > > > In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils > > already sent in this thread. > > > > Regards, > > Jan Kaluza > > > >> -- > >> 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 > > > > > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On 03/20/2018 10:18 AM, Ralph Bean wrote: > FWIW, greenwave does supply the list of missing and/or failed testcase > names in its API response back to Bodhi. Surfacing those more > granular details in the Bodhi UI would be good. I filed an issue about this: https://github.com/fedora-infra/bodhi/issues/2227 signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza wrote: > Your tool can use good old buildsys.build.state.change fedmsg with the > well known name/version/release fields like this: > > https://apps.stg.fedoraproject.org/datagrepper/ > raw?topic=org.fedoraproject.stg.buildsys.build.state.change > Initially I was very concerned about the idea of having to query Koji for each module to get NSVC, because in Taskotron we run ten thousand tasks per day and every unnecessary network request means slower execution, higher risk of failure and more logs to debug. We try to minimize the number of network requests as much as we can. However, if the structured metadata is/will be available in fedmsgs, I think I don't have a use case at hand that I could use to object to this. I still think it's a bad idea, though, and will bite us in the long run. > > That's staging, because it's easier for me to find the module builds there > :). > > Unfortunatelly, Koji does not add "type" field there, so you cannot find > out if that's module or not. > Is that something that will get resolved soon? Because it seems like a big blocker to any automated processing. If we want to run some tasks just on rpms and some tasks just on modules, how do we distinguish that? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On Mon, Mar 19, 2018 at 12:23:49PM -0700, Adam Williamson wrote: > On Mon, 2018-03-19 at 15:57 +0100, Pierre-Yves Chibon wrote: > > On Mon, Mar 19, 2018 at 03:41:15PM +0100, Dan Horák wrote: > > > On Mon, 19 Mar 2018 14:06:56 +0100 > > > Dan Horák wrote: > > > > > > > On Sun, 18 Mar 2018 20:25:31 +0100 > > > > Fabio Valentini wrote: > > > > > > > > > On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth > > > > > wrote: > > > > > > On 03/18/2018 01:02 PM, Fabio Valentini wrote: > > > > > > > > > > > > > > I've looked at waiverdb-cli too, but since no tests seem to have > > > > > > > run at all, it looks like the wrong tool for the job: > > > > > > > I don't want to push an update despite a failed test, I want to > > > > > > > push my update despite no test data being available ... > > > > > > > > > > > > > > > > > > Randy said the tests refresh every 6 hours and/or every time the > > > > > > update is edited. Neither seemed to have occurred for you. > > > > > > > > > > Exactly. The "no test results found" status in bodhi hasn't been > > > > > refreshed in over 10 days now. > > > > > > > > > > Bodhi also displays that all these tests were successful, bit still > > > > > blocks the update because "no test results found", which is > > > > > obviously just wrong. > > > > > > > > > > A manual lookup in resultdb shows me that the tests have in fact > > > > > been run and have all passed: > > > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is in > > > > the same situation, all tests are green, but "no test results found" > > > > is reported. It's not very user friendly ... > > > > > > and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 is > > > even more interesting with "The update can not be pushed: 1 of 2 > > > required tests not found", but the listed tests are again all green. No > > > idea what's missing from the output. > > > > All the tests can be green if the "important" ones are missing, they don't > > show > > :( > > > > The important ones are the ones defined in the policy that gates packages > > and > > are listed here: https://fedoraproject.org/wiki/CI/gating_updates > > > > waiverdb-cli should now support waiving missing results, I'm > > double-checking it > > and see if we can document it at: > > https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests > > next to the other examples. > > It is also still the case that unpushing and re-pushing the update > should re-trigger the tests in Taskotron, at the cost of re-setting the > karma and 'wait time' clocks for the update (so you'll need to either > get positive karma or wait 7 or 14 days before being able to push it, > from the time of the re-push). > > One obvious easy win here would be to change the "No test results > found" text, as it's clearly confusing. It could be something like "No > results found for blocking tests", perhaps? We could even give Bodhi > the ability to list the names of the 'expected' blocking tests, and > have the text show that somehow, whether as a hyperlink or perhaps just > as a mouseover or something? Yeah, the text is misleading. Greenwave supplies that "summary" line, and agreed - it should be updated to be more informative on its own. This came up in decathorpe's issue thread here: https://pagure.io/greenwave/issue/141 FWIW, greenwave does supply the list of missing and/or failed testcase names in its API response back to Bodhi. Surfacing those more granular details in the Bodhi UI would be good. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Arsenick - René Jr Purcell
Thanks for your comment, that's a really good point! I think I will start with the packages and once I will have few accepted go back to have a talk on freenode with the spin guy's to see the best way to go for the rest of the adventure! Have a nice day! On Tue, Mar 20, 2018 at 5:21 AM, Björn Persson wrote: > Rene Jr Purcell wrote: > > I'm starting with a idea to build a spin of Fedora related to crypto > > Hello René! > > You should know that "crypto" was short for "cryptography" long before > it came to mean "cryptocurrency", and there are people around who will > misunderstand if you're not explicit. When introducing your spin to > people you should spell out "cryptocurrency" among the first words > they'll read. If you write just "crypto" then some people will think > that it's a collection of encryption tools. Live media focused on > privacy and security have been around for years, so it would be easy to > get the impression that yours is another of those. > > Björn Persson > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On Tue, 20 Mar 2018 08:22:32 -0500 Richard Shaw wrote: > On Mon, Mar 19, 2018 at 9:57 AM, Pierre-Yves Chibon > wrote: > > > The important ones are the ones defined in the policy that gates > > packages and > > are listed here: https://fedoraproject.org/wiki/CI/gating_updates > > > > waiverdb-cli should now support waiving missing results, I'm > > double-checking it > > and see if we can document it at: > > https://fedoraproject.org/wiki/Package_update_HOWTO# > > Handling_feedback_from_automated_tests > > next to the other examples. > > > Wow, that was an arduous task... I'm assuming I need to wait for > bodhi to detect the waiver before I can push? > > Also, this shows a "-t" option that is not available in waiverdb for > Fedora 27... waiverdb from updates-testing was required on my F-26 Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F29 System Wide Change: Python 3.7
= Proposed System Wide Change: Python 3.7 = https://fedoraproject.org/wiki/Changes/Python3.7 Owner(s): * Charalampos Stratakis * Miro Hrončok * Tomáš Orsava * Petr Viktorin Update the Python 3 stack in Fedora from Python 3.6 to Python 3.7. == Detailed description == Python 3.7 adds numerous features and optimizations. See the upstream notes at https://www.python.org/dev/peps/pep-0537/#features-for-3-7 and https://docs.python.org/3.7/whatsnew/3.7.html . === Important dates === * 2018-05-21 Python 3.7.0 candidate 1 * 2018-06-04 Python 3.7.0 candidate 2 (if necessary) * 2018-06-15 Python 3.7.0 final * 2018-07-11Fedora 29 Mass Rebuild * 2018-08-14Fedora 29 Change Checkpoint: Completion deadline (testable) (From https://www.python.org/dev/peps/pep-0537/#schedule and https://fedoraproject.org/wiki/Releases/29/Schedule .) === PEP 552 – Deterministic pycs === One change is notable from the packaging viewpoint: https://www.python.org/dev/peps/pep-0552/ – “Deterministic pycs”. We may decide to use the new UNCHECKED_HASH mode, which would mean that bytecode cache is not validated on import, i.e. changing a RPM-installed *.py file manually will have no effect (unless the corresponding __pycache__/*.pyc is updated or removed). == Scope == We will coordinate the work in a side tag and merge when ready. * Proposal owners: *# Retire python37 from F29+ *# Update python3 to what was in python37 *#* Mass rebuild all the packages that BR python3/python3-devel... (~2300 listed in [http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora]) *# Reintroduce python36 from Fedora 25. Update it to have all fixes and enhancements from python3 in Fedora 28 (or 29 before this change) * Other developers: Maintainers of packages that fail to rebuild during the mass rebuild will be asked, using bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with upstreams first and/or applying downstream patches. Also the package maintainers should have a look at: https://docs.python.org/3.7/whatsnew/3.7.html#porting-to-python-3-7 . And python-maint team will be available to help with fixing issues. * Fedora QA: Based on some troubles with the https://fedoraproject.org/wiki/Changes/Python3.6 , we'd like to have an ack from QA before we merge the side tag. * Release engineering: https://pagure.io/releng/issue/7390 A targeted rebuild for all python packages will be required, before the mass rebuild. ** List of deliverables: nope * Policies and guidelines: nope * Trademark approval: nope -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On Mon, Mar 19, 2018 at 9:57 AM, Pierre-Yves Chibon wrote: > The important ones are the ones defined in the policy that gates packages > and > are listed here: https://fedoraproject.org/wiki/CI/gating_updates > > waiverdb-cli should now support waiving missing results, I'm > double-checking it > and see if we can document it at: > https://fedoraproject.org/wiki/Package_update_HOWTO# > Handling_feedback_from_automated_tests > next to the other examples. Wow, that was an arduous task... I'm assuming I need to wait for bodhi to detect the waiver before I can push? Also, this shows a "-t" option that is not available in waiverdb for Fedora 27... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20180315.n.1 compose check report
Dne 16.3.2018 v 08:07 Adam Williamson napsal(a): > On Thu, 2018-03-15 at 22:26 +, Fedora compose checker wrote: >> No missing expected images. >> >> Failed openQA tests: 84/137 (x86_64), 24/24 (i386), 1/2 (arm) > Virtually all tests currently fail on Rawhide because a complete > redesign of Cantarell - the font we use in anaconda - landed and broke > just about every needle in openQA :/ Is it just Cantrell in Anaconda? I updated my Rawhide today and all fonts (well, at least fonts in my TB) looks weird/different. It is like if the hinting settings was changed again ... Vít > > This isn't affecting F28 install tests yet due to the freeze, it does > affect update tests, though. > > I've been redoing needles all day, I wanted to get it finished today > but it's midnight, so I'm leaving it for tonight, I'll finish up in the > morning. > > Sorry for the inconvenience. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR src.fp.o auto-rebuilds
Of course :) However I still look forward to some day, when branches named "private-*", used to help the maintainer with big tasks, will be fully under the package admin control. So far, you can see, such branches are used for either different versions of the package, or big tasks to be worked on (port to the new openssl for example). Theese are IMHO perfectly fine to be stored with the package. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat On Tue, Mar 20, 2018 at 1:42 PM, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, 2018-03-20 at 13:22 +0100, Michal Schorm wrote: >> Thanks for the tip. >> I just started using it and it works great! :) >> >> I'm not hooking forked repository, but private branches instead. >> The use case is to have multiple versions of packages available in >> COPR - especially MariaDB 10.3 and MySQL 8 which are still in >> developement. > > Note that there are no "private" branches in Fedora. Everything is kept > forever and available for public. > - -- > - -Igor Gnatenko > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqxAaQACgkQaVcUvRu8 > X0wcrg//VDOdyajLnVWd+zwLr682FvIhm2dIHEhhzGphsOTsOOkY7KhoQoRNY/8B > Fey9PafYmRiAWkELVUpfH/kA7W0t0YHnIoRJ55HCyIPz9ydxPYJuw0PCZw04UBun > BUiVmTr83PFK0+tSgSh66ihEn8Mns2M40GzIOKjJxu1SaOnQndhy8S0LCR0yosPn > mi4mhMmLDL1C9IZTyMyiYZdycFkPqVJShnCrVO9P5lWxsiA8BrwDEghshd/XWFg8 > +Vqr+1yimWGaKwfXkFN6GIbNr4nOZeKGLWCsRVnHNw70MSe9g+SxA+9tjWkNFixB > tRQN2zlYi+njNA+gQ1rI4BrWE8eFBa/iWttbwZ7U5NImrA4+gt5gNaNbKJeuw/td > TTHBxMXKg3fsOBWk68/K+awVjj0QTl8w7x+n2VORQNoRUN609kWFEC+eJjLAaQqn > bB8Y9a0jfxRWZdkv+3G+4K1PHPWyBcvCIi+4mpwFBup+XjC5QB88ceVdaHUDq5UP > GnHZ2YIeU39X2tgf3jENsefg2eEFt6lQO2etd59EFBoawTuNuWHQqcNwiYcip5qB > uMEZJvH8wYFQdisKHRVCjtZkHK38Ur3GmhwvdikkWp+GYFQE1+/j0tNtV4mVbGo1 > kL916kDdjYFaSGk/zs/ub7R332aQDXY72wW5PXAnuMNjDBxMnn8= > =Y/li > -END PGP SIGNATURE- > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR src.fp.o auto-rebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-03-20 at 13:22 +0100, Michal Schorm wrote: > Thanks for the tip. > I just started using it and it works great! :) > > I'm not hooking forked repository, but private branches instead. > The use case is to have multiple versions of packages available in > COPR - especially MariaDB 10.3 and MySQL 8 which are still in > developement. Note that there are no "private" branches in Fedora. Everything is kept forever and available for public. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqxAaQACgkQaVcUvRu8 X0wcrg//VDOdyajLnVWd+zwLr682FvIhm2dIHEhhzGphsOTsOOkY7KhoQoRNY/8B Fey9PafYmRiAWkELVUpfH/kA7W0t0YHnIoRJ55HCyIPz9ydxPYJuw0PCZw04UBun BUiVmTr83PFK0+tSgSh66ihEn8Mns2M40GzIOKjJxu1SaOnQndhy8S0LCR0yosPn mi4mhMmLDL1C9IZTyMyiYZdycFkPqVJShnCrVO9P5lWxsiA8BrwDEghshd/XWFg8 +Vqr+1yimWGaKwfXkFN6GIbNr4nOZeKGLWCsRVnHNw70MSe9g+SxA+9tjWkNFixB tRQN2zlYi+njNA+gQ1rI4BrWE8eFBa/iWttbwZ7U5NImrA4+gt5gNaNbKJeuw/td TTHBxMXKg3fsOBWk68/K+awVjj0QTl8w7x+n2VORQNoRUN609kWFEC+eJjLAaQqn bB8Y9a0jfxRWZdkv+3G+4K1PHPWyBcvCIi+4mpwFBup+XjC5QB88ceVdaHUDq5UP GnHZ2YIeU39X2tgf3jENsefg2eEFt6lQO2etd59EFBoawTuNuWHQqcNwiYcip5qB uMEZJvH8wYFQdisKHRVCjtZkHK38Ur3GmhwvdikkWp+GYFQE1+/j0tNtV4mVbGo1 kL916kDdjYFaSGk/zs/ub7R332aQDXY72wW5PXAnuMNjDBxMnn8= =Y/li -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 Beta Go/No-Go Meeting on Thursday, March 22 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-1 for this important meeting, wherein we shall determine the readiness of the Fedora 28 Beta. The meeting is going to be held on Thursday, March 22, 2018 at 17:00 UTC. Please check the [1] link for your time zone. Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go meeting. If you have any bug on the list, please help us with Beta release. If we won't be ready by Thursday, we will use this meeting to review blockers and decide what to do. In the meantime, please keep also an eye on the Fedora 28 Beta Blocker list [2]. For more details about this meeting please follow the [3] link. [1] https://apps.fedoraproject.org/calendar/meeting/8824/ [2] http://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting Thank you in advance for your support. Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 Beta Release Readiness Meeting on Thursday, March 22 @ 19:00 UTC
Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 28 Beta Release Readiness Meeting meeting. The meeting is going to be held on Thursday, March 22, 2017 at 19:00 UTC. Please check the [1] link for your time zone. We will meet to make sure we are coordinated and ready for the Beta release of Fedora 28. Please note that this meeting is going to be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but it is by purpose to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. For more information please check the [2] link. [1] https://apps.fedoraproject.org/calendar/meeting/8823/ [2] https://fedoraproject.org/wiki/Release_Readiness_Meetings Thank you for your support, Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: COPR src.fp.o auto-rebuilds
Thanks for the tip. I just started using it and it works great! :) I'm not hooking forked repository, but private branches instead. The use case is to have multiple versions of packages available in COPR - especially MariaDB 10.3 and MySQL 8 which are still in developement. -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat On Tue, Feb 27, 2018 at 12:04 AM, Michal Novotny wrote: > Hello, > > you can now very easily setup auto-rebuilds for your src.fp.o package: > > 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork > (please, use the https:// cloning option) > 2) make sure "Webhook Rebuild" checkbox is checked when you are creating the > package > 3) Go to settings for your package at src.fp.o and almost at the bottom in > Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update" > button. > > If your package is a main package (not a fork), then you can omit step 3. > > See https://pagure.io/copr/copr/issue/142 for more info. > COPR team > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Arsenick - René Jr Purcell
Rene Jr Purcell wrote: > I'm starting with a idea to build a spin of Fedora related to crypto Hello René! You should know that "crypto" was short for "cryptography" long before it came to mean "cryptocurrency", and there are people around who will misunderstand if you're not explicit. When introducing your spin to people you should spell out "cryptocurrency" among the first words they'll read. If you write just "crypto" then some people will think that it's a collection of encryption tools. Live media focused on privacy and security have been around for years, so it would be easy to get the impression that yours is another of those. Björn Persson pgpCrzLrXdes8.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On Mon, 19 Mar 2018 15:57:19 +0100 Pierre-Yves Chibon wrote: > On Mon, Mar 19, 2018 at 03:41:15PM +0100, Dan Horák wrote: > > On Mon, 19 Mar 2018 14:06:56 +0100 > > Dan Horák wrote: > > > > > On Sun, 18 Mar 2018 20:25:31 +0100 > > > Fabio Valentini wrote: > > > > > > > On Sun, Mar 18, 2018 at 7:13 PM, Michael Cronenworth > > > > wrote: > > > > > On 03/18/2018 01:02 PM, Fabio Valentini wrote: > > > > >> > > > > >> I've looked at waiverdb-cli too, but since no tests seem to > > > > >> have run at all, it looks like the wrong tool for the job: > > > > >> I don't want to push an update despite a failed test, I want > > > > >> to push my update despite no test data being available ... > > > > > > > > > > > > > > > Randy said the tests refresh every 6 hours and/or every time > > > > > the update is edited. Neither seemed to have occurred for you. > > > > > > > > Exactly. The "no test results found" status in bodhi hasn't been > > > > refreshed in over 10 days now. > > > > > > > > Bodhi also displays that all these tests were successful, bit > > > > still blocks the update because "no test results found", which > > > > is obviously just wrong. > > > > > > > > A manual lookup in resultdb shows me that the tests have in fact > > > > been run and have all passed: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-200708ae05 is > > > in the same situation, all tests are green, but "no test results > > > found" is reported. It's not very user friendly ... > > > > and https://bodhi.fedoraproject.org/updates/FEDORA-2018-71350d90a7 > > is even more interesting with "The update can not be pushed: 1 of 2 > > required tests not found", but the listed tests are again all > > green. No idea what's missing from the output. > > All the tests can be green if the "important" ones are missing, they > don't show :( I suspect the problem of missing tests is that dist.rpmdeplint is run on x86_64 only, but my update is for s390x only. So bodhi shouldn't rely on a result of a test that is intentionally skipped/omitted. > > The important ones are the ones defined in the policy that gates > packages and are listed here: > https://fedoraproject.org/wiki/CI/gating_updates But the UI should reflect that and eg. include an "empty" line for the omitted, but mandatory test. > waiverdb-cli should now support waiving missing results, I'm > double-checking it and see if we can document it at: > https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests > next to the other examples. ok Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
The question here is why don't we actually implement the modularity
the simple way.
Let's suppose I would like to make nodejs-8 available in EPEL7.
The most effortless way would be to create subdirectory called 8 at
src.fedoraproject.org/rpms/nodejs
with the updated spec file and sources for the bumped major version of
the nodejs package.
For fedpkg to be able to upload and download sources for that
subdirectory (submodule), the attached
single-line patch is needed in python-rpkg. There are a few more
changes needed to make srpm
importing work but it should be basically almost done as well.
Koji then just needs to learn how to build DistGit repositories
containing submodules where
submodule is any subdirectory containing a spec file. When Koji
discovers all the submodules
in a repository, it can start an srpm and a consequent rpm build for
each of them.
It is a very similar approach to what find_packages from python
setuptools implements. It
recognizes subpackages based on the presence of __init__.py file. The
only difference here
is that we will be recognizing subpackages (=submodules) by the
presence of *.spec file.
Everything else should be pretty much the same otherwise. Koji builds
nodejs-6 and nodejs-8 rpms
both with el7 disttag and both of these can go through the Bodhi
update process separately.
Of course, the question is if you can actually build and run nodejs-8
in EL7 successfully but
I think that will always be a problem no matter what the implementation is.
clime
On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza wrote:
>
>
> On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
> wrote:
>>
>> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
>> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
>> > > So you think having to send a request to a web service instead of just
>> > > parsing a string locally with one line of code is a good trade-off for
>> > > allowing dashes?
>> >
>> > This has been mentioned several times in this thread and I think there's
>> > a misunderstanding around this.
>> >
>> > So: When your tool/whatever works with modules it will have to have
>> > module metadata available in some form.
>>
>> What if I don't want to work with modules at all, just with information
>> about modules?
>>
>> What if I just want to write a tool that parses fedmsgs about module
>> builds in Koji and does something that depends on module names, streams
>> and versions? (e.g. some sort of changelog thing)
>
>
> Your tool can use good old buildsys.build.state.change fedmsg with the well
> known name/version/release fields like this:
>
> https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.stg.buildsys.build.state.change
>
> That's staging, because it's easier for me to find the module builds there
> :).
>
> Unfortunatelly, Koji does not add "type" field there, so you cannot find out
> if that's module or not. But in case your tool is doing general changelog
> per Koji build, it will work quite well with modules without you even
> noticing you are working with modules.
>
> In case of tools, you can even query koji using its api and pass the
> name/version/release there, instead of NVR.
>
> If you query Koji for the module build, you will actually find whole module
> metadata in "extra" part of the build.
>
> In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils
> already sent in this thread.
>
> Regards,
> Jan Kaluza
>
>> --
>> 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
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
From 51c184a0ea77a6b000d65045f87efc614d26fcbd Mon Sep 17 00:00:00 2001
From: clime
Date: Tue, 20 Mar 2018 08:53:01 +0100
Subject: [PATCH] patch for modularity
---
pyrpkg/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pyrpkg/__init__.py b/pyrpkg/__init__.py
index 74cdbfc..c182b90 100644
--- a/pyrpkg/__init__.py
+++ b/pyrpkg/__init__.py
@@ -740,7 +740,7 @@ class Commands(object):
self.log.debug('Creating repo object from %s', self.path)
try:
-self._repo = git.Repo(self.path)
+self._repo = git.Repo(self.path, search_parent_directories=True)
except (git.InvalidGitRepositoryError, git.NoSuchPathError):
raise rpkgError('%s is not a valid repo' % self.path)
--
2.14.3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Atomic 27-20180320.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) -- 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
