date:20180307

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PPIx-Regexp-0.056-1.fc
   ||29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-08 02:25:10



--- Comment #1 from Petr Pisar  ---
Substantial changes in the code. Suitable for Rawhide only.

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

Re: libqalculate soname change

On Wed, 2018-03-07 at 20:46 -0500, Mukundan Ragavan wrote:
> I will be updating libqalculate to the latest upstream release (v2.2.1).
> This involves a soname change. The following packages are affected.
> 
> plasma-workspace
> step
> cantor
> qalculate-kde
> 
> I have built all these packages for rawhide and F28 in a COPR [0]. Since
> we have the same versions on both rawhide and F28, I hope to push
> libqalculate to both and rebuild all these packages.
> 
> If building for F28 is not preferred, please let me know. I anticipate
> building everything by Friday (2018-03-08) and will proceed unless I
> hear otherwise.

Thanks for the notification.

Note F28 is currently in freeze for Beta; this is a long freeze, and
honestly, might get longer, given the current state of things. So I'm
not sure whether it'd be optimal to have this committed and built for
F28, but not able to go stable due to the freeze. Might be better to
wait till after Beta, *or* get a freeze exception. Is there any
significant benefit for us in the new libqalculate, which would justify
a freeze exception?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8 ABI change on x86_64

On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> Recently we discovered a serious bug in the compiler whereby we miscompiled
> several packages.  The problem started with my ABI-changing patch which 
> changed
> how empty classes are passed, as per the x86_64 psABI (so this bug only 
> affects
> x86_64).  The problem could arise when the code contained empty class 
> templates.  
> For more info see .
> 
> I did another mass rebuild with a specially-tweaked gcc in order to find out
> which packages need to be rebuild with patched gcc-8.0.1-0.16.  Sorry about
> this.
> 
> This is the list:

I've fired rebuilds of every package on the list, for F28 and Rawhide.
I'll investigate any failures and put together an F28 update tomorrow.
-- 
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: Spring cleaning my golang packages (orphaning now unused stuff)

2018-03-07 Thread Athos Ribeiro

On Wed, Mar 07, 2018 at 07:29:35PM +, Fabio Valentini wrote:
[snip...]
> 
> Also, Athos, if you're reading this, I see that hugo is also using my
> package golang-github-gobwas-glob - I can make you a co-maintainer if you
> want.

Yes, please :)

Thank you, Fabio

-- 
Athos Ribeiro

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

Re: compilation of lollypop fails on mock build server

2018-03-07 Thread Jerry James

On Wed, Mar 7, 2018 at 8:42 AM, Martin Gansser  wrote:
> the --nonet  option is already used in the spec file:
> https://src.fedoraproject.org/cgit/rpms/lollypop.git/tree/lollypop.spec

Yes, but look at your build log.  That option doesn't appear:

--- command ---
/usr/bin/appstream-util validate-relax
/builddir/build/BUILD/lollypop-0.9.400.1/noarch-redhat-linux-gnu/data/org.gnome.Lollypop.appdata.xml

That's because your invocation of appstream-util never happened; this
is due to the package itself defining a test that invokes
appstream-util.  See data/meson.build.  It invokes
desktop-file-validate as well, so everything except %meson_test in
%check is redundant.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libqalculate soname change

2018-03-07 Thread Mukundan Ragavan


I will be updating libqalculate to the latest upstream release (v2.2.1).
This involves a soname change. The following packages are affected.

plasma-workspace
step
cantor
qalculate-kde

I have built all these packages for rawhide and F28 in a COPR [0]. Since
we have the same versions on both rawhide and F28, I hope to push
libqalculate to both and rebuild all these packages.

If building for F28 is not preferred, please let me know. I anticipate
building everything by Friday (2018-03-08) and will proceed unless I
hear otherwise.

Mukundan.


[0] https://copr.fedorainfracloud.org/coprs/nonamedotc/libqalculate/builds/



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

[Bug 1552967] New: perl-PPIx-Regexp-0.056 is available

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

Bug ID: 1552967
   Summary: perl-PPIx-Regexp-0.056 is available
   Product: Fedora
   Version: rawhide
 Component: perl-PPIx-Regexp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.056
Current version/release in rawhide: 0.055-1.fc28
URL: http://search.cpan.org/dist/PPIx-Regexp/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3288/

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

[Bug 1552960] New: perl-Log-Dispatch-FileRotate-1.35 is available

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

Bug ID: 1552960
   Summary: perl-Log-Dispatch-FileRotate-1.35 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Log-Dispatch-FileRotate
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org,
tcall...@redhat.com



Latest upstream release: 1.35
Current version/release in rawhide: 1.34-2.fc28
URL: http://search.cpan.org/dist/Log-Dispatch-FileRotate/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/12212/

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

[389-devel] Use of int types in the code base,

2018-03-07 Thread William Brown

Hi there,

http://www.port389.org/docs/389ds/development/coding-style.html#types

In a few reviews I still see this sometimes.

It's pretty important that we keep moving our quality standard higher,
and having known type sizes is important to this. Types like int and
long are unknown sizes until you compile it depending on platform.

As a result, it's really important we use the intX_t and uintX_t types
so we have guarantees of our values. I would encourage the use of
int64_t and uint64_t, because while they are "larger", it's
significantly faster for a modern 64bit system to process these values
than their 32bit counterparts.

Another note is that arrays index by size_t, not 'int', so we should
always keep this in mind.

Finally, because we are using c99 now, this means we should avoid:

size_t i = 0;

for (i = 0; i < cond; i++) {
...
}

When we really should scope our values. Scoping is good because it
limits possibility of data corruption to flow and other mistakes such
as re-use of values. This means:

for (size_t i = 0; i < cond; i++) {
...
}

Thanks! 

-- 
Thanks,

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

[389-devel] please review: Ticket 49596 - repl-monitor.pl fails to find RUV entry

2018-03-07 Thread Mark Reynolds

master branch only

https://pagure.io/389-ds-base/issue/49596

https://pagure.io/389-ds-base/issue/raw/files/f6a2c1a621d1612d23e113bb064d63f5ee86a6ebf7818515bd2c4ac9b25c3e9c-0001-Ticket-49596-repl-monitor.pl-fails-to-find-db-tombst.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: GCC 8 ABI change on x86_64

2018-03-07 Thread Jakub Jelinek

On Wed, Mar 07, 2018 at 12:27:34PM -0800, Adam Williamson wrote:
> On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> > Recently we discovered a serious bug in the compiler whereby we miscompiled
> > several packages.  The problem started with my ABI-changing patch which 
> > changed
> > how empty classes are passed, as per the x86_64 psABI (so this bug only 
> > affects
> > x86_64).  The problem could arise when the code contained empty class 
> > templates.  
> > For more info see .
> > 
> > I did another mass rebuild with a specially-tweaked gcc in order to find out
> > which packages need to be rebuild with patched gcc-8.0.1-0.16.  Sorry about
> > this.
> > 
> > This is the list:
> 
> 
> 
> >   xautolock-2.2-18.fc24.src.rpm
> 
> This seems like an odd entry. How can a package last built for F24
> possibly be affected?

Just guessing; Marek has rebuilt all the non-noarch src.rpm for rawhide
and the package build diagnosed the ABI incompatibility.  Perhaps the build
normally only fails later than where the ABI issue was spotted.

The instrumented GCC had a new option to compile using the previous
(8.0.1-0.15 and earlier) wrong behavior and compiled everything twice,
comparing dumps on what would be produced between the two.

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

Re: GCC 8 ABI change on x86_64

On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> Recently we discovered a serious bug in the compiler whereby we miscompiled
> several packages.  The problem started with my ABI-changing patch which 
> changed
> how empty classes are passed, as per the x86_64 psABI (so this bug only 
> affects
> x86_64).  The problem could arise when the code contained empty class 
> templates.  
> For more info see .
> 
> I did another mass rebuild with a specially-tweaked gcc in order to find out
> which packages need to be rebuild with patched gcc-8.0.1-0.16.  Sorry about
> this.
> 
> This is the list:



>   xautolock-2.2-18.fc24.src.rpm

This seems like an odd entry. How can a package last built for F24
possibly be affected?

Other than that...this is a bit awkward as F28 is now in freeze. I will
try and rebuild all the affected packages and submit an update and an
FE bug.
-- 
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: Critpath karma

On Wed, 2018-03-07 at 14:43 -0500, Randy Barlow wrote:
> On 03/06/2018 07:20 PM, Adam Williamson wrote:
> > Removing it is one choice, sure. Looking at those ideas again and
> > deciding if we want to actually go ahead and implement any of them is
> > another choice.
> 
> Cool thanks for the history there. I actually think those ideas sound
> pretty cool and I'd +1 getting them in place (though I really can't
> personally do it soon because F28 but patches welcome).
> 
> Do you think the ideas require a separate karma feedback though? What if
> we did the ideas you talked about in response to a regular -1 on a
> critpath package? I.e., just the same karma button that we use for
> normal updates, but on critpath updates the alarm bells are bigger?

There's two problems with that:

1) The critpath can be broken by non-critpath packages, because our
critpath definition is really not *close* to correct. It's just a list
we made up one day and have not done a great job of updating since. It
is not in any way 'validated'. Until recently, it didn't have bash,
setup or selinux-policy in it, for instance.

2) Critpath packages can be broken in ways that don't break the
critical path. selinux-policy is a great example there, in fact; a -1
for an selinux-policy update *could* mean "this update renders all
systems unbootable", or it *could* mean "this update broke some obscure
leaf package two people are running".

> If we do think there's a good reason to keep two kinds of karma for the
> glorious feature, perhaps we could just hide the critpath karma feedback
> buttons in the UI for now just so they don't get confused with the
> normal karma, which can lead to some issues since it doesn't really do
> anything.

That sounds reasonable to me indeed.

