Did something change with ssh-agent in F24?

[Christopher]

Previously in F23, an ssh-agent was running when I started a gnome session.
I believe (perhaps incorrectly) that this was being provided by
gnome-keyring-daemon.

Now, it appears that one isn't running. When I type "ssh-add -L", I get the
message: "Could not open a connection to your authentication agent."

Is this an expected change in behavior with F24, or is it a bug which I
should file?
(Note, there are a few bugs for F23 open about ssh-agent and gnome-keyring,
but they appear to be unrelated, and I had no problems in F23).

If it is a bug, what can I do to troubleshoot for when I file a bugzilla?

An interim solution is to launch ssh-agent, but it's somewhat less
convenient.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: releng's mlt-6.2.0-3.fc25 failed to build

[Kevin Fenzi]

On Tue, 19 Jul 2016 18:40:11 +0100
Sérgio Basto  wrote:

> That is it , I got 2 releng's notifications that failed to build ,
> though that I will receive much more ... , so I decide to warning
> you. 
> 
> Let us know when we should resubmit the packages ... or if you will
> resubmit ? 

I don't think releng is going to resubmit. 

Look for https://fedorahosted.org/rel-eng/ticket/6432 to be closed and
then you can fire off a new build. 

kevin


pgpp55bJjsUEd.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Elections July 2016 - Voting now open

[Justin W. Flory]

The Campaign period of Elections for the Fedora Council and Fedora 
Engineering Steering Committee (FESCo) are now over. As of this morning, 
voting is now open.



== Candidate Interviews ==

There is one seat open on the Fedora Council (contested by two 
candidates) and four seats open on FESCo (contested by five candidates). 
Most candidates have published their platforms and answered questions 
from the official Questionnaire form on the Community Blog.


For your convenience, you can read this post, which lists all of the 
candidates and links to their interview (if applicable).



https://communityblog.fedoraproject.org/2016-july-elections-interviews/

Please take a moment to review the post as you prepare to vote.


== Eligibility ==

Both the Fedora Council and FESCo have different eligibility requirements.

* Fedora Council: Requires Fedora account (FAS), signed the CLA agreement
* FESCo: Requires Fedora account, signed the CLA agreement, member of 
one other "non-CLA" group in FAS


Voting takes place in the Elections application:

 https://admin.fedoraproject.org/voting/


== Voting ends: 2016 July 25, 23:59 UTC ==

Voting ends promptly on Monday, July 25, 2016, at 23:59 UTC. Voting will 
then close and candidates will be announced thereafter.


For more information about the voting process, you can review the wiki 
page for Fedora Elections.


 https://fedoraproject.org/wiki/Elections



Best of luck to all candidates running! For all voters, make sure you do 
get your vote in and participate in helping elect members of Fedora's 
leadership bodies.


--
Cheers,
Justin W. Flory
jflo...@fedoraproject.org





signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Steve Bonneville]

Oron Peled wrote:
> On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote:
> > ...
> > I remember when this came up before but can't find it now. I think it
> > was changed to 99 when UIDs went to 32 bit and it suddenly started
> > being 65535 on some systems and 4294967295 on others. * I was trying to
> > figure out why 99 was eventually chosen, but can't find it now.
> 
> I believe the uid 99 come from trying not to overlap regular users.
> Back then (end of 90's), regular users uid's were:
>  * On old RedHat Linux >= 500
>  * On some other Linux systems >= 1000
>  * On many legacy Unices >= 100 (except on Irix >= 1000)
> 
> It was very common to have NFS mounted /home across all servers (with 
> different *NIX vendors/versions).
> So '99' was the "last" uid that was assured not to collide with uid's of 
> regular users on NFS.

Solaris and IRIX used to have 60001 as nobody, *and* either -2 or 65534
as nobody, either under the same name (!!!) or some alternative similar
to nfsnobody.  

I don't think you want to assume that code thinks the two users are 
really identical in practice or that it's safe to merge them, though. 

  -- Steve

-- 
Steven Bonneville 
Technical Curriculum Architect  
Red Hat | Red Hat Training   Phone: +1-612-638-0507
gpg: 1024D/221D06FF  68B1 3E66 A351 6485 B9AF  24D8 3DF5 B50B 221D 06FF
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: notion of base or minimal image

[Oron Peled]

On יום שלישי, 19 ביולי 2016 9:20:41 IDT Colin Walters wrote:
> On Tue, Jul 19, 2016, at 07:32 AM, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  Is there some notion or definition of a Fedora minimal or base image?
> 
> A lot depends on whether "image" is a container or OS, which mostly
> boils down to "contains a kernel".

That's a good start, but I think it could be (usefully) refined.

Here is an example taxonomy:
   |
   +- Minimal Container (enough for chroot or entering into shell in container)
  |
  +- Minimal Build Container (Minimal Container + )
  |
  +- Minimal Bootable Container (Minimal Container + systemd)
 |
 +- Minimal OS VM (Minimal Bootable Container + kernel + boot-loader)
|
+- Minimal OS Metal (Minimal OS VM + udev + 
)

Sounds reasonable?
 * Should we assign '@' for each of these combinations?
 * What about ? (x86*, arm*)
 * What about some  package (similar to Debian)
   so there's a centralized definition for all implicit build
   dependencies (gcc, make, etc.) which should not be specified in 
"Build-Requires".
 * Other categories? Something that breaks this taxonomy?

Thanks,

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron

The most exciting phrase to hear in science, the one that heralds new
 discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
 -- Isaac Asimov
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: KillUserProcesses=yes by default

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jul 17, 2016 at 12:17:49AM +0200, Björn Persson wrote:
> Nico Kadel-Garcia wrote:
> > On Fri, Jul 15, 2016 at 12:34 PM, Lennart Poettering
> >  wrote:
> > > We can meet in the middle and make this LOG_NOTICE. That's not the
> > > usual LOG_INFO, but also not the higher LOG_WARNING.
> > 
> > Just to verify: I assume you mean that the killing of these processes
> > would normally emit a "LOG_NOTICE". message.
> 
> Do I understand correctly that KillUserProcesses is meant to be a safety
> net to catch processes that should have terminated when the user logged
> out, but failed to do so?
Yes, we usually expect user processes to exit on their own. But
it's quite likely that this kind of mistake will happen quite
often. Also, some users might simply take advantage of the fact that
this safety net is present and leave processes around. Either way,
it's not very clearly cut, and logging at error level would probably
be quite annoying.

But adjusting the log level is a very simple change, so we can start
at notice level (which by default will end up in logs, but will not be
too obnoxious), and adjust up (if in the common case we get no output)
or down (if in the common case we get too many logs).

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Oron Peled]

