Re: Managing stream (arbitrary) branch and module lifecycles

[Randy Barlow]

On 9/20/18 1:56 PM, Matthew Miller wrote:
> If it's "they'll find out when dnf system-upgrade errors out!", then see
> above. I'm ... not enthused. Something in dnf system-upgrade needs to do it;
> possibly a "dnf system-upgrade prep" step before "download".

I agree. Would it be feasible for the system-upgrade plugin to prompt
the user with "hey, you are using 1.7 but you need to switch to 1.8 to
upgrade. Proceed? (y/N)".



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Packages with cicku as admin or with commit access

[Jonathan Underwood]

On Thu, 20 Sep 2018 at 18:17, Jonathan Underwood
 wrote:
>
> Hi,
>
> In the process of orphaning a few packages lately, I noticed that the
> user "cicku" (Christopher Meng) still had commit or admin privelidges
> on the package. That user hasn't been active for a couple of years,
> and I vaguely remember packages that he owned being orphaned. But, it
> seems like packages where he was co-maintainer had no changes.
>
> Is this desirable for inactive developers? What if their account
> became compromised? Would it be better if the inactive maintainer
> process removed priviliges across all packages, rather than only
> orphaning the packages they own?
>

I forgot to add this ticket for the relevant non-responsive maintainer
ticket: https://pagure.io/fesco/issue/1542
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Disabling build options for SSE on non-capable arches ?

[David Timms]

On 20/09/18 09:38, Sérgio Basto wrote:
> On Thu, 2018-09-20 at 07:58 +1000, David Timms wrote:
> The conditional is correct but [1] from the previous %endif you leave
> two blanks lines which you can't, one blank line makes terminate the
> ./configure command and so last option "--disable-sse" is not included
> in build, you may check build.log [2] and you don't find any "
> --disable-sse" 

OK, thanks, guys. I had already noticed the blank lines removed and
commited, but my git foo can't have been on the ball. I was also getting
a clog generated which had the comment from an earlier commit - another
thing I don't understand.

Once properly committed, build succeeded on f27 on copr, so commited to
Fedora, and awaiting success!
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

[Test-Announce] (no subject)

[Ben Cotton]

The Fedora 29 Beta RC5 compose [1] is GO and is going to be shipped
live on Tuesday, September 25, 2018.

For more information please check the Go/No-Go meeting minutes [2] or logs [3].

Thank you to everyone who has and still is working on this release!

[1] http://dl.fedoraproject.org/pub/alt/stage
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-20/f29-beta-go_no_go-meeting.2018-09-20-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-09-20/f29-beta-go_no_go-meeting.2018-09-20-17.00.log.html

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Matthew Miller]

On Thu, Sep 20, 2018 at 04:20:49PM +0200, Adam Samalik wrote:
> > > And when that module is EOL, what is the user experience?
> > What I described in my reply earlier: the upgrade should not work and
> > the user should be required to switch to a new stream on their current
> > environment first. Which, of course, implies that we need a policy
> > requiring overlap.
> 
> Or a way of specifying a target stream during the update.

One possibility would be to add "--upgrade-obsolete-modules". But I'm not
liking that because we get into a circus of:

1. Trying dnf-upgrade download
2. Get errors
3. Add --allowerasing --best
4. Try again
5. Get errors
6. Seriously though, remove some i386 packages
7. Try again
8. Oh, now my modules are failing. 
9. Add another option.
10. Try again?

I mean, at this rate, we're never going to get to ???, let alone "profit!"


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Matthew Miller]

On Thu, Sep 20, 2018 at 09:35:41AM -0400, Stephen Gallagher wrote:
> > > Independently of this, you could also retire 1.7 with the end of F27 if
> > > there was no need to have it in the future releases.
> > Is there a way for users to say "keep me on whatever module is the default"
> > when upgrading?
> That would be a violation of the design principle that users should
> never have their module stream change underneath them without their
> consent.

That's fine and all, but I don't want to violate a different principle:
release-to-release updates on Fedora should be painless. Modularity is
supposed to make that better. The no-switch-without-consent design principle
is fine, but in order for these two things to both be true, we need a better
UX than erroring out and hoping the user knows what to do.

> Now, it gets a little trickier when we talk about upgrades from a
> release that supports 1.7 to one that no longer does... in that case I
> believe our expected behavior is that the user is expected to switch
> to the newer stream *before* initiating the upgrade process. So they'd
> do:
> 
> ```
> dnf module enable foomodule:1.8
> dnf distro-sync
> dnf system-upgrade --releasever=nextversion download
> ```

