Re: Respins for OEM preloads

2021-01-19 Thread Julen Landa Alustiza 

Good morning,

21/1/19 16:52(e)an, Peter Robinson igorleak idatzi zuen:

On Tue, Jan 19, 2021 at 3:50 PM Matthew Miller  wrote:


A large computer vendor with whom we have a friendly relationship would like
to update the image they're shipping on their systems so that 1) new users
don't have quite so many updates immediately and 2) auiu newer kernel helps
with some upcoming things *vague vague handwavy vague*.

I can think of four possibilities:

1. Sure, use the live-respins!

2. The live-respins are unofficial, but we have run [this specific
workstation iso] through our standard validation tests and we
recommend it for your use.

3. Use the netinstall and choose "apply updates" (or whatever that option is
called) when making your distribution image.

4. Uh, sorry, we got nothin'.


In all cases, they will run through their own internal testing and
validation. And, because of calendar things, they'd really love an answer
before the 26th of this month, which I know is short notice.

Of the above, I think #2 is the best, but requires someone other than me to
do significant work. So, I'm raising it here. :)


If they're doing the QE the #2 option isn't too hard, what artifact do
they need, the iso installer or the live image, something else?


Actually we already test the respins: 
https://openqa.fedoraproject.org/tests/overview?distri=fedora=33=FedoraRespin-33-updates-20210114.0=1

___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposal: Asynchronous blocker review process (using Pagure)

2020-01-13 Thread Julen Landa Alustiza 
The RFE commit have been merged on master: 
https://pagure.io/pagure/c/31280551ec2fdf282152abae2ff9d44f20faaf92?branch=master


I'll notify here once we release 5.9 and upgrade pagure.io with it.

19/12/5 10:06(e)an, Kamil Paral igorleak idatzi zuen:
On Thu, Dec 5, 2019 at 9:33 AM Julen Landa Alustiza 
mailto:jla...@fedoraproject.org>> wrote:



19/12/4 15:34(e)an, Kamil Paral igorleak idatzi zuen:

On Tue, Dec 3, 2019 at 10:22 PM Tim Flink mailto:tfl...@redhat.com>> wrote:

Has anyone poked at scoping out the work required for either
the bot or
the enhancements we would need for pagure?


Lukáš Brabec looked into it, and creating a new Pagure ticket is a
matter of a few lines of code (already written). Extending BBA
with a "discussion link" in each blocker row should be trivial as
well. I think that's all we need for trying it out.

