Orphaning avogadro

[Kevin Kofler]

Hi,

I am hereby orphaning the avogadro package (and am going to hit the
corresponding button in pkgdb after sending this message).

Avogadro is an advanced molecular editor for chemistry. It can be used both as a
standalone application and as a library. The latter is notably used by Kalzium,
the KDE periodic table (which is part of kdeedu), for its molecule viewer.

I originally picked up this package because it is a dependency of Kalzium, which
I was comaintaining at the time. Unfortunately, considering that:
* I never really used the standalone Avogadro application,
* I did not even use the Kalzium molecule viewer enough to be familiar with it,
* I do not even comaintain Kalzium anymore, and
* I do not have time to keep up with new upstream releases of Avogadro,
I have come to the conclusion that I am not the right person to maintain this
package.

The Rawhide package of Avogadro is at version 1.1.1. Upstream has an 1.2.0
release on SourceForge:
https://sourceforge.net/projects/avogadro/files/avogadro/1.2.0/
(The release is unfortunately NOT announced on the avogadro.cc site.) The new
maintainer will likely want to import the new version. However, he/she should
also ensure that Kalzium still keeps working with the updated library. (That is
the issue with this being both an application and a library.)

WARNING: The Avogadro project also has something called "Avogadro2". Kalzium is
NOT compatible with Avogadro2 at this time. I have also been told that the
Avogadro2 standalone application is also still missing features from Avogadro
(1). So it is NOT a good idea to replace Avogadro with Avogadro2. (If you want
Avogadro2 in Fedora, please submit a separate review request for it.) You have
been warned.

Thank you for your understanding,
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity WG

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Modularity WG on 2016-09-27 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting for the Modularity Working Group.

