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

[Kevin Kofler]

Adam Williamson wrote:
> What exactly would you have had me do? Just sit on this and pretend
> there was no bug and when we saw more and more people come into #fedora
> and complain about it, tell them the risk was minimal so they should
> just suck it up and get on with their lives? I mean, seriously, what do
> you suggest?

Tell people the actual workaround?

rpm -Uvh --nodeps --nopostun \
  http://$MIRROR/updates/testing/25/x86_64/s/systemd-udev-231-8.fc25.x86_64.rpm

--nopostun will disable the broken scriptlet.
--nodeps will avoid the hard EVR requirement on the rest of systemd.
Then a normal dnf update should fix your deps.

Kevin Kofler
___
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

[Florian Weimer]

On 10/06/2016 05:45 AM, Adam Williamson wrote:

On Wed, 2016-10-05 at 20:38 -0700, Andrew Lutomirski wrote:


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?



Yes.  dnf would prepare the transaction, solve dependencies, etc, and
then kick off a service to do the actual work.  The service would pipe
the progress state and such back to the client.


FWIW, someone told me today (in rather colorful terms) that apt-get is
designed exactly this way. It survives the death of its controlling
terminal (and, allegedly - again, I don't know this from personal
experience - has decent support for completing failed transactions if
the apt-get process itself crashes).


apt-get and dpkg cannot survive arbitrary crashes, but in general, the 
combination will rerun the equivalent of %preinst and %postinst scripts, 
to make sure that all installed packages are in a properly configured state.


It also intercepts ^C, so that you don't end up with an inconsistent 
package database simply because the administrator hit ^C in the wrong 
terminal.


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

[Florian Weimer]

On 10/05/2016 03:00 AM, Adam Williamson wrote:

On Tue, 2016-10-04 at 20:43 -0400, Sam Varshavchik wrote:

But ordinary regular app updates will happily run on cruise control, without
bringing the system down into single user mode. If Android can do that, I
see no reason why Fedora can't, either. The only time you need to reboot an
Android device is for a kernel-level update.


No, in fact, it's for any *system level* update. Any change to the
underlying system (as opposed to an app) requires the full reboot
treatment. Only updates to app packages don't.


Even that depends on what the “app” is doing.  If the format of data 
files changes in an incompatible way (or just their location on the file 
system



The reason Android can do fairly good app updates is precisely because
it does exactly what Flatpak and Snappy are trying to do for Linux:
hard separation between app space and system space.


I seriously doubt that is the reason.

This looks much more relevant:




Basically, the system can kill applications which do not run in the 
foreground at *any* time to recover resources.  This facility can also 
be used to transparently update system components on which applications 
depend.


> We can't realistically do it with the 'distribution is just a big pile
> of RPMs' model.

The lack of application state management which mirrors what mobile 
platforms are doing is hardly an RPM issue.


Florian

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Hans de Goede]

Hi,

On 05-10-16 20:30, Bruno Wolff III wrote:

On Wed, Oct 05, 2016 at 14:19:12 -0400,
 Matthew Miller  wrote:


In any case, what do you all think?


I don't think the tracking side would be hard to do. What I'd like to hear 
about is how the list will work for getting bugs better fixed than bugzilla 
entries will? Is this something people paid to work on Fedora (or perhaps 
centos and rhel for bugs in common with Fedora) can use to change their work 
priorities? Are we going to hope that volunteers will be more likely to notice 
bugs on this list than bugzilla. Or perhaps we hope to recruit volunteers who 
wouldn't normally work on a package to help out for these important bugs? 
(There are some really good packagers who could help out almost
anywhere but obviously have limited time and can't help everywhere.)


Speaking for myself only here, my experience in the gfx team
is that there are so many bugs that I cannot see the forest
through the trees.

A list with issues which are not blockers, but only barely so
and it would be really really good to have them fixed,
would certainly be a list I would look at and see if there is
anything on there I can pick up.

So I like the idea, I do propose to simply re-use most of
the blocker bug process for this, rather then inventing yet
another process. I guess this could even be integrated and
the way to get bugs on the list would be to propose them
as blockers as normal and then during the blocker meeting
when the vote says "no this is not a blocker" a second vote
is done to see if it is a critical bug.

Regards,

Hans
___
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 Kofler]

As for the KDE part:

Adam Williamson wrote:
> The 'standard Fedora solution' for KDE is...well I don't know,

The standard updater on the KDE Spin is plasma-pk-updates. The other tools 
can also do updates (or at least they claim to be able to), but the applet 
in the system tray that automatically notifies users of updates (and can 
also be manually refreshed) and performs them is plasma-pk-updates. The 
intention is that people should not be firing up a windowed application to 
do updates manually at all, they should just OK the automatic notification 
in the system tray (i.e., click on the "Install Updates" button).

> because KDE being KDE it ships three different package management GUIs,

There are 3 different package management GUIs not because "KDE is KDE", but 
because we had to work around at least 2 issues with Apper:
1. a Fedora-specific issue: the PackageKit-hif backend (still) does not
   implement the APIs to enumerate comps groups that Apper needs (which is
   the main reason Discover was added, so that people can browse packages –
   Discover uses AppStream instead of PackageKit for that), and
2. an upstream issue: Apper was not ported to KF5 (there is now an
   experimental port), and Plasma 4 (libplasma 1) widgets/plasmoids cannot
   be used in Plasma 5 (libplasma 2), so the standalone applet
   plasma-pk-updates was written (which is likely to stay because it is
   already better than the Apper plasmoid ever was, it shows information
   Apper displays only if you bring up the full UI).

We are looking into replacing Apper with something working better, but right 
now, the most likely candidate would be dnfdragora + plasma-pk-updates 
(dnfdragora itself has no applet, and is unlikely to get one because it is a 
cross-desktop solution using the toolkit abstraction libyui; Mageia, where 
dnfdragora comes from, is also going to implement plasma-pk-updates), and I 
am not sure Discover is going to be kicked out, either (some people really 
believe in AppStream – if it was up to me, Discover would be shown the door 
as soon as dnfdragora is implemented). Unfortunately, since, unlike the 3 
current tools, dnfdragora does not use PackageKit (but dnfdaemon), it will 
not really mean fewer ways to do updates. We are not going to patch out 
updating support from the package management applications.

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

[Bug 1381897] perl-Messaging-Message-1.6.1 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Messaging-Message-1.6.1-1.el6 has been pushed to the Fedora EPEL 6 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0018c104ee

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [HEADS UP] libtimidity-0.2.0 comes to rawhide

[Igor Gnatenko]

On Tue, Oct 4, 2016 at 10:42 AM, Igor Gnatenko  wrote:
> 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
Rebuilt and patch sent upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=772503
> * moc
RPM Fusion package, no actions done.
> * openttd
Rebuilt without any problems.
>
> 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



-- 
-Igor Gnatenko
___
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)

[Igor Gnatenko]

On Tue, Oct 4, 2016 at 10:18 AM, Björn Esser  wrote:
> 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.
I'm getting report that minetest has broken dependency on libjsoncpp.
Can you rebuild it as well?
>
> 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



-- 
-Igor Gnatenko
___
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 06.10.2016 um 11:09 schrieb Igor Gnatenko:

On Tue, Oct 4, 2016 at 10:18 AM, Björn Esser  wrote:

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.

I'm getting report that minetest has broken dependency on libjsoncpp.
Can you rebuild it as well?

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





minetest has been rebuild successfully for fc25.  On Rawhide, I get a 
build-error, which isn't related to jsoncpp:


-- *** Will build version 0.4.14 ***
-- Found Irrlicht: /usr/lib64/libIrrlicht.so
-- Found CURL: /usr/lib64/libcurl.so
-- cURL support enabled.
-- Found GetText: /usr/include
-- GetText enabled; locales found: 
be;ca;cs;da;de;eo;es;et;fr;he;hu;id;it;ja;jbo;ko;ky;lt;nb;nl;pl;pt;pt_BR;ro;ru;tr;uk;zh_CN;zh_TW

-- Found OpenAL: /usr/lib64/libopenal.so
-- Found VORBIS: /usr/include
-- Sound enabled.
-- Could NOT find LuaJit (missing:  LUA_INCLUDE_DIR)
-- LuaJIT not found, using bundled Lua.
CMake Error at src/CMakeLists.txt:173 (add_subdirectory):
  add_subdirectory given source "lua" which is not an existing directory.
-- Using GMP provided by system.
-- Found GMP: /usr/lib64/libgmp.so
-- Could NOT find Curses (missing:  CURSES_LIBRARY CURSES_INCLUDE_PATH)
-- ncurses not found!
-- LevelDB backend enabled.
-- Redis not found!
-- Found SQLite3: /usr/lib64/libsqlite3.so
-- Found JSONCPP: /usr/lib64/libjsoncpp.so
-- Using system JSONCPP library.
-- SpatialIndex not found!
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so
-- Looking for XOpenDisplay in 
/usr/lib64/libX11.so;/usr/lib64/libXext.so - found

-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Found X11: /usr/lib64/libX11.so
-- Found OpenGL: /usr/lib64/libGL.so
-- Found JPEG: /usr/lib64/libjpeg.so
-- Found BZip2: /usr/lib64/libbz2.so (found version "1.0.6")
-- Looking for BZ2_bzCompressInit
-- Looking for BZ2_bzCompressInit - found
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.8")
-- Found PNG: /usr/lib64/libpng.so (found version "1.6.25")
-- Looking for include file endian.h
-- Looking for include file endian.h - found
-- Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
-- Configuring incomplete, errors occurred!
See also "/builddir/build/BUILD/minetest-0.4.14/CMakeFiles/CMakeOutput.log".
error: Bad exit status from /var/tmp/rpm-tmp.RnGTCu (%build)
Bad exit status from /var/tmp/rpm-tmp.RnGTCu (%build)

Looks like it needs a bit of fixing from the package-maintainer…
___
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]

Adam Williamson writes:


On Wed, 2016-10-05 at 23:54 -0400, Sam Varshavchik wrote:

> * As a general workaround for this type of crashes, we need a
> >   complete-transaction command in DNF – please add your voices to:
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1091702
> >   – and not the sledgehammer approach of doing all updates offline.
>
> CLOSED/WONTFIX since 2014. No comment.

Except there is a comment. This is what Ales wrote when closing the
bug:

"Closign this as WONTFIX with a vote, i.e. once enough people are CCed
in the bug, we will see about adding this."

IOW, he didn't exactly mean WONTFIX. So, if you want that feature
added...CC yourself.


That's fair enough.

But I'm still waiting for a logical explanation why setsid() plus  
sigaction() for selected signal won't be, at least, an interim fix, insofar  
as preventing a failed install due to an X crashing for some reason, due to  
a bad scriptlet, or something.