>  Or another easy thing I could do server side is autodetect
> someone setting critpath karma to -1 and forcing their karma to also be
> -1 when that happens.

Also seems reasonable.
-- 
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: Frequently broken Rawhide/Branched composes

2018-03-07 Thread Randy Barlow

On 03/06/2018 03:37 PM, Kevin Kofler wrote:
> But bumping Epoch, as the policy makes you do in such a case, does 
> absolutely nothing to fix that. So I don't see how the current policy helps.

True, but the epoch thing also offers a bit more encouragement to fix
the package without forcing a downgrade, or at least to think more about
it first. If we just have a policy to use distro-sync I would expect
that we might see downgrades happening more often, which could lead to
the data problems.

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

Re: Critpath karma

2018-03-07 Thread Randy Barlow

On 03/06/2018 07:20 PM, Adam Williamson wrote:
> Removing it is one choice, sure. Looking at those ideas again and
> deciding if we want to actually go ahead and implement any of them is
> another choice.

Cool thanks for the history there. I actually think those ideas sound
pretty cool and I'd +1 getting them in place (though I really can't
personally do it soon because F28 but patches welcome).

Do you think the ideas require a separate karma feedback though? What if
we did the ideas you talked about in response to a regular -1 on a
critpath package? I.e., just the same karma button that we use for
normal updates, but on critpath updates the alarm bells are bigger?

If we do think there's a good reason to keep two kinds of karma for the
glorious feature, perhaps we could just hide the critpath karma feedback
buttons in the UI for now just so they don't get confused with the
normal karma, which can lead to some issues since it doesn't really do
anything. Or another easy thing I could do server side is autodetect
someone setting critpath karma to -1 and forcing their karma to also be
-1 when that happens.

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

Spring cleaning my golang packages (orphaning now unused stuff)

2018-03-07 Thread Fabio Valentini

Hi everybody,

I'm going to orphan some of my golang packages that were initially pulled
in by syncthing as dependencies, but have been dropped as dependencies
again (... don't ask. golang people produce dependencies like rabbits make
bunnies.).

Most of them are fairly low maintenance packages, with only a few commits
per year (if even that), and decent coverage with unit tests. All of them
are up-to-date with the latest upstream git master or latest stable
release, where available, except where I have indicated otherwise.

Just write if you want to take over maintenance of one or more of these
packages, and I'll transfer ownership of the package and its dependencies.
Otherwise, I'll orphan the rest in about one week (March 14), after
re-checking that nothing depends on them anymore.


Also, Athos, if you're reading this, I see that hugo is also using my
package golang-github-gobwas-glob - I can make you a co-maintainer if you
want.


Unused leaf packages:
- golang-github-AudriusButkevicius-kcp-go
- golang-github-calmh-luhn
- golang-github-ccding-go-stun
- golang-github-cznic-ql (1 commit behind git master)
- golang-github-xtaci-kcp-go

Dependencies becoming new unused leaves:
- golang-github-cznic-b
- golang-github-cznic-fileutil
- golang-github-cznic-golex
- golang-github-cznic-internal
- golang-github-cznic-lex
- golang-github-cznic-lexer
- golang-github-cznic-lldb
- golang-github-cznic-mathutil (2 commits behind git master)
- golang-github-cznic-sortutil
- golang-github-cznic-strutil
- golang-github-edsrzf-mmap-go
- golang-github-klauspost-reedsolomon
- golang-github-remyoudompheng-bigfft
- golang-github-templexxx-cpufeat
- golang-github-templexxx-reedsolomon
- golang-github-templexxx-xor
- golang-github-tjfoc-gmsm
- golang-github-xtaci-smux

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

Re: GCC 8 ABI change on x86_64

2018-03-07 Thread Sérgio Basto

On Wed, 2018-03-07 at 19:50 +0100, Marek Polacek wrote:
> I did another mass rebuild with a specially-tweaked gcc in order to
> find out
> which packages need to be rebuild with patched gcc-8.0.1-0.16. 

How we find out the same problem in packages from external repos ? 

Thanks, 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

Le mercredi 07 mars 2018 à 12:18 -0500, Josh Boyer a écrit :
> On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
>  wrote:
> > Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit
> > :
> > > 
> > > I don't know if this is useful but in the RHL and early Fedora
> > > days,
> > > the way to do inplace upgrades was to first update just the 'core'
> > > tools needed by rpm.
> 
> This is a totally unrelated comment, but I will personally send you $5
> if you can configure your email client to stop adding  in the
> Subject line for every thread you reply to.

I'm pretty sure that's added by one of the MTAs in the chain between
Fedora SMTP and my ISP MTA, to attest they did DKIM verification, since
I see it already positioned on some received messages before I ever
replied to them.

And not all of them, only for senders that use a mail host that provides
DKIM info.

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

Re: Re: Broken system upgrade due to rich dependencies


Le 2018-03-07 18:15, Reindl Harald a écrit :


if there wouldn't be dependencies in the real world making it risky
and difficult just update rpm itself

would you pull all dependencies down to glibc with that transaction?


If needed, yes, it is unsafe to install from a repo that has a newer rpm 
stack than the system one.



what if dnf itself don't work with that new rpm stack without rebuild?


That means building dnf from a new rpm is a special case that needs a 
buildroot override, not that everything else is a special case because 
the normal dnf use it pulling in rpm to rebuild itself.



how do you test that?


I certainly hope the rpm and dnf guys talk to each other and do not 
update the stack without taking the other needs in account.



how do you ensure that your tests are still true two months later?


That's the whole point, you don't need to, because you don't allow dnf 
installing packages from a repo with a newer rpm stack for months 
without updating rpm. The breakage, if any occurs directly at rpm update 
not months later once QA thinks everything is golden.


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

[389-devel] Re: Please review: Issue 49593 - NDN cache stats should be under the global stats

2018-03-07 Thread Simon Pichugin

Fixed compile warnings.

On Wed, Mar 07, 2018 at 06:53:53PM +0100, Simon Pichugin wrote:
> Hi team,
> please, review:
> 
> https://pagure.io/389-ds-base/pull-request/49595
> https://pagure.io/389-ds-base/issue/49593
> 
> Thanks,
> Simon
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

On Wed, 2018-03-07 at 09:13 -0500, Colin Walters wrote:
> 
> On Wed, Mar 7, 2018, at 5:52 AM, Igor Gnatenko wrote:
> > 
> > And you forgot:
> > 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> > proper way).
> 
> If you're using yum/dnf inside a container, the natural way to major upgrades 
> is
> to just pull the new base image and rebuild, rather than doing 
> update-in-place.
> Which has the semantics you're talking about.
> 
> For rpm-ostree, if you have no layered packages, depsolving etc. is not 
> involved
> at all, so it's completely immune to this problem.  If you have layered 
> packages,
> we do still use the libdnf from the booted deployment, but in the end if 
> something
> doesn't work you can temporarily drop your layered packages.  Down the line 
> we might
> try to do some libdnf parts inside a container in the new root, but that's a 
> huge change.

There are still a few of us living in the stone age, Colin, who aren't
using Fedora in a container *or* using ostree. Shocking, I know, but
it's true. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

GCC 8 ABI change on x86_64

2018-03-07 Thread Marek Polacek

Recently we discovered a serious bug in the compiler whereby we miscompiled
several packages.  The problem started with my ABI-changing patch which changed
how empty classes are passed, as per the x86_64 psABI (so this bug only affects
x86_64).  The problem could arise when the code contained empty class 
templates.  
For more info see .

I did another mass rebuild with a specially-tweaked gcc in order to find out
which packages need to be rebuild with patched gcc-8.0.1-0.16.  Sorry about
this.