More information available at: [Modularity Working Group wiki 
page](https://fedoraproject.org/wiki/Modularity_Working_Group)

The agenda for the meeting is available at [modularity-wg-agendas 
pad](http://piratepad.nl/modularity-wg-agendas).



Source: https://apps.fedoraproject.org/calendar/meeting/4407/

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

Orphaning vdr-streamdev

[Felix Kaechele]

Hi,

I'm orphaning vdr-streamdev since I no longer use it. There shouldn't be any 
open issues with this one.

Also, this was the package that initially got me sponsored :)

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

Fedora 25 Beta Freeze

[Mohan Boddu]

Hi all,


Today is an important day on the Fedora 25 schedule[1], with two
significant cut-offs.


Today is the Beta freeze[2]. This means that only packages which fix
accepted blocker or freeze exception bugs[3][4] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.


Finally, Today is the '100% code complete deadline' Change
Checkpoint[5], meaning that Fedora 24 Changes must now be code
complete, meaning all the code required to enable to the new change is
finished. The level of code completeness is reflected as tracker bug
state ON_QA. The change does not have to be fully tested by this
deadline'.


Regards


Mohan Boddu


[1] https://fedoraproject.org/wiki/Releases/25/Schedule

[2] https://fedoraproject.org/wiki/Milestone_freezes

[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

[5] https://fedoraproject.org/wiki/Changes/Policy
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning dansguardian

[Felix Kaechele]

Hi there,

I'm orphaning dansguardian. Upstream has been largely dormant and I haven't 
been using it for several years.
The package has some co-maintainers who also haven't been very active.

Feel free to pick-up the package, but bear in mind it needs some fixing.

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

Re: dnf update args and wiki update

[Adam Williamson]

On Tue, 2016-09-27 at 01:54 +0300, Catalin wrote:
> Dear team.
> 
> About dnf -help under I used fc25 .
> I don't see the update argument output of command: dnf --help.
> The dnf  args is in progress ?

Officially the command is 'upgrade', and 'update' is just a 'deprecated
alias'. This is made explicit in 'man dnf':

   Upgrade Command
   dnf [options] upgrade
  Updates each package to the latest version that is both available 
and resolvable.

   Update Command
   dnf [options] update
  Deprecated alias for the Upgrade Command.

The 'dnf --help' output, being shorter, only lists the 'official' name
- 'upgrade' - and doesn't mention 'update'.

> Also https://fedoraproject.org/wiki/DNF_system_upgrade is not updated.
> Most users do not know all the changes and do not have time to dig. We
> should therefore updated with the changes.

What changes? This is not new, and doesn't have anything to do with
'system upgrade', which is a different command. AFAIK there is nothing
wrong with any of the instructions on that page, they apply fully to
current Fedora.

Unless you just mean that the page said 'dnf update' not 'dnf upgrade',
in which case yeah, I guess theoretically it should have said
'upgrade'. But practically speaking I doubt they'll ever be able to
remove the 'deprecated alias' from dnf, since it'll be in about a
bajillion people's scripts (and we're all still used to it from 'yum
update', and anyway 'update' is a much better word than 'upgrade' so
they're just wrong anyway, jeez, c'mon folks). And again, this is not
new, dnf has claimed that update is 'deprecated' since 2012:

https://github.com/rpm-software-management/dnf/commit/91a92b01172ce03ff2cc8836622842c48534d905
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

dnf update args and wiki update

[Catalin]

Dear team.

About dnf -help under I used fc25 .
I don't see the update argument output of command: dnf --help.
The dnf  args is in progress ?

Also https://fedoraproject.org/wiki/DNF_system_upgrade is not updated.
Most users do not know all the changes and do not have time to dig. We
should therefore updated with the changes.

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

Re: A tale of systemd and MaxProcs

[Matthew Miller]

On Mon, Sep 26, 2016 at 03:53:53PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Ack. I run a lot of builds on rawhide, but none of my systems is large
> enough to hit such issues. From my side I'll try to watch out for
> changes in systemd and that change resource or privilege limitations
> that could affect large systems.

Thanks! I really appreciate the extra effort.

-- 
Matthew Miller

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

Re: duplicate package on fresh install

[stan]

On Mon, 26 Sep 2016 11:23:53 -0700
stan  wrote:


> dnf remove $(dnf repoquery --installonly --latest-limit -3 -q)

This is wrong! I copied the wrong line.  The actual command should be

dnf remove $(dnf repoquery --duplicated --latest-limit -1 -q)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

On Mon, 2016-09-26 at 16:23 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Xfce raw-xz armhfp
> Cloud_base raw-xz i386
> Atomic raw-xz x86_64
> 
> Failed openQA tests: 9/102 (x86_64), 2/17 (i386), 1/2 (arm)
> 
> New failures (same test did not fail in 25-20160925.n.0):
> 
> ID: 36378 Test: x86_64 Workstation-live-iso base_update_cli
> URL: https://openqa.fedoraproject.org/tests/36378

So again typing at the console had a problem. I think I might tweak the
test to wait for the system to be idle before running that command, it
may help...

> ID: 36379 Test: x86_64 Workstation-live-iso desktop_update_graphical
> URL: https://openqa.fedoraproject.org/tests/36379

This one is interesting, it seems like GNOME Software really had some
kind of problem refreshing the available updates. I'll have to look at
the logs and see if there's a definite bug to report.

> ID: 36382 Test: x86_64 Workstation-live-iso desktop_notifications_live
> URL: https://openqa.fedoraproject.org/tests/36382

GNOME actually crashed from the live desktop back to GDM while the test
was idling: this test just sits at the desktop for 10 minutes to see if
any notifications show up, during those 10 minutes, the system crashed
back to gdm. Three crash logs show up, for GNOME Shell, gjs and
evolution-alarm-notify. The GNOME Shell crash I filed as:
https://bugzilla.redhat.com/show_bug.cgi?id=1379440

> ID: 36386 Test: i386 Workstation-live-iso install_default
> URL: https://openqa.fedoraproject.org/tests/36386

This one, again, crashed. The install succeeded, the test then proceeds
to boot the installed system and log in as the 'test' user (created
during install) and click through gnome-initial-setup. It crashed back
to GDM from gnome-initial-setup. I'll file the crash.

> ID: 36433 Test: x86_64 universal install_simple_free_space@uefi
> URL: https://openqa.fedoraproject.org/tests/36433

This one's a bit odd, it just flat out failed to go anywhere at all
from the bootloader. Never seen that before and other UEFI tests in the
run (which should not behave differently at the point of just booting
the installer) worked fine, so this is probably just magic pixies.

> ID: 36444 Test: x86_64 universal upgrade_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/36444

This is that same test timing issue I wrote about the other day, I have
a change that should avoid this happening under review ATM.

> ID: 36445 Test: x86_64 universal upgrade_server_64bit
> URL: https://openqa.fedoraproject.org/tests/36445

This is actually kinda the same thing (don't want to bore people with
the details of how our openQA tests decide when they've reached a login
screen) and would also be fixed by my patch. These two tests passed on
staging, which is running my patch.

> ID: 36468 Test: x86_64 universal upgrade_2_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/36468

This test just flat out failed to boot the base image (an F23 KDE
install). Not sure what's up there, might just be one-off magic pixies,
I'll see if the image got regenerated last night or anything.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: duplicate package on fresh install

[stan]

On Mon, 26 Sep 2016 06:07:56 -
Samuel Rakitničan  wrote:


> Reinstall or any other dnf operation except remove doesn't work,
> didn't try --rebuilddb. There are many cases of such broken state on
> forums, but system is usually working fine AFAICT. Is there a way to
> alter rpm database to remove one version of a package without
> altering the system?
 
If you look at  man yum2dnf, it tells you the equivalent commands under
dnf for yum commands.  What you are trying to do is clean dupes.  These
are the appropriate commands for dnf, from that man page.

package-cleanup --dupes  
is now   
dnf repoquery --duplicated
and
package-cleanup --cleandupes  
is now  
dnf remove $(dnf repoquery --installonly --latest-limit -3 -q)

I recall using this dnf command successfully, but it has been a long
time.  Another way of saying, be careful.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Timothy Ward]