The only proposed explanation is that you still won't immediately know if  
the transaction is still running or not; without a clear explanation why  
ps(1) will be insufficient to make that determination. And, of course,  
implicit in that argument is that setsid()+sigaction() *will* be sufficient  
and that's just a different problem to solve. But just because the second  
problem needs a different solution doesn't mean that the first problem  
cannot be solved.





pgp50O4wp7qan.pgp
Description: PGP 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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 05, 2016 at 12:16:32PM -0600, Tim Flink wrote:
> On Tue, 4 Oct 2016 09:19:15 -0400
> Matthew Miller  wrote:
> 
> > 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?
> 
> As far as I know, separate repos shouldn't be very expensive in terms
> of maintenance once everything is in place. If we do decide to
> have separate ACLs for the "rpm" and "check" repos, that will require
> some work to make sure that changes affecting both repos are propagated
> correctly.
> 
> That being said, I'm not sure that having separate ACLs is much of a
> benefit for Fedora.

Yes, I don't see the advantage of so much permission fragmentation.
I'd much prefer that maintainers of individual packages arrange this
between themselves (e.g. "Please only commit to tests"), using social means,
as makes sense for the particular group of people.

Maybe we should standardize the prefix for git commits: "taskotron: "
or "tests: " or whatever, so it's easy to stop in git history.

Zbyszek
___
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 Wed, Oct 5, 2016 at 8:43 PM, Adam Williamson 
wrote:

>
> OK, from now on when I see bugs causing serious real world consequences
> for multiple real world reporters I'll just shut up and pretend it's
> not happening, shall I? Wouldn't want to be all 'alarmist' about it.


Adam... those questions in my last message were rhetorical.  I wasn't
expecting an answer.

You're still missing my point.

I appreciate the fact that you took positive action in regards to the
systemd/scriptlet bug.  The
Issue I had was when you made the blanket statement in regards to running
DNF.  That was the
overreach.  It was then compounded IMHO when you started the with the
implication that the
GNOME model should be expanded into other DEs.  As you yourself mentioned,
you want to help people
with this bug - but you expanded that into a mini-crusade for "offline
updates".

As Kevin pointed out, the best solution would be to give people the actual
workaround.

I would consider the concept of "offline updates" to be a sea change in the
mind of most Linux users.
I can imagine the press release:

"Ten Years in the making:  Fedora develops innovative methodology for safer
system updates:  REBOOT"

Now of course that can be spun many different ways, but honestly you can
guess how that is going to
play out in the twitter-verse.

As I mentioned several times, I do understand the value for "offline"
updates.  I also mentioned
that in the RFE Bug:  A nice goal would be for DNF to be able to
automatically recognize
which updates require a reboot and segregate them off for later processing
while continuing with those
which are safe to do in an online environment.  Many people are going to
have an issue with reboot for
all updates - and as well they should.  It just isn't necessary.  Which is
why I suggested it be added as an option,
at least until the logic to handle it automatically could be developed.

Regarding your comment about sharing history, etc. between DNF and PK, it
is apparently being
addressed:
https://lists.fedoraproject.org/pipermail/devel/2015-October/216136.html

If people feel strongly that not doing offline updates is a huge risk then
they should
escalate and take it up with FESCo.  I suspect the reason that the DNF team
isn't giving it a high priority
is because they don't view it as an urgent issue/risk.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Christian Stadelmann]

In theory, I like this idea. 

In practice,  Kevin Kofler is probably right. Unless there is a big hammer, 
bugs don't get fixed in many cases.

So I think the solution should be different: gfx team needs more manpower so 
they can handle bug reports. Right now, for some packages bugzilla serves as a 
dump of bugs nobody cares about. I doubt you can fix this by process or rules, 
I think fixing it by manpower will be more successful. As far as I can see 
those package maintainers do their job pretty well except for the fact that 
they don't have enough time to do so.
___
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

[Tomasz Kłoczko]

Hi every one,

Reading all ideas about solving issues with upgrading systems from working
systems are more or less ideas of ad choc solving some issues or even more
or less reinventing the wheel. IMO all those ideas will not solve anything
and will only increase total level of entropy. After this will be necessary
sooner or later add even more ad choc workarounds and so on ..

I've mention already that some solutions are close to reinventing the wheel.
Why? Because they've been solved long time ago. To be more precise *more
than decade ago*.

I'm working with rpm (RPM Package Manager) more than two decades (try to
execute "rpm -qa --channgelog | grep kloczek" and you can find one on my
earliest activities still present in any RH based distributions. I've been
maintaining for 3 years PLD which at peak time was withs rpm based
distribution with more than 5k src.rpm packages).
Initially rpm was huge step forward because it's been formalizing many
install/upgrade, uninstall, verifications, building, testing problems under
single hood.
Especially many things related to building packages have been solved very
well. So well that even today only some small improvements time too time
needs to be done.

>From the beginning of the rpm (from time when it was 100% implemented in
perl) compare do SySV packages (used on Solaris and BSD*s) and deb (kind of
only improved new skyfold on top of original SySV packaging tools ideas) up
to now problem of consistent upgrade never been solved completely. Why?
Because man assumption about doing upgrade on working system
image/resources is broken by design idea. As long as during upgrade process
will be deleted some files still used by working processes or will be
reopened by those processes always possibility that those processes will be
not able normally used resources or will be trying to use resources from
wrong version is relatively high.
Whatever could be done on packagemanager are to avoid those icebergs is not
enough and will never solve those two fundamental uncertain scenarios.

So why with existing rpm is not possible to solve upgrade dilemmas is
probably more or less obvious now.
So seems like now is yet another iteration of clashes with rmp limitations
only question is how (and by who?) those problems have been already solved?
Answer is very simple: those problems have been solved almost *decade ago
on Solaris* with introduction two crucial technologies like ZFS (Zeta File
System) and IPS (Image Packaging system). These two bits on maintaining
system resources are interacting very closely and they cannot be used
separately (yes .. atm only).

So how *ALL* upgrade problems have been solved on ideas layer?
Very simple: by assumption that system upgrade will never (ever) will be
done on working system resource.
Someone may scratch his head asking "how it is possible to do upgrade if
system resources are not touched?". Answer is that it is not possible to
implement this idea adding some functionalities to package management (PM)
software. Such operation like upgrade needs to be supported by OS and to be
more precise by *FS layer*.

So how problem of consistent upgrade have been solved on Solaris using ZFS
and IPS?
ZFS has ability to create snapshot of the vol (RO resource) and create on
top of the shapshot clone (RW resource).
Whole upgrade process consist from few steps:
- find volumes which needs to be snapshoted and cloned
- create clones
- mount clones as separated tree and perform upgrad
  This part is crucial. If anything wrong will happen during upgrade still
working system is not affected. It is possible to observe state of broken
upgrade and produce very precise diagnostic data allowing to fix upgrade
process on layer of packages. In other words *impact of *during *upgrade*
on top of still working system *is* *NULL/ZERO!!!*
- when upgrade process is finished grub boot loaded configuration is
updated to add new root point from from which updated system system image
needs to be booted.

As I wrote two technologies here (together) are crucial here to solve 100%
upgrade issues: ZFS and IPS. 3rd minor part is bootloaded. Originally on
Solaris 10 was used grub and grub2 on Solaris 11 only simplified whole
workflow.

So what is missing here on Linux to implement those idea? To be hones ..
not to much which is good :)
Only few small bolts and beans are missing :)

On Linux at the moment is available btrfs which provides possibility of RW
snapshots (equivalent of ZFS clones). All what needs to be added to this
layer is btrfs volume attribute indicating that volume needs to be cloned
during upgrade in case of more complicated scenarios.
Why? Because automatic discovery may be not enough in cases like mayr
database upgrade when part of the u[grade may be some format change which
needs to be applied in format for example database files used by some
application. If in boot loaded will be possible to have to boot entries
allowing to boot from original state from before upgrade 

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

[Matthew Miller]

On Thu, Oct 06, 2016 at 12:44:02PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Maybe we should standardize the prefix for git commits: "taskotron: "
> or "tests: " or whatever, so it's easy to stop in git history.

That'll have to be automated somehow or I don't think people will
remember.


-- 
Matthew Miller

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

Re: A new tool for backward compatibility analysis of API/ABI interfaces in RPM packages

[Ponomarenko Andrey]

06.10.2016, 08:23, "Pierre-Yves Chibon":
> On Wed, Oct 05, 2016 at 06:36:16PM +0300, Ponomarenko Andrey wrote:
>>  The tool is based on different software stack for analysis of backward
>>  compatibility developed since 2009: https://github.com/lvc (ABI Compliance 
>> Checker, ABI Dumper, etc.)
>>
>>  RedHat created an alternative libabigail tool in 2013. Implementation and 
>> reports are completely different. But anyway, two is better than one. Now we 
>> can verify reports of both tools by each other.
>
> I'm confused what Red Hat as to do in there. As far as I know, it's a person 
> not
> a company that runs the development or libabigail and I very much doubt that
> this person was tasked to do that by some higher power.
>
> That being said, did you look at it? Did you make some comparison on how it
> performs compared to this stack you mention?
> Are there times where one finds something that the other don't, vice-versa?
> Can they be ranked or are they too different to be compared?
>
> Thanks,
> Pierre

After a closer look at the source code, reports and docs of abipkgdiff / 
libabigail tools I can list some pros and cons of 
https://github.com/lvc/pkg-abidiff / abi-compliance-checker:

PROS
- separated analysis of both backward binary compatibility and backward source 
compatibility
- assigning severity levels to ABI changes
- explaining effects of ABI changes
- checks for more compatibility rules
- less false positives
- visual reports
- grouping of affected ABI interfaces by root cause (usually a change in the 
structure of data type), so the output report is more compact and easy to review
- estimating total compatibility rate of an object

CONS
- may be slower and consume more RAM memory than libabigail tools due to 
implementation language (C++ vs Python/Perl/C)
- the generation of output report is not configurable (can't pass any 
additional options to abi-compliance-checker via cli interface of pkg-abidiff)
- no option to generate detailed plain-text report (only console output and 
summary report in JSON format are present)

Please describe more CONS if any.

I'll try soon to compare outputs of both tools on a test library that 
implements almost all ABI changes noted in "Policies/Binary Compatibility 
Issues With C++" [1] in order to check out how it works in practice.

Anyway it is very handy to have two different implementations. In the future I 
will verify updates by both abipkgdiff/libabigail and 
pkg-abidiff/abi-compliance-checker tools.

Thank you.

[1] https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
___
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 Thu, 2016-10-06 at 10:18 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
What exactly would you have had me do? Just sit on this and pretend
there was no bug and when we saw more and more people come into #fedora
and complain about it, tell them the risk was minimal so they should
just suck it up and get on with their lives? I mean, seriously, what do
you suggest?