The blocker bot watching and updating the issue should be fairly
easy as well, I hope, but as described above, we've hit an issue
where Pagure API doesn't allow comment editing. Lukáš implemented
a workaround that adds a new metadata field on the right side of
each Pagure ticket showing the count summary. It's barebones, but
at least something. We've haven't yet looked into writing the
listener code, that would listen for Pagure events on the message
bus and react to them. We also haven't looked at Bugzilla updater
as described in the proposed workflow (that's really a cherry on
top, we don't need it right away).

Implementing an api endpoint to edit comment is easy, open an RFE on
pagure's issue tracker if you need it and I'll take it


I'm not going to say no to that! :-) Here it is:
https://pagure.io/pagure/issue/4683
Thanks a lot.

___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Draft SOP for handling group membership requests

2020-01-09 Thread Julen Landa Alustiza 

+1 on my side

20/1/9 10:19(e)an, Kamil Paral igorleak idatzi zuen:
On Thu, Jan 9, 2020 at 1:28 AM Adam Williamson 
mailto:adamw...@fedoraproject.org>> wrote:


Hi folks! As discussed at the meeting this week, we're sort of missing
a process for people to become QA group sponsors, and an SOP for how
sponsors should handle group membership requests. I've written a draft
for the second piece today:

https://fedoraproject.org/wiki/User:Adamwill/Draft_sop_new_member_welcome

this is pretty much a description of how Sumantro and I currently
handle new membership requests. If folks could review and comment on
it, that'd be great. 



LGTM

___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposal: Asynchronous blocker review process (using Pagure)

2019-12-05 Thread Julen Landa Alustiza 
19/11/28 17:13(e)an, Adam Williamson igorleak idatzi zuen:

> On Thu, 2019-11-28 at 13:29 +0100, Kamil Paral wrote:
>> What are your thoughts? Does the proposal sound reasonable? Would you
>> change something? Would you use a different backend system? Have I
>> forgotten something important? Feedback welcome.
> So overall I agree with a lot of what you wrote. It does cause me to
> wonder if writing some kind of plugin/extension for Pagure, or just
> writing the functionality into the blockerbugs app, might possibly be
> *less* work than writing and maintaining the 'blocker bot', however. My
> other concern would be that if we use something other than the
> blockerbugs app or Bugzilla, we now have *three* different systems
> involved in the blocker review process - Bugzilla, the blockerbugs app,
> and the discussion system. That seems like a lot of moving parts to
> keep synchronized.
pagure supports third-party themes|plugins , src.fp.o uses both for
custom features (anitya integration for example), we could do something
similar on pagure.io, where we are already using a downstream theme but
not plugin
> Thanks for working on this!
-- 
Julen Landa Alustiza
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposal: Asynchronous blocker review process (using Pagure)

2019-12-05 Thread Julen Landa Alustiza 

19/12/4 15:34(e)an, Kamil Paral igorleak idatzi zuen:
> On Tue, Dec 3, 2019 at 10:22 PM Tim Flink  <mailto:tfl...@redhat.com>> wrote:
>
> Has anyone poked at scoping out the work required for either the
> bot or
> the enhancements we would need for pagure?
>
>
> Lukáš Brabec looked into it, and creating a new Pagure ticket is a
> matter of a few lines of code (already written). Extending BBA with a
> "discussion link" in each blocker row should be trivial as well. I
> think that's all we need for trying it out.
>
> The blocker bot watching and updating the issue should be fairly easy
> as well, I hope, but as described above, we've hit an issue where
> Pagure API doesn't allow comment editing. Lukáš implemented a
> workaround that adds a new metadata field on the right side of each
> Pagure ticket showing the count summary. It's barebones, but at least
> something. We've haven't yet looked into writing the listener code,
> that would listen for Pagure events on the message bus and react to
> them. We also haven't looked at Bugzilla updater as described in the
> proposed workflow (that's really a cherry on top, we don't need it
> right away).
Implementing an api endpoint to edit comment is easy, open an RFE on
pagure's issue tracker if you need it and I'll take it
>  
>
>
> It might be interesting to look at porting the blockerbugs app to
> django if we can make use of some existing django plugins. In the
> past,
> I would have hesitated to do this because of the packaging
> requirements
> and the amount of fun that plugin ecosystems can present but we're
> going to have to move to openshift sooner than later which makes the
> prospect of using something like Django a lot less daunting.
>
>
> Ehh. Hmm. I'd really like to avoid being responsible for showing the
> discussion, handling authentication, sending out notifications, etc.
> Right now, if BBA is down, we're fine, it's just less comfortable. If
> we own the full process, it's much more demanding. Also, converting
> BBA to Django and using some discussion+votes plugins sounds like more
> work than those quite simple changes in BBA + blocker bot. Plus Josef
> is the only one except you who has some Django experience, I think.
>
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
-- 
Julen Landa Alustiza
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: 2019-11-25 @ 16:00 UTC - Fedora QA Meeting - Minutes

2019-11-25 Thread Julen Landa Alustiza 
Morning folks!

On November 25, 2019 9:41:41 PM GMT+01:00, Adam Williamson 
 wrote:
>==
>#fedora-meeting: Fedora QA Meeting
>==
>
>
>Meeting started by adamw at 16:00:29 UTC. The full logs are available
>at
>https://meetbot.fedoraproject.org/fedora-meeting/2019-11-25/fedora-qa.2019-11-25-16.00.log.html
>.
>
>
>
>Meeting summary
>---
>* Roll call  (adamw, 16:00:40)
>
>* Previous meeting follow-up  (adamw, 16:05:29)
>  * "adamw to follow up on the printing criteria proposal and ask
>sgallagh if he thinks we should push it out as-is" - that one got
>overtaken by events later in the meeting  (adamw, 16:05:55)
>  * "adamw to create F32 release criteria pages" - I did that! I'm
>helping!  (adamw, 16:06:08)
>  * "sgallagh to add proposed printing criterion to F32 criteria once
>they're ready" - it seems we actually added this criterion to the
>page back in april, so all is well here  (adamw, 16:11:27)
> * "tablepc to make the 'disk dismount' test case proposal into a draft
>wiki page" - he did that, at
>https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot ,
>and it'll come up for discussion later  (adamw, 16:22:57)
>  * "coremodule and sumantro to work on a heroes of fedora blog post" -
>   this is done, and the post is awaiting Magazine publication  (adamw,
>16:25:49)
>
>* Proposed disk unmount test case  (adamw, 16:27:45)
>  * we generally agreed this seems like a useful proposal and support
>adding the test case to the Base matrix, but there were several
>suggestions for revisions  (adamw, 16:45:08)
>  * ACTION: kparal to reply to the list with his suggestions for
>revisions to the proposed shutdown test case  (adamw, 16:45:53)
>  * ACTION: tablepc to do a new draft of the proposed test case after
>seeing kparal's suggestions  (adamw, 16:46:00)
>
>* Test systems update: Taskotron, autocloud, Zuul, oh my  (adamw,
>  16:51:40)
> * there was some discussion of retiring Taskotron very soon due to F29
>   EOL, but in the end, tflink managed to get it working on F30. so now
>Taskotron will stick around until F30 EOL  (adamw, 16:53:32)
> * autocloud *is* retiring with F29 EOL. we have extended openqa to run
>the tests autocloud was previously running, on the Cloud_Base qcow2
>images only for now. this is the 'cloud_autocloud' test case in
>openqa, it shows as 'compose.cloud_autocloud' in resultsdb  (adamw,
>16:55:07)
>  * LINK:
>https://lists.fedoraproject.org/archives/list/c...@lists.fedoraproject.org/message/CXDD2VYR6PHTR76JCJ5H5VEBIRG7YL37/
>(adamw, 16:56:13)
> * there is a new Zuul-based CI/CD system for dist-git pull requests in
>operation, more details at
>https://fedoraproject.org/wiki/Zuul-based-ci and the other links
>above  (adamw, 17:00:09)
FYI, fbo is working on a helper script to ease zuul configuration: 
https://pagure.io/fedora-project-config/blob/master/f/tools/project-settings-helper
 I'm coordinating with him to go further with automation, we expect to land 
some modifications on pagure side this week so the settings helper function can 
create tags and reduce manual work.

>
>Meeting ended at 17:06:16 UTC.
>
>
>
>
>Action Items
>
>* kparal to reply to the list with his suggestions for revisions to the
>  proposed shutdown test case
>* tablepc to do a new draft of the proposed test case after seeing
>  kparal's suggestions
>
>
>
>
>Action Items, by person
>---
>* kparal
>  * kparal to reply to the list with his suggestions for revisions to
>the proposed shutdown test case
>  * tablepc to do a new draft of the proposed test case after seeing
>kparal's suggestions
>* tablepc
>  * tablepc to do a new draft of the proposed test case after seeing
>kparal's suggestions
>* **UNASSIGNED**
>  * (none)
>
>
>
>
>People Present (lines said)
>---
>* adamw (110)
>* cmurf (37)
>* kparal (27)
>* lruzicka (23)
>* tablepc (17)
>* zodbot (15)
>* frantisekz (15)
>* coremodule (5)
>* tflink (3)
>* sgallagh (3)
>* satellit (1)
>* fbo (1)
>
>
>
>
>Generated by `MeetBot`_ 0.1.4
>
>.. _`MeetBot`: http://wiki.debian.org/MeetBot

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Gnome-calendar 3.34 bug reported

2019-09-19 Thread Julen Landa Alustiza 
Can you propose it as final blocker?

gnome-calendar is included on wks default install and has an icon on the menu, 
so it must work

On September 19, 2019 11:49:27 AM GMT+02:00, Ankur Sinha 
 wrote:
>Hello,
>
>Gnome-calendar doesn't always work in F31. Upstream bug was already
>reported, and I've also filed on on our bugzilla for completeness now:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1753558
>https://gitlab.gnome.org/GNOME/gnome-calendar/issues/455

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: proposal: move "image size" criterion from Beta to Final

2019-09-17 Thread Julen Landa Alustiza 
+1

On September 17, 2019 10:34:25 PM GMT+02:00, Ben Cotton  
wrote:
>On Tue, Sep 17, 2019 at 9:55 AM Kamil Paral  wrote:
>>
>> Considering this, I believe it makes sense to move the current
>criterion from Beta to Final.
>>
>I'd be okay with letting the responsible team specify a buffer they're
>willing to accept for Beta (e.g. so Workstation might say "we can
>allow 10% over our specified limit" and Server can say "if we go over
>the DVD won't burn, so what's the point?") In other words, any overage
>would be an automatic blocker, but teams can optionally pre-approve
>exceptions. This way, teams can still make determinations that are in
>the best interests of the deliverable they're targeting, but we don't
>end up in a position we're slipping a week because a deliverable is 5
>bytes larger than desired.
>
>I like this approach better than just moving the criterion to Final
>because in cases of large overages, the package gymnastics that might
>be required to make it work could prove to be pretty impactful. I'd
>have a lot more confidence in our ability to deliver a good experience
>to our users if we're trying to trim half a gig from an image before
>Beta than if we're doing it on the Monday before Go/No-Go.

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: proposal: move "image size" criterion from Beta to Final

2019-09-17 Thread Julen Landa Alustiza 
We should block on them until we stop supporting them.

But does not wks live size impact on ram usage? 4.7GB may be way too much on 
this case

On September 17, 2019 8:37:50 PM GMT+02:00, Adam Williamson 
 wrote:
>On Tue, 2019-09-17 at 15:54 +0200, Kamil Paral wrote:
>> We currently have the following Beta criterion:
>> "The release-blocking images must meet current size requirements."
>[1]
>> 
>> The latest "Workstation image is oversized" bug [2] showed that we
>don't
>> consider this requirement to be that critical. People mostly agreed
>that
>> having a slightly oversized image at Beta is no big deal. And there's
>much
>> truth to it. The limits were critical when we used optical media, but
>with
>> flash drives, there is always an option to use a larger one.
>> 
>> Considering this, I believe it makes sense to move the current
>criterion
>> from Beta to Final.
>> 
>> There are other options to handle this, like giving the image size
>e.g. 10%
>> headroom during Beta. We can do this, but the more I think about it,
>the
>> less value I see in it. If the image was 11% over size, would it
>really
>> matter? I think we actually don't care image image size restrictions
>before
>> Final release at all. For Final release, sure, some groups want to
>fit X GB
>> flash drives, and some groups want to fit onto a DVD disc. But for
>Beta we
>> can always test it just fine, regardless the size (and no images are
>> release blocking for optical media for Beta).
>
>> Thoughts?
>
>We could consider still enforcing sizes which clearly relate to optical
>media (so, basically, 700MB and 4.7GB sizes).

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: proposal: rename "target size" to "maximum size" for release-blocking images

2019-09-16 Thread Julen Landa Alustiza 

+1

19/9/13 17:41(e)an, Adam Williamson igorleak idatzi zuen:

On Fri, 2019-09-13 at 08:44 -0400, Ben Cotton wrote:

On Fri, Sep 13, 2019 at 8:09 AM Kamil Paral  wrote:

Related to Workstation image oversize bug [1] and the related
Go/NoGo meeting, I'd like to propose to rename the image-related
term "target size" to "maximum size".

+1. I see no downsides to this.

Also +1, dunno why someone picked 'target' in the first place.

--
Julen Landa Alustiza
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposing new release criteria

2019-08-29 Thread Julen Landa Alustiza 
Could we go on a more generic fashion?

Something like "Supported container engines must work on their basic features 
on all the blocker deliverables were they are installed by default" 

Our supported engines are, podman? cri-o?

On August 29, 2019 6:40:21 PM GMT+02:00, Matthew Miller 
 wrote:
>On Thu, Aug 29, 2019 at 11:45:44AM -0400, Dusty Mabe wrote:
>> Certainly anywhere where podman is shipped on media. Does podman ship
>in the server DVD? yes [1]
>> It looks like workstation also ships it if I'm reading the logs [2]
>correctly.
>
>Yeah, it's needed for Toolbox, which is a vital feature for Silverblue
>but
>also one we want to encourage on general Workstation as well.
>
>Pretty sure it's also required for IoT.

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: what to install to (eventually) be able to upgrade to fedora 31?

2019-08-28 Thread Julen Landa Alustiza 
Sure there are better explanations but...

DOOMED: a mandatory step for our blocking deliverables failed. x86_64 
workstation dvd iso can't build for example
FINISHED_INCOMPLETE: a non blocking deliverable failed. x86_64 xfce dvd iso for 
example

FINISHED (i'm not sure, didn't see it for a while): all was built

On August 28, 2019 1:13:09 PM GMT+02:00, "Robert P. J. Day" 
 wrote:
>On Tue, 27 Aug 2019, Alessio wrote:
>
>> On Tue, Aug 27, 2019, 7:07 PM Robert P. J. Day
> wrote:
>>
>>     what is the *proper* ISO to install that will eventually get
>me to
>>   fedora 31? thanks.
>>
>>
>> Hello.
>> I think you should look here:
>> https://kojipkgs.fedoraproject.org/compose/branched/
>>
>> Check the STATUS file to see if the building is still in progress.
>
>  i'm still curious about the meaning of the STATUS file there, as
>what i see currently is:
>
> COMPOSE_ID = Fedora-31-20190826.n.0
> STATUS = FINISHED_INCOMPLETE
>
>but if i wander down to find the ISO, i get what appears to be a
>perfectly installable:
>
>  Fedora-Workstation-Live-x86_64-31-20190826.n.0.iso
>
>so i don't know what FINISHED_INCOMPLETE means in the context of what
>appears to be a perfectly complete and working ISO.
>
>rday

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Update to last minute blocker bugs proposal (Rev:07242019)

2019-08-14 Thread Julen Landa Alustiza 
I have the same doubts about the 7. Well, nobody is sure ;) +1 on my side, 
great work Pat & Adam

On August 14, 2019 7:33:03 PM GMT+02:00, Ben Cotton  wrote:
>On Wed, Aug 14, 2019 at 1:26 PM Adam Williamson
> wrote:
>>
>> If we say 3 days, then we're committing to doing all of that for a
>> blocker that's proposed the Sunday before the go/no-go - one day
>before
>> the final blocker review meeting. Which, I mean...yeah, we have time
>to
>> do all that. Juuust barely. :)
>>
>I mean, it seems like we do that now anyway. I'm definitely okay with
>you saying "yes, but the status quo is still kinda terrible." And I'm
>okay with finding a bug and not being able to fix it in time for it to
>be in the RC. What I don't want happening is for a bug to pop up just
>before the meeting so that we end up spending half of of the go/no-go
>meeting trying to reproduce the bug report.
>
>> I dunno, it's hard to be sure what number is right exactly.
>
>Only because there's no right answer. :-) I'm fine with choosing 7
>days as a starting point. If that's the only area of disagreement on
>this proposal, then I'd say you've done pretty well.

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Release blocking architectures

