[Bug 1469110] perl-Text-Fuzzy-0.26 is available

[bugzilla]

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



--- Comment #9 from Upstream Release Monitoring 
 ---
releng's perl-Text-Fuzzy-0.26-3.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=949748

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 758  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 752  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 642  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 614  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 224  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 120  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e8124f23c8   
heimdal-7.4.0-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-515cca9a02   
GraphicsMagick-1.3.26-3.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-99fb0d61b0   
chicken-4.12.0-3.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ab5ed7f894   
python-tablib-0.11.5-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-70562ba4d2   
python-django-ckeditor-5.3.0-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f4a2132f26   
seamonkey-2.48-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b1d8b4aed9   
globus-ftp-client-8.36-1.el6 globus-ftp-control-7.8-1.el6 
globus-gass-cache-program-6.7-1.el6 globus-gass-copy-9.27-1.el6 
globus-gram-client-13.19-1.el6 globus-gram-job-manager-14.36-1.el6 
globus-gram-job-manager-condor-2.6-5.el6 globus-gridftp-server-12.2-1.el6 
globus-gridftp-server-control-5.1-1.el6 globus-gssapi-gsi-12.17-3.el6 
globus-io-11.9-1.el6 globus-net-manager-0.17-1.el6 globus-xio-5.16-1.el6 
globus-xio-gsi-driver-3.11-1.el6 globus-xio-pipe-driver-3.10-1.el6 
globus-xio-udt-driver-1.28-1.el6 myproxy-6.1.28-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-72e0f4a914   
php-horde-Horde-Core-2.30.0-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2a557f0b9c   
php-horde-Horde-Form-2.0.18-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3e60244bf3   
php-horde-Horde-Url-2.2.6-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4340a6e0a8   
php-horde-horde-5.2.16-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4654acd4ee   
php-horde-kronolith-4.2.22-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-19c0b8ff89   
php-horde-nag-4.2.15-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5b8e6e0279   
php-horde-turba-4.2.20-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d015ef3016   
gsoap-2.7.16-5.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cbc54495c7   
qpdf-5.1.1-3.el6


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

libdirq-0.5-1.el6

Details about builds:



 libdirq-0.5-1.el6 (FEDORA-EPEL-2017-cef1a3c96f)
 C implementation of the simple directory queue algorithm

Update Information:

Upgraded to upstream version 0.5.

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

Re: Discontinuing Phabricator

[Adam Williamson]

On Fri, 2017-08-04 at 22:41 +0200, Josef Skladanka wrote:
> As you all probably know, we decided that keeping Phab up and running is
> not the best use of our - rather limited, and shrinking - resources, so we
> moved all our projects to Pagure. Yay!
> 
> As of now, all (relevant) tickes are moved to Pagure, and we have the
> Differential revisions archived as html snapshots here:
> https://fedorapeople.org/groups/qa/phabarchive/differentials/phab.qa.fedoraproject.org/
> (note that this is not the final version, once kparal gets to update it,
> the "download raw diff" links will provide you with just that).
> 
> Links between tickets, and ticket dependencies are hopefully moved too, as
> are the references for the Differential revisions tied to that ticket - I
> was able to manually check a few tickets, and "it was fine" (tm). In
> phabricator, ticket could be a part of multiple projects (like execdb +
> resultsdb + libtaskotron) - we (kparal mostly) cleaned up quite a deal of
> those, but some still made sense to keep. Pagure can not represent these,
> so I ended up duplicating the tickets. Such tickets' first comment (or some
> of the few first comments) says "This is a duplicate of ..." - meaning just
> that this was part of several projects and the referenced ticket is just
> the same.
> 
> This also means, that as of now, we won't be actively taking part in
> maintaining, or using Phabricator. We are still to decide on a reasonable
> way to do code reviews, so any tips on the topic are more than welcomed. If
> you have some un-merged differential revisions, that you'd like to see
> taken care of, please create a pull request, and mention that it is WRT to
> a specific diff.
> 
> I'm sad to see this great tool go, hopefully, we'll be able to make decent
> use of Pagure.

Thanks a lot for all your work on this, Josef!

Just in case it's still of any use, I still have the pad we (RH folks)
were using to keep note of things we would like improved in Pagure
open:

https://etherpad.gnome.org/p/pagure-rough-edges

since I (oh so naively) thought I might have time to actually work on
some of them. Of course, I didn't. But at least it means I still have
the URL! So we can keep collating things there and maybe (har, har)
find some time to help implement them in future.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 879  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 642  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 224  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 122  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 120  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f9a6163b4   
tnef-1.4.14-1.el7
 119  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-47be021843   
heimdal-7.4.0-1.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a8886eb42e   
cross-binutils-2.27-9.el7.1 cross-gcc-4.8.5-16.el7.1
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c39b9065fa   
GraphicsMagick-1.3.26-3.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c4e53cc90d   
chicken-4.12.0-3.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1024674dfb   
moodle-3.1.7-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b39314b704   
mingw-c-ares-1.13.0-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2c3a1062a0   
seamonkey-2.48-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b50572c103   
sscep-0.6.1-5.20160525git2052ee1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4908d32c3c   
python-dbusmock-0.11.1-6.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-017fbc40e8   
supervisor-3.1.4-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b6bc17c1   
globus-ftp-client-8.36-1.el7 globus-ftp-control-7.8-1.el7 
globus-gass-cache-program-6.7-1.el7 globus-gass-copy-9.27-1.el7 
globus-gram-client-13.19-1.el7 globus-gram-job-manager-14.36-1.el7 
globus-gram-job-manager-condor-2.6-5.el7 globus-gridftp-server-12.2-1.el7 
globus-gridftp-server-control-5.1-1.el7 globus-gssapi-gsi-12.17-3.el7 
globus-io-11.9-1.el7 globus-net-manager-0.17-1.el7 globus-xio-5.16-1.el7 
globus-xio-gsi-driver-3.11-1.el7 globus-xio-pipe-driver-3.10-1.el7 
globus-xio-udt-driver-1.28-1.el7 myproxy-6.1.28-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-37e736147d   
knot-2.5.3-2.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-94c168d702   
php-horde-Horde-Core-2.30.0-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7d6b89ab36   
php-horde-Horde-Form-2.0.18-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-359039e1f1   
php-horde-Horde-Url-2.2.6-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-aebd466ffa   
php-horde-horde-5.2.16-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-531b8ee43e   
php-horde-kronolith-4.2.22-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-055fdcdee7   
php-horde-nag-4.2.15-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bad0726ae5   
php-horde-turba-4.2.20-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-886e003d48   
gsoap-2.8.16-9.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-816da4b59a   
ReviewBoard-2.5.14-2.el7 python-djblets-0.9.9-1.el7


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