Tell people the actual workaround?

rpm -Uvh --nodeps --nopostun \
  http://$MIRROR/updates/testing/25/x86_64/s/systemd-udev-231-8.fc25.x86_64.rpm

--nopostun will disable the broken scriptlet.
--nodeps will avoid the hard EVR requirement on the rest of systemd.
Then a normal dnf update should fix your deps.

Huh - that's handy, and I did not actually know --nopostun (something
new every day, etc.). It does involve including instructions on how to
find the package, though, which would inevitably go stale as it moves
from u-t to stable. Still, thanks.
-- 
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 Thu, 2016-10-06 at 08:20 -0700, Adam Williamson wrote:
> On Thu, 2016-10-06 at 10:18 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> What exactly would you have had me do? Just sit on this and pretend
> there was no bug and when we saw more and more people come into #fedora
> and complain about it, tell them the risk was minimal so they should
> just suck it up and get on with their lives? I mean, seriously, what do
> you suggest?
> 
> 
> 
> Tell people the actual workaround?
> 
> rpm -Uvh --nodeps --nopostun \
>   
> http://$MIRROR/updates/testing/25/x86_64/s/systemd-udev-231-8.fc25.x86_64.rpm
> 
> --nopostun will disable the broken scriptlet.
> --nodeps will avoid the hard EVR requirement on the rest of systemd.
> Then a normal dnf update should fix your deps.
> 
> Huh - that's handy, and I did not actually know --nopostun (something
> new every day, etc.). It does involve including instructions on how to
> find the package, though, which would inevitably go stale as it moves
> from u-t to stable. Still, thanks.

Sorry for the missed quotes; evolution's composer seems to have found
itself *yet another* failure mode, where it shows me nicely quoted text
but sends something with no quote characters at all...sometimes I
wonder if someone is doing all this because they lost a bet, or
something.
-- 
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: Fedora 25 Beta 1.1 compose check report

[Dennis Gilmore]

On Wednesday, October 5, 2016 11:08:10 PM CDT Fedora compose checker wrote:
> Missing expected images:
> 
> Cloud_base raw-xz i386
> Atomic raw-xz x86_64


These are not expected, they are not things configured to be built in the 
compose.

Dennis

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Base] adopting the Docker base image into Atomic WG

[Dennis Gilmore]

On Wednesday, October 5, 2016 2:41:50 PM CDT Colin Walters wrote:
> Now that Cloud -> Atomic and will be focusing on Project Atomic, can we move
> the Docker base image into this group from the "Fedora Base" group?
> 
> It never really made sense to me in Base; in:
> 
> $ git log --format='%ae' fedora-docker-base.ks | sort -u
> admil...@redhat.com
> den...@ausil.us
> jpazdzi...@redhat.com
> ke...@fedoraproject.org
> kushal...@gmail.com
> mat...@mattdm.org
> maxamill...@fedoraproject.org
> pbrobin...@gmail.com
> vpav...@redhat.com
> walt...@verbum.org
> 
> Most of the recent committers are outside of the Base group.
> 
> And it makes sense to me to have synchronized landing pages/information
> for Atomic Host and the Docker base image.
Base working Group does not exist anymore and has not for awhile. it and the 
docker base image have been taken over by modularity

Dennis

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Adam Williamson]

On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote:
> 
> So I like the idea, I do propose to simply re-use most of
> the blocker bug process for this, rather then inventing yet
> another process. I guess this could even be integrated and
> the way to get bugs on the list would be to propose them
> as blockers as normal and then during the blocker meeting
> when the vote says "no this is not a blocker" a second vote
> is done to see if it is a critical bug.

Let me phrase my earlier objection a little more strongly and
personally:

If someone tries to make me spend another three damn hours a week
reviewing 'proposed critical bugs' I'm going to jump out a window and
go start that yak farm. You won't see me for dust.

: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: Fedora 25 Beta 1.1 compose check report

[Adam Williamson]

On Thu, 2016-10-06 at 10:26 -0500, Dennis Gilmore wrote:
> On Wednesday, October 5, 2016 11:08:10 PM CDT Fedora compose checker wrote:
> > Missing expected images:
> > 
> > Cloud_base raw-xz i386
> > Atomic raw-xz x86_64
> 
> 
> These are not expected, they are not things configured to be built in the 
> compose.

Sorry about that, I didn't get around to updating fedfind's 'expected
image' list (I meant to throw it in with the release I did yesterday to
deal with the Workstation atomic installer metadata mess, but forgot).

Why isn't there a 'regular' Atomic disk image any more, though?
-- 
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: Fedora 25 Beta 1.1 compose check report

[Jan Kurik]

On Thu, Oct 6, 2016 at 5:30 PM, Adam Williamson
 wrote:
> On Thu, 2016-10-06 at 10:26 -0500, Dennis Gilmore wrote:
>> On Wednesday, October 5, 2016 11:08:10 PM CDT Fedora compose checker wrote:
>> > Missing expected images:
>> >
>> > Cloud_base raw-xz i386
>> > Atomic raw-xz x86_64
>>
>>
>> These are not expected, they are not things configured to be built in the
>> compose.
>
> Sorry about that, I didn't get around to updating fedfind's 'expected
> image' list (I meant to throw it in with the release I did yesterday to
> deal with the Workstation atomic installer metadata mess, but forgot).
>
> Why isn't there a 'regular' Atomic disk image any more, though?

Check the email from AdamM:
https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/MIQNF6KNLJ43DHNIOVQAAXEGPFQ6WJNO/

Regards,
Jan

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



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

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

[Chris Murphy]

On Thu, Oct 6, 2016 at 7:43 AM, Tomasz Kłoczko  wrote:


> So how problem of consistent upgrade have been solved on Solaris using ZFS
> and IPS?
> ZFS has ability to create snapshot of the vol (RO resource) and create on
> top of the shapshot clone (RW resource).
> Whole upgrade process consist from few steps:
> - find volumes which needs to be snapshoted and cloned
> - create clones
> - mount clones as separated tree and perform upgrad

This is what OSTree is effectively doing now.

/usr is read only. And updates aren't ever applied to the current file
system tree. A new tree is created and updated, the bootloader
configuration is changed, and the system is rebooted (at the user's
leisure) to get the updated system. i.e. it makes it clear your system
is not running updates until it's rebooted, which it maybe probably
who knows.

rpm-ostree integrates RPM support into OSTree.


>   This part is crucial. If anything wrong will happen during upgrade still
> working system is not affected. It is possible to observe state of broken
> upgrade and produce very precise diagnostic data allowing to fix upgrade
> process on layer of packages. In other words impact of during upgrade on top
> of still working system is NULL/ZERO!!!

Yes, it's the same for rpm-ostree, i.e. the basis for the various
Atomic Host products Fedora creates. And there's going to be a
Workstation version of it for Fedora 25 (for very early adopters, it
won't be at getfedora.org).



> On Linux at the moment is available btrfs which provides possibility of RW
> snapshots (equivalent of ZFS clones). All what needs to be added to this
> layer is btrfs volume attribute indicating that volume needs to be cloned
> during upgrade in case of more complicated scenarios.

It's actually kinda complicated to handle the changes that occur from
the time the current tree is snapshot, the update and reboot happens.
The current root tree can have changes to /var and /etc happening
during the update and before reboot, so those need to get merged such
that you can reboot either the old or new tree and have log and
journal continuity, and so on. rpm-ostree does this.


> Another small bit which needs to be sorted is related to install procedures
> implemented in anaconda and post installation procedures in kernel package.
> What is missing here? anaconda does not allow now to use /boot on btrfs. It
> forces use ext3/4.

It's a grubby bug. It doesn't understand Btrfs subvolumes. Any brave
person who wants to fix grubby? Someone else already tried, so there's
code available to look at to help grok the logic of what needs to be
done; but needs to be implemented in a different way to get approved
by upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=864198


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

Using devtoolset for EPEL builds

[Zuzana Svetlikova]

Hi,

I need/want/would like to build new node 6 for EL6, but gcc is too old. 
For that reason, I'd like to use devtoolset-4-gcc, but the build fails 
(obviously) because the package doesn't exist.

So, is there a way to make that work somehow?
I am not sure about enabling external repos during build, maybe someone 
will be wiser.

Here's the build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=15970697

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

Systemd Security

[Ivan Chavero]

I found this article stating some alarming claims about systemd 
security, are this claims true?

If so, as developers should we be hardening systemd?

It states stuff like this:

" 
Systemd's "we don't make mistakes" attitude towards security can be seen in 
other places, such as this code from the main() function of PID 1:

/* Disable the umask logic */
if (getpid() == 1)
umask(0);

Setting a umask of 0 means that, by default, any file created by systemd 
will be world-readable and -writable. Systemd defines a macro called 
RUN_WITH_UMASK 
which is used to temporarily set a more restrictive umask when systemd needs to 
create 
a file with different permissions. This is backwards. The default umask should 
be restrictive, 
so forgetting to change the umask when creating a file would result in a file 
that obviously
doesn't work. This is called fail-safe design.
"

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

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

Schedule for Friday's FESCo Meeting (2016-10-07)

[Kalev Lember]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-10-07 16:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1568 F25 Self Contained Changes
.fesco 1568
https://fedorahosted.org/fesco/ticket/1568

= New business =

#topic #1631 Unresponsive maintainer: strobert
.fesco 1631
https://fedorahosted.org/fesco/ticket/1631

#topic #1632 Drop package ACLs for user: spike
.fesco 1632
https://fedorahosted.org/fesco/ticket/1632

= Open Floor =

For more complete details, please visit each individual
ticket.  The report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can
reply to this e-mail, file a new ticket at
https://fedorahosted.org/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Systemd Security

[Tomasz Torcz]

On Thu, Oct 06, 2016 at 12:33:30PM -0400, Ivan Chavero wrote:
> 
> I found this article stating some alarming claims about systemd 
> security, are this claims true?
> 

  First of all, do not hijack threads. If you want to start something new,
start it, and do not reply to unrelated thread.

  Secondly, the article you've mentioned already got a response from
systemd developer: 
https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d


-- 
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: Systemd Security

[Lennart Poettering]

On Thu, 06.10.16 12:33, Ivan Chavero (ichav...@redhat.com) wrote:

> Setting a umask of 0 means that, by default, any file created by systemd 
> will be world-readable and -writable. Systemd defines a macro called 
> RUN_WITH_UMASK 
> which is used to temporarily set a more restrictive umask when systemd needs 
> to create 
> a file with different permissions. This is backwards. The default umask 
> should be restrictive, 
> so forgetting to change the umask when creating a file would result in a file 
> that obviously
> doesn't work. This is called fail-safe design.

Well, for starters umask isn't really usable in non-trivial system
service. It's per-process, not per-thread. This means changing it all
the time is problematic, since if you want to do it properly, you'd
have to add locking around it and make sure that any code touching the
umask is nice enough to care and take the lock, too.

This one major reason most daemons actually decide to turn off the
umask entirely, and just make the last argument of open() or mknod()
count as it is. Of course, if your daemon is trivial, and only ever
has one thread, then umask is fine, but the world isn't like that.

Now, PID 1 in systemd itself is pretty much single-threaded in
theory. The thing though is that a number of Linux ioctls are blocking
in nature. This means if you want to integrate them into a proper,
asynchronous event loop you don't really have any other option than to
run them in a thread or subprocess. Hence systemd maintains threads
for that after all. I wish we wouldn't have to... (Many of the VT and
autofs ioctls are blocking, as two examples). But many of the kernel
folks never touched userspace code, and didn't really get the message
yet that blocking kernel API are a bad idea in 2016 -- see the new
getrandom() syscall for example.