This is the list:

  0ad-0.0.22-5.fc28.src.rpm
  adonthell-0.3.6-7.fc28.src.rpm
  american-fuzzy-lop-2.52b-2.fc28.src.rpm
  ardour4-4.7.0-10.fc28.src.rpm
  ardour5-5.12.0-4.fc28.src.rpm
  BEDTools-2.26.0-3.fc26.src.rpm
  bro-2.5.3-1.fc28.src.rpm
  bullet-2.87-2.fc28.src.rpm
  camotics-1.1.1-11.fc28.src.rpm
  Canna-3.7p3-52.fc28.src.rpm
  crawl-0.21.1-2.fc28.src.rpm
  dx-4.4.4-44.fc28.src.rpm
  dyninst-9.3.2-10.fc28.src.rpm
  eiskaltdcpp-2.2.11-12.20180207git6ca065b.fc28.src.rpm
  enblend-4.2-9.fc28.src.rpm
  endless-sky-0.9.8-4.fc28.src.rpm
  eureka-1.00-11.fc28.src.rpm
  fastbit-2.0.3-5.fc28.src.rpm
  fbreader-0.12.10-18.fc23.src.rpm
  fcl-0.5.0-8.fc28.src.rpm
  freecad-0.16-11.fc28.src.rpm
  freenx-server-0.7.3-41.fc28.src.rpm
  freeorion-0.4.7.1-6.fc28.src.rpm
  glslang-3.1-0.6.20180205.git2651cca.fc28.src.rpm
  gnucap-0.35-24.fc28.src.rpm
  gtk4-3.92.1-2.fc28.src.rpm
  hypre-2.13.0-5.fc28.src.rpm
  ibp-0.21-17.fc28.src.rpm
  isdn4k-utils-3.27-10.fc28.src.rpm
  java-1.8.0-openjdk-1.8.0.161-8.b14.fc28.src.rpm
  kf5-libkleo-17.12.2-1.fc28.src.rpm
  kinput2-v3.1-58.fc28.src.rpm
  koules-1.4-25.fc28.src.rpm
  kyotocabinet-1.2.76-16.fc28.src.rpm
  lcgdm-1.10.0-1.fc28.src.rpm
  libimagequant-2.11.7-2.fc28.src.rpm
  libqb-1.0.3-2.fc28.src.rpm
  librime-1.2-21.fc28.src.rpm
  llvm34-3.4.2-10.fc26.src.rpm
  llvm35-3.5.2-4.fc26.src.rpm
  llvm3.7-3.7.1-7.fc27.src.rpm
  llvm3.9-3.9.1-11.fc27.src.rpm
  llvm4.0-4.0.1-3.fc28.src.rpm
  llvm5.0-5.0.1-4.fc28.src.rpm
  MagicPoint-1.13a-20.fc28.src.rpm
  mld2p4-2.1.1-0.4.fc28.src.rpm
  mlpack-2.2.5-3.fc28.src.rpm
  mmapper-2.4.5-1.fc28.src.rpm
  nas-1.9.4-11.fc28.src.rpm
  nco-4.7.1-1.fc28.src.rpm
  netpanzer-0.8.7-3.fc26.src.rpm
  nx-libs-3.5.0.33-3.fc28.src.rpm
  octave-image-2.6.2-1.fc28.src.rpm
  oggvideotools-0.9-5.fc27.src.rpm
  oneko-1.2-24.fc28.src.rpm
  openms-2.3.0-7.fc28.src.rpm
  openmsx-0.14.0-2.fc28.src.rpm
  p7zip-16.02-10.fc28.src.rpm
  pgRouting-2.5.2-3.fc28.src.rpm
  pngquant-2.11.7-3.fc28.src.rpm
  polyclipping-6.4.2-2.fc28.src.rpm
  pythia8-8.2.15-6.fc28.src.rpm
  python-pyclipper-1.1.0-1.fc28.src.rpm
  qt5-qtlocation-5.10.1-1.fc28.src.rpm
  quantum-espresso-5.4.0-12.fc26.src.rpm
  rasmol-2.7.5.2-8.fc27.src.rpm
  renderdoc-0.91-6.fc28.src.rpm
  rocksdb-5.7.3-2.fc28.src.rpm
  root-tail-1.2-20.fc28.src.rpm
  rosegarden4-17.12-3.fc28.src.rpm
  sendmail-8.15.2-23.fc28.src.rpm
  seqan-1.4.2-34.fc28.src.rpm
  seqan2-2.4.0-2.fc28.src.rpm
  stage-4.1.1-17.fc27.src.rpm
  stxxl-1.4.1-6.fc28.src.rpm
  supertuxkart-0.9.3-2.fc28.2.src.rpm
  synergy-2.0.0-2.fc28.src.rpm
  tapkee-1.1-6.fc28.src.rpm
  tcpxtract-1.0.1-26.fc28.src.rpm
  tgif-4.2.5-15.fc28.src.rpm
  unclutter-8-16.fc28.src.rpm
  v8-6.2.91-5.fc28.src.rpm
  vigra-1.11.1-4.fc28.src.rpm
  vtk-7.1.1-10.fc28.src.rpm
  vxl-1.17.0-25.fc28.src.rpm
  x11-ssh-askpass-1.2.4.1-21.fc28.src.rpm
  xapian-core-1.4.5-2.fc28.src.rpm
  xautolock-2.2-18.fc24.src.rpm
  xkeycaps-2.46-22.fc28.src.rpm
  xmountains-2.9-2.D20170103git3ba444a4f7.fc28.1.src.rpm
  xskat-4.0.0-19.fc28.src.rpm
  xstar-2.2.0-18.fc28.src.rpm
  xvkbd-3.7-6.fc28.src.rpm
  yadex-1.7.0-45.fc28.src.rpm

The following packages were affected, but have already been rebuilt:

  cbmc-5.7-3.fc27.src.rpm
  clamav-0.99.3-7.fc28.src.rpm
  ceph-12.2.2-1.fc28.src.rpm
  chromium-64.0.3282.119-1.fc28.src.rpm
  glibc-2.27-3.fc28.src.rpm
  golang-1.10-0.rc2.1.fc28.src.rpm
  libepoxy-1.4.3-6.fc28.src.rpm
  librealsense-2.10.0-1.fc28.src.rpm
  mapnik-3.0.18-1.fc28.src.rpm
  mongodb-3.6.2-5.fc28.src.rpm
  opencv-3.3.1-4.fc28.src.rpm
  opengrm-ngram-1.3.2-7.fc27.src.rpm
  pcl-1.8.1-1.fc28.src.rpm
  qbittorrent-4.0.3-3.fc28.src.rpm
  root-6.12.06-1.fc28.src.rpm
  sphinxtrain-1.0.8-39.fc28.src.rpm

These two packages couldn't be rebuild because of lack of memory.  I think
they should be rebuilt too, for a good measure:

  openvswitch-2.8.1-2.fc28.src.rpm
  openblas-0.2.20-6.fc28.src.rpm

Thanks,

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

Re: Linux Kernel 4.14.12 Released to Disable x86 PTI for AMD Processors

2018-03-07 Thread JD




On 03/07/2018 11:37 AM, Josh Boyer wrote:

On Wed, Mar 7, 2018 at 1:34 PM, JD  wrote:


On 03/07/2018 11:12 AM, Josh Boyer wrote:

On Wed, Mar 7, 2018 at 1:03 PM, JD  wrote:

Is the PTI patch available for download by itself?

http://news.softpedia.com/news/linux-kernel-4-14-12-released-to-disable-x86-pti-for-amd-radeon-processors-519253.shtml

Not without going through the upstream kernel git tree.  And that
article is old and had incomplete information.

josh

Thank you Josh.
I would truly appreciate some pointers to where the git checkin tree is.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

josh

Thank you Josh!
I found all the diffs!!!

Best Regards,

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

Re: Linux Kernel 4.14.12 Released to Disable x86 PTI for AMD Processors

2018-03-07 Thread Josh Boyer

On Wed, Mar 7, 2018 at 1:34 PM, JD  wrote:
>
>
> On 03/07/2018 11:12 AM, Josh Boyer wrote:
>>
>> On Wed, Mar 7, 2018 at 1:03 PM, JD  wrote:
>>>
>>> Is the PTI patch available for download by itself?
>>>
>>> http://news.softpedia.com/news/linux-kernel-4-14-12-released-to-disable-x86-pti-for-amd-radeon-processors-519253.shtml
>>
>> Not without going through the upstream kernel git tree.  And that
>> article is old and had incomplete information.
>>
>> josh
>
> Thank you Josh.
> I would truly appreciate some pointers to where the git checkin tree is.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

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

Re: Linux Kernel 4.14.12 Released to Disable x86 PTI for AMD Processors

2018-03-07 Thread JD




On 03/07/2018 11:12 AM, Josh Boyer wrote:

On Wed, Mar 7, 2018 at 1:03 PM, JD  wrote:

Is the PTI patch available for download by itself?
http://news.softpedia.com/news/linux-kernel-4-14-12-released-to-disable-x86-pti-for-amd-radeon-processors-519253.shtml

Not without going through the upstream kernel git tree.  And that
article is old and had incomplete information.

josh

Thank you Josh.
I would truly appreciate some pointers to where the git checkin tree is.

Regards,

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

Re: Frequently broken Rawhide/Branched composes

2018-03-07 Thread Lars Seipel

On Tue, Mar 06, 2018 at 04:47:49PM +0100, Pierre-Yves Chibon wrote:
> Sorry, just to be clear, what would have its own issues:
> - asking rawhide users to use distro-sync instead of update?
> - automatically have dnf detect it's running in rawhide and default to
>   distro-sync instead of update?

As distro-sync puts all packages back at the repo version, it can also
revert the installation of local rebuilds or bug fix builds
cherry-picked from Koji.

The latter has become pretty common for me in recent weeks, as the
persistent compose issues mean that packages may take a long time
to hit the repos.

Nothing that can't be worked around by judicious use of excludes, you
just have to be aware of it instead of blindly firing off a distro-sync.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Linux Kernel 4.14.12 Released to Disable x86 PTI for AMD Processors

2018-03-07 Thread Josh Boyer

On Wed, Mar 7, 2018 at 1:03 PM, JD  wrote:
> Is the PTI patch available for download by itself?
> http://news.softpedia.com/news/linux-kernel-4-14-12-released-to-disable-x86-pti-for-amd-radeon-processors-519253.shtml

Not without going through the upstream kernel git tree.  And that
article is old and had incomplete information.

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

Re: Linux Kernel 4.14.12 Released to Disable x86 PTI for AMD Processors

2018-03-07 Thread JD


Is the PTI patch available for download by itself?
http://news.softpedia.com/news/linux-kernel-4-14-12-released-to-disable-x86-pti-for-amd-radeon-processors-519253.shtml 
___

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

[389-devel] Please review: Issue 49593 - NDN cache stats should be under the global stats

2018-03-07 Thread Simon Pichugin

Hi team,
please, review:

https://pagure.io/389-ds-base/pull-request/49595
https://pagure.io/389-ds-base/issue/49593

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

Re: Re: Broken system upgrade due to rich dependencies

2018-03-07 Thread R P Herrold

On Wed, 7 Mar 2018, Nicolas Mailhot wrote:

> It is quite insane, that, to this day, users are expected to know the
> rpm stack better than dnf, and tell it to update it first.
> 
> KNOWING THE PACKAGE INFRA STACK STACK IS THE INSTALLER JOB
> 
> whenever dnf hits a repo with an updated rpm stack, it should update the
> system rpm stack to this updated stack by default in a separate
> transaction, before installing anything from this repo.

As I recall from RHL days, and trying to do 'hot upgrades' 
across Major releases [it _could_ be done, but was not time 
effective], this also pulled in glibc (and kernel pairs in 
support of that glibc).  When such failed, it was time to go 
to the L0 backup ... and in Fedora and with new deployment 
automation and configuration orchestration, I suspect few 
people actually do a reboot, and a L0 backup, before every 
upgrade.