2019-07-31 Thread Julen Landa Alustiza 
https://fedoraproject.org/wiki/Releases/30/ReleaseBlocking
Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: DVD does not show up in a dvd is inserted.

2019-07-10 Thread Julen Landa Alustiza 
You mean on gnome file explorer? That's intended, empty optical disc drivers 
does not appear on file explorer. You have to insert a valid cd/dvd/bluray to 
appear. once you insert an empty recordable disc it should appear on file 
explorer as blank cd/dvd



On July 10, 2019 2:35:47 AM GMT+02:00, Lawrence Graves 
 wrote:
>I am not able to burn a dvd or cd in my player. My player shows up in
>bios but after start up, it can't be seen.
>___
>test mailing list -- test@lists.fedoraproject.org
>To unsubscribe send an email to test-le...@lists.fedoraproject.org
>Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives:
>https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Media writer

2019-05-14 Thread Julen Landa Alustiza 
>From the live user's perspective I don't see the point on adding it, I
agree with kamil. The unique use case that cames to my mind for fmw on a
livecd session is burning an arm sd, but that does not make too much sense
neither, you can burn a fc31 arm sd from fc29 or whatever without problems,
so I'm more inclined to -1 this for livecd usage.

About adding it to the default desktop package set... imo this it out of
our scope and should be a workstation wg decission.

Of course we could suggest them to add it, but I don't see any clear
benefit on it
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Last minute blocker bugs

2019-05-14 Thread Julen Landa Alustiza 
Lukas Ruzicka  igorleak hau idatzi zuen (2019 mai. 14,
ar. 14:12):

>
> I am talking about the quorum, if there is a late discovered bug, that
> would normally be considered a blocker, but because
>
> a) it could not be fixed on time, and
> b) it is not as serious as it would prevent people from using Fedora anyway
>
> In this case, I think more people to decide is crucial because it keeps us
> from letting bugs flow into releases *whenever *we might need to. If more
> people decide that it is ok, then it is ok.
>
> What if any number of people in an IRC meeting could decide it? Then one
> person could possibly decide it, too? Or two? Or three? Or how many at
> least? And that is the quorum. Or do we say, it should be some percentage
> of the present? Ok.
>
> Until now, we always used the "above 50%" which leaves a bitter
> after-taste if you are in the "below 50" group. Therefore, I suggest more
> than 50. So that it is clearly decided that we want that outcome.
>
>
> That's 80% of votes, but just 16,67% of the total audience from your
>> matrix.
>>
>
> I do not understand which matrix do you mean?
>
The one on the previous mail. 4/25/19 meeting presence = 24. Positive votes
to block: 4. Voting people, 5. That makes a 80% of total votes but just
16,67% of total presence.


> The ksieve bug was reported by me in early February ... a long time before
> Beta and Final. I did not propose it a blocker, because I thought, that
> they would have fixed it a long time before Beta or Final. The did not.
> However that is not a best example of an unexpected blocker jumping out of
> nowhere. It was known for a long time.
>

Known or not, the bug was not proposed as blocker until aftet starting the
go/no-go meeting, so imo it can be considered as a latter bug. Actually we
resurrected this discussion due to that specific bug.

>
> I like that things are always decided by the community and with my
> suggestion I cry for more community.
>
> Lukas
>
>
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Last minute blocker bugs

2019-05-14 Thread Julen Landa Alustiza 
Lukas Ruzicka  igorleak hau idatzi zuen (2019 mai. 14,
ar. 12:55):

> Yeah, you can be right, Julen, however the process, as we are having now,
> would allow discarding Blocker Bugs possibly anytime, even if 3 or 4 people
> would be present on a meeting. And I don't think it is correct to let 4
> people decide.
> In case of a qorum (and I am not saying it has to be 10 people), the few
> people in the IRC meeting could always summon for more people to join, as
> we always do when we need to talk to particular people. They usually
> respond.
>
We can discuss about regular quorum rules of course, but here we were
talking about the last minute bug thing, are we talking about an special
rule for waiving or about changing the qorum rules for blocker-reviewing?
If the latter, we should discuss it on an independent thread, and sometimes
we do need small quorums. Many bz voted proposals are accepted/rejected
with just 3-4 +1s ans it helps a lot to polish the candidate to be able to
do that with some after last meeting bugs that need to be classified so
they can be pushed to the compose.


> But to show some numbers, I have gone through the meetings minutes of F30
> release and I realized that on average, there were more than 10 people
> actively present on each meeting, the average Go/no Go presence is *17*.
> See table.
>
> = Meeting presence
>
> == Go/No-go Meetings
>
> |===
> | Milestone | Date | Presence
> | Beta | 3/21/19 | 14
> | Beta | 3/28/19 | 16
> | Final | 4/25/19 | 24
> | Final | 4/26/19 | 14
> | Average |   | 17
> |===
>
> == Blocker Review Meetings
>
> |===
> | Date | Presence
> | 2/11/19 |  6
> | 3/04/19 | 11
> | 3/11/19 | 14
> | 3/18/19 |  9
> | 3/25/19 | 13
> | 4/1/19  | 10
> | 4/8/19  | 15
> | 4/15/19 | 14
> | 4/22/19 | 13
> | Average | 11
>

Nice job, thanks!!

But about the latest waiving thing, the ksieve bug that we found during the
4/25/29 go/no-go meeting was accepted with a +4/-1 result. That's 80% of
votes, but just 16,67% of the total audience from your matrix.

Anyhow I'm fine with that, even if we had waived it. We had to make a
agreement, and a vast majority of the participants agreed on the same way,
I'm fine with that.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Last minute blocker bugs

2019-05-14 Thread Julen Landa Alustiza 
Lukas Ruzicka  igorleak hau idatzi zuen (2019 mai. 14,
ar. 10:39):

> I have suggested the quorum, but we can still discuss the exact numbers
> (mine were just examples). Besides, the votes do not have to come from
> people present in one particular IRC meeting, but
>
>- votes could be recorded in all such meetings (blocker bugs meeting,
>go-nogo, ...)
>- votes could be casted in Bugzilla and IRC presence does not need to
>be required.
>
> The most important thing is, the majority agrees, not that we need to
> organize voting every time we meet.
>
> Lukas
>

But we are talking about last minute blockers so potentially they'll be
discussed just on one meeting (latest blocker-review or GO/No GO) and we
will not have a big time window for BZ voting.

I agree that the waiving should be agreed by a good majority, but I would
prefer bot having any special quorum requeriments.

Scenario: Go/NO-Go is running and kparal finds a last minute bug. We don't
have time for BZ voting, nor we can't wait for quorum. We need to agreed a
decision during the running meeting, either waiving or blocking or it.
Well, I would go with standard discuss, vote & agreement process, nothing
special.

Otherwise we will finish just autoblocking on all last minute bockers
waiting for quorum, so waiving will not be possible.

>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Last minute blocker bugs

2019-05-14 Thread Julen Landa Alustiza 
On both fc29 and fc30 cycles, nor the later blocker review meetings nor the
go/no-go ones did not have 10 participants, so needing a 80% agremeent with
a minimum of 10 votes would directly block on last minute bugs on those
scenarios.

I don't have a clear opinion on this, but for now I would prefer not having
an special hard quorum requirement
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Can we maybe reduce the set of packages we install by default a bit?

2019-04-10 Thread Julen Landa Alustiza 
I'm really interested on the livet crash, but I can't reproduce it with
latest branched compose.
Can you provide us with reproduction steps?

Hau idatzi du Neal Gompa (ngomp...@gmail.com) erabiltzaileak (2019 api. 10,
az. (02:59)):