Guides such as the original "Linux Daemon Writing" HOWTO also suggest
turning off umask -- google for it. (And so does daemon(7) actually,
as shipped with systemd)

In systemd we generally avoid munging with umask or relying on it for
the above reasons. But then there's also the problem that a number of
library calls and syscalls don't allow passing the file mode for nodes
in the file system that shall be created. Most prominently that is
bind() when used for creating AF_UNIX sockets in the file
system. Since there's no other way to race-freely ensure the right
file modes, in this case we actually *do* mangle the umask, and that's
what RUN_WITH_UMASK is for, but only this.

Or in other words: in a very simple world, yeah, umask is fine. But
the real world is much more complex, and in this real world umask is
just broken when applied to system services. The author of that blog
story doesn't really know what he is talking of. It would have been a
good idea for him to first read up on things before starting to bitch
how stupid the systemd devs are. 

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Many directories without owning packages

[Dridi Boukelmoune]

Hello,

I was surprised to see /usr/share/texlive on my system although I
remembered very well removing it months ago. It turned out to be
caused by two rpmsave files, although some *empty* directories weren't
removed:

$ find /usr/share/texlive/
/usr/share/texlive/
/usr/share/texlive/texmf-dist
/usr/share/texlive/texmf-dist/web2c
/usr/share/texlive/texmf-dist/web2c/fmtutil.cnf.rpmsave
/usr/share/texlive/texmf-dist/web2c/updmap.cfg.rpmsave
/usr/share/texlive/texmf-dist/tex
/usr/share/texlive/texmf-dist/tex/latex
/usr/share/texlive/texmf-dist/tex/latex/misc
/usr/share/texlive/tlpkg
/usr/share/texlive/tlpkg/TeXLive
/usr/share/texlive/tlpkg/tlpostcode
/usr/share/texlive/tlpkg/translations

But then I decided to check my whole /usr tree and found more orphans
than I expected.

My crude data gathering:

$ find /usr/ -type d -exec rpm -qf {} \; |
grep 'not owned' |
tee not_owned.txt

And the results on my current fc24 laptop:

$ wc -l 

Docker/Libvirt networking issue / bug?

[Nathanael D. Noblet]

Hello,

  I have an issue that likely needs a bug or something to fix but I'm
not sure which component is at fault. So I'm writing here in the hopes
that someone will know where to point me.

  I have a F24 Workstation where I've been using libvirt/qemu VMs for
development for awhile now. It works great. I have a bridge0 that
bridges all VMs and my main NIC so that the VMs are accessible on the
network. That works well too.

  Recently I started playing with docker. Both times after running a
few docker containers (with no defined networking / portmapping etc)
just a bash shell in the container. My VMs are no longer able to get IP
addresses from the router. They just time out. It has happened twice
this week and both times it happens sometime after I've done something
with docker. 

  I haven't done any custom configuration with docker so from what I
understood the docker daemon listens on a unix socket, however there is
a docker0 bridge that comes up (and doesn't go away when I stop the
docker service).

  Any VM that was up and running and connected to the network continues
to be. Any VM that I bring up after docker (if it is actually docker's
fault) can no longer get an IP. Stopping the docker service, bringing
down the docker0 bridge in no way fixes the issue. The only way I've
been able to fix it is to reboot the workstation. Once I do that then
the VMs are able to get IPs again.

  Where do I start looking/debugging this?

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

Re: Call for help contacting contributor: spike

[spike]

On 05.10.2016 12:44, Pierre-Yves Chibon wrote:
> It has been a month, more than I expected, so I asked FESCo to consider the 
> user
> spike MIA: https://fedorahosted.org/fesco/ticket/1632

Sorry, must have missed that mail. Just changed my Bugzilla EMail address back 
to what is was. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using devtoolset for EPEL builds

[Dave Johansen]

On Thu, Oct 6, 2016 at 10:32 AM, Zuzana Svetlikova 
wrote:

> Hi,
>
> I need/want/would like to build new node 6 for EL6, but gcc is too old.
> For that reason, I'd like to use devtoolset-4-gcc, but the build fails
> (obviously) because the package doesn't exist.
>
> So, is there a way to make that work somehow?
> I am not sure about enabling external repos during build, maybe someone
> will be wiser.
>

This has already been discussed several times:
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/KSEYFHCLVPK6DZBDOOPMK46AO65V2SM2/
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/7HWJYGXFOMEROUYY2TQKZLKC2MSAAA7R/
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/YQLNZYT5ATELGMHNGET7QCOG3S3UIYT5/

There are some potential roadblocks, but it comes down to someone writing
up an official proposal and going through the full approval process.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Call for help contacting contributor: spike

[Pierre-Yves Chibon]

On Thu, Oct 06, 2016 at 07:20:55PM +0200, spike wrote:
> On 05.10.2016 12:44, Pierre-Yves Chibon wrote:
> > It has been a month, more than I expected, so I asked FESCo to consider the 
> > user
> > spike MIA: https://fedorahosted.org/fesco/ticket/1632
> 
> Sorry, must have missed that mail. Just changed my Bugzilla EMail address 
> back to what is was. 

You may want to check either your email provider settings or you spam folder as
the infrastructure has been trying to reach for more than a month (more likely
around two months).

Many thanks for fixing this though, I'll wait to see if on the infrastructure
side things recover and if so I'll close the FESCo ticket :)

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

Fedora 25-20161006.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Kde live i386
Workstation live i386
Server dvd i386
Server boot x86_64
Server dvd x86_64
Kde live x86_64
Cloud_base raw-xz x86_64
Xfce raw-xz armhfp
Cloud_base raw-xz i386
Server boot i386
Atomic raw-xz x86_64
Minimal raw-xz armhfp
Workstation live x86_64

Failed openQA tests: 5/102 (x86_64), 3/17 (i386)

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

ID: 39321   Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/39321
ID: 39322   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39322
ID: 39420   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/39420
ID: 39421   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/39421

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

ID: 39315   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/39315
ID: 39316   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/39316
ID: 39412   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/39412
ID: 39422   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/39422

Passed openQA tests: 89/102 (x86_64), 14/17 (i386), 2/2 (arm)

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

ID: 39310   Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/39310
ID: 39323   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39323
ID: 39435   Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/39435

Skipped openQA tests: 8 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

Re: Fedora 25 Beta 1.1 compose check report

[Adam Williamson]

On Thu, 2016-10-06 at 17:48 +0200, Jan Kurik wrote:
> On Thu, Oct 6, 2016 at 5:30 PM, Adam Williamson
>  wrote:
> > On Thu, 2016-10-06 at 10:26 -0500, Dennis Gilmore wrote:
> > > On Wednesday, October 5, 2016 11:08:10 PM CDT Fedora compose checker 
> > > wrote:
> > > > Missing expected images:
> > > > 
> > > > Cloud_base raw-xz i386
> > > > Atomic raw-xz x86_64
> > > 
> > > 
> > > 
> > > These are not expected, they are not things configured to be built in the
> > > compose.
> > 
> > 
> > Sorry about that, I didn't get around to updating fedfind's 'expected
> > image' list (I meant to throw it in with the release I did yesterday to
> > deal with the Workstation atomic installer metadata mess, but forgot).
> > 
> > Why isn't there a 'regular' Atomic disk image any more, though?
> 
> 
> Check the email from AdamM:
> https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/MIQNF6KNLJ43DHNIOVQAAXEGPFQ6WJNO/