How do they know they need to do the former?

If it's "they'll find out when dnf system-upgrade errors out!", then see
above. I'm ... not enthused. Something in dnf system-upgrade needs to do it;
possibly a "dnf system-upgrade prep" step before "download".

Also, since we're enabling modules on Workstation, what happens in GNOME
Software?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Packages with cicku as admin or with commit access

[Jonathan Underwood]

Hi,

In the process of orphaning a few packages lately, I noticed that the
user "cicku" (Christopher Meng) still had commit or admin privelidges
on the package. That user hasn't been active for a couple of years,
and I vaguely remember packages that he owned being orphaned. But, it
seems like packages where he was co-maintainer had no changes.

Is this desirable for inactive developers? What if their account
became compromised? Would it be better if the inactive maintainer
process removed priviliges across all packages, rather than only
orphaning the packages they own?

Cheers,
Jonathan
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Chris Murphy]

On Thu, Sep 20, 2018 at 10:22 AM, Peter Robinson  wrote:
>> There was a bug[1] filed recently that indicated that printing was
>> broken on certain printers. As a result of that discussion, it became
>> apparent that there was no criteria for printing to work at all, which
>> seems like an oversight.
>>
>> I discussed this briefly with Matthias Clasen this morning and he
>> agreed that this should be treated as blocking for Workstation.
>>
>> I'd like to propose that we add the following criteria to Beta for Fedora 
>> 30+:
>> * Printing must work on at least one printer available to Fedora QA.
>> "Work" is defined as the output from the device matching a preview
>> shown on the GNOME print preview display. (Note that differences in
>> color reproduction are not considered "non-working".)
>>
>> and this to Final for Fedora 30+:
>> * Printing must work on at least one printer using each of the
>> following drivers:
>> (I don't know which ones to specify here, but we ought to try to
>> figure out a cross-section that covers a large swath of our expected
>> user base).
>
> I'm against this as a blocker for a number of reasons:
> * When we've tried to do hardware specific blocking at the time like
> dual boot with MacOS this has not worked well and the dual boot is
> testable with one piece of hardware
> * It's easy to do a zero day update or a standard update to fix it
> post release as doesn't affect the install path
> * We don't do it for other non critical hardware selections such as
> digital cameras, video cameras, and other such things
> * Hardware availability, I don't see blocking for one type of printer
> over another type is a good use of our time.


I think it's reasonable to block on some really basic aspects of
printing breakage, like not being able to print to a PDF file, and
possibly being unable to print to the far simpler realm of IPP
Everywhere printers.

But model specific stuff. No way. I'd be generous with freeze
exceptions, but not blocking the release. I'm even on the fence if I'd
actually block on IPP Everywhere printing being broken. Once we're at
a blocker, do we have the resources to get it fixed within a few days?
If not, forget it. It can't be a blocker if we don't have the
resources to support fixing the blocker in a time escalated manner.


-- 
Chris Murphy
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Peter Robinson]

> There was a bug[1] filed recently that indicated that printing was
> broken on certain printers. As a result of that discussion, it became
> apparent that there was no criteria for printing to work at all, which
> seems like an oversight.
>
> I discussed this briefly with Matthias Clasen this morning and he
> agreed that this should be treated as blocking for Workstation.
>
> I'd like to propose that we add the following criteria to Beta for Fedora 30+:
> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that differences in
> color reproduction are not considered "non-working".)
>
> and this to Final for Fedora 30+:
> * Printing must work on at least one printer using each of the
> following drivers:
> (I don't know which ones to specify here, but we ought to try to
> figure out a cross-section that covers a large swath of our expected
> user base).

I'm against this as a blocker for a number of reasons:
* When we've tried to do hardware specific blocking at the time like
dual boot with MacOS this has not worked well and the dual boot is
testable with one piece of hardware
* It's easy to do a zero day update or a standard update to fix it
post release as doesn't affect the install path
* We don't do it for other non critical hardware selections such as
digital cameras, video cameras, and other such things
* Hardware availability, I don't see blocking for one type of printer
over another type is a good use of our time.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Zdenek Dohnal]

Hi,

as CUPS maintainer, I agree with the idea of working printing as beta
criteria for Fedora.

I have two printers (Canon, HP) at my disposal, which I test cups,
cups-filters and hplip on when they have rebase. IMO it would be perfect
if such tests can be run every time when a component, which CUPS
requires, have an update - this way I could get know of glibc change or
nsswitch change sooner...