HHello

Has there been any testing with libmobiledevice library and especially
the gvfs-afc backend to this be able to connect to an idevice using
nautilus etc. The testing needs to be done on both new IOS 10.0.1
and an older version say 6.3.5 on an older idevice iphone 4. to ensure
compatibility across 

A link to a github respository for libimobledevice and other related
libaries 

https://github.com/libimobiledevice

Have a look at the issues for problems with openssl etc

Regards

Timothy Ward


On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote:
> 
> On So, 2016-09-24 at 00:52 +0100, David Woodhouse wrote:
> > 
> > 
> > On Tue, 2016-09-20 at 11:37 +0200, Tomas Mraz wrote:
> > > 
> > > 
> > > 
> > > Well... we certainly need to port it sooner or later although I
> > > understand that effort will be quite non-trivial.
> > You mean port libp11? That's already working against OpenSSL 1.1,
> > isn't
> > it? We just need to ensure we can ship a version of libp11 — or at
> > least the engine — for both OpenSSL 1.1 and OpenSSL 1.0.2, if
> > we're
> > going to ship them both in parallel.
> 
> Ah, that's a good news. I did not get to try to rebuild it against
> OpenSSL1.1 yet.
> 
> My current plan is to not ship such engine-pkcs11 package. We should
> try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
> compat package for third party binaries without -devel and any extra
> bells and whistles. It would be also temporarily used in Rawhide so
> it
> is installable but for that I think we can live with temporarily
> breaking PKCS#11 uri support.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20160926.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp
Cloud_base raw-xz i386
Atomic raw-xz x86_64

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

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

ID: 36378   Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/36378
ID: 36379   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/36379
ID: 36382   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/36382
ID: 36386   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/36386
ID: 36433   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/36433
ID: 36444   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/36444
ID: 36445   Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/36445
ID: 36468   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/36468

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

ID: 36388   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/36388
ID: 36401   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/36401
ID: 36489   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/36489
ID: 36497   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/36497

Passed openQA tests: 93/102 (x86_64), 15/17 (i386)

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

Fedora Rawhide-20160926.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base raw-xz i386
Atomic raw-xz x86_64

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

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

ID: 36258   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/36258
ID: 36323   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/36323
ID: 36336   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/36336
ID: 36367   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/36367

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

ID: 36266   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/36266
ID: 36267   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/36267
ID: 36280   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/36280
ID: 36357   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/36357
ID: 36358   Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/36358
ID: 36368   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/36368

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

Old soft failures (same test softfailed in Rawhide-20160924.n.0):

ID: 36274   Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/36274

Passed openQA tests: 95/102 (x86_64), 14/17 (i386)

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

Re: A tale of systemd and MaxProcs

[Zbigniew Jędrzejewski-Szmek]