That does not look relevant (this code only checks if the images
*exist*, it has no idea if they work and doesn't care). And AFAICT,
current composes *do* still have an Atomic disk image:

{
"arch": "x86_64",
"bootable": false,
"checksums": {
"sha256": 
"79e98c18676919782db4ef29d6bf5ce6e79f9dbe91ad95cbe7155682a73b09d0"
},
    "disc_count": 1,
"disc_number": 1,
"format": "raw.xz",
"implant_md5": null,
"mtime": 1475753687,
"path": 
"CloudImages/x86_64/images/Fedora-Atomic-25-20161006.n.0.x86_64.raw.xz",
"size": 374049700,
"subvariant": "Atomic",
"type": "raw-xz",
"volume_id": null
},

that's from today's F25 nightly. But the same image wasn't included in
the Beta compose; I'm not sure why not.
-- 
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

Fedora 25 Beta status is GO, release on Oct 11, 2016

[Jan Kurik]

At the Fedora 25 Beta Go/No-Go Meeting [1][2] that just ended,
has been agreed by QA, Release Engineering and Development
representatives to go live with the Fedora 25 Beta [3].

Fedora 25 Beta will be publicly available on Oct 11, 2016.

Meeting details can be seen here:
[1] Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-10-06/f25-beta-go_no_go-meeting.2016-10-06-17.00.html
[2] Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-10-06/f25-beta-go_no_go-meeting.2016-10-06-17.00.log.html
[3] The F25 Beta compose: http://dl.fedoraproject.org/pub/alt/stage/25_Beta-1.1/

Thanks everyone!
-- 
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

Re: Docker/Libvirt networking issue / bug?

[Neil Horman]

On Thu, Oct 06, 2016 at 11:08:21AM -0600, Nathanael D. Noblet wrote:
> Hello,
> 
>   I have an issue that likely needs a bug or something to fix but I'm
> not sure which component is at fault. So I'm writing here in the hopes
> that someone will know where to point me.
> 
>   I have a F24 Workstation where I've been using libvirt/qemu VMs for
> development for awhile now. It works great. I have a bridge0 that
> bridges all VMs and my main NIC so that the VMs are accessible on the
> network. That works well too.
> 
>   Recently I started playing with docker. Both times after running a
> few docker containers (with no defined networking / portmapping etc)
> just a bash shell in the container. My VMs are no longer able to get IP
> addresses from the router. They just time out. It has happened twice
> this week and both times it happens sometime after I've done something
> with docker. 
> 
>   I haven't done any custom configuration with docker so from what I
> understood the docker daemon listens on a unix socket, however there is
> a docker0 bridge that comes up (and doesn't go away when I stop the
> docker service).
> 
>   Any VM that was up and running and connected to the network continues
> to be. Any VM that I bring up after docker (if it is actually docker's
> fault) can no longer get an IP. Stopping the docker service, bringing
> down the docker0 bridge in no way fixes the issue. The only way I've
> been able to fix it is to reboot the workstation. Once I do that then
> the VMs are able to get IPs again.
> 
>   Where do I start looking/debugging this?
> 
I rarely mess with docker, but I expect that the docker0 bridge has an ip
address on it which may conflict with the one on libvirt bridge.  That is to
say, if they are on the same subnet, and the route for the docker0 bridge takes
precidence, you will loose dhcp.  Check the docker bridge ip and remove it if
you see one, I expect that will restore your functionality

Neil

> Thanks,
> -- 
> Nathanael
> ___
> 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: Docker/Libvirt networking issue / bug?

[Nathanael D. Noblet]

On Thu, 2016-10-06 at 14:28 -0400, Neil Horman wrote:
> I rarely mess with docker, but I expect that the docker0 bridge has
> an ip
> address on it which may conflict with the one on libvirt
> bridge.  That is to
> say, if they are on the same subnet, and the route for the docker0
> bridge takes
> precidence, you will loose dhcp.  Check the docker bridge ip and
> remove it if
> you see one, I expect that will restore your functionality
> 

Unfortunately that isn't the issue as the docker bridge is 172... and
bridge0 is 192.168... so they don't conflict. Also docker0 doesn't seem
to have any devices (meaning it brctl show has no interfaces attached
to it). Finally shutting down docker and removing docker0 doesn't
restore connectivity, only a reboot does. Not even restarting NM fixes
the issue.

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

Fedora Rawhide-20161006.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Kde live i386
Workstation live i386
Server dvd i386
Server boot x86_64
Server dvd x86_64
Kde live x86_64
Cloud_base raw-xz x86_64
Cloud_base raw-xz i386
Server boot i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp
Workstation live x86_64

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

New failures (same test did not fail in Rawhide-20161005.n.0):

ID: 39200   Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/39200

Old failures (same test failed in Rawhide-20161005.n.0):

ID: 39182   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39182
ID: 39183   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39183
ID: 39184   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39184
ID: 39185   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39185
ID: 39186   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39186
ID: 39194   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/39194
ID: 39196   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39196
ID: 39197   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39197
ID: 39198   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/39198
ID: 39199   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39199
ID: 39201   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39201
ID: 39202   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39202
ID: 39210   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/39210
ID: 39212   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/39212
ID: 39213   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/39213
ID: 39215   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39215
ID: 39216   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39216
ID: 39217   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/39217
ID: 39218   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/39218
ID: 39224   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/39224
ID: 39225   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/39225
ID: 39234   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/39234
ID: 39236   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/39236
ID: 39237   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/39237
ID: 39238   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/39238
ID: 39239   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/39239
ID: 39240   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/39240
ID: 39241   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/39241
ID: 39242   Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/39242
ID: 39243   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/39243
ID: 39244   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/39244
ID: 39245   Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/39245
ID: 39246   Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/39246
ID: 39248   Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/39248
ID: 39249   Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/39249
ID: 39250   Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/39250
ID: 39251   Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/39251
ID: 39252   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/39252
ID: 39253   Test: x86_64 universal install_simple_encrypted@u

Re: Docker/Libvirt networking issue / bug?

[Dan Williams]

On Thu, 2016-10-06 at 12:39 -0600, Nathanael D. Noblet wrote:
> On Thu, 2016-10-06 at 14:28 -0400, Neil Horman wrote:
> > 
> > I rarely mess with docker, but I expect that the docker0 bridge has
> > an ip
> > address on it which may conflict with the one on libvirt
> > bridge.  That is to
> > say, if they are on the same subnet, and the route for the docker0
> > bridge takes
> > precidence, you will loose dhcp.  Check the docker bridge ip and
> > remove it if
> > you see one, I expect that will restore your functionality
> > 
> 
> Unfortunately that isn't the issue as the docker bridge is 172... and
> bridge0 is 192.168... so they don't conflict. Also docker0 doesn't
> seem
> to have any devices (meaning it brctl show has no interfaces attached
> to it). Finally shutting down docker and removing docker0 doesn't
> restore connectivity, only a reboot does. Not even restarting NM
> fixes
> the issue.

Try running 'iptables-save' before you start docker, and then running
'iptables-save' after.  Diff the results.  Did docker remove anything?

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

Re: Docker/Libvirt networking issue / bug?

[Neil Horman]

On Thu, Oct 06, 2016 at 02:02:09PM -0500, Dan Williams wrote:
> On Thu, 2016-10-06 at 12:39 -0600, Nathanael D. Noblet wrote:
> > On Thu, 2016-10-06 at 14:28 -0400, Neil Horman wrote:
> > > 
> > > I rarely mess with docker, but I expect that the docker0 bridge has
> > > an ip
> > > address on it which may conflict with the one on libvirt
> > > bridge.  That is to
> > > say, if they are on the same subnet, and the route for the docker0
> > > bridge takes
> > > precidence, you will loose dhcp.  Check the docker bridge ip and
> > > remove it if
> > > you see one, I expect that will restore your functionality
> > > 
> > 
> > Unfortunately that isn't the issue as the docker bridge is 172... and
> > bridge0 is 192.168... so they don't conflict. Also docker0 doesn't
> > seem
> > to have any devices (meaning it brctl show has no interfaces attached
> > to it). Finally shutting down docker and removing docker0 doesn't
> > restore connectivity, only a reboot does. Not even restarting NM
> > fixes
> > the issue.
> 
> Try running 'iptables-save' before you start docker, and then running
> 'iptables-save' after.  Diff the results.  Did docker remove anything?
> 
+1, thats the next thing to look at.  Both docker and libvirt use iptables to
direct traffic in various ways.  They may well be in conflict
Neil

> Dan
> ___
> 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: Fedora 25 Beta Release Readiness Meeting, Thursday, October 6th @ 19:00 UTC

[Jan Kurik]

Hi everyone,

the F25 Beta Readiness meeting has shown readiness of all teams for
the F25 Beta release. There were no major issues reported during the
meeting and all teams stated we are ready to release the F25 Beta as
planned, on October 11th, 2016 at 14:00 UTC. For more details please
check the minutes [1] or log [2] from the meeting.

The Documentation team has reported they will welcome a help
especially with changes in systemd as well as with Wayland as the
default gnome session. So, if you have a time and the knowledge,
please help.

Thanks all for your work on the release.

[1] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-10-06/f25-beta-readiness-meeting.2016-10-06-19.00.html
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-10-06/f25-beta-readiness-meeting.2016-10-06-19.00.log.html

Best Regards,
Jan

On Mon, Oct 3, 2016 at 1:52 PM, Jan Kurik  wrote:
> Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 25
> Beta Release Readiness Meeting meeting.
>
> The meeting is going to be held on Thursday, October 6th, 2016 at
> 19:00 UTC. Please check the [FedoCal] link for your time zone.
>
> We will meet to make sure we are coordinated and ready for the Beta
> release of Fedora 25. Please note that this meeting is going to be
> held even if the release is delayed at the Go/No-Go meeting on the
> same day two hours earlier.
>
> You may received this message several times, but it is by purpose to
> open this meeting to the teams and to raise awareness, so hopefully
> more team representatives will come to this meeting. This meeting
> works best when we have representatives from all of the teams.
>
> [FedoCal] https://apps.fedoraproject.org/calendar/meeting/4782/
>
> More information available at:
> https://fedoraproject.org/wiki/Release_Readiness_Meetings
>
> Thank you for your support and Regards, Jan
>
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic



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

[Lars Seipel]

On Thu, Oct 06, 2016 at 08:20:34AM -0700, Adam Williamson wrote:
> On Thu, 2016-10-06 at 10:18 +0200, Kevin Kofler wrote:
> > rpm -Uvh --nodeps --nopostun \
> >   
> > http://$MIRROR/updates/testing/25/x86_64/s/systemd-udev-231-8.fc25.x86_64.rpm
> 
> Huh - that's handy, and I did not actually know --nopostun (something
> new every day, etc.). It does involve including instructions on how to
> find the package, though, which would inevitably go stale as it moves
> from u-t to stable. Still, thanks.

Use "dnf download" or yumdownloader to fetch the package?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Systemd Security

[Ivan Chavero]

- Original Message -
> From: "Tomasz Torcz" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, October 6, 2016 11:53:23 AM
> Subject: Re: Systemd Security
> 
> On Thu, Oct 06, 2016 at 12:33:30PM -0400, Ivan Chavero wrote:
> > 
> > I found this article stating some alarming claims about systemd
> > security, are this claims true?
> > 
> 
>   First of all, do not hijack threads. If you want to start something new,
> start it, and do not reply to unrelated thread.

I'm not hijacking any thread, I STARTED this thread (BTW, just searched for 
emails 
with the "Systemd Security" subject in this mailing list and didn't find any
immediate matches) because i have an honest concern for Systemd Security and 
general functionality.

I understand that my message can be interpreted as "hate mail" because of 
the constant Systemd controversy but that's not the intention.

BTW, if there's an effort to generate a more positive vibe for Sytemd, you're
not helping...

> 
>   Secondly, the article you've mentioned already got a response from
> systemd developer:
> https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d


Couldn't you just post this link instead of mistakenly ranting about imaginary 
thread
hijacking?

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

Re: Systemd Security

[Tomasz Torcz]

On Thu, Oct 06, 2016 at 04:05:34PM -0400, Ivan Chavero wrote:
> > On Thu, Oct 06, 2016 at 12:33:30PM -0400, Ivan Chavero wrote:
> > > 
> > > I found this article stating some alarming claims about systemd
> > > security, are this claims true?
> > > 
> > 
> >   First of all, do not hijack threads. If you want to start something new,
> > start it, and do not reply to unrelated thread.
> 
> I'm not hijacking any thread, I STARTED this thread (BTW, just searched for 
> emails 
> with the "Systemd Security" subject in this mailing list and didn't find any
> immediate matches) because i have an honest concern for Systemd Security and 
> general functionality.
> 
 
> Couldn't you just post this link instead of mistakenly ranting about 
> imaginary thread
> hijacking?

  Your email header contained:
In-Reply-To: 


  References: 
<20161005230810.d6e916087...@bastion01.phx2.fedoraproject.org> 
<1886682.cmx2irj...@ra.ausil.us> <1475767811.24685.6.ca...@fedoraproject.org>   