On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote:
> ...
> I remember when this came up before but can't find it now. I think it
> was changed to 99 when UIDs went to 32 bit and it suddenly started
> being 65535 on some systems and 4294967295 on others. * I was trying to
> figure out why 99 was eventually chosen, but can't find it now.

I believe the uid 99 come from trying not to overlap regular users.
Back then (end of 90's), regular users uid's were:
 * On old RedHat Linux >= 500
 * On some other Linux systems >= 1000
 * On many legacy Unices >= 100 (except on Irix >= 1000)

It was very common to have NFS mounted /home across all servers (with different 
*NIX vendors/versions).
So '99' was the "last" uid that was assured not to collide with uid's of 
regular users on NFS.

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron

No, You Can't Have My Rights, I'm Still Using Them
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi takes days to get something pushed to testing

[Kevin Fenzi]

On Tue, 19 Jul 2016 12:58:06 -0700
"Gerald B. Cox"  wrote:

> I guess that begs the question of what is happening that can't be
> automated.  Seems that if the build
> is successful and the packager then pushes to the testing repository,
> that should be something that
> could be automated.

Currently package signing is not fully automated. It takes an
authorized human who has been granted access and their passphrase(s) to
sign things. 

There is some work ongoing to setup an autosigner process, but we want
to make sure it's setup correctly and in such a way thats it's not
insecure or easy to subvert. 

kevin


pgpw0G3osVOeU.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi takes days to get something pushed to testing

[Gerald B. Cox]

On Tue, Jul 19, 2016 at 12:15 PM, Dennis Gilmore  wrote:

> I never push updates on weekends. the person pushing may or may not push
> them
> on weekends I would say updates pushes on weekends are not expected and
> are a
> bonus if they do happen.
>

I guess that begs the question of what is happening that can't be
automated.  Seems that if the build
is successful and the packager then pushes to the testing repository, that
should be something that
could be automated.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Matthew Miller]

On Mon, Jul 18, 2016 at 10:18:49AM -0400, Stephen John Smoogen wrote:
> > I'd like to start a discussion regarding the "nobody" user on Fedora,
> > and propose that we change its definition sooner or later. I am not
> > proposing a feature according to the feature process for this yet, but
> > my hope is that these discussions will lead to one eventually.
> I am not against this proposal. It has been tried at least once before
> in the past but those failed due to a lot of programs secretly relying
> on the seperate uids and not a lot of people being able to fix it.
> 
> I am not 100% certain that it was mostly 99 due to issues with various
> network authentication systems from long ago. (ypbind/ldap/etc) where

I remember when this came up before but can't find it now. I think it
was changed to 99 when UIDs went to 32 bit and it suddenly started
being 65535 on some systems and 4294967295 on others. * I was trying to
figure out why 99 was eventually chosen, but can't find it now.

In any case, the regularization makes sense to me.









* At $formeruniversity, we had someone who was trying to back up
/var/log without any special handling for sparse files and they
suddenly got very surprised and upset when lastlog became "gigantic".
Ah, good times.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi takes days to get something pushed to testing

[Dennis Gilmore]

On Monday, July 18, 2016 4:47:40 PM CDT Kevin Fenzi wrote:
> On Mon, 18 Jul 2016 15:05:56 -0700
> 
> "Gerald B. Cox"  wrote:
> > On Mon, Jul 18, 2016 at 2:57 PM, Kevin Fenzi  wrote:
> > > I could tell you more about your specific updates if you list
> > > them...
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2016-db2fbe6854
> > https://bodhi.fedoraproject.org/updates/FEDORA-2016-579b837594
> > 
> > Thanks for the info I was wanting to make sure it wasn't
> > something I was doing wrong which
> > was holding things up...
> 
> Nope, nothing on your side. Looks like there was a push late saturday
> and your updates just missed that, and there wasn't one sunday for some
> reason so they went out in the one I started this morning.
> 
> It was a little less than 2 days there, not 3 or more though.
> 
> kevin

I never push updates on weekends. the person pushing may or may not push them 
on weekends I would say updates pushes on weekends are not expected and are a 
bonus if they do happen.

Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: notion of base or minimal image

[Dennis Gilmore]

