Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Kamil Paral]

> Based on today's blocker review meeting discussion, and this email
> thread [1] I'd like to propose making only Fedora Media Writer the
> *officially supported* USB installation media creation tool, starting
> with Fedora 26.
> 
> The practical implication of "officially support" means bugs for which
> we'd block the release. It doesn't make sense to block the release if
> myriad tools all don't succeed. We only really need one to work, and
> Fedora Media Writer is the cross platform tool we're investing in long
> term.
> 
> The main idea of the proposal is to no longer block the release when
> Fedora Media Writer is working, but some other possibly useful ways of
> creating media aren't working. It doesn't mean those tools won't be
> fixed, or would be removed from the distribution, just means we're not
> holding up release for those alternative tools.
> 
> Comments?

Personally I'd block on FMW *and* dd. FMW uses dd-like approach internally, so 
if FMW works, dd should work as well. I'd even say that if you've successfully 
tested FMW, you can mark dd testcase passed as well. But we should still 
officially block on dd, because a) it's a universal approach, available in any 
distribution or even OS (direct copy writers exist for Windows and Mac) b) it's 
cmdline and therefore can be scripted/automated.

gnome-disks also use dd-like approach, so if dd works, gnome-disks should work 
as well modulo UI (or selinux) bugs. I'd probably not block on gnome-disks, 
because FMW does a better job as a GUI-based writer, and I don't see any extra 
benefit in gnome-disks over FMW. The only difference is that it's available in 
all distributions unlike FMW, but most probably in different versions than we 
currently have in Fedora, so blocking on it in Fedora (where we have FMW 
available) doesn't make much sense to me.

livecd-iso-to-disk seems to provide too much of an edge case functionality, so 
I wouldn't block on it either. I'm aware that persistence and non-destructive 
write is useful for some people, and this doesn't mean it will break and not 
get fixed. However, this is for a very narrow audience and I don't think 
holding up the whole release (and spending time testing it with every compose) 
is really worth it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Kamil Paral]

> > If we do not 'support' livecd-iso-to-disk any more, we no longer
> > support:
> >
> > 1) persistent storage (via overlays)
> > 2) non-destructive write
> 
> Does anyone know why we can't have Fedora Media Writer support these
> functions as well? 

I hope it won't. Or if it will, I hope it won't be the default, it will be well 
hidden, and we won't block on it. Because especially the non-destructive write 
is a can of worms. It almost never works for standard users, unless you have a 
very good understanding what a bootloader is and whether you should replace it 
or not. Most people don't need it (everyone has a small flash drive to be 
completely overwritten these days), and those who do, they can easily use 
livecd-iso-to-disk with its heap of magical cmdline switches.

So no, I don't see why our default tool which is intended to be simple and user 
friendly should support alternative modes of operations for <1% of our user 
base. Do one thing and do it well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Neal Gompa]

On Tue, Oct 4, 2016 at 3:46 AM, Kamil Paral  wrote:
>> > If we do not 'support' livecd-iso-to-disk any more, we no longer
>> > support:
>> >
>> > 1) persistent storage (via overlays)
>> > 2) non-destructive write
>>
>> Does anyone know why we can't have Fedora Media Writer support these
>> functions as well?
>
> I hope it won't. Or if it will, I hope it won't be the default, it will be 
> well hidden, and we won't block on it. Because especially the non-destructive 
> write is a can of worms. It almost never works for standard users, unless you 
> have a very good understanding what a bootloader is and whether you should 
> replace it or not. Most people don't need it (everyone has a small flash 
> drive to be completely overwritten these days), and those who do, they can 
> easily use livecd-iso-to-disk with its heap of magical cmdline switches.

That sounds more like we should revisit how we do those features
rather than anything else. When livecd-iso-to-disk was created, we
didn't have things like OverlayFS that may potentially simplify how we
support this greatly. Most flash drives I've seen in use are at least
2x larger than the Fedora images, so it's almost wasteful that we
can't leverage that extra space.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SO-NAME BUMP] jsoncpp 1.7.7 comes to rawhide (and maybe to fc25)

[Björn Esser]

Am 03.10.2016 um 06:10 schrieb Björn Esser:
Chain-build is running: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=15917326



Am 03.10.2016 um 05:38 schrieb Björn Esser:
I'm upgrading jsoncpp to v1.7.7 in Rawhide.  This will bump the 
so-name to libjsoncpp.so.11.


Affected packages:
cmake
engrid
mrpt
orthanc
paraview
pcl
vfrnav
vrpn
vtk

I'll chain-rebuild all affected packages when pushing the new version 
of jsoncpp.  If there isn't any trouble, I'll consider and prepare an 
update for fc25 as well.


Cheers
  Björn
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


All packages have been rebuilt, except for 'paraview', which FTBFS [1] 
[2].  It seems it needs a little patching for some small change in 
jsoncpp.  I will do that during the next few days.


Cheers,
  Björn


[1]  https://koji.fedoraproject.org/koji/buildinfo?buildID=806450
[2]  https://koji.fedoraproject.org/koji/buildinfo?buildID=806372
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Storing Automated Tasks/Tests In Dist-Git

[Jakub Jelen]

On 10/03/2016 09:50 PM, Tim Flink wrote:

One of the features for Taskotron that we've been planning since the
beginning was a way for contributors to maintain their own automated
tasks/tests which would be run during a package's lifecycle.

I'm happy to say that we're almost to this milestone and wanted to get
some feedback from devel@ on the specifics of what we're planning WRT
where these automated tasks will be stored and the execution modes that
we're planning to support. Our current plan is written up at:

https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/

The hope is that by making it easier for contributors to write
automated tasks and making the model completely self-service and
convention drive, there will be a lot more automated checks for
packages than we currently have for Fedora.

Please read through the wiki page I mentioned above and give us
feedback on whether what we're planning to implement is going to be
useful or if there are areas of the plan which could be improved.
Is there any way how this can be run on RHEL too once there will be some 
tests?


Is there possibility to run the tests in Beaker?

From the wiki it does not look in any way compatible with existing RHTS 
tests implemented in BeakerLib. Are there any plans to draw closer these 
initiatives in one way or the other?


Regards,

--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Storing Automated Tasks/Tests In Dist-Git (git-submodules)

[Pavel Raiskup]

On Monday, October 3, 2016 1:50:33 PM CEST Tim Flink wrote:
> https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/
> ...
> Please read through the wiki page I mentioned above and give us
> feedback on whether what we're planning to implement is going to be
> useful

Useful, yes!

> or if there are areas of the plan which could be improved.

Can we rather make the ./taskotron directory separate git submodule?  I expect
that I'm going to play with that directory a lot, without being "that much
careful" as I'm with package directories; which might mean that for packaging
work there might be a bit unpleasant rush in git-log otherwise.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] libtimidity-0.2.0 comes to rawhide

[Igor Gnatenko]

Hi,

I'm preparing update for new version. According to release notes[0],
there is only API additions and couple of changes. I will rebuild all
dependent packages:
* gstreamer-plugins-bad-free
* moc
* openttd

Before I build it in rawhide, I will try to build it in COPR.

Thanks for attention!


[0] 
https://sourceforge.net/p/libtimidity/news/2016/09/libtimidity-new-stable-version-020/
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Adam Williamson]

On Tue, 2016-10-04 at 03:50 -0400, Neal Gompa wrote:
> On Tue, Oct 4, 2016 at 3:46 AM, Kamil Paral  wrote:
> > If we do not 'support' livecd-iso-to-disk any more, we no longer
> > support:
> > 
> > 1) persistent storage (via overlays)
> > 2) non-destructive write
> 
> 
> Does anyone know why we can't have Fedora Media Writer support these
> functions as well?
> 
> 
> I hope it won't. Or if it will, I hope it won't be the default, it will be 
> well hidden, and we won't block on it. Because especially the non-destructive 
> write is a can of worms. It almost never works for standard users, unless you 
> have a very good understanding what a bootloader is and whether you should 
> replace it or not. Most people don't need it (everyone has a small flash 
> drive to be completely overwritten these days), and those who do, they can 
> easily use livecd-iso-to-disk with its heap of magical cmdline switches.
> 
> 
> That sounds more like we should revisit how we do those features
> rather than anything else. When livecd-iso-to-disk was created, we
> didn't have things like OverlayFS that may potentially simplify how we
> support this greatly. Most flash drives I've seen in use are at least
> 2x larger than the Fedora images, so it's almost wasteful that we
> can't leverage that extra space.

It's simply the case that no-one's cared enough about those features to
rewrite them. A few people have kicked around ideas for how to do it at
various points, but it's never gone beyond that.

There are other bits of the live image infrastructure that are severely
outdated too, and which no-one has chosen (or been paid) to modernize;
the obvious one is the way we do a lot of customization of the live
environment, by creating a couple of sysv services on the fly in the
%post sections of the live image kickstarts. The kickstarts in general
have a whole pile of junk in them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Martin Kolman]

On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
> On Mon, 2016-10-03 at 12:49 -0600, Chris Murphy wrote:
> > 
> > Based on today's blocker review meeting discussion, and this email
> > thread [1] I'd like to propose making only Fedora Media Writer the
> > *officially supported* USB installation media creation tool,
> > starting
> > with Fedora 26.
> > 
> > The practical implication of "officially support" means bugs for
> > which
> > we'd block the release. It doesn't make sense to block the release
> > if
> > myriad tools all don't succeed. We only really need one to work,
> > and
> > Fedora Media Writer is the cross platform tool we're investing in
> > long
> > term.
> > 
> > The main idea of the proposal is to no longer block the release
> > when
> > Fedora Media Writer is working, but some other possibly useful ways
> > of
> > creating media aren't working. It doesn't mean those tools won't be
> > fixed, or would be removed from the distribution, just means we're
> > not
> > holding up release for those alternative tools.
> > 
> > Comments?
> 
> There is currently no real way to use FMW on non-Fedora Linux
> distributions that don't a) support Flatpak and b) have an
> appropriate
> Flatpak runtime for running FMW on (beyond compiling it yourself, I
> guess).
That sounds weird - why can't it be packaged for other distros by using
the normal distro packaging mechanisms (RPM/deb,etc. packages) ?
> 
> If we do not 'support' livecd-iso-to-disk any more, we no longer
> support:
> 
> 1) persistent storage (via overlays)
> 2) non-destructive write
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedocal] Reminder meeting : Modularity WG

[Jan Kurik]

The meeting is cancelled for today.

This reminder has been sent by a mistake, probably due to a bug in
Fedocal https://fedorahosted.org/fedocal/ticket/162 .
I am sorry for any confusion this might cause.

Regards,
Jan

