Re: Notice on WebKitGTK+ API/ABI compatibility

2016-09-01 Thread Michael Catanzaro 
On Mon, 2016-06-13 at 21:47 -0500, Michael Catanzaro wrote:
> Hi,
> 
> Just want to let you know I am planning to document it on the WebKit
> wiki and also downstream somewhere (seems like a README might be
> better
> than a wiki page?).
> 
> Michael

An update on this. We have frozen the DOM bindings API; it's no longer
autogenerated. We're marking all unstable DOM API that's actually used
by applications as stable, and removing the rest of the unstable API.
WebKitGTK+ 2.16 will no longer have any unstable API.

Accordingly, I've changed my mind about creating a wiki page, as going
forward the API/ABI guarantee is very simple: we don't break either.

Until then, we'll continue to take care of affected applications
(Epiphany, Evolution, Yelp).

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

Where did res_querydomain go in f24??

2016-09-01 Thread Steve Dickson 
Hello, 

This is regard to bz1372136... as the bz says

From Koji logs :
 - x86_64 and armv7hl have an issue in configure : checking for res_querydomain 
in -lresolv... no
 - i686 works : checking for res_querydomain in -lresolv... yes
This is strange, since the symbol in present in /lib/libresolv-2.23.so.

Here was has res_querydomain or even res_nquerydomain moved to to??
Why can't I find it with a AC_CHECK_FUNC() or a AC_CHECK_LIB() macros?

tia,

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

Re: Some of my packages are looking for new (co-)maintainers

2016-09-01 Thread Piotr Popieluch 
On 09/01/2016 09:59 PM, Raphael Groner wrote:
> HI,
> 
> I'll orphan some of my packages due to lack of available time to properly 
> maintain them:
> - rpms/bats -- Bash Automated Testing System ( master f25 f24 f23 epel7 el6 )
I'll take bats

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

Some of my packages are looking for new (co-)maintainers

2016-09-01 Thread Raphael Groner 
HI,

I'll orphan some of my packages due to lack of available time to properly 
maintain them:
- rpms/bats -- Bash Automated Testing System ( master f25 f24 f23 epel7 el6 )
- rpms/docsis-config-encoder -- Encode a DOCSIS binary configuration file ( 
master f25 f24 f23 )
- rpms/i7z -- CLI curses based monitoring tool for Intel Core i7 processors ( 
master f25 f24 f23 )
- rpms/jpype -- Full access for Python programs to Java class libraries ( 
master f25 f24 f23 epel7 )
- rpms/mdp -- Minimalist password safe ( master f25 f24 f23 )
- rpms/python-javaobj -- Python module for serializing and deserializing Java 
objects ( master f25 f24 f23 )
- rpms/xfce-bluetooth -- A simple bluetooth manager for Xfce ( master f25 f24 
f23 epel7 ) 

Feel free to take some of the above.

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

Re: Bodhi 2 coming to a Rawhide near you

2016-09-01 Thread Randy Barlow 
I've filed an issue to track this problem:

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

Thanks again!

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi 2 coming to a Rawhide near you

2016-09-01 Thread Randy Barlow 
On Thu, 2016-09-01 at 20:45 +0200, Fabio Alessandro Locati wrote:
> The F24 copr seems to be broken. I've enabled it, updated all
> packages
> and running 'bodhi', it seems to be broken:
> 

> pkg_resources.DistributionNotFound: The 'bodhi==2.1.8' distribution
> was
> not found and is required by the application

How embarrassing for me! In fact, this is also broken in the Rawhide
build I just wrote about. It turns out that the bodhi-client package
only works if the bodhi-server package is installed, and during my
testing I always had both installed. Ooops.

I think I will add a bodhi-common package that will own the
distribution bits, which should allow bodhi-client to be installed
independently of the server.

Thanks for such amazing response time, and for letting me know. It
should be pretty quick to fix. Fale, you are why FOSS is great!

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Bodhi 2 coming to a Rawhide near you

2016-09-01 Thread Fabio Alessandro Locati 
On Thu, Sep 01, 2016 at 02:34:00PM -0400, Randy Barlow wrote:
> I forgot to mention, I'm also maintaining a Copr for Bodhi 2 for Fedora
> 23 and 24:
> 
> https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi/
> 
> Copr doesn't seem to have Fedora 25 buildroots yet, but I'll try to
> remember to add Fedora 25 as well once it does.