On Sun, Sep 25, 2016 at 01:11:16PM -0600, Kevin Fenzi wrote:
> On Sun, 25 Sep 2016 16:54:45 -
> "Timothy Ward"  wrote:
> 
> > Although I agree with the above then may be a builder should have a
> > rawhide VM running with these updated critical packages if only for
> > testing purposes to expose this type of failure. 
> 
> Sure, as I noted perhaps we should move some of the staging ones to
> branched or rawhide. But thats just the start/easy part. Then someone
> has to watch for failed builds, sort out which ones are caused by
> package error or other packages or whatever and find the few caused by
> the builder state and track them down. 
> 
> So, basically it's this problem x N. I personally don't have many free
> hours a week to devote to this, and I doubt the kernel maintainers do
> either. :) 
> 
> > The other concerns is that the package should have issued some sort
> > of critical error message to the appropriate log before the limit was
> > reached. and then start shutting down or limiting the process's or
> > threads running. Is easy to say but may be a lot harder to actually
> > achieve.
> 
> Yep. Would be nice, not sure how hard it is to do. 
>  
> > Although the change was communicated there needs to be a process that
> > effective communication of these sorts of changes is sent to ensure
> > that it will be picked up by more than just the fedora team leader
> > which already has a fairly big workload.
> 
> Well, the change was communicated only in the NEWS file burried in
> a bunch of other changes. 
> > 
> > It is a corner case at the extreme end as most testers probably would
> > not have the hardware or knowledge to test effectively. Supplying
> > info on how to test effectively may be a solution but will require
> > someone to do it.
> > 
> > But I feel Kevin's and others involved frustration and the amount of
> > time that trouble-shooting this would have taken.
> 
> Yeah, I just want to try and improve things so perhaps it doesn't
> happen again/as much/as soon. 

Ack. I run a lot of builds on rawhide, but none of my systems is large
enough to hit such issues. From my side I'll try to watch out for
changes in systemd and that change resource or privilege limitations
that could affect large systems.

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

Re: A tale of systemd and MaxProcs

[Matthew Miller]

On Sat, Sep 24, 2016 at 06:34:36PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > far-reaching infrastructure packages (systemd, glibc, kernel, whatever)
> > that any new restrictions or constraints should be disabled by default
> > in Fedora, regardless of upstream defaults, until we're able to have a
> > conversation — here, in the edition WGs, and/or in FESCo, as
> > appropriate for the particular change.
> Every change of this type is a judgement call. Most of such changes
> don't cause any issues and if FESCo wanted to review every one it
> would be swamped with useless work (apart from systemd, at least
> selinux introduce new restrictions every once in a while).

I hope that this kind of change is not actually intended to be so
frequent that "swamped" would apply!

(And I agree that the same thing should apply to selinux changes which
apply globally. Per-service restrictions should be coordinated with the
maintainers of that particular service and raised to FESCo and WGs as
appropriate.)



-- 
Matthew Miller

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

/sbin/nologin in /etc/shells

[Jakub Svoboda]

Hi,

nologin is listed in /etc/shells since 2002 [1].

This is in conflict with:

man 5 shells
DESCRIPTION
   /etc/shells  is  a text file which contains the full pathnames of
valid
   login shells.

man 8 nologin
DESCRIPTION
   nologin  displays  a message that an account is not available and
exits
   non-zero.  It is intended as a replacement shell field  to  deny
login
   access to an account.
NOTES
   nologin is a per-account way to disable login (usually used for
system
   accounts  like  http  or  ftp).

man 1 su
OPTIONS
   -s, --shell=shell
  Run the specified shell instead of the default.
  [snip]
  If  the  target  user has a restricted shell (i.e. not listed
in
  /etc/shells), the --shell option and the SHELL environment
vari‐
  ables are ignored unless the calling user is root.

Actual behavior and man pages are consistent for su and nologin and their
behavior is affected indirectly by /etc/shells. The inconsistency lies in
/etc/shells containing nologin and man 5 shells semantically telling the
opposite.

Let's fix it.

The stated reason for including nologin in shells is "so that 'chsh' and
other tools will allow its use without manual edit of /etc/passwd" [1].
This is argument is inaccurate. Tests on RHEL 6.0 and fc24 showed that the
man page for chsh is correct - when /sbin/nologin is not in /etc/shells,
root can successfully run chsh -s /sbin/nologin username. It prints a
warning but it does change the default shell to /sbin/nologin. man 1 chsh:

VALID SHELLS
   chsh will accept the full pathname of any executable file on  the
sys‐
   tem.   However,  it  will issue a warning if the shell is not listed
in
   the /etc/shells file.  On the other hand, it  can  also  be
configured
   such  that  it  will only accept shells listed in this file, unless
you
   are root.


Removing /sbin/nologin from /etc/shells would prohibit a regular user to
set /sbin/nologin as the default shell for themselves - an action that
makes little sense.