On Tue, Oct 4, 2016 at 5:00 AM,   wrote:
> Dear all,
>
> You are kindly invited to the meeting:
>Modularity WG on 2016-10-04 from 15:00:00 to 16:00:00 UTC
>At fedora-meetin...@irc.freenode.net
>
> The meeting will be about:
> Meeting for the Modularity Working Group.
>
> More information available at: [Modularity Working Group wiki 
> page](https://fedoraproject.org/wiki/Modularity_Working_Group)
>
> The agenda for the meeting is available at [modularity-wg-agendas 
> pad](http://piratepad.nl/modularity-wg-agendas).
>
>
>
> Source: https://apps.fedoraproject.org/calendar/meeting/4693/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 Self Contained Change: OpenSSH Crypto Policy (Client)

[Jan Kurik]

= Proposed Self Contained Change: OpenSSH Crypto Policy (Client) =
https://fedoraproject.org/wiki/Changes/OpenSSH_Crypto_Policy

Change owner(s):
* Jakub Jelen < jjelen AT redhat DOT com >

OpenSSH client will follow system-wide crypto policies already
followed by other cryptographic libraries and tools. It will allow to
use different security levels defined system-wide.


== Detailed Description ==
Currently, the set of cryptographic algorithms used in OpenSSH is
defined by upstream and Fedora just inherits what upstream considers
secure. If there are special requirements for the security, manual
modifications of the configuration files is required, which also
prevents package manager to update the configuration file with future
updates and can possibly leave enabled insecure algorithms.

Since Fedora 25 we have possibility to include configuration files
from the main ssh_config, which allowed us to include crypto policies
in the OpenSSH (client).

For more information about Crypto Policy, see the appropriate wiki
page Changes/CryptoPolicy describing the concept in whole.


== Scope ==
* Proposal owners: Default OpenSSH configuration will include the
generated policy file containing the definition of system-wide enabled
algorithms. The include must be before any other options so user
changes would not unintentionally get used instead of system-wide
policy. The policy preview is already available in the pull request on
github [ https://github.com/nmav/fedora-crypto-policies/pull/8 ].

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

devel@lists.fedoraproject.org

[Kushal Das]

On 30/09/16, Josh Berkus wrote:
> On 09/30/2016 02:01 PM, Josh Boyer wrote:
> 
> > 16:44:56  Cloud base image is the only blocking deliverable.
> > 16:44:59  Atomic is not.
> > 
> > I realize this WG is in the middle of rebooting itself, but to have
> > clearly conflicting information from the WG members is a bit
> > concerning.
> 
Atomic host image is the deliverable for the Atomic WG, which is under 2
week release cycle. We sync up with the official release version at the
time of GA, but we continue to be in our 2 week atomic release cycle
then on the 6month old GA. This is my understanding about all the work
done for 2 Week Atomic.

Now I may be completely wrong to understand our 2 week release cycle
process, but this is what I followed for the release-infra work till
now.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.in
https://dgplug.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Developer Portal - new update

[Petr Hracek]

Hi folks,

after a couple of months we have updated Fedora Developer Portal
which contains several fixes and new contents

New contents:
- Rust language [1]
- MicroPython [2]
- Leksah installation guide [3]
- Apache page [4]
- GTK+ page [5]

Fixes:
- several English typos.
- several command line fixes
- several HTML references.

Feel free to create a new content, community can use it for development and
propagation.

It's better to share your awesome knowledge.:)


[1] https://developer.stg.fedoraproject.org/tech/languages/rust/rust-
installation.html
[2] https://developer.stg.fedoraproject.org/tech/
languages/python/micropython.html

[3]
https://developer.stg.fedoraproject.org/tech/languages/haskell/leksah.html
[4] https://developer.stg.fedoraproject.org/start/sw/web-app/apache.html
[5] https://developer.stg.fedoraproject.org/tech/languages/c/gtk.html

-- 
Petr Hracek
Software Engineer
EMEA ENG Mainstream RHEL
Red Hat, Inc.
Mob: +420 777 056 169
email: phra...@redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Developer Portal - new update

[Petr Hracek]

Fix references to official Fedora Developer Portal.

On Tue, Oct 4, 2016 at 1:21 PM, Petr Hracek  wrote:

> Hi folks,
>
> after a couple of months we have updated Fedora Developer Portal
> which contains several fixes and new contents
>
> New contents:
> - Rust language [1]
> - MicroPython [2]
> - Leksah installation guide [3]
> - Apache page [4]
> - GTK+ page [5]
>
> Fixes:
> - several English typos.
> - several command line fixes
> - several HTML references.
>
> Feel free to create a new content, community can use it for development
> and propagation.
>
> It's better to share your awesome knowledge.:)
>
>
> [1] https://developer.fedoraproject.org/tech/languages/rust/
> rust-installation.html
> 
> [2] https://developer.fedoraproject.org/tech/languages/
> python/micropython.html
> 
> [3] https://developer.fedoraproject.org/tech/languages/haskell/leksah.html
> 
> [4] https://developer.fedoraproject.org/start/sw/web-app/apache.html
> 
> [5] https://developer.fedoraproject.org/tech/languages/c/gtk.html
> 
>
> --
> Petr Hracek
> Software Engineer
> EMEA ENG Mainstream RHEL
> Red Hat, Inc.
> Mob: +420 777 056 169
> email: phra...@redhat.com
>



-- 
Petr Hracek
Software Engineer
EMEA ENG Mainstream RHEL
Red Hat, Inc.
Mob: +420 777 056 169
email: phra...@redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Andrea Musuruane]

On Tue, Aug 23, 2016 at 1:54 PM, Andrea Musuruane  wrote:
>
>
> On Thu, Aug 18, 2016 at 8:25 PM, Jason L Tibbitts III 
> wrote:
>>
>> Here are the recent changes to the packaging guidelines.
>>
>> -
>>
>> The Filesystem Layout section of the guidelines was simplified and
>> outdated information was removed.
>>
>> * https://fedoraproject.org/wiki/Packaging:Guidelines
>> * https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout
>> * https://fedorahosted.org/fpc/ticket/623
>
>
> The links to FHS specs are all outdated. The current one is
> https://wiki.linuxfoundation.org/lsb/fhs
>
> Moreover I still read "The Filesystem Hierarchy Standard does not include
> any provision for libexecdir, " which is not accurate:
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

I still read the same issues. The page is protected and it cannot be
freely edited.

Bye,

Andrea
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

problems in Virtualbox

[mario . riassetto]

 I have noted a one problem in to the start of the image in Virtualbox. 
Virtualbox in fedora, not starting the virtual system installed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Ms Sanchez]

Agree with Kamil.  Do one thing and do it well.


Cheers,

Sylvia


On 04/10/16 09:46, Kamil Paral wrote:

If we do not 'support' livecd-iso-to-disk any more, we no longer
support:

1) persistent storage (via overlays)
2) non-destructive write

Does anyone know why we can't have Fedora Media Writer support these
functions as well?

I hope it won't. Or if it will, I hope it won't be the default, it will be well 
hidden, and we won't block on it. Because especially the non-destructive write 
is a can of worms. It almost never works for standard users, unless you have a 
very good understanding what a bootloader is and whether you should replace it 
or not. Most people don't need it (everyone has a small flash drive to be 
completely overwritten these days), and those who do, they can easily use 
livecd-iso-to-disk with its heap of magical cmdline switches.

So no, I don't see why our default tool which is intended to be simple and user 
friendly should support alternative modes of operations for <1% of our user 
base. Do one thing and do it well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Michael Catanzaro]

On Tue, 2016-10-04 at 03:35 -0400, Kamil Paral wrote:
> Personally I'd block on FMW *and* dd.

Yes, explicit +1 from me. dd needs to work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Storing Automated Tasks/Tests In Dist-Git

[Vít Ondruch]

Hi Tim,

How about this use case:

Let say I have Ruby on Rails. This framework is much broader then one
rubygem-rails package. Where test for such framework will be stored?

How about tests, which might cover multiple versions of components? Lets
say I will have some generic test cases which should run on Python 2 as
well as Python 3 (or MySql as well as MariadDB). Where such tests will
be stored?


Vít


Dne 3.10.2016 v 21:50 Tim Flink napsal(a):
> One of the features for Taskotron that we've been planning since the
> beginning was a way for contributors to maintain their own automated
> tasks/tests which would be run during a package's lifecycle.
>
> I'm happy to say that we're almost to this milestone and wanted to get
> some feedback from devel@ on the specifics of what we're planning WRT
> where these automated tasks will be stored and the execution modes that
> we're planning to support. Our current plan is written up at:
>
> https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/
>
> The hope is that by making it easier for contributors to write
> automated tasks and making the model completely self-service and
> convention drive, there will be a lot more automated checks for
> packages than we currently have for Fedora.
>
> Please read through the wiki page I mentioned above and give us
> feedback on whether what we're planning to implement is going to be
> useful or if there are areas of the plan which could be improved.
>
> Thanks,
>
> Tim
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Storing Automated Tasks/Tests In Dist-Git

[Matthew Miller]

On Mon, Oct 03, 2016 at 02:35:00PM -0600, Kevin Fenzi wrote:
> Another alternate here is that we could make taskotron a 'namespace'
> like currently rpms/ and docker/ are. Then we would have
> perhaps: /taskotron/rpms/foobar/ as the top level and all the rest is
> the same. This would get us a seperate pkgdb entry for the taskotron
> part of things (ie, it could have different maintainers, people allowed
> to commit, etc). That would add to complexity however. 

How much complexity in terms of ongoing maintenance? I think having
different committers is a big plus. The big downside — other than
complexity — is that the in-package-dist-git approach is very obvious
to existing packagers, whereas the namespaces are still a sort of
easter egg. Maybe we could do something in fedpkg to make it more
discoverable?

Also, if we do go with a separate namespace, how about "tests" instead
of "taskotron", with tasktron a subdir of that, and  "testcases"
another (for https://github.com/fedora-infra/bodhi/issues/942)?

> Thanks for working on all this. It's awesome to see it start to come to
> fruition!

+1


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: FAS name change

[Dridi Boukelmoune]

On Tue, Oct 4, 2016 at 8:21 AM, Sylvia  wrote:
>
> Hello Athos!
>
> Did you solve your problem in Bodhi?
>
>
> Cheers,
> Sylvia
>
>
> On Sat, 2016-10-01 at 10:55 -0300, Athos Coimbra Ribeiro wrote:
>
> Hello,
>
> [...]

Hello Sylvia,

Please avoid top-posting when replying on mailing lists.

See 
https://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message

Cheers,
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Ondřej Vašík]

Jakub Svoboda píše v Po 26. 09. 2016 v 17:36 +0200:
> 
> Hi,
> 
> 
> nologin is listed in /etc/shells since 2002 [1].

Hi,

based on the discussion, I think it is really time to remove nologin
from /etc/shells in Rawhide. Only one person objecting against the
removal is J.C. Cleaver , primarily because "bug becomes expected
feature after 14 years".
I don't think we should change this in released Fedoras ( I don't think
this is critical security hole, when you have access to local shell, it
is usually enough anyway ;) ), but adjustment in Rawhide seems
reasonable.
Any objections (other than "bug becomes expected")?

Regards,
   Ondrej


> 
> 
> This is in conflict with:
> 
> man 5 shells
> DESCRIPTION
>/etc/shells  is  a text file which contains the full pathnames
> of valid
>login shells.
> 
> 
> 
> man 8 nologin
> DESCRIPTION
>nologin  displays  a message that an account is not available
> and exits
>non-zero.  It is intended as a replacement shell field  to
> deny  login
>access to an account.
> 
> NOTES
>nologin is a per-account way to disable login (usually used for
> system
>accounts  like  http  or  ftp).
> 
> 
> man 1 su
> OPTIONS
>-s, --shell=shell
>   Run the specified shell instead of the default.
> 
>   [snip]
> 
>   If  the  target  user has a restricted shell (i.e. not
> listed in
>   /etc/shells), the --shell option and the SHELL
> environment vari‐
>   ables are ignored unless the calling user is root.
> 
> 
> Actual behavior and man pages are consistent for su and nologin and
> their behavior is affected indirectly by /etc/shells. The
> inconsistency lies in /etc/shells containing nologin and man 5 shells
> semantically telling the opposite. 
> 
> 
> Let's fix it.
> 
> 
> The stated reason for including nologin in shells is "so that 'chsh'
> and other tools will allow its use without manual edit
> of /etc/passwd" [1]. This is argument is inaccurate. Tests on RHEL 6.0
> and fc24 showed that the man page for chsh is correct -
> when /sbin/nologin is not in /etc/shells, root can successfully run
> chsh -s /sbin/nologin username. It prints a warning but it does change
> the default shell to /sbin/nologin. man 1 chsh:
> 
> VALID SHELLS
>chsh will accept the full pathname of any executable file on
> the  sys‐
>tem.   However,  it  will issue a warning if the shell is not
> listed in
>the /etc/shells file.  On the other hand, it  can  also  be
> configured
>such  that  it  will only accept shells listed in this file,
> unless you
>are root.
> 
> 
> 
> Removing /sbin/nologin from /etc/shells would prohibit a regular user
> to set /sbin/nologin as the default shell for themselves - an action
> that makes little sense.
> 
> 
> /sbin/nologin being in /etc/shells poses security and logical
> problems:
> 
> 
> - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as
> the default shell) succeeds with /bin/bash if auth is successful [2],
> even though man 1 su, man 8 nologin, and man 5 shells suggest that
> such a user is a restricted user and logging in with an alternate
> specified shell should be forbidden.
> 
> 
> - Red Hat Enterprise Linux 7 Security Guide advises [3]
> that /sbin/nologin should be used to prevent direct login to an
> account - the root account in this example. Presumably, this should be
> prevented in the case where the attacker has valid login credentials
> for the account. In that very case, however, the attacker can use an
> ordinary account to run su -s /bin/bash - root because the protection
> for this very attack present in su is rendered useless
> by /sbin/nologin being listed in /etc/shells. 
> 
> 
> - selinux has a workaround for /sbin/nologin -
> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00893.html
> 
> - gdm has a workaround for /sbin/nologin -
> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00894.html
> 
> 
> - Debian doesn't list nologin in /etc/shells. An opinion from a Debian
> developer [4]: "The point of having a shell that's not in /etc/shells
> isn't that you can't use it to log in, but that it's not a normal
> shell and that users with that shell set can't change it to something
> else. Adding nologin to /etc/shells would be very likely to open
> security vulnerabilities, and I will not do it."
> 
> 
> 
> 
> It seems as though /sbin/nologin is listed in /etc/shells as a
> workaround to some issues without even documenting it in the man
> pages. These issues are not important enough for those distributions
> and OSes that don't list /sbin/nologin in /etc/shells. Maybe fedora
> should be on the same boat.
> 
> 
> The rabbit hole of the past bugs and discussions about this starts
> here [5].
> 
> 
> 
> This is a bug that either lies solely in the setup package (which
> lists /sbin/nologin in the /etc/shells file) or it is an inter-package
> bug wher

Re: FAS name change

[Athos Ribeiro]

On Tue, Oct 04, 2016 at 08:21:31AM +0200, Sylvia wrote:
> 
> Hello Athos!
> 
> Did you solve your problem in Bodhi?

Not yet! I was a little busy these days (moving to a cool new
apartment). I will report the bug and ping Justing for the badges thing
later this afternoon.

Thank you guys!

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Matthew Miller]

On Tue, Oct 04, 2016 at 03:46:01PM +0200, Ondřej Vašík wrote:
> I don't think we should change this in released Fedoras ( I don't think
> this is critical security hole, when you have access to local shell, it
> is usually enough anyway ;) ), but adjustment in Rawhide seems
> reasonable.
> Any objections (other than "bug becomes expected")?

Let's make sure to get it in the F26 release notes.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Broken dependencies: vim-syntastic

[Pavel Raiskup]

On Monday, October 3, 2016 8:53:41 AM CEST Pavel Raiskup wrote:
> On Monday, October 3, 2016 8:12:50 AM CEST Pavel Raiskup wrote:
> > On Thursday, September 22, 2016 12:45:32 PM CEST Pavel Raiskup wrote:
> > > Thanks a lot for this discussion.  I'll go (probably) the hacky
> > > ExclusiveArch way, just because I want to give it a try.  Once this
> > > becomes too tiring (because the package has non-trivial amount of
> > > run-time-only dependencies), I'll talk to releng team.
> > 
> > The approach is here:
> > http://pkgs.fedoraproject.org/cgit/rpms/vim-syntastic.git/commit/?id=8f4bf0f6e30fa048bc8
> > 
> > One issue happened to me during the first build attempt -- aarch64 builder
> > was used while aarch64 was _not_ in all _sub_packages' ExclusiveArch:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=15918394
> > 
> > The second attempt on x86_64 has been successful:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=15918430
> > 
> > Is this related to?
> > https://pagure.io/koji/issue/19
> > 
> > What is the work-around?  Do I have to specify 'BuildArch: noarch' for all
> > subpackages (would that help)?  Do I have to try re-building until I get the
> > right machine?
> 
> Even more interesting, %arm is not on ExclusiveArch list for
> 'vim-syntastic-d' package, while the build on arm machine succeeded:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=15919447
> 
> What is the reason to fail on aarch64 then?