The F24 copr seems to be broken. I've enabled it, updated all packages
and running 'bodhi', it seems to be broken:

[fale@redhat ~]$ bodhi 
Traceback (most recent call last):
  File "/usr/bin/bodhi", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 3141, in 
@_call_aside
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 3127, in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 3154, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 640, in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 941, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 828, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'bodhi==2.1.8' distribution was
not found and is required by the application


-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


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

[EPEL-devel] Re: cmake issues with epel7 build

2016-09-01 Thread Tuomo Soini 
On Thu, 01 Sep 2016 09:38:08 -0400
jason taylor  wrote:

> Working on getting a bro build for epel7 and I am running into what
> appears to be a provides bug with cmake3. 

That's correct analysis yes, cmake3 provides cmake which it shouldn't
really do.

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-de...@lists.fedoraproject.org

Re: Bodhi 2 coming to a Rawhide near you

2016-09-01 Thread Randy Barlow 
I forgot to mention, I'm also maintaining a Copr for Bodhi 2 for Fedora
23 and 24:

https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi/

Copr doesn't seem to have Fedora 25 buildroots yet, but I'll try to
remember to add Fedora 25 as well once it does.

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Bodhi 2 coming to a Rawhide near you

2016-09-01 Thread Randy Barlow 
Hello again Fedora friends!

I just built bodhi-2.1.8-1.fc26 for Rawhide, and wanted to give you a
heads up as it is a backwards incompatible change. Rawhide previously
had bodhi-0.9.12.2-5.fc25.noarch so this is a pretty major update.

The bodhi client is probably what most of you are used to interacting
with (possibly only through fedpkg, which wraps it). The new CLI is a
rewrite from the old one, and has different commands and options. I
took a stab at writing the new man page from scratch and I think I got
most things covered. The CLI also has built-in help text that should be
pretty usable. If you find any issues with the man page or client,
please feel free to file an issue[0] or a pull request. You can read
the docs on GitHub as well[1].

This update has been a long time coming, and in fact the production
Bodhi server has been running version two for some time. We had a lot
of patches on bodhi-client-0.9 to make it work with Bodhi Server 2, so
this update will let everyone be on the new CLI that is natively
compatible with the production server now.

At this time, I've opted out of updating bodhi in Fedora 23, 24, and
even 25 since it is not backwards compatible. If you are using one of
those, it should continue to function the way you are used to it. I
also plan to update Bodhi in EPEL 7, and will write more about this on
the relevant EPEL mailing lists.

If you typically only use fedpkg to submit Bodhi updates rather than
the bodhi CLI directly, you will need to make sure you have fedpkg-
1.25-1.fc26 or newer. That version of fedpkg is compatible with both
Bodhi 0.9 and 2[2].

Thanks for reading, and happy updating!


[0] https://github.com/fedora-infra/bodhi/issues/new
[1] https://github.com/fedora-infra/bodhi/blob/develop/docs/man_bodhi.r
st
[2] https://pagure.io/fedpkg/pull-request/40

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora 25-20160901.n.0 compose check report

2016-09-01 Thread Adam Williamson 
On Thu, 2016-09-01 at 15:57 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Cloud_base raw-xz i386
> Atomic raw-xz x86_64
> 
> Failed openQA tests: 15/89 (x86_64), 4/17 (i386), 1/2 (arm)
> 
> ID: 31621 Test: x86_64 Workstation-live-iso install_default_upload
> URL: https://openqa.fedoraproject.org/tests/31621
> ID: 31622 Test: x86_64 Workstation-live-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/31622
> ID: 31628 Test: x86_64 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/31628
> ID: 31629 Test: x86_64 Workstation-boot-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/31629
> ID: 31630 Test: i386 Workstation-live-iso install_default
> URL: https://openqa.fedoraproject.org/tests/31630
> ID: 31631 Test: i386 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/31631

These are mostly needle issues, and should be solved tomorrow. The
tests passed on staging, where I fixed the needles.

> ID: 31632 Test: x86_64 Atomic-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/31632

This is the same ol' bug that's been around for months, but at least
there's some movement now.

