Re: [rawhide] install method testing wanted

[Ankur Sinha]

On Tue, 2013-03-05 at 23:56 -0800, Adam Williamson wrote:
> do you 
> have any suggestions for clarifying the text?

Maybe just mentioning the method John used? I could add it but I'm not
really sure how it works:

The url just needs to point to a directory with repodata in it? Does
this then become the only repository? Can you add stuff like rpmfusion
like this? etc.

Might lead to more confusion too.. 
-- 
Thanks, 
Warm regards,
Ankur: "FranciscoD"

Please only print if necessary. 

Looking to contribute to Fedora? Look here: 
https://fedoraproject.org/wiki/Fedora_Join_SIG

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Proposed dates for Fedora 19 image composes

[Adam Williamson]

Hi, folks. There was some discussion of this at the meeting on Monday, 
but no-one really gave much input, so I wanted to run these ideas by the 
list before we commit to them. Let's look at the image compose schedule 
for F19.


As things stand, the F19 calendar - 
http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html - 
still has the Acceptance Test Plan milestones in it. As with F18, we 
should probably take most of these out: we agreed to replace them with 
TCs a couple of releases back, and that has been working out fine. We 
can keep one, pre-Alpha, for a quick 'sanity check' run - for someone to 
spin up a boot.iso and file whatever showstoppers it inevitably 
contains, just ahead of the TC date.


We should also drop the specific 'Test (milestone) Candidate' dates - we 
don't really schedule RCs, we simply start building them as soon as 
possible after the change deadline, once blocker bugs are addressed. The 
date serves no purpose.


So looking back at the schedule we wound up using for F17:

https://lists.fedoraproject.org/pipermail/test/2011-November/104583.html

We pretty much went with 'three weeks between TC1 and Go/No-Go'. I think 
we should go with that again for F19. (We more or less did the same for 
F18, but I'm not sure we updated the official schedule, and we pretty 
much did wall-to-wall TCs from Beta till Final).


So here's what I'd propose as the dates for the F19 schedule:

Pre-Alpha Rawhide Acceptance Test Plan #1   Thu 2013-03-14
Test Alpha 'Test Compose'   Tue 2013-03-19
Fedora 19 Alpha Go/No-Go Meeting (17:00 US Eastern) Wed 2013-04-10

Test Beta 'Test Compose'Tue 2013-04-23
Fedora 19 Beta Go/No-Go Meeting (17:00 US Eastern)  Wed 2013-05-15

Test 'Final' Test Compose (TC)  Tue 2013-05-28
Fedora 19 Final Go/No-Go Meeting (17:00 US Eastern) Tue 2013-06-18

The entries "Pre-Alpha Rawhide Acceptance Test Plan #2", "Pre-Alpha 
Rawhide Acceptance Test Plan #3", "Test Alpha Candidate", "Pre-Beta 
Acceptance Test Plan", "Test Beta Candidate", "Pre-RC Acceptance Test 
Plan" and "Test 'Final' RC" can be dropped.


As a side note for Jaroslav, there are some odd discrepancies between 
the wording of the Alpha and Beta entries and the wording of the Final 
entries.


This schedule would give us 13 days till the first TC, folks, so time to 
get those pre-validation-cycle changes in! Yes, I know I'm the worst 
offender here - I still have some major criteria changes that I _really_ 
need to finish up and propose this week.

--
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: Proposed changes to blocker bug meeting processes

[Adam Williamson]

On 21/02/13 01:11 AM, Jaroslav Reznik wrote:

- Original Message -

We discussed a few possible changes to the blocker bug meeting
process
at the QA meeting this week. It was agreed that I'd draft up these
changes for list discussion. So here they are! Sent to test@ and
devel@
as QA, devel and releng are the stakeholders in this process: I'm
figuring releng folks are all subscribed to one list or the other.

https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_meeting
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_process


As it did these moves during F18 cycle, it makes sense. Also I hope F19
won't be such beast as F18 (yeah, hope :D). With automatic blocker status
for specific bug types, I think we are going the good direction! Thanks
guys!


Thanks for the feedback, Jaro and others. As per the discussion at the 
meeting on Monday, I've gone ahead and put these changes into 
production. So everyone remember to use #fedora-blocker-review for the 
next blocker meeting :)

--
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

2013-03-04 - Fedora QA Meeting - recap