I would expect it to be useful to do the 'subset' upgrade
mentioned by Smooge for rpm and friends, _most_ of the time,
but occasionally (thinking here of an underlying DB version
bump and rebuild by RPM) not always

Perhaps scanning the transactionset, add a check and consult 
an optional:
- enable doing updates piecemail

flag.  If adding such a flag, I'd also add flags for 
potentially 'dangerous' transactions:
- warn me to take a L0,
- reboot first, and 
- reboot after a new kernel, glibc, or rpm

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

Re: Frequently broken Rawhide/Branched composes

2018-03-07 Thread Sérgio Basto

On Tue, 2018-03-06 at 21:30 +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Do note that distro-sync can downgrade packages, but can't handle
> > all
> > the cases. ie, upgrade postgresql and update all your data you
> > can't
> > just downgrade the rpm and be fine. Or any number of other
> > scriptlets
> > that do things that cannot easily be reversed.
> 
> The Epoch hack that the current policy forces us to use does not
> solve any 
> of that though.

Definitively IMHO we should change this policy on rawhide and updates-
testing repos, with these repos we should use (sometimes) : 

dnf distro-sync 

Will allow packager revert one package upgrade without Epoch hack . 

Cheers,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Broken system upgrade due to rich dependencies

2018-03-07 Thread Josh Boyer

On Wed, Mar 7, 2018 at 12:11 PM, Nicolas Mailhot
 wrote:
> Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit :
>>
>> I don't know if this is useful but in the RHL and early Fedora days,
>> the way to do inplace upgrades was to first update just the 'core'
>> tools needed by rpm.

This is a totally unrelated comment, but I will personally send you $5
if you can configure your email client to stop adding  in the
Subject line for every thread you reply to.

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

Re: Re: Broken system upgrade due to rich dependencies

Le mercredi 07 mars 2018 à 11:31 -0500, Stephen John Smoogen a écrit :
> 
> I don't know if this is useful but in the RHL and early Fedora days,
> the way to do inplace upgrades was to first update just the 'core'
> tools needed by rpm.

It is quite insane, that, to this day, users are expected to know the
rpm stack better than dnf, and tell it to update it first.

KNOWING THE PACKAGE INFRA STACK STACK IS THE INSTALLER JOB

whenever dnf hits a repo with an updated rpm stack, it should update the
system rpm stack to this updated stack by default in a separate
transaction, before installing anything from this repo.

That’s all it takes to stop wasting our time and Fedora user’s time on
this.

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

Re: Critpath karma

On Wed, 2018-03-07 at 08:50 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 06, 2018 at 04:20:26PM -0800, Adam Williamson wrote:
> > 1. Any update that is marked as 'critpath breaking' by a FAS-registered 
> > tester would be blocked from going any further in the update process
> > without manual intervention (no autopushes at all)
> 
> IIRC, that happens with all updates now: any negative karma disables
> autopush, right?

autopush to stable, yes. I believe the text at the time referred to any
movement between states as an autopush, so it was also proposing that
e.g. if an update got -1 critpath before being sent to updates-testing, 
it shouldn't go to updates-testing.
-- 
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: Broken system upgrade due to rich dependencies

2018-03-07 Thread Stephen John Smoogen

On 7 March 2018 at 05:40, Jaroslav Mracek  wrote:
> Recently, several users report problems with system upgrade due to rich 
> dependencies that are not supported by RPM in Fedora 25, and not fully 
> supported by RPM in Fedora 26 (statement 'with'). Rich dependencies are 
> allowed and supported from Fedora 26, but during the System Upgrade from 
> Fedora 25 the transaction is checked by RPM that doesn't support rich 
> dependencies, therefore the transaction check performed by RPM fails. A 
> similar situation can be experienced for System Upgrade from Fedora 26 where 
> RPM is unable to handle rich dependency using "with" statement 
> (https://bugzilla.redhat.com/show_bug.cgi?id=1551543). In future we can 
> expect that more and more users will be affected by the problem due to 
> increase of rich dependencies in Fedora 26-28. I realize that there were 
> similar issue discussed in 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/#7JWQ2TFDFYNCQFJBMOAQFIPDP4XCYLVC,
>  but it does not cover user point o
>  f view.
>
> Possible solution:
> 1. Back-port support of "with" key word in rich dependencies into Fedora 26 
> (solves only upgrades from 26 to 27, and 26 to 28.)
> 2. Ban rich dependencies in Fedora 26, and 27, and in 28 only rich deps using 
> "with" statement (solves all issues)
> 3. Provide a copr repo with RPM for Fedora 25, and 26 that support all rich 
> dependencies (user unfriendly)
> 4. Disable rich dependency check in RPM release for Fedora 26 (solves only 
> upgrades from 26 to 27, and 26 to 28.)
>

I don't know if this is useful but in the RHL and early Fedora days,
the way to do inplace upgrades was to first update just the 'core'
tools needed by rpm. Then you would normally need to do an rpmrebuild
to make everything correct. Then the install would be restarted and
completed with the new in place tools. However every now and then a
'flag' day would happen which meant that past updates could not be
done with an inplace update and an external one was needed. This
sounds like this is the case with rich dependencies which would have
been a reason to move rpm4 to rpm5 but ahem that wasn't possible.

Is there a way to get either a minimal update installer or a scripted
set of commands to allow for the above?


> The issue can be experienced in following system upgrade combinations: 25 to 
> 26, 25 to 27,  26 to 27, 26 to 28.
> The list of Fedora 27 and 28 packages with incompatible rich deps - 
> https://bugzilla.redhat.com/show_bug.cgi?id=1552547
>
> Best regards
>
>Jaroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Giving up some packages to orphan

2018-03-07 Thread Matěj Cepl

Hi,

I have decided to orphan some more obscure packages:

  * pidgin-epel
  * python-backport_collections
  * python-dbusmock
  * python-html2text (Aaron Swartz’s one)
  * python-mako1.0
  * python-mccabe
  * rendercheck
  * waffle

And remove myself from maintaining some packages which have other 
co-maintainers:

  * clinfo
  * exiv2
  * linux-libertine-fonts
  * mozilla-fira-fonts
  * gnome-chess
  * gnuchess
  * hgsvn
  * http-parser
  * jabberd
  * josm
  * lcov
  * piglit
  * pyOpenSSL
  * python3-mypy
  * python-typeshed
  * python-behave
  * python-cryptography{,-vectors}
  * python-flake8
  * python-mako (well, I would like to, kylev)
  * python-mutagen
  * python-parse
  * python-parse_type
  * python-pelican
  * python-rope
  * pytz
  * signpost-core
  * svgsalamander

Go and help those guys maintaining those packages, please!

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
-- Tim Hansel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

cquad: Unresponsive package maintainer for josm

2018-03-07 Thread Christian Stadelmann

As per step 4 of Policy for nonresponsive package maintainers [1], I'm asking 
here whether anyone knows cquad, who is maintainer of the josm package, and has 
a way of contacting him/her. This package is quite outdated as it has not seen 
an update in 14 months. There is a bug report requesting an update [2] with 3 
comments from 3 different people and no response for 4 months.

I am not interested in taking over this package. As the software depends on 
rapidly changing web service APIs, it is partially broken and I would like to 
see it updated or removed, but not broken.

[1] 
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Outline
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1500778
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Sandro Mani




On 07.03.2018 16:54, Petr Pisar wrote:

On 2018-03-07, Sandro Mani  wrote:

I.e. mmg3d reports "No CMAKE_CXX_COMPILER could be found.", but mmg3d is
a pure C library, so I suppose it is just cmake which checks for a c++
compiler regardless of whether it is used or not.

C++ is the default language cmake expects and what compiler it invokes.
If your code in C only, than you have to explicitly specify that in
CMakeList.txt.

See .


But the build should have succeded regardless of the presence of g++.

No. It's fatal for cmake.

Ah I see, thanks for the explanation.

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

[Bug 1552598] perl-Number-Fraction-2.01 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Number-Fraction-2.01-1
   ||.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-03-07 11:05:14



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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Petr Pisar

On 2018-03-07, Sandro Mani  wrote:
> I.e. mmg3d reports "No CMAKE_CXX_COMPILER could be found.", but mmg3d is 
> a pure C library, so I suppose it is just cmake which checks for a c++ 
> compiler regardless of whether it is used or not.

C++ is the default language cmake expects and what compiler it invokes.
If your code in C only, than you have to explicitly specify that in
CMakeList.txt.

See .

> But the build should have succeded regardless of the presence of g++.

No. It's fatal for cmake.

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

Re: systemd 238 and sysusers

2018-03-07 Thread Simo Sorce

On Wed, 2018-03-07 at 16:23 +0100, Jakub Hrozek wrote:
> > On 7 Mar 2018, at 15:53, Stephen Gallagher  wrote:
> > 
> > 
> > 
> > On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:
> > On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > > > 
> > > > > However, you're right. On systems not using SSSD (which I suspect is a
> > > > > nontrivial number of systems running systemd...), people are probably 
> > > > > still
> > > > > using nss and we should call `nscd -i passwd` (plus `group` and 
> > > > > `shadow`
> > > > > where appropriate) if the nscd service is running.
> > > > 
> > > > nscd is supposed to monitor these files, too.
> > > > 
> > > > But is this monitoring sufficient?  RPM will immediately start
> > > > installing files after the scriptlet has finished.  nscd and SSSD
> > > > may not have completed their cache invalidation at this point, so
> > > > this looks like a race condition to me.
> > > 
> > > That sounds like a bug in the cache implementation. nscd and sssd
> > > simply _must_ ensure that their copy of passwd is the latest one.
> > > Shouldn't be a problem to call fstatat() before generating an answer
> > > an invalidate the cache if it returns a different mtime then previously.
> > 
> > The fast cache we provide from sssd is read directly by the client
> > (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> > it would be slow).
> > so there are windows for races if you change a passwd file and then
> > immediately read out of the fast caches.
> > This is not something we can fix without severely compromising
> > performance, which is the raison d'etre of those caches.
> > 
> > 
> > Probably the simplest solution for sysusers would be to execute the change 
> > and then run a wait-loop calling `getpwnam()` until it 
> > gets a successful result (or some reasonable timeout expires, indicating a 
> > bug elsewhere). That way, it can be trusted that sysusers won't return 
> > until the user addition is truly valid.
> 
> btw if nss_sss wouldn’t find the user, then, assuming the default order on 
> Fedora, the request would just fall back to nss_files. So I don’t think the 
> race condition when /adding/ a user is something to worry about. But the 
> other way around, if the user was removed, there can be a small race between 
> removing the user and nss_sss having its cache flushed. I don’t think this is 
> any different from nscd either.
> 
changing or removing users are the cases where races matters, just
adding is not indeed.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Vít Ondruch