> ID: 31641 Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/31641

It seems initial-setup is not running on boot (or, possibly, it's just
too slow and we're not waiting long enough). Jan wrote the ARM test
stuff, so if you could look into this...

> ID: 31653 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
> URL: https://openqa.fedoraproject.org/tests/31653

This is a dependency issue, but I haven't immediately been able to
reproduce it. I'll fiddle with it a bit more.

> ID: 31655 Test: x86_64 Server-dvd-iso server_cockpit_default
> URL: https://openqa.fedoraproject.org/tests/31655

This is another odd dependency issue, dnf refusing to install firefox
because of some sqlite dependency issue, even though sqlite of the
correct version is present in the repos and images with firefox on them
composed just fine. Again, not quite sure what's going on here. It
could simply be that the tests ran with yesterday's repos and there was
a problem there, we'll see what happens tomorrow.

> ID: 31684 Test: x86_64 universal install_iscsi
> URL: https://openqa.fedoraproject.org/tests/31684

Same old: https://bugzilla.redhat.com/show_bug.cgi?id=1347415
this should get fixed in the next anaconda update.

> ID: 31698 Test: x86_64 universal upgrade_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/31698
> ID: 31700 Test: x86_64 universal upgrade_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/31700
> ID: 31701 Test: x86_64 universal upgrade_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/31701
> ID: 31703 Test: x86_64 universal upgrade_2_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/31703
> ID: 31704 Test: x86_64 universal upgrade_2_server_64bit
> URL: https://openqa.fedoraproject.org/tests/31704
> ID: 31705 Test: x86_64 universal upgrade_2_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/31705
> ID: 31706 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/31706
> ID: 31723 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/31723
> ID: 31724 Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/31724

The desktop fails here are the same needle issues as with the desktop
image install tests. The others are:

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

> Passed openQA tests: 65/89 (x86_64), 13/17 (i386)
> 
> Skipped openQA tests: 8 of 108
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: My experiences with KillUserProcesses=yes on F24

2016-09-01 Thread Jason L Tibbitts III 
> "NK" == Nico Kadel-Garcia  writes:

NK> To me, it looks like systemd is activating a universal policy which
NK> you, and others, need more thoughtful and tunable handling for.
NK> Attempting to tune it by outsmarting systemd's default behavior
NK> looks expensive and unstable.

Well, please keep in mind that _I_ am the one who is activating this.  I
don't care one way or the other what the default is; a single line in a
file in /etc/systemd/logind.conf.d sets that the way I like.

NK> Agreed. The acceptance of the feature without any logging,
NK> whatsoever, of what processes it killed and when shocked me.

I'm not talking about any feature or any acceptance.  This is entirely
something I am trying, on my own, because I was intrigued by the
possibility of enforced process death at session termination.

I am making no commentary on the viability of any of this for Fedora in
general.  I'm just sharing my experiences.  Perhaps others can glean
something useful from them in some relation to what Fedora may or may
not do in the future, and that's fine, but I'm not trying to influence
that in any way.

>> What I wish for is for some "property", let's call it "persist" to be
>> "attached" to a scope in some way (presumably a flag to systemd-run)
>> which does nothing other than to indicate that the scope will
>> continue to run after the user's session has terminated.  This
>> wouldn't be a persistent user setting.  Nothing would start at boot.
>> The user manager would start up if necessary at login (even if it had
>> previously been killed) and persist until all user processes in any
>> scope have exited.

NK> Wouldn't an hourly or nightly cron job reporting such tasks, with an
NK> option to kill them on a group or user based policy basis, be safer
NK> if such a daemon is needed?

I'm not entirely sure what you're suggesting.

If you're saying that I could just a cron job cleaning up jobs that
shouldn't be there, I am not certain that such a thing is possible.
Plus I've experienced a problem where users get dropped back to the
login box after a timeout, with their session destroyed but processes
still hanging around in such a way that they're prevented from logging
in a second time.  Hourly cleanup of these things is far too slow, and
sub-minute-ly would be kind of a waste.  KillUserProcesses=yes appears
to handle this case just fine as far as I've been able to test this.
(It's tough to reproduce, and does involve the confluence of other
bugs.)

NK> Can the tasks run with cron jobs in your environment? I realize that
NK> Kerberized access to user home directories might prevent working
NK> access to scripts that live in their home directory.

Well, teaching users to do that would be beyond my means.  (I'm only
human, after all.)  Something like Condor is a far better option for
using desktop cycles in the background, but it's tough to beat the
"nohup my_job" that they learned out of some book about Fortran 25 years
ago.

NK> The thoughtful hands-on experience is welcome. It confirms the idea
NK> that in multi-user environment, backgrounded sessions continuing
NK> after logout is a common and effectively used feature worthy of
NK> support.

Well, keep in mind that it will always be supported as long as you can
still set KillUserProcesses=no.  I'm trying to get the best of both
worlds, to the extent that is possible, and I'm willing to hack things
to get it.  I'm not asking anyone else to support that, but I am trying
to inform them of what they're up against should they want the same
thing.  I do have a suspicion that I'm not the only person who would
want this, though, which is why I sent the message in the first place.

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

Fedora 25-20160901.n.0 compose check report

2016-09-01 Thread Fedora compose checker 
Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

Failed openQA tests: 15/89 (x86_64), 4/17 (i386), 1/2 (arm)

ID: 31621   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/31621
ID: 31622   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/31622
ID: 31628   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/31628
ID: 31629   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/31629
ID: 31630   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/31630
ID: 31631   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/31631
ID: 31632   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/31632
ID: 31641   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/31641
ID: 31653   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/31653
ID: 31655   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/31655
ID: 31684   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/31684
ID: 31698   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/31698
ID: 31700   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/31700
ID: 31701   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/31701
ID: 31703   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/31703
ID: 31704   Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/31704
ID: 31705   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/31705
ID: 31706   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/31706
ID: 31723   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/31723
ID: 31724   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/31724

Passed openQA tests: 65/89 (x86_64), 13/17 (i386)

Skipped openQA tests: 8 of 108
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Orphaned Packages in branched (2016-09-01)

2016-09-01 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
and   orphan, s4504kr 4 weeks ago   
avra  orphan, musolinoa   5 weeks ago   
cvsclient orphan, java-sig, mizdebsk, 13 weeks ago  
  msrb  
dbmailorphan, bjohnson9 weeks ago   
dwatchorphan, bjohnson9 weeks ago   
firecontrol   orphan, dajt, jwilson   4 weeks ago   
freeradius-client orphan, nmav17 weeks ago  
ghc-editline  orphan, haskell-sig, s4504kr4 weeks ago   
ghc-primesorphan, haskell-sig, s4504kr4 weeks ago   
glusterfs-hadoop  orphan, lalatendu   12 weeks ago  
gnustep-back  orphan, s4504kr 4 weeks ago   
gnustep-examples  orphan, s4504kr 4 weeks ago   
gnustep-gui   orphan, s4504kr 4 weeks ago   
gorm  orphan, s4504kr 4 weeks ago   
gresolver orphan, s4504kr 4 weeks ago   
js-jquery-migrate orphan, group::nodejs-sig,  4 weeks ago   
  jamielinux, patches   
kaya  orphan, s4504kr 4 weeks ago   
latex2emf orphan, alexlan 4 weeks ago   
libsieve  orphan, bjohnson9 weeks ago   
libzdborphan, bjohnson, cicku 9 weeks ago   
luma  orphan, s4504kr 4 weeks ago   
maniadriveorphan, jwrdegoede  8 weeks ago   
media-explorerorphan, hadess  0 weeks ago   
msp430-binutils   orphan, rspanton, swhiteho  8 weeks ago   
msp430-gccorphan, rspanton, swhiteho  8 weeks ago   
msp430-libc   orphan, rspanton8 weeks ago   
msp430mcu orphan, rspanton8 weeks ago   
mspdebug  orphan, rspanton8 weeks ago   
netmonitororphan, fab, tuxbrewr   6 weeks ago   
open-cobolorphan, s4504kr 4 weeks ago   
openlmi-storage   orphan, agk, jsafrane,  17 weeks ago  
  jsynacek, rnovacek
phpMemcachedAdmin orphan  10 weeks ago  
picprog   orphan, musolinoa   5 weeks ago   
polipoorphan, bjohnson, jcp   9 weeks ago   
powerman  orphan, tuxbrewr28 weeks ago  
psgml orphan, alexlan 4 weeks ago   
pypop orphan, alexlan 4 weeks ago   
python-pifpaf orphan, pkilambi0 weeks ago   
queuegraphorphan, bjohnson9 weeks ago   
rhncfgorphan  11 weeks ago  
snobolorphan, s4504kr 4 weeks ago   
suck  orphan, s4504kr 4 weeks ago   
system-config-dateorphan, nphilipp1 weeks ago   
system-config-date-docs   orphan, nphilipp1 weeks ago   
system-config-network orphan, nphilipp1 weeks ago   
system-config-nfs orphan, nphilipp1 weeks ago   
system-config-nfs-docsorphan, nphilipp1 weeks ago   
system-config-samba   orphan, nphilipp1 weeks ago   
system-config-samba-docs  orphan, nphilipp1 weeks ago   
system-config-servicesorphan, nphilipp1 weeks ago   
system-config-services-docs   orphan, nphilipp1 weeks ago   
system-config-users   orphan, nphilipp1 weeks ago   
system-config-users-docs

Orphaned Packages in rawhide (2016-09-01)

2016-09-01 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
and   orphan, s4504kr 4 weeks ago   
avra  orphan, musolinoa   5 weeks ago   
cvsclient orphan, java-sig, mizdebsk, 13 weeks ago  
  msrb  
dbmailorphan, bjohnson9 weeks ago   
dwatchorphan, bjohnson9 weeks ago   
firecontrol   orphan, dajt, jwilson   4 weeks ago   
freeradius-client orphan, nmav17 weeks ago  
ghc-editline  orphan, haskell-sig, s4504kr4 weeks ago   
ghc-primesorphan, haskell-sig, s4504kr4 weeks ago   
glusterfs-hadoop  orphan, lalatendu   12 weeks ago  
gnome-password-generator  orphan, rishi   5 weeks ago   
gnustep-back  orphan, s4504kr 4 weeks ago   
gnustep-examples  orphan, s4504kr 4 weeks ago   
gnustep-gui   orphan, s4504kr 4 weeks ago   
gorm  orphan, s4504kr 4 weeks ago   
gresolver orphan, s4504kr 4 weeks ago   
js-jquery-migrate orphan, group::nodejs-sig,  4 weeks ago   
  jamielinux, patches   
kaya  orphan, s4504kr 4 weeks ago   
latex2emf orphan, alexlan 4 weeks ago   
libsieve  orphan, bjohnson9 weeks ago   
libzdborphan, bjohnson, cicku 9 weeks ago   
luma  orphan, s4504kr 4 weeks ago   
maniadriveorphan, jwrdegoede  8 weeks ago   
media-explorerorphan, hadess  0 weeks ago   
msp430-binutils   orphan, rspanton, swhiteho  8 weeks ago   
msp430-gccorphan, rspanton, swhiteho  8 weeks ago   
msp430-libc   orphan, rspanton8 weeks ago   
msp430mcu orphan, rspanton8 weeks ago   
mspdebug  orphan, rspanton8 weeks ago   
netmonitororphan, fab, tuxbrewr   6 weeks ago   
open-cobolorphan, s4504kr 4 weeks ago   
openlmi-storage   orphan, agk, jsafrane,  17 weeks ago  
  jsynacek, rnovacek
phpMemcachedAdmin orphan  10 weeks ago  
picprog   orphan, musolinoa   5 weeks ago   
polipoorphan, bjohnson, jcp   9 weeks ago   
powerman  orphan, tuxbrewr28 weeks ago  
psgml orphan, alexlan 4 weeks ago   
pypop orphan, alexlan 4 weeks ago   
python-pifpaf orphan, pkilambi0 weeks ago   
queuegraphorphan, bjohnson9 weeks ago   
rhncfgorphan  11 weeks ago  
snobolorphan, s4504kr 4 weeks ago   
suck  orphan, s4504kr 4 weeks ago   
system-config-dateorphan, nphilipp1 weeks ago   
system-config-date-docs   orphan, nphilipp1 weeks ago   
system-config-network orphan, nphilipp1 weeks ago   
system-config-nfs orphan, nphilipp1 weeks ago   
system-config-nfs-docsorphan, nphilipp1 weeks ago   
system-config-samba   orphan, nphilipp1 weeks ago   
system-config-samba-docs  orphan, nphilipp1 weeks ago   
system-config-servicesorphan, nphilipp1 weeks ago   
system-config-services-docs   orphan, nphilipp1 weeks ago   
system-config-users

Re: My experiences with KillUserProcesses=yes on F24

2016-09-01 Thread Matthew Miller 
On Thu, Sep 01, 2016 at 04:13:13AM -0400, Nico Kadel-Garcia wrote:
> Agreed. The acceptance of the feature without any logging, whatsoever,
> of what processes it killed and when shocked me. It's the sort of

But note that we _didn't accept the feature without any logging. And
see https://bugzilla.redhat.com/show_bug.cgi?id=1357426#c3:

 Zbigniew Jędrzejewski-Szmek 2016-07-26 16:38:40 EDT

 Systemd-231 was compiled in rawhide today, with the first bit of
 implementation for this change: logging of left-over processes
 killed with SIGKILL/SIGABRT at notice level.

 I'm still working on the other parts.


-- 
Matthew Miller

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

Re: ejabberd, pam, and setuid root

2016-09-01 Thread Stephen Gallagher 
On 09/01/2016 01:31 AM, Randy Barlow wrote:
> Hello my fellow Fedora friends!
> 
> It's 01:00 in my local time and perhaps I should be resting instead of
> trying to figure out chicken-and-egg problems at such a time, but my
> tired mind is on the fence about the solution to one of my tickets and
> I would love the input of others:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1371984
> 
> Let's just say that daemon package A creates user/group A and depends
> on library B. One of library B's binaries needs to be installed setuid
> root because it is for PAM authentication, but I'd rather install the
> binary 4750 or 4700 than 4755. To do this, I can only think of four
> solutions:
> 
> 0) library B installs with 4700, and daemon package A sets a facl on
> the binary to allow user A to execute it. This seems pretty cool, but
> also weird to me since it seems odd for a package to modify a file from
> another package. Additionally, it seems like future updates to library
> B might disrupt the facls that were set by daemon package A until the
> next time it was installed/updated. That sounds right anyway, and if it
> is right I think this option is a no-go. Simple tests with the install
> utility on my fs did obliterate facls when new files were installed
> over existing files. A crazy workaround for this problem might be to
> detect whether the facls are present before the upgrade with %pre, and
> restore them in %post.
> 
> 1) library B creates group A (even though the library isn't necessarily
> only for daemon package A who is the only package to create this
> user/group at this time), and then sets its binary to 4750, owned by
> group A. This one is a little easier than the first option, since I'd
> only have to make an update to library B rather than both A and B. The
> only thing is that it seems kind of weird for library B to be creating
> a group called A, when library B is theoretically generally useful on
> its own and theoretically could have other packages that pull it in in
> the future. It would be weird for group A to exist if package A were
> not installed I think. Fortunately, it wouldn't need to create user A
> as well, only the group.
> 
> 2) We could leave the problem up to documentation, instructing users to
> set the facls or group ownership. However, this will suffer from the
> same update problem that the first solution suffers from, and the user
> will need to reset the facls whenever this package were updated.
> 
> 3) We could rely on an SELinux policy to ensure that only ejabberd can
> execute this binary. I don't like this for two reasons: users who
> disable SELinux wouldn't have the fallback regular Unix permissions as
> the second layer of defense. Secondly, unconfined users would still be
> able to run the binary. If there were ever security issues found in the
> binary itself, neither of these situations would be ideal.
> 
> Option #1 seems to have the fewest technical concerns, so I lean in
> that direction. Hopefully sleeping will get my mind to its peak
> efficiency and I'll see some obvious solution in the morning, but I'd
> love to hear what others think. Is there precedent for this problem? Do
> you have any other options that I haven't thought of? Thanks for any
> input you can offer!
> 