[Adam Williamson]

As always, minutes and IRC transcript available on the wiki at
https://fedoraproject.org/wiki/QA/Meetings/20130304

Next meeting is scheduled for 2013-03-11 at 1600 UTC in #fedora-meeting. 
If you have topics you think we should bring up at the

meeting, please add them to the Wiki page at
https://fedoraproject.org/wiki/QA/Meetings/20130311 . Thanks!

TOPIC: Previous meeting follow-up
===
* adamw to push 'automatic blocker' proposal to production -
  this was done[1]
* adamw to try and gather a bit more feedback on blocker
  process changes this week - dgilmore is okay with the
  changes, no objections from devel or fesco
* viking-ice or adamw to file a trac ticket for the smoke
  test-for-spins idea - not done yet, put back on the agenda
  for next week
* tflink to take a look at the question of tracking qa tool
  discussion and bugs/tickets and make a broad proposal about
  what to do - proposals made[2] and discussion is underway
  * We agreed to go with the simplest option of keeping one
trac instance and CCing ticket mails to the appropriate
list with the defaultcc plugin
* viking-ice noted he is working on a proposal to replace trac
  with rt[3]

TOPIC: Test Days
===
* After discussion of the pros and cons, we decided to make it
  clearer that test days can happen on any day (not just
  Thursdays)
* Other proposed topics left till next week

TOPIC: Open floor
===
* jreznik changed the QA calendar for F19[4] to show blocker
  meetings on Wednesdays
* We noted that blocker bug meetings should be starting up
  already, and discussed scheduling of RATS and TC composes

ACTION ITEMS
===
* adamw to push the blocker meeting changes live this week
* viking-ice or adamw to file a trac ticket for the smoke
  test-for-spins idea
* adamw to propose RATS/TC1 dates on the list
* tflink to announce first blocker meeting for wednesday, and
  get blocker bug tracker app ready
* jreznik to pencil in QA changes as discussed
* adamw to draft up changes to the test day process docs to
  accommodate test days being on any day, test day co-ordinator
  to ensure they're balanced out

1. https://lists.fedoraproject.org/pipermail/test/2013-February/114004.html
2. https://lists.fedoraproject.org/pipermail/test/2013-February/113997.html
3. http://www.bestpractical.com/rt/
4. http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.ne
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: upgrade to rawhide how

[Andre Robatino]

Adam Williamson  redhat.com> writes:

> It's very unusual for issues with completely different generations of 
> adapter to be the same, as so much of the code to support different 
> adapters is...different. It's almost out of the realm of possibility 
> that there's a bug that affects your adapter and my adapter - but not 
> many other adapters - that somehow affected yours at kernel 3.8 and mine 
> at kernel 3.9. That would be a hell of a heisenbug :)

Mine started being affected at 3.7, actually. Only 3.6.11 and the original
3.6.10 work.



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

Re: Urgent: Fedora 18 update breaks mount.cifs

[Adam Williamson]

On 06/03/13 04:30 PM, Chuck Forsberg WA7KGX N2469R wrote:

On 03/06/2013 01:59 PM, Adam Williamson wrote:

On 06/03/13 03:22 AM, Chuck Forsberg WA7KGX N2469R wrote:


It broke for me. It was coincident with the change from kernel 3.7.9
to 3.8.1 but I didn't investigate if this was the cause.

Adding a "sec=" option with either ntlm or ntlmv2 worked for me.
Slightly odd given that the man page says ntlm is the default.

Digging a little more, a possibly relevant kernel commit from
2012-11-25 has the comment "default authentication needs to be at
least ntlmv2 security for cifs mounts":
-#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM |
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
+#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP)

--
Paul



The "sec=ntlm" magic chant does the trick.   Flag Day overcome. Thnx.


Oh, sorry guys - I knew about that one, but I got a different error
message from you, so I assumed it was a different bug.

Apparently, NTLM has been found to be insecure so upstream doesn't
want to allow NTLM connections by default any more. There may be
something you can do at the server end to use NTLMv2 instead; that
would probably be safer than forcing the use of NTLM.

I'm using a NAS box with very limited configuration options so I'm
stuck with NTLM, but if you're using an actual Windows machine as the
host, you can probably fix it.

We should probably throw this in common bugs, now three people have
hit it...

