Re: test days & smolt retirement

[Jóhann B. Guðmundsson]

On 11/10/2012 06:17 AM, Kevin Fenzi wrote:

(It's mentioned on the wiki page link I specifically pointed at in the
email too)


I skimmed over the announcement went to the mailing list so no activity 
so how about mentioning the link to the replacement instead of hiding it 
in the deprecation page in next announcement ;)


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: test days & smolt retirement

[Jóhann B. Guðmundsson]

On 11/10/2012 06:08 AM, Adam Williamson wrote:

I thought it was mentioned in the link about Smolt deprecation. And
indeed it was.

https://lists.fedoraproject.org/pipermail/announce/2012-October/003107.html

reads:

"A replacement for much of the functionality of smolt is under
development, see the census project mailing list for more infor


Oh yea that one that mentioned deprecation on smolt and points out an an 
mailinglist referring to only crickets.

( no wonder I could not remember it )

JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: test days & smolt retirement

[Kevin Fenzi]

On Fri, 09 Nov 2012 22:08:14 -0800
Adam Williamson  wrote:

> On Sat, 2012-11-10 at 05:58 +, "Jóhann B. Guðmundsson" wrote:
> > On 11/10/2012 01:00 AM, Adam Williamson wrote:
> > > We may need to hack up some kind of instructions to include lspci
> > > -nn output in the meantime, at least for some test days, until
> > > the new system is available.
> > 
> > Speaking of lack of communication which seems to be the theme for
> > this release what new system?
> > 
> > Heck the head of the infrastructure which kindly reminded us that
> > smolt was deprecated did not even bother to mention any new system
> > or replacement...

(It's mentioned on the wiki page link I specifically pointed at in the
email too)

> I thought it was mentioned in the link about Smolt deprecation. And
> indeed it was.
> 
> https://lists.fedoraproject.org/pipermail/announce/2012-October/003107.html
> 
> reads:
> 
> "A replacement for much of the functionality of smolt is under
> development, see the census project mailing list for more information:
> http://lists.fedorahosted.org/mailman/listinfo/census";

Nathaniel McCallum is the one who came up with census at the last
Fudcon. There was much discussion about how a better smolt could be
setup and work, he hacked up some code and then unfortunately has been
swamped with other things and hasn't had a chance to go further. 

Hopefully he will be able to come up for air long enough to direct
folks into helping out in implementation soon. 

kevin


signature.asc
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: test days & smolt retirement

[Adam Williamson]

On Sat, 2012-11-10 at 05:58 +, "Jóhann B. Guðmundsson" wrote:
> On 11/10/2012 01:00 AM, Adam Williamson wrote:
> > We may need to hack up some kind of instructions to include lspci -nn
> > output in the meantime, at least for some test days, until the new
> > system is available.
> 
> Speaking of lack of communication which seems to be the theme for this 
> release what new system?
> 
> Heck the head of the infrastructure which kindly reminded us that smolt 
> was deprecated did not even bother to mention any new system or 
> replacement...

I thought it was mentioned in the link about Smolt deprecation. And
indeed it was.

https://lists.fedoraproject.org/pipermail/announce/2012-October/003107.html

reads:

"A replacement for much of the functionality of smolt is under
development, see the census project mailing list for more information:
http://lists.fedorahosted.org/mailman/listinfo/census";
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: test days & smolt retirement

[Jóhann B. Guðmundsson]

On 11/10/2012 01:00 AM, Adam Williamson wrote:

We may need to hack up some kind of instructions to include lspci -nn
output in the meantime, at least for some test days, until the new
system is available.


Speaking of lack of communication which seems to be the theme for this 
release what new system?


Heck the head of the infrastructure which kindly reminded us that smolt 
was deprecated did not even bother to mention any new system or 
replacement...


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Adam Williamson]

On Sat, 2012-11-10 at 04:14 +, "Jóhann B. Guðmundsson" wrote:
> On 11/10/2012 12:39 AM, Adam Williamson wrote:
> > I think there's still some host/guest confusion going on, possibly.
> 
> I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an 
> host which is in context with the criteria discussion about Fedora being 
> installed along with other OS.

Right - that was the confusion I referred to. I think you were talking
about guest, while others might still have been thinking about host.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/10/2012 12:39 AM, Adam Williamson wrote:

I think there's still some host/guest confusion going on, possibly.


I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an 
host which is in context with the criteria discussion about Fedora being 
installed along with other OS.


I considered it important that Fedora works out of the box when deployed 
as an guest in available virtual solutions but other people seem to 
praise stallman and what not fixating on open being the only way and 
failing to understand that people will use what works for *them* and 
accept other alternatives...


It's kinda obvious that we cover our ground to the best of our ability 
with Fedora as an host where applicable ( kvm/xen )


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Matthew Miller]

On Fri, Nov 09, 2012 at 04:39:53PM -0800, Adam Williamson wrote:
> VBox does need out-of-tree kernel modules when run as a host on Linux.
> Some Linux distros package these via kmods or dkms or whatever. I'm not
> sure if RPMFusion packages them for Fedora. If your distro does not have
> a packaged version of RPMFusion with the kernel modules included, you
> have to use a little installer script that comes along with VBox to
> install them.

I dunno about VMware, but if you run a Linux distribution without
vmware-tools installed, your VMware administrator *will* yell at you.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by mattdm):

 I would resolve it but none of the resolutions seem  appropriate -- it's
 not fixed, worksforme, invalid, wontfix, or duplicate. I guess it's up to
 your workflow, but my preference (absent a "deferred" state) would be to
 leave it open and then we'll come back to it shortly.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Problems with locales in F18

[Adam Williamson]

On Fri, 2012-11-09 at 19:18 +0100, Joachim Backes wrote:

> > You must be exporting it somewhere check .bash_profile etc for 
> > "en.UTF-8" ( which probably is supposed to be "en_US.utf8" )
> 
> No, not in my homedir. But found in /etc/locale.conf and in
> /etc/sysconfig/i18

It sounds like you installed with an older version of anaconda. This was
a known bug for a brief time. Just find any config file where this is
specified, and change it to en_US.UTF-8. Or en_US.utf8. It's remarkably
difficult to find information on why these two variant forms exist and
which one is 'more correct', but the best I've been able to figure out
is that both are valid and it should be acceptable to use either.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Radeon HD 5750 on Fedora 18 - airplane take off

[Adam Williamson]

On Fri, 2012-11-09 at 08:40 +0100, Mateusz Marzantowicz wrote:
> I've just tried Fedora 18 Live desktop image. It's a big wow and despite
> some changes in gnome 3.6 which I'm not accustomed to everything seems
> to work fine.
> 
> There is however some serious issue, that is also present in earlier
> Fedora 17 release. It's about power management of graphics card. As
> stated in title it's Radeon HD 5750 (Juniper) and open source driver.
> When I started booting Fedora 18 I felt like I was in airplane that is
> about to take off.
> 
> I've managed to fix this "bug" (or call I whatever you want) according
> to instructions in
> http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options .
> 
> I have "profile" method set with "low" profile chosen it reduced fan
> speed both on F17 and F18. I use rc.local to set it during boot up. My
> question is: is it possible to set this by default in new Fedora 18? I
> don't know if it could be done during compile time of kernel/drivers or
> must be set explicitly like I did it. I think lot of people will be
> happy to hear that GPU fan isn't so noisy.

We would not pre-empt upstream defaults for this sort of thing. Apart
from anything else, the Fedora X maintainers are heavily plugged into
upstream, so if our X folks thought it made sense to enable the PM code
by default, they'd already have changed that upstream.