Which clearly places it as a reply in thread about Fedora 25 compose status.

QED

-- 
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: Systemd Security

[Adam Williamson]

On Thu, 2016-10-06 at 16:05 -0400, Ivan Chavero wrote:
> I'm not hijacking any thread, I STARTED this thread (BTW, just searched for 
> emails 
> with the "Systemd Security" subject in this mailing list and didn't find any
> immediate matches) because i have an honest concern for Systemd Security and 
> general functionality.

You didn't do it properly. Your message has an 'In-Reply-To' header, so
most mail clients will consider it a part of whatever thread it's
marked as being a 'reply' to.

Just hitting reply then backspacing out the Subject line isn't a good
way to start a new thread, because more than just the subject line
indicates a 'reply', in email. Your client does stuff to the message
headers as well as the subject, when you click 'Reply'.
-- 
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: Systemd Security

[Chris Adams]

Once upon a time, Ivan Chavero  said:
> I'm not hijacking any thread, I STARTED this thread

No, you didn't start a thread.  You posted a reply to an unrelated
message (the subject of that message was "Re: Fedora 25 Beta 1.1 compose
check report").

When you want to start a new thread, do not reply to an existing thread.
Properly threaded mail clients (and list archives) will show your
message as being a part of that existing thread, just with a different
subject.

For example, see the threaded list archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZVTPX74T7KJ7KYK47RS3BQZF4W5ESDMJ/

When you scroll down, you'll find your message buried in an unrelated
thread.  That is commonly called "thread hijacking".
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Beta 1.1 compose check report

[Dennis Gilmore]

On Thursday, October 6, 2016 11:02:38 AM CDT Adam Williamson wrote:
> On Thu, 2016-10-06 at 17:48 +0200, Jan Kurik wrote:
> > On Thu, Oct 6, 2016 at 5:30 PM, Adam Williamson
> > 
> >  wrote:
> > > On Thu, 2016-10-06 at 10:26 -0500, Dennis Gilmore wrote:
> > > > On Wednesday, October 5, 2016 11:08:10 PM CDT Fedora compose checker 
wrote:
> > > > > Missing expected images:
> > > > > 
> > > > > Cloud_base raw-xz i386
> > > > > Atomic raw-xz x86_64
> > > > 
> > > > These are not expected, they are not things configured to be built in
> > > > the
> > > > compose.
> > > 
> > > Sorry about that, I didn't get around to updating fedfind's 'expected
> > > image' list (I meant to throw it in with the release I did yesterday to
> > > deal with the Workstation atomic installer metadata mess, but forgot).
> > > 
> > > Why isn't there a 'regular' Atomic disk image any more, though?
> > 
> > Check the email from AdamM:
> > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.or
> > g/thread/MIQNF6KNLJ43DHNIOVQAAXEGPFQ6WJNO/
> That does not look relevant (this code only checks if the images
> *exist*, it has no idea if they work and doesn't care). And AFAICT,
> current composes *do* still have an Atomic disk image:
> 
> {
> "arch": "x86_64",
> "bootable": false,
> "checksums": {
> "sha256":
> "79e98c18676919782db4ef29d6bf5ce6e79f9dbe91ad95cbe7155682a73b09d0" },
> "disc_count": 1,
> "disc_number": 1,
> "format": "raw.xz",
> "implant_md5": null,
> "mtime": 1475753687,
> "path":
> "CloudImages/x86_64/images/Fedora-Atomic-25-20161006.n.0.x86_64.raw.xz",
> "size": 374049700,
> "subvariant": "Atomic",
> "type": "raw-xz",
> "volume_id": null
> },
> 
> that's from today's F25 nightly. But the same image wasn't included in
> the Beta compose; I'm not sure why not.

For the sake of clarity (It was resolved on IRC) we deliver all artifacts as 
part of teh nightly branched/rawhide composes, the atomic host production 
deliverables are only delivered via the two week atomic host process and not 
as part of the Alpha, Beta, and GA production compose process.

Dennis

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Systemd Security

[Ivan Chavero]

- Original Message -
> From: "Lennart Poettering" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, October 6, 2016 11:58:06 AM
> Subject: Re: Systemd Security
> 
> On Thu, 06.10.16 12:33, Ivan Chavero (ichav...@redhat.com) wrote:
> 
> > Setting a umask of 0 means that, by default, any file created by systemd
> > will be world-readable and -writable. Systemd defines a macro called
> > RUN_WITH_UMASK
> > which is used to temporarily set a more restrictive umask when systemd
> > needs to create
> > a file with different permissions. This is backwards. The default umask
> > should be restrictive,
> > so forgetting to change the umask when creating a file would result in a
> > file that obviously
> > doesn't work. This is called fail-safe design.
> 
> Well, for starters umask isn't really usable in non-trivial system
> service. It's per-process, not per-thread. This means changing it all
> the time is problematic, since if you want to do it properly, you'd
> have to add locking around it and make sure that any code touching the
> umask is nice enough to care and take the lock, too.
> 
> This one major reason most daemons actually decide to turn off the
> umask entirely, and just make the last argument of open() or mknod()
> count as it is. Of course, if your daemon is trivial, and only ever
> has one thread, then umask is fine, but the world isn't like that.
> 
> Now, PID 1 in systemd itself is pretty much single-threaded in
> theory. The thing though is that a number of Linux ioctls are blocking
> in nature. This means if you want to integrate them into a proper,
> asynchronous event loop you don't really have any other option than to
> run them in a thread or subprocess. Hence systemd maintains threads
> for that after all. I wish we wouldn't have to... (Many of the VT and
> autofs ioctls are blocking, as two examples). But many of the kernel
> folks never touched userspace code, and didn't really get the message
> yet that blocking kernel API are a bad idea in 2016 -- see the new
> getrandom() syscall for example.
> 
> Guides such as the original "Linux Daemon Writing" HOWTO also suggest
> turning off umask -- google for it. (And so does daemon(7) actually,
> as shipped with systemd)
> 
> In systemd we generally avoid munging with umask or relying on it for
> the above reasons. But then there's also the problem that a number of
> library calls and syscalls don't allow passing the file mode for nodes
> in the file system that shall be created. Most prominently that is
> bind() when used for creating AF_UNIX sockets in the file
> system. Since there's no other way to race-freely ensure the right
> file modes, in this case we actually *do* mangle the umask, and that's
> what RUN_WITH_UMASK is for, but only this.
> 
> Or in other words: in a very simple world, yeah, umask is fine. But
> the real world is much more complex, and in this real world umask is
> just broken when applied to system services. The author of that blog
> story doesn't really know what he is talking of. It would have been a
> good idea for him to first read up on things before starting to bitch
> how stupid the systemd devs are.
> 


Thanks for the explanation, the article was a little dubious but i needed
to be sure it was just more ranting than facts. 
I'll make sure to pass on your response to people that is believing the 
stuff this guy is saying.

If you guys need extra hands would like to help with systemd 
testing/development.

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

Re: Fedora 25 Beta 1.1 compose check report

[Adam Williamson]

On Thu, 2016-10-06 at 15:11 -0500, Dennis Gilmore wrote:

> For the sake of clarity (It was resolved on IRC) we deliver all artifacts as 
> part of teh nightly branched/rawhide composes, the atomic host production 
> deliverables are only delivered via the two week atomic host process and not 
> as part of the Alpha, Beta, and GA production compose process.

Right, I've amended fedfind to 'expect' Atomic images for nightly
composes and 2-week Atomic composes, but not for 'candidate' and
release composes. Thanks for the info. I've also amended it never to
expect 32-bit cloud images any more. A new release is coming shortly.
-- 
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

[Lars Seipel]

On Wed, Oct 05, 2016 at 03:26:10PM -0700, Japheth Cleaver wrote:
> I don't know what the dnf equivalent is, but isn't that precisely what the
> 'needs-restarting' command provided?

DNF has the tracer plugin for doing exactly that, including printing a
list of commands to restart the affected services, if possible, or
advising a manual restart of specific programs, the login session or the
whole system otherwise, depending on the package set.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Systemd Security

[Ivan Chavero]

- Original Message -
> From: "Tomasz Torcz" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, October 6, 2016 3:11:36 PM
> Subject: Re: Systemd Security
> 
> On Thu, Oct 06, 2016 at 04:05:34PM -0400, Ivan Chavero wrote:
> > > On Thu, Oct 06, 2016 at 12:33:30PM -0400, Ivan Chavero wrote:
> > > > 
> > > > I found this article stating some alarming claims about systemd
> > > > security, are this claims true?
> > > > 
> > > 
> > >   First of all, do not hijack threads. If you want to start something
> > >   new,
> > > start it, and do not reply to unrelated thread.
> > 
> > I'm not hijacking any thread, I STARTED this thread (BTW, just searched for
> > emails
> > with the "Systemd Security" subject in this mailing list and didn't find
> > any
> > immediate matches) because i have an honest concern for Systemd Security
> > and
> > general functionality.
> > 
>  
> > Couldn't you just post this link instead of mistakenly ranting about
> > imaginary thread
> > hijacking?
> 
>   Your email header contained:
> In-Reply-To:
> 
> References:
> <20161005230810.d6e916087...@bastion01.phx2.fedoraproject.org>
> <1886682.cmx2irj...@ra.ausil.us>
> <1475767811.24685.6.ca...@fedoraproject.org>
> 
> 
> Which clearly places it as a reply in thread about Fedora 25 compose status.
> 
> QED

Ok, my bad here. 

I sincerely apologize for the hijack :S

Iván
___
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 Thu, 2016-10-06 at 10:18 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > What exactly would you have had me do? Just sit on this and pretend
> > there was no bug and when we saw more and more people come into #fedora
> > and complain about it, tell them the risk was minimal so they should
> > just suck it up and get on with their lives? I mean, seriously, what do
> > you suggest?
> 
> 
> Tell people the actual workaround?
> 
> rpm -Uvh --nodeps --nopostun \
>   
> http://$MIRROR/updates/testing/25/x86_64/s/systemd-udev-231-8.fc25.x86_64.rpm
> 
> --nopostun will disable the broken scriptlet.
> --nodeps will avoid the hard EVR requirement on the rest of systemd.
> Then a normal dnf update should fix your deps.

Huh - that's handy, and I did not actually know --nopostun (something
new every day, etc.). It does involve including instructions on how to
find the package, though, which would inevitably go stale as it moves
from u-t to stable. Still, thanks.
-- 
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 Toskin]

Adam Williamson wrote:
> Next time maybe I'll just say 'screw this' and go play golf instead, if this 
> is the thanks I get for trying to help people out.