On Tuesday, July 19, 2016 9:20:41 AM CDT Colin Walters wrote:
> On Tue, Jul 19, 2016, at 07:32 AM, Nikos Mavrogiannopoulos wrote:
> > Hi,
> >  Is there some notion or definition of a Fedora minimal or base image?
> 
> A lot depends on whether "image" is a container or OS, which mostly
> boils down to "contains a kernel".
> 
> For containers I would look at:
> 
> `docker run --rm -ti fedora:23 bash`
> as well as the rootfs produced by:
> yum install @buildsys-build

this is not a very useful case as it pulls in rpm-build, gcc, gcc-c++ and a 
bunch of tolols that are needed in teh minimal build environment but not the 
minimal runtime environmnet a better group to use would be core  so 
yum install @core however it is more than is in the docker base images.  you 
could look at the kickstarts https://pagure.io/fedora-kickstarts/  there is a 
minimal arm image thats fairly small and minimal, would not be hard to make a 
x86 version of it.

Dennis

> For OS images:
>  - The Anaconda ISO
>  - Atomic Host
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: releng's mlt-6.2.0-3.fc25 failed to build

[Sérgio Basto]

On Ter, 2016-07-19 at 11:12 -0600, Kevin Fenzi wrote:
> On Tue, 19 Jul 2016 11:05:38 -0600
> Kevin Fenzi  wrote:
> 
> > 
> > On Tue, 19 Jul 2016 16:10:06 +0100
> > Sérgio Basto  wrote:
> > 
> > > 
> > > DEBUG util.py:417:  Error: nothing provides
> > > libpoppler.so.60()(64bit) needed by gdal-libs-2.1.0-6.fc25.x86_64
> > > DEBUG util.py:417:  (try to add '--allowerasing' to command line
> > > to
> > > replace conflicting packages)
> > > DEBUG util.py:542:  Child return code was: 1  
> > Yes? Can you elaborate on what you are wanting or trying to say
> > here?
> > 
> > Whats the question?



> > mlt was rebuilt as part of
> > https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Pytho
> > n_RPM_Packages
> > but it failed due to gdal being broken by a recent poppler update. 

> > It looks like gdal is fixed now, so you could just resubmit this
> > build.
> Actually no, it's only been rebuilt/fixed in the f25-python side-
> tag. 
> Wait until thats pulled into the main rawhide (later today) before
> resubmitting. 

That is it , I got 2 releng's notifications that failed to build ,
though that I will receive much more ... , so I decide to warning you. 

Let us know when we should resubmit the packages ... or if you will
resubmit ? 

Thanks.

> kevin
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Test-Announce] Fedora 22 End Of Life

[Mohan Boddu]

As of the 19th of July 2016, Fedora 22 has reached its end of life for
updates and support. No further updates, including security updates,
will be available for Fedora 22. A previous reminder was sent on 22nd
of June [0]. Fedora 23 will continue to receive updates until
approximately one month after the release of Fedora 25. The
maintenance schedule of Fedora releases is documented on the Fedora
Project wiki [1]. The Fedora Project wiki also contains instructions
[2] on how to upgrade from a previous release of Fedora to a version
receiving updates.

Mohan Boddu.

[0] 
https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/4FBGGXFXRMU5GHT6OSSNOYVPMONZDWSD/
[1] 
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2] https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora 22 End Of Life

[Mohan Boddu]

As of the 19th of July 2016, Fedora 22 has reached its end of life for
updates and support. No further updates, including security updates,
will be available for Fedora 22. A previous reminder was sent on 22nd
of June [0]. Fedora 23 will continue to receive updates until
approximately one month after the release of Fedora 25. The
maintenance schedule of Fedora releases is documented on the Fedora
Project wiki [1]. The Fedora Project wiki also contains instructions
[2] on how to upgrade from a previous release of Fedora to a version
receiving updates.

Mohan Boddu.

[0] 
https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/4FBGGXFXRMU5GHT6OSSNOYVPMONZDWSD/
[1] 
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2] https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: releng's mlt-6.2.0-3.fc25 failed to build

[Kevin Fenzi]

On Tue, 19 Jul 2016 11:05:38 -0600
Kevin Fenzi  wrote:

> On Tue, 19 Jul 2016 16:10:06 +0100
> Sérgio Basto  wrote:
> 
> > DEBUG util.py:417:  Error: nothing provides
> > libpoppler.so.60()(64bit) needed by gdal-libs-2.1.0-6.fc25.x86_64
> > DEBUG util.py:417:  (try to add '--allowerasing' to command line to
> > replace conflicting packages)
> > DEBUG util.py:542:  Child return code was: 1  
> 
> Yes? Can you elaborate on what you are wanting or trying to say here?
> 
> Whats the question?
> 
> mlt was rebuilt as part of
> https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages
> but it failed due to gdal being broken by a recent poppler update. 
> 
> It looks like gdal is fixed now, so you could just resubmit this
> build.

Actually no, it's only been rebuilt/fixed in the f25-python side-tag. 
Wait until thats pulled into the main rawhide (later today) before
resubmitting. 

kevin



pgpF8ct9pSDqZ.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: releng's mlt-6.2.0-3.fc25 failed to build

[Kevin Fenzi]

On Tue, 19 Jul 2016 16:10:06 +0100
Sérgio Basto  wrote:

> DEBUG util.py:417:  Error: nothing provides libpoppler.so.60()(64bit)
> needed by gdal-libs-2.1.0-6.fc25.x86_64
> DEBUG util.py:417:  (try to add '--allowerasing' to command line to
> replace conflicting packages)
> DEBUG util.py:542:  Child return code was: 1