I don't follow this closely, but from what I know, the PM code is still
fairly new and is not considered reliable enough to enable by default
yet. The safest setting is still to run the fans in airplane mode - it
may be noisy, but at least we're pretty sure we're not cooking your
GPU. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: test days & smolt retirement

[Adam Williamson]

On Thu, 2012-11-08 at 09:59 -0500, Kamil Paral wrote:
> I have done a quick change [1] to our Test Day template and removed
> all Smolt references, because Smolt was retired [2]. But some test
> days might really miss this functionality. Any ideas how to replace
> missing Smolt with something useful in our test day matrices are
> welcome.

We may need to hack up some kind of instructions to include lspci -nn
output in the meantime, at least for some test days, until the new
system is available.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: post install very slooow

[Adam Williamson]

On Fri, 2012-11-09 at 16:30 -0800, Chuck Forsberg WA7KGX N2469R wrote:
> Somehow Anaconda managed to mess up the partition
> table on a different disk, so I had to reinstall a Fedora 16
> to get Windows et al back.
> 
> I noticed the post install processing in f16 lasted only
> a few seconds, not the seemingly interminable wait
> a Fedora 18 install takes.
> 
> Is this some sort of regression?

Yes, though it's smaller than is immediately obvious.

I found a bit of spare time last week and benchmarked this. F17 and
earlier actually paused for rather a long time while still showing
'Package XXX/XXX' - so they were really in post-installation before they
got around to telling you about it. F18 doesn't do this, installation of
the last package goes as quickly as it ought to, and it then immediately
tells you it's in post-install. So if you just count the amount of time
the UI is actually _telling_ you it's in post-install, you over-estimate
the slowness of F18. You have to adjust for the fact that F17 and
earlier lied. :)

When you do so, though, it still turns out that F18 post-install is
slower, just not so much slower.

I compared minimal installs of F17 and F18 - this was before the
firewalld-related growth in the size of F18's minimal package set, so
they were pretty comparable - and these are the numbers I got:

f17, start to finish: 1:23
f18, start to finish: 1:42

f17, last package to complete: 34s
f18, last package to complete: 56s

the 'last package to complete' number is the 'true' post-install time,
counting from when it starts installing the last package till when
install is complete, and accounting for the effect noted above. (the
splits are that f17 spends 30 seconds 'installing the last package' and
just 4 seconds on post-install, while F18 spends just 4 seconds
_actually_ installing the last package and 52 seconds on post-install).
So f18's true post-install time appears to be 22s longer than f17's,
when installing a minimal package set, and this accounts for the entire
overall decrease in f18's 'install performance' - f18 is actually faster
at the stuff before post-install than f17 was.

I mentioned this in #anaconda and interest was shown, but then more
important things came up and we've left it alone since then.

If someone has time to dive deeper into why post-install is taking more
time, though, I'm sure anaconda team would welcome it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Adam Williamson]

On Fri, 2012-11-09 at 17:21 -0700, Michal Jaegermann wrote:
> On Fri, Nov 09, 2012 at 11:24:54PM +, "Jóhann B. Guðmundsson" wrote:
> > On 11/09/2012 10:56 PM, Michal Jaegermann wrote:
> > >Vbox and vmware require external kernel modules.
> > 
> > Can you please provide a link to where it says you need to install
> > "external kernel modules"
> 
> Somebody said so earlier in this thread and I took it for a face value.
> Maybe I misunderstood something?

I think there's still some host/guest confusion going on, possibly.

VBox does need out-of-tree kernel modules when run as a host on Linux.
Some Linux distros package these via kmods or dkms or whatever. I'm not
sure if RPMFusion packages them for Fedora. If your distro does not have
a packaged version of RPMFusion with the kernel modules included, you
have to use a little installer script that comes along with VBox to
install them.

When running as a guest in VBox, I don't believe Linux _needs_ any out
of tree kernel modules to function, though I think there may be optional
'guest drivers' like most virt systems have, to improve the efficiency
of graphics and networking and provide for file transfer and
clipboarding between host and guest and so on.

I think you are a bit off-base when you say "This detail alone
immediately limits an audience for these "solutions" to a rather narrow
circle", though, even considering the host case. It's not very difficult
to install the modules to use VBox as a host even on Fedora, and on
Windows, Mac or many other distros, you can install VBox with the usual
installer system, you don't have to manually fiddle about with the
kernel modules.

I know from experience on these lists and on the forums that many users
do it. I'd say VBox is probably the most popular virtualization
environment for the 'desktop enthusiast' user group, who use a simple
single-system virt system to test out OSes and distributions - a
completely different use case from the 'enterprise virt' user who is
running multiple machines on a dedicated host. As I mentioned up-thread,
many users cite VBox's ease of use and features like 3D passthrough as a
reason to use it over virt-manager/libvirt/kvm.

Just go to the Fedora or Ubuntu forums and look how many people ask for
help with, or mention in passing that they are using, VBox. It's quite a
lot. And rather a lot more than mention virt-manager.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

post install very slooow

[Chuck Forsberg WA7KGX N2469R]

Somehow Anaconda managed to mess up the partition
table on a different disk, so I had to reinstall a Fedora 16
to get Windows et al back.

I noticed the post install processing in f16 lasted only
a few seconds, not the seemingly interminable wait
a Fedora 18 install takes.

Is this some sort of regression?

--
Chuck Forsberg WA7KGX N2469R c...@omen.com   www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
  Omen Technology Inc  "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Michal Jaegermann]

On Fri, Nov 09, 2012 at 11:24:54PM +, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2012 10:56 PM, Michal Jaegermann wrote:
> >Vbox and vmware require external kernel modules.
> 
> Can you please provide a link to where it says you need to install
> "external kernel modules"

Somebody said so earlier in this thread and I took it for a face value.
Maybe I misunderstood something?

   Michal
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Michal Jaegermann]

On Fri, Nov 09, 2012 at 11:17:16PM +, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2012 10:56 PM, Michal Jaegermann wrote:
> >Vbox and vmware require external kernel modules.  This detail alone
> >immediately limits an audience for these "solutions" to a rather narrow
> >circle
> 
> How so?

Is this is a serious question?  If yes then we definitely live in
different realities.

   Michal
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Adam Williamson]

On Fri, 2012-11-09 at 16:14 -0500, Josh Boyer wrote:
> On Fri, Nov 9, 2012 at 3:49 PM, "Jóhann B. Guðmundsson"
>  wrote:
> > On 11/09/2012 08:34 PM, Josh Boyer wrote:
> >>
> >> Maybe you're talking about running Fedora as a vbox or vmware guest on
> >> some other OS?
> >
> >
> > Yup those are the use cases I'm concern about as in users running other OS
> > and installing Fedora as an virtualzation guest in that OS. ( like Robyn
> > pointed out with Vbox as in "people who do dev-type work on macs" )
> 
> Eh.  There's certainly bugs in those cases too, because people install
> the 'guest' drivers to share the host FS and such, or because the
> implementation of the hypervisor is just broken.  So like I said, I'm
> not really thrilled about that case either.
> 
> However, I will admit it is a more difficult case to call because at
> least they're trying to use Linux in some form.  I just don't think,
> from a criteria perspective, that it's fair to compare it to dual boot.