> On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy 
> wrote:
> >
> > On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering 
> wrote:
> > >
> > > Heya,
> > >
> > > today I installed the current Fedora 30 Workstation beta on my new
> > > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> > > crashed five times or so on me, always kicking me out of anaconda
> > > again, just because I wanted to undo something).
> >
> > I haven't seen a single one come across in QA
> >
> > > 1. multipathd.
> >
> > I'm pretty sure it gets dragged in by the installer, i.e. the
> > installation environment needs it because installing to multipath is
> > supported. And since it's on the Workstation LiveOS, it just gets
> > copied over along with the installer itself (LiveOS installs use
> > rsync). I wonder if it's reasonable to apply more exclude filtering
> > during rsync to avoid copying some things needed for Live OS
> > environment, but not on the final installed system. But that's sorta
> > up to Workstation WG I think.
> >
>
> Not having the rpmdb in sync with what content is on the system is
> probably not a good idea. I'd advocate for anaconda being able to run
> dnf to clean up stuff instead.
>
> >
> > > 2. dmraid.
> >
> > Same as above. I'm not sure whether, or when, dmraid stuff is going to
> > be dropped by anaconda. For a long time now dmraid is deprecated. The
> > two supported ways of doing software raid are managed by mdadm and
> > lvm, both of which actually use the md driver in the kernel.
> >
> > So I think this is a question for the anaconda team.
> >
> >
> > > 4. Similar crond. On my fresh install it's only used by "zfs-fuse",
> > >which I really wonder why it even is in the default install? And
> > >"mdadm" wants this too. (which would be great if it would just use
> > >timer units)
> >
> > I think zfs-fuse and glusterfs are dragged in by libvirt, which is
> > present because of GNOME Boxes. I don't know why any of those want
> > crond.
> >
>
> These could be converted to systemd units. There's no reason not to,
> really...
>
> > mdadm scrub and monitoring depends on crond, and then email
> > notifications if mismatch count != 0; it's archaic these days I guess,
> > but that's how it works.
> >
> >
> > > 5. libvirtd. Why is this running? Can't we make this socket
> > >activatable + exit-on-idel? While I am sure it's useful on
> > >workstations why run it all the time, given that only very few
> > >users probably actually need that, and if they do starting it on
> > >demand would be much more appropriate? On my freshly installed
> > >system it is running all the time even though there are no VMs or
> > >anything around.
> >
> > Agreed.
> >
> >
> > >
> > > Ideally, the top 4 wouldn't be installed at all anymore (in case of
> > > the first two at least on the systems which do not need them). But if
> > > that's not in the cards, it would be great to at least not enable
> > > these services anymore in the default boot so that they are only a
> > > "systemctl enable" away for people who need them?
> >
> > At the least it seems reasonable they can be disabled on the installed
> > system, and enabled for Live OS boot if the installer needs them.
> >
> > --
> > Chris Murphy
> > ___
> > devel mailing list -- de...@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org
>


-- 
Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: "Basic graphics mode" feature and criterion discussion

2019-03-26 Thread Julen Landa Alustiza 
Due to the context and actual bugs, and what we see during the argues, the
main idea about "work correctly" is that you should be able to launch a
working desktop where typical use of some tools and specialy the installer
process can be launched and executed with success.

Yeah, with caveats, a suboptimal performance, maybe with difficulties to
use certain i18n options, but should be able to open a wiki and install the
box.

Nowadays you just got a blank screen on a lot of hardware and we had a 100%
freeze success rate on qa team wih nomodeset activated some weeks ago.

We don't have to problem to put a line on "what the hell is work correctly"
now, it just doesn't work at all on a lot of typical hardware



Adam Jackson  igorleak hau idatzi zuen (2019 mar. 26, ar.
21:03):

> On Tue, 2019-03-26 at 11:14 -0700, Adam Williamson wrote:
>
> > The justification for this is, I hope I am correctly representing all
> > views here (please say so if not), that this mechanism is both less
> > necessary (due to a general reduction in the amount of 'weird' graphics
> > hardware out there, and general improvement in the reliability and
> > coverage of the major drivers for the major graphics hardware
> > manufacturers) and inherently less likely to work (due to the general
> > trend of work on kernel modesetting and Wayland) than it used to be.
>
> At least in a Gnome context, the issue is that 'nomodeset' will likely
> leave you with efifb, and that mutter does not support (both being a
> wayland server and) rendering to fbdev devices, only drm devices. (This
> will probably soon be true for weston too; no idea what KDE does these
> days.) So in that scenario gdm will instead launch Xorg.
>
> Now, Xorg's not about to delete fbdev support, but this means you're
> exercising quite a few different paths relative to the normal Wayland
> session. Input devices are driven from Xorg so xinput(1) will show more
> interesting results, xrandr(1) will behave differently, control-center
> will be using a different backend, you probably won't get hidpi support
> working the same way, you'd expect HDR not to work once that's a thing
> we support at all, etc etc etc.
>
> So with the above caveat understood that "work correctly" has a bunch
> of asterisks next to it and you will probably be able to tell that
> you're using a fallback path, I don't think it's intrinsically less
> likely that graphics fallback would work. I might prefer that we call
> it "desperation" or "emergency" graphics instead of "basic", I suppose.
> But the support path itself is something we already want/need to keep
> working for the case of hardware released after the OS. I might want to
> see the code implementing that fallback path made cleaner, and I might
> wish the path weren't necessary, but.
>
> > 4) (This one mainly for ajax and airlied) to what extent does the
> > concept of a 'fallback option' for our supported desktop environments
> > and graphical servers still actually make sense? Could a different
> > implementation of the same basic idea be envisaged, and would it be
> > useful? If so, should we do that, and what would be the consequences
> > for the criteria?
>
> The components necessary to support fallback graphics are components we
> already have to support graphics in a dumb vm. I don't see that
> requirement going away, so I don't see much point in disabling that
> support for physical machines.
>
> From an implementation perspective I would certainly like to see the
> fallback path look more like the supported path, in that I'd like drm
> devices to be the only graphics abstraction, and eventually would like
> to stop caring about Xorg - meaning, the X server also being the
> display server and input server. But saying 'nomodeset' is a perfectly
> unambiguous way of asking for the fallback path, I don't think there's
> much point in requiring you to say something different on kcmdline.
>
> - ajax
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

2019-03-12 Thread Julen Landa Alustiza 
Sounds more than reasonable.

Adam Jackson  igorleak hau idatzi zuen (2019 mar. 12, ar.
19:11):

> On Wed, 2019-03-06 at 12:46 -0800, Adam Williamson wrote:
> > Hi folks!
> >
> > So there's a current Beta blocker bug:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1683197
> >
> > it is currently accepted as a blocker on the understanding that trying
> > to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset'
> > on the cmdline) *always* fails, on all hardware (or at least on most
> > hardware). However, we don't yet have enough testing to be sure of
> > this.
>
> I looked into this today, and while it's a truly gross issue at root, I
> think I've got a reasonable solution (see patch in comment #11).
>
> The issue seems to be:
>
> a) gdm is expecting a 'master-of-seat' property for the graphics device
> attached to a given seat before it will deign to touch the seat
>
> b) systemd is now setting that property only for a subset of devices -
> specifically, drm devices but not fbdev devices.
>
> c) you don't want to set master-of-seat unconditionally for fbdev
> devices, because it introduces a race: efifb will have bound to the
> device first, and drm driver load is asynchronous, so there's no
> guarantee i915 (or whatever) will have loaded by the time gdm starts,
> and if gdm wins the race the session at best comes up unaccelerated and
> RANDRless with fbdev and llvmpipe, and at worst crashes when the
> framebuffer handoff to i915 triggers.
>
> So. The workaround is to add a udev rule:
>
> # allow efifb / uvesafb to be a master if KMS is disabled
> SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw
> nomodeset /proc/cmdline", TAG+="master-of-seat"
>
> This says, if you asked for nomodeset, whatever fbdev device is present
> is good enough to be a seat master. This doesn't handle all possible
> cases. It doesn't catch the case of a user saying (for example)
> i915.modeset=0, which would also disable modesetting, but that's never
> what our tools write to our grub configs. It wouldn't catch the case of
> using vgafb or vesafb (or any other fbdev driver) _without_ explicitly
> saying nomodeset; but we ship very few such drivers, and our tools will
> not give you any of the generic ones like vga or vesa by default.
>
> So I think this handles 90%+ of the cases we care about, certainly
> enough to unblock the release. If anyone wants to polish it further,
> feel free. Let me know if there's any additional insight I can provide.
>
> - ajax
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Fedora 30 Beta blocker status mail #3

2019-03-08 Thread Julen Landa Alustiza 
The biggest problem would be the machine that can't boot the live iso on
normal mode and hangs on basic video mode too.

How frequent is this? My test boxes can install on normal mode, I did not
found a box that hangs on both modes.

Chris Murphy  igorleak hau idatzi zuen (2019 mar.
8, or. 21:38):

> On Fri, Mar 8, 2019 at 12:56 PM  wrote:
> >
> > On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson
> >  wrote:
> > > I requested testing on desktop@ and test@ lists earlier this week; so
> > > far that seems to suggest that this is failing for a lot of people on
> > > a
> > > lot of hardware...but it also fails the same way on F29 in most cases,
> > > suggesting we shipped F29 broken as well. I don't think we've yet had
> > > feedback from a system where nomodeset is actually *needed*, which
> > > would be interesting.
> >
> > Please also consider that the target audience for Fedora Workstation is
> > not going to know about nomodeset or how to modify the kernel command
> > line. So unless we have some specific release criterion referencing
> > nomodeset, I'm not sure why it would be a blocker.
>
> The installation media, netinstaller and Live, on both UEFI and BIOS,
> contains a boot menu with a Troubleshooting submenu, which contains a
> boot entry to boot using Basic Video, and that in turn has the
> nomodeset parameter already set.
>
> --
> Chris Murphy
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Modularity test cases for a review

2019-03-08 Thread Julen Landa Alustiza 
Yeah, I don't think that nobody would test old ones, the concern about
versioning is more theorical than practical.

But you talk about clean f30 installation tol and the upgraded systems are
out of scope while support the upgrades from 28 and 29.

Lukas Ruzicka  igorleak hau idatzi zuen (2019 mar. 9,
lr. 04:27):

