Fedora-Modular 27-20171111.n.0 compose check report
Missing expected images: Docker_base docker x86_64 Server dvd arm Failed openQA tests: 19/94 (x86_64), 5/19 (i386) New failures (same test did not fail in 27-20171110.n.1): ID: 168670 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/168670 ID: 168752 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/168752 Old failures (same test failed in 27-20171110.n.1): ID: 168654 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/168654 ID: 168668 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/168668 ID: 168674 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/168674 ID: 168676 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/168676 ID: 168681 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/168681 ID: 168682 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/168682 ID: 168718 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168718 ID: 168719 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/168719 ID: 168720 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/168720 ID: 168721 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/168721 ID: 168723 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/168723 ID: 168724 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/168724 ID: 168725 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/168725 ID: 168734 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168734 ID: 168735 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/168735 ID: 168736 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/168736 ID: 168740 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/168740 ID: 168741 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/168741 ID: 168746 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/168746 ID: 168759 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/168759 ID: 168760 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/168760 ID: 168763 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/168763 Soft failed openQA tests: 1/94 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in 27-20171110.n.1): ID: 168666 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/168666 Passed openQA tests: 65/94 (x86_64), 14/19 (i386) Skipped openQA tests: 3 of 113 Installed system changes in test x86_64 universal install_package_set_minimal: System load changed from 0.02 to 0.23 Previous test data: https://openqa.fedoraproject.org/tests/168555#downloads Current test data: https://openqa.fedoraproject.org/tests/168687#downloads -- 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
[Test-Announce] Proposal to CANCEL: 2017-11-13 blocker review meeting
Hi folks! I'm proposing we cancel the blocker review meeting for Monday, as there are no proposed Server Final blockers at present. Please yell if you think we will need to run a meeting. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
[Test-Announce] 2017-11-13 @ ** 16:00 UTC ** - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2017-11-13 # Time: ** 16:00 ** UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's time for another meeting! We've finished with Fedora 27, but not Fedora Modular Server 27, so let's chat about that, and other things... If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 27 wrap-up 3. Fedora Modular Server 27 GA test planning 4. Fedora 28 planning 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Fedora Modular 27 compose report: 20171111.n.0 changes
OLD: Fedora-Modular-27-20171110.n.1 NEW: Fedora-Modular-27-2017.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 0.00 B Size of downgraded packages: 0.00 B Size change of upgraded packages: 0.00 B Size change of downgraded packages: 0.00 B = ADDED IMAGES = = 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
Re: Tagging large packages (texlive) takes a very long time
On 11/10/2017 10:43 AM, Richard W.M. Jones wrote: > On Fri, Nov 10, 2017 at 09:47:02AM -0800, Kevin Fenzi wrote: >> All that said, I don't see where s390x is involved in the current build. >> The parent task is being handled by buildvm-23, but indeed it seems like >> something has gone wrong. I can try and free that task to another >> builder, but that might cause it to fail. I suppose I can resubmit after >> that... so will give it a try > > It seems as if the build has been resubmitted. It was on an s390x > builder (according to the hostname), but when I reloaded the page just > a few moments ago it's now on buildvm-02.phx2, and in the final stage > already. > > Thanks for the explanation & fix yeah, I freed it from the buildvm-23 it was on, and buildvm-02 got it. I guess we will wait a few hours and see if it finishes. Texlive is pretty much the worst case example for the build system, and has broken things in various tools a number of times. From it's 5000 subpackages, it's > 2GB src.rpm, etc. Hopefully it will complete now, if it doesn't we need to look more, likely for a koji hub bug. ;( kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tagging large packages (texlive) takes a very long time
On Fri, Nov 10, 2017 at 09:47:02AM -0800, Kevin Fenzi wrote: > All that said, I don't see where s390x is involved in the current build. > The parent task is being handled by buildvm-23, but indeed it seems like > something has gone wrong. I can try and free that task to another > builder, but that might cause it to fail. I suppose I can resubmit after > that... so will give it a try It seems as if the build has been resubmitted. It was on an s390x builder (according to the hostname), but when I reloaded the page just a few moments ago it's now on buildvm-02.phx2, and in the final stage already. Thanks for the explanation & fix. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular bikeshed compose report: 20171026.n.0 changes
OLD: Fedora-Modular-Bikeshed-20171026.n.0 NEW: Fedora-Modular-Bikeshed-20171026.n.0 = SUMMARY = Added images:0 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 = = 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
Re: Changes Policy & Fedora Release Life Cycle - request for review
On 11/10/2017 09:18 AM, Matthew Miller wrote: ...snip... > > On a bigger note: Do we really want to have a window after branch where > Bodhi isn't active? Might it be better to put that as part of the > Branch step? I don't think we want a longer freeze period (especially > during beta) but we You got cut off there? The reason in the past for the window after branching, but before bodhi enablement was because it allowed for a small window to fix up fallout from branching, but if everyone is ok with just doing it at the same time I suppose it should be possible. > And, on a even bigger note, the F27 July-to-October experiment worked > reasonably well (with the large remainer of the still-outstanding > Modular Server) but I don't think we want to do that again. I'd like to > suggest that if the April/May release slips into July, or the > October/November release slips into January, we *automatically* skip > the next target date for a _longer_ cycle to bring us back to schedule > rather than a short one. Sounds somewhat reasonable, but might get us behind on 'first' kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Adding CAP_NET_RAW to binaries
On 10/11/17 17:38, nicolas.mail...@laposte.net wrote: Full details are in cap_from_text(3) by the looks of it. Unfortunately, no. None of the fine manuals I located explain the difference between ep and just p flags :( Everyone seems to use +ep blindly, but the Fedora spec only adds p? The F27 version of the manual page mentions e for sure. The letters are the sets that you want to set it in: p = permitted capabilities e = effective capabilities i = inherited capabilities Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Modular 27-20171110.n.1 compose check report
Missing expected images: Docker_base docker x86_64 Server dvd arm Failed openQA tests: 18/94 (x86_64), 4/19 (i386) ID: 168522 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/168522 ID: 168536 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/168536 ID: 168542 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/168542 ID: 168544 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/168544 ID: 168549 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/168549 ID: 168550 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/168550 ID: 168586 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168586 ID: 168587 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/168587 ID: 168588 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/168588 ID: 168589 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/168589 ID: 168591 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/168591 ID: 168592 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/168592 ID: 168593 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/168593 ID: 168602 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168602 ID: 168603 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/168603 ID: 168604 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/168604 ID: 168608 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/168608 ID: 168609 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/168609 ID: 168614 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/168614 ID: 168627 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/168627 ID: 168628 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/168628 ID: 168631 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/168631 Soft failed openQA tests: 2/94 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 168534 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/168534 ID: 168539 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/168539 Passed openQA tests: 68/94 (x86_64), 15/19 (i386) Skipped openQA tests: 1 of 113 -- 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: Modularity questions for "traditional" RPM packaging
On 11/10/2017 06:32 AM, Richard Shaw wrote: > On Fri, Nov 10, 2017 at 8:25 AM, Christopher > wrote: > > +1000 from me. > > I maintain or co-maintain probably more than 60 packages and I still don't > completely get it. I've read the wiki, I watched the video on arbitrary > branching and I *KINDA* get the idea at a HIGH level, but as far as what > the workflow will actually look like I'm completely confused. I think it's a combo of things right now: * All the people who understand how things are setup are heads-down in trying to get everything working for the F27 modular server efforts. * Some of it's not really known yet. It's going to take some trial and effort and deciding things are not going to work some way so they get redone another way. * Some of it's not going to be clear until lots more people start using it and finding the pain points. So, IMHO, it's not either black (ignore modularity!) or white (panic and must do something now), but watch things, try and use the modular server when it comes out and hopefully help with workflows when there's more clear ideas of what those are. > I also don't care for the new pagure.io repo when dealing with importing > new packages. I get an email when the repository and branches are created > when the tickets are closed, but I still can't build the package for > several hours. I just have to keep trying until it works. Not a good > experience. Can you please file a infrastructure ticket when you see this happening? It should be at most 10min or so, not several hours. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changes Policy & Fedora Release Life Cycle - request for review
On Fri, Nov 10, 2017 at 11:18 AM, Matthew Miller wrote: And, on a even bigger note, the F27 July-to-October experiment worked reasonably well (with the large remainer of the still-outstanding Modular Server) but I don't think we want to do that again. I'd like to suggest that if the April/May release slips into July, or the October/November release slips into January, we *automatically* skip the next target date for a _longer_ cycle to bring us back to schedule rather than a short one. I thought it worked quite well. If a release gets delayed to July and we completely skip the October release, so that the next release is in April/May, then we need to be willing to push out major version upgrades to the current stable release, and accept any accompanying breakage. And that really blows up the entire concept of having stable releases. A 10 month release cycle seems like a much bigger change to me than a four month cycle. Fedora can't be a year behind and remain relevant. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tagging large packages (texlive) takes a very long time
On 11/10/2017 07:01 AM, Richard W.M. Jones wrote: > On Fri, Nov 10, 2017 at 06:33:09AM -0800, John Reiser wrote: >> On 11/10/2017 1058Z, Richard W.M. Jones wrote: >> >>> 24 hours and counting ... >>> >>> I talked to someone on #fedora-admin about this and it is caused by >>> Koji having to load the metadata (files, dependencies etc) of every >>> RPM into its database. Combined with the fact this happens to be >>> running on s390x and it's texlive, makes it slow. >> >> Can you be more specific? Is it slow because: >> 1. the s390x has a slow or inappropriate CPU for the task? >> 2. the VM on the s390x has not enough real RAM, and is page thrashing on a >> spinning harddrive? >> 3. the database uses a quadratic algorithm that hurts in this case? >> 4. the database has very high CPU overhead in general? >> 5. "every RPM" means all 30,000 .rpm in Fedora, not just the 300 for >> texlive? >> (And if so, then why isn't tagging slow for _every_ package?) >> 6. some other specific reason(s)? >> >> Indexing 1GB of data should take no more than a few minutes. > > I don't have any access to the machine so I'm not in a position to say. > > I will note however that the previous successful build of texlive took > 4 hours in total (that's building, adding to the database and > tagging). This one has been running for 30 hours and still has not > completed. The S390x builders are not in the same datacenter as all the rest of the builders, the koji hub and it's database. They are not particularly slow, but sending all the data back and forth over the net is likely the bottleneck here. It's particularly bad (if I understand correctly how it works) because one builder manages the parent task and farms out the builds to other builders, then collects them back and uploads them to the hub. So, if a s390x builder is controlling the parent task it will have to pull all the resuts back accross the net to itself, then push them back accross the net to the hub. All that said, I don't see where s390x is involved in the current build. The parent task is being handled by buildvm-23, but indeed it seems like something has gone wrong. I can try and free that task to another builder, but that might cause it to fail. I suppose I can resubmit after that... so will give it a try kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Adding CAP_NET_RAW to binaries
> Full details are in cap_from_text(3) by the looks of it. Unfortunately, no. None of the fine manuals I located explain the difference between ep and just p flags :( Everyone seems to use +ep blindly, but the Fedora spec only adds p? Regards, -- Nicolas mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Adding CAP_NET_RAW to binaries
- Mail original - De: "Jeffrey Ollie" > Instead of setting CAP_NET_RAW on the binary, why not have systemd give the > service the capability at runtime? The blackbox exporter isn't something > that you run from the CLI much anyway is it? Yes that's another solution, I hadn't thought so far yet. Right now I just want the thing to build ;) I figured that since I had already done 99% of the work building the snmp exporter, I could reuse the spec stack for the rest (upstream does not provide snmp exporter binaries, they need linking outside go land) > Here's what part of my service file looks like: Thanks a lot > Maybe this is just bikeshedding, but why have you renamed the binary from > blackbox_exporter to prometheus-blackbox-exporter? blackbox_exporter > doesn't conflict with anything else AFAIK and renaming it is just going to > confuse people when they are reading upstream documentation etc. That was just defensive packaging on my part :) I don't want to package a set of exporters, only to find out one of them conflicts and requires renaming the rest. Upstream naming feels rather generic and collision-prone (plus I hate underscores in commands). That's peanuts to change later if needed Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changes Policy & Fedora Release Life Cycle - request for review
On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote: > [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle This looks generally good to me. The one change I would make is to add to "Tue: Primary date from which rest of schedule derives". Make that: Tue: Primary date from which rest of schedule derives This date is either the Tuesday before May 1st or October 31st. Upcoming potential target dates are: 2018-04-24, 2018-10-30, 2019-04-30, and 2019-10-29. Can you draw up how exactly any changes would affect: https://fedoraproject.org/wiki/Releases/28/Schedule (FESCo approved) https://fedoraproject.org/wiki/Releases/29/Schedule (still a draft) I think offhand that they're basically the same (and that this change basically brings the policy in line with the praxis), but I may have missed something. On a bigger note: Do we really want to have a window after branch where Bodhi isn't active? Might it be better to put that as part of the Branch step? I don't think we want a longer freeze period (especially during beta) but we And, on a even bigger note, the F27 July-to-October experiment worked reasonably well (with the large remainer of the still-outstanding Modular Server) but I don't think we want to do that again. I'd like to suggest that if the April/May release slips into July, or the October/November release slips into January, we *automatically* skip the next target date for a _longer_ cycle to bring us back to schedule rather than a short one. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Adding CAP_NET_RAW to binaries
On 10/11/17 16:47, nicolas.mail...@laposte.net wrote: Thanks a lot, I should have thought of it myself, I must be tired today. Is there a difference between setcap cap_net_raw+ep and %caps(cap_net_raw=p) I can't seem to locate a correct setcap or %caps() reference I imagine you want =ep to make it the same? Assuming it's like chmod then +ep adds the e and p flags while =ep would set the flags to exactly that. Obviously in the context on installing an rpm adding flags doesn't make sense, you just want to specify what they should be. Full details are in cap_from_text(3) by the looks of it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 27-20171110.n.1 compose check report
Missing expected images: Workstation live i386 Kde live i386 Failed openQA tests: 6/137 (x86_64) New failures (same test did not fail in 27-20171110.n.0): ID: 168421 Test: x86_64 Workstation Ostree-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/168421 ID: 168422 Test: x86_64 Workstation Ostree-dvd_ostree-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/168422 ID: 168424 Test: x86_64 Workstation Ostree-dvd_ostree-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/168424 ID: 168488 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/168488 Old failures (same test failed in 27-20171110.n.0): ID: 168412 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/168412 ID: 168471 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/168471 Soft failed openQA tests: 6/137 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in 27-20171110.n.0): ID: 168382 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/168382 Old soft failures (same test soft failed in 27-20171110.n.0): ID: 168468 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168468 ID: 168470 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/168470 ID: 168484 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168484 ID: 168485 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/168485 ID: 168492 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/168492 Passed openQA tests: 124/137 (x86_64), 22/22 (i386), 2/2 (arm) New passes (same test did not pass in 27-20171110.n.0): ID: 168417 Test: x86_64 Workstation Ostree-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/168417 ID: 168420 Test: x86_64 Workstation Ostree-dvd_ostree-iso base_selinux URL: https://openqa.fedoraproject.org/tests/168420 ID: 168423 Test: x86_64 Workstation Ostree-dvd_ostree-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/168423 ID: 168425 Test: x86_64 Workstation Ostree-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/168425 ID: 168441 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/168441 ID: 168449 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/168449 ID: 168467 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/168467 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.05 to 0.17 Previous test data: https://openqa.fedoraproject.org/tests/168185#downloads Current test data: https://openqa.fedoraproject.org/tests/168354#downloads Installed system changes in test i386 Server-dvd-iso install_default: System load changed from 0.44 to 0.16 Previous test data: https://openqa.fedoraproject.org/tests/168208#downloads Current test data: https://openqa.fedoraproject.org/tests/168377#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Average CPU usage changed from 1.79523810 to 26.20952381 Used mem changed from 899 MiB to 1026 MiB Previous test data: https://openqa.fedoraproject.org/tests/168213#downloads Current test data: https://openqa.fedoraproject.org/tests/168382#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.23 to 0.58 Average CPU usage changed from 2.17142857 to 26.32857143 Used mem changed from 897 MiB to 1021 MiB Previous test data: https://openqa.fedoraproject.org/tests/168214#downloads Current test data: https://openqa.fedoraproject.org/tests/168383#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default: System load changed from 0.30 to 0.70 Average CPU usage changed from 1.60476190 to 22.76190476 Used mem changed from 887 MiB to 1008 MiB Previous test data: https://openqa.fedoraproject.org/tests/168225#downloads Current test data: https://openqa.fedoraproject.org/tests/168394#downloads Installed system changes in test x86_64 Workstation-boot-iso install_default@uefi: System load changed from 0.17 to 0.64 Average CPU usage changed from 1.7333 to 23.72380952 Used mem changed from 887 MiB to 1014 MiB Previous test data: https://openqa.fedoraproject.org/tests/168228#downloads Current test data: https://openqa.fedoraproject.org/tests/168397#downloads Installed system changes in test i386 Workstation-boot-iso install_default
Re: Adding CAP_NET_RAW to binaries
Instead of setting CAP_NET_RAW on the binary, why not have systemd give the service the capability at runtime? The blackbox exporter isn't something that you run from the CLI much anyway is it? Here's what part of my service file looks like: [Service] User=blackbox_exporter Group=blackbox_exporter AmbientCapabilities=CAP_NET_RAW ExecStart=/opt/blackbox_exporter/blackbox_exporter --config.file /opt/blackbox_exporter/config.yaml --log.level debug On Fri, Nov 10, 2017 at 10:07 AM, wrote: > > I've done the naïve > setcap cap_net_raw+ep /builddir/build/BUILDROOT/ > prometheus-blackbox-exporter-0.10.0-1.fc28.llt.x86_64/usr/ > bin/prometheus-blackbox-exporter > Maybe this is just bikeshedding, but why have you renamed the binary from blackbox_exporter to prometheus-blackbox-exporter? blackbox_exporter doesn't conflict with anything else AFAIK and renaming it is just going to confuse people when they are reading upstream documentation etc. -- Jeff Ollie The majestik møøse is one of the mäni interesting furry animals in Sweden. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Adding CAP_NET_RAW to binaries
Hi Tom Thanks a lot, I should have thought of it myself, I must be tired today. Is there a difference between setcap cap_net_raw+ep and %caps(cap_net_raw=p) I can't seem to locate a correct setcap or %caps() reference Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Modular 27 compose report: 20171110.n.1 changes
OLD: Fedora-Modular-27-20171110.n.0 NEW: Fedora-Modular-27-20171110.n.1 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 0.00 B Size of downgraded packages: 0.00 B Size change of upgraded packages: 0.00 B Size change of downgraded packages: 0.00 B = ADDED IMAGES = = 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
Re: Adding CAP_NET_RAW to binaries
Hi, There is a RPM macro for it. You may find a good example in the spec file of wireshark On November 10, 2017 5:07:28 PM GMT+01:00, nicolas.mail...@laposte.net wrote: >Hi, > >I'm building the prometheus blackbox exporter that needs the >CAP_NET_RAW capability to conduct ICMP probes (I don't want to run it >as root) > >I've done the naïve >setcap cap_net_raw+ep >/builddir/build/BUILDROOT/prometheus-blackbox-exporter-0.10.0-1.fc28.llt.x86_64/usr/bin/prometheus-blackbox-exporter > >in the specfile, but that makes mock barf >unable to set CAP_SETFCAP effective capability: Operation not permitted > >What is the correct way to handle this? > >Regards, > >-- >Nicolas Mailhot >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Adding CAP_NET_RAW to binaries
On 10/11/17 16:07, nicolas.mail...@laposte.net wrote: I'm building the prometheus blackbox exporter that needs the CAP_NET_RAW capability to conduct ICMP probes (I don't want to run it as root) I've done the naïve setcap cap_net_raw+ep /builddir/build/BUILDROOT/prometheus-blackbox-exporter-0.10.0-1.fc28.llt.x86_64/usr/bin/prometheus-blackbox-exporter in the specfile, but that makes mock barf unable to set CAP_SETFCAP effective capability: Operation not permitted What is the correct way to handle this? Set it in the file list with %cap as iputils does for ping etc: https://src.fedoraproject.org/rpms/iputils/blob/master/f/iputils.spec#_142 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Changes Policy & Fedora Release Life Cycle - request for review
Hi everybody, I tried to merge together all the changes we were facing during the last time with regards to Changes Policy & Fedora Release Life Cycle. The outcome is available in [1] and [2]. Before I will ask FESCo for a review, I would like to ask anyone who is interested for a review and comments. Basically the changes I did are related to the following topics: * No More Alphas Change [3] * Discussion about String Freeze [4] * Rain dates and such [5] * Removal of description how to build schedule on your own as this paragraph was not already valid. I might add some description of this later, however I do not think that this belongs to Life Cycle policy anyway. [1] https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle [2] https://fedoraproject.org/wiki/User:Jkurik/Changes.Policy [3] https://fedoraproject.org/wiki/Changes/NoMoreAlpha [4] https://lists.fedoraproject.org/archives/list/tr...@lists.fedoraproject.org/thread/XVX4YQCN4MVCHBSSNXMAWOFGMNSUAUTR/#XVX4YQCN4MVCHBSSNXMAWOFGMNSUAUTR [5] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FMDJYAK6SBYFKXUIIPT6OBN5NRZTKL7I/#FMDJYAK6SBYFKXUIIPT6OBN5NRZTKL7I Thanks, 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
Adding CAP_NET_RAW to binaries
Hi, I'm building the prometheus blackbox exporter that needs the CAP_NET_RAW capability to conduct ICMP probes (I don't want to run it as root) I've done the naïve setcap cap_net_raw+ep /builddir/build/BUILDROOT/prometheus-blackbox-exporter-0.10.0-1.fc28.llt.x86_64/usr/bin/prometheus-blackbox-exporter in the specfile, but that makes mock barf unable to set CAP_SETFCAP effective capability: Operation not permitted What is the correct way to handle this? Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-11-10 at 14:39 +0100, Florian Weimer wrote: > On 11/08/2017 06:08 PM, Björn 'besser82' Esser wrote: > > Hello everyone, > > > > since there has been some discussion in the last time about > > removing > > libcrypt from glibc in some time [1,2,3,4] and splitting it out > > into a > > separate project which can evolve quicker, I'd like to hear your > > oppinion about replacing glibc's libcrypt with libxcrypt [5] for > > Fedora > > 29 (or 30). > > I'd prefer this to happen in Fedora 28 if at all possible. It is still possible to propose this as System-Wide change for F28 😉 - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAloFv3MACgkQaVcUvRu8 X0yYJxAAnmsLv1pcrOmYcW/WX6thXJDlFwxqH5VhhVSO8Yvxvz7s/DUdbhtRlgJ6 cdLL7IxqPkgpzDoX2t0fVDk3eUVFDQuJlGZI7sygwgRK/nvm5ehaELN4JSLl8J0A 1MmWrq9XWMhSig68hfm9wg09k+kT8F9WltRMz1tc9Ql2VOAineFc7QHlCOnq5H8z NBBA79KfOjtr0tQFWm5oiGsXKreWs8KG/jTsuRPybuisMCTT2zT3ju74hNmx0DTJ JFfXlcPgt7+ukIJI0L0Mbi8WO6QIsEAy1Iwr1oM5ZCGexi6C+FMCzYsyQe/ebq+I zmHUlfwt/1LsTwcYUlNk26Bv309ayanU2xcIHjQ2I9YUdGWrj7n5Jugbz2uah8eG 2i3SlJiHV0gt0y5oXQjWJqcJu9J/b07qgb0YcU3ospIog6q4JEAiXKzNrQXlt4Jr 5tvf+NtbgcoHF7vUMkwHnQikT7dxEEu/LXAC0DQQ5FwyNjRQwqlk75/jX+j7SEss vQRBF07mwb+ljzrEfeg6GVm1RsETSsgLXomFipNZYk4uvEKKzhut8Srw7noklpYo x6dfSTxKlEpUfnThr5vuetgwfwZSgniqfTKM7BjkG5CTK1SFfnM5AnHhzdIXSKNt pR//UTAVDTIWXx9iTrvkHSRbbwXax5pOQaIqd3CoFlLTpLr6vxQ= =If2C -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tagging large packages (texlive) takes a very long time
On Fri, Nov 10, 2017 at 06:33:09AM -0800, John Reiser wrote: > On 11/10/2017 1058Z, Richard W.M. Jones wrote: > > >24 hours and counting ... > > > >I talked to someone on #fedora-admin about this and it is caused by > >Koji having to load the metadata (files, dependencies etc) of every > >RPM into its database. Combined with the fact this happens to be > >running on s390x and it's texlive, makes it slow. > > Can you be more specific? Is it slow because: > 1. the s390x has a slow or inappropriate CPU for the task? > 2. the VM on the s390x has not enough real RAM, and is page thrashing on a > spinning harddrive? > 3. the database uses a quadratic algorithm that hurts in this case? > 4. the database has very high CPU overhead in general? > 5. "every RPM" means all 30,000 .rpm in Fedora, not just the 300 for > texlive? > (And if so, then why isn't tagging slow for _every_ package?) > 6. some other specific reason(s)? > > Indexing 1GB of data should take no more than a few minutes. I don't have any access to the machine so I'm not in a position to say. I will note however that the previous successful build of texlive took 4 hours in total (that's building, adding to the database and tagging). This one has been running for 30 hours and still has not completed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Fri, Nov 10, 2017 at 09:12:33AM -0500, Neal Gompa wrote: > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > >> Zbigniew Jędrzejewski-Szmek wrote: > >> > The fedora-release package contains stuff that is tied to each Fedora > >> > version and changes slowly, and it also contains the preset files for > >> > systemd units, which change fairly often (a few requests per month). > >> > >> Why not have a separate fedora-presets then? Just like fedora-repos was > >> split out from fedora-release several releases ago. > > > > Well, pfff, no particular reason, at least from my side. Just opening > > a new package and going through the (trivial) review, etc., is a bit > > of up-front effort, and then releasing updates for two packages is > > always a bit more effort then for one. So instead, I'd want a good reason > > to make another package and how that is going to solve something. So far I > > haven't seen anything except some hypothetical issues. > > This would allow us to deduplicate the presets shipped in > generic-release and fedora-release, wouldn't it? That is a very good point. It would probably make sense to do such deduplication. But I think it should be a separate step after fedora-release is reorganized. Doing everything at once is more likely to lead to a mess. But yeah, it's definitely something I'll want to do later on. Zbyszek > And as long has it has a "system-presets" Provides, downstream folks > can swap them easily enough. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Tagging large packages (texlive) takes a very long time
On 11/10/2017 1058Z, Richard W.M. Jones wrote: 24 hours and counting ... I talked to someone on #fedora-admin about this and it is caused by Koji having to load the metadata (files, dependencies etc) of every RPM into its database. Combined with the fact this happens to be running on s390x and it's texlive, makes it slow. Can you be more specific? Is it slow because: 1. the s390x has a slow or inappropriate CPU for the task? 2. the VM on the s390x has not enough real RAM, and is page thrashing on a spinning harddrive? 3. the database uses a quadratic algorithm that hurts in this case? 4. the database has very high CPU overhead in general? 5. "every RPM" means all 30,000 .rpm in Fedora, not just the 300 for texlive? (And if so, then why isn't tagging slow for _every_ package?) 6. some other specific reason(s)? Indexing 1GB of data should take no more than a few minutes. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Modularity questions for "traditional" RPM packaging
On Fri, Nov 10, 2017 at 8:25 AM, Christopher wrote: > > The biggest concerns/questions I have about modularity are probably not > even the biggest challenges the modularity effort has to overcome. My > concerns/questions are really about "what's my role in this?". I'm not > involved in the release process, and have almost zero understanding of > Fedora compositions, editions, "flavors", "spins", etc. I'm just a lowly > maintainer who has one or two packages, and is helping out with a few > others, because I use them. > > I really don't understand how my role changes with the modularity > effort... if at all. It is easy to do as Kevin suggests, and simply ignore > these efforts... but I fear that's what too many in my position have done > so far, and I'm worried that we're going to have our packages excluded from > future Fedora, because we don't understand the new composition/release > process, which many of us have probably never had to think about before. > I'm worried that the effort to ease releases/composes may make it much > harder for regular package maintainers to contribute to Fedora. > > That said, I really don't want to be critical of the modularity effort. > From what I've read, I think it has a rational basis. At this point, I just > want to understand it better, so I know how I can continue to contribute to > Fedora for the packages I care about, and how this all will affect me. > +1000 from me. I maintain or co-maintain probably more than 60 packages and I still don't completely get it. I've read the wiki, I watched the video on arbitrary branching and I *KINDA* get the idea at a HIGH level, but as far as what the workflow will actually look like I'm completely confused. I also don't care for the new pagure.io repo when dealing with importing new packages. I get an email when the repository and branches are created when the tickets are closed, but I still can't build the package for several hours. I just have to keep trying until it works. Not a good experience. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Modularity questions for "traditional" RPM packaging
On Fri, Nov 10, 2017 at 9:02 AM Neal Gompa wrote: > On Fri, Nov 10, 2017 at 8:40 AM, Kalev Lember > wrote: > > On 11/10/2017 02:23 PM, Kevin Kofler wrote: > >> Please just ignore this module nonsense. The more maintainers boycott > it, > >> the less likely it is to succeed and produce completely unnecessary > extra > >> work for you, me and all the other maintainers. > > > > Kevin, please stop the trolling and belittling others. This is out of > line. > > > > How would YOU feel if I kept responding to any messages about KDE with: > > "Please just ignore this KDE nonsense. The more maintainers boycott it, > > the less likely it is to succeed and produce completely unnecessary > > extra work for you, me and all the other maintainers" ? > > > > Kevin aside, the way the modular server was introduced in Fedora 27 > was poorly handled. > > It should have never been declared as a replacement deliverable for > the classic Fedora Server for the Fedora 27 release. It's very clear > now that was a mistake, as now one third of the deliverables aren't > even going to be released until mid January, probably later. The > necessary tooling to properly do modular composes didn't even go live > until a couple of weeks ago. > > If I thought there was a shot to fix this, I'd be proposing that we > *ignore* Modular server for the Fedora 27 release and release the > regular Fedora Server for Fedora 27, and ship the Modular server as > another tech preview post Fedora 27 release. That would give it more > time to bake and deal with the inherent issues with modularity for > Fedora 28. > > This was the approach we took with Atomic replacing the Cloud Edition, > and I have no idea why anyone thought it was a good idea to ignore > that process for modularity. > > The biggest concerns/questions I have about modularity are probably not even the biggest challenges the modularity effort has to overcome. My concerns/questions are really about "what's my role in this?". I'm not involved in the release process, and have almost zero understanding of Fedora compositions, editions, "flavors", "spins", etc. I'm just a lowly maintainer who has one or two packages, and is helping out with a few others, because I use them. I really don't understand how my role changes with the modularity effort... if at all. It is easy to do as Kevin suggests, and simply ignore these efforts... but I fear that's what too many in my position have done so far, and I'm worried that we're going to have our packages excluded from future Fedora, because we don't understand the new composition/release process, which many of us have probably never had to think about before. I'm worried that the effort to ease releases/composes may make it much harder for regular package maintainers to contribute to Fedora. That said, I really don't want to be critical of the modularity effort. >From what I've read, I think it has a rational basis. At this point, I just want to understand it better, so I know how I can continue to contribute to Fedora for the packages I care about, and how this all will affect me. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: >> Zbigniew Jędrzejewski-Szmek wrote: >> > The fedora-release package contains stuff that is tied to each Fedora >> > version and changes slowly, and it also contains the preset files for >> > systemd units, which change fairly often (a few requests per month). >> >> Why not have a separate fedora-presets then? Just like fedora-repos was >> split out from fedora-release several releases ago. > > Well, pfff, no particular reason, at least from my side. Just opening > a new package and going through the (trivial) review, etc., is a bit > of up-front effort, and then releasing updates for two packages is > always a bit more effort then for one. So instead, I'd want a good reason > to make another package and how that is going to solve something. So far I > haven't seen anything except some hypothetical issues. This would allow us to deduplicate the presets shipped in generic-release and fedora-release, wouldn't it? And as long has it has a "system-presets" Provides, downstream folks can swap them easily enough. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > The fedora-release package contains stuff that is tied to each Fedora > > version and changes slowly, and it also contains the preset files for > > systemd units, which change fairly often (a few requests per month). > > Why not have a separate fedora-presets then? Just like fedora-repos was > split out from fedora-release several releases ago. Well, pfff, no particular reason, at least from my side. Just opening a new package and going through the (trivial) review, etc., is a bit of up-front effort, and then releasing updates for two packages is always a bit more effort then for one. So instead, I'd want a good reason to make another package and how that is going to solve something. So far I haven't seen anything except some hypothetical issues. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
On 11/10/2017 02:21 PM, Kevin Kofler wrote: Björn 'besser82' Esser wrote: libxcrypt will be fully binary compatible with software linked against glibc's libcrypt and does not require any rebuilds. However, the converse is not true: programs linked against libxcrypt will not work with glibc's libcrypt. It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra. Also, programs that use certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt. I think it would make more sense to add the new APIs to glibc, without dropping existing APIs or changing the implementation of the remaining existing APIs. I disagree, and I think so do all the people who work on glibc. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Modularity questions for "traditional" RPM packaging
On Fri, Nov 10, 2017 at 8:40 AM, Kalev Lember wrote: > On 11/10/2017 02:23 PM, Kevin Kofler wrote: >> Please just ignore this module nonsense. The more maintainers boycott it, >> the less likely it is to succeed and produce completely unnecessary extra >> work for you, me and all the other maintainers. > > Kevin, please stop the trolling and belittling others. This is out of line. > > How would YOU feel if I kept responding to any messages about KDE with: > "Please just ignore this KDE nonsense. The more maintainers boycott it, > the less likely it is to succeed and produce completely unnecessary > extra work for you, me and all the other maintainers" ? > Kevin aside, the way the modular server was introduced in Fedora 27 was poorly handled. It should have never been declared as a replacement deliverable for the classic Fedora Server for the Fedora 27 release. It's very clear now that was a mistake, as now one third of the deliverables aren't even going to be released until mid January, probably later. The necessary tooling to properly do modular composes didn't even go live until a couple of weeks ago. If I thought there was a shot to fix this, I'd be proposing that we *ignore* Modular server for the Fedora 27 release and release the regular Fedora Server for Fedora 27, and ship the Modular server as another tech preview post Fedora 27 release. That would give it more time to bake and deal with the inherent issues with modularity for Fedora 28. This was the approach we took with Atomic replacing the Cloud Edition, and I have no idea why anyone thought it was a good idea to ignore that process for modularity. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: streamlining fedora-release
Zbigniew Jędrzejewski-Szmek wrote: > The fedora-release package contains stuff that is tied to each Fedora > version and changes slowly, and it also contains the preset files for > systemd units, which change fairly often (a few requests per month). Why not have a separate fedora-presets then? Just like fedora-repos was split out from fedora-release several releases ago. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
On 11/09/2017 02:26 AM, Yaakov Selkowitz wrote: On 2017-11-08 11:08, Björn 'besser82' Esser wrote: since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30). Is anyone besides us (committed to) using and contributing to libxcrypt? Doesn't matter IMHO because libcrypt-nss is essentially our very own special snowflake, too. While splitting things out of glibc is overall probably a good thing -- IMO the ecosystem has generally benefited from libtirpc -- in this case the proposed removal method concerns me: * crypt(3)'s declaration is in unistd.h according to SUS. While a duplicate declaration has been in crypt.h for some time, standards-conforming software can reasonably rely on the former. The glibc crypt removal proposal included an outright removal of this declaration, along with _XOPEN_CRYPT, which would leave no way for libxcrypt to fulfill the standard. Instead, if at least GCC 5 can be assumed, they should be made conditional on __has_include(). I think we can keep crypt at least in Fedora's . * encrypt and setkey, while noted in the Future Directions as subject to future obsoletion or removal, is still not even officially obsolete in SUSv4. This plan seems to leave no way whatsoever to compile software which depends on these still-standardized calls. But these calls are truly obsolete. We can't change them from 56-bit DES in glibc for backwards compatibility reasons, and applications really should not use DES anymore. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Modularity questions for "traditional" RPM packaging
On 11/10/2017 02:23 PM, Kevin Kofler wrote: > Please just ignore this module nonsense. The more maintainers boycott it, > the less likely it is to succeed and produce completely unnecessary extra > work for you, me and all the other maintainers. Kevin, please stop the trolling and belittling others. This is out of line. How would YOU feel if I kept responding to any messages about KDE with: "Please just ignore this KDE nonsense. The more maintainers boycott it, the less likely it is to succeed and produce completely unnecessary extra work for you, me and all the other maintainers" ? Thanks. Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
On 11/08/2017 06:08 PM, Björn 'besser82' Esser wrote: Hello everyone, since there has been some discussion in the last time about removing libcrypt from glibc in some time [1,2,3,4] and splitting it out into a separate project which can evolve quicker, I'd like to hear your oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora 29 (or 30). I'd prefer this to happen in Fedora 28 if at all possible. Anyways, before this can happen, there is still some work to be done with libxcrypt, like adding a FIPS mode or FIPS compliance in a different way. I think the best way to achieve that would be to contribute libxcrypt (its interfaces and its peculiar build process) to some FIPS-validated cryptographic libraries, so that the actual algorithms and FIPS mode logic could be reused from that library. Otherwise, unless you have experience dealing with FIPS requirements and getting cryptographic libraries through validation, I strongly recommend not to work on this at all. If and when we need this downstream, we can contribute exactly what is needed according to the auditors back upstream. Personally, I do not have a way to know what the requirements would be in advance. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Modularity questions for "traditional" RPM packaging
Christopher wrote: > Is it necessary for maintainers to create modules for their RPM packages? > Is modularity something that a maintainer for an RPM package must deal > with? Please just ignore this module nonsense. The more maintainers boycott it, the less likely it is to succeed and produce completely unnecessary extra work for you, me and all the other maintainers. Thanks in advance, Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
Björn 'besser82' Esser wrote: > libxcrypt will be fully binary compatible with software linked against > glibc's libcrypt and does not require any rebuilds. However, the > converse is not true: programs linked against libxcrypt will not work > with glibc's libcrypt. It comes with a set of extended interfaces > pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, > crypt_gensalt_rn, and crypt_gensalt_ra. Also, programs that use > certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r, > setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt. I think it would make more sense to add the new APIs to glibc, without dropping existing APIs or changing the implementation of the remaining existing APIs. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: time-1.8
= System Wide Change: time-1.8 = https://fedoraproject.org/wiki/Changes/time-1.8 Change owner(s): * Petr A new time tool version 1.8 has changed output format. == Detailed Description == After many years a new 1.8 version of time tool was released. This version brings some noticeable changes: License changed from (GPLv2+) to (GPLv3+ and GFDL). Additional exit codes are used to report measured command failures and failures to execute the command. A measured command failure is reported by default. See the first line in this output: $ time /usr/bin/false Command exited with non-zero status 1 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 1196maxresident)k 0inputs+0outputs (0major+55minor)pagefaults 0swaps In previous Fedora versions, the first line was printed only if -v option was specified. This is not true anymore and the line is printed by default. You can disable it with a new -q option: $ time -q /usr/bin/false 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 1268maxresident)k 0inputs+0outputs (0major+55minor)pagefaults 0swaps Because this violated POSIX mode, Fedora changed time-1.8 not to print the first line when invoked with -p option and upstream accepted the change so that future time versions will behave like Fedora. For Fedora users, there is no change in the POSIX mode output: $ time -p /usr/bin/false real 0.00 user 0.00 sys 0.00 If you use time tool in your script without the -p option, then either adjust your script to expect different output, or add -q option. Be ware of portability across distributions using different time versions. == Scope == * Proposal owners: The time package will be upgraded and patched to preserve output format in the POSIX mode. * Other developers: Review their scripts and packages whether they use time' in non-POSIX mode and parse time's output. If they are affected, they should add -q option to the time command, or adjust their code do deal with the new first line. * Release engineering: https://pagure.io/releng/issue/7153 * List of deliverables: Not affected * Policies and guidelines: No change is needed. * Trademark approval: No approval is needed. -- 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 27-20171110.n.0 compose check report
Missing expected images: Workstation live i386 Kde live i386 Failed openQA tests: 6/137 (x86_64) New failures (same test did not fail in 27-20171105.n.0): ID: 168248 Test: x86_64 Workstation Ostree-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/168248 ID: 168272 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/168272 ID: 168280 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/168280 ID: 168298 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/168298 Old failures (same test failed in 27-20171105.n.0): ID: 168243 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/168243 ID: 168302 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/168302 Soft failed openQA tests: 5/137 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in 27-20171105.n.0): ID: 168315 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168315 Old soft failures (same test soft failed in 27-20171105.n.0): ID: 168299 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/168299 ID: 168301 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/168301 ID: 168316 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/168316 ID: 168323 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/168323 Passed openQA tests: 119/137 (x86_64), 22/22 (i386), 2/2 (arm) New passes (same test did not pass in 27-20171105.n.0): ID: 168194 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/168194 ID: 168209 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/168209 ID: 168217 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/168217 ID: 168234 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/168234 ID: 168245 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/168245 ID: 168262 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/168262 ID: 168281 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/168281 ID: 168309 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/168309 ID: 168319 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/168319 ID: 168337 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/168337 ID: 168351 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/168351 Skipped openQA tests: 6 of 161 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 1 services(s) added since previous compose: rpc-statd-notify.service Previous test data: https://openqa.fedoraproject.org/tests/165743#downloads Current test data: https://openqa.fedoraproject.org/tests/168185#downloads Installed system changes in test x86_64 Server-boot-iso install_default: 1 services(s) added since previous compose: rpc-statd-notify.service Previous test data: https://openqa.fedoraproject.org/tests/165744#downloads Current test data: https://openqa.fedoraproject.org/tests/168186#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.08 to 0.23 Previous test data: https://openqa.fedoraproject.org/tests/165745#downloads Current test data: https://openqa.fedoraproject.org/tests/168188#downloads Installed system changes in test i386 Server-boot-iso install_default: 1 services(s) added since previous compose: rpc-statd-notify.service Previous test data: https://openqa.fedoraproject.org/tests/165765#downloads Current test data: https://openqa.fedoraproject.org/tests/168207#downloads Installed system changes in test i386 Server-dvd-iso install_default: System load changed from 0.08 to 0.44 Previous test data: https://openqa.fedoraproject.org/tests/165766#downloads Current test data: https://openqa.fedoraproject.org/tests/168208#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.72 to 0.23 Used mem changed from 1025 MiB to 897 MiB Previous test data: https://openqa.fedoraproject.org/tests/165771#downloads Current test data: https://openqa.fedoraproject.org/tests/168214#downloads Installed system changes in test x86_64 Workstation-boot-iso install_de
Re: Tagging large packages (texlive) takes a very long time
On Thu, Nov 09, 2017 at 01:52:19PM +, Richard W.M. Jones wrote: > On Thu, Nov 09, 2017 at 12:01:44PM +, Richard W.M. Jones wrote: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=23008582 > > > > This has been stuck in the final tagging stage for must be at least 1 > > hour now, possibly 2 hours. > > Still tagging! I'm starting to wonder if it's broken. 24 hours and counting ... I talked to someone on #fedora-admin about this and it is caused by Koji having to load the metadata (files, dependencies etc) of every RPM into its database. Combined with the fact this happens to be running on s390x and it's texlive, makes it slow. Still, this is blocking the builds of anything that depends on tex, which is quite a lot of things because documentation tends to be built using tools that use tex. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CUPS will change license since 2.3 version - now incompatible with GPLv2
On 2017-11-09 07:27, Zdenek Dohnal wrote: Adding gtk+ maintainer. Paul, would you mind commenting about this issue? On 11/09/2017 01:07 AM, Michael Catanzaro wrote: On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa wrote: libkprint, kde-print-manager, etc. may have dependencies that make the mix impossible. I don't know for sure, though. gtk+ isn't linked with cups. However, gtk2 and gtk3 are. Should probably ask Matthias, who maintains the non-legacy gtk libraries. Cheers, Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