Others have thanked you, actually, but parts of this email chain have gotten a 
little heated, so I guess it's worth repeating: Thanks for starting this 
discussion. I learned something, and I'm not the only one :)
___
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

[Eric Griffith]

Can anyone answer this relatively simple question: "Why grubby?" I've seen a 
number of discussions on various topics surrounding the boot loader that all 
seem to devolve into "We would love to support that, but grubby doesn't, so we 
can't." 

At what point does the maintenance burden of using grubby outweigh its own 
benefits?

I don't ask this rhetorically, or because I particularly want to see grubby 
gone. I just don't see the benefit that we get from having grubby when other 
distros seem to get by just fine without it, or if they do use it, it doesn't 
seem to be getting in their way.

Cheers!
Eric

> On Oct 6, 2016, at 12:12, Chris Murphy  wrote:
> 
> On Thu, Oct 6, 2016 at 7:43 AM, Tomasz Kłoczko  
> wrote:
> 
> 
>> So how problem of consistent upgrade have been solved on Solaris using ZFS
>> and IPS?
>> ZFS has ability to create snapshot of the vol (RO resource) and create on
>> top of the shapshot clone (RW resource).
>> Whole upgrade process consist from few steps:
>> - find volumes which needs to be snapshoted and cloned
>> - create clones
>> - mount clones as separated tree and perform upgrad
> 
> This is what OSTree is effectively doing now.
> 
> /usr is read only. And updates aren't ever applied to the current file
> system tree. A new tree is created and updated, the bootloader
> configuration is changed, and the system is rebooted (at the user's
> leisure) to get the updated system. i.e. it makes it clear your system
> is not running updates until it's rebooted, which it maybe probably
> who knows.
> 
> rpm-ostree integrates RPM support into OSTree.
> 
> 
>>  This part is crucial. If anything wrong will happen during upgrade still
>> working system is not affected. It is possible to observe state of broken
>> upgrade and produce very precise diagnostic data allowing to fix upgrade
>> process on layer of packages. In other words impact of during upgrade on top
>> of still working system is NULL/ZERO!!!
> 
> Yes, it's the same for rpm-ostree, i.e. the basis for the various
> Atomic Host products Fedora creates. And there's going to be a
> Workstation version of it for Fedora 25 (for very early adopters, it
> won't be at getfedora.org).
> 
> 
> 
>> On Linux at the moment is available btrfs which provides possibility of RW
>> snapshots (equivalent of ZFS clones). All what needs to be added to this
>> layer is btrfs volume attribute indicating that volume needs to be cloned
>> during upgrade in case of more complicated scenarios.
> 
> It's actually kinda complicated to handle the changes that occur from
> the time the current tree is snapshot, the update and reboot happens.
> The current root tree can have changes to /var and /etc happening
> during the update and before reboot, so those need to get merged such
> that you can reboot either the old or new tree and have log and
> journal continuity, and so on. rpm-ostree does this.
> 
> 
>> Another small bit which needs to be sorted is related to install procedures
>> implemented in anaconda and post installation procedures in kernel package.
>> What is missing here? anaconda does not allow now to use /boot on btrfs. It
>> forces use ext3/4.
> 
> It's a grubby bug. It doesn't understand Btrfs subvolumes. Any brave
> person who wants to fix grubby? Someone else already tried, so there's
> code available to look at to help grok the logic of what needs to be
> done; but needs to be implemented in a different way to get approved
> by upstream.
> https://bugzilla.redhat.com/show_bug.cgi?id=864198
> 
> 
> -- 
> Chris Murphy
> ___
> 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: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Adam Williamson]

On Thu, 2016-10-06 at 17:05 -0400, Eric Griffith wrote:
> Can anyone answer this relatively simple question: "Why grubby?" I've
> seen a number of discussions on various topics surrounding the boot
> loader that all seem to devolve into "We would love to support that,
> but grubby doesn't, so we can't." 
> 
> At what point does the maintenance burden of using grubby outweigh
> its own benefits?
> 
> I don't ask this rhetorically, or because I particularly want to see
> grubby gone. I just don't see the benefit that we get from having
> grubby when other distros seem to get by just fine without it, or if
> they do use it, it doesn't seem to be getting in their way.

The major reason it exists, AIUI, is that it provides a consistent
interface across different bootloaders (we use bootloaders other than
grub on non-Intel architectures). It's also I think mostly consistent
across grub-legacy and grub2. This is a big thing for big RHEL sites
that want to have consistent bootloader management across disparate
arches and RHEL releases (inc. old ones that still use grub-legacy).

The same situation does exist for Fedora, since we *do* have PPC and
s390 and stuff as secondary arches.
-- 
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

[Kevin Fenzi]

On Thu, 6 Oct 2016 17:05:45 -0400
Eric Griffith  wrote:

> Can anyone answer this relatively simple question: "Why grubby?" I've
> seen a number of discussions on various topics surrounding the boot
> loader that all seem to devolve into "We would love to support that,
> but grubby doesn't, so we can't." 
> 
> At what point does the maintenance burden of using grubby outweigh
> its own benefits?
> 
> I don't ask this rhetorically, or because I particularly want to see
> grubby gone. I just don't see the benefit that we get from having
> grubby when other distros seem to get by just fine without it, or if
> they do use it, it doesn't seem to be getting in their way.

Well, I don't know the full history here, but IMHO, the problem is that
the way grub2 does config is not very ideal. Most applications when you
want to add some new configuration allow you to just do that and leave
everything else you already set the way you wanted it alone. With grub2
it expects to completely regenerate it's config file every time you
want to add a new entry. 

From a practical standpoint this means if you have several entries that
work just fine and add a new one you could end up with none of them
working instead of just the most recent one failing and allowing you to
go back and use one of the previous (working) ones. 

Perhaps other distros have figured out better ways to deal with this, I
don't know. If someone wanted to go and survey this and report back
that information might be of help. 

kevin



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

Re: Fedora 25 Beta status is GO, release on Oct 11, 2016

[Jeremy Newton]

At risk of asking a redundant question, I'm assuming Wayland is still a go?
IIRC the contingency deadline was the beta.

I ask because it does not appear to be a part of the changeset, yet this FEDCo 
ticket seems to suggest otherwise:
https://fedorahosted.org/fesco/ticket/1615
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Andrew Toskin]

We've discussed how and whether it's best practice to disallow a user from 
logging into an account they previously had access to.

But now I'm sorta curious about the opposite situation: What's the use case for 
blocking a user from accessing their account, rather than just deleting the 
account altogether?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /sbin/nologin in /etc/shells

[Andrew Toskin]

Er, let me clarify: Much of the discussion here, as I see it, has been about 
how to preserve a user account, but block user access to that account.

My question is: If it were really important to make sure the user could no 
longer access the system at all, why not just delete the account? Deleting the 
user does not (necessarily) delete their data, so what's the use case for 
keeping the account at all in such a situation?

> We've discussed how and whether it's best practice to disallow a user from 
> logging
> into an account they previously had access to.
> 
> But now I'm sorta curious about the opposite situation: What's the use case 
> for
> blocking a user from accessing their account, rather than just deleting the 
> account
> altogether?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Docker/Libvirt networking issue / bug?

[Catalin]

maybe I'm come with not right answer ,
I think that depend by network configuration over internet and routing process
over applications. so will not be any conflict. I'm right?
> Both docker and libvirt use iptables to direct traffic in various ways.  They 
> may well be in conflict


2016-10-06 22:18 GMT+03:00 Neil Horman :
> On Thu, Oct 06, 2016 at 02:02:09PM -0500, Dan Williams wrote:
>> On Thu, 2016-10-06 at 12:39 -0600, Nathanael D. Noblet wrote:
>> > On Thu, 2016-10-06 at 14:28 -0400, Neil Horman wrote:
>> > >
>> > > I rarely mess with docker, but I expect that the docker0 bridge has
>> > > an ip
>> > > address on it which may conflict with the one on libvirt
>> > > bridge.  That is to
>> > > say, if they are on the same subnet, and the route for the docker0
>> > > bridge takes
>> > > precidence, you will loose dhcp.  Check the docker bridge ip and
>> > > remove it if
>> > > you see one, I expect that will restore your functionality
>> > >
>> >
>> > Unfortunately that isn't the issue as the docker bridge is 172... and
>> > bridge0 is 192.168... so they don't conflict. Also docker0 doesn't
>> > seem
>> > to have any devices (meaning it brctl show has no interfaces attached
>> > to it). Finally shutting down docker and removing docker0 doesn't
>> > restore connectivity, only a reboot does. Not even restarting NM
>> > fixes
>> > the issue.
>>
>> Try running 'iptables-save' before you start docker, and then running
>> 'iptables-save' after.  Diff the results.  Did docker remove anything?
>>
> +1, thats the next thing to look at.  Both docker and libvirt use iptables to
> direct traffic in various ways.  They may well be in conflict
> Neil
>
>> Dan
>> ___
>> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Screenshots with Wayland and Dual Displays

[Jeffrey Ollie]

I just noticed that I can't take a screenshot of anything on the secondary
display when using two displays - you just get a transparent PNG. In fact,
if you try and grab an area that spans the displays it'll capture the
screen from the primary display properly while the area from the secondary
display is transparent. I didn't find anything in Bugzilla that looked
similar but I wasn't sure if it should be filed under Wayland or something
else.

-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Beta status is GO, release on Oct 11, 2016

[Adam Williamson]

On Thu, 2016-10-06 at 21:22 +, Jeremy Newton wrote:
> At risk of asking a redundant question, I'm assuming Wayland is still a go?
> IIRC the contingency deadline was the beta.

Workstation still uses Wayland by default in the Beta, yep.
-- 
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: /sbin/nologin in /etc/shells

[Toby Goodwin]

>My question is: If it were really important to make sure the user could no 
>longer access the system at all, why not just delete the account? Deleting the 
>user does not >(necessarily) delete their data, so what's the use case for 
>keeping the account at all in such a situation?

In my experience, something like nologin is the best choice when you
want to disable a user temporarily. For one example, suppose you run a
shell server for paying customers - what should you do with a customer
who forgets to pay?

If you altogether delete the account, or lock the password, they will
get an authentication failure, giving them no clue as to the problem.
With nologin, you have the opportunity to display a message encouraging
them to make the payment. (Deleting the account outright will also destroy
the password, and may cause further problems, for example their UID
might be reused.)

Using account expiry might be an even better option for this scenario,
but I think nologin predates that mechanism.

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

[Kevin Kofler]

Adam Williamson wrote:
> Huh - that's handy, and I did not actually know --nopostun (something
> new every day, etc.). It does involve including instructions on how to
> find the package, though, which would inevitably go stale as it moves
> from u-t to stable. Still, thanks.