> I put there those numbers, because I was not expecting that somebody would
> want to test old releases. We are about to start validation testing for F30
> and this is where I aim with these test cases and of course any later
> releases onwards.
> Modularity was semi-available in F28, it was supported in F29, but there
> were changes made and now it should behave slightly differently than in F29
> and 28. For example, in F29 it was possible to switch a module directly
> using the installation command for a new stream, but this is not possible
> in F30. My intent was to test modularity as it is available now, in
> upcoming F30. I think that nobody would test for old releases, but I might
> be wrong.
>
> On Fri, Mar 8, 2019 at 7:04 PM Julen Landa Alustiza 
> wrote:
>
>> My concern is around the minimum version constraints. >= 29 or clean >=
>> 30, while we support and block from 28 till 29 and we're testing 30 and an
>> upgraded box should work like a clean one for blocking purposes. What
>> happens with the versions that are supported but out of scope of these
>> testcases? Current modularity tests does not have any versioning constraint
>> so we're going backward :S
>>
>>
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>


Lukas Ruzicka  igorleak hau idatzi zuen (2019 mar. 9,
lr. 04:27):

> I put there those numbers, because I was not expecting that somebody would
> want to test old releases. We are about to start validation testing for F30
> and this is where I aim with these test cases and of course any later
> releases onwards.
> Modularity was semi-available in F28, it was supported in F29, but there
> were changes made and now it should behave slightly differently than in F29
> and 28. For example, in F29 it was possible to switch a module directly
> using the installation command for a new stream, but this is not possible
> in F30. My intent was to test modularity as it is available now, in
> upcoming F30. I think that nobody would test for old releases, but I might
> be wrong.
>
> On Fri, Mar 8, 2019 at 7:04 PM Julen Landa Alustiza 
> wrote:
>
>> My concern is around the minimum version constraints. >= 29 or clean >=
>> 30, while we support and block from 28 till 29 and we're testing 30 and an
>> upgraded box should work like a clean one for blocking purposes. What
>> happens with the versions that are supported but out of scope of these
>> testcases? Current modularity tests does not have any versioning constraint
>> so we're going backward :S
>>
>>
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Modularity test cases for a review

2019-03-08 Thread Julen Landa Alustiza 
My concern is around the minimum version constraints. >= 29 or clean >= 30,
while we support and block from 28 till 29 and we're testing 30 and an
upgraded box should work like a clean one for blocking purposes. What
happens with the versions that are supported but out of scope of these
testcases? Current modularity tests does not have any versioning constraint
so we're going backward :S

Lukas Ruzicka  igorleak hau idatzi zuen (2019 mar. 8,
or. 15:20):

> Hello,
>
> I have updated the modularity test cases according to what we discussed in
> a meeting with @Stephen Gallagher  , @Petr Sabata
>  , @Adam Samalik  , @Mohan Boddu
>  . Currently, we have the following test cases defined
> to cover modular use cases in Fedora (see below).
> Can you please take a look and provide some additions or comments if
> needed. If there are no comments, I will assume that we have the issue
> covered and will work from there.
> Thanks,
> Lukas
>
>- Find out about modules -
>https://fedoraproject.org/wiki/User:Lruzicka/Testcase_module_information
>- Install a module -
>https://fedoraproject.org/wiki/QA:Testcase_Modularity_install_module
>- Switch a module stream -
>https://fedoraproject.org/wiki/User:Lruzicka/Testcase_switch_stream
>- Remove a module -
>https://fedoraproject.org/wiki/User:Lruzicka/Testcase_remove_module
>- Enable and disable a module"-
>https://fedoraproject.org/wiki/QA:Testcase_Modularity_enable-disable_module
>- Update or upgrade a modular system -
>https://fedoraproject.org/wiki/User:Lruzicka/Testcase_modular_update
>
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> 
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: [Test-Announce] Fedora 30 Gnome 3.32 Test Day 2019-02-05

2019-02-22 Thread Julen Landa Alustiza 
Will we have a working branched f30 compose with gnome 3.32 for then? :D

Sumantro Mukherjee  igorleak hau idatzi zuen (2019
ots. 22, or. 15:18):

> Hola!
>
> Monday, 2019-02-25 will be Fedora 30 Gnome 3.32 Test Day!
>
> As part of this planned Change for Fedora 30, So this is an important Test
> Day!
> As we approach the beta dates, we try to make sure that all the gnome
> features
> are performing as they should and then file bugs well ahead of time.
>
>
> We need to ensure it's working well enough and catch any remaining issues.
> It's also pretty easy to join in: all you'll need is Test Day image (which
> you can grab from the wiki page[0]).
>
> As always, the event will be in #fedora-test-day on Freenode IRC.
>
> [0]https://fedoraproject.org/wiki/Test_Day:2019-02-25_Gnome_3.32_Test_Day
>
>
> Thanks
> //sumantro
> ___
> test-announce mailing list -- test-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> test-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposal: Drop most optional packages from Server DVD

2019-02-18 Thread Julen Landa Alustiza 
Lukas' question made me another one... Server spin has a couple of blockers
on software (freeipa and posgresql at least). Are we going to take them out
from the installer?

Matthew Miller  igorleak hau idatzi zuen (2019
ots. 18, al. 17:00):

> On Mon, Feb 18, 2019 at 11:43:46AM +0100, Lukas Ruzicka wrote:
> > Yes, I agree with the proposal. I also agree that most servers will be
> > connected to the Internet, however, I can think of some use cases where
> > Internet connection is not wanted and an intranet is sufficient, such as:
>
> In this case, I would expect that intranet to have a local mirror. Intranet
> servers also need security and bug fixes.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposal: Drop most optional packages from Server DVD

2019-02-15 Thread Julen Landa Alustiza 
+1 here. totally agree with

Stephen Gallagher  igorleak hau idatzi zuen (2019 ots.
15, or. 16:49):

> For a long time, the Fedora Server Edition has provided a fairly
> lightweight default installation, but a fairly heavyweight DVD. This
> is because we opted to include a lot of infrastructure-related content
> on the disk, such as BIND, FreeIPA, MariaDB and PostgreSQL, among
> others.
>
> The reality these days is that this is probably more or less
> unnecessary. There's no such thing as a server that is not connected
> to a network and since we aren't shipping the entirety of the Fedora
> package collection on this disk, inevitably anyone installing from it
> is going to need to have access to package mirrors anyway.
>
> So I'd like to propose that we get rid of nearly the entirety of the
>  section from comps.xml[1][2] and variants-fedora.xml[3].
> The result will be a far smaller install DVD, less space wasted on the
> mirrors (both for the DVD and the install tree) and very little
> difference in user experience.
>
> Arguments against this have historically been that having it all on
> one disk is better for network-constrained environments to avoid
> downloading content multiple times. Realistically, however, I think
> this is generally going to be solved by local mirroring in most
> real-world scenarios.
>
>
> [1] https://pagure.io/fedora-comps/blob/master/f/comps-f30.xml.in
> [2] With the exception of the "server-hardware-support" and
> "guest-agents" which may be needed for proper installation, depending
> on the hardware.
> [3] https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Participating in the Monday QA meetings

2019-01-14 Thread Julen Landa Alustiza 
The meeting had been cancelled (subscribe to qa-announce so you don't miss
the meeting cancelling mail next time) and it uses to be on
#fedora-meeting-1

pmkel...@frontier.com  I tried to attend the Monday QA meeting, but when ever I typed something
> to the chat screen I got an error something like (can not send to the
> channel) I was able to send a Query to Adam and his reply suggested that
> I needed to have audio set up. I have speakers hooked up and on, but I
> could not hear anyone talking I plugged in and turned on a micro phone
> and that didn't seem to do anything. I'm thinking I need a lesson on how
> get setup so I can participate in the QA meetings.
>
> I connected via a this web link:
>
> https://webchat.freenode.net/?channels=#fedora-qa
>
> Then I remembered hexchat and opened that and it said I was talking on
> #fedora-qa, but I still wasn't able to participate in the discussion.
>
>  Have a Great Day!
>
>  Pat(tablepc)
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: repos used by anaconda during Branched

2018-11-27 Thread Julen Landa Alustiza 
i'm glad to see this revived.

As I mentioned before, my vote goes to B + updates-testing checkbox for
prereleases.

That way we can:
- test the compose as is, even installing from lives
- bypass broken u-t packages

But also:
- install directly with u-t in case that compose is installing but broken
after install but fixed on u-t

Imho this will cover all the broken cases except when compose brokes the
installation process

Stephen Gallagher  On Thu, Nov 22, 2018 at 11:00 AM Kamil Paral  wrote:
> ...
> > b) don't use testing updates at all during the whole cycle
> >
> > This makes the install process more stable (testing updates can't break
> it). The installed packages more closely match what the composes consist of
> (the composes never use testing updates, but occasionally they might
> include a few extra packages on top of what is currently stable, if QA
> requests it). After Beta, you will not end up with a system that contains
> testing packages, but the testing repo is disabled (that might throw some
> people off, if they don't know they should use dnf distrosync instead of
> dnf update).
> > The downside is that before Beta, you'll need to install the system and
> then also update it, to have all the latest packages (including testing
> updates).
> >
> This one has my vote, as I really feel that having install media that
> is unpredictably reliable (especially at Beta) reduces our ability to
> get people testing it.
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Blocking criteria proposal: cron

2018-11-19 Thread Julen Landa Alustiza 
We found a bug[0] on cron + selinux-policy that broke /etc/cron.d
readability for cron, resulting in a non working /etc/cron.d directory and
was proposed as blocker bug.

During the blocker-review meeting, there was a majority of attendes in
favour of blocking due to this bug but we didn't have a clearly violated
criteria [1], so I'd like to discuss about a new server criteria to fix
this situation.

Let start with something short:
"Cron service must work on server for root's jobs, other users' jobs and
jobs from cron job directories inside /etc".