I can cover two printer driver software, hplip and foomatic-db+foomatic
with this testing (at least for these two printer models), but I would
need other printers for others (like gutenprint, foo2zjs, not mention
3rd party ones like brother, lexmark, epson) and especially a printer
which is capable of driver-less printing (like IPP everywhere standard,
or Airprint), which is the newest way how to install printers (I mean
most printers with release date after 2010). It would be great that we
can test it out too...

This way I would like to reach who they have such printers and asked
them for cooperation with testing - preferably on every cups update test
if printer works as it should.

According cups-pdf, which is different project and isn't under my
maintenance, I'm not sure, but I'm CCing cups-pdf maintainer, if he can
say more about it. The same can be said about ghostscript - it should be
tested properly too.

On 9/20/18 4:21 PM, Chris Murphy wrote:
>
>
> On Thu, Sep 20, 2018, 7:50 AM Stephen Gallagher  > wrote:
>
> On Thu, Sep 20, 2018 at 9:47 AM Ben Cotton  > wrote:
> >
> > On Thu, Sep 20, 2018 at 8:33 AM Stephen Gallagher
> mailto:sgall...@redhat.com>> wrote:
> > >
> > > I'd like to propose that we add the following criteria to Beta
> for Fedora 30+:
> > > * Printing must work on at least one printer available to
> Fedora QA.
> > > "Work" is defined as the output from the device matching a preview
> > > shown on the GNOME print preview display. (Note that
> differences in
> > > color reproduction are not considered "non-working".)
> > >
> > +1 to this
> >
> > > and this to Final for Fedora 30+:
> > > * Printing must work on at least one printer using each of the
> > > following drivers:
> > > (I don't know which ones to specify here, but we ought to try to
> > > figure out a cross-section that covers a large swath of our
> expected
> > > user base).
>
>
>
> Print to file (PDF) is available by default and should be in the list. 
> " work" means
> - creates a file that, when opened with the default PDF reader and in
> Firefox using its built-in PDF support, is reasonably similar to
> the preview shown on the GNOME print preview display.
>
> As for a real printer, I suggest limiting it to an IPP Everywhere
> printer (any make and model), also known as driverless printing.
>
> Otherwise you can quickly get stuck in the mud.
>
>
>
>  So I'd suggest that this criteria
> essentially means "We block if it is *known* to fail".
>
>
>
> +1
>
> Chris Murphy
>
> ___
> devel mailing list -- devel@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/devel@lists.fedoraproject.org

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Orphaning several nodejs-* packages

[Stephen Gallagher]

I'm planning to orphan the following packages tomorrow, as I don't use
them any more and don't have time to maintain them properly:

* nodejs-spdx-expression-parse-v2.0.2
* nodejs-aproba-v2.0.0
* nodejs-read-package-tree
* nodejs-less-3.8.1

If anyone would like to pick them up, let me know and I'll reassign
them. Otherwise they'll be orphaned sometime tomorrow.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Fedora 29 Beta Bug

[Chris Murphy]

On Thu, Sep 20, 2018, 5:05 AM Vascom  wrote:

> Hi all.
>
> I have big bug with Fedora 29 Beta Candidate 1.5.
> Live-usb just stuck boot just before start graphical mode. I am can't
> understand what component causes this so can't create bugreport in
> bugzilla.
>
> This happen on my netbook Asus 1225c with Atom N2800 and gma500
> graphics. The same behaviour I see when update installed F28 to F29.
> Upgrade complete good but after reboot it stuck when sddm must start.
> It can normal boot only in text mode and can't execute startx.
>
> But all kernels (4.18.x) in F28 work good on this netbook.
>
> Please help at least locate right component for bugreport.
>


Add systemd.debug-shell=1 boot parameter at the grub menu, then switch to
tty9 once startup has failed.

journalctl -b -o short-monotonic > journal.text

Use scp journal.txt or copy it to a different USB stick to extract.


Chris Murphy
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Stephen Gallagher]

On Thu, Sep 20, 2018 at 9:12 AM Matthew Miller  wrote:
>
> On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote:
> > There is another concept in Modularity we can use here: defaults. You could
> > have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora
> > releases, but have different default for each. So in your case, F27 could
> > have 1.7 as a default and F28+ could have 1.8 as a default.
> >
> > Independently of this, you could also retire 1.7 with the end of F27 if
> > there was no need to have it in the future releases.
>
> Is there a way for users to say "keep me on whatever module is the default"
> when upgrading?

That would be a violation of the design principle that users should
never have their module stream change underneath them without their
consent.