I tried all the sec= options given in "man mount.cifs".  The only one
that worked was ntlm.
This is with a fully patched 64 bit Win 7 home premium on the local
network.

If the main purpose of mount.cifs is to mount Microsoft Windows shares,
a default that actually works
with the dominant Windows would be useful.


Again, there are many configuration options for the server end of CIFS 
shares. You can't assume 'Windows 7' is just a Thing and all Windows 7 
CIFS shares behave exactly the same, because they don't.

--
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: upgrade to rawhide how

[Adam Williamson]

On 06/03/13 02:53 PM, Andre Robatino wrote:

Adam Williamson  redhat.com> writes:


On 06/03/13 01:10 AM, Andre Robatino wrote:

Adam Williamson  redhat.com> writes:


(Current Rawhide kernels die as soon as modesetting kicks in, for me, on
a Geforce 9600 GT. I need to get around to triaging it.)


Is what you're talking about anything like
https://bugzilla.redhat.com/show_bug.cgi?id=901816 ? I've been having that
problem on F18 for a while with a GeForce 6150SE nForce 430.


No, it only showed up since the 3.9 DRM merge. (3.9 kernels before the
DRM merge work, but once or twice a day I get a big kernel oops and the
system dies; 3.8 kernels work fine.)


Okay, but I thought the same exact problem might have appeared much earlier with
the GeForce 6, since they don't get as much attention. (The fact that no one
else seems to have reported the problem seems to confirm that - either that or
everyone is using the nvidia driver as a workaround.)


It's very unusual for issues with completely different generations of 
adapter to be the same, as so much of the code to support different 
adapters is...different. It's almost out of the realm of possibility 
that there's a bug that affects your adapter and my adapter - but not 
many other adapters - that somehow affected yours at kernel 3.8 and mine 
at kernel 3.9. That would be a hell of a heisenbug :)

--
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: Urgent: Fedora 18 update breaks mount.cifs

[Chuck Forsberg WA7KGX N2469R]

On 03/06/2013 01:59 PM, Adam Williamson wrote:

On 06/03/13 03:22 AM, Chuck Forsberg WA7KGX N2469R wrote:


It broke for me. It was coincident with the change from kernel 3.7.9
to 3.8.1 but I didn't investigate if this was the cause.

Adding a "sec=" option with either ntlm or ntlmv2 worked for me.
Slightly odd given that the man page says ntlm is the default.

Digging a little more, a possibly relevant kernel commit from
2012-11-25 has the comment "default authentication needs to be at
least ntlmv2 security for cifs mounts":
-#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM |
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
+#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP)

--
Paul



The "sec=ntlm" magic chant does the trick.   Flag Day overcome. Thnx.


Oh, sorry guys - I knew about that one, but I got a different error 
message from you, so I assumed it was a different bug.


Apparently, NTLM has been found to be insecure so upstream doesn't 
want to allow NTLM connections by default any more. There may be 
something you can do at the server end to use NTLMv2 instead; that 
would probably be safer than forcing the use of NTLM.


I'm using a NAS box with very limited configuration options so I'm 
stuck with NTLM, but if you're using an actual Windows machine as the 
host, you can probably fix it.


We should probably throw this in common bugs, now three people have 
hit it...
I tried all the sec= options given in "man mount.cifs".  The only one 
that worked was ntlm.

This is with a fully patched 64 bit Win 7 home premium on the local network.

If the main purpose of mount.cifs is to mount Microsoft Windows shares, 
a default that actually works

with the dominant Windows would be useful.

--
 Chuck Forsberg WA7KGX   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

Fedora 17 updates-testing report

[updates]

The following Fedora 17 Security updates need testing:
 Age  URL
 243  
https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17
  85  
https://admin.fedoraproject.org/updates/FEDORA-2012-20092/libproxy-0.4.11-1.fc17
  60  
https://admin.fedoraproject.org/updates/FEDORA-2013-0210/vdsm-4.10.0-13.fc17
  60  
https://admin.fedoraproject.org/updates/FEDORA-2013-0231/ca-certificates-2012.87-1.fc17
  56  
https://admin.fedoraproject.org/updates/FEDORA-2013-0455/fedora-business-cards-1-0.1.beta1.fc17
  42  
https://admin.fedoraproject.org/updates/FEDORA-2013-1286/python-tw2-jquery-2.0.3-5.fc17
  33  