Yes? Can you elaborate on what you are wanting or trying to say here?

Whats the question?

mlt was rebuilt as part of
https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages
but it failed due to gdal being broken by a recent poppler update. 

It looks like gdal is fixed now, so you could just resubmit this build.

kevin
--
> 
> 
> On Ter, 2016-07-19 at 13:20 +, notificati...@fedoraproject.org
> wrote:
> > Package:mlt-6.2.0-3.fc25
> > Status: failed
> > Built by:   releng
> > ID: 781765
> > Started:Tue, 19 Jul 2016 08:45:59 UTC
> > Finished:   Tue, 19 Jul 2016 09:09:36 UTC
> > 
> > Closed tasks:
> > -
> > Task 14940864 on buildppc-02.phx2.fedoraproject.org
> > Task Type: build (noarch)
> > Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14940864
> > 
> > error building package (arch x86_64), mock exited with status 30;
> > see root.log for more information
> > 
> > Task 14941380 on arm04-builder06.arm.fedoraproject.org
> > Task Type: buildSRPMFromSCM (noarch)
> > Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941380
> > logs:
> >   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/root.lo
> > g
> >   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/state.l
> > og
> >   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/build.l
> > og
> > srpm:
> >   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/mlt-6.2
> > .0-3.fc25.src.rpm
> > 
> > Task 14941915 on buildvm-24.phx2.fedoraproject.org
> > Task Type: buildArch (x86_64)
> > Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941915
> > 
> > error building package (arch x86_64), mock exited with status 30;
> > see root.log for more information
> > 
> > Task 14941914 on arm02-builder10.arm.fedoraproject.org
> > Task Type: buildArch (armhfp)
> > Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941914
> > 
> > Task 14941914 is canceled
> > 
> > Task 14941916 on buildhw-03.phx2.fedoraproject.org
> > Task Type: buildArch (i386)
> > Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941916
> > 
> > Task 14941916 is canceled
> > 
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=781765
> > 
> > --
> > You received this message due to your preference settings at
> > https://apps.fedoraproject.org/notifications/sergiomb.id.fedoraprojec
> > t.org/email/30349  



pgptV2n0swkOp.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi takes days to get something pushed to testing

[Kevin Fenzi]

On Tue, 19 Jul 2016 11:30:30 +0200
Thomas Moschny  wrote:

> 2016-07-18 23:57 GMT+02:00 Kevin Fenzi :
> > I could tell you more about your specific updates if you list
> > them...  
> 
> This one took a bit more than 6 days from submission to testing:
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-e5b5fbfa86

Yep. This is one of the other cases where something happened. :) 

So, when we first started doing atomic updates in bodhi composes we ran
into some problems with f22-updates-testing. Some were server (selinux,
etc), some were bodhi, some were rpm-ostree. In debugging and trying to
fix that we added a side repo with a newer rpm-ostree. This allowed us
to interate quickly without having to officially build and submit
rpm-ostree updates. We got everything composing and moved on. 

Last week however we were adding the f24-updates and
f24-updates-testing atomic updates and when doing so noticed we still
had the old side repo enabled for f22-updates-testing. This was
removed/disabled. However, things broke again there (only in
f22-updates-testing, which your update above was in). Making things
more difficult, many releng folks were on vacation that week (I was).

Finally we got it fixed up by unpushing a rpm-ostree update that was
sitting in f22-updates-testing for a year, re-enabling the side repo
and doing a compose, then disabling it again.

This took some of my saturday morning (to see what was going on), then
discussion in the releng meeting monday morning to come up with a plan
to fix things up, then the actual fix monday. 

kevin


pgpqZqqa_J1e5.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Simo Sorce]

On Tue, 2016-07-19 at 07:39 -0400, Nico Kadel-Garcia wrote:
> Like I said, I'm thinking of "rsync", "tar", and "star". Also,
> people do some interesting scripting to detect things like failed
> NFS configurations. I'm not saying that's a blocker, but shifting it
> to overlap with the current "nfsnobody" is likely to break some
> people's tools in the field, especially if they run the latest Fedora
> alongside RHEL, CentOS,  or previous Fedora releases.

The breakage for some will be un-breakage for someone else, and being
consistent with the kernel point of view and other distributions, in
this case, is more important IMO.

Simo.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Simo Sorce]