Does ejabberd in Fedora need to use local authentication in all cases (default
configuration), or is this something that is configured by the user after
installation?

If the latter, one thing you could do is avoid needing to give epam privileges
at all and have it use pam_sss.so instead of pam_unix.so and then set up SSSD
with the proxy provider like:


== sssd.conf ==

[sssd]
services = nss, pam
config_file_version = 2
domains = ejabberd


[nss]


[pam]


[domain/ejabberd]

id_provider = proxy
proxy_lib_name = files

auth_provider = proxy
proxy_pam_target = ejabberd


Then you configure /etc/pam.d/ejabberd to use pam_unix.so

SSSD is already a privileged process, so it will perform the authentication on
your behalf and forward the result back to epam.




In the future (hopefully F26...) we're going to be making SSSD processing of
local users a default for Fedora[1]. So when that happens, the manual SSSD
configuration will go away and you should be able to just always trust that
pam_sss.so will return proper information.


[1] https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider



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

Python-cvss licence change

2016-09-01 Thread P J P 
Hello,

  -> https://github.com/skontar/cvss
  -> https://admin.fedoraproject.org/pkgdb/package/rpms/python-cvss/
  -> https://www.first.org/cvss/calculator/3.0

Recently I packaged the cvss Python modules for computing
Common Vulnerability Scoring System(CVSS) rating for security issues.
It contains CVSS v2 and v3 computation utilities and interactive
calculator compatible with both Python v2 and v3.