/sbin/nologin being in /etc/shells poses security and logical problems:

- su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the
default shell) succeeds with /bin/bash if auth is successful [2], even
though man 1 su, man 8 nologin, and man 5 shells suggest that such a user
is a restricted user and logging in with an alternate specified shell
should be forbidden.

- Red Hat Enterprise Linux 7 Security Guide advises [3] that /sbin/nologin
should be used to prevent direct login to an account - the root account in
this example. Presumably, this should be prevented in the case where the
attacker has valid login credentials for the account. In that very case,
however, the attacker can use an ordinary account to run su -s /bin/bash -
root because the protection for this very attack present in su is rendered
useless by /sbin/nologin being listed in /etc/shells.

- selinux has a workaround for /sbin/nologin -
https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00893.html

- gdm has a workaround for /sbin/nologin -
https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00894.html

- Debian doesn't list nologin in /etc/shells. An opinion from a Debian
developer [4]: "The point of having a shell that's not in /etc/shells isn't
that you can't use it to log in, but that it's not a normal shell and that
users with that shell set can't change it to something else. Adding nologin
to /etc/shells would be very likely to open security vulnerabilities, and I
will not do it."

It seems as though /sbin/nologin is listed in /etc/shells as a workaround
to some issues without even documenting it in the man pages. These issues
are not important enough for those distributions and OSes that don't list
/sbin/nologin in /etc/shells. Maybe fedora should be on the same boat.

The rabbit hole of the past bugs and discussions about this starts here [5].

This is a bug that either lies solely in the setup package (which lists
/sbin/nologin in the /etc/shells file) or it is an inter-package bug where
multiple packages that are correct on their own exhibit an incorrect
behavior together. In any case, it is clear *something* is wrong here.

What can we do to fix this issue or to at least to make man pages
consistent with the actual behavior? Are there serious reasons to continue
listing /sbin/nologin in /etc/shells?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=53963
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c0
[3]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Controlling_Root_Access.html#sec-Disallowing_Root_Access
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419132#32
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c1

Thanks,

--
Jakub Svoboda / Red Hat Product Security
___
devel mailing list -- devel@lists.fedoraproject.org
To 

Reviews Weekly

[nobody]

Start Date: 2016-09-19 10:08:02.157981
End Date: 2016-09-26 10:08:02.157981

gil cattaneo : 5

https://bugzilla.redhat.com/show_bug.cgi?id=1379093 
python-pickleshare
https://bugzilla.redhat.com/show_bug.cgi?id=1378021 jetty-alpn
https://bugzilla.redhat.com/show_bug.cgi?id=1379090 python-qtconsole
https://bugzilla.redhat.com/show_bug.cgi?id=1378971 f25-backgrounds
https://bugzilla.redhat.com/show_bug.cgi?id=1378077 
jetty-test-helper


Jitka Plesnikova : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1377228 
perl-Test2-Plugin-NoWarnings
https://bugzilla.redhat.com/show_bug.cgi?id=1377252 
perl-Params-ValidationCompiler


Paul Wouters : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1377876 jose
https://bugzilla.redhat.com/show_bug.cgi?id=1377877 luksmeta


Tim Flink : 2

https://bugzilla.redhat.com/show_bug.cgi?id=1376869 gap-pkg-lpres
https://bugzilla.redhat.com/show_bug.cgi?id=1373666 hddfancontrol


Alexander Kurtakov : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1369224 
jackson-modules-base


Ben Rosser : 1

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


Charalampos Stratakis : 1

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


Christoph Junghans : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1290337 ed25519-java


Fl@sh : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1378445 kf5-kirigami


Igor Gnatenko : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1377733 
systemd-bootchart


Jerry James : 1

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


Luya Tshimbalanga : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1290339 curve25519-java


Mukundan Ragavan : 1

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


Nathaniel McCallum : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1378160 
jitterentropy-rngd


Neal Gompa : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1375926 python-nose2


Parag AN(पराग) : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1377812 
python-sphinxcontrib-blockdiag


Petr Menšík : 1

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


Petr Pisar : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1378014 perl-IO-FDPass


Randy Barlow : 1

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


Sandro Mani : 1

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


Simone Caronni : 1

https://bugzilla.redhat.com/show_bug.cgi?id=1374781 
python-sphinxcontrib-autoprogram



Completed Review Requests: 28
This report was generated by bz-review-report.py.
The original source is available at: 
https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