Now, it gets a little trickier when we talk about upgrades from a
release that supports 1.7 to one that no longer does... in that case I
believe our expected behavior is that the user is expected to switch
to the newer stream *before* initiating the upgrade process. So they'd
do:

```
dnf module enable foomodule:1.8
dnf distro-sync
dnf system-upgrade --releasever=nextversion download
```
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Chris Murphy]

On Thu, Sep 20, 2018, 7:50 AM Stephen Gallagher  wrote:

> On Thu, Sep 20, 2018 at 9:47 AM Ben Cotton  wrote:
> >
> > On Thu, Sep 20, 2018 at 8:33 AM Stephen Gallagher 
> wrote:
> > >
> > > I'd like to propose that we add the following criteria to Beta for
> Fedora 30+:
> > > * Printing must work on at least one printer available to Fedora QA.
> > > "Work" is defined as the output from the device matching a preview
> > > shown on the GNOME print preview display. (Note that differences in
> > > color reproduction are not considered "non-working".)
> > >
> > +1 to this
> >
> > > and this to Final for Fedora 30+:
> > > * Printing must work on at least one printer using each of the
> > > following drivers:
> > > (I don't know which ones to specify here, but we ought to try to
> > > figure out a cross-section that covers a large swath of our expected
> > > user base).
>


Print to file (PDF) is available by default and should be in the list.
" work" means
- creates a file that, when opened with the default PDF reader and in
Firefox using its built-in PDF support, is reasonably similar to
the preview shown on the GNOME print preview display.

As for a real printer, I suggest limiting it to an IPP Everywhere printer
(any make and model), also known as driverless printing.

Otherwise you can quickly get stuck in the mud.



 So I'd suggest that this criteria
> essentially means "We block if it is *known* to fail".



+1

Chris Murphy
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Adam Samalik]

On Thu, Sep 20, 2018 at 4:17 PM Stephen Gallagher 
wrote:

> On Thu, Sep 20, 2018 at 10:16 AM Matthew Miller
>  wrote:
> >
> > On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote:
> > > > Is there a way for users to say "keep me on whatever module is the
> default"
> > > > when upgrading?
> > > If they enable the module explicitly, they will keep that stream,
> > > regardless of what the current defaults are.
> >
> > And when that module is EOL, what is the user experience?
>
> What I described in my reply earlier: the upgrade should not work and
> the user should be required to switch to a new stream on their current
> environment first. Which, of course, implies that we need a policy
> requiring overlap.
>

Or a way of specifying a target stream during the update.


> ___
> devel mailing list -- devel@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/devel@lists.fedoraproject.org
>


-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Stephen Gallagher]

On Thu, Sep 20, 2018 at 10:16 AM Matthew Miller
 wrote:
>
> On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote:
> > > Is there a way for users to say "keep me on whatever module is the 
> > > default"
> > > when upgrading?
> > If they enable the module explicitly, they will keep that stream,
> > regardless of what the current defaults are.
>
> And when that module is EOL, what is the user experience?

What I described in my reply earlier: the upgrade should not work and
the user should be required to switch to a new stream on their current
environment first. Which, of course, implies that we need a policy
requiring overlap.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Matthew Miller]

On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote:
> > Is there a way for users to say "keep me on whatever module is the default"
> > when upgrading?
> If they enable the module explicitly, they will keep that stream,
> regardless of what the current defaults are.

And when that module is EOL, what is the user experience?


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Petr Šabata]

On Thu, Sep 20, 2018 at 09:11:57AM -0400, Matthew Miller wrote:
> On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote:
> > There is another concept in Modularity we can use here: defaults. You could
> > have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora
> > releases, but have different default for each. So in your case, F27 could
> > have 1.7 as a default and F28+ could have 1.8 as a default.
> > 
> > Independently of this, you could also retire 1.7 with the end of F27 if
> > there was no need to have it in the future releases.
> 
> Is there a way for users to say "keep me on whatever module is the default"
> when upgrading?

If they enable the module explicitly, they will keep that stream,
regardless of what the current defaults are.

Explicit enablement can happen in two ways:

1. By running `dnf module enable name:stream`, or
2. by installing any package from that module.

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Stephen Gallagher]

