Fwd: Broken dependencies: redhat-rpm-config
Started getting these bogus broken deps emails after merging a request to depend on gcc conditionally. Is the broken dependencies check done with yum era repoclosure still, or...? - Panu - Forwarded Message Subject: Broken dependencies: redhat-rpm-config Date: Tue, 9 Jan 2018 01:30:25 + (UTC) From: build...@fedoraproject.org To: redhat-rpm-config-ow...@fedoraproject.org redhat-rpm-config has broken dependencies in the rawhide tree: On x86_64: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On armhfp: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On ppc64le: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On aarch64: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On ppc64: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On s390x: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) On i386: redhat-rpm-config-72-1.fc28.noarch requires (annobin if gcc) Please resolve this as soon as possible. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20180108.n.0 compose check report
No missing expected images. Failed openQA tests: 15/128 (x86_64), 4/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180107.n.0): ID: 184999 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/184999 ID: 185004 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/185004 ID: 185059 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/185059 ID: 185070 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/185070 Old failures (same test failed in Rawhide-20180107.n.0): ID: 184923 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/184923 ID: 184958 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/184958 ID: 184959 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/184959 ID: 184960 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/184960 ID: 184969 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/184969 ID: 184971 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/184971 ID: 184972 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/184972 ID: 185013 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/185013 ID: 185030 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/185030 ID: 185031 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/185031 ID: 185034 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/185034 ID: 185035 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/185035 ID: 185036 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/185036 ID: 185053 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/185053 ID: 185064 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/185064 ID: 185069 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/185069 Soft failed openQA tests: 74/128 (x86_64), 19/24 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20180107.n.0): ID: 184940 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/184940 ID: 184955 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/184955 ID: 185000 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/185000 ID: 185021 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/185021 Old soft failures (same test soft failed in Rawhide-20180107.n.0): ID: 184911 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/184911 ID: 184912 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184912 ID: 184913 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/184913 ID: 184914 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/184914 ID: 184921 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/184921 ID: 184922 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/184922 ID: 184931 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/184931 ID: 184933 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184933 ID: 184934 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/184934 ID: 184935 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/184935 ID: 184936 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184936 ID: 184937 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184937 ID: 184938 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/184938 ID: 184939 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/184939 ID: 184951 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184951 ID: 184954
Re: F28 System Wide Change: AArch64 Server Promotion
On Tue, 2018-01-09 at 04:09 +, Peter Robinson wrote: > On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson > wrote: > > On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote: > > > > > > > A significant miss here is 'testing'. Making an arch primary means we > > > > need to ensure we have the necessary resources to run all the relevant > > > > validation testing. > > > > > > > > I note pwhalen is a co-owner of the proposal so he's likely signed up > > > > to ensure testing gets done, but still, it should be properly covered > > > > in the Change document itself. > > > > > > Yes, we've got a bunch of stuff here but the change document template > > > doesn't really have a good spot to outline all of that. > > > > It does have an entire section called "How To Test". > > Fair enough, I was assuming more that was a end user individual as > opposed to CI/CD/infra details I mean, it's a template. Adjust as appropriate. Including the relevant material seems clearly preferable to leaving it out. Anyhoo. -- 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
Re: F28 System Wide Change: AArch64 Server Promotion
On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson wrote: > On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote: >> >> > A significant miss here is 'testing'. Making an arch primary means we >> > need to ensure we have the necessary resources to run all the relevant >> > validation testing. >> > >> > I note pwhalen is a co-owner of the proposal so he's likely signed up >> > to ensure testing gets done, but still, it should be properly covered >> > in the Change document itself. >> >> Yes, we've got a bunch of stuff here but the change document template >> doesn't really have a good spot to outline all of that. > > It does have an entire section called "How To Test". Fair enough, I was assuming more that was a end user individual as opposed to CI/CD/infra details ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
On Mon, Jan 8, 2018 at 8:17 PM, Peter Robinson wrote: I thought for some reason that all updates marked as security were automatically urgent, maybe I'm misremembering, but if not it might be good to do that as a RFE that way all security updates go out non batched. Most security updates are simply not urgent, and we really don't want to pester users with these on a daily basis. So it would be nice if security updates went through batched by default. Still, this update was marked as a high-severity security update. It probably makes sense that those should skip batched, in addition to updates marked as urgent. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
>> > == Scope == >> > * Proposal owners: >> > The general AArch64 support is already in place and is widely and >> > actively supported by the Fedora ARM SIG and numerous ARM vendors >> > and >> > third parties in Fedora. There will be further and wider support, >> > hardware enablement, polish and general improvements. >> > >> > * Other developers: >> > N/A: There's no work required for other developers, the aarch64 >> > architecture is already widely supported as an Alternate >> > Architecture. >> > >> > * Release engineering: >> > Needs approval from release engineering as a primary architecture >> > as >> > well as pungi configuration changes to output artifacts to new >> > location on the primary mirror. >> > rel-eng ticket #7243: https://pagure.io/releng/issue/7243 >> > >> > * Policies and guidelines: >> > Updates to the primary architectures and release blocking details >> > will >> > need to be updated to reflect that the AArch64 Server/Cloud/Docker >> > components are now considered primary. >> > >> > * Trademark approval: >> > N/A (not needed for this Change) >> >> A significant miss here is 'testing'. Making an arch primary means we >> need to ensure we have the necessary resources to run all the >> relevant >> validation testing. >> >> I note pwhalen is a co-owner of the proposal so he's likely signed up >> to ensure testing gets done, but still, it should be properly covered >> in the Change document itself. >> >> As a further note, almost all the Server validation for x86_64 is >> done >> by openQA; doing it manually can be a considerable pain, as you have >> to >> set up a mini FreeIPA deployment. It would probably be best if we add >> aarch64 workers to the Fedora openQA deployment to run these tests on >> aarch64; we've already extended openQA (staging) to ppc64, so all the >> bits should be in place for us to add another arch, pretty much. I'm >> going to follow up on this with pwhalen. >> >> Another consideration would be whether we ought to also have aarch64 >> support in Taskotron, if it's going to become a primary arch. I'm not >> actually sure if Taskotron currently covers 32-bit ARM, though, even. > > currently taskotron is x86 only. I am not sure what it would take to > extend it beyond x86, it would be a worthwhile investigation. It would > be useful to have all arches in openQA regardless of primary or > secondary status. I would like to see openQA working for aarch64 in > Fedora's instance a hard requirement of this change. I'm fine with that, we already have OpenQA working fine on aarch64 and the only reason it's not yet in the Fedora infra was that we were awaiting on the DC move and the EOL of Fedora 25 to be able to move hardware around. In fact it basically was a hard requirement for myself (and I suspect Paul as well) as basically I'm lazy and would prefer a machine do as much as the testing as humanly possible so I don't have to :-D Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote: > > > A significant miss here is 'testing'. Making an arch primary means we > > need to ensure we have the necessary resources to run all the relevant > > validation testing. > > > > I note pwhalen is a co-owner of the proposal so he's likely signed up > > to ensure testing gets done, but still, it should be properly covered > > in the Change document itself. > > Yes, we've got a bunch of stuff here but the change document template > doesn't really have a good spot to outline all of that. It does have an entire section called "How To Test". -- 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
Re: F28 Self Contained Change: Anaconda modularization
On Tue, 2018-01-09 at 02:31 +, Peter Robinson wrote: > On Mon, Jan 8, 2018 at 2:01 PM, Matthew Miller > wrote: > > On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote: > > > Yep - basically, there will be no "old" and "new, DBUS/modular" > > > Anaconda, the plan is to turn the current Anaconda to the new one one > > > step at a time. > > > > > > This should allow us to fix bugs as usual and handle any unforeseen > > > modularization issues early on one-by-one as they show up. > > > > It sounds like there actually isn't a contingency plan as such. Do you > > think that this could all be reverted on Final Freeze day if we would > > decide it's not working out? If not, let's not call that a contingency. > > I would argue this isn't a "Self Contained Change" but a system wide > one. If anaconda is broken we can't even compose so this should all be > landed and complete by the time the system wide features need to be. Yeah, good point. I'd agree this should be considered system-wide, not self-contained. -- 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
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 6:06 PM, Andreas Tunek wrote: > 2018-01-08 19:03 GMT+01:00 Jonathan Dieter : >> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >>> On 8 January 2018 at 12:28, Matthew Miller >>> wrote: >>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >>> > > A significant miss here is 'testing'. Making an arch primary >>> > > means we >>> > > need to ensure we have the necessary resources to run all the >>> > > relevant >>> > > validation testing. >>> > >>> > Are there hardware needs here? (Like, not in the server room but in >>> > QA >>> > team member's hands?) >>> > >>> >>> I would say in both. We would need to make sure we have enough >>> systems >>> which openqa can reliably run on and we need to have some sort of >>> system that testers can get a hand on. That would require a bit of a >>> 'we expect this hardware to work and this is how you buy/get it' from >>> the aarch64 team.. otherwise most everyone is going to come and ask >>> why the raspberry pi 3 isn't supported (just like they did with the >>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >>> more that is what most testers can get their hands on easily.. and it >>> is not a aarch64 platform we support). >> >> I may be going off in the weeds here, but is https://fedoraproject.org/ >> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not >> accurate when it says it *is* supported? >> > > That link does not work for me and I get some strange redirect to the > Fedora download page. https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 6:03 PM, Jonathan Dieter wrote: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >> On 8 January 2018 at 12:28, Matthew Miller >> wrote: >> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> > > A significant miss here is 'testing'. Making an arch primary >> > > means we >> > > need to ensure we have the necessary resources to run all the >> > > relevant >> > > validation testing. >> > >> > Are there hardware needs here? (Like, not in the server room but in >> > QA >> > team member's hands?) >> > >> >> I would say in both. We would need to make sure we have enough >> systems >> which openqa can reliably run on and we need to have some sort of >> system that testers can get a hand on. That would require a bit of a >> 'we expect this hardware to work and this is how you buy/get it' from >> the aarch64 team.. otherwise most everyone is going to come and ask >> why the raspberry pi 3 isn't supported (just like they did with the >> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >> more that is what most testers can get their hands on easily.. and it >> is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? Nope, it's completely accurate and it's supported ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 5:53 PM, Stephen John Smoogen wrote: > On 8 January 2018 at 12:28, Matthew Miller wrote: >> On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >>> A significant miss here is 'testing'. Making an arch primary means we >>> need to ensure we have the necessary resources to run all the relevant >>> validation testing. >> >> Are there hardware needs here? (Like, not in the server room but in QA >> team member's hands?) >> > > I would say in both. We would need to make sure we have enough systems > which openqa can reliably run on and we need to have some sort of > system that testers can get a hand on. That would require a bit of a There will be more than enough HW for openQA, we have two large systems we'll put into the cloud (awaiting commissioning now the DC migration is done) which will enable us to use AutoCloud (or what ever it's replacement is) for VM/Docker testing, and a number of physical systems for OpenQA. > 'we expect this hardware to work and this is how you buy/get it' from > the aarch64 team.. otherwise most everyone is going to come and ask > why the raspberry pi 3 isn't supported (just like they did with the The Raspberry Pi 3 *IS* supported on aarch64 [1]! As is the Pine64, currently headless needs a serial console but by F-28 it will be supported with basic console out for HDMI too, We support around 20 aarch64 SBCs in F-27 [1] and I expect that to likely double, or even more than that, with F-28. Along with all the SBSA compliant hardware etc. I have the ability to get HW provided to people that are actually going to use it for testing the problem I have here is that I regularly give people hardware for testing and I get zero testing back and Paul, myself and others still end up doing all the testing. > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. > more that is what most testers can get their hands on easily.. and it > is not a aarch64 platform we support). Err, RPi 0-2 are 32 bit only devices in the case of < 2 they're ARMv6, and we support the RPi2 with 32 bit I don't see how any of that is relevant to this conversation? [1] https://nullr0ute.com/2017/11/overview-of-aarch64-sbc-support-in-fedora-27/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamson wrote: > On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote: >> >> == Scope == >> * Proposal owners: >> The general AArch64 support is already in place and is widely and >> actively supported by the Fedora ARM SIG and numerous ARM vendors and >> third parties in Fedora. There will be further and wider support, >> hardware enablement, polish and general improvements. >> >> * Other developers: >> N/A: There's no work required for other developers, the aarch64 >> architecture is already widely supported as an Alternate Architecture. >> >> * Release engineering: >> Needs approval from release engineering as a primary architecture as >> well as pungi configuration changes to output artifacts to new >> location on the primary mirror. >> rel-eng ticket #7243: https://pagure.io/releng/issue/7243 >> >> * Policies and guidelines: >> Updates to the primary architectures and release blocking details will >> need to be updated to reflect that the AArch64 Server/Cloud/Docker >> components are now considered primary. >> >> * Trademark approval: >> N/A (not needed for this Change) > > A significant miss here is 'testing'. Making an arch primary means we > need to ensure we have the necessary resources to run all the relevant > validation testing. > > I note pwhalen is a co-owner of the proposal so he's likely signed up > to ensure testing gets done, but still, it should be properly covered > in the Change document itself. Yes, we've got a bunch of stuff here but the change document template doesn't really have a good spot to outline all of that. > As a further note, almost all the Server validation for x86_64 is done > by openQA; doing it manually can be a considerable pain, as you have to > set up a mini FreeIPA deployment. It would probably be best if we add > aarch64 workers to the Fedora openQA deployment to run these tests on > aarch64; we've already extended openQA (staging) to ppc64, so all the > bits should be in place for us to add another arch, pretty much. I'm > going to follow up on this with pwhalen. Yes, that is the plan, we have the HW to do it and Paul Whalen has it running locally, the reason it's not in place already basically comes down to two things: 1) we needed to wait for the DC migration before we could set some of it up 2) with all the various changes around CI/testing/modularity etc awaiting to see what the final outcome would be > Another consideration would be whether we ought to also have aarch64 > support in Taskotron, if it's going to become a primary arch. I'm not > actually sure if Taskotron currently covers 32-bit ARM, though, even. That's also on my list, basically we have some hardware, with the option of more, I had on my list of options: * openQA * auto cloud * task-o-tron * other CI/CD pipelines * any other options. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Anaconda modularization
On Mon, Jan 8, 2018 at 2:01 PM, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote: >> Yep - basically, there will be no "old" and "new, DBUS/modular" >> Anaconda, the plan is to turn the current Anaconda to the new one one >> step at a time. >> >> This should allow us to fix bugs as usual and handle any unforeseen >> modularization issues early on one-by-one as they show up. > > It sounds like there actually isn't a contingency plan as such. Do you > think that this could all be reverted on Final Freeze day if we would > decide it's not working out? If not, let's not call that a contingency. I would argue this isn't a "Self Contained Change" but a system wide one. If anaconda is broken we can't even compose so this should all be landed and complete by the time the system wide features need to be. > I'm not saying we shouldn't do this, but let's be honest with > ourselves. If the contingency plan is "None: we'll have to hold up the > release for fixes if it's not ready", the Change plan should say that. And we should be honest that the "Final Freeze day" is _WAY_ too late to be working out whether we should revert this or not! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
On Mon, Jan 8, 2018 at 5:39 PM, Kevin Fenzi wrote: > On 01/07/2018 08:01 PM, Kevin Kofler wrote: >> Kevin Fenzi wrote: >>> The critera for bypassing batched is if the update is marked "urgent". >> >> The problem is, this appears to be insufficient. > Well, if this firefox update was urgent, shouldn't it have been marked > urgent? I thought for some reason that all updates marked as security were automatically urgent, maybe I'm misremembering, but if not it might be good to do that as a RFE that way all security updates go out non batched. >> I really don't understand why we do this "batched" thing to begin with. > > To reduce the constant flow of updates that are very minor or affect > very few mixed in with the major updates that affect lots of people and > are urgent. To save users downloads of repodata. > >> Users who want to batch updates have always been able to do it, GNOME >> Software will even do it for theNow, those users who want to batch their >> updates are forced to follow Fedora rel-eng's schedule for the batches >> rather than being able to pick their own weekday, so how does the server- >> side batching help them? And those users (like me) who want to get their >> updates, including security fixes (!) as we see here, as soon as they passed >> testing are now screwed. > > rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch > appears on wed's pushes). > > There was some discussion about changing the gnome batching based on the > Fedora batching, but I don't know whats happened there. > > I haven't seen a bunch of urgent updates get blocked by this process. > Do you have more data for updates that hit this? > >> If people insist on that "batched" misfeature, can we please at least get a >> fast track repository that contains all the batched updates (but no updates >> that are still in testing and have not been batched yet!)? > > I would be very much against additional repos like this. > > > kevin > > > ___ > 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: Security updates and batched pushes
On Mon, 08 Jan 2018 19:53:01 +0100 Kevin Kofler wrote: > Batching really needs to be left to the client side! Right. I did wonder what was going on with the updates... dnf-cron, gnome-software etc could all *default* to weekly. But if I'm doing a dnf update, I want the updates *now*. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 08, 2018 at 04:37:34PM -0800, Adam Williamson wrote: > > Are there hardware needs here? (Like, not in the server room but in QA > > team member's hands?) > pwhalen has hardware. Not sure who else does. I'm not going to ask for > any, because it'd just join all my ARM hardware in the Pile Of Boxes I > Never Get Time To Open. If anyone else on the QA team (or Server SIG) has time but *not* the pile of boxes, this is a good time to say something. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability
On Mon, Jan 08, 2018 at 08:27:22PM -0500, Matthew Miller wrote: > > combination of the 2. Unfortunately both have external requirements. > > Retpoline requires GCC patches, and microcode updates for some CPUs. > > IBRS requires microcode updates. While RHEL has done quite a bit of > > Does this mean we should do a mass rebuild once those patches have > landed? We have a mass rebuild scheduled for Jan 31st (basically three > weeks from now). Is that too soon? Or are the GCC changes just needed for the kernel itself? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability
On Mon, Jan 08, 2018 at 04:49:44PM -0600, Justin Forbes wrote: > combination of the 2. Unfortunately both have external requirements. > Retpoline requires GCC patches, and microcode updates for some CPUs. > IBRS requires microcode updates. While RHEL has done quite a bit of Does this mean we should do a mass rebuild once those patches have landed? We have a mass rebuild scheduled for Jan 31st (basically three weeks from now). Is that too soon? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 20:03 +0200, Jonathan Dieter wrote: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: > > On 8 January 2018 at 12:28, Matthew Miller > > wrote: > > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > > > A significant miss here is 'testing'. Making an arch primary > > > > means we > > > > need to ensure we have the necessary resources to run all the > > > > relevant > > > > validation testing. > > > > > > Are there hardware needs here? (Like, not in the server room but in > > > QA > > > team member's hands?) > > > > > > > I would say in both. We would need to make sure we have enough > > systems > > which openqa can reliably run on and we need to have some sort of > > system that testers can get a hand on. That would require a bit of a > > 'we expect this hardware to work and this is how you buy/get it' from > > the aarch64 team.. otherwise most everyone is going to come and ask > > why the raspberry pi 3 isn't supported (just like they did with the > > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. > > more that is what most testers can get their hands on easily.. and it > > is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? I'd say it's slightly unclear. So far as *the ARM team* is concerned, they 'support' that hardware, but so far as *anyone else* is concerned, aarch64 has been a secondary arch all this time. No aarch64 image has been considered 'release-blocking', the aarch64 trees / images are published in the fedora-secondary tree (not the fedora tree), etc. -- 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
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: > On 8 January 2018 at 12:28, Matthew Miller wrote: > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > > A significant miss here is 'testing'. Making an arch primary means we > > > need to ensure we have the necessary resources to run all the relevant > > > validation testing. > > > > Are there hardware needs here? (Like, not in the server room but in QA > > team member's hands?) > > > > I would say in both. We would need to make sure we have enough systems > which openqa can reliably run on and we need to have some sort of > system that testers can get a hand on. That would require a bit of a > 'we expect this hardware to work and this is how you buy/get it' from > the aarch64 team.. pwhalen says we already have hardware available in phx, but I haven't asked him for more details yet. We wouldn't need much to run the necessary tests, really. Enough boxes to run ~8 VMs simultaneously would probably suffice. -- 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
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 12:28 -0500, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > A significant miss here is 'testing'. Making an arch primary means we > > need to ensure we have the necessary resources to run all the relevant > > validation testing. > > Are there hardware needs here? (Like, not in the server room but in QA > team member's hands?) pwhalen has hardware. Not sure who else does. I'm not going to ask for any, because it'd just join all my ARM hardware in the Pile Of Boxes I Never Get Time To Open. -- 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
Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability
tl;dr: We are fixing things as quickly as we can safely do so. The fixes will be ongoing, keep testing and installing new kernels as they appear! On Sat, Jan 6, 2018 at 1:32 PM, Chris Adams wrote: > Once upon a time, Adam Williamson said: >> * If the fix does cause problems on your hardware, you can disable it >> by booting with the kernel parameter 'nopti'. > > So, on RHEL/CentOS kernels, there are three new entries in > /sys/kernel/debug/x86; ibpb_enabled, ibrs_enabled, and pti_enabled. I > don't see these on the Fedora kernel. > > Are these variables something added by Red Hat to their kernel, > something that will be added to Fedora, etc.? They are useful to see > exactly what fix(es) are being applied, as well as to have a runtime way > to enable/disable them. These do not exist in Fedora yet. For KPTI, the feature is implemented, but there isn't a debugfs entry. Variant 2 Spectre mitigation has a couple of proposed solutions. IBRS and retpoline are both being discussed upstream, and the end result will likely be a combination of the 2. Unfortunately both have external requirements. Retpoline requires GCC patches, and microcode updates for some CPUs. IBRS requires microcode updates. While RHEL has done quite a bit of testing with IBRS in their kernels, Fedora moves a lot quicker and current Fedora kernels are substantially different from the current RHEL kernels. Additionally, while RHEL was given microcode to ship with these updates, Intel has not released them upstream (soon I am told). It is entirely possible that the patches floating around upstream have not been tested with the microcode that RHEL shipped. Given that variant 2 is difficult (not impossible) to attack, we have been waiting to see what we can ship, when microcode is available and GCC updates are available. I can assure you that I have spending pretty much all of my time tracking upstream, testing patch sets, and doing what I can to make sure we have mitigations for all 3 variants in place as quickly as possible. Today's build of rawhide contains mitigation for variant 1 of spectre and variant 3 (meltdown) for x86_64. Current stable Fedora kernels contain mitigation for meltdown on x86_64 as well. Wednesday should see a new kernel pushed to updates-testing with some bug fixes for the meltdown mitigation (KPTI), and some mitigation for variant 1. I am hoping to also get some meltdown coverage for other architectures in that update. While I would love to see some variant 2 coverage as well, it is unlikely in the Wednesday time frame. If it is possible, I will include those as well, but even then, it will not be the final solution. As soon as a solution is deemed ready, it will be pushed to Fedora. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity WG (once every two weeks)
Dear all, You are kindly invited to the meeting: Modularity WG (once every two weeks) on 2018-01-09 from 10:00:00 to 11:00:00 US/Eastern At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](https://board.net/p/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5249/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Ruby 2.5 - Mass rebuild
Hi, Vít. On Monday, 08 January 2018 at 15:19, Vít Ondruch wrote: > Hi everybody, > > The sidetag with Ruby 2.5 and all the rebuilt packages were merged into > F25 [1]. Since the update of Ruby involved soname > bump, we managed to rebuild most of the depending packages. But there > are still some packages which are broken for various reasons (you can > see the analysis of them here [2]. But luckily, some of the issues from > the list were already resolved). We will try to fix them, but of course, > any help is welcome. > > Also, please check your pure Ruby packages for compatibility with Ruby > 2.5 (Koschei will help you to catch those issues), but there were no > major issues during rebuild, so I am quite positive there wont be many. > > Let us know if you need some help ... I could use some help debugging mkvtoolnix build failure. It doesn't depend on Ruby directly, but it uses drake to build: https://apps.fedoraproject.org/koschei/package/mkvtoolnix?collection=f28 and fails with: [...] rake aborted! File exists @ dir_s_mkdir - ./rake.d/dependency.d Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
- Original Message - > On Mon, Jan 8, 2018 at 2:52 PM, Jonathan Lebon wrote: > > Interestingly, these are both things that Atomic Host make > > easier to query. > > > > E.g. if both VMs are on AH but sitting on different commits, > > you can pull the commit on one of the two and do: > > > > $ rpm-ostree db diff COMMIT1 COMMIT2 > > oh, that's so very nice. Can it be extracted, split out to a script? > (ie: point it to two rpmdb dirs...) It's not pretty, though here's a Gist that does this: https://gist.github.com/jlebon/790fcd04646e10bb09ae7993b20ca307 You'll need `ostree` and `rpm-ostree` (which can be installed equally well in yum/dnf-managed systems). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
On Mon, Jan 8, 2018 at 3:38 PM, Fernando Nasser wrote: > On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote: >> >> On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser >> wrote: >>> >>> On 2018-01-08 12:21 PM, Steve Dickson wrote: Hello, Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0: http://server.com/package1/package1.tar Source1: http://server.com/package2/package2.tar >> >> It happens all the time. Subversion used to do this a lot, when the >> requirement for the "swig" library was more recent than what was in >> Fedora. It also happens quite a lot for RHEL and EPEL packages, where >> the necessary versions of various libraries may conflict with the >> stable, standard library used by other tools. > > > Hum... not sure if this was good form. An important security fix may fail > to be applied to this "hidden" library for one thing. This is absolutely true. It's especially been necessary for various EPEL packages, which may have requirements of more recent libraries. > This is supposed to be handled by having a versioned package for the > alternative library version that could then be used by this package (as > opposed as the default Fedora version of it). Yeah. It can be awkward to maintain, and the potential requirement is precisely why the "%setup" macro in RPM is designed to support the extraction of multiple tarballs in an arbitrary build layout: because some packages are published as a set of multiple tarballs. "git", for example, has often been built from the distinct git, git-html, and git-manpages tarballs from upstream in order to avoid having to build those other components and require all the build tools for documentation on the local RPM build environment. Been there, done that, publish tools for CentOS 6 and 7 for git-2.15 at https://github.com/nkadel/git215-srpm/blob/master/git215.spec "texlive" is a better example, since it has so many source tarballs for different fonts from upstreamy. I count roughly 7000 distinct Source tarballs listed in texlive.spec, Those *are* the Fedora system component for those fonts, so it's a better example of where the usage or multiple tarballs makes great sense sense. Building distinct, internal libraries has been unusual to need directly for Fedora, since Fedora tends to be near the bleeding edge of software releases. But it's certainly happened on occasion, especially if software needs to be backported to EPEL for RHEL and CentOS use, or for for older versions of Fedora. > This has similar problems as using the Maven shadow plugin in Fedora Java > builds (which is AFAIK also discouraged). > > --Fernando > > > >> ___ >> 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: Changelog between OS states (ie: VMs)
On Mon, Jan 8, 2018 at 2:52 PM, Jonathan Lebon wrote: > Interestingly, these are both things that Atomic Host make > easier to query. > > E.g. if both VMs are on AH but sitting on different commits, > you can pull the commit on one of the two and do: > > $ rpm-ostree db diff COMMIT1 COMMIT2 oh, that's so very nice. Can it be extracted, split out to a script? (ie: point it to two rpmdb dirs...) thanks, m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote: On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser wrote: On 2018-01-08 12:21 PM, Steve Dickson wrote: Hello, Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0: http://server.com/package1/package1.tar Source1: http://server.com/package2/package2.tar It happens all the time. Subversion used to do this a lot, when the requirement for the "swig" library was more recent than what was in Fedora. It also happens quite a lot for RHEL and EPEL packages, where the necessary versions of various libraries may conflict with the stable, standard library used by other tools. Hum... not sure if this was good form. An important security fix may fail to be applied to this "hidden" library for one thing. This is supposed to be handled by having a versioned package for the alternative library version that could then be used by this package (as opposed as the default Fedora version of it). This has similar problems as using the Maven shadow plugin in Fedora Java builds (which is AFAIK also discouraged). --Fernando ___ 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: Package Question
On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser wrote: > On 2018-01-08 12:21 PM, Steve Dickson wrote: >> >> Hello, >> >> Is it a problem for a package to pull from two different >> upstream tar balls? Basically have >> >> Source0: http://server.com/package1/package1.tar >> Source1: http://server.com/package2/package2.tar It happens all the time. Subversion used to do this a lot, when the requirement for the "swig" library was more recent than what was in Fedora. It also happens quite a lot for RHEL and EPEL packages, where the necessary versions of various libraries may conflict with the stable, standard library used by other tools. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
- Original Message - > On Mon, Jan 8, 2018 at 1:19 PM, Nico Kadel-Garcia wrote: > I fully agree wrt configuration changes. I am scoping my interest > exclusively to rpms. > > A bit like saying "I run yum/dnf update on an OS, what bugfixes are > landing/have landed?" Interestingly, these are both things that Atomic Host make easier to query. E.g. if both VMs are on AH but sitting on different commits, you can pull the commit on one of the two and do: $ rpm-ostree db diff COMMIT1 COMMIT2 to get a diff of the rpmdb between the two, and with the `--changelogs` flag, it will also output new changelog entries. Re. configuration changes, not exactly what you were looking for, though `ostree admin config-diff` allows you to see which `/etc` files were changed/added/removed from the base shipped configuration. Anyway, I realize this doesn't help if your VMs are not currently on AH, though just thought I'd bring it up for general interest! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
On 2018-01-08 12:21 PM, Steve Dickson wrote: Hello, Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0: http://server.com/package1/package1.tar Source1: http://server.com/package2/package2.tar Important questions: 1) Are the lifecycles the same? 2) Can one be built independently of the other? 3) Are the licenses the same? Is the IP owner the same? I am just wondering if these cannot be split into two packages, built one after the other. Maybe it is necessary to look into the specifics of the case, instead of trying to reason over a generic case. What are you trying to package exactly? Regards, Fernando Then I would, by hand, untar Source1 into Source0 directory. Before do the work I want to make sure I'm not breaking violating any package rules. I did look around and didn't see anything addressing this. If this is kosher, are there any examples of other packages doing this... tia, steved. ___ 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: Security updates and batched pushes
Kevin Fenzi wrote: > Well, if this firefox update was urgent, shouldn't it have been marked > urgent? Urgency is always in the eye of the beholder. I as a user consider all security updates "urgent", and in addition, I want ALL updates as soon as they passed testing no matter whether they actually are urgent. >> I really don't understand why we do this "batched" thing to begin with. > > To reduce the constant flow of updates that are very minor or affect > very few mixed in with the major updates that affect lots of people and > are urgent. But the users were already able to opt to update only weekly. So why force a fixed schedule on them? > To save users downloads of repodata. This does not work in practice because there is almost always at least one urgent update that requires downloading the whole repodata. (And also because maintainers are free to skip batched without giving a reason. I always do this because I consider batching a disservice to my users.) > rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch > appears on wed's pushes). > > There was some discussion about changing the gnome batching based on the > Fedora batching, but I don't know whats happened there. But what if this is a company that wants to do weekly updates on Monday morning in order to be free from disruptions for the working week? Then they will get the updates up to almost 2 weeks late rather than up to 1 week as both you and they intend. Batching really needs to be left to the client side! > I haven't seen a bunch of urgent updates get blocked by this process. > Do you have more data for updates that hit this? I have empirically seen security updates end up in the batches, but I have not checked each of them to see whether it actually went through "batched" or just happened to go out on that day. But again, I think it is essential for users to be able to opt to getting updates without arbitrary delays. >> If people insist on that "batched" misfeature, can we please at least get >> a fast track repository that contains all the batched updates (but no >> updates that are still in testing and have not been batched yet!)? > > I would be very much against additional repos like this. Why? It would allow you to keep the server-side batching while still allowing those users like me to opt out of it. And the repodata download size for fast track would be minimal if updates that went out to stable get removed from fast track. Even RHEL has a fast track repository. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On 8 January 2018 at 13:03, Jonathan Dieter wrote: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >> On 8 January 2018 at 12:28, Matthew Miller >> wrote: >> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> > > A significant miss here is 'testing'. Making an arch primary >> > > means we >> > > need to ensure we have the necessary resources to run all the >> > > relevant >> > > validation testing. >> > >> > Are there hardware needs here? (Like, not in the server room but in >> > QA >> > team member's hands?) >> > >> >> I would say in both. We would need to make sure we have enough >> systems >> which openqa can reliably run on and we need to have some sort of >> system that testers can get a hand on. That would require a bit of a >> 'we expect this hardware to work and this is how you buy/get it' from >> the aarch64 team.. otherwise most everyone is going to come and ask >> why the raspberry pi 3 isn't supported (just like they did with the >> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >> more that is what most testers can get their hands on easily.. and it >> is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? > Well I am off by a year or more on supported hardware and was passing along DUD (Dodgy Unusable Data). That said it would be good to know what hardware that they want testing on.. in case there is something about XYZ hardware which makes it bootable/runnable but more out of luck than anything people want to put effort to fix on. > Jonathan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
El lun, 08-01-2018 a las 09:16 -0800, Adam Williamson escribió: > On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote: > > > > == Scope == > > * Proposal owners: > > The general AArch64 support is already in place and is widely and > > actively supported by the Fedora ARM SIG and numerous ARM vendors > > and > > third parties in Fedora. There will be further and wider support, > > hardware enablement, polish and general improvements. > > > > * Other developers: > > N/A: There's no work required for other developers, the aarch64 > > architecture is already widely supported as an Alternate > > Architecture. > > > > * Release engineering: > > Needs approval from release engineering as a primary architecture > > as > > well as pungi configuration changes to output artifacts to new > > location on the primary mirror. > > rel-eng ticket #7243: https://pagure.io/releng/issue/7243 > > > > * Policies and guidelines: > > Updates to the primary architectures and release blocking details > > will > > need to be updated to reflect that the AArch64 Server/Cloud/Docker > > components are now considered primary. > > > > * Trademark approval: > > N/A (not needed for this Change) > > A significant miss here is 'testing'. Making an arch primary means we > need to ensure we have the necessary resources to run all the > relevant > validation testing. > > I note pwhalen is a co-owner of the proposal so he's likely signed up > to ensure testing gets done, but still, it should be properly covered > in the Change document itself. > > As a further note, almost all the Server validation for x86_64 is > done > by openQA; doing it manually can be a considerable pain, as you have > to > set up a mini FreeIPA deployment. It would probably be best if we add > aarch64 workers to the Fedora openQA deployment to run these tests on > aarch64; we've already extended openQA (staging) to ppc64, so all the > bits should be in place for us to add another arch, pretty much. I'm > going to follow up on this with pwhalen. > > Another consideration would be whether we ought to also have aarch64 > support in Taskotron, if it's going to become a primary arch. I'm not > actually sure if Taskotron currently covers 32-bit ARM, though, even. currently taskotron is x86 only. I am not sure what it would take to extend it beyond x86, it would be a worthwhile investigation. It would be useful to have all arches in openQA regardless of primary or secondary status. I would like to see openQA working for aarch64 in Fedora's instance a hard requirement of this change. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
Hi, It can be done but it's a PITA to maintain and it's a very bad idea to do if the two packages are actually two different projects with different lifecycle expectations, legalities, etc See the convolutions of the %setup macro Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
On Mon, Jan 8, 2018 at 1:19 PM, Nico Kadel-Garcia wrote: > On Mon, Jan 8, 2018 at 12:59 PM, Martin Langhoff > wrote: >> I have two VMs, or OS states I can `rpm -qa` on. Is there a script to >> diff the output of the two listings, and then query the package >> changelogs to generate an overall OS-wide changelog? > > This is so sensitive to individual environment requirements it has > never been standardized well that I've seen. It *always* gets done by > the local admin, to fit their requirments. I fully agree wrt configuration changes. I am scoping my interest exclusively to rpms. A bit like saying "I run yum/dnf update on an OS, what bugfixes are landing/have landed?" cheers, m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
On Mon, Jan 8, 2018 at 12:59 PM, Martin Langhoff wrote: > I have two VMs, or OS states I can `rpm -qa` on. Is there a script to > diff the output of the two listings, and then query the package > changelogs to generate an overall OS-wide changelog? This is so sensitive to individual environment requirements it has never been standardized well that I've seen. It *always* gets done by the local admin, to fit their requirments. If you really want to store system configs to be able to do diffs, I personally pull backups to a secured central server with tools like "rsnapshot" to get daily backups of all of "/etc/" and "/root/" and a few critical logs It's very stable, very robust, and very flexible. > Use case: I generated an F26 OVA image using imagefactory 30 days ago, > then I generated a new F26 image today. I'd export rpm -qa listings > from both, and then get a changelog showing all the package updates, > expecting to see the kernel package with the recent CVEs fixed. > > Does such a tool exist? > > > > > m > -- > martin.langh...@gmail.com > - ask interesting questions ~ http://linkedin.com/in/martinlanghoff > - don't be distracted~ http://github.com/martin-langhoff >by shiny stuff > ___ > 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: F28 System Wide Change: AArch64 Server Promotion
On 01/08/2018 01:06 PM, Andreas Tunek wrote: That link does not work for me and I get some strange redirect to the Fedora download page. There was something odd in the link---this works for me: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
Ben Rosser wrote: > On Mon, Jan 8, 2018 at 12:58 PM, Rob Crittenden wrote: >> Florian Weimer wrote: >>> On 01/08/2018 06:21 PM, Steve Dickson wrote: Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0:http://server.com/package1/package1.tar Source1:http://server.com/package2/package2.tar Then I would, by hand, untar Source1 into Source0 directory. >>> >>> That's fairly common. I don't particularly like it, but if it's the way >>> upstream ships things, there isn't much choice. >> >> wine is an example of this. wine-staging is provided as a separate >> tarball of patches that are applied before build. > > This is also the recommended way to handle git submodules, according > to the packaging guidelines. > > https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Submodules It isn't a sub-module. It is a quasi-related project AIUI. rob ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Disable a package for Fedora 26
On 01/08/2018 06:20 AM, Jonny Heggheim wrote: > Hi! > > We just pused a urgent security update for Electrum for Fedora 27 and > rawhide, Fedora 26 is still affected. > > All versions of Electrum is affected by this bug, Fedora 26 still runs > an older version because of big changes in Electrum 3.0 and an updated > version of a dependency. > > So I see 3 options: > > * Upgrade to latest version for Fedora 26. Will take time to update and > might brake something else. I think this might be the best option here. It would leave things close to upstream so you could upgrade from there or report bugs and get help. > > * Create a patch for the version running on Fedora 26. Will take time > to make the patch and test on Fedora 26. This seems less good because you are diverging from upstream and will have to maintain the backport yourself. > * Make an update that disables Electrum, include only a README or > someting like that. Will make users confused. This is not a good option, IMHO. > Any better options? > > See https://bodhi.fedoraproject.org/updates/FEDORA-2018-4978426286 for > details I'd advise the first path... 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: Package Question
On Mon, Jan 8, 2018 at 12:58 PM, Rob Crittenden wrote: > Florian Weimer wrote: >> On 01/08/2018 06:21 PM, Steve Dickson wrote: >>> Is it a problem for a package to pull from two different >>> upstream tar balls? Basically have >>> >>> Source0:http://server.com/package1/package1.tar >>> Source1:http://server.com/package2/package2.tar >>> >>> Then I would, by hand, untar Source1 into Source0 directory. >> >> That's fairly common. I don't particularly like it, but if it's the way >> upstream ships things, there isn't much choice. > > wine is an example of this. wine-staging is provided as a separate > tarball of patches that are applied before build. This is also the recommended way to handle git submodules, according to the packaging guidelines. https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Submodules Ben ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
2018-01-08 19:03 GMT+01:00 Jonathan Dieter : > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >> On 8 January 2018 at 12:28, Matthew Miller >> wrote: >> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> > > A significant miss here is 'testing'. Making an arch primary >> > > means we >> > > need to ensure we have the necessary resources to run all the >> > > relevant >> > > validation testing. >> > >> > Are there hardware needs here? (Like, not in the server room but in >> > QA >> > team member's hands?) >> > >> >> I would say in both. We would need to make sure we have enough >> systems >> which openqa can reliably run on and we need to have some sort of >> system that testers can get a hand on. That would require a bit of a >> 'we expect this hardware to work and this is how you buy/get it' from >> the aarch64 team.. otherwise most everyone is going to come and ask >> why the raspberry pi 3 isn't supported (just like they did with the >> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >> more that is what most testers can get their hands on easily.. and it >> is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? > That link does not work for me and I get some strange redirect to the Fedora download page. /Andreas Tunek > Jonathan > ___ > 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: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: > On 8 January 2018 at 12:28, Matthew Miller > wrote: > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > > A significant miss here is 'testing'. Making an arch primary > > > means we > > > need to ensure we have the necessary resources to run all the > > > relevant > > > validation testing. > > > > Are there hardware needs here? (Like, not in the server room but in > > QA > > team member's hands?) > > > > I would say in both. We would need to make sure we have enough > systems > which openqa can reliably run on and we need to have some sort of > system that testers can get a hand on. That would require a bit of a > 'we expect this hardware to work and this is how you buy/get it' from > the aarch64 team.. otherwise most everyone is going to come and ask > why the raspberry pi 3 isn't supported (just like they did with the > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. > more that is what most testers can get their hands on easily.. and it > is not a aarch64 platform we support). I may be going off in the weeds here, but is https://fedoraproject.org/ wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not accurate when it says it *is* supported? Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Changelog between OS states (ie: VMs)
I have two VMs, or OS states I can `rpm -qa` on. Is there a script to diff the output of the two listings, and then query the package changelogs to generate an overall OS-wide changelog? Use case: I generated an F26 OVA image using imagefactory 30 days ago, then I generated a new F26 image today. I'd export rpm -qa listings from both, and then get a changelog showing all the package updates, expecting to see the kernel package with the recent CVEs fixed. Does such a tool exist? m -- martin.langh...@gmail.com - ask interesting questions ~ http://linkedin.com/in/martinlanghoff - don't be distracted~ http://github.com/martin-langhoff by shiny stuff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
Florian Weimer wrote: > On 01/08/2018 06:21 PM, Steve Dickson wrote: >> Is it a problem for a package to pull from two different >> upstream tar balls? Basically have >> >> Source0:http://server.com/package1/package1.tar >> Source1:http://server.com/package2/package2.tar >> >> Then I would, by hand, untar Source1 into Source0 directory. > > That's fairly common. I don't particularly like it, but if it's the way > upstream ships things, there isn't much choice. wine is an example of this. wine-staging is provided as a separate tarball of patches that are applied before build. rob > >> If this is kosher, are there any examples of other >> packages doing this... > > glibc did that until Fedora 20. We eventually split out the files in > the tarball into individual source files, which was easy enough in our > case (and the files were Fedora-specific anyway). > > Thanks, > Florian > ___ > 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: F28 System Wide Change: AArch64 Server Promotion
On 8 January 2018 at 12:28, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> A significant miss here is 'testing'. Making an arch primary means we >> need to ensure we have the necessary resources to run all the relevant >> validation testing. > > Are there hardware needs here? (Like, not in the server room but in QA > team member's hands?) > I would say in both. We would need to make sure we have enough systems which openqa can reliably run on and we need to have some sort of system that testers can get a hand on. That would require a bit of a 'we expect this hardware to work and this is how you buy/get it' from the aarch64 team.. otherwise most everyone is going to come and ask why the raspberry pi 3 isn't supported (just like they did with the raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. more that is what most testers can get their hands on easily.. and it is not a aarch64 platform we support). > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package Question
On 01/08/2018 06:21 PM, Steve Dickson wrote: Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0:http://server.com/package1/package1.tar Source1:http://server.com/package2/package2.tar Then I would, by hand, untar Source1 into Source0 directory. That's fairly common. I don't particularly like it, but if it's the way upstream ships things, there isn't much choice. If this is kosher, are there any examples of other packages doing this... glibc did that until Fedora 20. We eventually split out the files in the tarball into individual source files, which was easy enough in our case (and the files were Fedora-specific anyway). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Security updates and batched pushes
On 01/07/2018 08:01 PM, Kevin Kofler wrote: > Kevin Fenzi wrote: >> The critera for bypassing batched is if the update is marked "urgent". > > The problem is, this appears to be insufficient. Well, if this firefox update was urgent, shouldn't it have been marked urgent? > I really don't understand why we do this "batched" thing to begin with. To reduce the constant flow of updates that are very minor or affect very few mixed in with the major updates that affect lots of people and are urgent. To save users downloads of repodata. > Users who want to batch updates have always been able to do it, GNOME > Software will even do it for theNow, those users who want to batch their > updates are forced to follow Fedora rel-eng's schedule for the batches > rather than being able to pick their own weekday, so how does the server- > side batching help them? And those users (like me) who want to get their > updates, including security fixes (!) as we see here, as soon as they passed > testing are now screwed. rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch appears on wed's pushes). There was some discussion about changing the gnome batching based on the Fedora batching, but I don't know whats happened there. I haven't seen a bunch of urgent updates get blocked by this process. Do you have more data for updates that hit this? > If people insist on that "batched" misfeature, can we please at least get a > fast track repository that contains all the batched updates (but no updates > that are still in testing and have not been batched yet!)? I would be very much against additional repos like this. 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: Package Question
2018-01-08 11:21 GMT-06:00 Steve Dickson : > Hello, > > Is it a problem for a package to pull from two different > upstream tar balls? Basically have > > Source0: http://server.com/package1/package1.tar > Source1: http://server.com/package2/package2.tar > > Then I would, by hand, untar Source1 into Source0 directory. > > Before do the work I want to make sure I'm not > breaking violating any package rules. I did look > around and didn't see anything addressing this. > > > Patch the content of the package2 inside the package1 do not work the same? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > A significant miss here is 'testing'. Making an arch primary means we > need to ensure we have the necessary resources to run all the relevant > validation testing. Are there hardware needs here? (Like, not in the server room but in QA team member's hands?) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Package Question
Hello, Is it a problem for a package to pull from two different upstream tar balls? Basically have Source0: http://server.com/package1/package1.tar Source1: http://server.com/package2/package2.tar Then I would, by hand, untar Source1 into Source0 directory. Before do the work I want to make sure I'm not breaking violating any package rules. I did look around and didn't see anything addressing this. If this is kosher, are there any examples of other packages doing this... tia, steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote: > > == Scope == > * Proposal owners: > The general AArch64 support is already in place and is widely and > actively supported by the Fedora ARM SIG and numerous ARM vendors and > third parties in Fedora. There will be further and wider support, > hardware enablement, polish and general improvements. > > * Other developers: > N/A: There's no work required for other developers, the aarch64 > architecture is already widely supported as an Alternate Architecture. > > * Release engineering: > Needs approval from release engineering as a primary architecture as > well as pungi configuration changes to output artifacts to new > location on the primary mirror. > rel-eng ticket #7243: https://pagure.io/releng/issue/7243 > > * Policies and guidelines: > Updates to the primary architectures and release blocking details will > need to be updated to reflect that the AArch64 Server/Cloud/Docker > components are now considered primary. > > * Trademark approval: > N/A (not needed for this Change) A significant miss here is 'testing'. Making an arch primary means we need to ensure we have the necessary resources to run all the relevant validation testing. I note pwhalen is a co-owner of the proposal so he's likely signed up to ensure testing gets done, but still, it should be properly covered in the Change document itself. As a further note, almost all the Server validation for x86_64 is done by openQA; doing it manually can be a considerable pain, as you have to set up a mini FreeIPA deployment. It would probably be best if we add aarch64 workers to the Fedora openQA deployment to run these tests on aarch64; we've already extended openQA (staging) to ppc64, so all the bits should be in place for us to add another arch, pretty much. I'm going to follow up on this with pwhalen. Another consideration would be whether we ought to also have aarch64 support in Taskotron, if it's going to become a primary arch. I'm not actually sure if Taskotron currently covers 32-bit ARM, though, even. -- 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
nfs-utils: does not compile in rawhide
Just an FYI... nfs-utils currently does not compile in rawhide do to this change: https://bugzilla.redhat.com/show_bug.cgi?id=1531540 We know about and should be resolved by the EOD... Personally I think this is step in the right direction but apologize for the inconvenience steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Ruby 2.5 - Mass rebuild
Dne 8.1.2018 v 16:10 Pavel Valena napsal(a): > - Original Message - >> From: "Vít Ondruch" >> To: ruby-...@lists.fedoraproject.org, "Development discussions related to >> Fedora" >> Sent: Monday, January 8, 2018 3:19:11 PM >> Subject: Re: Ruby 2.5 - Mass rebuild >> >> Hi everybody, >> >> The sidetag with Ruby 2.5 and all the rebuilt packages were merged into >> F25 [1]. Since the update of Ruby involved soname > You probable meant F28, right? (ruby-2.5.0-86.fc28) Right. 5 is dangerously close to 8 on my numerical keyboard. Sorry for the confusion. V. > >> bump, we managed to rebuild most of the depending packages. But there >> are still some packages which are broken for various reasons (you can >> see the analysis of them here [2]. But luckily, some of the issues from >> the list were already resolved). We will try to fix them, but of course, >> any help is welcome. >> >> Also, please check your pure Ruby packages for compatibility with Ruby >> 2.5 (Koschei will help you to catch those issues), but there were no >> major issues during rebuild, so I am quite positive there wont be many. >> >> Let us know if you need some help ... >> >> And special thanks goes to Mamoru, who handled the major part of the >> rebuild. > Good job, both of you! > > Pavel > >> Regards, >> >> >> Vít >> >> >> [1] https://pagure.io/releng/issue/7228 >> [2] >> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/XGQNGECLGHMCCA2CLEYWLGRJFR2AR3VV/ >> >> ___ >> 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: Ruby 2.5 - Mass rebuild
- Original Message - > From: "Vít Ondruch" > To: ruby-...@lists.fedoraproject.org, "Development discussions related to > Fedora" > Sent: Monday, January 8, 2018 3:19:11 PM > Subject: Re: Ruby 2.5 - Mass rebuild > > Hi everybody, > > The sidetag with Ruby 2.5 and all the rebuilt packages were merged into > F25 [1]. Since the update of Ruby involved soname You probable meant F28, right? (ruby-2.5.0-86.fc28) > bump, we managed to rebuild most of the depending packages. But there > are still some packages which are broken for various reasons (you can > see the analysis of them here [2]. But luckily, some of the issues from > the list were already resolved). We will try to fix them, but of course, > any help is welcome. > > Also, please check your pure Ruby packages for compatibility with Ruby > 2.5 (Koschei will help you to catch those issues), but there were no > major issues during rebuild, so I am quite positive there wont be many. > > Let us know if you need some help ... > > And special thanks goes to Mamoru, who handled the major part of the > rebuild. Good job, both of you! Pavel > > Regards, > > > Vít > > > [1] https://pagure.io/releng/issue/7228 > [2] > https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/XGQNGECLGHMCCA2CLEYWLGRJFR2AR3VV/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Pavel Valena Software Engineer, Red Hat Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: mpfr-4.0.0
= System Wide Change: mpfr-4.0.0 = https://fedoraproject.org/wiki/Changes/mpfr-4.0.0 Change owner(s): * James Paul Turner Update the MPFR package to version 4.0.0. == Detailed Description == The purpose of this change is to update the Fedora MPFR package to the latest version (4.0.0), released on the 25th December 2017. Due to a soname bump, this change will rebuild all packages that depend on MPFR. == Scope == * Proposal owners: - Rebuild of packages that depend on MPFR - Minor specfile corrections and testing * Other developers: Testing and/or minor fixes of dependant packages * Release engineering: Separate Koji tag for package rebuild will be needed. #7247: https://pagure.io/releng/issue/7247 * List of deliverables: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) -- 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
Flexible Metadata Format
Hi! In order to keep test execution efficient when number of test cases grows, it is crucial to maintain corresponding metadata, which define some aspects of how the test coverage is executed. For example limiting environment combinations where the test is relevant or selecting a subset of important test cases for quick verification of essential features when testing a security update. Within the BaseOS QE team we were thinking (for a long time) about an efficient metadata solution which would cover our use cases and would be open source. Recently we've been involved in the Upstream First initiative which increased the need for an open metadata solution which would enable us to more easily share test code between Red Hat Enterprise Linux and Fedora. We've put together a draft solution which covers some of the most important stories we've gathered so far. It does not cover all use cases and it is not complete. In this early stage we would like to invite others who might have similar use cases to gather your feedback, share your experience or even join the project: https://fedoraproject.org/wiki/Flexible_Metadata_Format The page lists some of our core user stories as well as a couple of real-life examples to demonstrate proposed features of the format. Can you see similar user stories in your team? Is this something that could be useful for you as well? Do you know of a different solution for these use cases? Any other relevant ideas? To illustrate where we could be heading: In the ideal future there could be just a single test case for a particular feature stored in public with a single set of metadata attached close to the test code and together used for testing in both upstream and downstream without need to duplicate the test code (maintain both copies). This proposal does not suggest in any way to replace tests.yml [1] files defined by the Standard Test Interface. The new format could serve as an extension for selecting the right tests to be executed (e.g. filtering tests by tag instead of listing them manually). Looking forward to your feedback! psss... [1] https://fedoraproject.org/wiki/CI/Tests ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Disable a package for Fedora 26
Hi! We just pused a urgent security update for Electrum for Fedora 27 and rawhide, Fedora 26 is still affected. All versions of Electrum is affected by this bug, Fedora 26 still runs an older version because of big changes in Electrum 3.0 and an updated version of a dependency. So I see 3 options: * Upgrade to latest version for Fedora 26. Will take time to update and might brake something else. * Create a patch for the version running on Fedora 26. Will take time to make the patch and test on Fedora 26. * Make an update that disables Electrum, include only a README or someting like that. Will make users confused. Any better options? See https://bodhi.fedoraproject.org/updates/FEDORA-2018-4978426286 for details Sincerely Jonny Heggheim 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: Ruby 2.5 - Mass rebuild
Hi everybody, The sidetag with Ruby 2.5 and all the rebuilt packages were merged into F25 [1]. Since the update of Ruby involved soname bump, we managed to rebuild most of the depending packages. But there are still some packages which are broken for various reasons (you can see the analysis of them here [2]. But luckily, some of the issues from the list were already resolved). We will try to fix them, but of course, any help is welcome. Also, please check your pure Ruby packages for compatibility with Ruby 2.5 (Koschei will help you to catch those issues), but there were no major issues during rebuild, so I am quite positive there wont be many. Let us know if you need some help ... And special thanks goes to Mamoru, who handled the major part of the rebuild. Regards, Vít [1] https://pagure.io/releng/issue/7228 [2] https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/XGQNGECLGHMCCA2CLEYWLGRJFR2AR3VV/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Anaconda modularization
On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote: > Yep - basically, there will be no "old" and "new, DBUS/modular" > Anaconda, the plan is to turn the current Anaconda to the new one one > step at a time. > > This should allow us to fix bugs as usual and handle any unforeseen > modularization issues early on one-by-one as they show up. It sounds like there actually isn't a contingency plan as such. Do you think that this could all be reverted on Final Freeze day if we would decide it's not working out? If not, let's not call that a contingency. I'm not saying we shouldn't do this, but let's be honest with ourselves. If the contingency plan is "None: we'll have to hold up the release for fixes if it's not ready", the Change plan should say that. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: AArch64 Server Promotion
= System Wide Change: AArch64 Server Promotion = https://fedoraproject.org/wiki/Changes/AArch64_Server_Promotion Change owner(s): * Peter Robinson * Paul Whalen Promote Aarch64 server technologies to Primary Architecture status. This would include the Server installer, the DVD installer ISOs, the Cloud (qcow2 images) and Docker base images to the same status as other primary Server architectures. This would NOT currently include other components such as Workstation images/installs, any of the various spins, or Fedora Atomic components. == Detailed Description == The AArch64 Architecture in the server space is a mature product with numerous platforms widely available for testing. We support both SBSA Enterprise Haware as well as a number of Single Board Computers, initially officially supported in Fedora 27 with the aarch64 SBC Feature, with new device support being added all the time and more widely available and affordable hardware. The changes is actually a minor one as we already produce all the deliverables as an Alternate Architecture, this primarily be a change of where the output of the artifacts are delivered on the mirrors and making the architecture a release blocking architecture. This would NOT currently include other components such as Workstation images/installs, any of the various spins, or Fedora Atomic components. == Scope == * Proposal owners: The general AArch64 support is already in place and is widely and actively supported by the Fedora ARM SIG and numerous ARM vendors and third parties in Fedora. There will be further and wider support, hardware enablement, polish and general improvements. * Other developers: N/A: There's no work required for other developers, the aarch64 architecture is already widely supported as an Alternate Architecture. * Release engineering: Needs approval from release engineering as a primary architecture as well as pungi configuration changes to output artifacts to new location on the primary mirror. rel-eng ticket #7243: https://pagure.io/releng/issue/7243 * Policies and guidelines: Updates to the primary architectures and release blocking details will need to be updated to reflect that the AArch64 Server/Cloud/Docker components are now considered primary. * Trademark approval: N/A (not needed for this Change) -- 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: F28 Self Contained Change: Anaconda modularization
- Original Message - > From: "Colin Walters" > To: "development discussions related to Fedora" > > Sent: Saturday, January 6, 2018 5:29:28 PM > Subject: Re: F28 Self Contained Change: Anaconda modularization > > > > On Fri, Jan 5, 2018, at 7:28 AM, Jan Kurik wrote: > > > Anaconda installer will be split into several modules that will > > communicate over DBus using stable API. > > For the curious this blog entry is useful: > http://blog-jkonecny.rhcloud.com/2017/06/16/shining-new-anaconda-modularisation/ > > I also would still like > http://blog-jkonecny.rhcloud.com/2017/06/16/shining-new-anaconda-modularisation/#comment-3366641149 > > However my main concern here is: Anaconda is a baseline requirement > for really doing much at all in releasing anything "Fedora" - for example > we use Anaconda to generate both cloud images and the base container images. > And obviously it's required to do bare metal installs. > > There are a few ways I could imagine doing this; ideally Fedora releng > would have a real branching concept. I think it can sort of be set up > manually. > Do you have any plans to request that? > > At least let's be ready with a fallback plan of using the existing codebase? > Are there going to be git branches upstream so fixes can still land > in the current installer? As the changes will be done incrementally, we don't plan to use any special branches and all usual bug fixes, feature development and modularization work will happen on the master branch. > > For example I had plans to work on > https://github.com/rhinstaller/anaconda/issues/1259 > sometime soon, and *hopefully* it shouldn't conflict with modularization > but it seems likely the change would need to go in both branches or so? As mentioned above, targeting the master branch should be fine. > ___ > 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: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement
On Mon, 8 Jan, 2018 at 11:44 AM, Tom Hughes wrote: The only real concern then is that the implicit permanent authorisation of the device - that if you can once get an administrator to plug it in you can in future do so when they aren't present. So if I am J Evil Hacker and I can get you to connect to my projector at a conference then I can in future plug my Evil Memory Stealer device in that presents the same ID and hence gets accepted. Yep, that is indeed tricky. The problem is, that J Evil Hacker build the Evil Memory Stealer in such a way that you have to authorize it to get a picture at all and the already super nervous Speaker (who was already a bit late and his talk is of course too long) just wants to get that ** projector working NOW and so clicks YES YES YES on any dialog warning him. But you are of course right that this problem. For people who really care, the solution is to put the daemon in paranoid mode before going to untrusted environments. A better solution would be if we had a global status somewhere if we are in a safe or unsafe environment and honour that for thunderbolt and also usb etc. pp. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Anaconda modularization
- Original Message - > From: jkone...@redhat.com > To: "Development discussions related to Fedora" > > Sent: Monday, January 8, 2018 12:56:17 PM > Subject: Re: F28 Self Contained Change: Anaconda modularization > > On Sat, 2018-01-06 at 09:09 +, Zbigniew Jędrzejewski-Szmek wrote: > > Wow, that sounds like a hefty change. Has the work already begun? > > Is there a repo/branch where one can look at the WIP, test stuff, > > etc? > > > > We are already working on that and everything goes directly to master - > "Rawhide" branch. The code is just not enabled right now on Rawhide but > will be soon. > > Our plan is to move incrementally on Rawhide - migrate one thing after > another without changing functionality and without user noticeable impact. > So everything should be incrementally tested on Rawhide, no big potentially > disruptive flag days. Yep - basically, there will be no "old" and "new, DBUS/modular" Anaconda, the plan is to turn the current Anaconda to the new one one step at a time. This should allow us to fix bugs as usual and handle any unforeseen modularization issues early on one-by-one as they show up. > > Jirka > ___ > 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: F28 Self Contained Change: Anaconda modularization
On Sat, 2018-01-06 at 09:09 +, Zbigniew Jędrzejewski-Szmek wrote: > Wow, that sounds like a hefty change. Has the work already begun? > Is there a repo/branch where one can look at the WIP, test stuff, > etc? > We are already working on that and everything goes directly to master - "Rawhide" branch. The code is just not enabled right now on Rawhide but will be soon. Our plan is to move incrementally on Rawhide - migrate one thing after another without changing functionality and without user noticeable impact. So everything should be incrementally tested on Rawhide, no big potentially disruptive flag days. Jirka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
- Mail original - De: "Tom Hughes" >> Well /usr/share/authselect/custom is not really the correct location >> for local administrator configuration... > > What location do you suggest? > Well somewhere in /etc in short. Like other such packages it needs a hierarchy with default templates in /usr/share and local updates in /etc Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement
On 08/01/18 10:23, Christian Kellner wrote: Hi Tom, On Mon, 8 Jan, 2018 at 11:07 AM, Tom Hughes wrote: On 08/01/18 09:59, Christian Kellner wrote: The current design how gnome-shell and boltd work together will avoid showing any prompts at all as long as a) the current user is an admin, b) she is logged in and c) the session is unlocked. We hope that this will take care of most situations where people plug in thunderbolt devices. I obviously misunderstood... I thought the whole point of the desktop bit was so it could prompt you when it saw a new device? Ideally I would have though with the option to allow it once or permanently. If this is so potentially dangerous what's the logic behind going to all this trouble and then not actually asking the user? Can I point you to the design document for answers to that question: https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess Although I did not come up with the design myself, I do indeed agree that for most people "do you want to allow XXX to work" is not a meaningful question and the most likely thing happening is that people click yes not matter what. The main attack vector that is prevented but "all this trouble" is that someone plugs in a malicious tb3 device into your computer to read all your main memory while you are away from the computer. I guess that does make reasonable sense if the model is that for an unlocked machine with an administrator logged in that user is physically present to observe anything being plugged in. The only real concern then is that the implicit permanent authorisation of the device - that if you can once get an administrator to plug it in you can in future do so when they aren't present. So if I am J Evil Hacker and I can get you to connect to my projector at a conference then I can in future plug my Evil Memory Stealer device in that presents the same ID and hence gets accepted. 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
Re: F28 Self Contained Change: VirtualBox Guest Integration
Hi, On 05-01-18 15:03, Sérgio Basto wrote: Hi, On Thu, 2018-01-04 at 14:16 +0100, Jan Kurik wrote: - Add VirtualBox Guest Additions package to the default package list for the Workstation product I don't understand this one, VirtualBox Guest should *only* be installed in an virtual machine . But it is impossible to determine ahead of time if e.g. a Fedora Workstation Live image is going to get booted as a VirtualBox guest or in some other way. As others have reported, we do the same thing for the guest tools for all other hypervisors. Today VirtualBox-server conflicts with VirtualBox-guest-additions and vice versa . I don't know why this used to be done, but this simply will no longer be necessary going forward. There are going to be 2 kernel modules named vboxguest.ko and vboxsf.ko as part of the main kernel-modules package, which will have no symbols which in any way will conflict with the out of tree vbox host kernel modules and the VirtualBox-guest-additions package itself (which will not contain any kernel modules) will contain this: [hans@shalem master]$ rpm -qlp x86_64/VirtualBox-guest-additions-5.2.2-1.fc27.x86_64.rpm VirtualBox-guest-additions-5.2.2-1.fc27.x86_64 /etc/X11/xinit/xinitrc.d/98vboxadd-xclient.sh /etc/xdg/autostart/vboxclient.desktop /usr/bin/VBoxClient /usr/bin/VBoxClient-all /usr/bin/VBoxControl /usr/lib/systemd/system/vboxservice.service /usr/lib/udev/rules.d/60-vboxguest.rules /usr/lib64/security/pam_vbox.so /usr/sbin/VBoxService /usr/sbin/mount.vboxsf /usr/share/licenses/VirtualBox-guest-additions /usr/share/licenses/VirtualBox-guest-additions/COPYING /usr/share/licenses/VirtualBox-guest-additions/COPYING.CDDL ConditionVirtualization=|oracle So the service will only run under vbox. As for the file size, the installed size is all of 3308559 bytes. I also propose the patch attach, to don't let install VirtualBox-guest- additions in host systems, at the time could break the Xorg graphics and all windows managers . Furthermore at least is just a waste of disk space, for non virtual machines and for who don't use VirtualBox. As others have already explained this is a bad idea. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Abhiram Kuchibhotla
Hello and welcome! - Original Message - > From: "Abhiram Kuchibhotla" > To: devel@lists.fedoraproject.org > Sent: Sunday, January 7, 2018 10:28:57 PM > Subject: Self Introduction: Abhiram Kuchibhotla > > Good day, everyone! > > My name is Abhiram, and I go by "Axel" online. > I recently graduated college with a bachelor's degree in technology with a > focus on software engineering and IT. > > I've been a full time Linux user for about 11-ish years having started my > journey on good ol' Fedora core 9. > > Recently, I've started to teach myself how to package applications for Fedora > and I submitted my first package review request earlier > today(https://bugzilla.redhat.com/show_bug.cgi?id=1532042) for Compton which > is a compositor for X11 that I use regularly. > > Besides that, I've also made a copr repository for a small program called > nvidia-xrun which allows people with Nvidia Optimus devices to launch > separate Xsessions using their nvidia cards. > > I have a few more packages that I'm making, and I'm looking for a sponsorship > into the packager group so that I can contribute further. > > I really look forward to working with all of you! > > Best Regard, > Abhiram K. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement
Hi Tom, On Mon, 8 Jan, 2018 at 11:07 AM, Tom Hughes wrote: On 08/01/18 09:59, Christian Kellner wrote: The current design how gnome-shell and boltd work together will avoid showing any prompts at all as long as a) the current user is an admin, b) she is logged in and c) the session is unlocked. We hope that this will take care of most situations where people plug in thunderbolt devices. I obviously misunderstood... I thought the whole point of the desktop bit was so it could prompt you when it saw a new device? Ideally I would have though with the option to allow it once or permanently. If this is so potentially dangerous what's the logic behind going to all this trouble and then not actually asking the user? Can I point you to the design document for answers to that question: https://wiki.gnome.org/Design/Whiteboards/ThunderboltAccess Although I did not come up with the design myself, I do indeed agree that for most people "do you want to allow XXX to work" is not a meaningful question and the most likely thing happening is that people click yes not matter what. The main attack vector that is prevented but "all this trouble" is that someone plugs in a malicious tb3 device into your computer to read all your main memory while you are away from the computer. FWIW: I do intend to add a "paranoid" mode for people that know what they are doing and are maybe exposed to more security relevant contexts; in such a mode we would indeed show a polkit-dialog for all devices (https://github.com/gicmo/bolt/issues/14). But that will not be the default. Cheers, CK ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
On 08/01/18 10:02, Pavel Březina wrote: On 01/05/2018 04:54 PM, Tom Hughes wrote: On 05/01/18 15:02, Pavel BÅ™ezina wrote: Yes, there is a data dir: /usr/share/authselect/ Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in Well /usr/share/authselect/custom is not really the correct location for local administrator configuration... What location do you suggest? Well somewhere in /etc in short. I mean /usr/share/authselect/custom is fine for local customisation via building your own rpms but not for on the fly changes. Really nobody should ever be changing anything in /usr (excluding /usr/local) except via package installation/update/removal. 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
Re: Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement
On 08/01/18 09:59, Christian Kellner wrote: The current design how gnome-shell and boltd work together will avoid showing any prompts at all as long as a) the current user is an admin, b) she is logged in and c) the session is unlocked. We hope that this will take care of most situations where people plug in thunderbolt devices. I obviously misunderstood... I thought the whole point of the desktop bit was so it could prompt you when it saw a new device? Ideally I would have though with the option to allow it once or permanently. If this is so potentially dangerous what's the logic behind going to all this trouble and then not actually asking the user? 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
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
On 01/05/2018 04:54 PM, Tom Hughes wrote: On 05/01/18 15:02, Pavel Březina wrote: Yes, there is a data dir: /usr/share/authselect/ Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in Well /usr/share/authselect/custom is not really the correct location for local administrator configuration... What location do you suggest? Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Make authselect default tool instead of authconfig
On 01/05/2018 04:43 PM, John Florian wrote: On Fri, 2018-01-05 at 16:02 +0100, Pavel Březina wrote: On 01/05/2018 03:14 PM, John Florian wrote: On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote: The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory. How? The authselect(8) man page tells me that `authselect show profile_id` will print info about the profile, but I see nothing of any detail. (Perhaps more could be gleaned with `--trace`, but without any apparent dry-run option I'd want a VM to experiment.) There is also authselect-profiles(5) that explains how profiles works. But it is not yet present in current Fedora packages. I will do new release on Monday. Ah, that explains a lot. I did fail to mention this was all from the perspective of a F27 system. Looking at the package contents doesn't help much either: $ rpm -ql authselect /usr/bin/authselect /usr/lib/.build-id /usr/lib/.build-id/b6 /usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e /usr/share/man/man8/authselect.8.gz So the built-in profiles are hard-coded into the binary? I might have expected a data dir providing these to serve as examples for making new ones. Yes, there is a data dir: /usr/share/authselect/ Doh! I see now that's part of authselect-libs, a package I failed to notice getting installed alongside of authselect itself. We have put the authselect functionality into a separate library so it is better usable by realmd (that can call it directly instead of executing cli) and other programs that may be interested. We also plan to provide ansible module and probably also python and maybe even dbus bindings. But this is out of scope of F28. Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect -profiles.5.txt.in.in Oh, very nice! I also didn't see (nor did I even try searching for) any mention of the upstream project. Otherwise, this is a very nice write up. I'm mostly curious as our setup uses an openldap directory server for identity and WinAD for authentication. realmd doesn't seem to cover (from a very cursory glance) that arrangement. So I have an eye out for how to best leverage these things, if at all. We had many discussions on this topic while designing and developing authselect. The resolution was to include only sssd and winbind profiles and avoid other use cases and avoid plain ldap and kerberos since they can be implemented with sssd. So the use case that you have mentioned above (different id and auth providers) can be achieved. That makes sense and seems like a wise choice. One last thought, how friendly is this going to be with tools like puppet and ansible? For example, would something like this be doable? It is idempotent so it can be used here as well. exec { 'authselect select sssd': unless => "authselect current | grep -q '^sssd$' && authselect check | grep -q unmodified" } The idea being to only run to make a change if needed to keep change reports tidy. I can't quite tell at this point because: $ sudo authselect current No existing configuration detected. In this sense, it would be helpful if authselect(8) had some details about exit codes. Also, the "check" command could be more explicit about what happens with exit codes/output messages when: * the config was created by authselect and remains unmodified * the config was created by authselect but has since been modified * the config hasn't apparently ever been touched by authselect Maybe another command like "test" command could be ideal for the job if it did much the same but gave diff output and suitable exit code indicating spot-on vs. needs-change. Thank you for your input, we will try to include it soon: https://github.com/pbrezina/authselect/issues/26 I ask because I'd far prefer to have a well maintained tool like authselect managing PAM versus self-hacked file replacements based on old configurations that once may have been correct(ish). PAM syntax is a wee bit too arcane and yet immensely critical to go mucking around haphazardly. Yes, this is exactly what we aim for. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fwd: Re: F28 Self Contained Change: Thunderbolt Enablement
Hi Florian, On Fri, 5 Jan, 2018 at 10:45 AM, Florian Weimer wrote: > Devices connected via Thunderbolt can be DMA masters and thus read system memory without interference of the operating system (or even the CPU). Version 3 of the interface provides 4 different security levels, in order to mitigate the aforementioned security risk that connected devices pose to the system. The security level is set by the system firmware. The four security levels are: * none: Security disabled, all devices will fully functional on connect. * dponly: Only pass the display-port stream through to the connected device. * user: Connected devices need to be manually authorized by the user. * secure: As 'user', but also challenge the device with a secret key to verify its identity. Can the IOMMU help here? If it can, would it make sense to disable all security prompts? In theory yes, in practice it is hard to make sure it is always properly set up (for all drivers in the mix). Also apparently "various [other] reasons" according to the Linux kernel documentation: "There are ways to prevent this by setting up an IOMMU but it is not always available for various reasons." The current design how gnome-shell and boltd work together will avoid showing any prompts at all as long as a) the current user is an admin, b) she is logged in and c) the session is unlocked. We hope that this will take care of most situations where people plug in thunderbolt devices. Are there plans to prevent enabling devices when the shield is active? (That's something we should do for most USB decices, too, FWIW.) I am not sure what you refer to with "shield" but if you mean the lock screen, then yes indeed we wont enable devices when the session is locked. Cheers, CK [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/admin-guide/thunderbolt.rst -- Dr. Christian J. Kellner Desktop Hardware Enablement Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org