https://admin.fedoraproject.org/updates/FEDORA-2013-1804/coreutils-8.15-10.fc17
  26  
https://admin.fedoraproject.org/updates/FEDORA-2013-2143/rubygem-rdoc-3.12-5.fc17
  26  https://admin.fedoraproject.org/updates/FEDORA-2013-2023/tor-0.2.3.25-1700
  22  
https://admin.fedoraproject.org/updates/FEDORA-2013-2315/rubygem-rack-1.4.0-4.fc17
  13  https://admin.fedoraproject.org/updates/FEDORA-2013-2789/yum-3.4.3-31.fc17
  13  
https://admin.fedoraproject.org/updates/FEDORA-2013-2793/openssl-1.0.0k-1.fc17
  11  
https://admin.fedoraproject.org/updates/FEDORA-2013-2874/Django-1.4.5-1.fc17
  11  
https://admin.fedoraproject.org/updates/FEDORA-2013-2845/bugzilla-4.0.10-1.fc17
  10  
https://admin.fedoraproject.org/updates/FEDORA-2013-2984/libtasn1-2.14-1.fc17,gnutls-2.12.23-1.fc17
   7  
https://admin.fedoraproject.org/updates/FEDORA-2013-3079/nss-3.14.3-1.fc17,nss-softokn-3.14.3-1.fc17,nss-util-3.14.3-1.fc17,nspr-4.9.5-2.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3252/kernel-3.7.10-101.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3259/crypto-utils-2.4.1-39.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3270/sudo-1.8.6p7-1.fc17
   2  
https://admin.fedoraproject.org/updates/FEDORA-2013-3382/zfs-fuse-0.7.0-3.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3437/euca2ools-2.1.3-1.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3116/krb5-1.10.2-9.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3227/mediawiki-1.19.4-1.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3438/mingw-gnutls-2.12.23-1.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3439/telepathy-gabble-0.16.5-1.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3443/perl-5.14.3-223.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3457/poppler-0.18.4-4.fc17


The following Fedora 17 Critical Path updates have yet to be approved:
 Age URL
 196  
https://admin.fedoraproject.org/updates/FEDORA-2012-12509/PackageKit-0.7.6-1.fc17
  26  
https://admin.fedoraproject.org/updates/FEDORA-2013-2065/abrt-2.1.0-1.fc17,libreport-2.1.0-2.fc17
  25  
https://admin.fedoraproject.org/updates/FEDORA-2013-2163/policycoreutils-2.1.13-27.3.fc17
  13  https://admin.fedoraproject.org/updates/FEDORA-2013-2789/yum-3.4.3-31.fc17
  13  
https://admin.fedoraproject.org/updates/FEDORA-2013-2793/openssl-1.0.0k-1.fc17
  11  https://admin.fedoraproject.org/updates/FEDORA-2013-2858/orc-0.4.17-2.fc17
  10  
https://admin.fedoraproject.org/updates/FEDORA-2013-2984/libtasn1-2.14-1.fc17,gnutls-2.12.23-1.fc17
   7  
https://admin.fedoraproject.org/updates/FEDORA-2013-3119/python-pycurl-7.19.0-11.fc17
   7  
https://admin.fedoraproject.org/updates/FEDORA-2013-3079/nss-3.14.3-1.fc17,nss-softokn-3.14.3-1.fc17,nss-util-3.14.3-1.fc17,nspr-4.9.5-2.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3304/libvpx-1.2.0-1.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3276/createrepo-0.9.9-12.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3252/kernel-3.7.10-101.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-3270/sudo-1.8.6p7-1.fc17
   3  https://admin.fedoraproject.org/updates/FEDORA-2013-3360/qt-4.8.4-14.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3494/iproute-3.3.0-6.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3466/selinux-policy-3.10.0-168.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3443/perl-5.14.3-223.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-3435/python-bugzilla-0.8.0-2.fc17


The following builds have been pushed to Fedora 17 updates-testing

appmenu-qt-0.2.6-3.fc17
bmake-20130123-1.fc17
gnome-games-3.4.2-2.fc17
iproute-3.3.0-6.fc17
krb5-1.10.2-9.fc17
mingw-eigen3-3.1.2-1.fc17
miniupnpc-1.6-9.fc17
shinken-1.2.4-2.fc17
splix-2.0.1-0.13.20121128svn.fc17
wbox-5-5.fc17
zeroinstall-injector-2.0-1.fc17