On Thu, Sep 20, 2018 at 9:47 AM Ben Cotton  wrote:
>
> On Thu, Sep 20, 2018 at 8:33 AM Stephen Gallagher  wrote:
> >
> > I'd like to propose that we add the following criteria to Beta for Fedora 
> > 30+:
> > * Printing must work on at least one printer available to Fedora QA.
> > "Work" is defined as the output from the device matching a preview
> > shown on the GNOME print preview display. (Note that differences in
> > color reproduction are not considered "non-working".)
> >
> +1 to this
>
> > and this to Final for Fedora 30+:
> > * Printing must work on at least one printer using each of the
> > following drivers:
> > (I don't know which ones to specify here, but we ought to try to
> > figure out a cross-section that covers a large swath of our expected
> > user base).
> >
> My main concern here is making sure QA has at least one of each of the
> necessary printers. That could get large pretty quickly if we're not
> careful. I'm also concerned that we could end up blocking the final
> because a printer broke or is out of ink, or other hardware failure. I
> think I'd rather keep the Beta proposal for Final. Since we have no
> criterion currently, adding the Beta criterion is an improvement. We
> can always make the requirement more aggressive if it turns out to be
> insufficient.

We do in fact have criteria that we cannot always verify (like the
Serial-Attached SCSI criteria). In this case, we don't always test it,
but if someone who does have that hardware reports that it doesn't
work, we generally will block on it. So I'd suggest that this criteria
essentially means "We block if it is *known* to fail".
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Ben Cotton]

On Thu, Sep 20, 2018 at 8:33 AM Stephen Gallagher  wrote:
>
> I'd like to propose that we add the following criteria to Beta for Fedora 30+:
> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that differences in
> color reproduction are not considered "non-working".)
>
+1 to this

> and this to Final for Fedora 30+:
> * Printing must work on at least one printer using each of the
> following drivers:
> (I don't know which ones to specify here, but we ought to try to
> figure out a cross-section that covers a large swath of our expected
> user base).
>
My main concern here is making sure QA has at least one of each of the
necessary printers. That could get large pretty quickly if we're not
careful. I'm also concerned that we could end up blocking the final
because a printer broke or is out of ink, or other hardware failure. I
think I'd rather keep the Beta proposal for Final. Since we have no
criterion currently, adding the Beta criterion is an improvement. We
can always make the requirement more aggressive if it turns out to be
insufficient.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Matthew Miller]

On Tue, Sep 18, 2018 at 10:48:46AM +0200, Adam Samalik wrote:
> There is another concept in Modularity we can use here: defaults. You could
> have both streams 1.7 and 1.8 built for all active (non-EOL) Fedora
> releases, but have different default for each. So in your case, F27 could
> have 1.7 as a default and F28+ could have 1.8 as a default.
> 
> Independently of this, you could also retire 1.7 with the end of F27 if
> there was no need to have it in the future releases.

Is there a way for users to say "keep me on whatever module is the default"
when upgrading?




-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Jared K. Smith]

On Thu, Sep 20, 2018 at 8:40 AM Stephen Gallagher 
wrote:

> I'd like to propose that we add the following criteria to Beta for Fedora
> 30+:
> * Printing must work on at least one printer available to Fedora QA.
>


> and this to Final for Fedora 30+:
> * Printing must work on at least one printer using each of the
> following drivers:
>

I'm in agreement here -- they seem like very reasonable criteria.  As for
the printer drivers, I think that the Postscript ought to be in the list,
and perhaps something along the lines of HP LaserJet 4, as there are lots
and lots and lots of printers that try to stay compatible with that.  I'd
also love to see "Print to PDF" added to that list, as I find myself using
that more and more as time goes on.

-Jared
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

DevConf.cz CfP open

[Ben Cotton]

DevConf.cz 2019 is the 11th annual, free, Red Hat sponsored community
conference for developers, admins, DevOps engineers, testers,
documentation writers and other contributors to Open Source Linux,
middleware, virtualization, storage, cloud and mobile technologies
where FLOSS communities sync, share, and hack on upstream projects
together in the beautiful city of Brno, Czech Republic.

The CfP is now open! Ready to submit your proposal? Submit at: devconf.info/cfp

Looking for ideas? Check out this year's primary themes at
https://devconf.info/cz

Important dates
- CfP closes: *October 26, 2018*
- Accepted speakers confirmation: *November 12, 2018*
- Event dates: Friday January 25 to Sunday January 27, 2019

Questions? i...@devconf.cz

--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Petr Šabata]

On Thu, Sep 20, 2018 at 08:33:05AM -0400, Stephen Gallagher wrote:
> There was a bug[1] filed recently that indicated that printing was
> broken on certain printers. As a result of that discussion, it became
> apparent that there was no criteria for printing to work at all, which
> seems like an oversight.
> 
> I discussed this briefly with Matthias Clasen this morning and he
> agreed that this should be treated as blocking for Workstation.
> 
> I'd like to propose that we add the following criteria to Beta for Fedora 30+:
> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that differences in
> color reproduction are not considered "non-working".)
> 
> and this to Final for Fedora 30+:
> * Printing must work on at least one printer using each of the
> following drivers:
> (I don't know which ones to specify here, but we ought to try to
> figure out a cross-section that covers a large swath of our expected
> user base).