You might want to read back in the thread to a post from Kamil in
response to me. I think we have a plausible way to go here, where we
write a criterion which says something like 'There must be no issues in
the installed system which prevent it from running as a guest on a
VirtualBox host' (roughly - just the idea, not final wording). The point
would be to only require that _we don't screw anything up_, not to say
definitively that 'the release must work as a VBox guest', as we do for
KVM. That gives us a get-out clause in the case where VBox itself is
busted upstream, which we don't want to block for; so long as everything
on the Fedora side was in order we'd be okay.

That way we could have a test case for running Fedora as a VBox guest,
and we could run it as part as validation, and if we ran into problems
we'd figure out whether they were Fedora-side or VBox-side, and if they
were Fedora-side they'd be blockers, but if they were VBox-side they
wouldn't.

Sensible?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Adam Williamson]

On Fri, 2012-11-09 at 13:06 -0700, Robyn Bergeron wrote:
> On 11/09/2012 12:37 PM, "Jóhann B. Guðmundsson" wrote:
> > On 11/09/2012 07:24 PM, Josh Boyer wrote:
> >> On Fri, Nov 9, 2012 at 2:17 PM, "Jóhann B. Guðmundsson"
> >>  wrote:
> >>> On 11/09/2012 07:14 PM, Kevin Fenzi wrote:
>  Smolt is also being retired:
> 
>  https://fedoraproject.org/wiki/Smolt_retirement
> 
>  The stats also have not been updated in quite a while.
> 
>  I'd take any data from smolt with a block of salt.
> >>>
> >>> Well those numbers show clear dominance in vbox and vmware on the
> >>> virtualzation field amongs those users that reported their smolt 
> >>> data so I
> >>> dont think we can ignore those numbers just like that.
> >> Yes we can.  We don't support VMWare or VBox.  We can ignore anything we
> >> don't support as much as we want.
> >
> > Yet we have criteria is specifically tailored at dual booting along 
> > proprietary operating system on proprietary filesystem ( thus arguably 
> > support it ) which can block our own release if not fulfilled.
> >
> > What's your take on that since you are so opposed to us adding a 
> > criteria that cover vbox,vmware which atleast arguably is equally 
> > being used among our userbase?
> Sticking strictly to the statistics point - I tend to agree at least on 
> Vbox - esp. for all the people who do dev-type work on macs, etc.
> 
> VMware is a bit harder to see - obviously they're the huge elephant in 
> the virt space but I would tend to think that people using KVM or Xen 
> would be more likely to use Fedora/care about open source and that we'd 
> get more value out of testing for that scenario than VMWare. But if the 
> (albeit old) stats reflect otherwise it might be worth considering, 
> though the ability to actually test that way isn't cheap and i fear that 
> we'd have pretty low participation in it.

I think the 'old' thing is pretty significant here; for quite a while
VMware was about the _only_ viable virt option. I certainly used
VMware-player for quite a long time just because there wasn't anything
else. I think it's certainly plausible that the smolt stats have a heavy
skew to VMware based on the time ranges they cover and don't cover. It
would be nice if we had better numbers, but lots of things would be
nice :/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by johannbg):

 Matt is it ok to close this ticket and you can just reopen it once the
 minimal sig comes to be or fesco decision has been made if need be or are
 you wondering or waiting for someone else to comment on the ticket?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Adam Williamson]

On Fri, 2012-11-09 at 10:01 +0100, Matthias Runge wrote:
> On 11/09/2012 09:49 AM, "Jóhann B. Guðmundsson" wrote:
> 
> >
> > But as has been pointed out why aren't we testing and ensuring that
> > Fedora runs well in vmware,hyperv and virtualbox since we ensure it
> > works well being dualbooted alongside windows?
> >
> > JBG
> OK, agreed. It seems common, to run Fedora also in any kind of 
> virtualization environment. So, we're also interested in a good user 
> experience there (whatever this may include).
> 
> But: Which environments do we take into account? Carry this to extremes: 
> We also need to look at cloud infrastructure envs, which are a special 
> case of virtualization

The fact that EC2 runs on Xen is actually one of the main reasons we
added a criterion for Xen a couple of cycles back. I think Johann and
Kamil make a decent point that we might want to continue expanding our
support/testing in the direction of more diverse virt environments than
just Fedora's 'native' virt stack.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by adamwill):

 matt, just in case you wonder why I haven't said anything - I think kparal
 is entirely on point in everything, and have nothing to add. comment #15
 covers the situation perfectly for me.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 10:56 PM, Michal Jaegermann wrote:

Vbox and vmware require external kernel modules.


Can you please provide a link to where it says you need to install 
"external kernel modules" because there is no mention of a such things 
here [1]


JBG

1.http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2030588http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2030588
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 10:56 PM, Michal Jaegermann wrote:

Vbox and vmware require external kernel modules.  This detail alone
immediately limits an audience for these "solutions" to a rather narrow
circle


How so?

JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Michal Jaegermann]

On Fri, Nov 09, 2012 at 06:58:07PM +, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2012 06:40 PM, Michal Jaegermann wrote:
> >On Fri, Nov 09, 2012 at 06:16:24PM +, "Jóhann B. Guðmundsson" wrote:
> >>On 11/09/2012 05:30 PM, Michal Jaegermann wrote:
> >>>On Fri, Nov 09, 2012 at 08:49:19AM +, "Jóhann B. Guðmundsson" wrote:
> >I was saying today it's more common that people use vm ( In both
> >direction linux in vm on windows and windows in vm on linux )
> >instead of dualbooting.
> >>>Just out of curiosity.  Do you have some real data to back up this claim
> >>Look at the top model section of [1] Virtual vs HW
> >...
> >>1. http://smolt.fedoraproject.org/static/stats/stats.html
> >You think that smolt data are representative?  I have serious doubts due
> >to a self-selection nature of these submissions; but at least these are
> >some numbers.
> 
> It's the only numbers we have and the accuracy of them is debatable
...
> 
> But there is certainly one thing we can say with these numbers that
> we should most definitely add a criteria surrounding vbox and vmware
> usage...

Vbox and vmware require external kernel modules.  This detail alone
immediately limits an audience for these "solutions" to a rather narrow
circle.  Yes, I appreciate that you do not have other numbers but I
would refrain from ascribing too much significance to these.

   Michal
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Robyn Bergeron]

On 11/09/2012 01:49 PM, "Jóhann B. Guðmundsson" wrote:

On 11/09/2012 08:34 PM, Josh Boyer wrote:

Maybe you're talking about running Fedora as a vbox or vmware guest on
some other OS?


Yup those are the use cases I'm concern about as in users running 
other OS and installing Fedora as an virtualzation guest in that OS. ( 
like Robyn pointed out with Vbox as in "people who do dev-type work on 
macs" )

Indeed, those are the use cases I was speaking of as well. :)


JBG





--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Josh Boyer]

On Fri, Nov 9, 2012 at 3:49 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 11/09/2012 08:34 PM, Josh Boyer wrote:
>>
>> Maybe you're talking about running Fedora as a vbox or vmware guest on
>> some other OS?
>
>
> Yup those are the use cases I'm concern about as in users running other OS
> and installing Fedora as an virtualzation guest in that OS. ( like Robyn
> pointed out with Vbox as in "people who do dev-type work on macs" )

Eh.  There's certainly bugs in those cases too, because people install
the 'guest' drivers to share the host FS and such, or because the
implementation of the hypervisor is just broken.  So like I said, I'm
not really thrilled about that case either.

However, I will admit it is a more difficult case to call because at
least they're trying to use Linux in some form.  I just don't think,
from a criteria perspective, that it's fair to compare it to dual boot.