Its licence has been changed from GPLv3+ to LGPLv3+.
  -> https://github.com/skontar/cvss/issues/6



Thank you.

---
  -P J P
http://feedmug.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: My experiences with KillUserProcesses=yes on F24

2016-09-01 Thread Nico Kadel-Garcia 
On Wed, Aug 31, 2016 at 10:25 AM, Jason L Tibbitts III
 wrote:
> After reading (some of) the "discussion" about systemd-logind's
> KillUserProcesses setting, I decided that I'd like to try enabling it
> and see how it works and how I can make it useful in my environment.
> Sorry, it's long, but I though folks might want to know.

Thanks for the thoughtful work.

> Now at each boot, no users are set to linger and no user managers will
> be started until login.  The wrapper scripts will re-enable that as
> necessary so this doesn't hurt anything.

Wrapper scripts. *Yech*.

To me, it looks like systemd is activating a universal policy which
you, and others, need more thoughtful and tunable handling for.
Attempting to tune it by outsmarting systemd's default behavior looks
expensive and unstable.

> Conclusion: I can make this work, mostly, unless someones user manager
> happens to die.  But really, this is all an unpleasant hack,
> necessitated by a mismatch between systemd's design and what I'm trying
> to accomplish.  And I don't think that what I'm trying to accomplish is
> particularly unreasonable.

