Re: coreutils in Rawhide ~ behavior change to the -v option on cp?
On Mon, Apr 24, 2023 at 11:46:25AM +1000, Ian Laurie wrote: > It looks to me like there has been a recent change to the verbose reporting > option on the cp command. > > Previously (and still in Fedora 38) the -v option will report on files > actually copied, but ignores files not copied (for example when -v is used > with -u). > > However in Rawhide the -v option now reports on files skipped when used with > -u, which has made a big mess of many of my bash scripts. > > Anyone know if there is some trick to reverting traditional behavior? According to the NEWS file in coreutils-9.3, I see this: ** Changes in behavior 'cp -n' and 'mv -n' now issue an error diagnostic if skipping a file, to correspond with -n inducing a nonzero exit status as of coreutils 9.2. Similarly 'cp -v' and 'mv -v' will output a message for each file skipped due to -n, -i, or -u. So it looks like behavior has changed. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Request for Fedora QA team information
Hi, The Fedora Council is working to update the Team Directory in the council-docs project. Part of that is reviewing the teams we have documented and if the information is correct. The Fedora QA Team is currently listed here: https://docs.fedoraproject.org/en-US/engineering/ We are asking for teams to fill out this template so we can have a more consistent listing for team information: https://pagure.io/Fedora-Council/council-docs/blob/master/f/engineering/modules/ROOT/partials/TEMPLATE_team_info.adoc Can you complete this template and send it to me via email (I am trying to collect and update the engineering team entries)? If you no longer wish to have the team listed in the council-docs, that's fine too. Here is information about what we are trying to accomplish with the Fedora Team Directory: https://docs.fedoraproject.org/en-US/council/procedures/team_directory/ If you have any questions, let me know. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
rpminspect Copr repository moving
If you are using rpminspect and rpminspect-data-fedora from my Copr repository, please note that it is moving. The move is tied to my username change that happened internally at Red Hat and then I mirrored in Fedora. The short story is that I can now have "dcantrell" as my username and discontinue using "dcantrel". THE NEW COPR REPO: https://copr.fedorainfracloud.org/coprs/dcantrell/rpminspect The previous one will be removed next week. No new builds are happening in the old repo. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On 8/27/19 2:00 PM, Chris Murphy wrote: > On Tue, Aug 27, 2019 at 11:25 AM David Cantrell wrote: >> >> The installer team rejecting btrfs patches is going to be based on their >> resources to support the functionality. I would say "btrfs in Fedora" >> needs a FESCo decision to set expectations and policy for the project. >> Is it something that Fedora wants to offer and if so, what does that >> look like? > > FESCo already voted 8 years ago to make Btrfs the default file system, > and then allowed that to wither and become moot rather than revert the > decision. Then later when the editions were created, part of > Fedora.next, the decision of default file systems was handed to the > working groups to decide. And the Fedora kernel team has also said > this is a working group decision. > > The Fedora working group's technical specification states Btrfs is to > be the default. Yet the working group has said it's uncomfortable > taking action on this decision expressly because the Federal kernel > team's official recommendation is to not recommend Btrfs. And I agree. > I trust the Fedora kernel team as they've clearly stated limited > resources and interest in Btrfs, the expectations and parameters for > properly supporting Btrfs either as bug blocker worthy, and as a > default file system from a user advocacy point of view. OK, so 8 years has gone by and the landscape around btrfs looks different in Fedora. Given the kernel team's position, is it worth still having the FESCo decision and kernel team's recommendation at odds? >> If it's a best effort thing, then that makes it easier for >> projects and contributors. Going back to Adam's original list, I would >> suggest a FESCo decision like this should require explicit opt-in by the >> user to enable btrfs functionality in the application in question. For >> example, in the installer that could be enabled via a boot parameter (we >> did this initially when btrfs functionality was first enabled in anaconda). > > That can only be considered to be a remarkable regression, not just in > the context of Fedora, but in the context of the top 10 linux > distributions all of which have visible Btrfs support in their GUI > installers. Fedora's installer being the first to make Btrfs invisible > by default would be a remarkable first indeed. I'm merely offering an example scenario. This does illustrate a problem with expectations among users. It's visible now, but not a priority, which leads to frustration. >> I'm not advocating one way or another for btrfs. But it seems we as a >> project need a larger decision and policy around btrfs in general so we >> can set expectations for users and developers. > > That decision and policy has already been made. Do you want it reverted? I guess I meant to say "FESCo needs to revisit this decision for a potential change". Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On 8/27/19 12:07 PM, Adam Williamson wrote: > On Tue, 2019-08-27 at 08:57 -0400, Josh Boyer wrote: >> >>> There *was* a PR submitted. It was even a one-liner because the >>> contributor fixed the underlying problem elsewhere. It's been in limbo >>> for over a year: https://github.com/rhinstaller/anaconda/pull/1375 >>> >>> You seem to think that I'm just shouting without any effort to back it >>> up. There was originally four of us working on this two years ago. >>> It's dwindled over time as the roadblocks were thrown up time and time >>> again. >> >> No, I don't think that at all. I think you've taken that PR, which >> was rejected because the project doesn't want to do more btrfs >> enablement, and generalized it to "nobody can contribute to anaconda". >> That's my point. You're using hyperbole as an argument for something >> specific. >> >> If you have other PRs that were general bug fixes or unrelated to >> btrfs which were rejected, I think it would be refreshing for all >> involved to look at why again. That would indicate a contribution >> model problem to me. Not a single feature/PR the project doesn't want >> to include. > > Josh, to be fair, I can see Neal's point here. In a way you seem to be > kinda sending him in circles here: "anaconda team doesn't have the > time/resources to invest in btrfs development, but you can help by > sending them pull requests. Oh, you sent them a pull request and they > rejected it? Well, it's because they don't have time/resources for > btrfs development..." You're right that one rejected PR doesn't > necessarily indicate a contribution model problem, but putting the > wider issue aside, a very simple one-liner with a major impact on btrfs > functionality being rejected *does* seem to say a lot about the > prospects of any btrfs-related work being accepted. > > Putting myself in Neal's shoes, given my experience with that PR and > other attempts to help out with btrfs in anaconda, why would I invest > my time and effort to write another one when it seems extremely likely > it would be rejected? There's an assumption here that when someone is asked to send a PR, it will always be accepted. Enabling and/or fixing btrfs functionality in anaconda is not a zero cost. There's also the issue that anaconda has always aimed to not break systems. Does the project have the resources to guarantee that and fix problems that show up? What might appear at first as a "one line patch" comes with a lot of other assumptions and expectations from users. > I think we at least owe it to people to be clear about whether there is > any point in them investing time and effort *trying* to contribute to > btrfs support in anaconda, and if the answer is currently "no", whether > there would realistically be any prospect of there being any way to > change this. > > I also think there are other perspectives that might at least > potentially be useful here. Right now we've mainly heard from a couple > of community folks who are very passionate about btrfs, and Red Hat > folks from anaconda/kernel development and RHEL management who > essentially see it as a burden that is not aligned with their > priorities. Is that all the perspectives we have to make a decision > with? I think we should at least talk to the Facebook team that > apparently uses btrfs on Fedora extensively about whether they'd be sad > to see installer btrfs support die and, if so, whether they'd perhaps > be interested in helping support it. And more broadly, community folks > on all the lists this is going to: are there more people who actually > are interested in this functionality and would be sad to see it go? If > btrfs isn't a part of Red Hat's product roadmaps but is important to > lots of folks in the wider Fedora community, maybe that's another > indicator we can useor indeed, if it turns out not many folks > actually care. The installer team rejecting btrfs patches is going to be based on their resources to support the functionality. I would say "btrfs in Fedora" needs a FESCo decision to set expectations and policy for the project. Is it something that Fedora wants to offer and if so, what does that look like? If it's a best effort thing, then that makes it easier for projects and contributors. Going back to Adam's original list, I would suggest a FESCo decision like this should require explicit opt-in by the user to enable btrfs functionality in the application in question. For example, in the installer that could be enabled via a boot parameter (we did this initially when btrfs functionality was first enabled in anaconda). I'm not advocating one way or another for btrfs. But it
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote: On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote: On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote: On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote: I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour. Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible. This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle. If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer. You're assuming before asking. With the structure of the installer now, we can look at changes like taking the password aspect and making it product-specific controllable by a number of different methods. Our historic aim to end variant specifics in the installer was because the old code (and variants) lacked a way to assign owners to those product specifics, which meant that requests of the installer to be product specific meant we were asked to be the owners of those specifics. Let me ask now, then: can we make the change to reject 'weak' passwords specific to only those products that enable sshd by default, please ? [adding anaconda-devel-list to CC] From a technical standpoint, I see this being possible. Conditionalize it on sshd being enabled or not. That's not really variant-specific and just a system condition we could work around. I'm putting this on anaconda-devel-list for further discussion. bcl, others? What are your thoughts on this request? -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote: On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote: I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour. Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible. This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle. If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer. You're assuming before asking. With the structure of the installer now, we can look at changes like taking the password aspect and making it product-specific controllable by a number of different methods. Our historic aim to end variant specifics in the installer was because the old code (and variants) lacked a way to assign owners to those product specifics, which meant that requests of the installer to be product specific meant we were asked to be the owners of those specifics. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to calculate priority for missing tests or %check
On Fri, Feb 28, 2014 at 11:24:48AM -0800, Adam Williamson wrote: On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote: I'm not sure what purpose does the URL field serve nowadays but it looks like it can be removed from the spec file (and RPM for that matter)! No, please. It could be made *optional*. But there are certainly cases where the upstream is non-discoverable - the generic-release one is a fun one, for instance. There are cases where a project has forked, and Google does not make it particularly obvious which side of the fork is which. It's not a useless field. I'd vote for optional, but there are plenty of other useless fields in spec files. Group, for instance. Considering we don't even use those groupings. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda new UI testing: new snapshot available
On Wed, Jul 18, 2012 at 07:18:42AM -0400, Scott Robbins wrote: On Tue, Jul 17, 2012 at 09:20:01PM -0700, Adam Williamson wrote: On Tue, 2012-07-17 at 17:42 -0400, Scott Robbins wrote: So, now one has to use kickstart, which is not all that simple, and has to be set up somewhere, to put in some BASIC Unix function. All to support the inexperienced user who will probably be more inconvenienced than endangered by this anyway. It's just more work for the sysadmin. I'd rather expect any sysadmin worth their salt would be deploying via scripts, not interactively. Which is what kickstart is - it's just the way you do a scripted install. Not necessarily. There are all sorts of reasons one wouldn't, for example, small companies with widely varying needs in individual servers. Even still, I hope the small companies are able to reproduce their install should the system they are using fail. We write out /root/anaconda-ks.cfg for this purpose and with some modifications on the part of the admin, you can have a kickstart file that will reproduce the set up that probably took you days to arrive at. But that's just me. I do this for my systems for my own disaster recovery purposes. It's really pretty simple and not weird and scary complicated like people want to think it is. -- David Cantrell dcantr...@redhat.com Supervisor, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda is forcing GPT on non-EFI BIOS
On 08/02/2011 02:52 PM, Athmane Madjoudj wrote: On 08/02/2011 07:45 PM, Athmane Madjoudj wrote: On 08/02/2011 07:36 PM, Athmane Madjoudj wrote: Hello, I noticed when I tried to install F16 Alpha TC1 on a new guest ie: without any existing partition table that Anaconda is forcing GPT instead of msdos even on a classic BIOS (non EFI) Any idea why ? Maybe it's related to: http://fedoraproject.org/wiki/Features/GUID_Partition_Table I found some good info here: https://bugzilla.redhat.com/show_bug.cgi?id=694808 Correct. There's no forcing by us, your hardware forced us to use GPT because of the size of its disk. If you have a UEFI-capable system, I suggest using it in UEFI mode. -- David Cantrell dcantr...@redhat.com Supervisor, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda is forcing GPT on non-EFI BIOS
On 08/02/2011 04:05 PM, Athmane Madjoudj wrote: On 08/02/2011 08:52 PM, David Cantrell wrote: On 08/02/2011 02:52 PM, Athmane Madjoudj wrote: On 08/02/2011 07:45 PM, Athmane Madjoudj wrote: On 08/02/2011 07:36 PM, Athmane Madjoudj wrote: Hello, snip I found some good info here: https://bugzilla.redhat.com/show_bug.cgi?id=694808 Correct. There's no forcing by us, your hardware forced us to use GPT because of the size of its disk. If you have a UEFI-capable system, I suggest using it in UEFI mode. Weird because it was a KVM guest with 32G disk That definitely sounds suspicious. -- David Cantrell dcantr...@redhat.com Supervisor, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Instalatron: Anaconda testing framework
On 07/20/2011 08:50 AM, Sergio Rubio wrote: On Wed, Jul 20, 2011 at 11:23 AM, Hongqing Yanghoy...@redhat.com wrote: Hi, Sergio, Hi Hongqing, Thanks for sharing. Now I and Tao Wu are working on the project Fedora installation test automation. The project is based on the Autotest framework and part of the AutoQA project. Now it is using qemu-kvm and the test results are read from the logs. The installations from url, DVD, hard drive and upgrade are almost finished, we try to implement all the tests roughly first, so we can use them at the usual tests, more details will be done later. I think we also will adopt screen-shot in future, since we cannot see the errors of UIs from logs. I'm eagerly waiting to have a look at that project. Any ETA or something that I can have a look at? I saw you compare the images in the codes, but which are images should the screen-shots compare with when one new product is released? If Anaconda UI has not changed a lot, you can just copy the script Just a heads up, the anaconda UI will be changing a lot: http://fedoraproject.org/wiki/Anaconda/UX_Redesign and: http://blog.linuxgrrl.com/category/fedora/anaconda/ from a previous recording (say F15) and replace the relevant steps in script.yml (i.e. replacing the png and/or altering the keyboard sequence). Usually 90% of the script can be reused and you only need to change the steps where the UI has changed. I'm writing some docs about this, it's a great use case. Thanks again, I leaned much from you codes, You are the first one I meet also works on the installation test. Glad to know you. My pleasure. Hongqing -- David Cantrell dcantr...@redhat.com Supervisor, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