Heh, here it comes :)

  | vim-syntastic has broken dependencies in the rawhide tree:
  | On aarch64:
  | vim-syntastic-lisp-3.7.0-8.fc26.noarch requires clisp
  | On aarch64:
  | vim-syntastic-d-3.7.0-8.fc26.noarch requires ldc
  | On armhfp:
  | vim-syntastic-d-3.7.0-8.fc26.noarch requires ldc
  | On aarch64:
  | vim-syntastic-cs-3.7.0-8.fc26.noarch requires mono-core
  | Please resolve this as soon as possible.

Seems like the ExclusiveArch for subset of sub-packages did not help at all.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Chris Murphy]

On Tue, Oct 4, 2016 at 1:46 AM, Kamil Paral  wrote:
>> > If we do not 'support' livecd-iso-to-disk any more, we no longer
>> > support:
>> >
>> > 1) persistent storage (via overlays)
>> > 2) non-destructive write
>>
>> Does anyone know why we can't have Fedora Media Writer support these
>> functions as well?
>
> I hope it won't. Or if it will, I hope it won't be the default, it will be 
> well hidden, and we won't block on it. Because especially the non-destructive 
> write is a can of worms. It almost never works for standard users, unless you 
> have a very good understanding what a bootloader is and whether you should 
> replace it or not. Most people don't need it (everyone has a small flash 
> drive to be completely overwritten these days), and those who do, they can 
> easily use livecd-iso-to-disk with its heap of magical cmdline switches.
>
> So no, I don't see why our default tool which is intended to be simple and 
> user friendly should support alternative modes of operations for <1% of our 
> user base. Do one thing and do it well.

Over on Windows and macOS, there is no such thing as a non-destructive
install media creation. It warns but obliterates the entire stick.
They also don't have persistence. So I think you're on very solid
ground calling both features edge cases, and as such probably not
reasonable to block a release on if it weren't to work.

I think both features are better applied to the installer. Any
installer deficiencies installing to removable media should be
addressed. This would provide both of the listed functions. In theory
it should just work anyway.

The one concern I have is with Sugar on a Stick spin. Their
installation instructions require livecd-iso-to-disk, because their
media boots straight into SoaS, not Anaconda. But I have some ideas
about how to deal with that going forward to, rather than depend
indefinitely on livecd-iso-to-disk.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: A tale of systemd and MaxProcs

[Denys Vlasenko]

On 09/24/2016 08:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Sep 22, 2016 at 12:18:53PM -0400, Matthew Miller wrote:

On Wed, Sep 21, 2016 at 12:32:40PM -0600, Kevin Fenzi wrote:

* IMHO the initial upstream default didn't make sense for Fedora


On this specific change, I'm not sure the *updated* default makes sense
either. It still is quite constrained.


* Perhaps after beta but before final we ping maintainers of
  "important" packages asking what big changes have happened? Or
  someone just goes thru the release notes for them all and proposes a
  list of them?


I think this is good, but probably too late for some kinds of
decisions.


This would help by highlighting things that should be testing… I don't
know though if pinging maintainers is the best way to do this, since
this would require quite a bit of time from some volunteer.


* Your brilliant idea here.


I think that we should have a general policy for packagers of
far-reaching infrastructure packages (systemd, glibc, kernel, whatever)
that any new restrictions or constraints should be disabled by default
in Fedora, regardless of upstream defaults, until we're able to have a
conversation — here, in the edition WGs, and/or in FESCo, as
appropriate for the particular change.


Every change of this type is a judgement call. Most of such changes
don't cause any issues and if FESCo wanted to review every one it
would be swamped with useless work (apart from systemd, at least
selinux introduce new restrictions every once in a while).

I'm sorry about TasksMax causing issues. We should have been more
careful in introducing it and phased it in by first introducing it for
internal systemd units, and only later turn on the global setting.
We'll try to do better in the future :)


How did you arrive at the idea that users are in need of no longer
being able to run as many processes as before?

Was there a user report asking for such change?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161004.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386

Failed openQA tests: 5/102 (x86_64), 1/17 (i386), 1/2 (arm)

New failures (same test did not fail in 25-20161003.n.0):

ID: 38574   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/38574
ID: 38590   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/38590

Old failures (same test failed in 25-20161003.n.0):

ID: 38571   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/38571
ID: 38572   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/38572
ID: 38577   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38577
ID: 38678   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/38678
ID: 38682   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/38682

Passed openQA tests: 97/102 (x86_64), 16/17 (i386)

New passes (same test did not pass in 25-20161003.n.0):

ID: 38639   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/38639

Skipped openQA tests: 1 of 121
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.

I'm working with the reporter right now to investigate and hopefully
get this fixed, but in the meantime - and this is in fact our standard
advice anyway, but it bears repeating - DON'T RUN 'dnf update' INSIDE A
DESKTOP.

Running the update process inside a desktop just gives it all the more
opportunity to crash somehow. If the terminal app crashes, the update
crashes. If the desktop crashes, the update crashes.

I don't want to get in the KDE folks' bad graces, but this likely could
also affect KDE's graphical update system, so I'd advise against using
that for the present too.

If you're using Workstation, the offline update system is expressly
designed to minimize the likelihood of this kind of problem, so please
do consider using it. Otherwise, at least run 'dnf update' in a VT -
hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
there. Don't do it inside your desktop.

Thanks folks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 16:56 +0100, Patrick O'Callaghan wrote:
> On 4 October 2016 at 16:51, Adam Williamson 
> wrote:
> 
> > Running the update process inside a desktop just gives it all the more
> > opportunity to crash somehow. If the terminal app crashes, the update
> > crashes. If the desktop crashes, the update crashes.
> > 
> > I don't want to get in the KDE folks' bad graces, but this likely could
> > also affect KDE's graphical update system, so I'd advise against using
> > that for the present too.
> > 
> 
> 
> Maybe I've just been lucky but I run dnf on a daily basis in a Konsole
> terminal window (under KDE) and have never seen this kind of problem. I
> don't use the graphical updater(s).

Well, as I said it may be package set or hardware dependent, or just a
case of luck. There've been I think at least five or six reports so far
that I've heard of one way or another, which seemed like enough to send
out a mail shot.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Oct 4, 2016 8:52 AM, "Adam Williamson" 
wrote:
>
> Recently several reports of people getting 'duplicated packages' and
> 'kernel updates not working' have come through to us in QA from Fedora
> 24 users. I managed to get one reporter to explain more specifically
> what happened, and it sounds a lot like what's happening is that
> something in the 'dnf update' process can cause a GNOME or X crash,
> possibly depending on hardware or package set installed. When that
> happens, the update process is killed and does not complete cleanly,
> which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)?  This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

I once hosed a RHEL5 system when an ssh terminal running yum died.  Sigh.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Neal Gompa]

On Tue, Oct 4, 2016 at 12:06 PM, Andrew Lutomirski  wrote:
>
> On Oct 4, 2016 8:52 AM, "Adam Williamson" 
> wrote:
>>
>> Recently several reports of people getting 'duplicated packages' and
>> 'kernel updates not working' have come through to us in QA from Fedora
>> 24 users. I managed to get one reporter to explain more specifically
>> what happened, and it sounds a lot like what's happening is that
>> something in the 'dnf update' process can cause a GNOME or X crash,
>> possibly depending on hardware or package set installed. When that
>> happens, the update process is killed and does not complete cleanly,
>> which is why you get 'duplicated packages' and other odd results.
>
> How hard would it be to make dnf do the rpm transaction inside a proper
> system-level service (transient or otherwise)?  This would greatly increase
> robustness against desktop crashes, ssh connection loss, KillUserProcs, and
> other damaging goofs.
>
> I once hosed a RHEL5 system when an ssh terminal running yum died.  Sigh.
>

This is pretty much what dnfdaemon does. However, dnfdaemon is only
used by yumex-dnf[1] and dnfdragora[2].

To the best of my knowledge, there are no CLI clients for it.

[1]: https://github.com/timlau/yumex-dnf
[2]: https://github.com/anaselli/dnfdragora


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Stephen Gallagher]

On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:
> 
> On Oct 4, 2016 8:52 AM, "Adam Williamson"  > wrote:
>>
>> Recently several reports of people getting 'duplicated packages' and
>> 'kernel updates not working' have come through to us in QA from Fedora
>> 24 users. I managed to get one reporter to explain more specifically
>> what happened, and it sounds a lot like what's happening is that
>> something in the 'dnf update' process can cause a GNOME or X crash,
>> possibly depending on hardware or package set installed. When that
>> happens, the update process is killed and does not complete cleanly,
>> which is why you get 'duplicated packages' and other odd results.
> 
> How hard would it be to make dnf do the rpm transaction inside a proper
> system-level service (transient or otherwise)?  This would greatly increase
> robustness against desktop crashes, ssh connection loss, KillUserProcs, and
> other damaging goofs.

That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Japheth Cleaver]

On 10/3/2016 3:02 PM, Stephen John Smoogen wrote:

On 3 October 2016 at 16:53, Toby Goodwin  wrote:

I was just reviewing this thread to date, and came across somebody asking:


How is this a "critical...security hole"?

I'm wondering if perhaps some of the staunch defenders of the status quo
have missed the security hole?


Why do people have to think that people are being 'stauch defenders'
when they might just needed a clearer explanation? I know you
mentioned chsh in your original email but even after rereading it, I
am not able to make the leap from it to what you show below. What you
show below is clearly a security problem for multi-user systems
(though I expect that there would be arguments that you are not
supposed to use chsh /sbin/nologin to lock someone out but usermod
-L).

The owner of the setup package is Ondrej Vasik, email:
ova...@redhat.com. They seem fairly active and would probably be
receptive to fixing the problem with the explanation included.

My objection here is roughly the same. /sbin/nologin does not mean 
"locked out", it's a non-shell that can serve as a shell. While there 
may be some value in chsh disallowing a change *from* /sbin/nologin to 
something else by the own user, it's not intended to block any access at 
all by a user -- it's canonical purpose allowed FTP logins successfully, 
for example.


To prevent an 'su' specification of shell and to prevent any login, one 
can use /bin/false easily enough (which, again, was historical practice 
AFAIK). To prevent login via password (or an 'su' from one local user to 
another), usermod -L would seem to be more correct.


My concern here is that we're losing a useful tool: a built-in 
"non-shell" shell, functioning as a middle-ground between an invalid 
shell and an account lockout.



Regards,

-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ... and Fedora 25! - Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 18:28 +0200, Karel Volný wrote:
> > Recently several reports of people getting 'duplicated packages' and
> > 'kernel updates not working' have come through to us in QA from Fedora
> > 24 users. I managed to get one reporter to explain more specifically
> > what happened, and it sounds a lot like what's happening is that
> > something in the 'dnf update' process can cause a GNOME or X crash,
> 
> 
> LXQT in my case, so more X than GNOME crash
> 
> is there a bug I can subscribe to?

Not yet (AFAIK), I'm trying to walk the reporter who's currently in
#fedora-qa through filing one. abrt is showing an X crash for him,
indeed. If you have hit this and you still have the system live, you
should be able to find the X crash in abrt and report it.

> > Otherwise, at least run 'dnf update' in a VT -
> > hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
> > there. Don't do it inside your desktop.
> 
> 
> or better (IMHO) - run it using `screen` ;-)

I think whether that's better or not depends on exactly how the
screen/tmux server process was run...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 9:56 AM, Patrick O'Callaghan
 wrote:
>
> On 4 October 2016 at 16:51, Adam Williamson 
> wrote:
>>
>> Running the update process inside a desktop just gives it all the more
>> opportunity to crash somehow. If the terminal app crashes, the update
>> crashes. If the desktop crashes, the update crashes.
>>
>> I don't want to get in the KDE folks' bad graces, but this likely could
>> also affect KDE's graphical update system, so I'd advise against using
>> that for the present too.
>
>
> Maybe I've just been lucky but I run dnf on a daily basis in a Konsole
> terminal window (under KDE) and have never seen this kind of problem. I
> don't use the graphical updater(s).

I do it also but I also take a snapshot of root first, and then I
expect without warning that the GUI could just vanish and munge a
bunch of things. It's a use case I expect to not work, even though it
Works For Me™.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ... and Fedora 25! - Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 18:28 +0200, Karel Volný wrote:
> > Recently several reports of people getting 'duplicated packages' and
> > 'kernel updates not working' have come through to us in QA from Fedora
> > 24 users. I managed to get one reporter to explain more specifically
> > what happened, and it sounds a lot like what's happening is that
> > something in the 'dnf update' process can cause a GNOME or X crash,
> 
> 
> LXQT in my case, so more X than GNOME crash
> 
> is there a bug I can subscribe to?

Seems the bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1341327
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Tue, Oct 4, 2016 at 9:09 AM, Stephen Gallagher  wrote:
>
> On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:
> >
> > On Oct 4, 2016 8:52 AM, "Adam Williamson"  > > wrote:
> >>
> >> Recently several reports of people getting 'duplicated packages' and
> >> 'kernel updates not working' have come through to us in QA from Fedora
> >> 24 users. I managed to get one reporter to explain more specifically
> >> what happened, and it sounds a lot like what's happening is that
> >> something in the 'dnf update' process can cause a GNOME or X crash,
> >> possibly depending on hardware or package set installed. When that
> >> happens, the update process is killed and does not complete cleanly,
> >> which is why you get 'duplicated packages' and other odd results.
> >
> > How hard would it be to make dnf do the rpm transaction inside a proper
> > system-level service (transient or otherwise)?  This would greatly increase
> > robustness against desktop crashes, ssh connection loss, KillUserProcs, and
> > other damaging goofs.
>
> That seems like a waste of effort, considering we have the offline updates
> process which just boots into a special, minimalist environment with almost
> nothing but the updater running.
>
>