2 packages were orphaned

oflb-riordonfancy-fonts [master, f25, f24] was orphaned by till
 A stylized font
 https://admin.fedoraproject.org/pkgdb/package/oflb-riordonfancy-fonts
python-wheel [el6] was orphaned by stardust85
 A built-package format for Python
 https://admin.fedoraproject.org/pkgdb/package/python-wheel

9 packages were retired

docker-distribution [epel7] was retired by lsm5
 Docker toolset to pack, ship, store, and deliver content
 https://admin.fedoraproject.org/pkgdb/package/docker-distribution
instack [master, f25] was retired by slagle
 OpenStack installation tool for diskimage-builder style elements
 https://admin.fedoraproject.org/pkgdb/package/instack
jackson-datatype-guava [f25] was retired by gil
 Add-on module for Jackson JSON processor which handles Guava data-types
 https://admin.fedoraproject.org/pkgdb/package/jackson-datatype-guava
jackson-module-afterburner [master, f25] was retired by gil
 Jackson module that uses byte-code generation to further speed up data 
binding
 https://admin.fedoraproject.org/pkgdb/package/jackson-module-afterburner
jackson-module-mrbean [master, f25] was retired by gil
 An extension that implements support for POJO type materialization
 https://admin.fedoraproject.org/pkgdb/package/jackson-module-mrbean
kf5-akonadi [f25] was retired by dvratil
 The Akonadi client libraries
 https://admin.fedoraproject.org/pkgdb/package/kf5-akonadi
os-cloud-config [master, f25] was retired by slagle
 Configuration for OpenStack clouds
 https://admin.fedoraproject.org/pkgdb/package/os-cloud-config
perl-Data-Alias [f25] was retired by pghmcfc
 Comprehensive set of aliasing operations
 https://admin.fedoraproject.org/pkgdb/package/perl-Data-Alias
rubygem-audited-activerecord [master, f25] was retired by vondruch
 Log all changes to your ActiveRecord models
 https://admin.fedoraproject.org/pkgdb/package/rubygem-audited-activerecord

2 packages unorphaned
-
maniadrive [f25] was unorphaned by sergiomb
 3D stunt driving game
 https://admin.fedoraproject.org/pkgdb/package/maniadrive
xcf-pixbuf-loader [f23, master, f25, f24] was unorphaned by yselkowitz
 XCF (GIMP) image loader for GTK+ applications
 https://admin.fedoraproject.org/pkgdb/package/xcf-pixbuf-loader

0 packages were unretired


2 packages were given

mongodb [f23, master, f25, f24, epel7, el5] was given by hhorak to mskalick
 High-performance, schema-free document-oriented database
 https://admin.fedoraproject.org/pkgdb/package/mongodb
rubygem-jgrep [f23, master, el6, epel7] was given by lkundrak to domcleal
 Filter JSON documents with a simple logical language
 https://admin.fedoraproject.org/pkgdb/package/rubygem-jgrep

0 packages had new branches



Sources: https://github.com/pypingou/fedora-owner-change
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [critpath] bash - Security fix for CVE-2016-0634 ready for testing.