josh
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 08:34 PM, Josh Boyer wrote:

Maybe you're talking about running Fedora as a vbox or vmware guest on
some other OS?


Yup those are the use cases I'm concern about as in users running other 
OS and installing Fedora as an virtualzation guest in that OS. ( like 
Robyn pointed out with Vbox as in "people who do dev-type work on macs" )


JBG


--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 08:06 PM, Robyn Bergeron wrote:


Sticking strictly to the statistics point - I tend to agree at least 
on Vbox - esp. for all the people who do dev-type work on macs, etc.


VMware is a bit harder to see - obviously they're the huge elephant in 
the virt space but I would tend to think that people using KVM or Xen 
would be more likely to use Fedora/care about open source and that 
we'd get more value out of testing for that scenario than VMWare. But 
if the (albeit old) stats reflect otherwise it might be worth 
considering, though the ability to actually test that way isn't cheap 
and i fear that we'd have pretty low participation in it. 


Users care and deploy what they can use so it has less with open but 
more about usable user interface which is why you have vmware on top 
citrix xenserver and Microsoft HyperV and since they have the only 
usable interfaces we kinda have to *care* that Fedora works out of the 
box on those as much as we care about dualbooting Fedora along Windows ( 
why dont we care about that with os-x hello! ) and if Fedora does not 
work out of the box with those they simply turn to the distribution that 
does ( most notably the triple U distro )


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Josh Boyer]

On Fri, Nov 9, 2012 at 3:16 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 11/09/2012 07:56 PM, Josh Boyer wrote:
>>
>> My personal take is that Windows doesn't try and load things into the
>> Linux kernel, or otherwise disrupt the installed Fedora OS so I don't
>> personally care.
>
>
> And vbox vmware and hyperv do?

Yes.  vbox and vmware load out-of-tree kernel modules.  We get many,
many reports in the kernel about things being broken when they're
loaded.

Hyperv modules are already provided as part of the Fedora kernel
because their development team worked diligently on getting them into
the upstream kernel.

Maybe you're talking about running Fedora as a vbox or vmware guest on
some other OS?  E.g. Windows as the host OS running Fedora within vbox.
We've seen reports where vbox has screwed up it's machine emulation and
caused Fedora kernels to crash in the guest too.  I'm really not
thrilled at all about that case either, but I don't really have a formed
opinion about it.

> What about ( citrix ) xen in that regard as well?

What about them?  Xen is already a supported target and has release
criteria against it working.  And as someone already noted somewhere
else, Amazon EC2 is all Xen and the cloud people are all about taht.
(I'm using the word supported here very loosely.  We are lucky to have
upstream Xen people looking at most of the issues that pop up around it.)

josh
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 07:56 PM, Josh Boyer wrote:

My personal take is that Windows doesn't try and load things into the
Linux kernel, or otherwise disrupt the installed Fedora OS so I don't
personally care.


And vbox vmware and hyperv do?

What about ( citrix ) xen in that regard as well?

Actually network out of the box in F17 guest in hyperv does not work out 
of the box ( but work on the triple U distro ) hence I dont think we 
need to worry to much that users are using/deploying fedora in hyperv...


JB.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Robyn Bergeron]

On 11/09/2012 12:37 PM, "Jóhann B. Guðmundsson" wrote:

On 11/09/2012 07:24 PM, Josh Boyer wrote:

On Fri, Nov 9, 2012 at 2:17 PM, "Jóhann B. Guðmundsson"
 wrote:

On 11/09/2012 07:14 PM, Kevin Fenzi wrote:

Smolt is also being retired:

https://fedoraproject.org/wiki/Smolt_retirement

The stats also have not been updated in quite a while.

I'd take any data from smolt with a block of salt.


Well those numbers show clear dominance in vbox and vmware on the
virtualzation field amongs those users that reported their smolt 
data so I

dont think we can ignore those numbers just like that.

Yes we can.  We don't support VMWare or VBox.  We can ignore anything we
don't support as much as we want.


Yet we have criteria is specifically tailored at dual booting along 
proprietary operating system on proprietary filesystem ( thus arguably 
support it ) which can block our own release if not fulfilled.


What's your take on that since you are so opposed to us adding a 
criteria that cover vbox,vmware which atleast arguably is equally 
being used among our userbase?
Sticking strictly to the statistics point - I tend to agree at least on 
Vbox - esp. for all the people who do dev-type work on macs, etc.


VMware is a bit harder to see - obviously they're the huge elephant in 
the virt space but I would tend to think that people using KVM or Xen 
would be more likely to use Fedora/care about open source and that we'd 
get more value out of testing for that scenario than VMWare. But if the 
(albeit old) stats reflect otherwise it might be worth considering, 
though the ability to actually test that way isn't cheap and i fear that 
we'd have pretty low participation in it.


JBG




--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Install didn't bring in libreoffice-langpack-en

[Bill Nottingham]

Orion Poplawski (or...@cora.nwra.com) said: 
> On 11/09/2012 12:00 PM, Bill Nottingham wrote:
> >Orion Poplawski (or...@cora.nwra.com) said:
> >>Just did a test kickstart install of F18.  Used the "@libreoffice"
> >>group for package selection, but I didn't get
> >>libreoffice-langpack-en installed.  Anyone know why?
> >
> >What version of anaconda & lorax were in the tree you installed from?
> >(This just had fixes come across very recently, they may not be in the
> >nightly tree.)
> >
> >Bill
> >
> 
> These were with the Beta TC7 images.  So I guess I'll wait for the
> next set. Thanks!

No problem. See https://bugzilla.redhat.com/show_bug.cgi?id=868869.

Bill
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Josh Boyer]

On Fri, Nov 9, 2012 at 2:37 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 11/09/2012 07:24 PM, Josh Boyer wrote:
>>
>> On Fri, Nov 9, 2012 at 2:17 PM, "Jóhann B. Guðmundsson"
>>  wrote:
>>>
>>> On 11/09/2012 07:14 PM, Kevin Fenzi wrote:

 Smolt is also being retired:

 https://fedoraproject.org/wiki/Smolt_retirement

 The stats also have not been updated in quite a while.

 I'd take any data from smolt with a block of salt.
>>>
>>>
>>> Well those numbers show clear dominance in vbox and vmware on the
>>> virtualzation field amongs those users that reported their smolt data so
>>> I
>>> dont think we can ignore those numbers just like that.
>>
>> Yes we can.  We don't support VMWare or VBox.  We can ignore anything we
>> don't support as much as we want.
>
>
> Yet we have criteria is specifically tailored at dual booting along
> proprietary operating system on proprietary filesystem ( thus arguably
> support it ) which can block our own release if not fulfilled.
>
> What's your take on that since you are so opposed to us adding a criteria
> that cover vbox,vmware which atleast arguably is equally being used among
> our userbase?

My personal take is that Windows doesn't try and load things into the
Linux kernel, or otherwise disrupt the installed Fedora OS so I don't
personally care.

As for being "popular", I have no doubt they are.  So are the nvidia
and flgrx drivers, and mp3 support, and a bunch of other things we
don't support as well.  All of that may be the best stuff since sliced
bread and awesome for our users, but it all runs within the Fedora OS
and comparing it to something completely outside of it seems odd.

Again, this is all my personal opinion which doesn't matter at all.

josh
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Install didn't bring in libreoffice-langpack-en

[Orion Poplawski]

On 11/09/2012 12:00 PM, Bill Nottingham wrote:

Orion Poplawski (or...@cora.nwra.com) said:

Just did a test kickstart install of F18.  Used the "@libreoffice"
group for package selection, but I didn't get
libreoffice-langpack-en installed.  Anyone know why?


What version of anaconda & lorax were in the tree you installed from?
(This just had fixes come across very recently, they may not be in the
nightly tree.)

Bill



These were with the Beta TC7 images.  So I guess I'll wait for the next set. 
Thanks!


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 07:24 PM, Josh Boyer wrote:

On Fri, Nov 9, 2012 at 2:17 PM, "Jóhann B. Guðmundsson"
 wrote:

On 11/09/2012 07:14 PM, Kevin Fenzi wrote:

Smolt is also being retired:

https://fedoraproject.org/wiki/Smolt_retirement

The stats also have not been updated in quite a while.

I'd take any data from smolt with a block of salt.


Well those numbers show clear dominance in vbox and vmware on the
virtualzation field amongs those users that reported their smolt data so I
dont think we can ignore those numbers just like that.

Yes we can.  We don't support VMWare or VBox.  We can ignore anything we
don't support as much as we want.


Yet we have criteria is specifically tailored at dual booting along 
proprietary operating system on proprietary filesystem ( thus arguably 
support it ) which can block our own release if not fulfilled.


What's your take on that since you are so opposed to us adding a 
criteria that cover vbox,vmware which atleast arguably is equally being 
used among our userbase?


JBG

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Josh Boyer]

On Fri, Nov 9, 2012 at 2:17 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 11/09/2012 07:14 PM, Kevin Fenzi wrote:
>>
>> Smolt is also being retired:
>>
>> https://fedoraproject.org/wiki/Smolt_retirement
>>
>> The stats also have not been updated in quite a while.
>>
>> I'd take any data from smolt with a block of salt.
>
>
> Well those numbers show clear dominance in vbox and vmware on the
> virtualzation field amongs those users that reported their smolt data so I
> dont think we can ignore those numbers just like that.

Yes we can.  We don't support VMWare or VBox.  We can ignore anything we
don't support as much as we want.

josh
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 07:14 PM, Kevin Fenzi wrote:

Smolt is also being retired:

https://fedoraproject.org/wiki/Smolt_retirement

The stats also have not been updated in quite a while.

I'd take any data from smolt with a block of salt.


Well those numbers show clear dominance in vbox and vmware on the 
virtualzation field amongs those users that reported their smolt data so 
I dont think we can ignore those numbers just like that.

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Kevin Fenzi]

Smolt is also being retired: 

https://fedoraproject.org/wiki/Smolt_retirement

The stats also have not been updated in quite a while. 

I'd take any data from smolt with a block of salt. 

kevin


signature.asc
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Install didn't bring in libreoffice-langpack-en

[Bill Nottingham]

Orion Poplawski (or...@cora.nwra.com) said: 
> Just did a test kickstart install of F18.  Used the "@libreoffice"
> group for package selection, but I didn't get
> libreoffice-langpack-en installed.  Anyone know why?

What version of anaconda & lorax were in the tree you installed from?
(This just had fixes come across very recently, they may not be in the
nightly tree.)

Bill
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 06:40 PM, Michal Jaegermann wrote:

On Fri, Nov 09, 2012 at 06:16:24PM +, "Jóhann B. Guðmundsson" wrote:

On 11/09/2012 05:30 PM, Michal Jaegermann wrote:

On Fri, Nov 09, 2012 at 08:49:19AM +, "Jóhann B. Guðmundsson" wrote:

I was saying today it's more common that people use vm ( In both
direction linux in vm on windows and windows in vm on linux )
instead of dualbooting.

Just out of curiosity.  Do you have some real data to back up this claim

Look at the top model section of [1] Virtual vs HW

...

1. http://smolt.fedoraproject.org/static/stats/stats.html

You think that smolt data are representative?  I have serious doubts due
to a self-selection nature of these submissions; but at least these are
some numbers.


It's the only numbers we have and the accuracy of them is debatable for 
instance you cant see how many % of total hw install are dualboot 
installs or how many virtualbox are running on windows etc...


But there is certainly one thing we can say with these numbers that we 
should most definitely add a criteria surrounding vbox and vmware usage...


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Problems with locales in F18

[Joachim Backes]

On 11/09/2012 07:35 PM, Sergio wrote:
> 
>>> You must be exporting it somewhere check .bash_profile
>> etc for 
>>> "en.UTF-8" ( which probably is supposed to be
>> "en_US.utf8" )
>>
>> No, not in my homedir. But found in /etc/locale.conf and in
>> /etc/sysconfig/i18
>>
> 
> run localectl
> 
> ('localectl list-locales' lists all valid locales)
> 

localectl set-locale en_US.utf8

in ~/.bashrc does not help (same warning),

but

localectl list-locales|grep en_US

en_US
en_US.iso88591
en_US.iso885915
en_US.utf8

Kind regards

Joachim Backes 

https://www-user.rhrk.uni-kl.de/~backes
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Install didn't bring in libreoffice-langpack-en

[Orion Poplawski]

Just did a test kickstart install of F18.  Used the "@libreoffice" group for 
package selection, but I didn't get libreoffice-langpack-en installed.  Anyone 
know why?


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Michal Jaegermann]

On Fri, Nov 09, 2012 at 06:16:24PM +, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2012 05:30 PM, Michal Jaegermann wrote:
> >On Fri, Nov 09, 2012 at 08:49:19AM +, "Jóhann B. Guðmundsson" wrote:
> >>>
> >>>I was saying today it's more common that people use vm ( In both
> >>>direction linux in vm on windows and windows in vm on linux )
> >>>instead of dualbooting.
> >Just out of curiosity.  Do you have some real data to back up this claim
> 
> Look at the top model section of [1] Virtual vs HW
...
> 
> 1. http://smolt.fedoraproject.org/static/stats/stats.html

You think that smolt data are representative?  I have serious doubts due
to a self-selection nature of these submissions; but at least these are
some numbers.

   Michal
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Problems with locales in F18

[Sergio]

> > You must be exporting it somewhere check .bash_profile
> etc for 
> > "en.UTF-8" ( which probably is supposed to be
> "en_US.utf8" )
> 
> No, not in my homedir. But found in /etc/locale.conf and in
> /etc/sysconfig/i18
> 

run localectl

('localectl list-locales' lists all valid locales)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 05:30 PM, Michal Jaegermann wrote:

On Fri, Nov 09, 2012 at 08:49:19AM +, "Jóhann B. Guðmundsson" wrote:

>
>I was saying today it's more common that people use vm ( In both
>direction linux in vm on windows and windows in vm on linux )
>instead of dualbooting.

Just out of curiosity.  Do you have some real data to back up this claim
or this is one of those made-up statistical statements based on an
negligible sample and wishful thinking?  From what a limited examples I
have seen I would say that vm use is nearly non-existent in a "general
population of Linux users" but I am not trying to affirm in public that
this is typical.


Look at the top model section of [1] Virtual vs HW

Virtual box 12723 + VMware 9990 + Parallels Virtual Platform, Bochs ( 
KVM ) 773 and  ( xen I believe ) 546  = 24032 vm
( of what I can identify as virtual solution out of it dont know the 
output from dmidecode on hyperv )


With VB and WMware only ( which can be considered running on Windows ) = 
22713 vm which are clearly dominating there on the top


1. http://smolt.fedoraproject.org/static/stats/stats.html
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Problems with locales in F18

[Joachim Backes]