ReviewBoard-2.5.14-2.el7
bodhi-2.9.0-1.el7
modularity-testing-framework-0.5.1-3.el7
python-djblets-0.9.9-1.el7

Details about builds:



 ReviewBoard-2.5.14-2.el7 (FEDORA-EPEL-2017-816da4b59a)
 Web-based code review tool

Update Information:

https://www.reviewboard.org/docs/releasenotes/reviewboard/2.5.14/  Start using
Pygments 2.2 for syntax highlighting




 bodhi-2.9.0-1.el7 (FEDORA-EPEL-2017-5344219d81)
 A modular framework that facilitates publishing software updates

Update Information:

Update to [2.9.0](https://github.com/fedora-infra/bodhi/releases/tag/2.9.0).

References:

  [ 1 ] Bug #1477579 - bodhi-2.9.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1477579




 modularity-testing-framework-0.5.1-3.el7 (FEDORA-EPEL-2017-9c6fc8c4a8)
 Framework for writing tests for modules and containers

Discontinuing Phabricator

[Josef Skladanka]

As you all probably know, we decided that keeping Phab up and running is
not the best use of our - rather limited, and shrinking - resources, so we
moved all our projects to Pagure. Yay!

As of now, all (relevant) tickes are moved to Pagure, and we have the
Differential revisions archived as html snapshots here:
https://fedorapeople.org/groups/qa/phabarchive/differentials/phab.qa.fedoraproject.org/
(note that this is not the final version, once kparal gets to update it,
the "download raw diff" links will provide you with just that).

Links between tickets, and ticket dependencies are hopefully moved too, as
are the references for the Differential revisions tied to that ticket - I
was able to manually check a few tickets, and "it was fine" (tm). In
phabricator, ticket could be a part of multiple projects (like execdb +
resultsdb + libtaskotron) - we (kparal mostly) cleaned up quite a deal of
those, but some still made sense to keep. Pagure can not represent these,
so I ended up duplicating the tickets. Such tickets' first comment (or some
of the few first comments) says "This is a duplicate of ..." - meaning just
that this was part of several projects and the referenced ticket is just
the same.

This also means, that as of now, we won't be actively taking part in
maintaining, or using Phabricator. We are still to decide on a reasonable
way to do code reviews, so any tips on the topic are more than welcomed. If
you have some un-merged differential revisions, that you'd like to see
taken care of, please create a pull request, and mention that it is WRT to
a specific diff.

I'm sad to see this great tool go, hopefully, we'll be able to make decent
use of Pagure.

Josef

P.S. if you feel brave enough, feel free to have a look at the junk-code
that made this possible at https://pagure.io/fedora-qa/phabarchive/
(disclaimer - the code should die in fire!)
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

[389-devel] Please review: Issue 83 - Add an util for generating instance parameters

[Simon Pichugin]

Hi team,
please, review a new patch for big topology refactoring.
I'll add a patch for 389-ds-base tests before the pushing it.

https://pagure.io/lib389/issue/83
https://pagure.io/lib389/issue/raw/files/57003067766f1a08da96060e1d51e95583cc5a43ef98d73991fb2576a50501ce-0001-Issue-83-Add-an-util-for-generating-instance-paramet.patch

Thanks,
Simon


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

Re: heads up: poppler soname bump

[Adam Williamson]

On Wed, 2017-08-02 at 13:19 +0200, David Tardon wrote:
> Hi,
> 
> I will build a new release of poppler this week, which includes soname
> bump. I will take care of rebuilding the affected packages:
> 
> boomaga
> calligra
> cups-filters
> evas-generic-loaders
> gambas3
> gdal
> gdcm
> inkscape
> kf5-kfilemetadata
> libreoffice
> okular
> pdf2djvu
> poppler-sharp
> texlive
> texworks

Welp, the rebuild of texlive failed, which means gdal can't be built,
and I can't build openqa. And none of this seems to have been touched
since yesterday, so now it's probably going to be stuck over the
weekend, right?

Perhaps next time, you could test rebuilds of at least major things
like texlive against the new poppler *before* you land the new poppler
into rawhide? Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Stub python packages for EPEL

[Jason L Tibbitts III]

> "KF" == Kevin Fenzi  writes:

KF> I don't think we have any way to find out the version of a package
KF> in all channels. At least I don't know of such a way. So, I think we
KF> should concern ourselves with only the channels that EPEL says it
KF> will try and not conflict with.

I don't even know what those are, really.  All I know is what I can
extract from those json files, and what CentOS has.  Certainly limiting
things to what EPEL can see is the only reasonable way; I was just
trying to hedge against the fact that I can't see what's in 

KF> So, yeah, we would need to make sure and retire the epel package as
KF> soon as rhel started providing a source package with the same name.

I think it is somewhat unlikely that RHEL would begin providing any
python2-X source packages where they currently provide python-X source
packages.  I guess it's possible, though, and it's something we'd have
to deal with immediately if it ever happens.  However, it shouldn't
cause issues for end-user systems in that case, only the EPEL builders,
and for those the fix is very quick (block in koji and wait for a newrepo).

KF> I'm in favor... lets give it a try with some of the common ones. :)

Thanks; I have a list of four I'm starting with, listed at the end of
https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages

I hope that once in this will make life easier for someone.

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

Re: BTRFS dropped by RedHat

[Peter Robinson]