Details about builds:



 appmenu-qt-0.2.6-3.fc17 (FEDORA-2013-3486)
 Global application menu to Qt

Update Information:

This package allows Qt to export its menus over DBus
-

Re: upgrade to rawhide how

[Andre Robatino]

Adam Williamson  redhat.com> writes:

> On 06/03/13 01:10 AM, Andre Robatino wrote:
> > Adam Williamson  redhat.com> writes:
> >
> >> (Current Rawhide kernels die as soon as modesetting kicks in, for me, on
> >> a Geforce 9600 GT. I need to get around to triaging it.)
> >
> > Is what you're talking about anything like
> > https://bugzilla.redhat.com/show_bug.cgi?id=901816 ? I've been having that
> > problem on F18 for a while with a GeForce 6150SE nForce 430.
> 
> No, it only showed up since the 3.9 DRM merge. (3.9 kernels before the 
> DRM merge work, but once or twice a day I get a big kernel oops and the 
> system dies; 3.8 kernels work fine.)

Okay, but I thought the same exact problem might have appeared much earlier with
the GeForce 6, since they don't get as much attention. (The fact that no one
else seems to have reported the problem seems to confirm that - either that or
everyone is using the nvidia driver as a workaround.)



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

Re: Urgent: Fedora 18 update breaks mount.cifs

[Adam Williamson]

On 06/03/13 03:22 AM, Chuck Forsberg WA7KGX N2469R wrote:


It broke for me. It was coincident with the change from kernel 3.7.9
to 3.8.1 but I didn't investigate if this was the cause.

Adding a "sec=" option with either ntlm or ntlmv2 worked for me.
Slightly odd given that the man page says ntlm is the default.

Digging a little more, a possibly relevant kernel commit from
2012-11-25 has the comment "default authentication needs to be at
least ntlmv2 security for cifs mounts":
-#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM |
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
+#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP)

--
Paul



The "sec=ntlm" magic chant does the trick.   Flag Day overcome. Thnx.


Oh, sorry guys - I knew about that one, but I got a different error 
message from you, so I assumed it was a different bug.


Apparently, NTLM has been found to be insecure so upstream doesn't want 
to allow NTLM connections by default any more. There may be something 
you can do at the server end to use NTLMv2 instead; that would probably 
be safer than forcing the use of NTLM.


I'm using a NAS box with very limited configuration options so I'm stuck 
with NTLM, but if you're using an actual Windows machine as the host, 
you can probably fix it.


We should probably throw this in common bugs, now three people have hit 
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: upgrade to rawhide how

[Adam Williamson]

On 06/03/13 01:10 AM, Andre Robatino wrote:

Adam Williamson  redhat.com> writes:


(Current Rawhide kernels die as soon as modesetting kicks in, for me, on
a Geforce 9600 GT. I need to get around to triaging it.)


Is what you're talking about anything like
https://bugzilla.redhat.com/show_bug.cgi?id=901816 ? I've been having that
problem on F18 for a while with a GeForce 6150SE nForce 430.


No, it only showed up since the 3.9 DRM merge. (3.9 kernels before the 
DRM merge work, but once or twice a day I get a big kernel oops and the 
system dies; 3.8 kernels work fine.)

--
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

Today's rawhide

[Chuck Forsberg WA7KGX N2469R]

Installed with F18 anaconda from local rawhide mirror using pxeboot:

Gnome still dies with something gone wrong.

KDE install crashes Anaconda if too much asked for.
A less ambitious install yields a functioning KDE desktop.
(I disable selinux and rhgb quiet)
I was then able to install xfce.

--
 Chuck Forsberg WA7KGX   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: Mesa 9.0.3 update

[drago01]

On Wed, Mar 6, 2013 at 4:52 PM, Michael Cronenworth  wrote:
> His reason for defending software
> patents? Money.

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

Re: Mesa 9.0.3 update

[Michael Cronenworth]

Adam Jackson wrote:
> We've asked our lawyers.  If and when they give the go-ahead, we'll
> enable it.  If they don't, we won't.

Thanks.

> Feel free to ask your congressman why it's at all sane to allow someone
> to patent using floats instead of ints for representing colors.