Actually is quite difficult to fully test cron funcionality (openqa worker
can't wait for 3 months to see if cron is working properly for a trimestral
cron line), so I think that we should be more specific about "must work".

Regards,

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1625645
[1]
https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-09-24/f29-blocker-review.2018-09-24-16.05.txt

-- 
Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: [Test-Announce] 2018-11-12 @ ** 16:00 ** UTC - Fedora QA Meeting

2018-11-12 Thread Julen Landa Alustiza 
Discussing about Lukas's propossal without you has no sense, we could delat
that point to next meeting

Have a nice team dinner ;)

El lun., 12 nov. 2018 10:17, Kamil Paral  escribió:

> On Sun, Nov 11, 2018 at 6:13 PM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> # Fedora Quality Assurance Meeting
>> # Date: 2018-11-12
>> # Time: ** 16:00 ** UTC
>> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
>> # Location: #fedora-meeting on irc.freenode.net
>>
>> Greetings testers!
>>
>> We've got some interesting stuff under discussion on the list at
>> the moment, so having a meeting seems like a good idea! Note that
>> clocks have gone back in DST countries since the last meeting, so the
>> meeting time moves to 1600 UTC. If you have changed your clocks back
>> recently, the meeting will be at the same local time as always. If you
>> have not (i.e. you live somewhere DST does not apply), the meeting will
>> be an hour later, local time.
>>
>> If anyone has any other items for the agenda, please reply to this
>> email and suggest them! Thanks.
>>
>> == Proposed Agenda Topics ==
>>
>> 1. Previous meeting follow-up
>> 2. Lukas' desktop testing proposals
>> 3. Fedora 30 status
>> 4. IBM
>> 5. Open floor
>>
>
> Unfortunately we the Brno group won't be around this time, because we're
> having a team dinner. Sorry! We will feel bad about this the whole
> evening...
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: [fedora-qa] Issue #569: Proposal to redefine core applications.

2018-11-07 Thread Julen Landa Alustiza 
Related to this and server, and remembering that we had a non working cron
issue proposed as blocker but we didn't have a clear criteria that was
violated to accept the blocker bug, but the majority of the meeting
attendees was in favour of blocking because cron was not working on server
edition and that was a big issue... could we discuss about having blocking
core applications on server flavour? just some basic services, sshd, cron,
systemd...

El mié., 7 nov. 2018 11:35, Lukas Ruzicka  escribió:

> Hello Fedora QA and friends,
>
> I would like to propose a change of what we define as core applications
> because I feel that how it is done today is not sufficient. Let me explain.
>
> ## How it works today?
>
> The *core applications* are defined in this testcase (
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications).
> In our matrices, the core applications are only tested for Gnome
> Workstation. The appropriate test case (
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications)
> requires that all core applications are installed on the system and that
> they start. The functionality is apparently tested by the *Desktop Menus
> Testcase*.
>
> ## How I think it could work?
> I think we could change how we approach the core applications, how we test
> them and where we test them. For example:
>
> * A list of generic core applications should be made (or the old list
> used, see above), so that core applications are not limited to a certain
> desktop environment (although we only test Gnome). By *generic* I mean that
> we should not explicitly say, if the terminal application is
> *gnome-terminal* or anything else. We only say it is a *terminal*
> application and each spin will pick up what suits best for them.
> * Core applications should be promoted to be a part of all Fedora spins.
> It should not happen that a spin is missing a core application after a
> clean installation.
> * The presence check (that the apps are installed) could be easily done by
> OpenQA. Possibly, it could be done even for more DE than just Gnome, hence
> we could enhance the user experience for spin users.
> * Functionality of the applications should be redefined - what we expect
> for them to be doing - and this functionality should be required. I
> suppose, that we would only block on Workstation functionality, though.
> However, these guidelines could help the spin teams to decide which apps to
> use as core apps.
> * *Core applications* should not just have a basic functionality, as
> defined in *Gnome Menus testcase* (
> https://fedoraproject.org/wiki/QA:Testcase_desktop_menus), they should be
> fully functioning.
>
> Before I focus on details, I would like to know your opinions on this
> matter.
>
> Thank you.
>
> To reply, visit the link below or just reply to this email
> https://pagure.io/fedora-qa/issue/569
>
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> 
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

fc29 + nvidia + xorg

2018-10-31 Thread Julen Landa Alustiza 
Hi, I'm suffering a very strange behaviour on my wks and I would like to
know if it's a general issue or just my setup before going further.

I upgraded an fc28 wks to fc29 yesterday. fc28 was almost a default wks +
nvidia drivers, I don't have more extra repos nor too much extra packages.
It had uncommented the waylandEnabled=false line on /etc/gdm/custom.conf

After upgrading first boot went on and it worked properly. I rebooted the
machine and ended with a stucked gdm after login in with my standard user.
It looked like being to trying to go with wayland on nvidia, so I rebooted
the machine to init 3 to fix the problem.

First weird situation: I found /etc/gdm/custom.conf with
waylandEnabled=true. wtf, i swear I did 't change it. I fixed the line and
exec init 5 as root. gdm goes properly to xorg and I continued working.

Second reboot, and same gdm stucking issue. This time /etc/gdm/custom.conf
continues with false for waylandEnabled. there is nothing strange on
/run/gdm/custom.conf either.

Ok, I went init 3 again. sudo init 5 just after login on text console ends
with a working gdm. going to runlevel 5 directly ends on gdm stucked after
login.

I haven't have time to look further and I won't touch that box again until
monday

Is someone else having this kind of issues with default workstatin install
+ nvidia or it's just my box?

It's a ryzen with a nvidia 1060.

Regards,
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Ideas for discussion (Issue #567)

2018-10-31 Thread Julen Landa Alustiza 
that will allow us to install a working enviroment if there is something
broken on u-t or if there is something broken on the compose and fixed on
u-t since we will be able to add the repo during install process.

Would be great to have a disabled by default checkbox on additional repos
windows so we don't have to add manually u-t repo when the broken package
is on the compose

El mié., 31 oct. 2018 15:09, Stephen Gallagher 
escribió:

> On Wed, Oct 31, 2018 at 10:01 AM Kamil Paral  wrote:
> >
> > On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka 
> wrote:
> >>
> >> Hello,
> >> I have been assigned to organize a discussion about this issue
> https://pagure.io/fedora-qa/issue/567.
> >>
> >> I have thought about some possibilities (see lower or the issue) how
> the behaviour should be defined. I would like you to comment on it and add
> your ideas to the material. I hope this discussion will result in one
> transparent, documented and testable scenario in the end.
> >>
> >> Thanks a lot.
> >> Lukas
> >
> >
> > I agree with Stephen at
> https://pagure.io/fedora-qa/issue/567#comment-538601 , this might be a
> misunderstanding. I don't think we need to change when updates-testing is
> enabled/disabled in the installed system. That seems to be working quite
> fine. But we want to define how anaconda should behave when installing from
> online repos, whether it should use updates-testing for installation or
> not, or when.
> >
> > So the possible options probably are:
> > * always disabled during installation
> > * always enabled during installation up to the final RC
> > * respect the default values in fedora-repos (enabled only as long as it
> is enabled in the installed system). Note that this is likely decided at
> compose time.
> >
> > And then we need to define what happens when the user enables/disables
> additional updates using the checkbox in "installation source" spoke. Or,
> in case we keep updates-testing enabled at least sometime, whether the GUI
> should change somehow to reflect that.
>
>
> I want to cast a vote that anaconda should never enable the
> updates-testing repository absent an explicit user request (such as
> adding them as supplementary install sources). The advantage here is
> that we are far more likely to succeed with installations and then
> testing will take place once they have a viable starting point.
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Ideas for discussion (Issue #567)

2018-10-31 Thread Julen Landa Alustiza 
I'm agree with stephen & kparal too.

For anaconda, I would prefer always disabled or respect fedora-release

El mié., 31 oct. 2018 15:01, Kamil Paral  escribió:

> On Wed, Oct 31, 2018 at 2:48 PM Lukas Ruzicka  wrote:
>
>> Hello,
>> I have been assigned to organize a discussion about this issue
>> https://pagure.io/fedora-qa/issue/567.
>>
>> I have thought about some possibilities (see lower or the issue) how the
>> behaviour should be defined. I would like you to comment on it and add your
>> ideas to the material. I hope this discussion will result in one
>> transparent, documented and testable scenario in the end.
>>
>> Thanks a lot.
>> Lukas
>>
>
> I agree with Stephen at
> https://pagure.io/fedora-qa/issue/567#comment-538601 , this might be a
> misunderstanding. I don't think we need to change when updates-testing is
> enabled/disabled in the installed system. That seems to be working quite
> fine. But we want to define how anaconda should behave when installing from
> online repos, whether it should use updates-testing for installation or
> not, or when.
>
> So the possible options probably are:
> * always disabled during installation
> * always enabled during installation up to the final RC
> * respect the default values in fedora-repos (enabled only as long as it
> is enabled in the installed system). Note that this is likely decided at
> compose time.
>
> And then we need to define what happens when the user enables/disables
> additional updates using the checkbox in "installation source" spoke. Or,
> in case we keep updates-testing enabled at least sometime, whether the GUI
> should change somehow to reflect that.
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Request Testing on 1637751 - gnome-maps

2018-10-19 Thread Julen Landa Alustiza 
Tested 3.30.1 on bare metal, i78550U . I suffer the bug here too.

btw, gnome-maps --version throws an error

Hau idatzi du Firas Dieter Nuwayhid (f.d.nuway...@outlook.com)
erabiltzaileak (2018 urr. 18, og. (11:44)):

> On my local machine the artefacts looks different after following the
> steps.
>
> The sidebar for the planning of the route doen't appear at all.
>
> Even more interesting: if I use the integrated screenshot-tool to take a
> screenshot of the window - the map disappears and the route plan side bar
> is visible. If I select a rectangle of the screen the map becomes visible
> and the sidebar invisible (s. attachments).
> --
> *From:* Geoffrey Marr 
> *Sent:* Wednesday, October 17, 2018 4:03 AM
> *To:* test@lists.fedoraproject.org
> *Subject:* Request Testing on 1637751 - gnome-maps
>
> Testers,
>
> One of the current blockers for F29 Final is this bug regarding
> gnome-maps: [0]
>
> Based off the comments in-bug it seems that there is conflicting data
> regarding whether or not this is an isolated instance or a widespread
> issue. Can you please view the bug above, run the quick test, and report
> in-bug your findings?
>
> TL;DR
> Update to latest F29
> Ensure running gnome-maps-3.30.1-1.fc29
> Open gnome-maps
> Right click anywhere, select "Route from here", ensure that window on
> right of screen opens with no strange artefacts. Also, resize window and
> make sure no artefacts. See video here for example of wrong behavior: [1]
>
> Thanks!
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1637751
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1637751=02%7C01%7C%7C2c0d4dca2efc42e87caa08d633d4d8c4%7C84df9e7fe9f640afb435%7C1%7C0%7C636753386594134402=rBavOn%2FevfaVBQJKx%2BYz9nsX%2FZ%2F0%2FVdNG8M0VeeLFRw%3D=0>
> [1] https://bugzilla.redhat.com/attachment.cgi?id=1492297
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fattachment.cgi%3Fid%3D1492297=02%7C01%7C%7C2c0d4dca2efc42e87caa08d633d4d8c4%7C84df9e7fe9f640afb435%7C1%7C0%7C636753386594134402=uucy2B%2FU%2FaxmgTtr0Erjt9G%2FQ7jCLkH9Jj23VYhZGn4%3D=0>
>
> Geoff Marr
> IRC: coremodule
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>


-- 
Julen Landa Alustiza 
 gnome-maps --version

(org.gnome.Maps:4284): Gjs-WARNING **: 19:26:11.529: Some code called 
array.toString() on a Uint8Array instance. Previously this would have 
interpreted the bytes of the array as a string, but that is nonstandard. In the 
future this will return the bytes as comma-separated digits. For the time 
being, the old behavior has been preserved, but please fix your code anyway to 
explicitly call ByteArray.toString(array).
(Note that array.toString() may have been called implicitly.)
0  ["resource:///org/gnome/Maps/js/osmTypes.js":32]
1  ["resource:///org/gnome/Maps/js/osmEditDialog.js":35]
2  ["resource:///org/gnome/Maps/js/osmEdit.js":25]
3  ["resource:///org/gnome/Maps/js/contextMenu.js":33]
4  ["resource:///org/gnome/Maps/js/mainWindow.js":33]
5  ["resource:///org/gnome/Maps/js/application.js":35]
6  ["resource:///org/gnome/Maps/js/main.js":43]
7 start() ["resource:///org/gnome/gjs/modules/package.js":209]
8  ["/usr/bin/gnome-maps":2]


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: About dnf 4.0.4

2018-10-18 Thread Julen Landa Alustiza 
I've been reading all the release criterias after founding the bug and I
don't see any violated criteria.

My concern more than being blocker or not is about being a major version
upgrade during freezing that creates at least one new regression because
it's a version that changes much more than just fixing the blocker and
freeze exception bugs.

El jue., 18 oct. 2018 14:43, Kamil Paral  escribió:

> On Thu, Oct 18, 2018 at 2:37 PM Matthew Miller 
> wrote:
>
>> Please nominate it as a blocker.
>>
>
> We already talked about it with the DNF team and I don't think there's any
> release criterion that this would violate. But they're trying to have it
> fixed before final release.
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

About dnf 4.0.4

2018-10-18 Thread Julen Landa Alustiza 
Hi!

Last monday we sent 4.0.4 inclusion during freezing to fesco during the
blocker bugs review meeting[1].

Yesterday I found a new bug on 4.0.4[2] that doesn't occure on 3.5.1 of
fc29 beta 1.5 .

I think that fesco should know about this issue, but I don't know how
should qa proceed in this case. Should I write a comment on fesco issue?
Should we discuss this during today meeting?

Dunno how to proceed :D

Regards,

[1]: https://pagure.io/fesco/issue/2001
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1640235
-- 
Julen Landa Alustiza 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Request Testing on 1637751 - gnome-maps

2018-10-17 Thread Julen Landa Alustiza 
I'll try asap.

El mié., 17 oct. 2018 17:37, Geoffrey Marr  escribió:

> Julen,
>
> Thanks for testing. If possible, can you try testing on a bare-metal
> install and see if you have the glitch?
>
> Geoff Marr
> IRC: coremodule
>
>
> On Wed, Oct 17, 2018 at 9:26 AM Julen Landa Alustiza 
> wrote:
>
>> Just tried on a vm with libvirt, I have the glitch
>>
>> El mié., 17 oct. 2018 4:04, Geoffrey Marr  escribió:
>>
>>> Testers,
>>>
>>> One of the current blockers for F29 Final is this bug regarding
>>> gnome-maps: [0]
>>>
>>> Based off the comments in-bug it seems that there is conflicting data
>>> regarding whether or not this is an isolated instance or a widespread
>>> issue. Can you please view the bug above, run the quick test, and report
>>> in-bug your findings?
>>>
>>> TL;DR
>>> Update to latest F29
>>> Ensure running gnome-maps-3.30.1-1.fc29
>>> Open gnome-maps
>>> Right click anywhere, select "Route from here", ensure that window on
>>> right of screen opens with no strange artefacts. Also, resize window and
>>> make sure no artefacts. See video here for example of wrong behavior: [1]
>>>
>>> Thanks!
>>>
>>> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1637751
>>> [1] https://bugzilla.redhat.com/attachment.cgi?id=1492297
>>>
>>> Geoff Marr
>>> IRC: coremodule
>>> ___
>>> test mailing list -- test@lists.fedoraproject.org
>>> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>>>
>> ___
>> test mailing list -- test@lists.fedoraproject.org
>> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Request Testing on 1637751 - gnome-maps

2018-10-17 Thread Julen Landa Alustiza 
Just tried on a vm with libvirt, I have the glitch

El mié., 17 oct. 2018 4:04, Geoffrey Marr  escribió:

> Testers,
>
> One of the current blockers for F29 Final is this bug regarding
> gnome-maps: [0]
>
> Based off the comments in-bug it seems that there is conflicting data
> regarding whether or not this is an isolated instance or a widespread
> issue. Can you please view the bug above, run the quick test, and report
> in-bug your findings?
>
> TL;DR
> Update to latest F29
> Ensure running gnome-maps-3.30.1-1.fc29
> Open gnome-maps
> Right click anywhere, select "Route from here", ensure that window on
> right of screen opens with no strange artefacts. Also, resize window and
> make sure no artefacts. See video here for example of wrong behavior: [1]
>
> Thanks!
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1637751
> [1] https://bugzilla.redhat.com/attachment.cgi?id=1492297
>
> Geoff Marr
> IRC: coremodule
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: proposal: drop optical media from release criteria

2018-09-20 Thread Julen Landa Alustiza 
I keep an optical driver in a box under the desk, it might be useful
someday.

I haven't used it for years. So yeah, it's time to clean the box

El jue., 20 sept. 2018 20:26, Richard Shaw  escribió:

> On Thu, Sep 20, 2018 at 12:49 PM Matthew Miller 
> wrote:
>
>> Justification:
>> http://newsthump.com/2018/05/21/man-decides-to-keep-box-of-cables-hes-has-since-2002-for-another-year/
>
>
> Ouch, that stings just a little :) But yeah, I have burned an install disk
> in years.
>
> Thanks,
> Richard
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: F29 network issues

2018-07-20 Thread Julen Landa Alustiza 
Adam said on the last meeting that there was an known issue with
NetworkManager not starting properly somethings.

sudo systemctl start NetworkManager should repair your issue until it's
fixed

El vie., 20 jul. 2018 14:19, Alessio Ciregia  escribió:

> Using F29 I've spotted that sometimes (1 time every 5 reboots, more or
> less) the network interface doesn't work. Upon reboots, the network
> address of the ethernet interface is not configured.
>
> Issuing the command
>   nmcli connection show
> I get that the NetworkManager is not running.
> Starting the service, the network start to work.
>
> I've spotted this issue on two F29 installations.
> How to diagnose this behaviour?
>
> Ciao,
> A.
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/ZLAT7ECYLPILVTPVIF5HBSUKBQTEETSB/
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/J5MKDBQYHUMMZROPFOQ6YTMFQI4JV4LO/

Re: 2018-06-11 @ 15:00 UTC - Fedora QA Meeting - Minutes

2018-06-12 Thread Julen Landa Alustiza 

Some progress updates...

On fc28, after installing libtirpc-devel and applying 
https://pagure.io/kernel-tests/pull-request/18 the performance test can 
be compiled and it PASS on a fc28 server KVM guest, but committing the 
pull-request will break the test suite on fc27 and earlier.



IMHO the fast, ugly but working solution would be creating a branch for 
> fc28 until some kind of ./configure is included on kernel-tests 
project and update the regression test's wiki page with proper for > 27 
version instructions. I tried to edit it, but I can't since my FAS 
account is not member of any group.



Regards,


ar., 2018.eko ekaren 12a 10:38(e)an, Sumantro Mukherjee igorleak idatzi 
zuen:


- Original Message -

From: pmkel...@frontier.com
To: test@lists.fedoraproject.org
Sent: Tuesday, June 12, 2018 12:07:29 AM
Subject: Re: 2018-06-11 @ 15:00 UTC - Fedora QA Meeting - Minutes



On 06/11/2018 12:20 PM, Adam Williamson wrote:

==
#fedora-meeting: Fedora QA Meeting
==


Meeting started by adamw at 15:00:03 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2018-06-11/fedora-qa.2018-06-11-15.00.log.html
.



Meeting summary
---
* Roll call  (adamw, 15:00:12)

* Previous meeting follow-up  (adamw, 15:02:29)
* "adamw to follow up on crypto and grub Change proposals with
  concerns about 'how to test' sections" - I did that, there's been
  some follow-up discussion on devel@  (adamw, 15:03:02)
* "adamw to draft proposal to drop the kickstart criterion" - I also
  did that, and the proposal was generally +1ed, I will likely go
  ahead and make the change this week  (adamw, 15:03:27)
* ACTION: adamw to implement removal of kickstart package criterion
  (adamw, 15:03:35)
* LINK: https://fedoraproject.org/wiki/Changes/ModulesForEveryone
  (sgallagh, 15:06:32)

* Modularity testing coverage  (adamw, 15:08:45)
* ACTION: adamw to file ticket for writing permanent modularity test
  cases, adding them to the validation matrix, tag sumantrom, sgallagh
  and langdon  (adamw, 15:17:46)

* Onboarding status  (adamw, 15:20:45)
* onboarding meeting is pencilled in for 2018-06-19, please come along
  if you would find it helpful or you want to help onboard some new
  members!  (adamw, 15:24:00)

* Open floor  (adamw, 15:25:55)
* kernel 4.17 test day is tomorrow, 2018-06-12 - be there or be
  square!  (adamw, 15:26:50)
* LINK:
  https://fedoraproject.org/wiki/Test_Day:2018-06-12_Kernel_4.17_Test_Day
  (adamw, 15:27:09)

Meeting ended at 15:39:20 UTC.




Action Items

* adamw to implement removal of kickstart package criterion
* adamw to file ticket for writing permanent modularity test cases,
adding them to the validation matrix, tag sumantrom, sgallagh and
langdon




Action Items, by person
---
* adamw
* adamw to implement removal of kickstart package criterion
* adamw to file ticket for writing permanent modularity test cases,
  adding them to the validation matrix, tag sumantrom, sgallagh and
  langdon
* langdon
* adamw to file ticket for writing permanent modularity test cases,
  adding them to the validation matrix, tag sumantrom, sgallagh and
  langdon
* sgallagh
* adamw to file ticket for writing permanent modularity test cases,
  adding them to the validation matrix, tag sumantrom, sgallagh and
  langdon
* **UNASSIGNED**
* (none)




People Present (lines said)
---
* adamw (59)
* sgallagh (17)
* zodbot (12)
* Sumantrom_ (10)
* lruzicka (7)
* Sumantrom (3)
* langdon (2)
* coremodule (2)
* frantisekz (2)
* tflink (1)
* reher (1)
* x3mboy (1)
* sumantrom[m] (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


I've looked around, but I can't find the kernel 4.17 that is to be
tested. I couldn't figure out what to do from this line from the test
day page. "A fully updated [XYZ test day image] or Fedora 28
Workstation...". I have F28 fully up to date and it's at 4.16.14-300. I
looked around in the few places I know to look in koji and couldn't find
it. I'll appreciate it if someone can send me a link.

Have a Great Day!

Pat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q6ITN5KPWARKIXLDB3G2S2CTXNK7LJVD/


Hey Pat,

The image link is updated and you can start testing :)

Thanks
//sumantrom
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an

Re: 2018-06-11 @ 15:00 UTC - Fedora QA Meeting - Minutes

2018-06-12 Thread Julen Landa Alustiza 
The performance test is not compiling on fc28 due to rpc/rpc.h stuff

El mar., 12 jun. 2018 10:38, Sumantro Mukherjee 
escribió:

>
>
> - Original Message -
> > From: pmkel...@frontier.com
> > To: test@lists.fedoraproject.org
> > Sent: Tuesday, June 12, 2018 12:07:29 AM
> > Subject: Re: 2018-06-11 @ 15:00 UTC - Fedora QA Meeting - Minutes
> >
> >
> >
> > On 06/11/2018 12:20 PM, Adam Williamson wrote:
> > > ==
> > > #fedora-meeting: Fedora QA Meeting
> > > ==
> > >
> > >
> > > Meeting started by adamw at 15:00:03 UTC. The full logs are available
> at
> > >
> https://meetbot.fedoraproject.org/fedora-meeting/2018-06-11/fedora-qa.2018-06-11-15.00.log.html
> > > .
> > >
> > >
> > >
> > > Meeting summary
> > > ---
> > > * Roll call  (adamw, 15:00:12)
> > >
> > > * Previous meeting follow-up  (adamw, 15:02:29)
> > >* "adamw to follow up on crypto and grub Change proposals with
> > >  concerns about 'how to test' sections" - I did that, there's been
> > >  some follow-up discussion on devel@  (adamw, 15:03:02)
> > >* "adamw to draft proposal to drop the kickstart criterion" - I also
> > >  did that, and the proposal was generally +1ed, I will likely go
> > >  ahead and make the change this week  (adamw, 15:03:27)
> > >* ACTION: adamw to implement removal of kickstart package criterion
> > >  (adamw, 15:03:35)
> > >* LINK: https://fedoraproject.org/wiki/Changes/ModulesForEveryone
> > >  (sgallagh, 15:06:32)
> > >
> > > * Modularity testing coverage  (adamw, 15:08:45)
> > >* ACTION: adamw to file ticket for writing permanent modularity test
> > >  cases, adding them to the validation matrix, tag sumantrom,
> sgallagh
> > >  and langdon  (adamw, 15:17:46)
> > >
> > > * Onboarding status  (adamw, 15:20:45)
> > >* onboarding meeting is pencilled in for 2018-06-19, please come
> along
> > >  if you would find it helpful or you want to help onboard some new
> > >  members!  (adamw, 15:24:00)
> > >
> > > * Open floor  (adamw, 15:25:55)
> > >* kernel 4.17 test day is tomorrow, 2018-06-12 - be there or be
> > >  square!  (adamw, 15:26:50)
> > >* LINK:
> > >
> https://fedoraproject.org/wiki/Test_Day:2018-06-12_Kernel_4.17_Test_Day
> > >  (adamw, 15:27:09)
> > >
> > > Meeting ended at 15:39:20 UTC.
> > >
> > >
> > >
> > >
> > > Action Items
> > > 
> > > * adamw to implement removal of kickstart package criterion
> > > * adamw to file ticket for writing permanent modularity test cases,
> > >adding them to the validation matrix, tag sumantrom, sgallagh and
> > >langdon
> > >
> > >
> > >
> > >
> > > Action Items, by person
> > > ---
> > > * adamw
> > >* adamw to implement removal of kickstart package criterion
> > >* adamw to file ticket for writing permanent modularity test cases,
> > >  adding them to the validation matrix, tag sumantrom, sgallagh and
> > >  langdon
> > > * langdon
> > >* adamw to file ticket for writing permanent modularity test cases,
> > >  adding them to the validation matrix, tag sumantrom, sgallagh and
> > >  langdon
> > > * sgallagh
> > >* adamw to file ticket for writing permanent modularity test cases,
> > >  adding them to the validation matrix, tag sumantrom, sgallagh and
> > >  langdon
> > > * **UNASSIGNED**
> > >* (none)
> > >
> > >
> > >
> > >
> > > People Present (lines said)
> > > ---
> > > * adamw (59)
> > > * sgallagh (17)
> > > * zodbot (12)
> > > * Sumantrom_ (10)
> > > * lruzicka (7)
> > > * Sumantrom (3)
> > > * langdon (2)
> > > * coremodule (2)
> > > * frantisekz (2)
> > > * tflink (1)
> > > * reher (1)
> > > * x3mboy (1)
> > > * sumantrom[m] (1)
> > >
> > >
> > >
> > >
> > > Generated by `MeetBot`_ 0.1.4
> > >
> > > .. _`MeetBot`: http://wiki.debian.org/MeetBot
> > >
> >
> > I've looked around, but I can't find the kernel 4.17 that is to be
> > tested. I couldn't figure out what to do from this line from the test
> > day page. "A fully updated [XYZ test day image] or Fedora 28
> > Workstation...". I have F28 fully up to date and it's at 4.16.14-300. I
> > looked around in the few places I know to look in koji and couldn't find
> > it. I'll appreciate it if someone can send me a link.
> >
> >   Have a Great Day!
> >
> >   Pat
> > ___
> > test mailing list -- test@lists.fedoraproject.org
> > To unsubscribe send an email to test-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q6ITN5KPWARKIXLDB3G2S2CTXNK7LJVD/
>
>
> Hey Pat,
>
> The image link is updated and you can start testing :)
>
> Thanks
> //sumantrom
> >
>