On Fri, Aug 4, 2017 at 7:35 PM, Tomasz Torcz  wrote:
> On Fri, Aug 04, 2017 at 06:43:51PM +0200, David Sommerseth wrote:
>> On 04/08/17 18:06, Neal Gompa wrote:
>> > On Fri, Aug 4, 2017 at 11:23 AM, Fernando Nasser  
>> > wrote:
>> >> On 2017-08-04 11:12 AM, Przemek Klosowski wrote:
>> >>
>> >> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
>> >>
>> >>
>> >> Is it only RHEL?
>> >>
>> >> What are other distros doing?
>> >>
>> >
>> > It is only RHEL, but unfortunately that has a *huge* knock on effect
>> > across hundreds of derivative distribution projects and products.
>> >
>> > It's an enormous problem that they're doing this...
>>
>> Hmmm, that sounds backwards to me.   I would say it is more a problem
>> that Btrfs haven't reached a stability/trust level over so many years
>> which makes Enterprise Linux considering to use it.  To me this more
>> indicates the overall state of Btrfs.
>
>   There's more to Enteprise Linux than Red Hat. SUSE is happy
> to support subset of btrfs' features for enterprise distribution..
>
>> I certainly do hope that Btrfs development doesn't slow down by this,
>> rather that the pace gets improved and it will come back again in
>> stronger and more solid during a future RHEL 8 release.
>
>   Red Hat has none (I think) developers working on btrfs. So btrfs
> development speed is not affected by this. At all.

No, but the ability to support it and to backport fixes and new
functionality to the enterprise kernel would be.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: BTRFS dropped by RedHat

[Mauricio Tavares]

On Fri, Aug 4, 2017 at 11:48 AM, Neal Gompa  wrote:
>
> I'm not particularly pleased with their decision. I think the path
> they're going down is wrong, and they should really reconsider.
> However, I'm reading over their Stratis whitepaper before I formulate
> a response about it.
>
> I don't think they fully understand how the Stratis path cannot
> replace what Btrfs gives you, and the irony about this is that the
> Btrfs developers been working on fixing the major remaining issues
> with RAID this year and it looks like it'll be much better next year.
>
> All of my CentOS 7 servers (and my one RHEL 7 box) use Btrfs, because
> it's so much better than the alternatives.
>
  Better than ZFS?
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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: BTRFS dropped by RedHat

[Tomasz Torcz]

On Fri, Aug 04, 2017 at 06:43:51PM +0200, David Sommerseth wrote:
> On 04/08/17 18:06, Neal Gompa wrote:
> > On Fri, Aug 4, 2017 at 11:23 AM, Fernando Nasser  wrote:
> >> On 2017-08-04 11:12 AM, Przemek Klosowski wrote:
> >>
> >> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
> >>
> >>
> >> Is it only RHEL?
> >>
> >> What are other distros doing?
> >>
> > 
> > It is only RHEL, but unfortunately that has a *huge* knock on effect
> > across hundreds of derivative distribution projects and products.
> > 
> > It's an enormous problem that they're doing this...
> 
> Hmmm, that sounds backwards to me.   I would say it is more a problem
> that Btrfs haven't reached a stability/trust level over so many years
> which makes Enterprise Linux considering to use it.  To me this more
> indicates the overall state of Btrfs.

  There's more to Enteprise Linux than Red Hat. SUSE is happy
to support subset of btrfs' features for enterprise distribution..
 
> I certainly do hope that Btrfs development doesn't slow down by this,
> rather that the pace gets improved and it will come back again in
> stronger and more solid during a future RHEL 8 release.

  Red Hat has none (I think) developers working on btrfs. So btrfs
development speed is not affected by this. At all.

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: BTRFS dropped by RedHat

[Gerald B. Cox]

On Fri, Aug 4, 2017 at 10:18 AM, Richard Hughes  wrote:

> On 4 August 2017 at 16:46, Solomon Peachy  wrote:
> > ...it fails the most basic requirement of a filesystem -- to not
> > eat data.
>
> Me also; I've tried btfs three times now -- in one case telling me I
> had no free space after a few weeks when clearly there was tens GBs
> free, one time needing to wipe and reformat as writes trudged to a few
> thousand bytes per second and and the other time destroying my
> file-system when I ran out of battery power. I think "it's getting
> better, we promise" only works for so many years. I've never had a
> problem with EXT3/4 or with XFS. YMMV.
>

Yeah... I was very excited about RAID 6 capability and starting using it in
2013.  I took all the necessary precautions, backups, etc. and never lost
data.  I waited and waited for it to be declared stable and followed the
mailing list threads.  Then the announcement came in July 2016 that RAID
5/6 was toxic and a year later, it's still not fixed.  That was it for me
and I switched to XFS and counted my blessings I wasn't burnt as some
people have been.  Then there was this:  https://www.patreon.com/bcachefs
and this:  https://www.youtube.com/watch?v=79fvDDPaIoY=18m28s

I believe it's a good decision on Redhat's part.  At some point you have to
fish or cut bait.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: BTRFS dropped by RedHat

[Richard Hughes]

On 4 August 2017 at 16:46, Solomon Peachy  wrote:
> ...it fails the most basic requirement of a filesystem -- to not
> eat data.

Me also; I've tried btfs three times now -- in one case telling me I
had no free space after a few weeks when clearly there was tens GBs
free, one time needing to wipe and reformat as writes trudged to a few
thousand bytes per second and and the other time destroying my
file-system when I ran out of battery power. I think "it's getting
better, we promise" only works for so many years. I've never had a
problem with EXT3/4 or with XFS. YMMV.

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

Re: BTRFS dropped by RedHat

[David Sommerseth]

On 04/08/17 18:06, Neal Gompa wrote:
> On Fri, Aug 4, 2017 at 11:23 AM, Fernando Nasser  wrote:
>> On 2017-08-04 11:12 AM, Przemek Klosowski wrote:
>>
>> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
>>
>>
>> Is it only RHEL?
>>
>> What are other distros doing?
>>
> 
> It is only RHEL, but unfortunately that has a *huge* knock on effect
> across hundreds of derivative distribution projects and products.
> 
> It's an enormous problem that they're doing this...

Hmmm, that sounds backwards to me.   I would say it is more a problem
that Btrfs haven't reached a stability/trust level over so many years
which makes Enterprise Linux considering to use it.  To me this more
indicates the overall state of Btrfs.

I certainly do hope that Btrfs development doesn't slow down by this,
rather that the pace gets improved and it will come back again in
stronger and more solid during a future RHEL 8 release.