On 11/09/2012 06:04 PM, "Jóhann B. Guðmundsson" wrote:
> On 11/09/2012 04:49 PM, Joachim Backes wrote:
>> Hi,
>>
>> if logging in on some tty, I always get the warnings:
>>
>> -bash: warning: setlocale: LC_CTYPE: cannot change locale (en.UTF-8): No
>> such file or directory
>> -bash: warning: setlocale: LC_COLLATE: cannot change locale (en.UTF-8):
>> No such file or directory
>> -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en.UTF-8):
>> No such file or directory
>> -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en.UTF-8):
>> No such file or directory
>> -bash: warning: setlocale: LC_TIME: cannot change locale (en.UTF-8): No
>> such file or directory
>>
>> How to get rid from this warning? I don't set any LC_... vars.
>>
>> The locale command outputs:
>>
>> locale
>>
>> LANG=en_US.utf8
>> LC_CTYPE="en_US.utf8"
>> LC_NUMERIC="en_US.utf8"
>> LC_TIME="en_US.utf8"
>> LC_COLLATE="en_US.utf8"
>> LC_MONETARY="en_US.utf8"
>> LC_MESSAGES="en_US.utf8"
>> LC_PAPER="en_US.utf8"
>> LC_NAME="en_US.utf8"
>> LC_ADDRESS="en_US.utf8"
>> LC_TELEPHONE="en_US.utf8"/etc/sysconfig/i18n/etc/sysconfig/i18n
>> LC_MEASUREMENT="en_US.utf8"
>> LC_IDENTIFICATION="en_US.utf8"
>> LC_ALL=en_US.utf8
>>
>> Kind regards
>>
> 
> You must be exporting it somewhere check .bash_profile etc for 
> "en.UTF-8" ( which probably is supposed to be "en_US.utf8" )

No, not in my homedir. But found in /etc/locale.conf and in
/etc/sysconfig/i18

> 
> JBG
> 


-- 
Joachim Backes 

https://www-user.rhrk.uni-kl.de/~backes
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Fedora 16 updates-testing report

[updates]

The following Fedora 16 Security updates need testing:
 Age  URL
   8  
https://admin.fedoraproject.org/updates/FEDORA-2012-17376/seamonkey-2.13.2-1.fc16
  48  
https://admin.fedoraproject.org/updates/FEDORA-2012-14452/bacula-5.0.3-33.fc16
   8  
https://admin.fedoraproject.org/updates/FEDORA-2012-17388/kdelibs-4.8.5-2.fc16
  21  
https://admin.fedoraproject.org/updates/FEDORA-2012-16415/389-ds-base-1.2.10.16-1.fc16
   7  
https://admin.fedoraproject.org/updates/FEDORA-2012-17482/plib-1.8.5-8.fc16
   5  
https://admin.fedoraproject.org/updates/FEDORA-2012-17588/catdoc-0.94.2-10.fc16
   5  
https://admin.fedoraproject.org/updates/FEDORA-2012-17553/libproxy-0.4.10-1.fc16
 126  
https://admin.fedoraproject.org/updates/FEDORA-2012-10314/revelation-0.4.14-1.fc16
  46  
https://admin.fedoraproject.org/updates/FEDORA-2012-14654/tor-0.2.2.39-1600.fc16
  27  
https://admin.fedoraproject.org/updates/FEDORA-2012-16032/cobbler-2.4.0-beta2.fc16
   1  
https://admin.fedoraproject.org/updates/FEDORA-2012-17746/libsocialweb-0.25.21-1.fc16
   1  
https://admin.fedoraproject.org/updates/FEDORA-2012-17745/icedtea-web-1.3.1-1.fc16
   9  
https://admin.fedoraproject.org/updates/FEDORA-2012-17291/thunderbird-16.0.2-1.fc16
   0  
https://admin.fedoraproject.org/updates/FEDORA-2012-17854/cumin-0.1.5522-4.fc16


The following Fedora 16 Critical Path updates have yet to be approved:
 Age URL
   1  
https://admin.fedoraproject.org/updates/FEDORA-2012-17746/libsocialweb-0.25.21-1.fc16
   1  
https://admin.fedoraproject.org/updates/FEDORA-2012-17755/NetworkManager-0.9.6.4-1.fc16
   1  
https://admin.fedoraproject.org/updates/FEDORA-2012-17766/coreutils-8.12-8.fc16
   3  
https://admin.fedoraproject.org/updates/FEDORA-2012-17660/gnutls-2.12.14-4.fc16
   5  
https://admin.fedoraproject.org/updates/FEDORA-2012-17572/libfm-1.1.0-1.fc16,pcmanfm-1.1.0-1.fc16
   5  
https://admin.fedoraproject.org/updates/FEDORA-2012-17553/libproxy-0.4.10-1.fc16
   8  
https://admin.fedoraproject.org/updates/FEDORA-2012-17403/fuse-2.8.7-2.fc16
   8  
https://admin.fedoraproject.org/updates/FEDORA-2012-17388/kdelibs-4.8.5-2.fc16
   9  
https://admin.fedoraproject.org/updates/FEDORA-2012-17291/thunderbird-16.0.2-1.fc16
   9  
https://admin.fedoraproject.org/updates/FEDORA-2012-17316/xdg-utils-1.1.0-0.14.20120809git.fc16
  10  https://admin.fedoraproject.org/updates/FEDORA-2012-17192/qt-4.8.3-7.fc16
  12  
https://admin.fedoraproject.org/updates/FEDORA-2012-17029/mdadm-3.2.6-1.fc16
The following builds have been pushed to Fedora 16 updates-testing

asterisk-1.8.18.0-1.fc16
cifs-utils-5.7-3.fc16
cumin-0.1.5522-4.fc16
drupal7-7.17-2.fc16
ibus-typing-booster-0.0.20-1.fc16
ipa-ex-mincho-fonts-002.01-1.fc16
mailx-12.5-4.fc16
perl-Imager-0.93-1.fc16
perl-Log-Any-Adapter-0.10-1.fc16
perl-Test-TCP-1.18-1.fc16
perl-Test-Taint-1.06-1.fc16
php-pirum-Pirum-1.1.4-2.fc16
php-twig-Twig-1.11.0-1.fc16
python-pyvfs-0.2.7-1.fc16
z88dk-1.10-1.fc16

Details about builds:



 asterisk-1.8.18.0-1.fc16 (FEDORA-2012-17870)
 The Open Source PBX

Update Information:

The Asterisk Development Team has announced the release of Asterisk 1.8.18.0.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk

The release of Asterisk 1.8.18.0 resolves several issues reported by the
community and would have not been possible without your participation.
Thank you!

The following is a sample of the issues resolved in this release:

* --- dsp.c User Configurable DTMF_HITS_TO_BEGIN and
  DTMF_MISSES_TO_END
  (Closes issue ASTERISK-17493. Reported by alecdavis)

* --- Fix error where improper IMAP greetings would be deleted.
  (Closes issue ASTERISK-20435. Reported by fhackenberger)

* --- iax2-provision: Fix improper return on failed cache retrieval
  (Closes issue ASTERISK-20337. Reported by John Covert)

* --- Fix T.38 support when used with chan_local in between.
  (Closes issue ASTERISK-20229. Reported by wdoekes)

* --- Fix an issue where media would not flow for situations where the
  legacy STUN code is in use.
  (Closes issue ASTERISK-20415. Reported by Michele Cicciotti)

For a full list of changes in this release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8.18.0

ChangeLog:

* Wed Nov  7 2012 Jeffrey Ollie  - 1.8.18.0-1:
- The Asterisk Development Team has announced the release of Asterisk 1.8.18.0.
- This release is available for immediate download at
- http://downloads.asterisk.org/pub/telephony/asterisk
-
- The release of Asterisk 1.8.18.0 resolves several issues reported by the
- community and would have not been possible without your participation.
- Thank you!
-
- The following is a sampl

Re: How to interpret F18 Blocker criterion

[Michal Jaegermann]

On Fri, Nov 09, 2012 at 08:49:19AM +, "Jóhann B. Guðmundsson" wrote:
> 
> I was saying today it's more common that people use vm ( In both
> direction linux in vm on windows and windows in vm on linux )
> instead of dualbooting.

Just out of curiosity.  Do you have some real data to back up this claim
or this is one of those made-up statistical statements based on an
negligible sample and wishful thinking?  From what a limited examples I
have seen I would say that vm use is nearly non-existent in a "general
population of Linux users" but I am not trying to affirm in public that
this is typical.

  Michal
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 18: No GDM on boot.

[Adam Jackson]

On 11/8/12 7:17 PM, Ankur Sinha wrote:

Hi folks,

My f18 system doesn't pull up a login screen on boot. It just waits.
Restarting the gdm.service from a virtual terminal gets it up though,
but I need to this at every boot now.

Here's the gdm.service status when it didn't come up:
http://paste.stg.fedoraproject.org/1590/

I checked the xorg logs as suggested. They seem to have nouveau related
issues:
http://paste.stg.fedoraproject.org/1592/


An excerpt:

/var/log/Xorg.1.log:[27.316] (EE) [drm] Could not set DRM device bus ID.

This is X's cryptic way of saying someone else already owns the DRM 
device.  Almost certainly plymouth.  What version of plymouth are you 
running?


- ajax
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Problems with locales in F18

[Jóhann B. Guðmundsson]

On 11/09/2012 04:49 PM, Joachim Backes wrote:

Hi,

if logging in on some tty, I always get the warnings:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (en.UTF-8): No
such file or directory
-bash: warning: setlocale: LC_COLLATE: cannot change locale (en.UTF-8):
No such file or directory
-bash: warning: setlocale: LC_MESSAGES: cannot change locale (en.UTF-8):
No such file or directory
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (en.UTF-8):
No such file or directory
-bash: warning: setlocale: LC_TIME: cannot change locale (en.UTF-8): No
such file or directory

How to get rid from this warning? I don't set any LC_... vars.

The locale command outputs:

locale

LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8

Kind regards



You must be exporting it somewhere check .bash_profile etc for 
"en.UTF-8" ( which probably is supposed to be "en_US.utf8" )


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Problems with locales in F18

[Joachim Backes]

Hi,

if logging in on some tty, I always get the warnings:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (en.UTF-8): No
such file or directory
-bash: warning: setlocale: LC_COLLATE: cannot change locale (en.UTF-8):
No such file or directory
-bash: warning: setlocale: LC_MESSAGES: cannot change locale (en.UTF-8):
No such file or directory
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (en.UTF-8):
No such file or directory
-bash: warning: setlocale: LC_TIME: cannot change locale (en.UTF-8): No
such file or directory

How to get rid from this warning? I don't set any LC_... vars.

The locale command outputs:

locale

LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8

Kind regards

-- 
Joachim Backes 

https://www-user.rhrk.uni-kl.de/~backes
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 03:52 PM, Matthew Miller wrote:

On Fri, Nov 09, 2012 at 03:31:23PM +, "Jóhann B. Guðmundsson" wrote:

Btw last time I check the cloud solution being deployed rank this...

Where were you checking?


Inhouse Gartner document which seems to be inline with the recent cloud 
survey from zenoss





1.VMware
2 Xen
3.KVM
4.HyperV

These are virtualization technologies, which are fundamental to cloud but
not in themselves cloud solutions.


We are talking about testing the virtualzation technologies not cloud 
solution or their providers





So that criteria only cover Xen but not the most used and deployed
cloud solution

Amazon EC2 is Xen-based. Rackspace uses KVM. (OpenStack.)


These are cloud providers using cloud solution on top of the 
virtualization technologies and our criteria should only cover running 
fedora as an guests and hosts ( server ) where applicable ( guest in 
vmware,xen,kvm,hyperv and server for kvm,xen ).


JBG

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Matthew Miller]

On Fri, Nov 09, 2012 at 03:31:23PM +, "Jóhann B. Guðmundsson" wrote:
> Btw last time I check the cloud solution being deployed rank this...

Where were you checking?

> 1.VMware
> 2 Xen
> 3.KVM
> 4.HyperV

These are virtualization technologies, which are fundamental to cloud but
not in themselves cloud solutions.

> So that criteria only cover Xen but not the most used and deployed
> cloud solution

Amazon EC2 is Xen-based. Rackspace uses KVM. (OpenStack.)




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 03:08 PM, Matthew Miller wrote:

On Fri, Nov 09, 2012 at 03:04:48PM +, "Jóhann B. Guðmundsson" wrote:

afaik we dont have any criteria that specifically deals with cloud bits

Final criterion #13.



Interesting which cloud access does QA have to actually test this stuff?

Btw last time I check the cloud solution being deployed rank this...

1.VMware
2 Xen
3.KVM
4.HyperV

So that criteria only cover Xen but not the most used and deployed cloud 
solution


JBG

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by mattdm):

 Thanks Kamil. That sounds reasonable. (Too bad trac doesn't have a
 "deferred" state.)

 It's my opinion that a few key things like this need to go in the release
 criteria because otherwise they have no teeth. There are plenty of other
 release criterion which could technically be fixed after the fact (like
 "no fuzzy menu items"). But I'm happy for FESCO to make the call.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Matthew Miller]

On Fri, Nov 09, 2012 at 03:04:48PM +, "Jóhann B. Guðmundsson" wrote:
> afaik we dont have any criteria that specifically deals with cloud bits

Final criterion #13.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 01:36 PM, Matthew Miller wrote:

On Fri, Nov 09, 2012 at 09:31:47AM +, "Jóhann B. Guðmundsson" wrote:

But: Which environments do we take into account? Carry this to
extremes: We also need to look at cloud infrastructure envs, which
are a special case of virtualization

The cloud community seems to be taking care of ensuring that Fedora
works in various cloud environments ( which is good ) so I dont
think that's something we have to worry about.

I hope the QA team keeps a _little_ bit of worry about it!



afaik we dont have any criteria that specifically deals with cloud bits

JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--

