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
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
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
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
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
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.
, 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
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
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
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 /
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
>
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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.
_
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
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
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
. 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.
On 12/17/2015 05:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 17, 2015 at 05:34:31PM -0800, Brendan Conoboy wrote:
On 12/17/2015 05:27 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 17, 2015 at 04:13:06PM -0800, Brendan Conoboy wrote:
On 12/17/2015 01:43 AM, Harald Hoyer wrote
On 12/17/2015 04:22 PM, Adam Williamson wrote:
On Thu, 2015-12-17 at 16:13 -0800, Brendan Conoboy wrote:
On 12/17/2015 01:43 AM, Harald Hoyer wrote:
For docker containers, or containers, which don't want systemd, the current
"Requires: systemd" in a lot of packages is preven
On 12/17/2015 05:27 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 17, 2015 at 04:13:06PM -0800, Brendan Conoboy wrote:
On 12/17/2015 01:43 AM, Harald Hoyer wrote:
For docker containers, or containers, which don't want systemd, the current
"Requires: systemd" in a lot
eir package set to the utmost, they would be able to do so
without creating fake stub packages or using hacks to get around requires.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 10/08/2015 03:32 PM, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 09 October 2015 at 00:14, Brendan Conoboy wrote:
On 10/08/2015 08:48 AM, Haïkel wrote:
[snip]
Please keep in mind, that Fesco is aware this is not a perfect
solution, and we''ll gladly review any propo
nts- Fesco is clearly open to and expecting this, so
if you have an idea on how to further improve the bundling policies,
please propose it. In this way Fedora gets better and better over time.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing
On 09/15/2015 07:26 AM, Colin Walters wrote:
'On Mon, Sep 14, 2015, at 05:12 PM, Brendan Conoboy wrote:
I'm just one person with an opinion, it would be best if everybody
with a stake took part in the ring definitions. Creating additional
rings that address communities where self-ho
On 09/15/2015 07:51 AM, Josh Boyer wrote:
On Tue, Sep 15, 2015 at 10:27 AM, Matthew Miller
wrote:
On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote:
Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we
offer a longer term of support for ring 0 than rin
On 09/15/2015 07:27 AM, Matthew Miller wrote:
On Mon, Sep 14, 2015 at 02:19:38PM -0700, Brendan Conoboy wrote:
Let's say ring 0 isn't self hosting, but ring 0 + 1 ring is. Can we
offer a longer term of support for ring 0 than ring 1? What happens
when a bug in ring 0 requires a fix
On 09/14/2015 11:40 PM, Miroslav Suchy wrote:
Dne 14.9.2015 v 23:10 Brendan Conoboy napsal(a):
/Then/ we could start thinking about /truly minimal/ concepts,
perhaps “container minimal” = “the minimal set needed to start and
run an executable dependent on Fedora ABI” (e.g. kernel version
On 09/07/2015 05:34 AM, Miroslav Suchý wrote:
Dne 2.9.2015 v 20:59 Brendan Conoboy napsal(a):
5. Ring membership is at the source package level, not the binary
package. If one source package's binary/noarch sub-package is in ring
0, all sub-packages are in ring 0.
So we are going to in
ing 0 than ring 1? What happens
when a bug in ring 0 requires a fix in ring 1, but the support window
for ring 1 has closed? That's the main thing that's worrying about a
free-for-all with self hosting.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
deve
first class OS for
languages where rpm packaging doesn't make sense is great!
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 09/07/2015 05:21 AM, Miloslav Trmac wrote:
2015-09-02 23:24 GMT+02:00 Brendan Conoboy mailto:b...@redhat.com>>:
[blc]
>> 5. Ring membership is at the source package level, not the binary
>> package. If one source package's binary/noarch sub-package is in
On 09/02/2015 02:14 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 13:57 -0700, Brendan Conoboy wrote:
On 09/02/2015 12:47 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote:
On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
Re-sending this with a
On 09/02/2015 12:47 PM, Simo Sorce wrote:
On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote:
On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
Re-sending this with a better title so people might read it ;-)
Yes, thanks -- I admit to having skimmed over it in my mail
On 09/02/2015 12:31 PM, Matthew Miller wrote:
On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
Re-sending this with a better title so people might read it ;-)
Yes, thanks -- I admit to having skimmed over it in my mail-catchup
attempt.
especially how the rings interact. As
On 09/02/2015 12:24 PM, Josh Boyer wrote:
On Wed, Sep 2, 2015 at 2:59 PM, Brendan Conoboy wrote:
Re-sending this with a better title so people might read it ;-)
I read it last week. Perhaps the lack of commentary isn't because of
the title. It's because there is nothing new
On 09/02/2015 12:24 PM, Adam Miller wrote:
On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
For today's meeting we didn't really use zodbot minute keeping
features, so in the interest of sparking some discussion I'd like to
recap.
At Flock 2015 there was a 2 hour session on the s
that does pass repoclosure, the
remaining subpackages go into a second repository with less strict
requirements.
--
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 Con
Re-sending this with a better title so people might read it ;-)
On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]
Minutes:
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.h
On 08/31/2015 11:41 AM, Simo Sorce wrote:
On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote:
On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]
Minutes:
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html>
Minutes
eate a ring 0 minimal
compose since we already need to check repoclosure? This might be a
great way to refactor primary/secondary such that we can gracefully
transition i686 down and secondary arches up. Lots of opportunities,
much to consider.
--
Brendan Conoboy / Red Hat, Inc. / b...@redh
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
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
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
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
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
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
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,
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
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
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
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
e graphics would it still be essential for PA
promotion that libGL for ARM work and be accelerated? There is no
proposal to throw out the baby or the bathwater. This is about defining
the threshold at which point armv7hl gets built along side i686 and x86_64.
--
Brendan Conoboy / Red Hat, Inc.
On 07/15/2013 10:15 AM, Chris Tyler wrote:
I think that's s/Arndale/Chromebook/
Same SoC, different peripherals sticking out.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3.9 GA
kernel, but are in the 3.10 update. This means Arndale should be fully
supportable in Fedora 20. Meanwhile, there is an F19 remix for Arndale
using a later kernel:
http://fedoraproject.org/wiki/Architectures/ARM/F19/Remixes
Kudos to Jon Disnard for putting this together.
--
Brenda
s out of line? There are a lot more people
with ARM devices than x86. Sorry everybody, we're going to have to
demote x86. ;-)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
primary build system I would say let's drop
graphics from official Fedora ARM support for the purposes of the move
and make all graphical images respins or remixes.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
this on a Cubieboard?
I'm not aware of the current remix situation on F19- Perhaps Hans will
comment?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
nt in what
is protected against, albeit less efficient?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
libGL because it's not a
requirement for headless deployment scenarios. Why would you argue for it?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
is that there are relatively major Fedora features that we've
advertised in big letters in the relatively recent past that simply
don't work because nobody has paid any attention to whether or not they
work.
Hmm.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing l
fully featured. Specifically stack guards are present but
pointer guards are not. This was news to all of us. It's disappointing
that the issue was not brought to the ARM team's attention prior to the
F20 promotion discussion being introduced.
--
Brendan Conoboy / Red Hat, Inc. / b...@re
ch a good job that Fedora already
has ARM on the same day as x86 and PowerPC.
Fair enough!
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
em. We're talking about cutting out the middle man.
6. It simplifies releng and infrastructure in that there is one less
secondary to handle, one less koji server to maintain, one less set of
firewall exceptions to honor, and whatever else goes into maintaining
the distinction.
d, but if all goes well this one will be
popular in hindsight :-)
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3. After #1 and #2 are complete, we can talk about what else is needed.
I would say you're setting the bar too high, but it has passed the event
horizon so evidence of its supposed existence is hard to come by. If
this is not what you mean to be conveying please demonstrate otherwise.
it's inevitable, but I would like to avoid a reprisal of the
Richard Dawkins & Wendy Wright debate. What evidence are you asking for?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
upports interactive anaconda installs over serial. Or vnc
installs if you want graphics. Or kickstart installs if you want
automation.
--
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
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
? 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
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
- 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
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
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
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
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
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
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
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
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
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
support.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
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
On 10/30/2012 02:58 PM, David Airlie wrote:
Should we just skip F18? (like seriously).
Seems a little over the top. Why not use the extra time to squash other
bugs, making F18 a better release overall?
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel
27;s formally asked. Everything else is opinion.
Some of it informed: attorneys, some of it educated guessing (devoted
groklaw readers), some of it blindingly ignorant. Wherever each member
of de...@l.fpo falls on that spectrum, the odds are they shouldn't be
giving legal advice becaus
On 06/18/2012 10:18 AM, Adam Williamson wrote:
Sorry for the self-reply, but just in case it's not brutally clear yet,
I wanted to explicitly state this:
[snip]
Bravo!
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
1 - 100 of 158 matches
Mail list logo