-- 
kind regards,

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

Re: Adding program to Software Center

[Richard Hughes]

On 4 August 2017 at 08:54, Vít Ondruch  wrote:
> Heh .. things always happens in the wrong time ;) Checking g-s with the
> appstream-data-27-4.fc27, I can see "Amazon Cloud Player" listed under
> Nuvola, so this looks promising.

Good stuff.

> BTW could you please take a look at "eu.tiliado.Nuvola.desktop" listed
> in [1]. It states "Vetosduplicate of nuvolaruntime-4.5.0-4.fc27". It
> seems that this relates to the rename from nuvolaplayer to
> nuvolaruntime. I'd say that nuvolaplayer was correctly obsoleted, it is
> retired in pkgdb and it should be blocked in Koji. Is it correctly
> handled from AppData POV?

When generating the AppStream XML I just point the generator at a
level 2 mirror, so that's sometimes several days behind. Once the
package is gone from the repo then it will no longer be processed by
the generator.

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

Re: BTRFS dropped by RedHat

[Neal Gompa]

On Fri, Aug 4, 2017 at 11:23 AM, Fernando Nasser  wrote:
> On 2017-08-04 11:12 AM, Przemek Klosowski wrote:
>
> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
>
>
> Is it only RHEL?
>
> What are other distros doing?
>

It is only RHEL, but unfortunately that has a *huge* knock on effect
across hundreds of derivative distribution projects and products.

It's an enormous problem that they're doing this...

-- 
真実はいつも一つ！/ 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: BTRFS dropped by RedHat

[František Zatloukal]

Some insight why was BTRFS dropped by RH:
https://news.ycombinator.com/item?id=14907771

Also check out Stratis:
https://fedoraproject.org/wiki/Changes/StratisStorage

2017-08-04 17:12 GMT+02:00 Przemek Klosowski :

> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_
> Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
>
> Btrfs has been deprecated
>
> The Btrfs file system has been in Technology Preview state since the
> initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving
> Btrfs to a fully supported feature and it will be removed in a future major
> release of Red Hat Enterprise Linux.
> The Btrfs file system did receive numerous updates from the upstream in
> Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat
> Enterprise Linux 7 series. However, this is the last planned update to this
> feature.
>
> I think RH roadmap is to use XFS over LVM.
>
> This is a pity---BTRFS features looked attractive:
>
> - integrated RAID that ties low level (block/stripe) issues with
> high-level objects (files); I thought this is important because with brfs
> filesystem integrity features filesystem-level trouble could be tied to low
> level issues like silent failures on one raid element. This is important
> and unique: I had seen failures of large volumes both on proprietary RAID
> hardware and in software RAID, due to silent corruption of one element of
> the array, that propagated to other healthy elements.
>
> - snapshotting/rollbacks that enable recovery system update failures and
> other nice functionality
>
> - scalable support for really large file systems (reasonable fsck times,
> etc)
>
> Are people who care about mass storage issues aware of RedHat's plans and
> are OK with the situation? Are there any other options apart from what
> RedHat is planning?
>
> ___
> 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: BTRFS dropped by RedHat

[Josh Boyer]

On Fri, Aug 4, 2017 at 11:12 AM, Przemek Klosowski
 wrote:
> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
>
> Btrfs has been deprecated

This is a statement on RHEL 7.  It does not reflect on Fedora.

> This is a pity---BTRFS features looked attractive:

What is a pity is that the attractive looking features and the
stability of the filesystem did not line up as one would hope.  Btrfs
works well for some use cases, but for others it can be error prone
and result in data loss.

> Are people who care about mass storage issues aware of RedHat's plans and
> are OK with the situation? Are there any other options apart from what
> RedHat is planning?

Btrfs remains enabled in Fedora.  Realistically, it will remain
enabled and selectable as an option for installs for the foreseeable
future.  Whether a user wishes to use it or not remains up to them.

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

Re: BTRFS dropped by RedHat

[Neal Gompa]

On Fri, Aug 4, 2017 at 11:12 AM, Przemek Klosowski
 wrote:
> The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
>
> Btrfs has been deprecated
>
> The Btrfs file system has been in Technology Preview state since the initial
> release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a
> fully supported feature and it will be removed in a future major release of
> Red Hat Enterprise Linux.
> The Btrfs file system did receive numerous updates from the upstream in Red
> Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise
> Linux 7 series. However, this is the last planned update to this feature.
>
> I think RH roadmap is to use XFS over LVM.
>
> This is a pity---BTRFS features looked attractive:
>
> - integrated RAID that ties low level (block/stripe) issues with high-level
> objects (files); I thought this is important because with brfs filesystem
> integrity features filesystem-level trouble could be tied to low level
> issues like silent failures on one raid element. This is important and
> unique: I had seen failures of large volumes both on proprietary RAID
> hardware and in software RAID, due to silent corruption of one element of
> the array, that propagated to other healthy elements.
>
> - snapshotting/rollbacks that enable recovery system update failures and
> other nice functionality
>
> - scalable support for really large file systems (reasonable fsck times,
> etc)
>
> Are people who care about mass storage issues aware of RedHat's plans and
> are OK with the situation? Are there any other options apart from what
> RedHat is planning?
>

I'm not particularly pleased with their decision. I think the path
they're going down is wrong, and they should really reconsider.
However, I'm reading over their Stratis whitepaper before I formulate
a response about it.

I don't think they fully understand how the Stratis path cannot
replace what Btrfs gives you, and the irony about this is that the
Btrfs developers been working on fixing the major remaining issues
with RAID this year and it looks like it'll be much better next year.

All of my CentOS 7 servers (and my one RHEL 7 box) use Btrfs, because
it's so much better than the alternatives.


-- 
真実はいつも一つ！/ 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: BTRFS dropped by RedHat

[Solomon Peachy]

On Fri, Aug 04, 2017 at 11:12:46AM -0400, Przemek Klosowski wrote:
> This is a pity---BTRFS features looked attractive:

Regardless of the attractiveness of btr's feature sets, the RH 
annoucnement is an indication that they don't consider it supportable 
for the kinds of users that fork over money for RHEL.