$ curl https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt | wc -l
  % Total    % Received % Xferd  Average Speed   Time    Time Time 
Current
 Dload  Upload   Total   Spent    Left 
Speed
100  281k  100  281k    0 0   156k  0  0:00:01  0:00:01
--:--:--  156k
6193


$ curl https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt |
wc -l
  % Total    % Received % Xferd  Average Speed   Time    Time Time 
Current
 Dload  Upload   Total   Spent    Left 
Speed
100  200k  100  200k    0 0   116k  0  0:00:01  0:00:01
--:--:--  116k
4657


Good job everybody!


V.


Dne 7.3.2018 v 08:43 Igor Gnatenko napsal(a):
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.
>
> Since people might have fixed their packages after I started rebuild, I
> decided to include information about commits I have used to build
> packages. Hope this helps.
>
>
> New list of packages, their commits and build logs are available:
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-commits-2.tx
> t
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-2.txt
>
>
> [0] https://lists.fedoraproject.org/archives/list/devel-announce@lists.
> fedoraproject.org/thread/IJFYI5Q2BYZKIGDFS2WLOBDUSEGWHIKV/
> ___ > 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



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

Re: compilation of lollypop fails on mock build server

2018-03-07 Thread Martin Gansser

the --nonet  option is already used in the spec file:
https://src.fedoraproject.org/cgit/rpms/lollypop.git/tree/lollypop.spec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Trying out More Go Packaging: Bugs and Questions

Le mercredi 07 mars 2018 à 16:35 +0100, Nicolas Mailhot a écrit :
> Le mercredi 07 mars 2018 à 16:02 +0100, Jan Chaloupka a écrit :
> 
> Hi,
> 
> > Nicolas, can you more elaborate on that? I don't see any more reason
> > why we should block folks from relying on the new macros.
> 
> IMHO they're solid enough to be used in production both for binary
> packages and -devel packages (modulo the fixes which are in the PRs I
> sent you).
> 
> The remaining work 

(also to clean up the way golist is assembled and built, but that need
not change the way other packages use it)


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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Vít Ondruch



Dne 7.3.2018 v 15:08 Jerry James napsal(a):
> On Wed, Mar 7, 2018 at 12:43 AM, Igor Gnatenko
>  wrote:
>> This is the second iteration of my mass-scratch-rebuild without
>> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
>> original mail still applies.
> The abe and flocq packages should be considered false positives.  The
> configure script in abe checks for a C++ compiler, but the makefile
> only uses a C compiler.

I think the same happens to Ruby. It checks for C++ while C++ is not
needed. I might try to query upstream about it.

V.

>   Complaining to upstream is unlikely to be
> effective, since patches I sent upstream 7 years ago have not been
> touched; i.e., upstream is dead.
>
> The flocq package uses some build-related files that are common to all
> projects by the same upstream.  They check for a C++ compiler, but
> there is no C or C++ code in the flocq package.  That upstream likes
> using the same build-related files across all of his packages, because
> it makes things simpler for him.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Trying out More Go Packaging: Bugs and Questions

Le mercredi 07 mars 2018 à 16:02 +0100, Jan Chaloupka a écrit :

Hi,

> Nicolas, can you more elaborate on that? I don't see any more reason
> why we should block folks from relying on the new macros.

IMHO they're solid enough to be used in production both for binary
packages and -devel packages (modulo the fixes which are in the PRs I
sent you).

The remaining work is to decide whether to do unit test packages and
example packages (of if yes, how), or just ignore the mess they are, by
making unit tests not participate in requires or just plain not
installing them, and pushing examples to doc.

> > Also will this be available for EPEL7 too?
> 
> I hope they will be. Thought, it will be not so trivial cause RHEL
> has different policies. It will take some time.

I doubt anyone will want them in EL before they prove themselves in
Fedora (I'm using them in EL7, but not publicly). So probably at least a
few months, or even a full Fedora release, before attempting to push
them to EL would be wise.

EL+1 is something else as the .0 release is not expected to be as rock
solid as the follow-ups.

Regards,

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

Re: systemd 238 and sysusers

2018-03-07 Thread Jakub Hrozek



> On 7 Mar 2018, at 15:53, Stephen Gallagher  wrote:
> 
> 
> 
> On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:
> On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > >
> > > > However, you're right. On systems not using SSSD (which I suspect is a
> > > > nontrivial number of systems running systemd...), people are probably 
> > > > still
> > > > using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> > > > where appropriate) if the nscd service is running.
> > >
> > > nscd is supposed to monitor these files, too.
> > >
> > > But is this monitoring sufficient?  RPM will immediately start
> > > installing files after the scriptlet has finished.  nscd and SSSD
> > > may not have completed their cache invalidation at this point, so
> > > this looks like a race condition to me.
> >
> > That sounds like a bug in the cache implementation. nscd and sssd
> > simply _must_ ensure that their copy of passwd is the latest one.
> > Shouldn't be a problem to call fstatat() before generating an answer
> > an invalidate the cache if it returns a different mtime then previously.
> 
> The fast cache we provide from sssd is read directly by the client
> (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> it would be slow).
> so there are windows for races if you change a passwd file and then
> immediately read out of the fast caches.
> This is not something we can fix without severely compromising
> performance, which is the raison d'etre of those caches.
> 
> 
> Probably the simplest solution for sysusers would be to execute the change 
> and then run a wait-loop calling `getpwnam()` until it gets 
> a successful result (or some reasonable timeout expires, indicating a bug 
> elsewhere). That way, it can be trusted that sysusers won't return until the 
> user addition is truly valid.

btw if nss_sss wouldn’t find the user, then, assuming the default order on 
Fedora, the request would just fall back to nss_files. So I don’t think the 
race condition when /adding/ a user is something to worry about. But the other 
way around, if the user was removed, there can be a small race between removing 
the user and nss_sss having its cache flushed. I don’t think this is any 
different from nscd either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: compilation of lollypop fails on mock build server

2018-03-07 Thread Jerry James

On Wed, Mar 7, 2018 at 7:54 AM, Martin Gansser  wrote:
> when trying to build lollypop on the fedora mock build server, the package 
> build fails, when test suite (%meson_test) is enabled.

Does it help to pass the --nonet option to appstream-util?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

orphaning German dictionary/thesaurus/hyphenation

2018-03-07 Thread Michael Stahl


hello,

i've orphaned these linguistic packages for "de" languages:

* hunspell-de
  this tends to have a new release once or twice a year

* mythes-de
  upstream is a bit odd in that there is a new automatically generated
  .oxt file once per day, but the file name never changes...

* hyphen-de
  this one never changes

they are all up-to-date in rawhide/F28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Trying out More Go Packaging: Bugs and Questions

2018-03-07 Thread Jan Chaloupka




On 03/07/2018 04:02 PM, Jan Chaloupka wrote:



On 03/07/2018 03:50 PM, Robert-André Mauchin wrote:

On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:

Hi Robert-André,

thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. 
Making

the packaging experience as easy as possible at the same time.



Can we already use the new guidelines in "production"? Should I 
recommed their
use in the Golang Package Review? Or should we still wait for you to 
adjust

the finer details?


Go for it :) We still can not guarantee the macros will not change 
their API but the macro names and their flags are solid.
We could introduce more flags if needed. However, most of the changes 
are in macro implementation only.

In case there is macro incompatible change we will let you know.



Saying that, I will prepare new builds of gofed so the new spec files 
are generated with the new macros.


Nicolas, can you more elaborate on that? I don't see any more reason 
why we should block folks from relying on the new macros.



Also will this be available for EPEL7 too?


I hope they will be. Thought, it will be not so trivial cause RHEL has 
different policies. It will take some time.




Best regards,

Robert-André


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

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

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

Re: Trying out More Go Packaging: Bugs and Questions

2018-03-07 Thread Jan Chaloupka




On 03/07/2018 03:50 PM, Robert-André Mauchin wrote:

On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:

Hi Robert-André,

thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.



Can we already use the new guidelines in "production"? Should I recommed their
use in the Golang Package Review? Or should we still wait for you to adjust
the finer details?


Go for it :) We still can not guarantee the macros will not change their 
API but the macro names and their flags are solid.
We could introduce more flags if needed. However, most of the changes 
are in macro implementation only.

In case there is macro incompatible change we will let you know.

Nicolas, can you more elaborate on that? I don't see any more reason why 
we should block folks from relying on the new macros.



Also will this be available for EPEL7 too?


I hope they will be. Thought, it will be not so trivial cause RHEL has 
different policies. It will take some time.




Best regards,

Robert-André


___
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

[EPEL-devel] Fedora EPEL 7 updates-testing report

2018-03-07 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1094  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 856  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 439  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 336  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 168  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 105  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  29  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91   
freexl-1.0.5-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aacf1b47d6   
clamav-0.99.4-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-815e0064e9   
tor-0.2.9.15-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dkms-2.5.0-2.20180306gitb1b9033.el7
knot-resolver-2.1.1-1.el7
libabigail-1.2-1.el7
pax-utils-1.2.3-1.el7
perl-Fsdb-2.65-2.el7
php-pecl-krb5-1.1.2-1.el7
python-django16-1.6.11.7-1.el7
squashfuse-0.1.102-1.el7
standard-test-roles-2.9-1.el7
x2goclient-4.1.1.1-1.el7

