On 07/16/2013 11:01 AM, Bill Nottingham wrote:
Brendan Conoboy (b...@redhat.com) said:
If not now, when? When libGL is ready to go?
... when someone fixes it?
Hypothetically speaking, if libGL is fixed in the next few days, do you
have any objections to armv7hl being moved to primary koji
t welcome to join in and
pursue your interest.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t employee I can provide access to ARM systems of
the same caliber as what is in the Fedora colo. Drop me a line and let
me know what you need- I will make it happen.
Thanks,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject
ether that's good enough."
I don't want to move the goalposts on the ARM effort, but I think it's
reasonable to expect that a list of "Known Broken/Deficient items" be
available. Does such a list exist?
The list of outstanding ARM bugs is tracked here:
https://bug
On 07/16/2013 07:16 PM, Matthew Garrett wrote:
On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote:
On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller
wrote:
On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote:
I don't want to move the goalposts on the ARM effort,
is one (slow) avenue. Beyond that, in some
cases it possible to provide hardware. Please email me if you need
this. Thanks,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
s testing, release blocking, etc, so growing the matrix needs to
approached cautiously. There is also a question of timing- what is the
cutoff for adding a new release blocking device? Alpha? Beta? Is it a
feature request? Feedback appreciated.
--
Brendan Conoboy / Red Hat, Inc. / b...@r
e to properly verify.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
for September of course :-) Cheers,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
is a ".x1"
(or x2, x3, x4) in the NVR- in which case we added some patches to make
it build.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fe
them. The bug report's suggestion of
running autoreconf will still have the desired effect, but the
'autoconf' suggestion was off. Sorry about that.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedor
On 03/25/2013 01:36 PM, Orion Poplawski wrote:
What version of
automake added aarch64?
Autoamke 1.11.4, evidently.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
14)
* jonmasters (13)
* msalter (9)
* zodbot (9)
* jsmith (8)
* pwhalen (5)
* handsome_pirate (5)
* dmarlin (3)
* ahs3 (1)
* j_dulaney (0)
* pbrobinson (0)
* ctyler (0)
* agreene (0)
* ddd (0)
* dgilmore (0)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fed
all ears. 999 out of 1000 is pretty good.
Cheers,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
e ARM
team are traveling or packing their bags today. We are going to skip
the weekly IRC discussion in #fedora-meeting-1, take flight, and be back
next week ready to rock Fedora 20's world.
TL;DR: No irc meeting today.
Thanks,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
dev
boot are supported on Fedora.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
- Aarch64 Koji VM
4) F20 PA Promotion
5) Open Floor
If there is something that you would like to discuss that isn't
mentioned please feel free to bring it up at the end of the meeting or
send an email to the list. Cheers,
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel ma
3 (1)
* j_dulaney (0)
* pbrobinson (0)
* ctyler (0)
* agreene (0)
* ddd (0)
* dgilmore (0)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
? The changes to the build system would be the same
with our without these desktops in either case. Note I'm not asking
Adam specifically; it's a question for the room.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject
to be merged. Whether you call it Primary, Secondary, or some new
middle-of-the-ground word, it's progress.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
t;. At first blush I like the idea of a
"primary server" and "primary desktop" designation (maintaining a
unified build system) but haven't thought the full consequences through.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lis
On 12/21/2012 08:53 AM, Matthew Garrett wrote:
Are you looking at F19 or F20 for PA?
This will be a very engaging topic at FUDCon next month. Current
logistics make the following likely:
F19: Transition to enterprise ARM hardware in PHX
F20: Push armv7hl to PA
--
Brendan Conoboy / Red
220.img.xz
kpartx -av F18-kirkwood-20121220.img
From here you can mount the partition with the files you need. I'm not
sure which one it is so you'll have to experiment:
mount /dev/mapper/loop0p1 /somewhere
Good luck, and don't forget to umount and kpartx -d that image when
support.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it done in F19.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
edora-meeting-1.2013-01-16-21.00.txt
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-16/fedora-meeting-1.2013-01-16-21.00.log.html
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
these files. Are the required
changes in upstream autoconf yet, and if so what version? If not,
why not?
Support for aarch64 landed in autoconf 2.69 which was released on March
25th and first built in Fedora on May 15th. Packages that use autoconf
2.69 are already good to go.
--
Brendan
do that instead? It
would be more of a stable midpoint release than a tick-tock, but you
get a similar effect without constraining devel.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
. It's a thing that could be adopted whether
or not Fedora moves to a once-a-year release and it could be done in
addition to rolling updates.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.
akes releases of their content layered on top of
the above package stream, but they can inject packages that are unique
to their edition. So the desktop edition can still make multiple
releases per year if they want, but they're layering on top of the
basic annual Fedora rele
On 12/20/2016 09:34 AM, Adam Williamson wrote:
On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote:
Batched updates are valuable when testing happens with the whole. It
sorts out complex interactions between multiple package updates by
testing them all together.
Of course, a corollary
ea.
If Fedora doesn't ship on predictable boundaries its alignment with
other projects that do is compromised. This includes projects like
glibc and gcc, which are a significant underpinnings of what makes a
Fedora release version.
--
Brendan Conoboy / RHEL Development Coordi
n could find their shared libraries in a
Debian specific directory, even though it's a Fedora system that is
booted. A lot of fiddly details and hand waving go here, but the end
result would be really useful.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_
e.
The fact we don't have that is part of what is driving container adoption.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
adapt, and grow.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
nd we can track whether that reason
continues to exist over time, having the capability is a win.
Is "the maintainer wants to keep maintaining it" a good enough reason?
Because really when that is no longer true, that evaluation follows.
--
Brendan Conoboy / RHEL Development Coordi
27;t like to install packages for
non-native architectures.
Stephen, are we in a seductive detail here or is this conversation
applicable to your original problem?
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel m
s are much better served by full GNU
sysroots (/usr/target, not /usr/lib/target).
Hey, I can agree to that. Can you agree that /usr/bin could then be a
symlink or linkfarm to /usr/target/usr/bin?
--
Brendan Conoboy / RHEL Development Coordinator / Re
On 01/12/2017 06:49 AM, Neal Gompa wrote:
On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy wrote:
On 01/11/2017 08:23 PM, Kevin Kofler wrote:
you must absolutely split the binaries (which would conflict with the
native
binaries) and the libraries (which you need to do your cross-compilation
doraproject.org/thread/IFBHS2WKKPKJH6H54OX4DV3U7A4XYOPU/
>
> --
> Aleksandra Fedorova
> bookwar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
choose
what buildroot they are based on. As an example, Fedora Server, which
has struggled to find its element, could actually be built in ways
more conducive to server use cases: different compiler flags, kernel
parameters, baselines, etc.
--
Brendan Conoboy / RHEL Development Coordinator /
On Thu, Jan 16, 2020 at 5:14 PM Kevin Fenzi wrote:
> On Thu, Jan 16, 2020 at 11:27:36AM -0800, Brendan Conoboy wrote:
> > One potential output of this change would be to have editions choose
> > what buildroot they are based on. As an example, Fedora Server, which
> > has
ebt, which is great, but would
you perhaps consider doing the same thing for F31, F32, etc? The
basic reasons for technical debt will continue- why not plan to
service the debt regularly?
--
Brendan Conoboy / RHEL Development Coordinator / Re
ar
gap between F30 and F31, perhaps the rules for what can be updated in
F30 could be revised to maintain the value people get from the 6 month
release cycle.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing
on't have to do that, we can just
make Fedora better. That's what having multiple cadences and
lifecycles is all about. So it is important to talk about how the
rules would change if F30 takes a year, because if the rules don't
change it might diminish one of the great thin
ons want to stick with it. Variable lifecycle or cadence can
open up these kinds of options. Some things are better fast. Some
things are better slow.
Owen
On Tue, Nov 27, 2018 at 1:19 PM Brendan Conoboy wrote:
On 11/27/18 10:13 AM, Josh Boyer wrote:
On Tue, Nov 27, 2018 at 11:21 AM Ow
kages. Similar for basic OS pieces: init system, dbus,
etc. Move the kernel faster, move the applications faster, but keep
that middle slower and stable. Having that platform live on the
gcc/libc 1 year cycle makes way more sense than the 6 month cycle we
have today.
--
Brendan Conoboy / RHE
independence of
each distribution and its members while creating something we can
share that is net-positive for all. It will be complex, but there is
definitely room for more 3-way collaboration than is happening today.
--
Brendan Conoboy / RHEL
ful opportunities? EG, if the same kernel were the default
for a longer period of time would that help make it suitable for
factory installs? I really enjoy that the same Fedora release goes
through many kernels in its lifetime, but being able to buy an XPS
with Fedora would easily equal that d
References:
1. Initial Announcement -
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/U7TZRWXVUGBCHS6EBJIBSFAVPFUHHV7J/
2. Migration Starting -
https://lists.centos.org/pipermail/centos-devel/2023-August/143056.html
3. Issues.redhat.com account basics -
https://access.redhat.com
On Fri, Sep 8, 2023 at 7:34 PM Maxwell G wrote:
> 2023-09-09T01:05:39Z Brendan Conoboy :
>
> > All new issues found or desired in RHEL (Or CentOS Stream) need to be
> > filed on issues.redhat.com[http://issues.redhat.com].
> Hi Brendan,
>
> Thanks for the update.
&g
On Fri, Sep 8, 2023 at 9:18 PM Gary Buhrmaster
wrote:
> On Sat, Sep 9, 2023 at 1:05 AM Brendan Conoboy wrote:
>
> > RHEL making this change does not imply or require that Fedora do the
> same.
>
> I am neither suggesting Fedora should do so, or
> not do so, but just a
sponsible for Bugzilla.
--
Brendan Conoboy / CASE & CPE / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/pro
ccount. Like most
systems, there is a "forgot your password?" link. If you have multiple
accounts (a common situation) you can mail rh-issues at redhat dot com for
help.
--
Brendan Conoboy / CASE & CPE / Red Hat, Inc.
___
devel m
rnel. The sooner
there is confidence in it the sooner it gets pushed out for everybody
to use. And in testing the kernel you are (probably) immediately
protecting yourself, so it's a win all around.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
bution. This
is a net-positive, right? If your position is that earlier is better,
we're doing it earlier, and this is better. If your position is that it
doesn't go far enough, consider the contrary feedback from some people here
where some maintainers are concerned about potential make
, and to do the fix in Fedora's ELN so both Fedora
and RHEL get a benefit instead of just RHEL.
--
Brendan Conoboy / Linux Project Lead / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@l
it doesn't seem to have sunk in.
I don't believe anybody has yet been asked to fix gcc-11 build
failures. I take his note to be about earlier build failures that
occurred with gcc 10, but not because of gcc 10.
--
Brendan Conoboy / Linux Project Lead / Red Hat, Inc.
Hi everybody,
The “CPE” name is a commonly used identifier in the Fedora and CentOS
communities. Inside Red Hat, it meant a specific set of individuals and
roles reporting into common management. We recently had a reorg that
brought it and other community roles together. There is a new name for th
tive. In the coming weeks I will be sharing insights and
ideas. I’m not sure where it will lead, but that’s part of the fun of
sharing with others, the feedback alters the course. I'd love to hear from
you.
(Dup-posting this to discussion since the audience may vary).
--
Brendan Conoboy /
On Thu, Jan 9, 2025 at 3:53 PM Michel Lind wrote:
> On Wed, 2025-01-08 at 20:43 -0800, Brendan Conoboy wrote:
> > Over the last few months on chat.fp.o and at conferences I have
> > started joining into conversations- listening, asking questions,
> > making assertions, te
ication about works in progress, things not decided, that which may
affect one another, or there would be a mutual interest is needed. When I
think about it, it’s astonishing we don’t have something so fundamental.
(This is dup-posted
<https://discussion.fedoraproject.org/t/what-every
ect.org/t/konflux-what-is-the-right-time/146722>
on the discussion forum).
--
Brendan Conoboy / Community Linux Engineering / Red Hat, Inc.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
101 - 163 of 163 matches
Mail list logo