On Mon, 2016-07-18 at 14:39 +0200, Lennart Poettering wrote:
> Heya!
> 
> I'd like to start a discussion regarding the "nobody" user on Fedora,
> and propose that we change its definition sooner or later. I am not
> proposing a feature according to the feature process for this yet,
> but
> my hope is that these discussions will lead to one eventually.
> 
> Most distributions (in particular Debian/Ubuntu-based ones) map the
> user "nobody" to UID 65534. I think we should change Fedora to do the
> same. Background:
> 
> On Linux two UIDs are special: that's UID 0 for root, which is the
> privileged user we all know. And then there's UID 65534
> (i.e. (uint16_t) -2), which is less well known. The Linux kernel
> calls
> it the "overflow" UID. It has four purposes:
> 
> 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
>    only supports 16bit UIDs, but a 32bit UID is passed to it.
> 
> 2. it's used by the kernel's user namespacing as a the internal UID
>    that external UIDs are mapped to that don't have any local
> mapping.
> 
> 3. It's used by NFS for all user IDs that cannot be mapped locally if
>    UID mapping is enabled.
> 
> 4. One upon a time some system daemons chose to run as the "nobody"
>    user, instead of a proper system user of their own. But this is
>    universally frowned upon, and isn't done on any current systems
>    afaics. In fact, to my knowledge Fedora even prohibits this
>    explicitly in its policy (?).
> 
> The uses 1-3 are relevant today, use 4 is clearly obsolete
> afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
> that cannot be mapped properly is mapped to".
> 
> On Fedora, we currently have a "nobody" user that is defined to UID
> 99. It's defined unconditionally like this. To my knowledge there's
> no
> actual use of this user at all in Fedora however. The UID 65514
> carries no name by default on Fedora, but as soon as you install the
> NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
> indicating that it would be used only by NFS even though it's a much
> more general concept. I figure the NFS guys adopted the name
> "nfsnobody" for this, simply because "nobody" was already taken by
> UID
> 99 on Fedora, unlike on other distributions.
> 
> In the context of user namespacing the UID 65534 appears a lot more
> often as owner of various files. For example, if you turn on user
> namespacing in typical container managers you'll notice that a ton of
> files in /proc will then be owned by this user. Very confusingly, in
> a
> container that includes the NFS utils all those files actually show
> up
> as "nfsnobody"-owned now, even though there's no relation to NFS at
> all
> for them.
> 
> I'd like to propose that we clean this up, and just make Fedora work
> like all other distributions. After all the reason of having this
> special UID in the first place is to sidestep mapping problems
> between
> different UID "realms". Hence I think it would be wise to at least
> make the name of this very special UID somewhat more stable and
> well-defined between distributions.
> 
> I think this is of particular relevance as Debian/Ubuntu-based
> container images tend to be substantially more popular than
> Fedora-based ones, and hence I think we should try to unify at least
> the names and semantics of the two special UIDs all distros have, to
> minimize mapping problems and making user interaction in containers a
> bit more friendly.
> 
> You might ask of course, why Fedora should change to adopt
> Debian's/Ubuntu's definition, instead of conversely making them adopt
> Fedora's definition? Well, that's simple: Debian's definition makes a
> lot more sense than Fedora's. And nothing we ship actually makes use
> of FEdora's definition afaics, and we currently carry a workaround
> called "nfsnobody" in some cases to avoid having to fix this
> properly.
> 
> Another option would be to define an entirely new user name for
> 65534,
> for example "void" or so. But quite frankly, that sounds like a
> pointless bikeshedding excercise, and creates even more confusion,
> balkanization and political hassles if you'd try to convince other
> distros to adopt the same scheme too.
> 
> Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
> the various dsitributions a tiny bit more, on this specific aspect.
> 
> How could a transition look like? I figure new installs should get
> "nobody" defined to 65534. Old installs should keep the old
> definitions in place instead. The NFS packages should be updated to
> not create the "nfsnobody" user if there's already another user
> mapped
> to 65534 (maybe it already does that?). Of course it's not pretty if
> old and new systems use different definitions for this user, but I
> think it's not too much of a real-life issue, as most code that
> refers
> to this group already does so by UID instead of name, simply because
> the name is not stable across distributions.
> 
> Opinions?

+1,
Simo.

Re: releng's mlt-6.2.0-3.fc25 failed to build

[Sérgio Basto]

DEBUG util.py:417:  Error: nothing provides libpoppler.so.60()(64bit)
needed by gdal-libs-2.1.0-6.fc25.x86_64
DEBUG util.py:417:  (try to add '--allowerasing' to command line to
replace conflicting packages)
DEBUG util.py:542:  Child return code was: 1



On Ter, 2016-07-19 at 13:20 +, notificati...@fedoraproject.org
wrote:
> Package:mlt-6.2.0-3.fc25
> Status: failed
> Built by:   releng
> ID: 781765
> Started:Tue, 19 Jul 2016 08:45:59 UTC
> Finished:   Tue, 19 Jul 2016 09:09:36 UTC
> 
> Closed tasks:
> -
> Task 14940864 on buildppc-02.phx2.fedoraproject.org
> Task Type: build (noarch)
> Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14940864
> 
> error building package (arch x86_64), mock exited with status 30; see
> root.log for more information
> 
> Task 14941380 on arm04-builder06.arm.fedoraproject.org
> Task Type: buildSRPMFromSCM (noarch)
> Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941380
> logs:
>   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/root.lo
> g
>   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/state.l
> og
>   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/build.l
> og
> srpm:
>   https://kojipkgs.fedoraproject.org/work/tasks/1380/14941380/mlt-6.2
> .0-3.fc25.src.rpm
> 
> Task 14941915 on buildvm-24.phx2.fedoraproject.org
> Task Type: buildArch (x86_64)
> Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941915
> 
> error building package (arch x86_64), mock exited with status 30; see
> root.log for more information
> 
> Task 14941914 on arm02-builder10.arm.fedoraproject.org
> Task Type: buildArch (armhfp)
> Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941914
> 
> Task 14941914 is canceled
> 
> Task 14941916 on buildhw-03.phx2.fedoraproject.org
> Task Type: buildArch (i386)
> Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=14941916
> 
> Task 14941916 is canceled
> 
>   http://koji.fedoraproject.org/koji/buildinfo?buildID=781765
> 
> --
> You received this message due to your preference settings at
> https://apps.fedoraproject.org/notifications/sergiomb.id.fedoraprojec
> t.org/email/30349
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: notion of base or minimal image

[Richard W.M. Jones]

On Tue, Jul 19, 2016 at 01:32:36PM +0200, Nikos Mavrogiannopoulos wrote:
> Hi,
>  Is there some notion or definition of a Fedora minimal or base image?
> I couldn't find some documentation on that. I would like to modify some
> script which a package on the critical path depends on, from bash to
> perl and I would like to understand whether that could affect any
> fedora images.