I ran into a patent attorney here in Texas last year. You probably know
Texas is the patent troll homeworld. His reason for defending software
patents? Money.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Mesa 9.0.3 update

[Adam Jackson]

On Wed, 2013-03-06 at 09:03 -0600, Michael Cronenworth wrote:
> Adam Jackson wrote:
> > The smiley does not make this less condescending.
> >
> > We will be updating Mesa aggressively.  I said as much on the phone to
> > Valve last week.
> 
> I asked this on the legal list but did not receive a response.
> 
> What's the status of enabling the floating-point features in Mesa? It
> prevents OpenGL 3+ from being advertised.

We've asked our lawyers.  If and when they give the go-ahead, we'll
enable it.  If they don't, we won't.

Feel free to ask your congressman why it's at all sane to allow someone
to patent using floats instead of ints for representing colors.

- ajax

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

Re: Mesa 9.0.3 update

[Michael Cronenworth]

Adam Jackson wrote:
> The smiley does not make this less condescending.
>
> We will be updating Mesa aggressively.  I said as much on the phone to
> Valve last week.

I asked this on the legal list but did not receive a response.

What's the status of enabling the floating-point features in Mesa? It
prevents OpenGL 3+ from being advertised.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Mesa 9.0.3 update

[Jóhann B. Guðmundsson]

On 03/06/2013 02:57 PM, Adam Jackson wrote:

On Wed, 2013-03-06 at 14:50 +, "Jóhann B. Guðmundsson" wrote:


Well they kinda need to rethink how they are handling this due to steam
and all ;)

The smiley does not make this less condescending.


Not meant to be condescending at all

JBG

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

Re: Mesa 9.0.3 update

[Adam Jackson]

On Wed, 2013-03-06 at 14:50 +, "Jóhann B. Guðmundsson" wrote:

> Well they kinda need to rethink how they are handling this due to steam 
> and all ;)

The smiley does not make this less condescending.

We will be updating Mesa aggressively.  I said as much on the phone to
Valve last week.

- ajax

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

Re: Mesa 9.0.3 update

[Jóhann B. Guðmundsson]

On 03/06/2013 07:47 AM, Adam Williamson wrote:

On 03/03/13 04:28 AM, Eduardo Jorge wrote:

It's very important to update Mesa from version 9.0.0 to 9.0.3.
Versions 9.0.1, 9.0.2 and 9.0.3 accumulate a lot of bug fixes.
Thank you.


Fedora's graphics stack maintainers are deeply involved in the 
maintenance of the kernel, X, and mesa. You don't really need to 
request updates. Where they're appropriate, they will happen.




Well they kinda need to rethink how they are handling this due to steam 
and all ;)


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

rawhide report: 20130306 changes

[Fedora Rawhide Report]

Compose started at Wed Mar  6 08:15:15 UTC 2013