Comment (by kparal):

 Matthew, I read the document you linked, I saw that you created
 http://fedoraproject.org/wiki/SIGs/Minimal_Core and I saw you started
 discussion in devel list. Great job!

 I think you should create some high-level goals of your SIG (e.g. "No X
 libraries in the minimal system", maybe with some generic exceptions) and
 FESCo should bless it. The concrete issues would be then decided by the
 SIG according to this high-level goals, without bothering FESCo. This way
 QA have no say in what should and what should not be included, and that is
 the correct way, we don't want to have any decision powers here.

 Currently we often have too much power - we create release criteria (even
 though we try to get feedback from other teams), we find bugs in Fedora,
 and we decide whether the bug violates the criteria. It's similar to
 having a single entity to be a parliament, police and judge, all at once.
 And we all know that's not a good idea.

 So I'm very glad that you started the SIG. FESCo (and users of Fedora)
 will decide the high level goals (the parliament), we will be the police,
 and you will be the judges.

 Now, the core question still remains - should we have a release criteria
 matching your goals? I think we should first wait to see what requirements
 you come up with and then decide whether the requirements are hard
 blockers. Because we are trying to include only the important criteria
 that are _critical_ to making a Fedora release. And I'm not fully sure
 whether a package that got included in the minimal install and brings 10
 more X libraries as dependencies is a blocker or not. I guess
 cloud/rhev/similar people often use netinst/pxeboot installations and
 therefore some hiccups can be fixed even after release by editing
 comps.xml (comps are downloaded before installation, aren't they?).
 Therefore it might not be critical to stop the release. That doesn't mean
 we can't accept it as NTH and push the fix during freeze periods or
 something.

 I think this should get discussed when we have some tangible outputs from
 your new SIG. What do you think?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Matthew Miller]

On Fri, Nov 09, 2012 at 09:31:47AM +, "Jóhann B. Guðmundsson" wrote:
> >But: Which environments do we take into account? Carry this to
> >extremes: We also need to look at cloud infrastructure envs, which
> >are a special case of virtualization
> The cloud community seems to be taking care of ensuring that Fedora
> works in various cloud environments ( which is good ) so I dont
> think that's something we have to worry about.

I hope the QA team keeps a _little_ bit of worry about it!

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

F-18 Branched report: 20121109 changes

[Fedora Branched Report]

Compose started at Fri Nov  9 09:15:42 UTC 2012

Broken deps for x86_64
--
[dhcp-forwarder]
dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl
[dvipdfm]
dvipdfm-0.13.2d-44.fc18.x86_64 requires libkpathsea.so.4()(64bit)
[dvipdfmx]
dvipdfmx-0-0.35.20090708cvs.fc18.x86_64 requires 
libkpathsea.so.4()(64bit)
[dvipng]
dvipng-1.14-4.fc18.x86_64 requires libkpathsea.so.4()(64bit)
[dvisvgm]
dvisvgm-1.0.12-1.fc18.x86_64 requires libkpathsea.so.4()(64bit)
[libsyncml]
1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8
1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit)
[mftrace]
mftrace-1.2.15-8.fc18.x86_64 requires texlive-fonts
[mod_pubcookie]
mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 
0:20051115-x86-64
[openvrml]
libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
libopenvrml-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.i686 requires 
libboost_filesystem-mt.so.1.48.0
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
libopenvrml-gl-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-java-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-javascript-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-nodes-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_thread-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_system-mt.so.1.48.0()(64bit)
openvrml-xembed-0.18.9-3.fc18.x86_64 requires 
libboost_filesystem-mt.so.1.48.0()(64bit)
[perl-Hardware-Verilog-Parser]
perl-Hardware-Verilog-Parser-0.13-9.fc17.noarch requires 
perl(:MODULE_COMPAT_5.14.2)
[perl-OpenOffice-UNO]
perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires 
perl(:MODULE_COMPAT_5.14.2)
[pyfuzzy]
pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python
[python-flask]
1:python-flask-doc-0.9-1.fc18.noarch requires python-flask = 
0:0.9-1.fc18
[reciteword]
reciteword-0.8.4-10.fc18.x86_64 requires esound
[resource-agents]
resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit)
resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit)
[ruby-revolution]
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libedataserver-1.2.so.16()(64bit)
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libecal-1.2.so.12()(64bit)
ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires 
libebook-1.2.so.13()(64bit)
[rubygem-calendar_date_select]
rubygem-calendar_date_select-1.15-6.fc17.noarch requires ruby(abi) = 
0:1.8
[rubygem-linecache]
rubygem-linecache-0.43-5.fc17.x86_64 requires ruby(abi) = 0:1.8
rubygem-linecache-0.43-5.fc17.x86_64 requires libruby.so.1.8()(64bit)
[rubygem-ruby-debug]
rubygem-ruby-debug-0.10.5-0.3.rc1.fc17.1.noarch requires ruby(abi) = 
0:1.8
[rubygem-ruby-debug-base]
rubygem-ruby-debug-base-0.10.5-0.1.rc1.fc17.1.x86_64 requires ruby(abi) 
= 0:1.8
rubygem-ruby-debug-base-0.10.5-0.1.rc1.fc17.1.x86_64 requires 
libruby.so.1.8()(64bit)
[tetex-tex4ht]
tetex-tex4ht-1.0.2008_09_16_1413-10.fc18.x86_64 requires 
libkpathsea.so.4()(64bit)
[xdvik]
xdvik-22.84.14-12.fc18.x86_64 requires libkpathsea.so.4()(64bit)
[xdvipdfmx]
xdvipdfmx-0.4-9.fc18.x86_64 requires libkpathsea.so.4()(64bit)
[znc-infobot]
znc-infobot-0.206-2.fc18.x86_64 requires znc = 0:0.206



Broken deps for i386
-

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 09:01 AM, Matthias Runge wrote:

On 11/09/2012 09:49 AM, "Jóhann B. Guðmundsson" wrote:



But as has been pointed out why aren't we testing and ensuring that
Fedora runs well in vmware,hyperv and virtualbox since we ensure it
works well being dualbooted alongside windows?

JBG
OK, agreed. It seems common, to run Fedora also in any kind of 
virtualization environment. So, we're also interested in a good user 
experience there (whatever this may include).


But: Which environments do we take into account? Carry this to 
extremes: We also need to look at cloud infrastructure envs, which are 
a special case of virtualization


The cloud community seems to be taking care of ensuring that Fedora 
works in various cloud environments ( which is good ) so I dont think 
that's something we have to worry about.


What worries me more is the *mixed* signal we keep sending both in 
criteria and on blocker bug meetings and that's something I feel we need 
to fix.


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Matthias Runge]

On 11/09/2012 09:49 AM, "Jóhann B. Guðmundsson" wrote:



But as has been pointed out why aren't we testing and ensuring that
Fedora runs well in vmware,hyperv and virtualbox since we ensure it
works well being dualbooted alongside windows?

JBG
OK, agreed. It seems common, to run Fedora also in any kind of 
virtualization environment. So, we're also interested in a good user 
experience there (whatever this may include).


But: Which environments do we take into account? Carry this to extremes: 
We also need to look at cloud infrastructure envs, which are a special 
case of virtualization

--
Matthias Runge 
   
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: How to interpret F18 Blocker criterion

[Jóhann B. Guðmundsson]

On 11/09/2012 07:49 AM, Matthias Runge wrote:

On 11/09/2012 01:01 AM, "Jóhann B. Guðmundsson" wrote:


In today's age it's become more common to just run GNU/Linux in a vm
since more or less all hw you buy this day has a virtual capable cpu
instead of jumping through the partitioning hoops and loose the warranty
and support while you are at it and yeah one of the fundamental things
users like and have to do is to upgrade their computers and devices
firmware and even now in the 21 century it cant be done in GNU/Linux
with an ease...
Do I understand you right, that you're suggesting to run Linux in a vm 
instead of real hardware? Because it's the 21st century and we would 
loose warranty?


N!, right?


If I was asked I would actual respond that way if it voids people 
warranty or OS support.

If those have expired then it's an whole different ball game...



We definitely need to ensure, Fedora runs quite well as dual boot 
installation.


I was saying today it's more common that people use vm ( In both 
direction linux in vm on windows and windows in vm on linux ) instead of 
dualbooting.


But as has been pointed out why aren't we testing and ensuring that 
Fedora runs well in vmware,hyperv and virtualbox since we ensure it 
works well being dualbooted alongside windows?


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test