On Fri, 2012-11-09 at 23:38 -0800, M. Edward (Ed) Borasky wrote:
> On Fri, Nov 9, 2012 at 8:22 PM, Ralf Corsepius wrote:
> > On 11/10/2012 01:30 AM, Adam Williamson wrote:
> >>
> >> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
> >>>
> >>> Adam Williamson wrote:
> >
> >
> >>> So, since Fe
On Fri, Nov 9, 2012 at 8:22 PM, Ralf Corsepius wrote:
> On 11/10/2012 01:30 AM, Adam Williamson wrote:
>>
>> On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
>>>
>>> Adam Williamson wrote:
>
>
>>> So, since Fedora has existed, Anaconda's memory requirements have
>>> increased
>>> by at least
On Fri, 2012-11-09 at 22:17 -0800, Adam Williamson wrote:
> So right now, we are doing substantially *better* at supporting old
> systems than we were in 2003.
Oh, god, I'm pulling a Kevin with this list spamming, but this is just
too glorious not to post. I couldn't resist taking a trip in the w
On 11/10/2012 05:12 AM, Adam Williamson wrote:
But it's not_helping_ anything. It's not signal. It's just noise. I
didn't say 'you need 6GB of RAM to install Fedora'. I said to Kevin
'you're comparing the minimum requirements from a time when 256MB of RAM
was a standard desktop configuration to
On Fri, Nov 9, 2012 at 1:26 PM, Jerry James wrote:
> Does anybody know if there are licensing issues with itext 5.x? I'd like to
> package some software that needs a fairly recent version of itext, but I
> know we've had license issues with that package in the past.
>
> Also, FWIW, bouncycastle h
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote:
> > Look, I like a good argument as much as anyone else, but this is
> > ludicrous. Are you just replying to me for the sake of scoring a point?
> No. I feel Fedora is going down the drain, with the installer's demands
> and Fedora's upgra
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote:
> I am pointing out that what you are calling "9 year old" hardware is not
> unlike the hardware to be found on 4-2 year old netbooks/laptops/tablets
> etc. and consider ignoring this hardware to be a mistake.
BTW, for the factual record,
On Sat, 2012-11-10 at 06:40 +0100, Ralf Corsepius wrote:
> > Is this really what you would like us to
> > do, or are you just compulsively contradicting whatever you can?
> Neither. I am simply deeply convinced that one of Linux traditional
> domains and key feature had been "not being as resourc
Once upon a time, "Jóhann B. Guðmundsson" said:
> *cough* tmpfs *cough*
>
> Not that I have been bitten by or explicitly looking at it but depending
> how close to upstream systemd Anaconda is an % percentage of that ram is
> being reserved else where ;)
Where is it being "reserved"? Hint: no
On 11/10/2012 05:36 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 05:22 +0100, Ralf Corsepius wrote:
On 11/10/2012 01:30 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
So, since Fedora has existed, Anaconda's memory requirements h
On Sat, 2012-11-10 at 06:13 +, Vincenzo Virgilio wrote:
> Finally, there are a lot of people here that can choose fedora, and
> many more if Anaconda will put its install memory requirement to 512
> mbyte so i can choose Xfce or Lxde without doing more tricky
> workaround.
>
> On 22-23 of Mar
Usually I'm a lurker here, but now I have two things to say, and maybe make two
of you return to working with renewed responsability.
First of all, i work as network manager at the University of Palermo, Italy,
and we have a lug and jug named Sputnix.
I spent last three years of my life pushing
On Sat, 2012-11-10 at 04:56 +, "Jóhann B. Guðmundsson" wrote:
> On 11/10/2012 04:46 AM, Adam Williamson wrote:
> > On Sat, 2012-11-10 at 04:40 +, "Jóhann B. Guðmundsson" wrote:
> >> On 11/10/2012 12:30 AM, Adam Williamson wrote:
> >>> You're being pretty absurd comparing 2003 requirements t
On 11/10/2012 04:46 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 04:40 +, "Jóhann B. Guðmundsson" wrote:
On 11/10/2012 12:30 AM, Adam Williamson wrote:
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
My hp pavi
On 11/10/2012 02:01 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
People thinking like you are the reason why e
On 11/10/2012 01:19 AM, Carl G wrote:
Could you provide a link to that discussion?
pick a release cycle and go through the mailinglist archives.
It's one of those topics that resurface on each of them so you should
not have a hard time finding something in each of them...
JBG
--
devel maili
On Sat, 2012-11-10 at 04:40 +, "Jóhann B. Guðmundsson" wrote:
> On 11/10/2012 12:30 AM, Adam Williamson wrote:
> > You're being pretty absurd comparing 2003 requirements to 2012
> > requirements without allowing at all for hardware inflation.
>
> My hp pavilion came out of the box with 2GB ram
On 11/10/2012 12:30 AM, Adam Williamson wrote:
You're being pretty absurd comparing 2003 requirements to 2012
requirements without allowing at all for hardware inflation.
My hp pavilion came out of the box with 2GB ram bought last year ago and
tablets and various other devices aren't that high
On 11/10/2012 12:12 AM, Kevin Kofler wrote:
Adam Williamson wrote:
>It's not one of our supported upgrade mechanisms, and there appears to
>be no chance of that changing.
That's the whole problem. Why is our most reliable upgrade mechanism not
"supported"?
For the first QA got completely byp
On Sat, 2012-11-10 at 05:22 +0100, Ralf Corsepius wrote:
> On 11/10/2012 01:30 AM, Adam Williamson wrote:
> > On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
> >> Adam Williamson wrote:
>
> >> So, since Fedora has existed, Anaconda's memory requirements have increased
> >> by at least an or
On 11/10/2012 01:30 AM, Adam Williamson wrote:
On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
So, since Fedora has existed, Anaconda's memory requirements have increased
by at least an order of magnitude! How's that NOT "skyrocketing"?
You're being pretty abs
On Fri, Nov 09, 2012 at 01:26:44PM -0500, Matthew Miller wrote:
> This perplexing to me. In my %post section, I tried both writing
> "GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set
> timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the
> config file after
Matthew Miller wrote:
> On Sat, Nov 10, 2012 at 01:16:55AM +0100, Kevin Kofler wrote:
>> > However, I'm not sure that we can solve this kind of disconnect by a
>> > process change.
>> How about a general policy that planned regressions are not acceptable
>> unless explicitly approved by FESCo? Any
On Sat, 2012-11-10 at 02:49 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > You're being pretty absurd comparing 2003 requirements to 2012
> > requirements without allowing at all for hardware inflation.
>
> People thinking like you are the reason why entire villages in China and
> Africa
Adam Williamson wrote:
> You're being pretty absurd comparing 2003 requirements to 2012
> requirements without allowing at all for hardware inflation.
People thinking like you are the reason why entire villages in China and
Africa are huge heavily-polluted landfills of electronic scrap material.
On Fri, 2012-11-09 at 20:39 -0500, Matthew Miller wrote:
> On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote:
> > it maybe doesn't actually need to be). So perhaps we should change
> > firewalld to default to opening port 22.
>
> +1, even having read the rest of this message.
>
>
>
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote:
> Of course, the real question is why the heck PolicyKit needs a Turing-
> complete rule language (which also forced everyone to port their existing
> rules) when the previously-used simple INI-style pkla rule format did the
> job just
On Sat, 2012-11-10 at 01:19 +, Carl G wrote:
> Could you provide a link to that discussion?
Oh, god, it's been dragged up at least three times that I remember. I
don't really want to spend my afternoon dredging my archives to find the
precise links, but I'd recommend browsing the results of th
On Sat, Nov 10, 2012 at 01:16:55AM +0100, Kevin Kofler wrote:
> > However, I'm not sure that we can solve this kind of disconnect by a
> > process change.
> How about a general policy that planned regressions are not acceptable
> unless explicitly approved by FESCo? Any feature that you want to re
On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote:
> it maybe doesn't actually need to be). So perhaps we should change
> firewalld to default to opening port 22.
+1, even having read the rest of this message.
Same with iptables if firewalld is not installed by default.
--
Matth
Matthew Miller wrote:
> Apparently the new version of polkit brings in javascript. The js package
> is 6.5MB. I think anything that uses polkit will depend on it -- can we
> remove it from core?
Of course, the real question is why the heck PolicyKit needs a Turing-
complete rule language (which al
Could you provide a link to that discussion?
Thanks
2012/11/9 Adam Williamson
> On Sat, 2012-11-10 at 01:12 +0100, Kevin Kofler wrote:
> > Adam Williamson wrote:
> > > It's not one of our supported upgrade mechanisms, and there appears to
> > > be no chance of that changing.
> >
> > That's the
Kevin Fenzi wrote:
> On Fri, 09 Nov 2012 20:16:50 +0100
> Roberto Ragusa wrote:
>
>> Serious question: why usrmove is not doable?
>> If you have all the dirs in your path, and move executable files from
>> one place to another, why should this fail?
>
> All your dynamic libraries move?
If you
Am 10.11.2012 01:12, schrieb Kevin Kofler:
> Adam Williamson wrote:
>> It's not one of our supported upgrade mechanisms, and there appears to
>> be no chance of that changing.
>
> That's the whole problem. Why is our most reliable upgrade mechanism not
> "supported"?
>
>> Please don't warm ove
On Sat, 2012-11-10 at 01:12 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > It's not one of our supported upgrade mechanisms, and there appears to
> > be no chance of that changing.
>
> That's the whole problem. Why is our most reliable upgrade mechanism not
> "supported"?
>
> > Please d
On Sat, 2012-11-10 at 00:52 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > It hasn't really 'skyrocketed'. We cited 512MB for several releases,
> > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> > F17, and it's back up to 768MB or 1GB for F18 atm because everyone ha
Miloslav Trmač wrote:
> However, I'm not sure that we can solve this kind of disconnect by a
> process change.
How about a general policy that planned regressions are not acceptable
unless explicitly approved by FESCo? Any feature that you want to remove
(temporarily or permanently) MUST be spel
Am 09.11.2012 23:57, schrieb drago01:
> On Fri, Nov 9, 2012 at 10:23 PM, Reindl Harald wrote:
>>
>>
>> Am 09.11.2012 22:14, schrieb Kevin Fenzi:
>>> I think the thing people are missing here is that yum dist upgrades are
>>> perfectly fine for advanced users who know how to work around problems
Adam Williamson wrote:
> It's not one of our supported upgrade mechanisms, and there appears to
> be no chance of that changing.
That's the whole problem. Why is our most reliable upgrade mechanism not
"supported"?
> Please don't warm over that argument again.
Why not?
> The messaging and opti
Toshio Kuratomi wrote:
> Being stricter about having viable contingency plans for features like
> this (ones that require coordination and can potentially block us if they
> aren't done/done correctly) is one possible way to address this type of
> situation in the future.
And it's the right way. I
Adam Williamson wrote:
> It hasn't really 'skyrocketed'. We cited 512MB for several releases,
> bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> F17, and it's back up to 768MB or 1GB for F18 atm because everyone has
> more important stuff to do than optimize the RAM usage righ
On Fri, 09.11.12 11:42, Daniel Drake (d...@laptop.org) wrote:
> Hi Bill
>
> I see that initscripts in F18 ships this udev rule:
>
> ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device",
> RESULT=="?*", ENV{INTERFACE_NAME}="$result"
>
> I'm trying to tackle some problems related to
On Sat, 10.11.12 00:12, Paolo Bonzini (pbonz...@redhat.com) wrote:
>
> Il 09/11/2012 18:26, Lennart Poettering ha scritto:
> > 1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org)
> > wrote:
> >
> >> On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
> >>>
On Fri, 2012-11-09 at 15:06 -0800, Adam Williamson wrote:
> Right now it seems like anaconda actually just throws firewalld into the
> target package set in absolutely all cases, like it does with
> authconfig, which I think is wrong. As the above makes clear, it only
> really makes sense to use a
On Fri, 2012-11-09 at 07:12 -0500, Matthias Clasen wrote:
> On Thu, 2012-11-08 at 14:18 -0500, Bill Nottingham wrote:
>
> > FYI, re: firewalld & minimal install.
> >
> > firewalld isn't in the minimal comps groups. However, it's pulled in
> > by anaconda, see pyanaconda/install.py:
> >
> > #
On 2012-11-09, 19:45 GMT, Jesse Keating wrote:
> I don't think I'm necessarily disagreeing with you. I don't think
> anybody on the Anaconda team is happy with the current memory usage.
> That said, we've had very very very little time to pursue fixing this
> particular issue.
I said in my fi
On Fri, Nov 9, 2012 at 10:23 PM, Reindl Harald wrote:
>
>
> Am 09.11.2012 22:14, schrieb Kevin Fenzi:
>> I think the thing people are missing here is that yum dist upgrades are
>> perfectly fine for advanced users who know how to work around problems
>> and use the tools, but aren't very good for
On Fri, 2012-11-09 at 14:14 -0700, Kevin Fenzi wrote:
> On Fri, 09 Nov 2012 20:16:50 +0100
> Roberto Ragusa wrote:
>
> > Serious question: why usrmove is not doable?
> > If you have all the dirs in your path, and move executable files from
> > one place to another, why should this fail?
>
> All
Am 09.11.2012 22:14, schrieb Kevin Fenzi:
> I think the thing people are missing here is that yum dist upgrades are
> perfectly fine for advanced users who know how to work around problems
> and use the tools, but aren't very good for well, everyone else.
yes and no
one real benefit of the yum
On 11/09/2012 09:21 PM, Adam Williamson wrote:
We just just have feature submission deadline, feature approval
>deadline, then we work on approved features until they are done and then
>give releng/marketing x time to prepare for release. that means we can
>have 5 month release cycle or 7 or 9 mo
On Fri, 2012-11-09 at 21:11 +, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2012 05:35 PM, Toshio Kuratomi wrote:
> > On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
> >> As far as Anaconda reverted in the future, I'm confused as to
> >> when/where this became a requirement.
> >>
>
Juan Rodriguez writes:
> I did it on a live system, too. The only thing that failed during that time
> was postgres (Which managed to stay borked after it was done and f18
> booted, the pg_upgrade method didn't work properly)
BZ?
regards, tom lane
--
devel mailing list
d
On Fri, 09 Nov 2012 20:16:50 +0100
Roberto Ragusa wrote:
> Serious question: why usrmove is not doable?
> If you have all the dirs in your path, and move executable files from
> one place to another, why should this fail?
All your dynamic libraries move? You need selinux relabling?
> I managed
On Fri, 2012-11-09 at 12:33 -0800, Jesse Keating wrote:
> On 11/09/2012 12:24 PM, Adam Williamson wrote:
> > On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote:
> >
> >>> But if we continue to look at minimal install which post-install
> >>> configuration files is Anaconda explicitly touching?
On 11/09/2012 05:35 PM, Toshio Kuratomi wrote:
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
As far as Anaconda reverted in the future, I'm confused as to
when/where this became a requirement.
I think he's saying this because:
1) Features have a section for contingency plans.
I can't comment on UsrMove because I'm quite unfamiliar with it, but I did
manage to upgrade from f17 to f18 using the totally unsupported yum update
--releasever --enablerepo="*testing" --nogpgcheck method.
Computer booted and everything's exactly as it used to (Though I did have
to remove some p
On 11/09/2012 12:05 PM, Toshio Kuratomi wrote:
On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote:
On 11/08/2012 11:31 AM, Adam Williamson wrote:
Yes. This is_absolutely_ a feature. A complete rewrite of a core and
non-optional component cannot be done ad hoc without planning. One
b
On Fri, 2012-11-09 at 09:47 -0800, Jesse Keating wrote:
> > But if we continue to look at minimal install which post-install
> > configuration files is Anaconda explicitly touching?
>
> root auth and firewall config are the main ones. Note that we don't
> have any UI for firewall config either,
On Fri, 2012-11-09 at 09:35 -0800, Jesse Keating wrote:
> On 11/08/2012 11:31 AM, Adam Williamson wrote:
> > Yes. This is_absolutely_ a feature. A complete rewrite of a core and
> > non-optional component cannot be done ad hoc without planning. One
> > blindingly obvious reason for this in the cur
On Fri, 2012-11-09 at 14:47 +, Matthew Garrett wrote:
> On Thu, Nov 08, 2012 at 06:02:10PM -0800, Adam Williamson wrote:
>
> > Aside from that - I can understand your frustration that you think
> > people are chinwagging and not helping, but my point is kind of that you
> > (anaconda team) hav
On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote:
> On 11/08/2012 11:31 AM, Adam Williamson wrote:
> >Yes. This is_absolutely_ a feature. A complete rewrite of a core and
> >non-optional component cannot be done ad hoc without planning. One
> >blindingly obvious reason for this in the
On 11/09/2012 11:32 AM, Matej Cepl wrote:
On 2012-11-09, 17:06 GMT, Jesse Keating wrote:
Because anaconda links into a large amount of runtime stuff, that
normally runs isloated and so it /looks/ like our memory usage is
balooned, when in reality the entire system has balooned, we're just
gettin
On 2012-11-09, 17:15 GMT, Peter Jones wrote:
> The installer's memory footprint is largely bound by the size of the
> package set. So, for example, a yum "upgrade" will take more ram -
> because there are effectively twice as many packages involved.
I see that. Couldn’t be there a way how to someh
On 2012-11-09, 17:06 GMT, Jesse Keating wrote:
> Because anaconda links into a large amount of runtime stuff, that
> normally runs isloated and so it /looks/ like our memory usage is
> balooned, when in reality the entire system has balooned, we're just
> getting the blame.
Right, that looks po
Am 09.11.2012 19:08, schrieb Jesse Keating:
> On 11/09/2012 09:57 AM, Panu Matilainen wrote:
>>
>> Except that rpm (and yum) use a lot LESS memory these days than they did
>> in the RHEL-5 era, which I think was used as a comparison here. That's
>> not where all the memory has gone, quite the con
On 11/09/2012 10:19 AM, drago01 wrote:
> On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý wrote:
>> On 11/08/2012 03:10 PM, Roberto Ragusa wrote:
>>>
>>> Hmm, I now see there is a "set -e" at the beginning.
>>> Still a little scary.:-)
>>
>>
>> Scary is only the idea. And only because we are not us
On Fri, 9 Nov 2012, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote:
Not sure these two QUITE do the same thing - but they use the
installer similarly, I think.
here's what I've been using:
https://github.com/eucalyptus/ami-creator
I've got https://github
Am 09.11.2012 17:45, schrieb Thomas Woerner:
> On 11/09/2012 05:24 PM, Eric H. Christensen wrote:
> Please have a look at the feature list for F-18.
>
> firewalld replaces system-config-firewall/lokkit, and the iptables and
> ip6tables services, not the iptables package
> and command.
>
> The
On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote:
> Not sure these two QUITE do the same thing - but they use the
> installer similarly, I think.
>
> here's what I've been using:
>
> https://github.com/eucalyptus/ami-creator
I've got https://github.com/katzj/ami-creator :)
--
Matthew
On Fri, 9 Nov 2012, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote:
in your kickstart can you do:
bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect
_either_.
hmmm - seems to work for me using ami-creator.
I'm us
On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote:
> >>in your kickstart can you do:
> >>bootloader --timeout=1
> >Forgot to mention: this is already there and does not have any effect
> >_either_.
> hmmm - seems to work for me using ami-creator.
I'm using appliance-creator because it's w
On Fri, 9 Nov 2012, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote:
in your kickstart can you do:
bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect
_either_.
hmmm - seems to work for me using ami-creator.
-sv
On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote:
> in your kickstart can you do:
> bootloader --timeout=1
Forgot to mention: this is already there and does not have any effect
_either_.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁
--
devel mailing list
devel@lists.fedorapro
Am 09.11.2012 17:35, schrieb Kevin Fenzi:
> On Fri, 9 Nov 2012 11:20:08 -0500
> Matthew Miller wrote:
>
>> On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote:
Yes probably. Anyone know why it's there?
>>> IIRC, even if you 'disable' it, plymouth is still the thing handing
>>> the
On Fri, 9 Nov 2012, Matthew Miller wrote:
This perplexing to me. In my %post section, I tried both writing
"GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set
timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the
config file after doing those things.
Bu
This perplexing to me. In my %post section, I tried both writing
"GRUB_TIMEOUT=0" to /etc/default/grub and using sed to replace "set
timeout=5" in grub2.cfg. I even put a call to grub2-mkconfig to re-write the
config file after doing those things.
But on boot, grub.cfg file always contains timeout
Does anybody know if there are licensing issues with itext 5.x? I'd like
to package some software that needs a fairly recent version of itext, but I
know we've had license issues with that package in the past.
Also, FWIW, bouncycastle hasn't been updated because of itext (
https://bugzilla.redhat
On 11/09/2012 09:57 AM, Panu Matilainen wrote:
Except that rpm (and yum) use a lot LESS memory these days than they did
in the RHEL-5 era, which I think was used as a comparison here. That's
not where all the memory has gone, quite the contrary.
While that may be true, the amount of ram (free
On Fri, Nov 09, 2012 at 08:57:05AM -0800, Jesse Keating wrote:
> >>Just to cite similar complaints I see from time to time... It irritates
> >>me that people think it's a problem that in 2012 they can't install in a
> >>VM that is allocated with 256M of RAM. Allocate a reasonable amount,
> >>start
On 11/09/2012 07:15 PM, Peter Jones wrote:
On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote:
On 2012-11-09, 14:30 GMT, David Cantrell wrote:
Just to cite similar complaints I see from time to time... It
irritates me that people think it's a problem that in 2012 they can't
install in
On Fri, Nov 09, 2012 at 09:49:00AM -0800, Jesse Keating wrote:
> On 11/09/2012 09:35 AM, Toshio Kuratomi wrote:
> >On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
> >>
> >>As far as Anaconda reverted in the future, I'm confused as to
> >>when/where this became a requirement.
> >>
> >
On 11/09/2012 09:35 AM, Toshio Kuratomi wrote:
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
As far as Anaconda reverted in the future, I'm confused as to
when/where this became a requirement.
I think he's saying this because:
1) Features have a section for contingency plans
On 11/09/2012 09:11 AM, "Jóhann B. Guðmundsson" wrote:
Well the argue can be made that If you are doing a minimal install it
kinda indicates you actually know what you are doing ( which means you
will probably change whatever was set afterwards ) so the system should
just default to use sane work
On Fri, Nov 09, 2012 at 12:55:30PM +0100, Vratislav Podzimek wrote:
> On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote:
> >
> > I've been told that the F18 Anaconda work was for some time done on a
> > single rawhide snapshot; after ~2 months the snapshot was updated -
> > and it took weeks
Hi Bill
I see that initscripts in F18 ships this udev rule:
ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device",
RESULT=="?*", ENV{INTERFACE_NAME}="$result"
I'm trying to tackle some problems related to interface renaming, and
understanding how this works would be useful.
But I c
On Fri, 09.11.12 08:53, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Fri, Nov 09, 2012 at 01:41:08PM +, "Jóhann B. Guðmundsson" wrote:
> > You might want to remove plymouth from the minimal install since it
> > does not make sense having it there anyway
>
> Yes probably. Anyone know
On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote:
>
> As far as Anaconda reverted in the future, I'm confused as to
> when/where this became a requirement.
>
I think he's saying this because:
1) Features have a section for contingency plans.
2) In this particular case, we're slippin
On 08.11.2012 15:10, Miroslav Suchý wrote:
[1] https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum
Nice start, Thank you! I like the scripting (ifs) or even better a rule
based (make-like) approach. I will test your script on few instances.
--
devel mailing list
devel@lists.fedoraproje
On Fri, 2012-11-09 at 11:21 +0100, Matej Cepl wrote:
> On 2012-11-09, 07:43 GMT, Adam Williamson wrote:
> > It hasn't really 'skyrocketed'. We cited 512MB for several releases,
> > bumped it to 768MB for F15/F16 (IIRC), got it back down to 512MB for
> > F17, and it's back up to 768MB or 1GB for F18
On 11/09/2012 05:17 PM, Jesse Keating wrote:
I can keep going, but is it really necessary?
I argue yes maybe not here but having a wikipage under the anaconda name
space which mention all the package and configuration files change that
can directly affect the installer and how would be neces
On 11/09/2012 03:27 AM, Miloslav Trmač wrote:
Well, perhaps thing B shouldn't have been changed incompatibly in the
first place. I realize that's an ideal that is impossible to achieve,
but we are rather cavalier about changing interfaces without adequate
notification.
I've been told that the F
1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mat...@fedoraproject.org)
wrote:
> On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
> > deserved. Just today I made a minor fix to systemd git to deal nicely
> > with PK-less systems.
>
> Right now, I get:
>
> $ reboot
> Failed
"Jóhann B. Guðmundsson" (johan...@gmail.com) said:
> >The storage packages are going to be needed for the system to boot.
> >
> >Anaconda could probably add some smarts to remove authconfig if it wasn't
> >pulled in by anything in the selected comps, but I'm not sure it'd be worth
> >the special l
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
> deserved. Just today I made a minor fix to systemd git to deal nicely
> with PK-less systems.
Right now, I get:
$ reboot
Failed to issue method call: The name org.freedesktop.PolicyKit1 was not
provided by any .service files
Mu
On 11/08/2012 12:47 PM, "Jóhann B. Guðmundsson" wrote:
On 11/08/2012 08:40 PM, David Lehman wrote:
No. It is an inevitable consequence of the feature set demanded of the
Fedora OS installer.
If thing A must be able to set up and configure thing B and thing B
changes in ways directly related to
On 11/09/2012 05:13 PM, Jesse Keating wrote:
As far as Anaconda reverted in the future, I'm confused as to
when/where this became a requirement.
It never was up to this point you know the usual attitude of "let's
cross that bridge when we get there" and this release cycle has proven
that it'
On Fri, Nov 09, 2012 at 05:33:05PM +0100, Matej Cepl wrote:
> On 2012-11-09, 14:30 GMT, David Cantrell wrote:
> > Just to cite similar complaints I see from time to time... It
> > irritates me that people think it's a problem that in 2012 they can't
> > install in a VM that is allocated with 256
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
> Of course, it should be clear that making PK optional if a desktop is
> installed is not desirable, but other than that I think for head-less
> systems such as servers or embedded making PK optional would be
> desirable goal and
On 11/09/2012 05:01 PM, Jesse Keating wrote:
On 11/09/2012 05:48 AM, Matthias Clasen wrote:
I still think there would be room for shrinking both code base and the
system dependencies if the installer focused on its core responsibility
- getting the bits on disk. That is an important and very hig
On 11/09/2012 08:57 AM, "Jóhann B. Guðmundsson" wrote:
On 11/09/2012 04:43 PM, Jesse Keating wrote:
While that has some obvious issues, like new hardware doesn't work
with old kernel/syslinux/grub/udev/etc...,
It's not like it always works in that area anyway
Right, computers don't always w
1 - 100 of 156 matches
Mail list logo