By that standard, why do we support dnf at all?

$ sudo dnf upgrade
Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot when asked.

I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks.  As far as I know, Fedora
considers plain ol' dnf to be supported.

For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 10:09 AM, Stephen Gallagher  wrote:
> On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:
>>
>> On Oct 4, 2016 8:52 AM, "Adam Williamson" > > wrote:
>>>
>>> Recently several reports of people getting 'duplicated packages' and
>>> 'kernel updates not working' have come through to us in QA from Fedora
>>> 24 users. I managed to get one reporter to explain more specifically
>>> what happened, and it sounds a lot like what's happening is that
>>> something in the 'dnf update' process can cause a GNOME or X crash,
>>> possibly depending on hardware or package set installed. When that
>>> happens, the update process is killed and does not complete cleanly,
>>> which is why you get 'duplicated packages' and other odd results.
>>
>> How hard would it be to make dnf do the rpm transaction inside a proper
>> system-level service (transient or otherwise)?  This would greatly increase
>> robustness against desktop crashes, ssh connection loss, KillUserProcs, and
>> other damaging goofs.
>
> That seems like a waste of effort, considering we have the offline updates
> process which just boots into a special, minimalist environment with almost
> nothing but the updater running.

It's not really workable without an atomic and out of tree update
method, otherwise libraries are still yanked out from under running
processes at some point. I've done this with nspawn (and chroot),
taking snapshots of root, then applying the update to the snapshot,
changing the bootloader to boot the updated snapshot. This is tedious
but it's reliable in that pretty much anything bad can happen and it's
only the fs tree being updated that can be broken. And only one reboot
is needed.

The long term solution is rpm-ostree based Workstation where the
currently running fs tree isn't touched either.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Kevin Fenzi]

On Tue, 4 Oct 2016 09:51:16 -0700
Andrew Lutomirski  wrote:

> By that standard, why do we support dnf at all?
> 
> $ sudo dnf upgrade
> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
> when asked.
> 
> I, for one, *like* not rebooting, and I'm perfectly capable of
> rebooting manually if stuff breaks.  As far as I know, Fedora
> considers plain ol' dnf to be supported.

Well, the problem there, what do you mean by 'support'? 

In this case lots of people use dnf for updates, so IMHO it would be
"we will try and keep this working, and fix anything we can, but do
understand that there's a low level problem here that something could
mess up updates in progress, if you want to be more sure of not hitting
problems, use the offline updates in your graphical desktop"
> 
> For server use, I'm not convinced that the offline update mechanism is
> supported (at the very least, I have no idea how to trigger it), and
> servers have the same issue.

Much less so. In the server case you have usually ssh, bash and dnf, in
the desktop case you have X, possibly wayland, tons of graphics
libraries, the terminal application you are using and all it's
libraries, and a shell and dnf. There's just a lot more there to
possibly crash. 

kevin


pgpnB6BUUYG_A.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20161004.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Kde live i386
Workstation live i386
Kde live x86_64
Cloud_base raw-xz i386
Workstation live x86_64

Failed openQA tests: 57/80 (x86_64), 14/15 (i386)

New failures (same test did not fail in Rawhide-20161003.n.1):

ID: 38504   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/38504
ID: 38518   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/38518

Old failures (same test failed in Rawhide-20161003.n.1):

ID: 38462   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38462
ID: 38463   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/38463
ID: 38464   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38464
ID: 38465   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38465
ID: 38466   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/38466
ID: 38467   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38467
ID: 38468   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38468
ID: 38471   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38471
ID: 38472   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/38472
ID: 38473   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/38473
ID: 38474   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/38474
ID: 38481   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/38481
ID: 38482   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/38482
ID: 38491   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/38491
ID: 38492   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/38492
ID: 38493   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/38493
ID: 38494   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/38494
ID: 38495   Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/38495
ID: 38496   Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/38496
ID: 38497   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/38497
ID: 38498   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/38498
ID: 38499   Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/38499
ID: 38503   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/38503
ID: 38508   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/38508
ID: 38510   Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/38510
ID: 38511   Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/38511
ID: 38512   Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/38512
ID: 38513   Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/38513
ID: 38514   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/38514
ID: 38515   Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/38515
ID: 38516   Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/38516
ID: 38517   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/38517
ID: 38520   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/38520
ID: 38521   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/38521
ID: 38522   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/38522
ID: 38523   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/38523
ID: 38524   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/38524
ID: 38525   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/38525
ID: 38526   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tes

Re: RFC: Storing Automated Tasks/Tests In Dist-Git

[Kevin Fenzi]

On Mon, 3 Oct 2016 15:57:14 -0600
Tim Flink  wrote:

> Thanks for the clarification - the emphasis was on coming support for
> PRs. I've reworded that part of the proposal to make it more clear
> that dist-git isn't "moving to pagure".

Thanks. 
> 
> > Another alternate here is that we could make taskotron a 'namespace'
> > like currently rpms/ and docker/ are. Then we would have
> > perhaps: /taskotron/rpms/foobar/ as the top level and all the rest
> > is the same. This would get us a seperate pkgdb entry for the
> > taskotron part of things (ie, it could have different maintainers,
> > people allowed to commit, etc). That would add to complexity
> > however.   
> 
> That is an alternative that we had been looking at before we learned
> that dist-git would be getting pull requests. The namespace we were
> talking about was 'checks/rpms/foobar' which would also open the door
> for things like 'checks/docker/foobar' or any other type of
> deliverable which uses dist-git.
> 
> Our thought is that keeping all the checks in the same repo that spec
> files live in is going to be easier to use than having to worry about
> keeping 2 repos in sync with eachother.

Fair enough. I just thought it would be worth mentioning. 

> That being said, we're fine with either storage paradigm and it
> doesn't matter much if we look for tasks in a directory inside
> dist-git branches or a separate repo which only holds tasks as long
> as there is a single convention that is easy for most contributors
> and doesn't involve something that's unmanageable for the Taskotron
> devs/admins.

Yeah, I don't have much of a horse in this race either. 
I guess it depends on how much maintainers will find tests being
added/edited/etc as noise or not. 
 
> > Is there any provision for tests that should be run on _all_
> > packages? or we would need to link the test into all repos, etc?
> > I have in mind a test that would get the checksum from the sources
> > file and see if it could compare it to upstream.   
> 
> At this point, that's pretty much "come talk to us and we'll get
> something figured out". I suspect that things which run on all
> builds/uploads are going to be the minority of tasks that people want
> to run and for now, it's treated as a special case.

ok. Thats fair.

> So, if you have ideas for checks that would run on all packages or on
> groups of packages, please come find us. If I'm wrong and there are a
> lot of more general checks that people want to run, we can speed up
> plans to make them less of a special case.
> 
> > Finally, are the lifecycle points triggered via fedmsg? If so, it
> > would be nice to have a UPLOAD lifecycle where someone has uploaded
> > a source to lookaside cache. (The above test would probibly be
> > better at upload time than sources git commit time, but either
> > could work).   
> 
> Everything that runs in Taskotron is triggered via fedmsg so we can
> add pretty much anything which emits a fedmsg.

Excellent. 

...snip...

kevin




pgpzrt99FV3Eg.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 10:51 AM, Andrew Lutomirski  wrote:

> By that standard, why do we support dnf at all?
>
> $ sudo dnf upgrade
> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot when 
> asked.

Well it's not always risky, it depends on what's being updated. If
it's applications, it's pretty safe unless they're running. There is a
qualitative difference between server and workstation, so the warning
may be misleading if it exists on server also.


> I, for one, *like* not rebooting, and I'm perfectly capable of
> rebooting manually if stuff breaks.  As far as I know, Fedora
> considers plain ol' dnf to be supported.

Yeah this is really debatable for best practices to expect users to
know these things. You can argue if they're using dnf they should know
better, and just accept that things can blow up, or help track them
down so if possible this stuff can get fixed.


> For server use, I'm not convinced that the offline update mechanism is
> supported (at the very least, I have no idea how to trigger it), and
> servers have the same issue.

PackageKit is installed on server, so while I haven't tested it, it
seems plausible it could be used for system updates. But I think the
risk here is much less because dnf is a bit more isolated by not
running in a GUI Terminal in a user session. But even here, a reboot
is expected for many things, there's just no guarantee of state
otherwise.

I think the thing that's unique with current offline updates compared
to other platforms I use is the double reboot. The reboot to get to
offline updates target where the update happens, and then a reboot to
get back to graphical target. That does seem suboptimal to me, where
other platforms just log out the user session, and drop to their
reduced function "updates" state to do the update, and then there's
one reboot.

Anyway, my opinion is that Workstation folks should use Gnome Software
to do their updates, and if there's something wonky there, we need to
get it fixed. That's the default and primary update method. Within
something like 5 minutes of first boot after an installation,
PackageKit is already downloading updated packages. Unless that's
disabled, a 'dnf update' is going to unnecessarily download those
packages in duplicate.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Stephen John Smoogen]

On 4 October 2016 at 13:05, Kevin Fenzi  wrote:
> On Tue, 4 Oct 2016 09:51:16 -0700
> Andrew Lutomirski  wrote:
>
>> By that standard, why do we support dnf at all?
>>
>> $ sudo dnf upgrade
>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
>> when asked.
>>
>> I, for one, *like* not rebooting, and I'm perfectly capable of
>> rebooting manually if stuff breaks.  As far as I know, Fedora
>> considers plain ol' dnf to be supported.
>
> Well, the problem there, what do you mean by 'support'?
>
> In this case lots of people use dnf for updates, so IMHO it would be
> "we will try and keep this working, and fix anything we can, but do
> understand that there's a low level problem here that something could
> mess up updates in progress, if you want to be more sure of not hitting
> problems, use the offline updates in your graphical desktop"
>>
>> For server use, I'm not convinced that the offline update mechanism is
>> supported (at the very least, I have no idea how to trigger it), and
>> servers have the same issue.
>
> Much less so. In the server case you have usually ssh, bash and dnf, in
> the desktop case you have X, possibly wayland, tons of graphics
> libraries, the terminal application you are using and all it's
> libraries, and a shell and dnf. There's just a lot more there to
> possibly crash.
>

As a systems administrator, I am left with at least 2 different fail states:

1) I reboot the box and have no idea what is going on because it never
came back.
2) I run dnf update and I know it got to sshd or glibc when my
connection to the server went away.

In either case I am hosed and if I am running a cloud of servers..
hosed in scale (or hosed as a service?). The part we really want to do
is try and make it so if we are hosed.. how do we get it to be less
hosed? Because this is going to happen in any case in some form no
matter what.. when it does how do we recover in scale?


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Stephen Gallagher]

On 10/04/2016 12:51 PM, Andrew Lutomirski wrote:
> On Tue, Oct 4, 2016 at 9:09 AM, Stephen Gallagher  wrote:
>>
>> On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:
>>>
>>> On Oct 4, 2016 8:52 AM, "Adam Williamson" >> > wrote:

 Recently several reports of people getting 'duplicated packages' and
 'kernel updates not working' have come through to us in QA from Fedora
 24 users. I managed to get one reporter to explain more specifically
 what happened, and it sounds a lot like what's happening is that
 something in the 'dnf update' process can cause a GNOME or X crash,
 possibly depending on hardware or package set installed. When that
 happens, the update process is killed and does not complete cleanly,
 which is why you get 'duplicated packages' and other odd results.
>>>
>>> How hard would it be to make dnf do the rpm transaction inside a proper
>>> system-level service (transient or otherwise)?  This would greatly increase
>>> robustness against desktop crashes, ssh connection loss, KillUserProcs, and
>>> other damaging goofs.
>>
>> That seems like a waste of effort, considering we have the offline updates
>> process which just boots into a special, minimalist environment with almost
>> nothing but the updater running.
>>
>>
> 
> By that standard, why do we support dnf at all?
> 
> $ sudo dnf upgrade
> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot when 
> asked.
> 
> I, for one, *like* not rebooting, and I'm perfectly capable of
> rebooting manually if stuff breaks.  As far as I know, Fedora
> considers plain ol' dnf to be supported.
> 
> For server use, I'm not convinced that the offline update mechanism is
> supported (at the very least, I have no idea how to trigger it), and
> servers have the same issue.

```
sudo pkcon refresh force && \
sudo pkcon update --only-download && \
sudo pkcon offline-trigger **
sudo systemctl reboot
```





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Stephen Gallagher]

On 10/04/2016 01:20 PM, Stephen Gallagher wrote:
> On 10/04/2016 12:51 PM, Andrew Lutomirski wrote:
>> On Tue, Oct 4, 2016 at 9:09 AM, Stephen Gallagher  
>> wrote:
>>>
>>> On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:

 On Oct 4, 2016 8:52 AM, "Adam Williamson" >>> > wrote:
>
> Recently several reports of people getting 'duplicated packages' and
> 'kernel updates not working' have come through to us in QA from Fedora
> 24 users. I managed to get one reporter to explain more specifically
> what happened, and it sounds a lot like what's happening is that
> something in the 'dnf update' process can cause a GNOME or X crash,
> possibly depending on hardware or package set installed. When that
> happens, the update process is killed and does not complete cleanly,
> which is why you get 'duplicated packages' and other odd results.

 How hard would it be to make dnf do the rpm transaction inside a proper
 system-level service (transient or otherwise)?  This would greatly increase
 robustness against desktop crashes, ssh connection loss, KillUserProcs, and
 other damaging goofs.
>>>
>>> That seems like a waste of effort, considering we have the offline updates
>>> process which just boots into a special, minimalist environment with almost
>>> nothing but the updater running.
>>>
>>>
>>
>> By that standard, why do we support dnf at all?
>>
>> $ sudo dnf upgrade
>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot when 
>> asked.
>>
>> I, for one, *like* not rebooting, and I'm perfectly capable of
>> rebooting manually if stuff breaks.  As far as I know, Fedora
>> considers plain ol' dnf to be supported.
>>
>> For server use, I'm not convinced that the offline update mechanism is
>> supported (at the very least, I have no idea how to trigger it), and
>> servers have the same issue.
> 
> ```
> sudo pkcon refresh force && \
> sudo pkcon update --only-download && \
> sudo pkcon offline-trigger **
> sudo systemctl reboot
> ```