Details about builds:



 dkms-2.5.0-2.20180306gitb1b9033.el7 (FEDORA-EPEL-2018-943a093af6)
 Dynamic Kernel Module Support Framework

Update Information:

Update to latest snapshot. Compressed module support and cleanups.




 knot-resolver-2.1.1-1.el7 (FEDORA-EPEL-2018-e9a6e2deb9)
 Caching full DNS Resolver

Update Information:

Knot Resolver 2.1.1 (2018-02-23)   Bugfixes
 - when iterating, avoid unnecessary queries for NS in insecure parent.
This problem worsened in 2.0.0. (#246) - prevent UDP packet leaks when using TLS
forwarding - fix the hints module also on some other systems, e.g. Gentoo.




 libabigail-1.2-1.el7 (FEDORA-EPEL-2018-dddf390c1e)
 Set of ABI analysis tools

Update Information:

Update to upstream 1.2




 pax-utils-1.2.3-1.el7 (FEDORA-EPEL-2018-dfb0769899)
 ELF utils that can check files for security relevant properties

Update Information:

ELF utils that can check files for security relevant properties.

References:

  [ 1 ] Bug #1548693 - pax-utils-1.2.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1548693




 perl-Fsdb-2.65-2.el7 (FEDORA-EPEL-2018-8fc46c3d61)
 A set of commands for manipulating flat-text databases from the shell

Update Information:

uplift to 2.65




 php-pecl-krb5-1.1.2-1.el7 (FEDORA-EPEL-2018-4ae839f24e)
 Kerberos authentification extension

Update Information:

**Version 1.1.2**  - [BUG] Add missing function entry termination for TLData -
[CLEANUP] Don't return garbage on hard class initialization errors, don't throw
from create_object handlers

compilation of lollypop fails on mock build server

2018-03-07 Thread Martin Gansser

Hi,

when trying to build lollypop on the fedora mock build server, the package 
build fails, when test suite (%meson_test) is enabled.
 
rpm -E "%meson_test"

/usr/bin/ninja test -v -j2 -C x86_64-redhat-linux-gnu ||
{ rc=$?;
  echo "-BEGIN TESTLOG-";
  cat x86_64-redhat-linux-gnu/meson-logs/testlog.txt;
  echo "-END TESTLOG-";
  exit $rc; }
 
build.log: https://kojipkgs.fedoraproject.org//work/tasks/980/25540980/build.log

how can i solve this ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

2018-03-07 Thread Stephen Gallagher

On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:

> On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > >
> > > > However, you're right. On systems not using SSSD (which I suspect is
> a
> > > > nontrivial number of systems running systemd...), people are
> probably still
> > > > using nss and we should call `nscd -i passwd` (plus `group` and
> `shadow`
> > > > where appropriate) if the nscd service is running.
> > >
> > > nscd is supposed to monitor these files, too.
> > >
> > > But is this monitoring sufficient?  RPM will immediately start
> > > installing files after the scriptlet has finished.  nscd and SSSD
> > > may not have completed their cache invalidation at this point, so
> > > this looks like a race condition to me.
> >
> > That sounds like a bug in the cache implementation. nscd and sssd
> > simply _must_ ensure that their copy of passwd is the latest one.
> > Shouldn't be a problem to call fstatat() before generating an answer
> > an invalidate the cache if it returns a different mtime then previously.
>
> The fast cache we provide from sssd is read directly by the client
> (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> it would be slow).
> so there are windows for races if you change a passwd file and then
> immediately read out of the fast caches.
> This is not something we can fix without severely compromising
> performance, which is the raison d'etre of those caches.
>
>
Probably the simplest solution for sysusers would be to execute the change
and then run a wait-loop calling `getpwnam()` until it
gets a successful result (or some reasonable timeout expires, indicating a
bug elsewhere). That way, it can be trusted that sysusers won't return
until the user addition is truly valid.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Trying out More Go Packaging: Bugs and Questions

2018-03-07 Thread Robert-André Mauchin

On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote:
> Hi Robert-André,
> 
> thank you for your patience and all comments pointing out pieces that 
> are not working as expected.
> Introduction of new macros is a time-consuming process and it requires 
> resilience so we keep up till the state
> where the macros are generally usable for a lot of our use cases. Making 
> the packaging experience as easy as possible at the same time.
> 


Can we already use the new guidelines in "production"? Should I recommed their 
use in the Golang Package Review? Or should we still wait for you to adjust 
the finer details?
Also will this be available for EPEL7 too?

Best regards,

Robert-André


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

Re: systemd 238 and sysusers

2018-03-07 Thread Simo Sorce

On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > 
> > > However, you're right. On systems not using SSSD (which I suspect is a
> > > nontrivial number of systems running systemd...), people are probably 
> > > still
> > > using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> > > where appropriate) if the nscd service is running.
> > 
> > nscd is supposed to monitor these files, too.
> > 
> > But is this monitoring sufficient?  RPM will immediately start
> > installing files after the scriptlet has finished.  nscd and SSSD
> > may not have completed their cache invalidation at this point, so
> > this looks like a race condition to me.
> 
> That sounds like a bug in the cache implementation. nscd and sssd
> simply _must_ ensure that their copy of passwd is the latest one.
> Shouldn't be a problem to call fstatat() before generating an answer
> an invalidate the cache if it returns a different mtime then previously.

The fast cache we provide from sssd is read directly by the client
(sssd nsswitch plugin) without the involvement of the sssd daemon (or
it would be slow).
so there are windows for races if you change a passwd file and then
immediately read out of the fast caches.
This is not something we can fix without severely compromising
performance, which is the raison d'etre of those caches.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

2018-03-07 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 966  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 856  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 828  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 439  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 168  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  87  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  59  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  54  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829   
freexl-1.0.5-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7e91105260   
clamav-0.99.4-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

libabigail-1.2-1.el6
pax-utils-1.2.3-1.el6
perl-Fsdb-2.65-2.el6
php-pecl-krb5-1.1.2-1.el6

Details about builds:



 libabigail-1.2-1.el6 (FEDORA-EPEL-2018-b6e67b83c8)
 Set of ABI analysis tools

Update Information:

Update to upstream 1.2




 pax-utils-1.2.3-1.el6 (FEDORA-EPEL-2018-a27d71c715)
 ELF utils that can check files for security relevant properties

Update Information:

Update to the latest upstream release, fixes multiple security vulnerabilities.

References:

  [ 1 ] Bug #1418754 - pax-utils: Multiple vulnerabilities
https://bugzilla.redhat.com/show_bug.cgi?id=1418754




 perl-Fsdb-2.65-2.el6 (FEDORA-EPEL-2018-87bbf9f7d0)
 A set of commands for manipulating flat-text databases from the shell

Update Information:

uplift to 2.65




 php-pecl-krb5-1.1.2-1.el6 (FEDORA-EPEL-2018-9eb81e5ec3)
 Kerberos authentification extension

Update Information:

**Version 1.1.2**  - [BUG] Add missing function entry termination for TLData -
[CLEANUP] Don't return garbage on hard class initialization errors, don't throw
from create_object handlers

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

Re: systemd 238 and sysusers

On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> >Yes, SSSD monitors those files and automatically cleans its cache.
> >
> >However, you're right. On systems not using SSSD (which I suspect is a
> >nontrivial number of systems running systemd...), people are probably still
> >using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> >where appropriate) if the nscd service is running.
> 
> nscd is supposed to monitor these files, too.
> 
> But is this monitoring sufficient?  RPM will immediately start
> installing files after the scriptlet has finished.  nscd and SSSD
> may not have completed their cache invalidation at this point, so
> this looks like a race condition to me.

That sounds like a bug in the cache implementation. nscd and sssd
simply _must_ ensure that their copy of passwd is the latest one.
Shouldn't be a problem to call fstatat() before generating an answer
an invalidate the cache if it returns a different mtime then previously.

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

Re: Broken system upgrade due to rich dependencies

2018-03-07 Thread Colin Walters

On Wed, Mar 7, 2018, at 5:52 AM, Igor Gnatenko wrote:
>
> And you forgot:
> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> proper way).

If you're using yum/dnf inside a container, the natural way to major upgrades is
to just pull the new base image and rebuild, rather than doing update-in-place.
Which has the semantics you're talking about.

For rpm-ostree, if you have no layered packages, depsolving etc. is not involved
at all, so it's completely immune to this problem.  If you have layered 
packages,
we do still use the libdnf from the booted deployment, but in the end if 
something
doesn't work you can temporarily drop your layered packages.  Down the line we 
might
try to do some libdnf parts inside a container in the new root, but that's a 
huge change.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Jerry James

On Wed, Mar 7, 2018 at 12:43 AM, Igor Gnatenko
 wrote:
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.

The abe and flocq packages should be considered false positives.  The
configure script in abe checks for a C++ compiler, but the makefile
only uses a C compiler.  Complaining to upstream is unlikely to be
effective, since patches I sent upstream 7 years ago have not been
touched; i.e., upstream is dead.

The flocq package uses some build-related files that are common to all
projects by the same upstream.  They check for a C++ compiler, but
there is no C or C++ code in the flocq package.  That upstream likes
using the same build-related files across all of his packages, because
it makes things simpler for him.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1470030] perl-Test-LeakTrace-0.16-1.fc27 FTBFS: Failed test ' UninitCondition' on ppc64

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

Paul Howarth  changed:

   What|Removed |Added

Version|27  |28



--- Comment #12 from Paul Howarth  ---
I'm fine with keeping this one open myself.

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

[Bug 1470030] perl-Test-LeakTrace-0.16-1.fc27 FTBFS: Failed test ' UninitCondition' on ppc64

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