When making virt-builder templates we install only packages from @core
(and their dependencies obviously).  Here is the script we use:

https://github.com/libguestfs/libguestfs/blob/master/builder/website/fedora.sh#L65

Rich.

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

Re: notion of base or minimal image

[Stephen Gallagher]

On 07/19/2016 07:32 AM, Nikos Mavrogiannopoulos wrote:
> Hi,
>  Is there some notion or definition of a Fedora minimal or base image?
> I couldn't find some documentation on that. I would like to modify some
> script which a package on the critical path depends on, from bash to
> perl and I would like to understand whether that could affect any
> fedora images.
> 

This definition is supposed to be one of the direct deliverables of the
Modularity WG, so I'd direct you to talk to them (CCing Langdon from that team).




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: notion of base or minimal image

[Colin Walters]

On Tue, Jul 19, 2016, at 07:32 AM, Nikos Mavrogiannopoulos wrote:
> Hi,
>  Is there some notion or definition of a Fedora minimal or base image?

A lot depends on whether "image" is a container or OS, which mostly
boils down to "contains a kernel".

For containers I would look at:

`docker run --rm -ti fedora:23 bash`
as well as the rootfs produced by:
yum install @buildsys-build

For OS images:
 - The Anaconda ISO
 - Atomic Host
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160719.n.0 compose check report

[Fedora compose checker]

Missing expected images:

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

Failed openQA tests: 26/74 (x86_64), 15/15 (i386)

ID: 25632   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/25632
ID: 25633   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/25633
ID: 25634   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/25634
ID: 25635   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/25635
ID: 25636   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/25636
ID: 25637   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/25637
ID: 25639   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/25639
ID: 25641   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/25641
ID: 25647   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/25647
ID: 25648   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/25648
ID: 25655   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/25655
ID: 25656   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/25656
ID: 25659   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/25659
ID: 25663   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/25663
ID: 25674   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/25674
ID: 25675   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/25675
ID: 25676   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/25676
ID: 25677   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/25677
ID: 25678   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/25678
ID: 25679   Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/25679
ID: 25684   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/25684
ID: 25685   Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/25685
ID: 25686   Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/25686
ID: 25687   Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/25687
ID: 25688   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/25688
ID: 25691   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/25691
ID: 25693   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/25693
ID: 25698   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/25698
ID: 25707   Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/25707
ID: 25708   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/25708
ID: 25709   Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/25709
ID: 25710   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/25710
ID: 25711   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/25711
ID: 25712   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/25712
ID: 25713   Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/25713
ID: 25714   Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/25714
ID: 25715   Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/25715
ID: 25716   Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/25716
ID: 25717   Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/25717
ID: 25718   Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/25718
ID: 25719   Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/25719

Soft failed openQA tests: 3/74 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 25690   Test: x86_64

Re: Fixing the "nobody" user?

[Benjamin Coddington]

On 18 Jul 2016, at 8:39, Lennart Poettering wrote:

> Heya!
>
> I'd like to start a discussion regarding the "nobody" user on Fedora,
> and propose that we change its definition sooner or later. I am not
> proposing a feature according to the feature process for this yet, but
> my hope is that these discussions will lead to one eventually.
>
> Most distributions (in particular Debian/Ubuntu-based ones) map the
> user "nobody" to UID 65534. I think we should change Fedora to do the
> same. Background:
>
> On Linux two UIDs are special: that's UID 0 for root, which is the
> privileged user we all know. And then there's UID 65534
> (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
> it the "overflow" UID. It has four purposes:
>
> 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
>only supports 16bit UIDs, but a 32bit UID is passed to it.
>
> 2. it's used by the kernel's user namespacing as a the internal UID
>that external UIDs are mapped to that don't have any local mapping.
>
> 3. It's used by NFS for all user IDs that cannot be mapped locally if
>UID mapping is enabled.
>
> 4. One upon a time some system daemons chose to run as the "nobody"
>user, instead of a proper system user of their own. But this is
>universally frowned upon, and isn't done on any current systems
>afaics. In fact, to my knowledge Fedora even prohibits this
>explicitly in its policy (?).
>
> The uses 1-3 are relevant today, use 4 is clearly obsolete
> afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
> that cannot be mapped properly is mapped to".

I think this is a good proposal, but the work would be in making sure use 4
really is obsolete since the big change here would be redefining what
that "nobody" means.  Right now, "nobody" is a real local account that scripts
and daemons have used to sandbox themselves, and sometimes we can even find
stuff like uid == 99 in conditionals.

It's important to NFS that when passing file owner name strings between
clients and servers the string "nobody" means the unmappable user, and not a
real user of lowest privilege.  If we make the change to redefine what the
local user "nobody" means, we should make sure use 4 is obsolete.

Otherwise, NFS is pretty flexible about being able to configure uid/name
mappings, and I don't see a problem for NFS in changing -2 from nfsnobody to
nobody.

> On Fedora, we currently have a "nobody" user that is defined to UID
> 99. It's defined unconditionally like this. To my knowledge there's no
> actual use of this user at all in Fedora however.

After a quick grep, Lustre has a
#define NOBODY_UID  99

I don't know how that's used..

> The UID 65514 carries no name by default on Fedora, but as soon as you
> install the NFS utils it gets mapped to the "nfsnobody" user name,
> misleadingly indicating that it would be used only by NFS even though it's
> a much more general concept. I figure the NFS guys adopted the name
> "nfsnobody" for this, simply because "nobody" was already taken by UID 99
> on Fedora, unlike on other distributions.

Likely, yes -- but maybe some of the other NFS people know more of the
history.

> In the context of user namespacing the UID 65534 appears a lot more
> often as owner of various files. For example, if you turn on user
> namespacing in typical container managers you'll notice that a ton of
> files in /proc will then be owned by this user. Very confusingly, in a
> container that includes the NFS utils all those files actually show up
> as "nfsnobody"-owned now, even though there's no relation to NFS at all
> for them.
>
> I'd like to propose that we clean this up, and just make Fedora work
> like all other distributions. After all the reason of having this
> special UID in the first place is to sidestep mapping problems between
> different UID "realms". Hence I think it would be wise to at least
> make the name of this very special UID somewhat more stable and
> well-defined between distributions.
>
> I think this is of particular relevance as Debian/Ubuntu-based
> container images tend to be substantially more popular than
> Fedora-based ones, and hence I think we should try to unify at least
> the names and semantics of the two special UIDs all distros have, to
> minimize mapping problems and making user interaction in containers a
> bit more friendly.
>
> You might ask of course, why Fedora should change to adopt
> Debian's/Ubuntu's definition, instead of conversely making them adopt
> Fedora's definition? Well, that's simple: Debian's definition makes a
> lot more sense than Fedora's. And nothing we ship actually makes use
> of FEdora's definition afaics, and we currently carry a workaround
> called "nfsnobody" in some cases to avoid having to fix this properly.
>
> Another option would be to define an entirely new user name for 65534,
> for example "void" or so. But quite frankly, that sounds like a
> pointless bikeshedding excercise, and c

[Test-Announce] 2016-07-20 @ 16:00 UTC - Fedora 25 Blocker Review

[Petr Schindler]

# F25 Blocker Review meeting
# Date: 2016-07-20
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have currently few blockers proposed for future Fedora 25
so it would be great to look at them now when they aren't overpopulated
yet. There are 3 proposed Beta blockers, 1 Beta blocker and 1 Final
blocker.

If you have some time, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ . Remember to check
each outstanding milestone (Alpha, Beta and Final).

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F25 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

Have a nice day,
Petr Schindler, Fedora QA
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Nico Kadel-Garcia]