That "**" should have been "&& \"



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi  wrote:
> On Tue, 4 Oct 2016 09:51:16 -0700
> Andrew Lutomirski  wrote:
>
>> By that standard, why do we support dnf at all?
>>
>> $ sudo dnf upgrade
>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
>> when asked.
>>
>> I, for one, *like* not rebooting, and I'm perfectly capable of
>> rebooting manually if stuff breaks.  As far as I know, Fedora
>> considers plain ol' dnf to be supported.
>
> Well, the problem there, what do you mean by 'support'?
>
> In this case lots of people use dnf for updates, so IMHO it would be
> "we will try and keep this working, and fix anything we can, but do
> understand that there's a low level problem here that something could
> mess up updates in progress, if you want to be more sure of not hitting
> problems, use the offline updates in your graphical desktop"
>>
>> For server use, I'm not convinced that the offline update mechanism is
>> supported (at the very least, I have no idea how to trigger it), and
>> servers have the same issue.
>
> Much less so. In the server case you have usually ssh, bash and dnf, in
> the desktop case you have X, possibly wayland, tons of graphics
> libraries, the terminal application you are using and all it's
> libraries, and a shell and dnf. There's just a lot more there to
> possibly crash.

My point is that a lot of this exposure could be avoided.  Sure,
there's a decent chance that updating packages will crash running
programs.  But, unless one of those programs is dnf, rpm, or systemd,
that shouldn't be an excuse to blow up the whole upgrade.  I've had
Firefox blow up many times due to concurrent dnf, but this doesn't
hose my system.  Having gnome-terminal or X or Wayland die shouldn't
be any more dangerous.

>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>


So, yes, offline updates or ostree-style updates are better in many
respects, but as long as we provide plain dnf, I think it would be
worth the small amount of effort to make dnf robust against the
terminal dying.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ... and Fedora 25! - Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Ian Pilcher]

On 10/04/2016 11:41 AM, Adam Williamson wrote:

On Tue, 2016-10-04 at 18:28 +0200, Karel Volný wrote:

or better (IMHO) - run it using `screen` ;-)


I think whether that's better or not depends on exactly how the
screen/tmux server process was run...


Can you clarify?  In what circumstances would the dnf command running
within a screen session not survive an X/desktop crash?

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 11:26 AM, Andrew Lutomirski  wrote:
> On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi  wrote:
>> On Tue, 4 Oct 2016 09:51:16 -0700
>> Andrew Lutomirski  wrote:
>>
>>> By that standard, why do we support dnf at all?
>>>
>>> $ sudo dnf upgrade
>>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
>>> when asked.
>>>
>>> I, for one, *like* not rebooting, and I'm perfectly capable of
>>> rebooting manually if stuff breaks.  As far as I know, Fedora
>>> considers plain ol' dnf to be supported.
>>
>> Well, the problem there, what do you mean by 'support'?
>>
>> In this case lots of people use dnf for updates, so IMHO it would be
>> "we will try and keep this working, and fix anything we can, but do
>> understand that there's a low level problem here that something could
>> mess up updates in progress, if you want to be more sure of not hitting
>> problems, use the offline updates in your graphical desktop"
>>>
>>> For server use, I'm not convinced that the offline update mechanism is
>>> supported (at the very least, I have no idea how to trigger it), and
>>> servers have the same issue.
>>
>> Much less so. In the server case you have usually ssh, bash and dnf, in
>> the desktop case you have X, possibly wayland, tons of graphics
>> libraries, the terminal application you are using and all it's
>> libraries, and a shell and dnf. There's just a lot more there to
>> possibly crash.
>
> My point is that a lot of this exposure could be avoided.  Sure,
> there's a decent chance that updating packages will crash running
> programs.  But, unless one of those programs is dnf, rpm, or systemd,
> that shouldn't be an excuse to blow up the whole upgrade.


I think it's avoided by propagating the point adamw started the thread for.

User: Doctor, it hurts when I do this!
DocAdamW: So then don't do that!

Do users need an INFO message when running 'dnf update' to kill off
the myth that without a warning it's expected to be reliable? Maybe.


> I've had
> Firefox blow up many times due to concurrent dnf, but this doesn't
> hose my system.  Having gnome-terminal or X or Wayland die shouldn't
> be any more dangerous.

I don't understand how you arrive at this conclusion. dnf is sitting
on the top of a house of cards when it's running in Terminal. If
anything below it dies, dnf dies and by extension so is rpm. Could dnf
be put into it's own session or scope (whatever it's called), and
would that prevent it from dying if the whole GUI died? Even if true,
how does the user know to wait XX minutes before hitting the reset
button? I think it's a rabbit hole, just stop touching the owie.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi  wrote:

>
> Well, the problem there, what do you mean by 'support'?
>
> In this case lots of people use dnf for updates, so IMHO it would be
> "we will try and keep this working, and fix anything we can, but do
> understand that there's a low level problem here that something could
> mess up updates in progress, if you want to be more sure of not hitting
> problems, use the offline updates in your graphical desktop"
> >


OK, I'm completely confused.
First of all, I've never seen a message such as:

> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
> when asked.

and I have NEVER used the graphical update since the first release of
Fedora.  I've always used yum or dnf.  As I mentioned earlier in the past
I've found the graphical tools to be quirky at best - perhaps that has
changed, but since the command line has always worked for me, I've stuck
with it.  Apparently I've missed something along the way because now people
are implying that using the command line tools from within GNOME or KDE are
dangerous.  What exactly is going on?

As far as rebooting after every update?  Huh?  Who does that?  Are we
Windows?  We're suppose to be moving toward the time when you won't need to
reboot for kernel updates.  Perhaps this is only a GNOME problem... but
when I used GNOME years ago, I never experienced it.  I also have never
seen it with KDE or LxQT.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 10:39 -0700, Gerald B. Cox wrote:

> and I have NEVER used the graphical update since the first release of
> Fedora.  I've always used yum or dnf.  As I mentioned earlier in the past
> I've found the graphical tools to be quirky at best - perhaps that has
> changed, but since the command line has always worked for me, I've stuck
> with it.  Apparently I've missed something along the way because now people
> are implying that using the command line tools from within GNOME or KDE are
> dangerous.  What exactly is going on?

It's always been dangerous. It works fine all the time until it
doesn't, and then you're left with a pile of broken bits that you get
to spend all afternoon fixing.

It's pretty simple, really: a process running in a terminal inside a
graphical desktop will crash if the terminal app crashes, or if the
desktop crashes, or if X crashes. If any of those things happens, your
update process just dies instantly, leaving whatever bits it hadn't
done yet...undone. This is a situation it's technically more or less
impossible to *fully* recover from (it's more or less impossible to
figure out and execute precisely whatever scriptlet actions should have
happened but did not), and is a pain to more-or-less-practically
recover from (you get to hack up some crappy script to detect duplicate
packages, run rpm -e --justdb --noscripts on the old NEVR and run dnf
reinstall on the new NEVR...)

I'm not entirely sure if the KDE graphical updater is safer or not, but
I don't think it is, because I think it again effectively just runs the
update transaction inside the KDE session, where it will die partway
through if KDE or X crashes.

The current GNOME update workflow, however, is the most reliable we
have, because it downloads the updates then boots to a minimal systemd
target with as few things running as possible to install the updates,
then boots back to the normal system. This is far, far safer than
running the update inside a desktop.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Neal Gompa]

On Tue, Oct 4, 2016 at 1:53 PM, Adam Williamson
 wrote:
> On Tue, 2016-10-04 at 10:39 -0700, Gerald B. Cox wrote:
>
>> and I have NEVER used the graphical update since the first release of
>> Fedora.  I've always used yum or dnf.  As I mentioned earlier in the past
>> I've found the graphical tools to be quirky at best - perhaps that has
>> changed, but since the command line has always worked for me, I've stuck
>> with it.  Apparently I've missed something along the way because now people
>> are implying that using the command line tools from within GNOME or KDE are
>> dangerous.  What exactly is going on?
>
> It's always been dangerous. It works fine all the time until it
> doesn't, and then you're left with a pile of broken bits that you get
> to spend all afternoon fixing.
>
> It's pretty simple, really: a process running in a terminal inside a
> graphical desktop will crash if the terminal app crashes, or if the
> desktop crashes, or if X crashes. If any of those things happens, your
> update process just dies instantly, leaving whatever bits it hadn't
> done yet...undone. This is a situation it's technically more or less
> impossible to *fully* recover from (it's more or less impossible to
> figure out and execute precisely whatever scriptlet actions should have
> happened but did not), and is a pain to more-or-less-practically
> recover from (you get to hack up some crappy script to detect duplicate
> packages, run rpm -e --justdb --noscripts on the old NEVR and run dnf
> reinstall on the new NEVR...)
>
> I'm not entirely sure if the KDE graphical updater is safer or not, but
> I don't think it is, because I think it again effectively just runs the
> update transaction inside the KDE session, where it will die partway
> through if KDE or X crashes.
>
> The current GNOME update workflow, however, is the most reliable we
> have, because it downloads the updates then boots to a minimal systemd
> target with as few things running as possible to install the updates,
> then boots back to the normal system. This is far, far safer than
> running the update inside a desktop.

I have never heard of anyone reaching out to the KDE PK frontend
developers for supporting this mechanism. As I recall, it required
special development to get working in GNOME Software. Heck, even the
system upgrade stuff required custom development and special plugins
for GNOME Software. If you're going to suggest that people do it this
way, then perhaps you should be reaching out to the Plasma Discover
and Apper developers to ensure that it works from there too...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ... and Fedora 25! - Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Tomasz Torcz]

On Tue, Oct 04, 2016 at 12:31:43PM -0500, Ian Pilcher wrote:
> On 10/04/2016 11:41 AM, Adam Williamson wrote:
> > On Tue, 2016-10-04 at 18:28 +0200, Karel Volný wrote:
> > > or better (IMHO) - run it using `screen` ;-)
> > 
> > I think whether that's better or not depends on exactly how the
> > screen/tmux server process was run...
> 
> Can you clarify?  In what circumstances would the dnf command running
> within a screen session not survive an X/desktop crash?


   KillUserProcesses=yes

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Stephen Gallagher]

On 10/04/2016 02:01 PM, Neal Gompa wrote:
> On Tue, Oct 4, 2016 at 1:53 PM, Adam Williamson
>  wrote:
>> On Tue, 2016-10-04 at 10:39 -0700, Gerald B. Cox wrote:
>>
>>> and I have NEVER used the graphical update since the first release of
>>> Fedora.  I've always used yum or dnf.  As I mentioned earlier in the past
>>> I've found the graphical tools to be quirky at best - perhaps that has
>>> changed, but since the command line has always worked for me, I've stuck
>>> with it.  Apparently I've missed something along the way because now people
>>> are implying that using the command line tools from within GNOME or KDE are
>>> dangerous.  What exactly is going on?
>>
>> It's always been dangerous. It works fine all the time until it
>> doesn't, and then you're left with a pile of broken bits that you get
>> to spend all afternoon fixing.
>>
>> It's pretty simple, really: a process running in a terminal inside a
>> graphical desktop will crash if the terminal app crashes, or if the
>> desktop crashes, or if X crashes. If any of those things happens, your
>> update process just dies instantly, leaving whatever bits it hadn't
>> done yet...undone. This is a situation it's technically more or less
>> impossible to *fully* recover from (it's more or less impossible to
>> figure out and execute precisely whatever scriptlet actions should have
>> happened but did not), and is a pain to more-or-less-practically
>> recover from (you get to hack up some crappy script to detect duplicate
>> packages, run rpm -e --justdb --noscripts on the old NEVR and run dnf
>> reinstall on the new NEVR...)
>>
>> I'm not entirely sure if the KDE graphical updater is safer or not, but
>> I don't think it is, because I think it again effectively just runs the
>> update transaction inside the KDE session, where it will die partway
>> through if KDE or X crashes.
>>
>> The current GNOME update workflow, however, is the most reliable we
>> have, because it downloads the updates then boots to a minimal systemd
>> target with as few things running as possible to install the updates,
>> then boots back to the normal system. This is far, far safer than
>> running the update inside a desktop.
> 
> I have never heard of anyone reaching out to the KDE PK frontend
> developers for supporting this mechanism. As I recall, it required
> special development to get working in GNOME Software. Heck, even the
> system upgrade stuff required custom development and special plugins
> for GNOME Software. If you're going to suggest that people do it this
> way, then perhaps you should be reaching out to the Plasma Discover
> and Apper developers to ensure that it works from there too...
> 
> 

The requisite functionality was built in PackageKit specifically to ensure that
it was available for any desktop that wanted to use it. Obviously, since GNOME
Software developers were the ones who developed it, they did the work to make
sure it functions properly there.

Nothing stops KDE or any other mechanism from using this functionality (it's
exposed in the public PackageKit API). See my other replies on this thread for
information on how you could do it from the `pkcon` CLI in a pinch...



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[stan]

On Tue, 04 Oct 2016 08:51:07 -0700
Adam Williamson  wrote:

> I'm working with the reporter right now to investigate and hopefully
> get this fixed, but in the meantime - and this is in fact our standard
> advice anyway, but it bears repeating - DON'T RUN 'dnf update' INSIDE
> A DESKTOP.