--- Comment #11 from Mark Wielaard  ---
(In reply to Paul Howarth from comment #10)
> For the moment, I have disabled the optional valgrind test on ppc64 and
> ppc64le, which has allowed the package to build. I would of course like to
> re-enable this as soon as valgrind and glibc can sort out their differences
> on ppc.

Sorry this is taking so long. There is some progress on the upstream bug
https://bugs.kde.org/show_bug.cgi?id=386945 (Bogus memcheck errors on ppc64(le)
when using strcmp() with gcc-7), but it isn't complete yet (it might require a
slight change in code generation on the gcc side too).

Should we keep this bug open till the upstream bug is resolved and backported
to valgrind, or do you like me to create a new bug for that?

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

Re: Broken system upgrade due to rich dependencies

2018-03-07 Thread Neal Gompa

On Wed, Mar 7, 2018 at 5:52 AM, Igor Gnatenko
 wrote:
> And you forgot:
> 5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
> proper way).
>

This has been requested for a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=1032541

It'd be *really* good if DNF implemented it.



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

Re: systemd 238 and sysusers

2018-03-07 Thread Florian Weimer


On 03/07/2018 01:55 PM, Stephen Gallagher wrote:

Yes, SSSD monitors those files and automatically cleans its cache.

However, you're right. On systems not using SSSD (which I suspect is a
nontrivial number of systems running systemd...), people are probably still
using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
where appropriate) if the nscd service is running.


nscd is supposed to monitor these files, too.

But is this monitoring sufficient?  RPM will immediately start 
installing files after the scriptlet has finished.  nscd and SSSD may 
not have completed their cache invalidation at this point, so this looks 
like a race condition to me.


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

Re: systemd 238 and sysusers

2018-03-07 Thread Stephen Gallagher

On Wed, Mar 7, 2018 at 5:56 AM Tom Hughes  wrote:

> On 07/03/18 10:46, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 10:28:58AM +, Tom Hughes wrote:
> >> On 07/03/18 10:10, Florian Weimer wrote:
> >>> On 03/06/2018 03:24 PM, Zbigniew JÄ™drzejewski-Szmek wrote:
>  It's a very simple tool to create system users and group in
> /etc/passwd.
>  It just creates entries in/etc/{passwd,group,shadow}, and does not
>  interact with audit in any way afaik.
> >>>
> >>> Does it perform any locking or cache invalidation?
> >>
> >> It appears to do locking:
> >>
> >>
> https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953
> >>
> >> which is calling:
> >>
> >>
> https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548
> >>
> >> which takes a write lock on /etc/.pwd.lock around everything.
> > Ack.
> >
> > Cache invalidation? I'm not sure what you mean, it just replaces the
> > file atomically and syncs the file system.
>
> Well historically nscd I guess though I think sssd is supposed to
> have replaced that now?
>
> I believe sssd watches the files with inotify and does it's own
> cache invalidation - a quick test with strace suggests it notices
> when I edit the groups file with vi.
>

Yes, SSSD monitors those files and automatically cleans its cache.

However, you're right. On systems not using SSSD (which I suspect is a
nontrivial number of systems running systemd...), people are probably still
using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
where appropriate) if the nscd service is running.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

On Wed, Mar 07, 2018 at 01:07:15PM +0100, Steve Grubb wrote:
> On Tue, 6 Mar 2018 16:31:29 +
> Zbigniew Jędrzejewski-Szmek  wrote:
> 
> > > > > > How does this interact with useradd and groupadd? Does this
> > > > > > replace them? And if so, does this send the required audit
> > > > > > events?
> > > > >
> > > > > It's a very simple tool to create system users and group
> > > > > in /etc/passwd. It just creates entries
> > > > > in /etc/{passwd,group,shadow}, and does not interact with audit
> > > > > in any way afaik.   
> > > > 
> > > > Is there some guideline that requires an audit log message to
> > > > occur whenever a user is added to a system?  
> > > 
> > > Yes. Absolutely. Even if that user is a system account.
> > >   
> > > > We can't necessarily know on every end-user system when a user is
> > > > added by a central authority like FreeIPA, for example.  
> > > 
> > > That also has to be audited.
> > >   
> > > > Even if we only limit it to dealing with /etc/passwd and friends,
> > > > there are still plenty of ways for this file to be modified that
> > > > wouldn't cause it to trigger an audit event unless we added a
> > > > service to monitor with inotify or similar.  
> > > 
> > > True. And we do include rules to catch these occurrences. But this
> > > not the preferred way because it does not give us the full
> > > information that is required. If we know that we are adding user
> > > accounts, we need to maintain the information for the whole
> > > lifecycle. If FreeIPA adds an account, it gets used and trips some
> > > audit events, then gets removed, we need the history of when it was
> > > added and when it was removed and by who.  
> > 
> > I assume that there some standarized log message to be emitted in this
> > case? If this is documented somewhere, we could add that, although
> > it'd probably be easier if somebody who knows audit submitted a pull
> > request. The sysusers code is at
> > https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1205.
> 
> It will take me a couple days to get to this, but its simple enough I
> can just add the events. This trick is that they must match exactly
> the same format that shadow-utils sends. (I also wrote the patch for
> shadow-utils.)
Cool, thanks!

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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Sandro Mani


On 07.03.2018 08:43, Igor Gnatenko wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is the second iteration of my mass-scratch-rebuild without
gcc/gcc-c++ in the buildroot[0]. Everything what was written in
original mail still applies.

Since people might have fixed their packages after I started rebuild, I
decided to include information about commits I have used to build
packages. Hope this helps.

Are this all actual build failures, or were the build.logs scanned for 
 errors regardless of whether the build succeded?


I.e. mmg3d reports "No CMAKE_CXX_COMPILER could be found.", but mmg3d is 
a pure C library, so I suppose it is just cmake which checks for a c++ 
compiler regardless of whether it is used or not. But the build should 
have succeded regardless of the presence of g++.

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

[Bug 1552598] New: perl-Number-Fraction-2.01 is available

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

Bug ID: 1552598
   Summary: perl-Number-Fraction-2.01 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Number-Fraction
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.01
Current version/release in rawhide: 2.00-7.fc28
URL: http://search.cpan.org/dist/Number-Fraction/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/9046/

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

Re: systemd 238 and sysusers

2018-03-07 Thread Steve Grubb

On Tue, 6 Mar 2018 16:31:29 +
Zbigniew Jędrzejewski-Szmek  wrote:

> > > > > How does this interact with useradd and groupadd? Does this
> > > > > replace them? And if so, does this send the required audit
> > > > > events?
> > > >
> > > > It's a very simple tool to create system users and group
> > > > in /etc/passwd. It just creates entries
> > > > in /etc/{passwd,group,shadow}, and does not interact with audit
> > > > in any way afaik.   
> > > 
> > > Is there some guideline that requires an audit log message to
> > > occur whenever a user is added to a system?  
> > 
> > Yes. Absolutely. Even if that user is a system account.
> >   
> > > We can't necessarily know on every end-user system when a user is
> > > added by a central authority like FreeIPA, for example.  
> > 
> > That also has to be audited.
> >   
> > > Even if we only limit it to dealing with /etc/passwd and friends,
> > > there are still plenty of ways for this file to be modified that
> > > wouldn't cause it to trigger an audit event unless we added a
> > > service to monitor with inotify or similar.  
> > 
> > True. And we do include rules to catch these occurrences. But this
> > not the preferred way because it does not give us the full
> > information that is required. If we know that we are adding user
> > accounts, we need to maintain the information for the whole
> > lifecycle. If FreeIPA adds an account, it gets used and trips some
> > audit events, then gets removed, we need the history of when it was
> > added and when it was removed and by who.  
> 
> I assume that there some standarized log message to be emitted in this
> case? If this is documented somewhere, we could add that, although
> it'd probably be easier if somebody who knows audit submitted a pull
> request. The sysusers code is at
> https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1205.

It will take me a couple days to get to this, but its simple enough I
can just add the events. This trick is that they must match exactly
the same format that shadow-utils sends. (I also wrote the patch for
shadow-utils.)

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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Jonathan Dieter

On Wed, 2018-03-07 at 08:43 +0100, Igor Gnatenko wrote:
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.


I've done lizardfs, naev, novacom-client, and novacom-server.

Jonathan

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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Tom Hughes


On 07/03/18 07:43, Igor Gnatenko wrote:


This is the second iteration of my mass-scratch-rebuild without
gcc/gcc-c++ in the buildroot[0]. Everything what was written in
original mail still applies.


Fixed rapidjson.

Tom

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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Alec Leamas




> On Wed, 07 Mar 2018 08:43:21 +0100
> Igor Gnatenko  wrote:
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.
>
> Since people might have fixed their packages after I started rebuild,
> I decided to include information about commits I have used to build
> packages. Hope this helps.
>
>
> New list of packages, their commits and build logs are available:
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
>

Fixed tonto and DecodeIR

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

Re: systemd 238 and sysusers

2018-03-07 Thread Tom Hughes


On 07/03/18 10:46, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Mar 07, 2018 at 10:28:58AM +, Tom Hughes wrote:

On 07/03/18 10:10, Florian Weimer wrote:

On 03/06/2018 03:24 PM, Zbigniew JÄ™drzejewski-Szmek wrote:

It's a very simple tool to create system users and group in /etc/passwd.
It just creates entries in/etc/{passwd,group,shadow}, and does not
interact with audit in any way afaik.


Does it perform any locking or cache invalidation?


It appears to do locking:

https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953

which is calling:

https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548

which takes a write lock on /etc/.pwd.lock around everything.

Ack.

Cache invalidation? I'm not sure what you mean, it just replaces the
file atomically and syncs the file system.


Well historically nscd I guess though I think sssd is supposed to
have replaced that now?

I believe sssd watches the files with inotify and does it's own
cache invalidation - a quick test with strace suggests it notices
when I edit the groups file with vi.