And FWIW, I intend to agree.  For all of btrfs's promise, in my personal 
experience it fails the most basic requirement of a filesystem -- to not 
eat data.  *Every* time I've experimented with btrfs, it's ended with 
massive filesystem corruption.  No unclean shutdowns or other hardware 
failures, and I was also just sticking to basic "give me a simple 
filesystem" feature set.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

[Bug 1238804] /usr/bin/perl is not linked with -z now and -pie, perl crashes with -pie

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1478470



--- Comment #16 from Petr Pisar  ---
I reported bug #1478470 against rpmgrill.

-- 
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: BTRFS dropped by RedHat

[Steven Whitehouse]

On 04/08/17 16:23, Fernando Nasser wrote:

On 2017-08-04 11:12 AM, Przemek Klosowski wrote:


The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:



Is it only RHEL?
Yes, it is only RHEL. It does not have any effect on Fedora, that is 
entirely independent,


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

Re: BTRFS dropped by RedHat

[Fernando Nasser]

On 2017-08-04 11:12 AM, Przemek Klosowski wrote:


The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:



Is it only RHEL?

What are other distros doing?


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

Btrfs has been deprecated

The Btrfs file system has been in Technology Preview state since
the initial release of Red Hat Enterprise Linux 6. Red Hat will
not be moving Btrfs to a fully supported feature and it will be
removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the
upstream in Red Hat Enterprise Linux 7.4 and will remain available
in the Red Hat Enterprise Linux 7 series. However, this is the
last planned update to this feature.

I think RH roadmap is to use XFS over LVM.

This is a pity---BTRFS features looked attractive:

- integrated RAID that ties low level (block/stripe) issues with 
high-level objects (files); I thought this is important because with 
brfs filesystem integrity features filesystem-level trouble could be 
tied to low level issues like silent failures on one raid element. 
This is important and unique: I had seen failures of large volumes 
both on proprietary RAID hardware and in software RAID, due to silent 
corruption of one element of the array, that propagated to other 
healthy elements.


- snapshotting/rollbacks that enable recovery system update failures 
and other nice functionality


- scalable support for really large file systems (reasonable fsck 
times, etc)


Are people who care about mass storage issues aware of RedHat's plans 
and are OK with the situation? Are there any other options apart from 
what RedHat is planning?




___
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

Unified database for DNF

[Przemek Klosowski]

I noticed this FESCo topic:
#link https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF

proposing a unified sqlite database for DNF. Recently there's been a 
discussion of replacing the RPM database with a custom database layer, 
where people asked why aren't we using something like sqlite---which I 
think is a reasonable idea, and even more so if the FESCo idea is 
approved and we have sqlite linked into DNF anyway. I just wanted to 
point out the connection, and the possible synergy (BS BINGO!!! BS BINGO!!!)


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

[Bug 1238804] /usr/bin/perl is not linked with -z now and -pie, perl crashes with -pie

[bugzilla]

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



--- Comment #15 from Petr Pisar  ---
I've already got response from Florian Weimer. Because the perl was built with
-Wl,--enable-new-dtags, the way how binding metadata are expresses is a little
bit different, but still perfectly valid and secure.

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

BTRFS dropped by RedHat

[Przemek Klosowski]

The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

   Btrfs has been deprecated

   The Btrfs file system has been in Technology Preview state since the
   initial release of Red Hat Enterprise Linux 6. Red Hat will not be
   moving Btrfs to a fully supported feature and it will be removed in
   a future major release of Red Hat Enterprise Linux.
   The Btrfs file system did receive numerous updates from the upstream
   in Red Hat Enterprise Linux 7.4 and will remain available in the Red
   Hat Enterprise Linux 7 series. However, this is the last planned
   update to this feature.

I think RH roadmap is to use XFS over LVM.

This is a pity---BTRFS features looked attractive:

- integrated RAID that ties low level (block/stripe) issues with 
high-level objects (files); I thought this is important because with 
brfs filesystem integrity features filesystem-level trouble could be 
tied to low level issues like silent failures on one raid element. This 
is important and unique: I had seen failures of large volumes both on 
proprietary RAID hardware and in software RAID, due to silent corruption 
of one element of the array, that propagated to other healthy elements.


- snapshotting/rollbacks that enable recovery system update failures and 
other nice functionality


- scalable support for really large file systems (reasonable fsck times, 
etc)


Are people who care about mass storage issues aware of RedHat's plans 
and are OK with the situation? Are there any other options apart from 
what RedHat is planning?


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

[389-devel] Please review 49342: CI test - password accepts sn attribute

[Nishan Boroian]

 
 

 
 
 
 
 
 
Got it, thank you.  
 
 
 

 
 

 
 
>  
> On Aug 4, 2017 at 10:04,  mailto:sraml...@redhat.com)>  
> wrote:
>  
>  
>  
>  https://pagure.io/389-ds-base/issue/49342 
> https://pagure.io/389-ds-base/issue/raw/files/c1c52646b4c79a1ffc1f16acd1a18ee43bbb863c9f8ca18433aa118866d654bd-0001-Password-accepts-sn-attr.patch
>  ___ 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

[389-devel] Re: Trying to understand entryrdn.db

[Ilias Stamatis]

2017-08-04 16:03 GMT+03:00 Ludwig Krispenz :

>
> On 08/04/2017 02:08 PM, Ilias Stamatis wrote:
>
> Okay, now that I have read and understood dbscan's code, I have a few more
> questions.
>
> 2017-08-03 10:10 GMT+03:00 Ludwig Krispenz :
>
>
>> Hi, now that I know the context here are some more comments.
>> If the purpose is to create a useful ldif file, which could eventually be
>> used for import then formatting an entry correctly is not enough. Order of
>> entries matters: parents need to come before children. We already handle
>> this in db2ldif or replication total update.
>> That said, whenever you write an entry you always have seen the parent
>> and could stack the dn with the parentid and createt the dn without using
>> the entryrdn index.
>> You even need not to keep track of all the entry rdsn/dns - only the ones
>> with children will be needed later, the presence of "numsubordinates"
>> identifies a parent.
>>
>
> Is it guaranteed that parents are going to appear before children in
> id2entry.db?
>
> no. that's what I said before, it is possible that parentid > entryid. It
> happens if an entry is moved by modrdn to aother subtree
>