Broken deps for x86_64
--
[HippoDraw]
HippoDraw-python-1.21.3-6.fc19.x86_64 requires 
libboost_python.so.1.50.0()(64bit)
[condor]
condor-plumage-7.9.1-0.1.fc19.4.x86_64 requires 
libboost_system.so.1.50.0()(64bit)
[connman]
connman-1.5-4.fc19.i686 requires libxtables.so.7
connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit)
[couchdb]
couchdb-1.2.1-2.fc19.x86_64 requires libicuuc.so.49()(64bit)
couchdb-1.2.1-2.fc19.x86_64 requires libicui18n.so.49()(64bit)
couchdb-1.2.1-2.fc19.x86_64 requires libicudata.so.49()(64bit)
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[epiphany-extensions]
epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6
[fawkes]
fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5
fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit)
fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2
fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires 
libclipsmm.so.2()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libgeos-3.3.6.so()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_signals-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
[fcitx-keyboard]
fcitx-keyboard-0.1.3-1.fc18.x86_64 requires libicuuc.so.49()(64bit)
[fcitx-libpinyin]
fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires 
libpinyin.so.2(LIBPINYIN)(64bit)
fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2()(64bit)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[freeipa]
freeipa-server-strict-3.1.2-3.fc19.x86_64 requires krb5-server = 0:1.11
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gdcm]
gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26
gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit)
[gedit-valencia]
gedit-valencia-0.3.0-11.20120430gite8a0f500555be.fc18.x86_64 requires 
libvala-0.18.so.0()(64bit)
[gnome-applets]
1:gnome-applets-3.5.92-3.fc18.x86_64 requires 
libgweather-3.so.1()(64bit)
[gnome-panel]
gnome-panel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5
gnome-panel-devel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
[grass]
grass-6.4.2-7.fc19.x86_64 requires libgeos-3.3.7.so()(64bit)
grass-libs-6.4.2-7.fc19.i686 requires libgeos-3.3.7.so
grass-libs-6.4.2-7.fc19.x86_64 requires libgeos-3.3.7.so()(64bit)
[jetty]
jetty-annotations-9.0.0-0.2.RC2.fc19.noarch requires 
mvn(org.eclipse.jetty.orbit:org.objectweb.asm)
jetty-annotations-9.0.0-0.2.RC2.fc19.noarch requires 
mvn(org.eclipse.jetty.orbit:javax.annotation)
jetty-jndi-9.0.0-0.2.RC2.fc19.noarch requires 
mvn(org.eclipse.jetty.orbit:javax.mail.glassfish)
jetty-jsp-9.0.0-0.2.RC2.fc19.noarch requires 
mvn(org.eclipse.jetty.orbit:org.apache.taglibs.standard.glassfish)
jetty-jsp-9.0.0-0.2.RC2.fc19.noarch requires 
mvn(org.eclipse.jetty.orbit:javax.servlet.jsp.jstl)
jetty-jsp-9.0.0-0.2.RC2.fc19.noarch requires 
mvn(org.eclipse.jetty.orbit:com.sun.el)
[kdevelop-python]
kdevelop-python-1.4.1-2.fc19.i686 requires libpython2.7-kdevelop.so.1.0
kdevelop-python-1.4.1-2.fc19.x86_64 requires 
libpython2.7-kdevelop.so.1.0()(64bit)
[libgda]
1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit)
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-uml-0.3.0-3.fc19.i686 requires 

Re: Mesa 9.0.3 update

[Kevin DeKorte]

Adam,

Would it be possible to put mesa on a faster update cycle within Fedora?
For example I find the kernel may get several updates during the lifetime
of a release, but mesa will stay at the major release that was available. I
found myself upgrading to F18 from F17 because I wanted some of the
features found in mesa 9 that were not in mesa 8. And Fedora 19 already has
mesa 9.1 available, but I expect that F18 will not get mesa 9.1. Since mesa
has all the 3d drivers in it along with the kernel and libdrm, it makes
sense to update it more rapidly as it is like updating the video driver on
a windows machine. If the kernel was not being updated rapidly, I would not
ask this, but since the kernel half of the drivers is being updated it
makes since to do the other half too.

Kevin


On Wed, Mar 6, 2013 at 12:47 AM, Adam Williamson wrote:

> On 03/03/13 04:28 AM, Eduardo Jorge wrote:
>
>> It's very important to update Mesa from version 9.0.0 to 9.0.3.
>> Versions 9.0.1, 9.0.2 and 9.0.3 accumulate a lot of bug fixes.
>> Thank you.
>>
>
> Fedora's graphics stack maintainers are deeply involved in the maintenance
> of the kernel, X, and mesa. You don't really need to request updates. Where
> they're appropriate, they will happen.
>
> http://koji.fedoraproject.org/**koji/buildinfo?buildID=400171
> --
> 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
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

RE: Rawhide installer and partitioning

[Joseph L. Casale]

> We'd need more details on the failure, but in general terms, Rawhide's 

> installer is having a lot of work done on it right now, it's not
> surprising that it's busted, and individual bugs don't necessarily need
> reporting at this time, as the code (particularly partitioning stuff) is
> under constant revision. It might be best to wait till things calm down
> a little before filing specific bugs.


I have a 1/2 TB disc with a couple partitions up front for windows.
Booting the last bootable live composition and trying to choose an
automatic partitioning scheme suggests there is no room.


> If you have time to drop by
> #anaconda you might be able to run your issue by the team there
> informally though, and check if it's something they're aware of.


I'll certainly head over there this morning as soon as I can, thanks!

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

Re: Urgent: Fedora 18 update breaks mount.cifs

[Chuck Forsberg WA7KGX N2469R]