I think I can confirm this advice.  I always run dnf manually from the
command line, in a VT logged in as root.  And I can run X while doing
this and I've never had a dnf update issue.  I don't use the
graphical update tools, and always have PackageKit disabled to prevent
duplicate downloads of updates.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 14:01 -0400, Neal Gompa wrote:
> 
> I have never heard of anyone reaching out to the KDE PK frontend
> developers for supporting this mechanism. As I recall, it required
> special development to get working in GNOME Software. Heck, even the
> system upgrade stuff required custom development and special plugins
> for GNOME Software. If you're going to suggest that people do it this
> way, then perhaps you should be reaching out to the Plasma Discover
> and Apper developers to ensure that it works from there too...

I'm giving users advice on how not to break their systems. I'm not
really in the business of telling desktops how to code their update
mechanisms.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 11:39 AM, Gerald B. Cox  wrote:
>
> On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi  wrote:
>>
>>
>> Well, the problem there, what do you mean by 'support'?
>>
>> In this case lots of people use dnf for updates, so IMHO it would be
>> "we will try and keep this working, and fix anything we can, but do
>> understand that there's a low level problem here that something could
>> mess up updates in progress, if you want to be more sure of not hitting
>> problems, use the offline updates in your graphical desktop"
>> >
>
>
> OK, I'm completely confused.
> First of all, I've never seen a message such as:
>
>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
>> when asked.

That was a suggested change to inform the user.

It's an OK idea. With "atomic" deployments (those that are rpm-ostree
based) the 'dnf update' command hard fails. You're expected to use
'rpm-ostree upgrade' which itself would be integrated into the
graphical updater.

>
> and I have NEVER used the graphical update since the first release of
> Fedora.  I've always used yum or dnf.  As I mentioned earlier in the past
> I've found the graphical tools to be quirky at best - perhaps that has
> changed, but since the command line has always worked for me, I've stuck
> with it.  Apparently I've missed something along the way because now people
> are implying that using the command line tools from within GNOME or KDE are
> dangerous.  What exactly is going on?


This is old news. It's come up on this list numerous times. It's the
*entire* reason why offline updates exists. Not doing them offline is
know to entail all kinds of non-deterministic risks.



> As far as rebooting after every update?  Huh?  Who does that?

Strictly speaking it's not necessary for every update, there's just no
mechanism for knowing for sure what updates entail more risk than
others. You'll notice that once an application is installed, whether
by dnf or Gnome Software, it's considered part of the system. There's
no separation of OS upgrades from application updates. The former
entail a lot more risk than the latter. In the near future, I expect
flatpak applications can be updated in place, once complete you'd get
a prompt to relaunch the application to use the update one, or
something like that.



>Are we
> Windows?

Yes, we're Windows. Is that what you want to hear? I don't understand
why you think this is a question to be taken seriously rather than
ridiculous.

And by the way, macOS does the same thing. The main difference there
is application updates rarely require reboots, because applications
are self contained. You do have to quit them for the update to get
applied though.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Michael Cronenworth]

On 10/04/2016 01:19 PM, Chris Murphy wrote:

Strictly speaking it's not necessary for every update, there's just no
mechanism for knowing for sure what updates entail more risk than
others. You'll notice that once an application is installed, whether
by dnf or Gnome Software, it's considered part of the system. There's
no separation of OS upgrades from application updates. The former
entail a lot more risk than the latter. In the near future, I expect
flatpak applications can be updated in place, once complete you'd get
a prompt to relaunch the application to use the update one, or
something like that.


dnf install python3-dnf-plugins-extras-tracer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 4, 2016 at 10:53 AM, Adam Williamson  wrote:

> The current GNOME update workflow, however, is the most reliable we
> have, because it downloads the updates then boots to a minimal systemd
> target with as few things running as possible to install the updates,
> then boots back to the normal system. This is far, far safer than
> running the update inside a desktop.
>

Interesting... since I don't use GNOME that is probably why I wasn't aware
of this.

I found this:
https://lists.fedoraproject.org/pipermail/users/2015-March/459603.html

>From what I've read so far, KDE does not do "offline" updates I'm still
researching so maybe that has changed, but in the above mentioned thread,
KDE did not support it.

I understand the theoretical exposure, but I guess what I'm missing is how
offline updates eliminates that risk? There is still a plethora of things
which could
interfere with a normal completion of the update process.  Seems to me it
would be more worthwhile to build in better error recovery within DNF than
to always require "offline" - especially
since the incidence of failure (at least anecdotally) just isn't that
high.  Instead of dealing with the problem (failed updates and error
recovery) - this approach just tries to avoid it by always requiring
a reboot.  Kind of defeats the purpose of being able to update a kernel
without a reboot, if your going to always reboot for other updates - and of
course the majority of updates don't require a reboot.

IMHO the risk/benefit ratio is way off on this approach to the problem -
but hey, that's just me - and I'm a KDE user who isn't using it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 4, 2016 at 11:19 AM, Chris Murphy 
wrote:

> >Are we
> > Windows?
>
> Yes, we're Windows. Is that what you want to hear? I don't understand
> why you think this is a question to be taken seriously rather than
> ridiculous.
>

No, it was a rhetorical question.   See my other response.  Basically, IMHO
this
"solution" fails a simple risk/benefit analysis.  Instead of dealing with
the root issue which
is error recovery it attempts to circumvent it at the expense of system
availability.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 12:49 PM, Michael Cronenworth  wrote:
> On 10/04/2016 01:19 PM, Chris Murphy wrote:
>>
>> Strictly speaking it's not necessary for every update, there's just no
>> mechanism for knowing for sure what updates entail more risk than
>> others. You'll notice that once an application is installed, whether
>> by dnf or Gnome Software, it's considered part of the system. There's
>> no separation of OS upgrades from application updates. The former
>> entail a lot more risk than the latter. In the near future, I expect
>> flatpak applications can be updated in place, once complete you'd get
>> a prompt to relaunch the application to use the update one, or
>> something like that.
>
>
> dnf install python3-dnf-plugins-extras-tracer

That's cool but it's not the default behavior, and it also doesn't
come in advance as part of all the information what will be updated.
It'd be useful to know what needs restarting, including if a reboot is
needed.

Looks like this might also be useful, but isn't included by default.
http://dnf-plugins-core.readthedocs.io/en/latest/needs_restarting.html



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Storing Automated Tasks/Tests In Dist-Git

[Richard W.M. Jones]

On Mon, Oct 03, 2016 at 08:21:42PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Oct 03, 2016 at 01:50:33PM -0600, Tim Flink wrote:
> > One of the features for Taskotron that we've been planning since the
> > beginning was a way for contributors to maintain their own automated
> > tasks/tests which would be run during a package's lifecycle.
> > 
> > I'm happy to say that we're almost to this milestone and wanted to get
> > some feedback from devel@ on the specifics of what we're planning WRT
> > where these automated tasks will be stored and the execution modes that
> > we're planning to support. Our current plan is written up at:
> > 
> > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/
> 
> Sounds reasonable.
> 
> How does the environment in which those tasks are run look?
> Would it be possible for example to run a test which launches
> a qemu VM to test stuff that requires a functional installation
> and a reboot?

And related to this question, do we also need to define
"TestRequires" packages/dependencies?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 12:51 PM, Gerald B. Cox  wrote:

> I understand the theoretical exposure, but I guess what I'm missing is how
> offline updates eliminates that risk?

The system reboots to system-update.target which is a minimal
environment. It's basically the kernel, systemd, rpm and maybe dnf.
Then it reboots again, with graphical.target.



>There is still a plethora of things
> which could
> interfere with a normal completion of the update process.

No.



> Seems to me it
> would be more worthwhile to build in better error recovery within DNF than
> to always require "offline" - especially
> since the incidence of failure (at least anecdotally) just isn't that high.

Sufficiently impractical that it's not possible. This is why offline
updates exists. It's why work is being done on
ostree>rpm-ostree>atomic host, which affects the entire build system,
deployments, updates, and eventually all of the mirrors. It's why
Microsoft and Apple don't allow anything other than offline updates.
It's why openSUSE has spent a ton of resources, and a few bloody
noses, getting completely atomic updates working with Btrfs and
snapper, with very fine rollback capabilities. There's a reason why so
many different experts at system updates have looked at this problem
and just say, yeah no, not anymore of that.


> Instead of dealing with the problem (failed updates and error recovery) -
> this approach just tries to avoid it by always requiring
> a reboot.

Yes. But it's also considered a stop gap. It's not the permanent
state. A better way forward is in development.

>Kind of defeats the purpose of being able to update a kernel
> without a reboot, if your going to always reboot for other updates - and of
> course the majority of updates don't require a reboot.

Fedora doesn't enable or use live patching for the kernel.


> IMHO the risk/benefit ratio is way off on this approach to the problem - but
> hey, that's just me - and I'm a KDE user who isn't using it.

I think your risk assessment is deficient and unconvincing. This has
been explained in great detail by those working on the various
solutions to the problem. Read those, then provide contra arguments if
you want. Otherwise this is sortof a noisy conversation.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Stephen John Smoogen]

On 4 October 2016 at 15:00, Gerald B. Cox  wrote:
>
> On Tue, Oct 4, 2016 at 11:19 AM, Chris Murphy 
> wrote:
>>
>> >Are we
>> > Windows?
>>
>> Yes, we're Windows. Is that what you want to hear? I don't understand
>> why you think this is a question to be taken seriously rather than
>> ridiculous.
>
>
> No, it was a rhetorical question.   See my other response.  Basically, IMHO
> this
> "solution" fails a simple risk/benefit analysis.  Instead of dealing with
> the root issue which
> is error recovery it attempts to circumvent it at the expense of system
> availability.

This problem is not easily solvable by dnf or yum or anything else.
You are standing on the branch of a tree. When you do an update you
are cutting off branches of a tree and growing new ones. Sometimes you
are cutting the trunk of the tree. The problem is that if you are
cutting your own branch or the tree trunk.. you are sunk.

The problem is that modern software has a lot of branches. The tree
looks like this
https://twitter.com/NaturelsWeird/status/783006609765269504

Maybe that branch you cut doesn't look like it has anything to do with
the one you are standing on.. but maybe it did and now you are hosed.

This has been a problem for as long as Red Hat Linux existed with a
remote shell and people would end up with crashed systems because sshd
died when an update was done. There were all kinds of 'hacks' to make
it work mostly but there were still conditions where you could crash
out your system. It also showed up every now and then on X updates
which could also be 'hacked' around but was still racy. As the tree
gets more complicated.. the more the hacks are moving from an 95%
solution to a 0.95 * 0.95 * 0.95 ... and ending up with it being a 60%
solution and just getting worse over time.



> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Toby Goodwin]

>Why do people have to think that people are being 'stauch defenders'
>when they might just needed a clearer explanation?

Stephen, I've been striving to keep my comments technically focused.
That remark slipped below my own standards. I didn't mean it as a
personal jibe, just a slightly light hearted way of characterizing one
side of the debate. I apologize to you, and anyone else who felt
slighted or offended.

>I know you
>mentioned chsh in your original email but even after rereading it, I
>am not able to make the leap from it to what you show below.

Thank Jakub Svoboda, it was all there in his original ticket [1].

And thank you, Stephen J Smoogen, for having the courage to publicly
change your mind!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c0

Toby
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Luya Tshimbalanga]

Thanks for the warning. Fortunately I frequently run update with Gnome 
Software. 
Does that issue also affect "pkcon update" command as well?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 4, 2016 at 12:22 PM, Chris Murphy 
wrote:

> > IMHO the risk/benefit ratio is way off on this approach to the problem -
> but
> > hey, that's just me - and I'm a KDE user who isn't using it.
>
> I think your risk assessment is deficient and unconvincing. This has
> been explained in great detail by those working on the various
> solutions to the problem. Read those, then provide contra arguments if
> you want. Otherwise this is sortof a noisy conversation.


Well, it could be that this is just an issue in the GNOME environment.  I
can't really comment on that
because I haven't used it for years.  Don't get upset just because I don't
agree with you..  You haven't produced
any hard facts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 11:51 -0700, Gerald B. Cox wrote:
> 
> I understand the theoretical exposure, but I guess what I'm missing is how
> offline updates eliminates that risk? There is still a plethora of things
> which could
> interfere with a normal completion of the update process.

It doesn't eliminate it, it minimizes it. It makes the 'plethora' much
smaller. Basically, I think, unless pid 1 crashes or dnf itself
crashes, the update is going to complete.

>   Seems to me it
> would be more worthwhile to build in better error recovery within DNF

I'm not sure that's a path that'd really get anywhere terribly
profitable. You could probably make some kinds of improvements to it, I
guess, but I'm not sure it's ever going to be possible to say 'meh, no
big deal if the updater crashes halfway through the update'.

>  than
> to always require "offline" - especially
> since the incidence of failure (at least anecdotally) just isn't that
> high.

The point is that it doesn't *have* to be high for it to be a problem.
Having this happen one time is one time too many.

(But FWIW, it seems like in this case the crash is pretty much reliably
reproducible on at least one affected system, and would happen *any*
time systemd-udev is updated.)

>   Instead of dealing with the problem (failed updates and error
> recovery) - this approach just tries to avoid it by always requiring
> a reboot.  Kind of defeats the purpose of being able to update a kernel
> without a reboot, if your going to always reboot for other updates - and of
> course the majority of updates don't require a reboot.

I think you're kind of conflating two things here. The offline update
thing isn't about 'make sure there's a reboot so the updates are fully
applied'. The first reboot is to get to the clean minimal environment
where the update can be safely run, the second reboot is to get back
*out* of that environment. It's not really 'avoid[ing the problem] by
always requiring a reboot', it's avoiding the problem by running the
update in a minimal environment, which happens to *imply* a couple of
reboots (though we've had discussions about ways it could be done with
just one reboot).

Some people do seem to place great stock in the 'update without
rebooting' thing, but it's fundamentally not entirely safe with RPM
updates. Even the offline update approach isn't 100% safe, though it's
a lot closer than updating in X and a little closer than updating from
a VT. Fedora, AFAIK, doesn't have any kind of focus on the whole
'update the kernel without rebooting' thing, so I'm not sure why you're
bringing that up.