Ooh, you're right. I got confused, sorry.
I'm also having a hard time finding where this functionality is implemented
in db2ldif. :/

If I tried to do it "from scratch", I think we go back to this (because we
need to grab something that is located after where the cursor is currently
pointing):

On 08/02/2017 09:12 PM, Mark Reynolds wrote:

I have not looked closely into it - so it might not be necessary to use
> entryrdn.  I thought it might be more efficient to use it.  If you just use
> id2entry, you have to keep scanning it over and over, and starting over
> every time you need to read the next entry.  Maybe not though, maybe you
> can just "search" it and not have to scan it sequentially when trying to
> find parents and entries.  I'll leave that up to you to find out ;-)
>

BDB has this method: https://docs.oracle.com/cd/
E17275_01/html/api_reference/C/dbget.html
It allows you to retrieve a key / data pair directly, without a need for
iterating over cursor->c_get(cursor, , , DB_NEXT).

The thing is that I don't know how it is implemented. Does it scan the DB
sequentially or or is it faster than that (I hope and guess it's the
latter)?

If it's not that efficient, maybe it does make sense to use entryrdn
instead finally?
___
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 49342: CI test - password accepts sn attribute

[Sankar Ramalingam]

https://pagure.io/389-ds-base/issue/49342
https://pagure.io/389-ds-base/issue/raw/files/c1c52646b4c79a1ffc1f16acd1a18ee43bbb863c9f8ca18433aa118866d654bd-0001-Password-accepts-sn-attr.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2017-08-04)

[Josh Boyer]

On Thu, Aug 3, 2017 at 11:00 PM, Jared K. Smith
 wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2017-08-04 16:00 UTC'
>
>
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda

I'll be absent from the meeting.  Will vote in tickets.

>
> = Followups =
>
> #topic #1736 - Don't automatically close security bugs on Fedora EOL
> .fesco 1736
> #link https://pagure.io/fesco/issue/1736
>
> #topic #1737 - Proposal: i686 SIG needs to be functional by F27 release date
> .fesco 1737
> #link https://pagure.io/fesco/issue/1737
>
> #topic #1744 - F27 System Wide Change: NSS signtool deprecation
> .fesco 1744
> #link https://pagure.io/fesco/issue/1744
>
> #topic #1745 - F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
> .fesco 1745
> #link https://pagure.io/fesco/issue/1745
>
> #topic #1747 - F27 System Wide Change: RPM 4.14
> .fesco 1747
> #link https://pagure.io/fesco/issue/1747

This one is already fully approved.  I don't believe it needs to be
discussed, nor do I know why it's still open.

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

Orphaning: makedepf90

[Dominik 'Rathann' Mierzejewski]

Dear All,
I'm orphaning the package makedepf90. I originally packaged it only
to be able to unbundle it from cp2k, where it was used during the
build process, but it hasn't been used since release 2.6.0, when
upstream switched to their own dependency generation script written
in python. If anyone wants to take it, feel free to do so. Nothing
depends on it as far as I know. Upstream website seems to be gone
since January 2017:
https://web.archive.org/web/20170116121627/http://personal.inet.fi/private/erikedelmann/makedepf90/
Last release was in June 2006.

I'll orphan the package as soon as pagure-over-dist-git is functional,
because PkgDB is read-only already.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning procedure for libpwiz

[Antonio Trande]

Hi all.

I'm going to abandon 'libpwiz' package on f27.
Feel free to claim ownership if you need it.

Regards.
-- 
--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
<>

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

[389-devel] Please review 48081: CI test - password

[Sankar Ramalingam]

https://pagure.io/389-ds-base/issue/48081
https://pagure.io/389-ds-base/issue/raw/files/38ccf56b0efaa7f9f38bdaa532e036f7f3fd92acb6e3e7a34eb09f7ca07b870e-0001-Password-accepts-sn-attr.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: one concrete ideas for fedora

[Matthew Miller]

On Fri, Aug 04, 2017 at 11:23:30AM +0100, Sérgio Basto wrote:
> Do a stable release do Fedora 25.1 or 26.1 
> 
> install a live disk and have 2 bg of updates is a joke, 
> you may take double of the time but do something that we can call it
> stable . 

Making a stable release like this would imply that we go through the QA
effort that we do with our actual stable releases. This is a lot of
work. So, this idea is much easier said than done.

Note, though, that if you use the network installer instead of the live
CD, you can have the updates repo eanbled for the initial install, so
you *just* get the new versions of packages.

-- 
Matthew Miller

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

Re: one concrete ideas for fedora

[Michael Cronenworth]

On 08/04/2017 06:04 AM, František Zatloukal wrote:

There are updated ISOs available: 
http://dl.fedoraproject.org/pub/alt/live-respins/

Not for Fedora 26 yet, but I guess they´ll be available soon.



It's also very easy to create an updated ISO yourself.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Trying to understand entryrdn.db

[Ludwig Krispenz]

On 08/04/2017 02:08 PM, Ilias Stamatis wrote:
Okay, now that I have read and understood dbscan's code, I have a few 
more questions.


2017-08-03 10:10 GMT+03:00 Ludwig Krispenz >:


Hi, now that I know the context here are some more comments.
If the purpose is to create a useful ldif file, which could
eventually be used for import then formatting an entry correctly
is not enough. Order of entries matters: parents need to come
before children. We already handle this in db2ldif or replication
total update.
That said, whenever you write an entry you always have seen the
parent and could stack the dn with the parentid and createt the dn
without using the entryrdn index.
You even need not to keep track of all the entry rdsn/dns - only
the ones with children will be needed later, the presence of
"numsubordinates"
identifies a parent.


Is it guaranteed that parents are going to appear before children in 
id2entry.db?
no. that's what I said before, it is possible that parentid > entryid. 
It happens if an entry is moved by modrdn to aother subtree


If so, here's what could probably work:

- Start reading entries from id2entry sequentially.
- For each entry, if it has a numSubordinates attribute it means it is 
a parent for other entries. So we can store it's ID - DN pair in a 
hash map.
- For entries that they have a parentid and so we need to figure out 
their parent's DN, we just look for hashmap[parentid].