On Mon, Jul 18, 2016 at 8:39 AM, Lennart Poettering
 wrote:

> On Fedora, we currently have a "nobody" user that is defined to UID
> 99. It's defined unconditionally like this. To my knowledge there's no
> actual use of this user at all in Fedora however. The UID 65514
> carries no name by default on Fedora, but as soon as you install the
> NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
> indicating that it would be used only by NFS even though it's a much
> more general concept. I figure the NFS guys adopted the name
> "nfsnobody" for this, simply because "nobody" was already taken by UID
> 99 on Fedora, unlike on other distributions.

At first glance it makes some sense. 2^32-2 doesn't force it into
64-bit space, it's tested on other operating systems, I'm concerned
that overlapping "nobody" with the working "nfsnobody" is going to
break tools. I'm also cncerned that it will change behavior for "tar",
"rsync", "star", and other programs that can be configured to store
and extract usernames *or* uids, or a mix of both.

> In the context of user namespacing the UID 65534 appears a lot more
> often as owner of various files. For example, if you turn on user
> namespacing in typical container managers you'll notice that a ton of
> files in /proc will then be owned by this user. Very confusingly, in a
> container that includes the NFS utils all those files actually show up
> as "nfsnobody"-owned now, even though there's no relation to NFS at all
> for them.

And this is where the shift in behavior would get confusing.

> How could a transition look like? I figure new installs should get
> "nobody" defined to 65534. Old installs should keep the old
> definitions in place instead. The NFS packages should be updated to
> not create the "nfsnobody" user if there's already another user mapped
> to 65534 (maybe it already does that?). Of course it's not pretty if
> old and new systems use different definitions for this user, but I
> think it's not too much of a real-life issue, as most code that refers
> to this group already does so by UID instead of name, simply because
> the name is not stable across distributions.

Like I said, I'm thinking of "rsync", "tar", and "star". Also,
people do some interesting scripting to detect things like failed
NFS configurations. I'm not saying that's a blocker, but shifting it
to overlap with the current "nfsnobody" is likely to break some
people's tools in the field, especially if they run the latest Fedora
alongside RHEL, CentOS,  or previous Fedora releases.

> Opinions?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

notion of base or minimal image

[Nikos Mavrogiannopoulos]

Hi,
 Is there some notion or definition of a Fedora minimal or base image?
I couldn't find some documentation on that. I would like to modify some
script which a package on the critical path depends on, from bash to
perl and I would like to understand whether that could affect any
fedora images.

regards,
Nikos
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Lennart Poettering]

On Tue, 19.07.16 11:17, James Hogarth (james.hoga...@gmail.com) wrote:

> On 19 July 2016 at 10:59, Lennart Poettering  wrote:
> 
> > On Mon, 18.07.16 17:45, Sam Varshavchik (mr...@courier-mta.com) wrote:
> >
> > > Lennart Poettering writes:
> > >
> > > >On Fedora, we currently have a "nobody" user that is defined to UID
> > > >99. It's defined unconditionally like this. To my knowledge there's no
> > > >actual use of this user at all in Fedora however.
> > >
> > > I see distccd running as the nobody user.
> > >
> > > I also see dnsmasq running as the nobody user.
> >
> > Urks, this looks broken. Don't our package guidelines prohibit this?
> >
> >
> >
> I don't see anything in the overall guidelines[1], the users_and_groups
> guidelines[2] or the systemd_unit guidelines[3]
> 
> A quick search of FPC tickets doesn't show any discussion there either.
> 
> [1] https://fedoraproject.org/wiki/Packaging:Guidelines
> [2] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
> [3] https://fedoraproject.org/wiki/Packaging:Systemd