Makes sense overall.

Perhaps we could compose a list of major CUPS drivers and make
sure we test each with at least one printer.

P

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255


signature.asc
Description: PGP signature
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Blocking criteria proposal for F30+: Printing

[Vít Ondruch]

This one is interesting as well, since I was bitten by it:

https://bugzilla.redhat.com/show_bug.cgi?id=1614978


V.


Dne 20.9.2018 v 14:33 Stephen Gallagher napsal(a):
> There was a bug[1] filed recently that indicated that printing was
> broken on certain printers. As a result of that discussion, it became
> apparent that there was no criteria for printing to work at all, which
> seems like an oversight.
>
> I discussed this briefly with Matthias Clasen this morning and he
> agreed that this should be treated as blocking for Workstation.
>
> I'd like to propose that we add the following criteria to Beta for Fedora 30+:
> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that differences in
> color reproduction are not considered "non-working".)
>
> and this to Final for Fedora 30+:
> * Printing must work on at least one printer using each of the
> following drivers:
> (I don't know which ones to specify here, but we ought to try to
> figure out a cross-section that covers a large swath of our expected
> user base).
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
> ___
> devel mailing list -- devel@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/devel@lists.fedoraproject.org
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

[Test-Announce] Re: Fedora 29 Candidate Beta-1.5 Available Now!

[Sinny Kumari]

Cloud Base and Atomic Host AMIs are available to test for various regions.

Cloud Base AMIs are here:
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-northeast-1
ami-0a24cb0b129391f91  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-northeast-2
ami-025a265da1a333635  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-south-1
ami-032f4d743f5c677bb  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-southeast-1
ami-0e014a47fd58202e1  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-southeast-2
ami-04f1eafc8d8cef238  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ca-central-1
ami-0423d7ead4d36fc13  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  eu-central-1
ami-0097aa31bfa6d957f  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  eu-west-1
ami-08779cabb5a70b267  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  eu-west-2
ami-0a2cafce4e146fa6f  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  sa-east-1
ami-07c85de0c364891f8  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  us-east-1
ami-0a5a4a027c594a3ee  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  us-west-1
ami-0db1697b106a42511  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  us-west-2
ami-0ae9bebb94df0dfb2  hvm  standard
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-northeast-1
ami-05cb9a208a11375a0  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-northeast-2
ami-03f32d94e35e8ee16  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-south-1
ami-08a95ab722459da46  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-southeast-1
ami-0b19c7c9c9f0e71b6  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ap-southeast-2
ami-03df355d88c07b195  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  ca-central-1
ami-02f4f27b3c8cda214  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  eu-central-1
ami-04077be43a1aa41cf  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  eu-west-1
ami-0fa29ca888e696593  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  eu-west-2
ami-09a9fa30546daec7b  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  sa-east-1
ami-0fe4b2f13a9c10b68  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  us-east-1
ami-0ef357b3f269575be  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  us-west-1
ami-0e24cc3e688d75512  hvm  gp2
Fedora-Cloud-Base-29_Beta-1.5.x86_64  us-west-2
ami-0e2412f7959332635  hvm  gp2

Atomic Host AMIs are here:
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-northeast-1
ami-0c8c3a243f8fa9389  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-northeast-2
ami-0f516fa511f7f5e73  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-south-1
ami-007c9eb1578a4688d  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-southeast-1
ami-0a0efd1bb6204159e  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-southeast-2
ami-04544eb8e7d88954e  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  ca-central-1
ami-0039a676512a0794e  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  eu-central-1
ami-0ba7d4f7df3adecd4  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  eu-west-1
ami-025df16716016af3a  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  eu-west-2
ami-0dd9376c148025bda  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  sa-east-1
ami-05851e0e3ba8fa569  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  us-east-1
ami-03630244e374b092b  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  us-west-1
ami-0455c73d39bb9d922  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  us-west-2
ami-08494e1090a21e688  hvm  standard
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-northeast-1
ami-0751c7e8531851ba0  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-northeast-2
ami-02d3a759042127f7a  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-south-1
ami-0ca9ba91af3aa6d22  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-southeast-1
ami-0ab9ca1d8d1e8353f  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  ap-southeast-2
ami-00383f891422b1ed2  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  ca-central-1
ami-075e5b73667dedb33  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  eu-central-1
ami-0716bdf9a47a23af4  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  eu-west-1
ami-0ed1063c442c97e39  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  eu-west-2
ami-0ab7b595091a81399  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  sa-east-1
ami-03952c6395be8a35d  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  us-east-1
ami-0be45426d63c7cf4a  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  us-west-1
ami-09f6c41ffc8c38a92  hvm  gp2
Fedora-AtomicHost-29_Beta-1.5.x86_64  us-west-2
ami-0e640910b38a99ad6  hvm  gp2