To make it even more efficient (if really needed though, because it 
will make things more complicated) we can store the value of 
numSubordinates with each parent as well somehow in the map. Every 
time a parentid is looked in the map we can decrease the value of 
numSubordinates by 1. When it becomes 0, it means there are no more 
children of this ID so we can safely remove it from the map.


However, I don't know if we would really need this last thing. In a 
100 million entry db how many parents would we expect to have 
approximately?


Also, do we have a hash map implemented somewhere?

If parents are not guaranteed to appear before children in 
id2entry.db, then we would have to alter the above strategy.


Thanks!



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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

[389-devel] Re: Trying to understand entryrdn.db

[Nishan Boroian]

 
 
 
Ok, thanks for the update.  
 
 
 

 
 

 
 
>  
> On Aug 4, 2017 at 08:08,  mailto:stamatis.ili...@gmail.com)> 
>  wrote:
>  
>  
>  
> Okay, now that I have read and understood dbscan's code, I have a few more 
> questions.
>  
>  
>
>  
> 2017-08-03 10:10 GMT+03:00 Ludwig Krispenz   (mailto:lkris...@redhat.com)>:
>  
> >  Hi, now that I know the context here are some more comments.
> >  
> > If the purpose is to create a useful ldif file, which could eventually be 
> > used for import then formatting an entry correctly is not enough. Order of 
> > entries matters: parents need to come before children. We already handle 
> > this in db2ldif or replication total update.
> >  That said, whenever you write an entry you always have seen the parent and 
> > could stack the dn with the parentid and createt the dn without using the 
> > entryrdn index.
> >  You even need not to keep track of all the entry rdsn/dns - only the ones 
> > with children will be needed later, the presence of "numsubordinates"
> >  identifies a parent.
> >
>
>  
> Is it guaranteed that parents are going to appear before children in 
> id2entry.db?
>  
>  
> If so, here's what could probably work:
>  
>  
> - Start reading entries from id2entry sequentially.
>  
> - For each entry, if it has a numSubordinates attribute it means it is a 
> parent for other entries. So we can store it's ID - DN pair in a hash map.
>  
> - For entries that they have a parentid and so we need to figure out their 
> parent's DN, we just look for hashmap[parentid].
>  
>  
> To make it even more efficient (if really needed though, because it will make 
> things more complicated) we can store the value of numSubordinates with each 
> parent as well somehow in the map. Every time a parentid is looked in the map 
> we can decrease the value of numSubordinates by 1. When it becomes 0, it 
> means there are no more children of this ID so we can safely remove it from 
> the map.
>  
>  
> However, I don't know if we would really need this last thing. In a 100 
> million entry db how many parents would we expect to have approximately?
>  
>  
> Also, do we have a hash map implemented somewhere?
>  
>  
> If parents are not guaranteed to appear before children in id2entry.db, then 
> we would have to alter the above strategy.
>
>
>  
> Thanks!
>  
>
>___ 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

[Bug 1238804] /usr/bin/perl is not linked with -z now and -pie, perl crashes with -pie

[bugzilla]

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



--- Comment #14 from Harald Reindl  ---
BIND_NOW is -z now aka "Full RELRO"
http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html

it's peferred but not always possible

-- 
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 1238804] /usr/bin/perl is not linked with -z now and -pie, perl crashes with -pie

[bugzilla]

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



--- Comment #13 from Petr Pisar  ---
/usr/bin/perl is now built with all necessary options, but the resulting
executable differs from other executables:

$ readelf -d /usr/bin/rpm | grep NOW
 0x0018 (BIND_NOW)   
 0x6ffb (FLAGS_1)Flags: NOW PIE
$ readelf -d /usr/bin/perl | grep NOW
 0x001e (FLAGS)  BIND_NOW
 0x6ffb (FLAGS_1)Flags: NOW PIE

I need to figure out if this is a problem or not.

-- 
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: Why Atomic Host should be built using Modularity

[Petr Šabata]

On Wed, Aug 02, 2017 at 02:18:09PM -0400, Colin Walters wrote:
> What next
> -
> 
> We're going to experiment with this!

My humble plan is to create a very early PoC Atomic Host module
that people could try out within the next two weeks.  This will
reveal the weak spots in the pipeline and will give people an
idea how it could be developed and maintained.

So stay tuned :)

P


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

[Bug 1354386] CVE-2016-6185 perl: XSLoader loads relative paths not included in @INC

[bugzilla]

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

Cedric Buissart  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2016 |impact=moderate,public=2016
   |0630,reported=20160630,sour |0630,reported=20160630,sour
   |ce=debian,cvss2=6.8/AV:N/AC |ce=debian,cvss2=6.8/AV:N/AC
   |:M/Au:N/C:P/I:P/A:P,cvss3=7 |:M/Au:N/C:P/I:P/A:P,cvss3=7
   |.3/CVSS:3.0/AV:L/AC:L/PR:L/ |.3/CVSS:3.0/AV:L/AC:L/PR:L/
   |UI:R/S:U/C:H/I:H/A:H,rhel-5 |UI:R/S:U/C:H/I:H/A:H,rhel-5
   |/perl=wontfix,rhel-6/perl=w |/perl=wontfix,rhel-6/perl=w
   |ontfix,rhel-7/perl=wontfix, |ontfix,rhel-7/perl=wontfix,
   |rhscl-2/rh-perl520-perl=aff |rhscl-2/rh-perl520-perl=won
   |ected,fedora-all/perl=notaf |tfix,fedora-all/perl=notaff
   |fected,rhscl-2/rh-perl524-p |ected,rhscl-2/rh-perl524-pe
   |erl=affected|rl=wontfix



-- 
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 1354386] CVE-2016-6185 perl: XSLoader loads relative paths not included in @INC

[bugzilla]

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

Cedric Buissart  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WONTFIX
Last Closed||2017-08-04 07:29:43



-- 
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: one concrete ideas for fedora

[František Zatloukal]

There are updated ISOs available:
http://dl.fedoraproject.org/pub/alt/live-respins/

Not for Fedora 26 yet, but I guess they´ll be available soon.

2017-08-04 12:23 GMT+02:00 Sérgio Basto :

> Do a stable release do Fedora 25.1 or 26.1
>
> install a live disk and have 2 bg of updates is a joke,
> you may take double of the time but do something that we can call it
> stable .
>
> --
> Sérgio M. B.
> ___
> 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