[David Kaspar [Dee'Kej]]

Hello Matthes,

thank you for the heads up, I was fixing the issue because I'm "backup"
maintainer of bash, and the main contact (Siteshwar) was not avaiable. I've
put him in CC, so if he wishes he can create the test plan. Unfortunately,
I personally do not have time for it now. :(

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .

On Thu, Sep 22, 2016 at 6:24 PM, Matthew Miller 
wrote:

> On Thu, Sep 22, 2016 at 09:21:22AM -, David Kaspar wrote:
> > Hello guys,
> >
> > I backported the upstream patch for CVE-2016-0634 [1] into bash for
> Rawhide, F25, F24, and F23. If you have some spare time, feel free to help
> verifying the issue / testing the stability of bash [2][3][4].
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1377614
> > [2] https://bodhi.fedoraproject.org/updates/bash-4.3.43-3.fc25
> > [3] https://bodhi.fedoraproject.org/updates/bash-4.3.42-6.fc24
> > [4] https://bodhi.fedoraproject.org/updates/bash-4.3.42-4.fc23
>
> Hi David! Bash is relatively important. It'd be awesome to have a test
> plan for this. See
> https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation if
> you'd like to write one... or, if you have a series of basic things
> you think people should test, maybe you could just list those here or
> on the test list and someone else will be inspired to help. :)
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Dominik 'Rathann' Mierzejewski]

On Thursday, 22 September 2016 at 15:41, Dominik 'Rathann' Mierzejewski wrote:
> Hello,
> I've just pushed (but not built) python-matplotlib-2.0.0b4 to rawhide.
> I'll be attempting to rebuild all the affected packages locally to
> test if they're compatible. In the meantime, feel free to git pull
> and build locally for your own testing.
> 
> $ dnf repoquery --srpm --releasever=rawhide --whatrequires python-matplotlib 
> --alldeps

Most packages rebuilt locally without errors, so
python-matplotlib-2.0.0-0.1.b4.fc26 is currently building in koji.

Here are the problematic ones:

> APLpy

Rebuild failed with (python3):
AttributeError: module 'distutils.config' has no attribute 'ConfigParser'

> python-igor

Looks like it got built with python3 and fails %check grepping for
python2.

> python-nipy

Missing (Build)dependency on python2-functools32. Also, 3 genuine test
failures:
ValueError: object arrays are not supported

> python-pebl

mv: 'docs/src/install.rst' and 'INSTALL.txt' are the same file

> python-pyriemann

Missing (Build)dependency on python2-functools32.

> python-seaborn

Missing (Build)dependency on python2-functools32.

I'll attempt to fix the above and rebuild over the coming days.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Mon, 2016-09-26 at 12:29 +0200, Tomas Mraz wrote:
> My current plan is to just switch and rebuild fixing the FTBFS during
> that. I want to persuade some of my colleagues to help me with that
> (and of course community help is also welcome).
> 
> Also we will be sharing the work with other downstream distributions
> here:
> https://github.com/patch-exchange/openssl-1.1-transition

Hm... might I suggest that every patch in there be tagged with an
'upstream status', and a link to the mailing list archive or ticket or
pull request where it was submitted upstream?

For which, the patches would actually need to be *acceptable* upstream.
At a quick glance, it looks like the wpa_supplicant one at least would
not be, because I think it'll break the build with OpenSSL <= 1.0.2.

> > We'd probably want to *stop* using /usr/include/openssl in that case;
> > the pkg-config files can set the include path, so everyone should cope
> > with that, and we don't want them accidentally picking up the *wrong*
> > header files.
> 
> I currently did not want to do that as some dependent packages might
> not use pkg-config and would have to be patched to use the different
> include directory anyway.

Some might not but most would, and all SHOULD. If we did ship parallel
-devel packages, then I really think we'd need to move them. So then we
get a nice clean failure and not a horrid mismatch of headers which
might lead to more subtle bugs.

But if we don't want to ship parallel -devel packages, that's fine.

> > But then again what happens when we end up with both versions of
> > OpenSSL loaded into a process? Even if we've converted everything in
> > Fedora and it's only third-party stuff that still uses a compat-1.0.2
> > package... if it loads other Fedora libraries which are using 1.1, we
> > end up with both. Isn't that going to end in tears? Is it even viable
> > to ship both at once? Or do we fix that with symbol versioning?
> 
> I've tested some scenarios - particularly running Apache with mod_ssl
> and libkrb5 linked to 1.0.2 and mod_auth_gssapi linked to 1.1.0 worked
> fine. So hopefully the symbol versioning works and allows this.

Great. I've seen occasional problems but I've been doing my own local
builds of random versions of OpenSSL, without the --default-symver that
our package adds.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On Po, 2016-09-26 at 09:35 +0100, David Woodhouse wrote:
> On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote:
> > 
> > My current plan is to not ship such engine-pkcs11 package. We
> > should
> > try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
> > compat package for third party binaries without -devel and any
> > extra
> > bells and whistles. It would be also temporarily used in Rawhide so
> > it
> > is installable but for that I think we can live with temporarily
> > breaking PKCS#11 uri support.
> If we move everything to 1.1 and nothing that *currently* supports
> PKCS#11 ends up broken in F26 because it's left behind on 1.0.2, then
> that works.
> 
> Although building the engine alone for 1.0.2, without shipping a
> matching version of libp11 alongside it, would also be feasible.
> 
> As for shipping without -devel... do we have a flag day in rawhide
> and
> just switch, either fixing the resulting FTBFS issues afterwards, or
> having had the fixes waiting in the wings to push to all the affected
> packages?

My current plan is to just switch and rebuild fixing the FTBFS during
that. I want to persuade some of my colleagues to help me with that
(and of course community help is also welcome).

Also we will be sharing the work with other downstream distributions
here:
https://github.com/patch-exchange/openssl-1.1-transition


> I was imagining that we'd deploy the new OpenSSL 1.1 package but
> still
> allow other packages to build against 1.0.2 if they need to, at least
> for a little while — even if we plan to kill the 1.0.2 -devel package
> before we actually ship F26?
> 
> We'd probably want to *stop* using /usr/include/openssl in that case;
> the pkg-config files can set the include path, so everyone should
> cope
> with that, and we don't want them accidentally picking up the *wrong*
> header files.

I currently did not want to do that as some dependent packages might
not use pkg-config and would have to be patched to use the different
include directory anyway.

> But then again what happens when we end up with both versions of
> OpenSSL loaded into a process? Even if we've converted everything in
> Fedora and it's only third-party stuff that still uses a compat-1.0.2
> package... if it loads other Fedora libraries which are using 1.1, we
> end up with both. Isn't that going to end in tears? Is it even viable
> to ship both at once? Or do we fix that with symbol versioning?

I've tested some scenarios - particularly running Apache with mod_ssl
and libkrb5 linked to 1.0.2 and mod_auth_gssapi linked to 1.1.0 worked
fine. So hopefully the symbol versioning works and allows this.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

attempting ton contact unresponsive maintainer - strobert

[James Hogarth]

Has anyone heard from Stephen Roberts (strobert) recently?


This bug has gone unresponded to and the rsnapshot package hasn't been
updated to the recent releases or had upstream pointed to its new
home:

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

Mailing the development list as per:

https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

I'll file the FESCO bug in a week if we can't get hold of him.

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

Re: F26 System Wide Change: OpenSSL 1.1.0

[David Woodhouse]

On Mon, 2016-09-26 at 10:09 +0200, Tomas Mraz wrote:
> My current plan is to not ship such engine-pkcs11 package. We should
> try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
> compat package for third party binaries without -devel and any extra
> bells and whistles. It would be also temporarily used in Rawhide so it
> is installable but for that I think we can live with temporarily
> breaking PKCS#11 uri support.

If we move everything to 1.1 and nothing that *currently* supports
PKCS#11 ends up broken in F26 because it's left behind on 1.0.2, then
that works.

Although building the engine alone for 1.0.2, without shipping a
matching version of libp11 alongside it, would also be feasible.

As for shipping without -devel... do we have a flag day in rawhide and
just switch, either fixing the resulting FTBFS issues afterwards, or
having had the fixes waiting in the wings to push to all the affected
packages?

I was imagining that we'd deploy the new OpenSSL 1.1 package but still
allow other packages to build against 1.0.2 if they need to, at least
for a little while — even if we plan to kill the 1.0.2 -devel package
before we actually ship F26?

We'd probably want to *stop* using /usr/include/openssl in that case;
the pkg-config files can set the include path, so everyone should cope
with that, and we don't want them accidentally picking up the *wrong*
header files.

But then again what happens when we end up with both versions of
OpenSSL loaded into a process? Even if we've converted everything in
Fedora and it's only third-party stuff that still uses a compat-1.0.2
package... if it loads other Fedora libraries which are using 1.1, we
end up with both. Isn't that going to end in tears? Is it even viable
to ship both at once? Or do we fix that with symbol versioning?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: OpenSSL 1.1.0

[Tomas Mraz]

On So, 2016-09-24 at 00:52 +0100, David Woodhouse wrote:
> On Tue, 2016-09-20 at 11:37 +0200, Tomas Mraz wrote:
> > 
> > Well... we certainly need to port it sooner or later although I
> > understand that effort will be quite non-trivial.
> You mean port libp11? That's already working against OpenSSL 1.1,
> isn't
> it? We just need to ensure we can ship a version of libp11 — or at
> least the engine — for both OpenSSL 1.1 and OpenSSL 1.0.2, if we're
> going to ship them both in parallel.

Ah, that's a good news. I did not get to try to rebuild it against
OpenSSL1.1 yet.

My current plan is to not ship such engine-pkcs11 package. We should
try to move everything to OpenSSL 1.1 and ship the 1.0.2 only as a
compat package for third party binaries without -devel and any extra
bells and whistles. It would be also temporarily used in Rawhide so it
is installable but for that I think we can live with temporarily
breaking PKCS#11 uri support.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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