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.
dures/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 Co
ername 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. |
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
ion 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
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:
> > >
> &
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
mea
On Fri, Feb 28, 2014 at 11:57:38PM +0200, Panu Matilainen wrote:
> On 02/28/2014 09:54 PM, David Cantrell wrote:
> >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:
> >>
> >>>
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
Manager, Installer Engineering Team
Red
rt 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
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:
>>>>
>
>
> 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 Ca
g 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
t/anaconda-ks.cfg.
A lot
of people use these as a starting point.
There is also system-config-kickstart.
Regardless of the tool you use, keep the kickstart documentation within easy
reach:
http://fedoraproject.org/wiki/Anaconda/Kickstart
--
David Cantrell
Red Hat / Honolulu, HI
--
test maili
14 matches
Mail list logo