one concrete ideas for fedora

[Sérgio Basto]

Do a stable release do Fedora 25.1 or 26.1 

install a live disk and have 2 bg of updates is a joke, 
you may take double of the time but do something that we can call it
stable . 

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

Re: Pagure over dist-git: what changes?

[Matthew Miller]

On Fri, Aug 04, 2017 at 10:55:54AM +0100, Peter Robinson wrote:
> > It is not yet deployed in production (I'm working on this today) so it is 
> > not
> > yet available :)
> Is it actually being deployed today? In the middle of the mass rebuild?

Yeah; not ideal, but it was coordinated so Pierre's work could start
after the git commit phase of the mass rebuild. 
https://public.etherpad-mozilla.org/p/koji-pdg-dance-steps


-- 
Matthew Miller

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

Re: Pagure over dist-git: what changes?

[Peter Robinson]

On Fri, Aug 4, 2017 at 10:43 AM, Pierre-Yves Chibon  wrote:
> On Fri, Aug 04, 2017 at 09:36:32AM +, Petr Pisar wrote:
>> On 2017-08-03, Pierre-Yves Chibon  wrote:
>> >
>> > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb
>> >
>> What is the Pagure over dist-git URL? The linked document has everywhere
>> placeholder links with src.fedoraproject.org domain and if I try any
>> of them it returns "Not Found" page.  And the top-level address
>> redirects to cgit interface.
>
> It is not yet deployed in production (I'm working on this today) so it is not
> yet available :)

Is it actually being deployed today? In the middle of the mass rebuild?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Builds stuck in f27-pending

[Peter Robinson]

On Fri, Aug 4, 2017 at 9:56 AM, Björn 'besser82' Esser
 wrote:
> Hello folks!
>
> I did some builds on Rawhide / fc27 yesterday and they are still stuck in
> f27-pending.  Is the signing queue blocked again?

There's probably a backlog due to mass rebuild part two being processed
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pagure over dist-git: what changes?

[Pierre-Yves Chibon]

On Fri, Aug 04, 2017 at 09:36:32AM +, Petr Pisar wrote:
> On 2017-08-03, Pierre-Yves Chibon  wrote:
> >
> > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb
> >
> What is the Pagure over dist-git URL? The linked document has everywhere
> placeholder links with src.fedoraproject.org domain and if I try any
> of them it returns "Not Found" page.  And the top-level address
> redirects to cgit interface.

It is not yet deployed in production (I'm working on this today) so it is not
yet available :)

We will be announcing it when it is ready (likely on Monday) and we'll make sure
to update the wiki page as well, thanks for pointing it out.


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

Re: Pagure over dist-git: what changes?

[Petr Pisar]

On 2017-08-03, Pierre-Yves Chibon  wrote:
>
> https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb
>
What is the Pagure over dist-git URL? The linked document has everywhere
placeholder links with src.fedoraproject.org domain and if I try any
of them it returns "Not Found" page.  And the top-level address
redirects to cgit interface.

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

Builds stuck in f27-pending

[Björn 'besser82' Esser]

Hello folks!

I did some builds on Rawhide / fc27 yesterday and they are still stuck 
in f27-pending.  Is the signing queue blocked again?


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

Re: Adding program to Software Center

[Vít Ondruch]

Dne 3.8.2017 v 15:24 Richard Hughes napsal(a):
> On 3 August 2017 at 14:07, Vít Ondruch  wrote:
>> Well, the thing is you are looking at old data as far as I can tell,
>> since this was fixed in the package several days ago [1].
> The metadata builder got stuck, and I was at GUADEC for the last few
> days. The new metadata should be uploaded to the screenshots repo in a
> few hours.

Heh .. things always happens in the wrong time ;) Checking g-s with the
appstream-data-27-4.fc27, I can see "Amazon Cloud Player" listed under
Nuvola, so this looks promising.

BTW could you please take a look at "eu.tiliado.Nuvola.desktop" listed
in [1]. It states "Vetosduplicate of nuvolaruntime-4.5.0-4.fc27". It
seems that this relates to the rename from nuvolaplayer to
nuvolaruntime. I'd say that nuvolaplayer was correctly obsoleted, it is
retired in pkgdb and it should be blocked in Koji. Is it correctly
handled from AppData POV?


Vít


[1] https://dl.fedoraproject.org/pub/alt/screenshots/f27/failed.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: State of Sparkleshare

[Peter Robinson]

On Fri, Aug 4, 2017 at 7:17 AM, Luya Tshimbalanga
 wrote:
> On 01/08/17 01:01 PM, Peter Robinson wrote:
>> On Tue, Aug 1, 2017 at 8:46 PM, Luya Tshimbalanga
>>  wrote:
>>> As a maintainer of Fedora Design Suite, the state of sparkleshare brought 
>>> attention with these outstanding report:
>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1375789
>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1151172
>>>
>>> Considering the critical vulnerability of the dependent package webkitgtk, 
>>> will it be possible for a proven package updating Sparkleshare to the 
>>> latest stable release
>>> as the Design Team depends on it?
>> The mono maintainers should be able to assist with that and are likely
>> best suited.
>>
>
> Thank you. I am contacting one of them.

If it's critical for the design team I also suggest getting one of the
Design team to become a co-maintainer of the package to ensure you
have some level of control over it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: State of Sparkleshare

[Luya Tshimbalanga]

On 01/08/17 01:01 PM, Peter Robinson wrote:
> On Tue, Aug 1, 2017 at 8:46 PM, Luya Tshimbalanga
>  wrote:
>> As a maintainer of Fedora Design Suite, the state of sparkleshare brought 
>> attention with these outstanding report:
>> * https://bugzilla.redhat.com/show_bug.cgi?id=1375789
>> * https://bugzilla.redhat.com/show_bug.cgi?id=1151172
>>
>> Considering the critical vulnerability of the dependent package webkitgtk, 
>> will it be possible for a proven package updating Sparkleshare to the latest 
>> stable release
>> as the Design Team depends on it?
> The mono maintainers should be able to assist with that and are likely
> best suited.
>
> Peter
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Thank you. I am contacting one of them.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org