On Thu, Sep 20, 2018 at 11:57 AM  wrote:

> According to the schedule [1], Fedora 29 Candidate Beta-1.5 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan
>
> Test coverage information for the current release can be seen at:
> https://www.happyassassin.net/testcase_stats/29
>
> You can see all results, find tes

Blocking criteria proposal for F30+: Printing

[Stephen Gallagher]

There was a bug[1] filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.

I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.

I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)

and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
following drivers:
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
user base).


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Fedora 29 Beta Bug

[Vascom]

Hi all.

I have big bug with Fedora 29 Beta Candidate 1.5.
Live-usb just stuck boot just before start graphical mode. I am can't
understand what component causes this so can't create bugreport in
bugzilla.

This happen on my netbook Asus 1225c with Atom N2800 and gma500
graphics. The same behaviour I see when update installed F28 to F29.
Upgrade complete good but after reboot it stuck when sddm must start.
It can normal boot only in text mode and can't execute startx.

But all kernels (4.18.x) in F28 work good on this netbook.

Please help at least locate right component for bugreport.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Intent to orphan coan

[Jonathan Underwood]

Hi Adam,

On Wed, 19 Sep 2018 at 20:51, Adam Jackson  wrote:
>
> On Wed, 2018-09-19 at 00:02 +0100, Jonathan Underwood wrote:
>
> > I don't have the time to continue maintaining this package,
> > unfortunately. Please get in touch if you want to maintain the
> > package and I'll hand it over to you.
>
> I use coan fairly regularly, it seems to get a lot of things right that
> unifdef just chokes on. I'd be happy to take it.
>

Thanks - filiperosset beat you to the punch (in BZ 1626440) and I've
already transferred ownership - I am sure filiperosset would welcome
co-maintainers though!

Cheers,
Jonathan
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Fedora 29 Beta 1.5 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/132 (x86_64), 1/24 (i386), 1/2 (arm)

ID: 283213  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/283213
ID: 283219  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/283219
ID: 283307  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/283307
ID: 283323  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/283323

Soft failed openQA tests: 4/132 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 283181  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/283181
ID: 283182  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/283182
ID: 283188  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/283188
ID: 283206  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/283206
ID: 283210  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/283210
ID: 283260  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/283260

Passed openQA tests: 126/132 (x86_64), 21/24 (i386)

Skipped openQA tests: 1 of 158
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: What does 141 mean?

[Jakub Hrozek]