Agreed. The acceptance of the feature without any logging, whatsoever,
of what processes it killed and when shocked me. It's the sort of
breakage of working, stable tools in the name of "resource management"
that gets people fired..

> What I wish for is for some "property", let's call it "persist" to be
> "attached" to a scope in some way (presumably a flag to systemd-run)
> which does nothing other than to indicate that the scope will continue
> to run after the user's session has terminated.  This wouldn't be a
> persistent user setting.  Nothing would start at boot.  The user manager
> would start up if necessary at login (even if it had previously been
> killed) and persist until all user processes in any scope have exited.

Wouldn't an hourly or nightly cron job reporting such tasks, with an
option to kill them on a group or user based policy basis, be safer if
such a daemon is needed?

> I am perfectly happy with wrappers around programs which indicate that
> something is to persist after logins so my users don't have to learn
> systemd-run.  I don't think systemd itself needs to know or care which
> processes should persist.  I don't care if those wrappers are in the
> base system.  If things like nohup or screen are patched to do this
> automatically, I'm happy with that but it makes no difference to me.

Can the tasks run with cron jobs in your environment? I realize that
Kerberized access to user home directories might prevent working
access to scripts that live in their home directory.

> Hope this is interesting to someone and adds useful content to the
> discussion.

The thoughtful hands-on experience is welcome. It confirms the idea
that in multi-user environment, backgrounded sessions continuing after
logout is a common and effectively used feature worthy of support.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Revew Swap Needed - tpm2-tools

2016-09-01 Thread yunying . sun 
Hi,

My first time packaging: https://bugzilla.redhat.com/show_bug.cgi?id=1369708 

The review request has been created for about 1 week, but no reviews done yet.
Could someone help to review it? Or maybe do a review swap?

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