On 03/06/2013 01:49 AM, Paul Black wrote:
On 6 March 2013 06:04, Ed Greshko > wrote:


On 03/06/13 13:27, Chuck Forsberg WA7KGX N2469R wrote:
> After a routine yum update at omen.com ,
> the previously reported mount.cifs breakage has spread from
rawhide to Fedora 18.
>
> It gives:
> mount error(22): Invalid argument
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>
> man mount.cifs has not changed at all.
>
> Is this botch breakage or an unannounced flag day???
>
> The bugzilla reporting tool would not allow me to generate a new
report.
>

Can we assume you are talking about a "clean" F18 system?  Any
reason not to post in the "users" mailing list?

FWIW.

[egreshko@meimei ~]$ pwd
/home/egreshko
[egreshko@meimei ~]$ ls silly
[egreshko@meimei ~]$ sudo mount -t cifs //silly/Pictures
/home/egreshko/silly -o
gid=egreshko,uid=egreshko,password=xx,username=xx
[egreshko@meimei ~]$ ls silly
2010_12_12  desktop.ini  iPod Photo Cache  Nokia  tiffs  x
[egreshko@meimei ~]$ uname -r
3.8.1-201.fc18.x86_64

I see no "breakage".


It broke for me. It was coincident with the change from kernel 3.7.9 
to 3.8.1 but I didn't investigate if this was the cause.


Adding a "sec=" option with either ntlm or ntlmv2 worked for me. 
Slightly odd given that the man page says ntlm is the default.


Digging a little more, a possibly relevant kernel commit from 
2012-11-25 has the comment "default authentication needs to be at 
least ntlmv2 security for cifs mounts":
-#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM | 
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)

+#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP)

--
Paul



The "sec=ntlm" magic chant does the trick.   Flag Day overcome. Thnx.

--
 Chuck Forsberg WA7KGX   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: Urgent: Fedora 18 update breaks mount.cifs

[Paul Black]

On 6 March 2013 06:04, Ed Greshko  wrote:

> On 03/06/13 13:27, Chuck Forsberg WA7KGX N2469R wrote:
> > After a routine yum update at omen.com,
> > the previously reported mount.cifs breakage has spread from rawhide to
> Fedora 18.
> >
> > It gives:
> > mount error(22): Invalid argument
> > Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> >
> > man mount.cifs has not changed at all.
> >
> > Is this botch breakage or an unannounced flag day???
> >
> > The bugzilla reporting tool would not allow me to generate a new report.
> >
>
> Can we assume you are talking about a "clean" F18 system?  Any reason not
> to post in the "users" mailing list?
>
> FWIW.
>
> [egreshko@meimei ~]$ pwd
> /home/egreshko
> [egreshko@meimei ~]$ ls silly
> [egreshko@meimei ~]$ sudo mount -t cifs //silly/Pictures
> /home/egreshko/silly -o
> gid=egreshko,uid=egreshko,password=xx,username=xx
> [egreshko@meimei ~]$ ls silly
> 2010_12_12  desktop.ini  iPod Photo Cache  Nokia  tiffs  x
> [egreshko@meimei ~]$ uname -r
> 3.8.1-201.fc18.x86_64
>
> I see no "breakage".
>

It broke for me. It was coincident with the change from kernel 3.7.9 to
3.8.1 but I didn't investigate if this was the cause.

Adding a "sec=" option with either ntlm or ntlmv2 worked for me. Slightly
odd given that the man page says ntlm is the default.

Digging a little more, a possibly relevant kernel commit from 2012-11-25
has the comment "default authentication needs to be at least ntlmv2
security for cifs mounts":
-#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLM |
CIFSSEC_MAY_NTLMV2 | CIFSSEC_MAY_NTLMSSP)
+#define   CIFSSEC_DEF (CIFSSEC_MAY_SIGN | CIFSSEC_MAY_NTLMSSP)

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

Re: upgrade to rawhide how

[Andre Robatino]

Adam Williamson  redhat.com> writes:

> (Current Rawhide kernels die as soon as modesetting kicks in, for me, on 
> a Geforce 9600 GT. I need to get around to triaging it.)

Is what you're talking about anything like
https://bugzilla.redhat.com/show_bug.cgi?id=901816 ? I've been having that
problem on F18 for a while with a GeForce 6150SE nForce 430.


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