> On 20 Sep 2018, at 06:47, Alexander Bokovoy  wrote:
> 
> On ke, 19 syys 2018, Björn Persson wrote:
>> Alexander Bokovoy wrote:
>>> Can you provide output from
>>> 
>>> export KRB5_TRACE=/dev/stderr
>>> klist -A
>>> kinit
>>> fedpkg build
>>> 
>>> ?
>> 
>> The log is attached. I tried it twice as Tony Nelson suggested. The
>> first attempt failed as usual, but the second attempt was successful.
>> 
>> Björn Persson
> 
>> [beorn@tag gnat-srpm-macros]$ export KRB5_TRACE=/dev/stderr
>> [beorn@tag gnat-srpm-macros]$ klist -A
>> Ticket cache: KCM:1000
>> Default principal: rombobe...@fedoraproject.org
>> 
>> Valid starting   Expires  Service principal
>> 2018-09-17 05:24:43  2018-09-18 05:24:35  
>> krbtgt/fedoraproject@fedoraproject.org
>>  renew until 2018-09-24 05:24:35
>> 2018-09-17 05:27:25  2018-09-18 05:24:35  
>> HTTP/koji.fedoraproject@fedoraproject.org
>>  renew until 2018-09-24 05:24:35
>> [beorn@tag gnat-srpm-macros]$ kinit rombobe...@fedoraproject.org
>> [14092] 1537389788.507256: Getting initial credentials for 
>> rombobe...@fedoraproject.org
>> [14092] 1537389788.507258: Sending request (207 bytes) to FEDORAPROJECT.ORG
>> [14092] 1537389788.507259: Resolving hostname id.fedoraproject.org
>> [14092] 1537389788.507260: TLS certificate name matched 
>> "id.fedoraproject.org"
>> [14092] 1537389789.71948: Sending HTTPS request to https 152.19.134.142:443
>> [14092] 1537389789.71949: Received answer (322 bytes) from https 
>> 152.19.134.142:443
>> [14092] 1537389789.71950: Terminating TCP connection to https 
>> 152.19.134.142:443
>> [14092] 1537389794.417687: Response was not from master KDC
>> [14092] 1537389794.417688: Received error from KDC: -1765328359/Additional 
>> pre-authentication required
>> [14092] 1537389794.417691: Processing preauth types: 16, 15, 14, 136, 19, 
>> 147, 2, 133
>> [14092] 1537389794.417692: Selected etype info: etype aes256-cts, salt 
>> "3'Ds5@-0:LIC'DI@", params ""
>> [14092] 1537389794.417693: Received cookie: MIT
>> Password for rombobe...@fedoraproject.org:
>> [14092] 1537389816.394788: AS key obtained for encrypted timestamp: 
>> aes256-cts/3ECA
>> [14092] 1537389816.394790: Encrypted timestamp (for 1537389811.329323): 
>> plain 301AA011180F3230313830393139323034315AA105020305066B, encrypted 
>> 9D4E22D8C8E839FD08FDEF5513D8B3ECA58449937FAA393FC840524E9FBB4C5AAD7AAF5747A5F9B36B608199BB2A62A85BAED55317B1BA18
>> [14092] 1537389816.394791: Preauth module encrypted_timestamp (2) (real) 
>> returned: 0/Success
>> [14092] 1537389816.394792: Produced preauth for next request: 133, 2
>> [14092] 1537389816.394793: Sending request (302 bytes) to FEDORAPROJECT.ORG
>> [14092] 1537389816.394794: Resolving hostname id.fedoraproject.org
>> [14092] 1537389816.394795: TLS certificate name matched 
>> "id.fedoraproject.org"
>> [14092] 1537389817.98943: Sending HTTPS request to https 140.211.169.196:443
>> [14092] 1537389817.98944: Received answer (795 bytes) from https 
>> 140.211.169.196:443
>> [14092] 1537389817.98945: Terminating TCP connection to https 
>> 140.211.169.196:443
>> [14092] 1537389822.391083: Response was not from master KDC
>> [14092] 1537389822.391084: Processing preauth types: 19
>> [14092] 1537389822.391085: Selected etype info: etype aes256-cts, salt 
>> "3'Ds5@-0:LIC'DI@", params ""
>> [14092] 1537389822.391086: Produced preauth for next request: (empty)
>> [14092] 1537389822.391087: AS key determined by preauth: aes256-cts/3ECA
>> [14092] 1537389822.391088: Decrypted AS reply; session key is: 
>> aes256-cts/A5E2
>> [14092] 1537389822.391089: FAST negotiation: available
>> [14092] 1537389822.391090: Initializing KCM:1000 with default princ 
>> rombobe...@fedoraproject.org
>> [beorn@tag gnat-srpm-macros]$ echo $?
>> 141
> So there is something wrong happening right after starting to save the cred 
> into KCM credentials
> cache.
> 
> Jakub (in CC:), do you see any reason for this?

Not without logs. Please file a bug so that we can take a look.

It would be nice to:
 - edit /etc/sssd/sssd.conf
 - add:
   [kcm]
   debug_level = 10
 - systemctl restart sssd # to regenerate the configuration
 - systemctl restart sssd-kcm # restart the KCM deamon
- attach the logs at /var/log/sssd/*

> 
>> [beorn@tag gnat-srpm-macros]$ fedpkg build
>> [14333] 1537389921.736427: ccselect module realm chose cache KCM:1000 with 
>> client principal rombobe...@fedoraproject.org for server principal 
>> HTTP/koji.fedoraproject@fedoraproject.org
>> [14333] 1537389921.736428: Getting credentials rombobe...@fedoraproject.org 
>> -> HTTP/koji.fedoraproject@fedoraproject.org using ccache KCM:1000
>> [14333] 1537389921.736429: Retrieving rombobe...@fedoraproject.org -> 
>> HTTP/koji.fedoraproject@fedoraproject.org from KCM:1000 with result: 
>> -1765328243/Matching credential not found
>> [14333] 1537389921.736430: Retrieving rombobe...@fedoraproject.org -> 
>> krbtgt/fedoraproject@fedoraproject.org from KCM:1000 with result: 
>> 0/Success