Tom

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

Re: Broken system upgrade due to rich dependencies

2018-03-07 Thread Igor Gnatenko

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-03-07 at 10:40 +, Jaroslav Mracek wrote:
> Recently, several users report problems with system upgrade due to
> rich dependencies that are not supported by RPM in Fedora 25, and not
> fully supported by RPM in Fedora 26 (statement 'with'). Rich
> dependencies are allowed and supported from Fedora 26, but during the
> System Upgrade from Fedora 25 the transaction is checked by RPM that
> doesn't support rich dependencies, therefore the transaction check
> performed by RPM fails. A similar situation can be experienced for
> System Upgrade from Fedora 26 where RPM is unable to handle rich
> dependency using "with" statement (https://bugzilla.redhat.com/show_b
> ug.cgi?id=1551543). In future we can expect that more and more users
> will be affected by the problem due to increase of rich dependencies
> in Fedora 26-28. I realize that there were similar issue discussed in
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/#7JWQ2TFDFYNCQFJBMOAQF
> IPDP4XCYLVC, but it does not cover user point o
>  f view.
> 
> Possible solution:
> 1. Back-port support of "with" key word in rich dependencies into
> Fedora 26 (solves only upgrades from 26 to 27, and 26 to 28.)

This is no-go, there are more incompatible changes in RPM.

> 2. Ban rich dependencies in Fedora 26, and 27, and in 28 only rich
> deps using "with" statement (solves all issues)

Thanks, no.

> 3. Provide a copr repo with RPM for Fedora 25, and 26 that support
> all rich dependencies (user unfriendly)

Agree, this is not "official" way of doing system upgrades.

> 4. Disable rich dependency check in RPM release for Fedora 26 (solves
> only upgrades from 26 to 27, and 26 to 28.)

I have proposed this to DNF team already, but nothing happened.

And you forgot:
5. Teach DNF to use "target" DNF/RPM stack to perform upgrade (best and
proper way).

> The issue can be experienced in following system upgrade
> combinations: 25 to 26, 25 to 27,  26 to 27, 26 to 28.
> The list of Fedora 27 and 28 packages with incompatible rich deps - h
> ttps://bugzilla.redhat.com/show_bug.cgi?id=1552547

Once more, this issue is not only about rich dependencies:
> The maximum supported header size was significantly raised in this
release. This cannot be tracked with rpmlib() dependencies as that
requires accessing the header, so attempting to access packages with
larger than 32MB header will just abruptly fail with ALL older rpm
versions.

So if you use RPM 4.13 to install RPM 4.14-built package which happen
to have such large header, RPM would simply crash. Solutions 1-4 are
not sustainable, #5 is.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqfxGoACgkQaVcUvRu8
X0zxaRAAkIrFRnMxIZNPNlJqNWRcNwuqbWODwgRfwEUUv2JDEb6tY5z5L/2faZI2
xOpMfQJhx+7qx49yudAS9TbIQsHla1ffQA8YWgH+jxmLARGVlciklcpuoY4DobAQ
hbxbhewIyoK1xM72P/+XYUBu1yAhjsDEem3nZ/Fi/YJgIoJ0kABPgwf168LFQSjG
nUIZ50989p8uT0q/gtdIAGQrhLfxjWZQIBIZF+ctrq2TQr3Ag9zJaocysJBXtyCo
z0zFFN1mZuXHl+zpynGRK9/FmhlTVC/+83om3eM7HmqCv/xDcLdj+HU0NDYJJPJz
nB4/HVs6HLhvkB3FPODjxEc7jmQ51JT4Pz+cZMXggOiXW9qVEEm0H8afbxjZcDje
jZxuDfvNoD92uFG9iZOSPFLv3DfstcYNsGABu9lK+Ust/+++o6+a1XYgdvrd+8L+
dt9qANVyguZQYO0afFZ/gEjOwGoFQUk0AuGyMe30iVDUi203b5lQCebeN0rz8hE6
KtxKKEO23rD3hFG7WyVYUc8+ot2KYkG/WsS7JzlDTt5I8hlq7uJ2eWCnTpua/7ew
Lz+lc8ZgHe9mkwboMZtGGbsRWesQBU6tzYcwu1XP7apvM4iA+gniGngf6QgeJrcr
tEj90kl98tnE36CE1xszihBOtniqEKCq5kpR8a6MBekKZQX7HlM=
=Xl8n
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

On Wed, Mar 07, 2018 at 10:28:58AM +, Tom Hughes wrote:
> On 07/03/18 10:10, Florian Weimer wrote:
> >On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>It's a very simple tool to create system users and group in /etc/passwd.
> >>It just creates entries in/etc/{passwd,group,shadow}, and does not
> >>interact with audit in any way afaik.
> >
> >Does it perform any locking or cache invalidation?
> 
> It appears to do locking:
> 
> https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953
> 
> which is calling:
> 
> https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548
> 
> which takes a write lock on /etc/.pwd.lock around everything.
Ack.

Cache invalidation? I'm not sure what you mean, it just replaces the
file atomically and syncs the file system.

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

Broken system upgrade due to rich dependencies

2018-03-07 Thread Jaroslav Mracek

Recently, several users report problems with system upgrade due to rich
dependencies that are not supported by RPM in Fedora 25, and not fully
supported by RPM in Fedora 26 (statement 'with'). Rich dependencies are allowed
and supported from Fedora 26, but during the System Upgrade from Fedora 25 the
transaction is checked by RPM that doesn't support rich dependencies, therefore
the transaction check performed by RPM fails. A similar situation can be
experienced for System Upgrade from Fedora 26 where RPM is unable to handle
rich dependency using "with" statement
(https://bugzilla.redhat.com/show_bug.cgi?id=1551543). In future we can expect
that more and more users will be affected by the problem due to increase of
rich dependencies in Fedora 26-28. I realize that there were similar issue
discussed in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/#7JWQ2TFDFYNCQFJBMOAQFIPDP4XCYLVC,
but it does not cover user point o
f view.

Possible solution:
1. Back-port support of "with" key word in rich dependencies into Fedora 26
(solves only upgrades from 26 to 27, and 26 to 28.)
2. Ban rich dependencies in Fedora 26, and 27, and in 28 only rich deps using
"with" statement (solves all issues)
3. Provide a copr repo with RPM for Fedora 25, and 26 that support all rich
dependencies (user unfriendly)
4. Disable rich dependency check in RPM release for Fedora 26 (solves only
upgrades from 26 to 27, and 26 to 28.)

The issue can be experienced in following system upgrade combinations: 25 to
26, 25 to 27, 26 to 27, 26 to 28.
The list of Fedora 27 and 28 packages with incompatible rich deps -
https://bugzilla.redhat.com/show_bug.cgi?id=1552547

Best regards

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

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

2018-03-07 Thread Paul Howarth

On Wed, 07 Mar 2018 08:43:21 +0100
Igor Gnatenko  wrote:
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.
> 
> Since people might have fixed their packages after I started rebuild,
> I decided to include information about commits I have used to build
> packages. Hope this helps.
> 
> 
> New list of packages, their commits and build logs are available:
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt

Fixed perl-Clone and perl-Text-Aspell.

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

Re: systemd 238 and sysusers

2018-03-07 Thread Tom Hughes


On 07/03/18 10:10, Florian Weimer wrote:

On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:

It's a very simple tool to create system users and group in /etc/passwd.
It just creates entries in/etc/{passwd,group,shadow}, and does not
interact with audit in any way afaik.


Does it perform any locking or cache invalidation?


It appears to do locking:

https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953

which is calling:

https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548

which takes a write lock on /etc/.pwd.lock around everything.

Tom

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

Re: systemd 238 and sysusers

2018-03-07 Thread Florian Weimer


On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:

It's a very simple tool to create system users and group in /etc/passwd.
It just creates entries in/etc/{passwd,group,shadow}, and does not
interact with audit in any way afaik.


Does it perform any locking or cache invalidation?

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

Re: Critpath karma

On Tue, Mar 06, 2018 at 04:20:26PM -0800, Adam Williamson wrote:
> 1. Any update that is marked as 'critpath breaking' by a FAS-registered 
> tester would be blocked from going any further in the update process
> without manual intervention (no autopushes at all)

IIRC, that happens with all updates now: any negative karma disables
autopush, right?

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

[Bug 1552358] perl-Test2-Suite-0.000106 is available

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



--- Comment #2 from Fedora Update System  ---
perl-Test-Simple-1.302128-1.fc28 perl-Test2-Suite-0.000106-1.fc28 has been
submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4420e51431

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

Re: Frequently broken Rawhide/Branched composes

2018-03-07 Thread Pierre-Yves Chibon

On Tue, Mar 06, 2018 at 12:56:56PM -0500, Randy Barlow wrote:
> On 03/03/2018 01:34 PM, Kevin Kofler wrote:
> > That is due to the "Rawhide can never go backwards" policy, which I still 
> > do 
> > not understand the point of, especially in the light of "distro-sync" 
> > having 
> > been supported by both the old yum and the new dnf for years.
> 
> Sometimes an updated package makes changes to its data structures. For
> example, consider if the package does some kind of migration to its data
> in such a way that the new version can read it, but the old cannot (e.g.
> a PostgreSQL upgrade, and IIRC the Firefox discussion from a while ago
> also noted that it cannot be downgraded in all cases). Thus, distro-sync
> doesn't work in all cases if the upgraded package has already made
> changes on the user's system.

What this tells me is that not all updates, even if they break things, will be
revertable, and for these, it's status quo with what we have today.
Allowing downgrade of updates that can be reverted would give us a little more
flexibility. We'll just have to keep in mind that not everything will be
revertable, which means we'll likely not be able to automatically rollback.

That doesn't sound too bad though, does it?


Pierre


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

[Bug 1552358] perl-Test2-Suite-0.000106 is available