If anything, the potential future Fedora is working towards is one
where the system is deployed and updated via ostree and apps are
deployed and updated via flatpak or DOCKAH DOCKAH DOCKAH. That's a
design where it's feasible to talk about safe updates without reboots.

> IMHO the risk/benefit ratio is way off on this approach to the problem -
> but hey, that's just me - and I'm a KDE user who isn't using it.

If you have an affected system, then the risk of running an update that
includes systemd-udev from inside X is 100%. That's a pretty high
ratio.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 1:34 PM, Luya Tshimbalanga
 wrote:
> Thanks for the warning. Fortunately I frequently run update with Gnome 
> Software.
> Does that issue also affect "pkcon update" command as well?

Likely. It's avoided if you use --only-download, enable the offline
update trigger and reboot.




-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 19:34 +, Luya Tshimbalanga wrote:
> Thanks for the warning. Fortunately I frequently run update with Gnome 
> Software. 
> Does that issue also affect "pkcon update" command as well?

Yes, it would. The issue does have an element of hardware dependence
also. What we've worked out so far (with thanks to Zbyszek) is
basically this:

1. When you update systemd-udev , it restarts systemd-udev-trigger.service
   in %post
2. That calls `udevadm trigger --type=devices --action=add`
3. That seems to result in the video adapter effectively being replugged
   at the udev level

Now on *most* systems, this seems to just cause X to (metaphorically)
blink, go "what the hell happened there?", shrug, and carry on. If your
system is one of these, you won't really notice anything. On affected
systems, however - which so far seems to be something like 'some
systems with NVIDIA adapters, possibly ones with NVIDIA/Intel hybrid
graphics' - it causes X to crash.

If you want to check if your system is affected you can just run
'systemctl restart systemd-udev-trigger.service' as root with a desktop
running, and see if it crashes. Make sure you don't have anything
running unsaved. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 4, 2016 at 12:52 PM, Chris Murphy 
wrote:

>
> Like I said, others have been working on this for a while, and they
> have documented it and they've included their hard facts. You just
> haven't bothered to make yourself aware of anything beyond your own
> experience.
>

Interesting... I posted a few links - still reading... haven't found
anything that changes my opinion.
If you have a link with some facts and statistics on failure please post.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 1:37 PM, Gerald B. Cox  wrote:
>
> On Tue, Oct 4, 2016 at 12:22 PM, Chris Murphy 
> wrote:
>>
>> > IMHO the risk/benefit ratio is way off on this approach to the problem -
>> > but
>> > hey, that's just me - and I'm a KDE user who isn't using it.
>>
>> I think your risk assessment is deficient and unconvincing. This has
>> been explained in great detail by those working on the various
>> solutions to the problem. Read those, then provide contra arguments if
>> you want. Otherwise this is sortof a noisy conversation.
>
>
> Well, it could be that this is just an issue in the GNOME environment.  I
> can't really comment on that
> because I haven't used it for years.

It is not a GNOME specific environment, this has already been explained.

>Don't get upset just because I don't
> agree with you..  You haven't produced
> any hard facts.

You can't make me angry. Meanwhile, you're constantly citing only your
own anecdotal evidence and then extrapolating beyond it to a much
broader population without any hard facts.

Like I said, others have been working on this for a while, and they
have documented it and they've included their hard facts. You just
haven't bothered to make yourself aware of anything beyond your own
experience.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 1:57 PM, Gerald B. Cox  wrote:
>
> On Tue, Oct 4, 2016 at 12:52 PM, Chris Murphy 
> wrote:
>>
>>
>> Like I said, others have been working on this for a while, and they
>> have documented it and they've included their hard facts. You just
>> haven't bothered to make yourself aware of anything beyond your own
>> experience.
>
>
> Interesting... I posted a few links - still reading... haven't found
> anything that changes my opinion.
> If you have a link with some facts and statistics on failure please post.

Let me Google that for you? No thanks. I told you the various projects
that are working on safer system updates, they've written tons about
this on their lists. That's where I learned about this stuff.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 4, 2016 at 1:02 PM, Chris Murphy 
wrote:

> On Tue, Oct 4, 2016 at 1:57 PM, Gerald B. Cox  wrote:
> >
> > On Tue, Oct 4, 2016 at 12:52 PM, Chris Murphy 
> > wrote:
> >>
> >>
> >> Like I said, others have been working on this for a while, and they
> >> have documented it and they've included their hard facts. You just
> >> haven't bothered to make yourself aware of anything beyond your own
> >> experience.
> >
> >
> > Interesting... I posted a few links - still reading... haven't found
> > anything that changes my opinion.
> > If you have a link with some facts and statistics on failure please post.
>
> Let me Google that for you? No thanks. I told you the various projects
> that are working on safer system updates, they've written tons about
> this on their lists. That's where I learned about this stuff.


Chris, I have been googling... and reading quite a bit... what I said was
that
I have yet to find what you are claiming.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Luya Tshimbalanga]

I confirm my system, an AMD/AMD hybrid graphics powered laptop, is affected by 
executing 'systemctl restart systemd-udev-trigger.service' as root on desktop. 
The desktop session crashed and the login screen comes afterwards.
The same command on a dedicated NVIDIA graphics card is fairly harmless.

It seems the issue is affecting all hardware with hybrid graphics.

Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 20:34 +, Luya Tshimbalanga wrote:
> I confirm my system, an AMD/AMD hybrid graphics powered laptop, is
> affected by executing 'systemctl restart systemd-udev-
> trigger.service' as root on desktop. The desktop session crashed and
> the login screen comes afterwards.
> The same command on a dedicated NVIDIA graphics card is fairly
> harmless.
> 
> It seems the issue is affecting all hardware with hybrid graphics.

That's great data, thanks - I'm gonna find a few other people to test,
but it definitely sounds like 'hybrid graphics' is the trigger here.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Luya Tshimbalanga]

> On Tue, Oct 4, 2016 at 1:34 PM, Luya Tshimbalanga
>  
> Likely. It's avoided if you use --only-download, enable the offline
> update trigger and reboot.
Thanks for the tips.

Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Toby Goodwin]

>My objection here is roughly the same. /sbin/nologin does not mean 
>"locked out", it's a non-shell that can serve as a shell. While there 
>may be some value in chsh disallowing a change *from* /sbin/nologin to 
>something else by the own user, it's not intended to block any access at 
>all by a user -- it's canonical purpose allowed FTP logins successfully, 
>for example.

OK. I understand what you're saying. I suppose this boils down to what
"nologin" is supposed to mean.

1. On the one hand, we have the behaviour of Fedora (and RHEL and
CentOS) since 2002, with nologin in /etc/shells, which is as you
describe.

2. On the other hand, we have nologin as introduced by 4.4BSD and copied
by Linux, including the original RedHat distro itself before Fedora
days: nologin is absent from /etc/shells, and setting it does disable
all access.

I am sure that disallowing logins while still allowing FTP was *not* the
original canonical purpose of nologin in 4.4BSD. Indeed, there is a
currently open ticket [1] to remove this text from the shells(5) man
page:

   Be aware that there are programs which consult this file to
   find out if a user is a normal user; for example, FTP daemons
   traditionally disallow access to users with shells not included
   in this file.

This text, of course, also appears in all those other Linux distros
where nologin is not in /etc/shells. 

>To prevent an 'su' specification of shell and to prevent any login, one 
>can use /bin/false easily enough (which, again, was historical practice 
>AFAIK). To prevent login via password (or an 'su' from one local user to 
>another), usermod -L would seem to be more correct.

It's true that we used to use /bin/false to disable shell access. I
wasn't there at the time, but I imagine the reason nologin was invented
was to make it clear to a user that their account has been disabled by
printing a message, rather than just mysteriously kicking them out.

It's also true that locking the password is a good idea if you want to
definitively disable an account. However, on all other systems except
Fedora and friends, nologin alone does seem to be sufficient.

(Of course, ssh with key-based access does not respect locked passwords,
although I've just discovered it does respect expired accounts. It would
seem that "usermod -e 1 -s /sbin/nologin -L user" is the belt and braces
approach to disabling an account!)

>My concern here is that we're losing a useful tool: a built-in 
>"non-shell" shell, functioning as a middle-ground between an invalid 
>shell and an account lockout.

Well, you do of course have the option of adding nologin back into
/etc/shells, or supplying your own program to do the job and listing
*that* in shells. You could even try to get such a thing into the core
distribution, but please don't call "nologin", as that is confusing to
anyone that's used to *BSD, Debian, etc.

I contend that we have this middle ground by historical accident, not by
design. If it were by design, surely all those system accounts (bin,
daemon, adm, etc) would have the "definitely no access" shell,
/bin/false or whatever, and not the "middle ground" shell of nologin?

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

Toby
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Tom Hughes]

On 04/10/16 16:51, Adam Williamson wrote:


Recently several reports of people getting 'duplicated packages' and
'kernel updates not working' have come through to us in QA from Fedora
24 users. I managed to get one reporter to explain more specifically
what happened, and it sounds a lot like what's happening is that
something in the 'dnf update' process can cause a GNOME or X crash,
possibly depending on hardware or package set installed. When that
happens, the update process is killed and does not complete cleanly,
which is why you get 'duplicated packages' and other odd results.


I had it happen this morning in fact.

When it happens X crashes and you're left with duplicate package entries 
that a distro-sync will normally fix though this morning was a bit more 
fun because systemd was included and the distro-sync didn't want to 
remove the duplicate.


It only ever happens on one of my machines, so it's obviously something 
about the environment, possibly the graphics card as that's the only 
machine I do this on that has nvidia graphics?


The weird thing is that there was nothing particularly X related in the 
update that caused it this morning. In fact systemd was probably about 
the most low level thing that was in the update.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 21:54 +0100, Tom Hughes wrote:
> 
> It only ever happens on one of my machines, so it's obviously something 
> about the environment, possibly the graphics card as that's the only 
> machine I do this on that has nvidia graphics?
> 
> The weird thing is that there was nothing particularly X related in the 
> update that caused it this morning. In fact systemd was probably about 
> the most low level thing that was in the update.

We've pretty much pinned it down, now. The recipe is: hybrid graphics +
systemd-udev update == X crash. That is, if there's a systemd-udev
update in the dnf transaction, and the system has hybrid graphics, and
X is running while the update runs, X will crash. If you're running the
update in a VT, X will crash but the update will complete OK. If you
run the update inside X, the update process will die when X crashes and
your system will be left messed up.

I'm gonna write up a blog post and spread the word about this a bit,
I'll send the link shortly; if people could spread it around that'd be
great.

The bug reports are
https://bugzilla.redhat.com/show_bug.cgi?id=1341327 (for the X side)
and
https://bugzilla.redhat.com/show_bug.cgi?id=1378974 (for the systemd
side). We are going to try and ensure the bug doesn't affect F25 Beta
installs. An update is pending for F24, but ironically (since the
service restart is in %postun not %post), the transaction to apply the
update will *suffer from* the problem; the update will only ensure that
*subsequent* updates no longer trigger the problem.

Thanks for the data everyone!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Tom Hughes]

On 04/10/16 22:04, Adam Williamson wrote:


We've pretty much pinned it down, now. The recipe is: hybrid graphics +
systemd-udev update == X crash. That is, if there's a systemd-udev
update in the dnf transaction, and the system has hybrid graphics, and
X is running while the update runs, X will crash. If you're running the
update in a VT, X will crash but the update will complete OK. If you
run the update inside X, the update process will die when X crashes and
your system will be left messed up.


My machine at work where this happens isn't hybrid. It has three 
monitors spread over two Nvidia cards though, driven by nouveau rather 
than the proprietary drivers.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Luya Tshimbalanga]

> On Tue, 2016-10-04 at 20:34 +, Luya Tshimbalanga wrote:
> 
> That's great data, thanks - I'm gonna find a few other people to test,
> but it definitely sounds like 'hybrid graphics' is the trigger here.
No problem. Glad the data helps.

Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Luya Tshimbalanga]

> On Tue, 2016-10-04 at 20:34 +, Luya Tshimbalanga wrote:
> 
> That's great data, thanks - I'm gonna find a few other people to test,
> but it definitely sounds like 'hybrid graphics' is the trigger here.
No problem. Glad the data helps.

Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 22:15 +0100, Tom Hughes wrote:
> On 04/10/16 22:04, Adam Williamson wrote:
> 
> > We've pretty much pinned it down, now. The recipe is: hybrid graphics +
> > systemd-udev update == X crash. That is, if there's a systemd-udev
> > update in the dnf transaction, and the system has hybrid graphics, and
> > X is running while the update runs, X will crash. If you're running the
> > update in a VT, X will crash but the update will complete OK. If you
> > run the update inside X, the update process will die when X crashes and
> > your system will be left messed up.
> 
> 
> My machine at work where this happens isn't hybrid. It has three 
> monitors spread over two Nvidia cards though, driven by nouveau rather 
> than the proprietary drivers.

OK, so probably strictly speaking this is triggered by having multiple
adapters. 'Hybrid graphics' is by far the most common case of that
these days, though. Thanks for the note, I'll revise my blog post (that
I'm writing ATM).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 4, 2016 at 2:39 PM, Adam Williamson
 wrote:
> On Tue, 2016-10-04 at 20:34 +, Luya Tshimbalanga wrote:
>> I confirm my system, an AMD/AMD hybrid graphics powered laptop, is
>> affected by executing 'systemctl restart systemd-udev-
>> trigger.service' as root on desktop. The desktop session crashed and
>> the login screen comes afterwards.
>> The same command on a dedicated NVIDIA graphics card is fairly
>> harmless.
>>
>> It seems the issue is affecting all hardware with hybrid graphics.
>
> That's great data, thanks - I'm gonna find a few other people to test,
> but it definitely sounds like 'hybrid graphics' is the trigger here.