Seeing how this is not the first time a broken %postun script causes 
unfixable trouble with updating a package, I think RPM really needs a way 
for a new version of a package to override the old version's %postun. It 
would be similar to how triggers work, but it should run INSTEAD OF the 
original %postun, not in addition to it. (As I understand it, postun 
triggers unfortunately run in addition to normal %postun.)

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

Re: /sbin/nologin in /etc/shells

[Chris Adams]

Once upon a time, Andrew Toskin  said:
> But now I'm sorta curious about the opposite situation: What's the use case 
> for blocking a user from accessing their account, rather than just deleting 
> the account altogether?

There are lots of reasons.  For example, if someone is paying for an
account, they may be temporarily blocked for non-payment.  A company may
block an account for an employee on extended leave.  An account that is
suspected of compromise or abuse may be blocked.

-- 
Chris Adams 
___
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 Fri, 2016-10-07 at 01:25 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Huh - that's handy, and I did not actually know --nopostun (something
> > new every day, etc.). It does involve including instructions on how to
> > find the package, though, which would inevitably go stale as it moves
> > from u-t to stable. Still, thanks.
> 
> 
> Seeing how this is not the first time a broken %postun script causes 
> unfixable trouble with updating a package, I think RPM really needs a way 
> for a new version of a package to override the old version's %postun. It 
> would be similar to how triggers work, but it should run INSTEAD OF the 
> original %postun, not in addition to it. (As I understand it, postun 
> triggers unfortunately run in addition to normal %postun.)

Yeah, that would be handy for sure. We're kicking around ways to use a
%pre to subvert the effect of the %postun in the bug report right now,
but having a dedicated mechanism would be handy.
-- 
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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 05, 2016 at 01:57:20PM -, Peter Larsen wrote:
> > I never needed to reboot.  I just keep working on my stuff, when I'm 
> > done I turn the laptop off.  Is there any reason to reboot right after 
> > updating?
> 
> That's actually a very common misunderstanding. People think that "yum/dnf 
> update" leaves their system in a new updated stage. But it doesn't 
> (completely). It never has. Only after a reboot are all your patches applied 
> and active. Existing/running processes are rarely if ever reloaded. So when 
> you update libraries, kernels etc. your system will keep running with the old 
> versions of those libraries loaded.  Remember, in Linux a inode is never 
> deleted until the very last process has released it. So any read file handles 
> will keep a file, even one you cannot see with ls, available.
> 
> The only real complete update you can do is one that does a full reboot. We 
> do have a few tricks with DNF which will attempt to let you know what needs 
> restarting. But you'll find that a good part of our updates requires a 
> restart of most if not all your system, in order for the updates to become 
> fully active.

What you write is mostly true, at least for "user" programs.
Various system services actually get restarted, e.g. all those that
are running as systemd units and are have %systemd_postun_with_restart in %post.
For servers that should be a majority of daemons (but not all, dbus-daemon
being a notable exception). Systemd also supports seamless restart of 
socket-activated
services, so it's even possible to restart daemons that are in live use without
anybody noticing.

For users programs we have nothing like that unfortunately.

But yeah, I'm nitpicking here, the general rule is what you say: one
has to restart the machine to make sure everything has bee restarted.

Zbyszek

> This problem often shows itself on long running servers by a system not 
> coming back up/online after a reboot. And nobody understand why - but it's 
> pretty simple. Nobody tested that things worked after an update, and in most 
> cases that requires a reboot. If you kernel, glibc or network control system 
> gets updated, you'll need to reboot to reload them. Or of course take your 
> network offline with everything running on your box (good luck!).
> 
> So it may look like that "it works just fine" but it's a deception. It's 
> still running the older versions of libraries etc for most processes. If you 
> start looking at what's actually running after your update, you'll find that 
> a good part of your updated packages aren't running (yet) - and old versions 
> are still active.  If you're attempting to apply security updates, this is an 
> important distinction and vital to be compliant. For us ordinary users, it's 
> mostly an annoyance as features we wanted, aren't there right after an 
> update, or programs starts failing after an update, as they attempt to 
> dynamicly load in modules and find them "changed", at times not even 
> compatible with the running older version, and things end up "strange". I've 
> seen fonts go nuts, backgrounds disappear, general themes not working etc. 
> after an update on a workstation, simply because the structure got changed - 
> CSSes looking for files that no longer are there, etc. 
___
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 Thu, Oct 6, 2016 at 3:17 PM, Kevin Fenzi  wrote:
> On Thu, 6 Oct 2016 17:05:45 -0400
> Eric Griffith  wrote:
>
>> Can anyone answer this relatively simple question: "Why grubby?" I've
>> seen a number of discussions on various topics surrounding the boot
>> loader that all seem to devolve into "We would love to support that,
>> but grubby doesn't, so we can't."
>>
>> At what point does the maintenance burden of using grubby outweigh
>> its own benefits?
>>
>> I don't ask this rhetorically, or because I particularly want to see
>> grubby gone. I just don't see the benefit that we get from having
>> grubby when other distros seem to get by just fine without it, or if
>> they do use it, it doesn't seem to be getting in their way.
>
> Well, I don't know the full history here, but IMHO, the problem is that
> the way grub2 does config is not very ideal.

It's not. And OS discovery is fraught with problems also.

One alternative is Bootloader Spec drop-in scripts. Fedora's GRUB
carries a patch to support them in the blscfg.mod, but it implements
it in an early interpretation of the spec. rpm-ostree creates drop in
scripts per this spec, but instead of depending on blscfg.mod to use
them directly, rpm-ostree calls a helper to use the scripts as source
material to generate new grub.cfg or extlinux.conf (both bootloaders
are supported). rpm-ostree doesn't use grubby at all.



> Perhaps other distros have figured out better ways to deal with this, I
> don't know. If someone wanted to go and survey this and report back
> that information might be of help.

I don't have a complete or recent evaluation but as of a couple years
ago, before Gene Czarcinski passed away, we found no other
distribution using grubby. Distros we ran into use grub-mkconfig as
recommended by upstream to obliterate the existing grub.cfg and create
an entirely new one.


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

Re: Screenshots with Wayland and Dual Displays

[Chris Murphy]

On Thu, Oct 6, 2016 at 3:59 PM, Jeffrey Ollie  wrote:
> I just noticed that I can't take a screenshot of anything on the secondary
> display when using two displays - you just get a transparent PNG. In fact,
> if you try and grab an area that spans the displays it'll capture the screen
> from the primary display properly while the area from the secondary display
> is transparent. I didn't find anything in Bugzilla that looked similar but I
> wasn't sure if it should be filed under Wayland or something else.

File it against the thing that's taking the screenshot.

What command are you using? I'm using Wayland and taking screenshots
and don't have that problem with gnome-screenshot; but I have
something similar with Shutter.

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



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

[Eric Griffith]

I'm just thinking out loud here, but, given that rpm-ostree does not use 
grubby, and we do have the Bootloader Spec, and no other distro uses grubby, 
would it be prudent to take a really hard look at whether grubby is still a 
path we want to walk? 

If it is, then more work obviously needs to be put into it to get it where we 
want/need it. Personally, I would love to see btrfs subvolume support, so that 
we could have snapshotting like on Suse, though it appears rpm-ostree would 
negate the need for it, correct?

If it's not a path we want to walk anymore, then let's announce an "Intention 
To Deprecate" to give all interested parties (RHEL) plenty of warning, and 
start figuring out what all will break by the removal of grubby. 

Adam, the only other distro that has serious alternate architecture support, 
AFAIK, is Debian. How do they handle grub2 + non-x86? Likewise, the alternate 
architectures that we support, how do we handle their bootloaders? Are they 
grub-based? Ext/Syslinux based? Grub-legacy? 

I agree with Kevin that grub2 is nonintuitive. But the only other serious 
option we have is bootctl, and I am not sure if that's even a possibility for a 
distro like Fedora. I know Arch has it as an install time option, but I don't 
know it's limitations. 

Cheers!
Eric

> On Oct 6, 2016, at 21:20, Chris Murphy  wrote:
> 
>> On Thu, Oct 6, 2016 at 3:17 PM, Kevin Fenzi  wrote:
>> On Thu, 6 Oct 2016 17:05:45 -0400
>> Eric Griffith  wrote:
>> 
>>> Can anyone answer this relatively simple question: "Why grubby?" I've
>>> seen a number of discussions on various topics surrounding the boot
>>> loader that all seem to devolve into "We would love to support that,
>>> but grubby doesn't, so we can't."
>>> 
>>> At what point does the maintenance burden of using grubby outweigh
>>> its own benefits?
>>> 
>>> I don't ask this rhetorically, or because I particularly want to see
>>> grubby gone. I just don't see the benefit that we get from having
>>> grubby when other distros seem to get by just fine without it, or if
>>> they do use it, it doesn't seem to be getting in their way.
>> 
>> Well, I don't know the full history here, but IMHO, the problem is that
>> the way grub2 does config is not very ideal.
> 
> It's not. And OS discovery is fraught with problems also.
> 
> One alternative is Bootloader Spec drop-in scripts. Fedora's GRUB
> carries a patch to support them in the blscfg.mod, but it implements
> it in an early interpretation of the spec. rpm-ostree creates drop in
> scripts per this spec, but instead of depending on blscfg.mod to use
> them directly, rpm-ostree calls a helper to use the scripts as source
> material to generate new grub.cfg or extlinux.conf (both bootloaders
> are supported). rpm-ostree doesn't use grubby at all.
> 
> 
> 
>> Perhaps other distros have figured out better ways to deal with this, I
>> don't know. If someone wanted to go and survey this and report back
>> that information might be of help.
> 
> I don't have a complete or recent evaluation but as of a couple years
> ago, before Gene Czarcinski passed away, we found no other
> distribution using grubby. Distros we ran into use grub-mkconfig as
> recommended by upstream to obliterate the existing grub.cfg and create
> an entirely new one.
> 
> 
> -- 
> Chris Murphy
> ___
> 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: Call for help contacting contributor: spike

[Pierre-Yves Chibon]

On Thu, Oct 06, 2016 at 07:20:55PM +0200, spike wrote:
> On 05.10.2016 12:44, Pierre-Yves Chibon wrote:
> > It has been a month, more than I expected, so I asked FESCo to consider the 
> > user
> > spike MIA: https://fedorahosted.org/fesco/ticket/1632
> 
> Sorry, must have missed that mail. Just changed my Bugzilla EMail address 
> back to what is was. 

It looks like the emails are still not matching.
Your FAS email is the one used here `spikefedora - gmail`, while as far as I can
see [1], your bugzilla email is your @fedoraproject.org alias.
Both addresses need to match.

Could you look into it?


Thanks,
Pierre


[1] using this ticket, assigned to you 
https://bugzilla.redhat.com/show_bug.cgi?id=1340441
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org