Hmm, OK. I filed an FPC ticket about this now:

https://fedorahosted.org/fpc/ticket/642

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Test-Announce] Fedora 25 Rawhide 20160719.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 25 Rawhide 20160719.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/25

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Rawhide_20160719.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/relval/
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[James Hogarth]

On 19 July 2016 at 10:59, Lennart Poettering  wrote:

> On Mon, 18.07.16 17:45, Sam Varshavchik (mr...@courier-mta.com) wrote:
>
> > Lennart Poettering writes:
> >
> > >On Fedora, we currently have a "nobody" user that is defined to UID
> > >99. It's defined unconditionally like this. To my knowledge there's no
> > >actual use of this user at all in Fedora however.
> >
> > I see distccd running as the nobody user.
> >
> > I also see dnsmasq running as the nobody user.
>
> Urks, this looks broken. Don't our package guidelines prohibit this?
>
>
>
I don't see anything in the overall guidelines[1], the users_and_groups
guidelines[2] or the systemd_unit guidelines[3]

A quick search of FPC tickets doesn't show any discussion there either.

[1] https://fedoraproject.org/wiki/Packaging:Guidelines
[2] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
[3] https://fedoraproject.org/wiki/Packaging:Systemd
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Lennart Poettering]

On Mon, 18.07.16 17:45, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Lennart Poettering writes:
> 
> >On Fedora, we currently have a "nobody" user that is defined to UID
> >99. It's defined unconditionally like this. To my knowledge there's no
> >actual use of this user at all in Fedora however.
> 
> I see distccd running as the nobody user.
> 
> I also see dnsmasq running as the nobody user.

Urks, this looks broken. Don't our package guidelines prohibit this?

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Lennart Poettering]

On Mon, 18.07.16 17:00, Ondřej Vašík (ova...@redhat.com) wrote:

> > So what do you propose instead? Just stick our heads in the sand,
> > ignore the issue, accept that in containers all files in /proc now
> > sometimes show up as owned by the literal "65534" user and sometimes
> > as owned by "nfsnobody", depending on whether the NFS utils package is
> > in the mix or not, even though userns has really *nothing* to do with
> > NFS?
> 
> No, that's not my proposal as you can read in my "we should find some
> way how to solve it." ;)
> 
> I even proposed other way - changing overflowid/overflowgid
> through  /proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid - that
> should work - although changing documented defaults is usually not the
> best way - so I don't think this is the right way to solve this
> either.

I'd be be very careful with that, as this would mean files with the
old UIDs would suddenly change ownership, and code might lose access.

I am pretty sure that of the two bad solutions of changing the name of
the user or changing the UID of it, the latter is much worse than the
former...

> > Another option could be to simply define both name mappings in
> > /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as
> > well as nobody → 65534. This is only semi-supported though, and might
> > just shift brokeness around... (a slightly different alternative could
> > be to implement the "nobody" mapping in an explicit NSS module that is
> > ordered after "files", and drop it from /etc/passwd. That way whatever
> > is defined in /etc/passwd would take precedence, but if "nobody" is
> > explicitly requested it would also be mapped, but would not show up in
> > the user listing of "getent passwd". In effect, /etc/passwd and
> > "getent passwd" would only show unique UID mappings that way, even
> > though "nobody" stays always resolvable).
> 
> Mapping of both names to same ID through file precedence is not going to
> solve this issue when nfs-utils package is installed. nfsnobody will own
> some of the /proc files, confusing users. I like the NSS module a bit
> more than "nobody->65534 , nfsnobody->get out" - especially if this will
> be part of the systems where user namespaces are likely - to the
> containers. Can be solution for most of the usecases (except the
> container with nfs-utils installed).

The NSS option would work for me too. In fact, I am tempted to just
ship an NSS module along with systemd that maps UIDs 0 and 65534 like
this, if they aren't listed properly in /etc/passwd. Having that would
be pretty neat as container-like environments could drop their passwd
database entirely and still get useful resolution of the two most
relevant UIDs in this context.

> In my opinion, simple solution is bad solution here. Maybe another
> solution can be to define safe namespaces for system users - something
> like _$name on OS X - however this is more complex than simple rename.

IIRC Debian adopted a similar scheme. Newly allocated system
users need to begin with an underscore. I am pretty sure Fedora should
adopt a similar scheme, at least for user/group names allocated from
now on... But that's a different discussion...

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi takes days to get something pushed to testing

[Thomas Moschny]

2016-07-18 23:57 GMT+02:00 Kevin Fenzi :
> I could tell you more about your specific updates if you list them...

This one took a bit more than 6 days from submission to testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-e5b5fbfa86

- Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: rpm-build's dependency on perl-generators removed

[Petr Šabata]

On Tue, Jul 19, 2016 at 06:56:43AM +, Petr Pisar wrote:
> Perl 
> F25 change, I removed run-time dependency on perl-generators from
> rpm-build package in rpm-4.13.0-0.rc1.40.fc25 build.
> 
> This should remove perl from minimal build root.
> 
> -- Petr

It may sound strange coming from me but... thank you for this :)

P


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org