I have AMD/Intel hybrid graphics and the problem doesn't happen. This
is F24, GNOME on Wayland.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 15:29 -0600, Chris Murphy wrote:
> On Tue, Oct 4, 2016 at 2:39 PM, Adam Williamson
>  wrote:
> > On Tue, 2016-10-04 at 20:34 +, Luya Tshimbalanga wrote:
> > > I confirm my system, an AMD/AMD hybrid graphics powered laptop, is
> > > affected by executing 'systemctl restart systemd-udev-
> > > trigger.service' as root on desktop. The desktop session crashed and
> > > the login screen comes afterwards.
> > > The same command on a dedicated NVIDIA graphics card is fairly
> > > harmless.
> > > 
> > > It seems the issue is affecting all hardware with hybrid graphics.
> > 
> > 
> > That's great data, thanks - I'm gonna find a few other people to test,
> > but it definitely sounds like 'hybrid graphics' is the trigger here.
> 
> 
> I have AMD/Intel hybrid graphics and the problem doesn't happen. This
> is F24, GNOME on Wayland.

Well, the bug is an X crash, so it's not surprising it doesn't exist in
Wayland. ;) Good job Wayland for not crashing, I guess...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 14:04 -0700, Adam Williamson wrote:
> 
> I'm gonna write up a blog post and spread the word about this a bit,
> I'll send the link shortly; if people could spread it around that'd be
> great.

Blog post:

https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-when-system-has-hybrid-graphics-and-systemd-udev-is-in-update/

If folks can spread that around, it'd be great. Please let me know of
any errors or inaccuracies you spot.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Jens Lody]

Am Tue, 04 Oct 2016 14:22:34 -0700
schrieb Adam Williamson :

> On Tue, 2016-10-04 at 22:15 +0100, Tom Hughes wrote:
> > On 04/10/16 22:04, Adam Williamson wrote:
> >   
> > > We've pretty much pinned it down, now. The recipe is: hybrid
> > > graphics + systemd-udev update == X crash. That is, if there's a
> > > systemd-udev update in the dnf transaction, and the system has
> > > hybrid graphics, and X is running while the update runs, X will
> > > crash. If you're running the update in a VT, X will crash but the
> > > update will complete OK. If you run the update inside X, the
> > > update process will die when X crashes and your system will be
> > > left messed up.  
> > 
> > 
> > My machine at work where this happens isn't hybrid. It has three 
> > monitors spread over two Nvidia cards though, driven by nouveau
> > rather than the proprietary drivers.  
> 
> OK, so probably strictly speaking this is triggered by having multiple
> adapters. 'Hybrid graphics' is by far the most common case of that
> these days, though. Thanks for the note, I'll revise my blog post
> (that I'm writing ATM).
I did not see such crashes on my hybrid laptop with F24, X and
gnome-shell.
I mostly use the intel gpu, but some games run on the
nvidia-gpu with nouveau-driver.
I tried the "systemctl restart systemd-udev-trigger.service"-approach
from a "normal" terminal and from a terminal under nouveau and there
was not even a flashing of the monitor visible. I do not have a
secondary (or third ...) monitor connected, just the default laptop
screen.

Jens




pgp36LaT8PMSZ.pgp
Description: Digitale Signatur von OpenPGP
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Tue, 2016-10-04 at 23:54 +0200, Jens Lody wrote:
> Am Tue, 04 Oct 2016 14:22:34 -0700
> schrieb Adam Williamson :
> 
> > On Tue, 2016-10-04 at 22:15 +0100, Tom Hughes wrote:
> > > On 04/10/16 22:04, Adam Williamson wrote:
> > >   
> > > > We've pretty much pinned it down, now. The recipe is: hybrid
> > > > graphics + systemd-udev update == X crash. That is, if there's a
> > > > systemd-udev update in the dnf transaction, and the system has
> > > > hybrid graphics, and X is running while the update runs, X will
> > > > crash. If you're running the update in a VT, X will crash but the
> > > > update will complete OK. If you run the update inside X, the
> > > > update process will die when X crashes and your system will be
> > > > left messed up.  
> > > 
> > > 
> > > 
> > > My machine at work where this happens isn't hybrid. It has three 
> > > monitors spread over two Nvidia cards though, driven by nouveau
> > > rather than the proprietary drivers.  
> > 
> > 
> > OK, so probably strictly speaking this is triggered by having multiple
> > adapters. 'Hybrid graphics' is by far the most common case of that
> > these days, though. Thanks for the note, I'll revise my blog post
> > (that I'm writing ATM).
> 
> I did not see such crashes on my hybrid laptop with F24, X and
> gnome-shell.
> I mostly use the intel gpu, but some games run on the
> nvidia-gpu with nouveau-driver.
> I tried the "systemctl restart systemd-udev-trigger.service"-approach
> from a "normal" terminal and from a terminal under nouveau and there
> was not even a flashing of the monitor visible. I do not have a
> secondary (or third ...) monitor connected, just the default laptop
> screen.

OK, that's the second report of an unaffected hybrid system (cmurf said
the same thing).

So basically we can say that at least several systems with multiple
adapters are affected, and no-one has yet reported a system with a
single adapter being affected so far as I can tell. But not *all*
multiple adapter systems are affected. We don't know what the
difference is yet. Still, safest thing is just to assume that if you
have a multiple adapter system you may be affected.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Björn Persson]

Adam Williamson wrote:
> If you're using Workstation, the offline update system is expressly
> designed to minimize the likelihood of this kind of problem, so please
> do consider using it.

In CentOS or Debian I can afford to reboot for every update. With
Fedora's rapid stream of updates that's simply not workable.

> Otherwise, at least run 'dnf update' in a VT -
> hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
> there.

In a VT I'll often be unable to review the list of updates before
hitting Y, as I'll only see the end of the list.

So if this bug is specific to F24 and multiple GPUs, then I guess I'm
lucky to be still using F23 and having only one GPU.

Björn Persson


pgpyM39AZAi5x.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Björn Persson]

Stephen Gallagher wrote:
> On 10/04/2016 01:20 PM, Stephen Gallagher wrote:
> > On 10/04/2016 12:51 PM, Andrew Lutomirski wrote:  
> >> For server use, I'm not convinced that the offline update
> >> mechanism is supported (at the very least, I have no idea how to
> >> trigger it), and servers have the same issue.  
> > 
> > ```
> > sudo pkcon refresh force && \
> > sudo pkcon update --only-download && \
> > sudo pkcon offline-trigger **
> > sudo systemctl reboot
> > ```  
> 
> That "**" should have been "&& \"

If there isn't a single command to do all of that, that can compete
with "yum update" in simplicity, then that shows that offline updating
isn't being seriously promoted for servers.

Björn Persson


pgpCYodPpl6y8.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Wed, 2016-10-05 at 00:20 +0200, Björn Persson wrote:
> Adam Williamson wrote:
> > If you're using Workstation, the offline update system is expressly
> > designed to minimize the likelihood of this kind of problem, so please
> > do consider using it.
> 
> 
> In CentOS or Debian I can afford to reboot for every update. With
> Fedora's rapid stream of updates that's simply not workable.

Then just don't apply every update. There's no law that says you have
to...if there's a pending security update you get a different and more
urgent notification, btw.

> > Otherwise, at least run 'dnf update' in a VT -
> > hit ctrl-alt-f3 to get a VT console login prompt, log in, and do it
> > there.
> 
> 
> In a VT I'll often be unable to review the list of updates before
> hitting Y, as I'll only see the end of the list.

You can look at the list from a desktop terminal but actually run the
transaction from the VT, or you can run inside screen or tmux and use
their scrollback features...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[stan]

On Wed, 5 Oct 2016 00:20:25 +0200
Björn Persson  wrote:
 
> In a VT I'll often be unable to review the list of updates before
> hitting Y, as I'll only see the end of the list.

An alternative to Adam's suggestions.

It takes a couple of logins as root, but running
dnf update > /tmp/dnf_out 2> /tmp/dnf_ror
in one terminal and then doing a 
less /tmp/dnf_*
in another allows a view of the updates before approving or denying
them. When you see the (y or N) in the less output, go back to the
console running the program and make your selection.  A little clumsy,
but works fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] python-matplotlib-2.0.0 major update

[Christian Krause]

Hi,

On Thu, Sep 22, 2016 at 3:41 PM, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

>
> I've just pushed (but not built) python-matplotlib-2.0.0b4 to rawhide.
> I'll be attempting to rebuild all the affected packages locally to
> test if they're compatible. In the meantime, feel free to git pull
> and build locally for your own testing.
>
> $ dnf repoquery --srpm --releasever=rawhide --whatrequires
> python-matplotlib --alldeps
>
> anki
>

Thanks for the heads-up. I just tested anki against
python-matplotlib-2.0.0b4: works fine, I haven't seen any issues.

There is no need to rebuild anki since it doesn't have a "BuildRequires:"
for python-matplotlib. The dependency is just caused by a "Requires:".

Best regards,
Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Björn Persson]

Adam Williamson wrote:
> On Wed, 2016-10-05 at 00:20 +0200, Björn Persson wrote:
> > Adam Williamson wrote:  
> > > If you're using Workstation, the offline update system is
> > > expressly designed to minimize the likelihood of this kind of
> > > problem, so please do consider using it.  
> > 
> > 
> > In CentOS or Debian I can afford to reboot for every update. With
> > Fedora's rapid stream of updates that's simply not workable.  
> 
> Then just don't apply every update. There's no law that says you have
> to...if there's a pending security update you get a different and more
> urgent notification, btw.

I don't get any notifications at all. I just try to remember to run Yum
periodically, and there I'm not told which updates are security updates.

I used to subscribe to the package-announce list, but I had to drop that
when some broken program started sending invalid mails to the list, and
the list server kicked me out for rejecting invalid mail. It was never a
very good notification mechanism anyway, as I always had to wait a day
or two for the packages to appear on the mirrors before I could update.

Many years ago there was sometimes a tray applet that could notify me
about pending updates, but it disappeared. If something similar exists
now, then I don't know its name so I don't know what to install.
Perhaps there is some notification mechanism in Gnome 3; I wouldn't
know. I'm not aunt Tillie so I don't use Gnome 3.

Björn Persson


pgpvv1clIcwfk.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Björn Persson]

Chris Murphy wrote:
> It's not really workable without an atomic and out of tree update
> method, otherwise libraries are still yanked out from under running
> processes at some point. 

Running programs and their loaded libraries count as open files. Unixy
filesystems don't delete open files. They change the directory entry to
point to the new file and keep the old file around until it's closed.
Therefore libraries are *not* yanked out from under running processes.

What tends to break is badly designed GUI programs that apparently
don't keep their files open but still expect different files to be from
the exact same version. Firefox and Seamonkey seem to do something like
that. They tend to break in funny ways when updated. Many other GUI
programs have no problems with getting updated while running.

Björn Persson


pgp3XdnO0ZVry.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Björn Persson]

stan wrote:
> On Wed, 5 Oct 2016 00:20:25 +0200
> Björn Persson  wrote:
>  
> > In a VT I'll often be unable to review the list of updates before
> > hitting Y, as I'll only see the end of the list.  
> 
> An alternative to Adam's suggestions.
> 
> It takes a couple of logins as root, but running
> dnf update > /tmp/dnf_out 2> /tmp/dnf_ror
> in one terminal and then doing a 
> less /tmp/dnf_*
> in another allows a view of the updates before approving or denying
> them. When you see the (y or N) in the less output, go back to the
> console running the program and make your selection.  A little clumsy,
> but works fine.

It's pretty obvious that improvement is needed when people start to
suggest *that* kind of hack-arounds.

Björn Persson


pgpm9eQH_INz2.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ... and Fedora 25! - Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Ian Pilcher]

On 10/04/2016 01:03 PM, Tomasz Torcz wrote:

On Tue, Oct 04, 2016 at 12:31:43PM -0500, Ian Pilcher wrote:


Can you clarify?  In what circumstances would the dnf command running
within a screen session not survive an X/desktop crash?



   KillUserProcesses=yes



Ouch!  Forgot about that.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Sam Varshavchik]

Andrew Lutomirski writes:


My point is that a lot of this exposure could be avoided.  Sure,
there's a decent chance that updating packages will crash running
programs.  But, unless one of those programs is dnf, rpm, or systemd,
that shouldn't be an excuse to blow up the whole upgrade.


I agree.

As far as I'm concerned, the only possible valid reason for the system to  
end up in an inconsistent state would be if the whole thing got SIGKILLed.


And I strongly doubt that an X crash would SIGKILL some process started by  
dnf. SIGHUP would be more likely. Perhaps SIGTERM, but neither of those  
should result in dnf blowing chunks and messing things up. Either the most  
recent transaction should be rolled back, or completed anyway.


The notion that an X crash would result in such situation is quite … 
inexplicable. There's simply no valid, logical reason for that, and I'm  
quite disappointed to hear that.



Firefox blow up many times due to concurrent dnf, but this doesn't
hose my system.  Having gnome-terminal or X or Wayland die shouldn't
be any more dangerous.


Agreed.

And even if dnf itlsef is SIGKILLed, that may certainly result in a system  
being temporarily in an inconsistent state, but I would expect that unless  
something like glibc was in the process of being unpacked, it should be  
recoverable.





pgpDGX3jAI1L8.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Sam Varshavchik]

Chris Murphy writes:


I don't understand how you arrive at this conclusion. dnf is sitting
on the top of a house of cards when it's running in Terminal. If
anything below it dies, dnf dies and by extension so is rpm. Could dnf
be put into it's own session or scope (whatever it's called), and


Has anyone ever heard of sigaction()? Just wondering.


would that prevent it from dying if the whole GUI died? Even if true,
how does the user know to wait XX minutes before hitting the reset
button?


I heard of a command called "ps" that might come in useful, in situations  
like that.






pgpxZwfCAVS0T.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org