Re: one concrete idea for fedora

[Sérgio Basto]

On Fri, 2017-08-04 at 09:24 -0400, Matthew Miller wrote:
> 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 and all in general , 
I'm very sorry for my bad mood and I apologize.
But what I want emphasize is that we are losing the concept of
stability not just in Fedora, it is in many other projects, KDE for
example, simply don't have any "stable" or LTS release or something
like that, that is real stable and solid as rock. 
For packages maintainers like me, that maintain packages in free time,
we got more and more work and begins to become impossible maintain all
packages correctly, we got lot of packages that aren't updated because
people simple don't have time, so should be important, that some team
take care of completely out-date packages, like, for example, gitlib
[1], also maybe in wild changes like systemd, selinux, appdata, etc,
the team help packagers on maintain his packages. 

About ISOs available at http://dl.fedoraproject.org/pub/alt/live-respin
s/ , yeah I forgot that, IHMO, it should be mention on https://getfedor
a.org/ .  Also I notice it now :) , if we also have netinstall images
updated, it will be awesome. 

About "Making a stable release like this would imply that we go through
the QA " OK I know, anyway I think you should consider that, I think
they will have much less work than the first release, because usually
when we respin packages that are in stable releases we don't have any
problem.

On F25 , if I'm correct, we got rpm update of backend database and it
is awful when we do an rpm command in a middle of one dnf upgrade after
a fresh live installation, we got a big rpm error and and we will need
rebuild rpm database I guess etc. So with one updated live or with
F25.1 release we could have more sense of stability.

Best regards and thanks,

[1]  
https://bugzilla.redhat.com/show_bug.cgi?id=822844


> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: heads up: poppler soname bump

[Josh Boyer]

On Sat, Aug 5, 2017 at 3:05 PM, Kevin Fenzi  wrote:
> On 08/05/2017 11:45 AM, Zbigniew Jędrzejewski-Szmek wrote:
>
>> From #fedora-releng:
>> 18:11 <+nirik> sharkcz: can you clean up space on s390 koji? its very close 
>> to full...
>> 18:22 < sharkcz> nirik: done, thanks for the notice
>>
>> Maybe you should try again?
>
> That is the old secondary arch s390 koji, nothing to do with builds now
> in rawhide as s390 has been added into main koji. ;)

I will buy you a beer the next time I see you if you stop calling it
s390.  It's s390x.  We don't build for old 31-bit weird mainframe
hardware, and we dropped multilib for it a while ago in Fedora, iirc.

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

Orphaned Packages in rawhide (2017-08-06)

[till]

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

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

 Package  (co)maintainersStatus Change 
==
apvlvorphan  0 weeks ago   
frepple  orphan, jdetaeye, salimma   1 weeks ago   
herbstluftwm orphan, cicku   0 weeks ago   
modem-manager-guiorphan, mariobl 4 weeks ago   
python-tlslite   orphan  0 weeks ago   
rubygem-haml-rails   orphan  2 weeks ago   
xsettingsd   orphan, pcarrier0 weeks ago   

The following packages require above mentioned packages:
Depending on: python-tlslite (1), status change: 2017-08-02 (0 weeks ago)
python-jira (maintained by: ralph)
python2-jira-1.0.7-2.fc27.noarch requires python2-tlslite = 
0.4.9-5.fc27
python3-jira-1.0.7-2.fc27.noarch requires python3-tlslite = 
0.4.9-5.fc27

Affected (co)maintainers
cicku: herbstluftwm
jdetaeye: frepple
mariobl: modem-manager-gui
pcarrier: xsettingsd
ralph: python-tlslite
salimma: frepple

Orphans (7): apvlv frepple herbstluftwm modem-manager-gui
python-tlslite rubygem-haml-rails xsettingsd


Orphans (dependend on) (1): python-tlslite


Orphans (rawhide) for at least 6 weeks (dependend on) (0):


Orphans  (rawhide)(not depended on) (6): apvlv frepple herbstluftwm
modem-manager-gui rubygem-haml-rails xsettingsd


Orphans (rawhide) for at least 6 weeks (not dependend on) (0):


Depending packages (rawhide) (1): python-jira


Packages depending on packages orphaned (rawhide) for more than 6
weeks (0):

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

jplesnik uploaded Perl-Stripper-0.10.tar.gz for perl-Perl-Stripper

[notifications]

180e6d6beb5e99c8a04602893151129da9d6688bacd505381e5d8f5e58b36d8573f97fa5a28b587560c5fada50c995cfb141120cd0dc6ab37e3a0b99436870fd
  Perl-Stripper-0.10.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Perl-Stripper/Perl-Stripper-0.10.tar.gz/sha512/180e6d6beb5e99c8a04602893151129da9d6688bacd505381e5d8f5e58b36d8573f97fa5a28b587560c5fada50c995cfb141120cd0dc6ab37e3a0b99436870fd/Perl-Stripper-0.10.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Perl-Stripper (master). "0.10 bump"

[notifications]

jplesnik pushed to perl-Perl-Stripper (master).  "0.10 bump"

https://src.fedoraproject.org/cgit/perl-Perl-Stripper.git/commit/?h=master=db060fd29a53aa91ca5ec933d1231697468d810a
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[DRAFT] Mass package change proposal

[Zbigniew Jędrzejewski-Szmek]

Hi!

This is a continuation of the "Finalizing Fedora's Switch to Python 3"
thread on fedora-devel, using the procedure from 
https://fedoraproject.org/wiki/Mass_package_changes.

I'm proposing an automated change to ~723 packages, and manual fixes
or follow-up bug filing for the remaining ~114 packages.


### Proposed changes ###

The change is to ensure that as many as possible python packages which
provide a version for python2 have a python2- subpackage as required by
the guidelines
[https://fedoraproject.org/wiki/Packaging:Naming#Python2_binary_package_naming].

For source packages which do *not* have a python- prefix, but already
have a python-foo subpackage, that subpackage will be renamed to python2-foo.

For packages which are called python-foo and just build a main binary package
python-foo, a new python2-foo subpackage will be created.
Provides/Requires/Conflicts/Obsoletes are moved from the main package to
the new subpackage.

In all cases, the new python2- subpackage will use lower-case naming.
This may lead to a situation where an existing python3- subpackage has
a differently-cased name than the python2- subpackage.
[Q: maybe the python3- subpackage should be renamed automatically in this case?]

An effort is made (thanks Miro!) to preserve the style which is used
in the spec file, so that if e.g. python-%{real_name} was used originally,
this is changed to python2-%{real_name}. If this macro cannot be guessed or
if it resolves to a non-lowercase name, a non-macro lower-case string will
be used.

%{python_provide python2-foobar} are added as required by the guidelines
[https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro].
One or two: %{python_provide python2-foobar} is always added, and if the package
has a non-lower-case name, %{python_provide python2-FooBar} is also added.
This provides backward compatible names to the package (python-foobar, 
python-FooBar),
as long as %{python_provide} is defined as it is now. Once %python_provide macro
is switched to prefer python3 subpackages, those compat names will be gone.

In case the source package name does not have a python- prefix, a Provides
for the old name is also added, with a comment that it should be removed later.
Example:
+%package -n python2-atpy
+Summary: %summary
+Requires: numpy python-astropy
+%{?python_provide:%python_provide python2-atpy}
+# Remove before F30
+Provides: ATpy = %{version}-%{release}

Changes are implemented in an automated way using
https://pagure.io/pyrenamer.

rpmdev-bumpspec is used to add changelog entries will be added that look like:
* Sat Aug 05 2017 Zbigniew Jędrzejewski-Szmek  - 3.3-4
- Python 2 subpackage renamed to python2-foobar
  See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

Current diff: https://in.waw.pl/~zbyszek/fedora/python2-renaming.diff
[https://in.waw.pl/~zbyszek/fedora/python2-renaming.color.diff is a version
will color escapes, to be downloaded and viewed with less:
curl https://in.waw.pl/~zbyszek/fedora/python2-renaming.color.diff | less -RF]


### Which packages need to change ###

http://fedora.portingdb.xyz/namingpolicy/ "Misnamed subpackage" lists 877 
subpackages.
It seems that the real number is a bit lower, because there are some
dead packages and some that have been fixed in the meanwhile on that
list. I'll generate a canonical maintainer: package, package: maintainer list
for the final version.

The automated rename currently works for 723 packages, 39 don't need work.
The remaining 141 packages will require manual fixes.
Some patches will be generated manually. They will be applied at the same
time.

I do *not* want maintainers to fix packages which are covered by the
automated changes by hand, since that provides no benefit. Maintainers are
of course encouraged to fix packages which are not covered, or to take the
automated patch and use it as a basis of their own fix if the automated change
is deficient for some reason.

I'm looking for volunteers to help with the remaining ~141 packages which
cannot be done automatically. If you can participate (either as a proven
packager or not), let me know. It is possible that automated cleanup can
be applied to some more packages (e.g. I just noticed that there's a
bunch of packages which have python%{python3_pkgversion}- subpackage,
which could done automatically...), so please coordinate with me to avoid
duplicated work.

[I'll be generating all the diffs as separate files and uploading them
somewhere later this weekend.]

Currently unhandled packages:

CONDITIONALS: ahkab mod_wsgi pystache python-alembic python-ansi2html
python-backports-ssl_match_hostname python-beaker python-bugzilla
python-cairocffi python-chameleon python-cliff python-cssmin
python-datanommer-models python-deltasigma python-django-dynamite
python-django-filter python-django-post_office
python-django-socialregistration python-docker-py python-flask-images
python-flask-wtf python-fmn-lib python-fmn-web 

[DRAFT] Mass package change proposal

[Zbigniew Jędrzejewski-Szmek]

Hi!

This is a continuation of the "Finalizing Fedora's Switch to Python 3"
thread on fedora-devel, using the procedure from 
https://fedoraproject.org/wiki/Mass_package_changes.

I'm proposing an automated change to ~723 packages, and manual fixes
or follow-up bug filing for the remaining ~114 packages.


### Proposed changes ###

The change is to ensure that as many as possible python packages which
provide a version for python2 have a python2- subpackage as required by
the guidelines
[https://fedoraproject.org/wiki/Packaging:Naming#Python2_binary_package_naming].

For source packages which do *not* have a python- prefix, but already
have a python-foo subpackage, that subpackage will be renamed to python2-foo.

For packages which are called python-foo and just build a main binary package
python-foo, a new python2-foo subpackage will be created.
Provides/Requires/Conflicts/Obsoletes are moved from the main package to
the new subpackage.

In all cases, the new python2- subpackage will use lower-case naming.
This may lead to a situation where an existing python3- subpackage has
a differently-cased name than the python2- subpackage.
[Q: maybe the python3- subpackage should be renamed automatically in this case?]

An effort is made (thanks Miro!) to preserve the style which is used
in the spec file, so that if e.g. python-%{real_name} was used originally,
this is changed to python2-%{real_name}. If this macro cannot be guessed or
if it resolves to a non-lowercase name, a non-macro lower-case string will
be used.

%{python_provide python2-foobar} are added as required by the guidelines
[https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro].
One or two: %{python_provide python2-foobar} is always added, and if the package
has a non-lower-case name, %{python_provide python2-FooBar} is also added.
This provides backward compatible names to the package (python-foobar, 
python-FooBar),
as long as %{python_provide} is defined as it is now. Once %python_provide macro
is switched to prefer python3 subpackages, those compat names will be gone.

In case the source package name does not have a python- prefix, a Provides
for the old name is also added, with a comment that it should be removed later.
Example:
+%package -n python2-atpy
+Summary: %summary
+Requires: numpy python-astropy
+%{?python_provide:%python_provide python2-atpy}
+# Remove before F30
+Provides: ATpy = %{version}-%{release}

Changes are implemented in an automated way using
https://pagure.io/pyrenamer.

rpmdev-bumpspec is used to add changelog entries will be added that look like:
* Sat Aug 05 2017 Zbigniew Jędrzejewski-Szmek  - 3.3-4
- Python 2 subpackage renamed to python2-foobar
  See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3

Current diff: https://in.waw.pl/~zbyszek/fedora/python2-renaming.diff
[https://in.waw.pl/~zbyszek/fedora/python2-renaming.color.diff is a version
will color escapes, to be downloaded and viewed with less:
curl https://in.waw.pl/~zbyszek/fedora/python2-renaming.color.diff | less -RF]


### Which packages need to change ###

http://fedora.portingdb.xyz/namingpolicy/ "Misnamed subpackage" lists 877 
subpackages.
It seems that the real number is a bit lower, because there are some
dead packages and some that have been fixed in the meanwhile on that
list. I'll generate a canonical maintainer: package, package: maintainer list
for the final version.

The automated rename currently works for 723 packages, 39 don't need work.
The remaining 141 packages will require manual fixes.
Some patches will be generated manually. They will be applied at the same
time.

I do *not* want maintainers to fix packages which are covered by the
automated changes by hand, since that provides no benefit. Maintainers are
of course encouraged to fix packages which are not covered, or to take the
automated patch and use it as a basis of their own fix if the automated change
is deficient for some reason.

I'm looking for volunteers to help with the remaining ~141 packages which
cannot be done automatically. If you can participate (either as a proven
packager or not), let me know. It is possible that automated cleanup can
be applied to some more packages (e.g. I just noticed that there's a
bunch of packages which have python%{python3_pkgversion}- subpackage,
which could done automatically...), so please coordinate with me to avoid
duplicated work.

[I'll be generating all the diffs as separate files and uploading them
somewhere later this weekend.]

Currently unhandled packages:

CONDITIONALS: ahkab mod_wsgi pystache python-alembic python-ansi2html
python-backports-ssl_match_hostname python-beaker python-bugzilla
python-cairocffi python-chameleon python-cliff python-cssmin
python-datanommer-models python-deltasigma python-django-dynamite
python-django-filter python-django-post_office
python-django-socialregistration python-docker-py python-flask-images
python-flask-wtf python-fmn-lib python-fmn-web 

Re: heads up: poppler soname bump

[Björn 'besser82' Esser]

Am 05.08.2017 um 21:05 schrieb Kevin Fenzi:

On 08/05/2017 11:45 AM, Zbigniew Jędrzejewski-Szmek wrote:


 From #fedora-releng:
18:11 <+nirik> sharkcz: can you clean up space on s390 koji? its very close to 
full...
18:22 < sharkcz> nirik: done, thanks for the notice

Maybe you should try again?

That is the old secondary arch s390 koji, nothing to do with builds now
in rawhide as s390 has been added into main koji. ;)

I'll poke around and see if I can see why this is failing...

kevin


I kicked off a new build and now everything seems to work fine on S390X.
___
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

[Kevin Fenzi]

On 08/04/2017 12:37 PM, Jason L Tibbitts III wrote:
>> "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 

The json files we provide are the exact channels that epel uses and
tries not to collide with. RHEL has hundreds (thousands?) of other
channels we don't look at.

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

Yep.

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

Indeed. Thanks for working on this.

kevin





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

Re: heads up: poppler soname bump

[Kevin Fenzi]

On 08/05/2017 11:45 AM, Zbigniew Jędrzejewski-Szmek wrote:

> From #fedora-releng:
> 18:11 <+nirik> sharkcz: can you clean up space on s390 koji? its very close 
> to full...
> 18:22 < sharkcz> nirik: done, thanks for the notice
> 
> Maybe you should try again?

That is the old secondary arch s390 koji, nothing to do with builds now
in rawhide as s390 has been added into main koji. ;)

I'll poke around and see if I can see why this is failing...

kevin




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: heads up: poppler soname bump

[Björn 'besser82' Esser]

Am 05.08.2017 um 20:45 schrieb Zbigniew Jędrzejewski-Szmek:

On Sat, Aug 05, 2017 at 08:36:22PM +0200, Björn 'besser82' Esser wrote:

Am 05.08.2017 um 18:14 schrieb Björn 'besser82' Esser:

Am 05.08.2017 um 18:08 schrieb Zbigniew Jędrzejewski-Szmek:

On Fri, Aug 04, 2017 at 01:00:55PM -0700, Adam Williamson wrote:

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

In file included from /usr/include/poppler/PDFDoc.h:53:0,
  from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:
/usr/include/poppler/Form.h:353:32: warning: override controls
(override/final) only available with -std=c++11 or -std=gnu++11
void fillChildrenSiblingsID () override;
 ^
In file included from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:0:
/usr/include/poppler/PDFDoc.h:295:153: error: 'nullptr' was not
declared in this scope
void markPageObjects(Dict *pageDict, XRef *xRef, XRef
*countRef, Guint numOffset, int oldRefNum, int newRefNum,
std::set *alreadyMarkedDicts = nullptr);

It seem the new poppler requires c++11. I'm now starting a build of
texlive with -std=c++11 locally. On the off chance that it does work
like that, I can try to build it in rawhide too.

Zbyszek

It works.  Just tried to.  Will start the rebuild within a few mins…

Looks like texlive is failing to build on S390X due some problems
with cpio…  I retried two times.  :(

```

DEBUG util.py:522:  Executing command: ['/bin/rpm', '-Uvh', '--nodeps', 
'/builddir/build/originals/texlive-2016-36.20160520.fc27.5.src.rpm'] with env {'TERM': 'vt100', 
'LANG': 'en_US.UTF-8', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': 
' \\s-\\v\\$ ', 'HOSTNAME': 'mock', 'HOME': '/builddir'} and shell False
DEBUG util.py:296:  Unsharing. Flags: 134217728
DEBUG util.py:439:  Updating / installing...
DEBUG util.py:439:  texlive-6:2016-36.20160520.fc27.5 

DEBUG util.py:439:  error: unpacking of archive failed on file 
/builddir/build/SOURCES/wadalab.tar.xz;598609dc: cpio: read
DEBUG util.py:439:  error: 
/builddir/build/originals/texlive-2016-36.20160520.fc27.5.src.rpm cannot be 
installed
DEBUG util.py:577:  Child return code was: 1
DEBUG util.py:188:  kill orphans
DEBUG util.py:598:  child environment: None

 From #fedora-releng:
18:11 <+nirik> sharkcz: can you clean up space on s390 koji? its very close to 
full...
18:22 < sharkcz> nirik: done, thanks for the notice

Maybe you should try again?

Zbyszek


Will do so, thanks!  =)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: heads up: poppler soname bump

[Zbigniew Jędrzejewski-Szmek]

On Sat, Aug 05, 2017 at 08:36:22PM +0200, Björn 'besser82' Esser wrote:
> Am 05.08.2017 um 18:14 schrieb Björn 'besser82' Esser:
> >Am 05.08.2017 um 18:08 schrieb Zbigniew Jędrzejewski-Szmek:
> >>On Fri, Aug 04, 2017 at 01:00:55PM -0700, Adam Williamson wrote:
> >>>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
> >>In file included from /usr/include/poppler/PDFDoc.h:53:0,
> >>  from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:
> >>/usr/include/poppler/Form.h:353:32: warning: override controls
> >>(override/final) only available with -std=c++11 or -std=gnu++11
> >>void fillChildrenSiblingsID () override;
> >> ^
> >>In file included from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:0:
> >>/usr/include/poppler/PDFDoc.h:295:153: error: 'nullptr' was not
> >>declared in this scope
> >>void markPageObjects(Dict *pageDict, XRef *xRef, XRef
> >>*countRef, Guint numOffset, int oldRefNum, int newRefNum,
> >>std::set *alreadyMarkedDicts = nullptr);
> >>
> >>It seem the new poppler requires c++11. I'm now starting a build of
> >>texlive with -std=c++11 locally. On the off chance that it does work
> >>like that, I can try to build it in rawhide too.
> >>
> >>Zbyszek
> >
> >It works.  Just tried to.  Will start the rebuild within a few mins…
> 
> Looks like texlive is failing to build on S390X due some problems
> with cpio…  I retried two times.  :(
> 
> ```
> 
> DEBUG util.py:522:  Executing command: ['/bin/rpm', '-Uvh', '--nodeps', 
> '/builddir/build/originals/texlive-2016-36.20160520.fc27.5.src.rpm'] with env 
> {'TERM': 'vt100', 'LANG': 'en_US.UTF-8', 'SHELL': '/bin/bash', 
> 'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PATH': 
> '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': ' \\s-\\v\\$ ', 
> 'HOSTNAME': 'mock', 'HOME': '/builddir'} and shell False
> DEBUG util.py:296:  Unsharing. Flags: 134217728
> DEBUG util.py:439:  Updating / installing...
> DEBUG util.py:439:  texlive-6:2016-36.20160520.fc27.5 
> 
> DEBUG util.py:439:  error: unpacking of archive failed on file 
> /builddir/build/SOURCES/wadalab.tar.xz;598609dc: cpio: read
> DEBUG util.py:439:  error: 
> /builddir/build/originals/texlive-2016-36.20160520.fc27.5.src.rpm cannot be 
> installed
> DEBUG util.py:577:  Child return code was: 1
> DEBUG util.py:188:  kill orphans
> DEBUG util.py:598:  child environment: None

From #fedora-releng:
18:11 <+nirik> sharkcz: can you clean up space on s390 koji? its very close to 
full...
18:22 < sharkcz> nirik: done, thanks for the notice

Maybe you should try again?

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

Re: heads up: poppler soname bump

[Björn 'besser82' Esser]

Am 05.08.2017 um 18:14 schrieb Björn 'besser82' Esser:

Am 05.08.2017 um 18:08 schrieb Zbigniew Jędrzejewski-Szmek:

On Fri, Aug 04, 2017 at 01:00:55PM -0700, Adam Williamson wrote:

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

In file included from /usr/include/poppler/PDFDoc.h:53:0,
  from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:
/usr/include/poppler/Form.h:353:32: warning: override controls 
(override/final) only available with -std=c++11 or -std=gnu++11

void fillChildrenSiblingsID () override;
 ^
In file included from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:0:
/usr/include/poppler/PDFDoc.h:295:153: error: 'nullptr' was not 
declared in this scope
void markPageObjects(Dict *pageDict, XRef *xRef, XRef *countRef, 
Guint numOffset, int oldRefNum, int newRefNum, std::set 
*alreadyMarkedDicts = nullptr);


It seem the new poppler requires c++11. I'm now starting a build of
texlive with -std=c++11 locally. On the off chance that it does work
like that, I can try to build it in rawhide too.

Zbyszek


It works.  Just tried to.  Will start the rebuild within a few mins…


Looks like texlive is failing to build on S390X due some problems with 
cpio…  I retried two times.  :(


```

DEBUG util.py:522:  Executing command: ['/bin/rpm', '-Uvh', '--nodeps', 
'/builddir/build/originals/texlive-2016-36.20160520.fc27.5.src.rpm'] with env {'TERM': 'vt100', 
'LANG': 'en_US.UTF-8', 'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': 
' \\s-\\v\\$ ', 'HOSTNAME': 'mock', 'HOME': '/builddir'} and shell False
DEBUG util.py:296:  Unsharing. Flags: 134217728
DEBUG util.py:439:  Updating / installing...
DEBUG util.py:439:  texlive-6:2016-36.20160520.fc27.5 

DEBUG util.py:439:  error: unpacking of archive failed on file 
/builddir/build/SOURCES/wadalab.tar.xz;598609dc: cpio: read
DEBUG util.py:439:  error: 
/builddir/build/originals/texlive-2016-36.20160520.fc27.5.src.rpm cannot be 
installed
DEBUG util.py:577:  Child return code was: 1
DEBUG util.py:188:  kill orphans
DEBUG util.py:598:  child environment: None
```
___
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 Sat, Aug 5, 2017 at 10:56 AM, Neal Gompa  wrote:

> On Sat, Aug 5, 2017 at 1:38 PM, Gerald B. Cox  wrote:
> >
> > That's all fine and good but features mean nothing if you don't have
> faith
> > in the underlying filesystem.
> > People have been burnt by Btrfs and just don't trust it's design.
> BcacheFS
> > now has the best chance of
> > being the next great thing - but Redhat wants to provide something for
> their
> > customers now and is tired
> > of playing the "it's getting better, we promise" game.  Hence the Stratis
> > strategy.  It's a wise approach.
> >
>
> No. Red Hat has *zero* engineers that work on Btrfs. That's the real
> reason for this.
>
> If Red Hat *really* wanted it, they would have got someone to work on
> it specifically to accelerate the stabilization of the filesystem code
> for the next RHEL. That *never* happened since Josef Bacik left Red
> Hat for Facebook years ago. Josef still works on Btrfs there, just for
> Facebook instead of Red Hat.
>

Why do you think they have zero engineers that work on it?
If they believed it was worthwhile they would have devoted resources to
it.  All
you have to do is connect the dots.
___
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 Sat, Aug 5, 2017 at 1:38 PM, Gerald B. Cox  wrote:
> On Sat, Aug 5, 2017 at 9:58 AM, Neal Gompa  wrote:
>>
>>
>> There are plenty of "clever" kernel modules that do bits and pieces of
>> what Btrfs offers.
>>
>> ...there you can leverage all the benefits of Btrfs.
>>
>
> That's all fine and good but features mean nothing if you don't have faith
> in the underlying filesystem.
> People have been burnt by Btrfs and just don't trust it's design. BcacheFS
> now has the best chance of
> being the next great thing - but Redhat wants to provide something for their
> customers now and is tired
> of playing the "it's getting better, we promise" game.  Hence the Stratis
> strategy.  It's a wise approach.
>

No. Red Hat has *zero* engineers that work on Btrfs. That's the real
reason for this.

If Red Hat *really* wanted it, they would have got someone to work on
it specifically to accelerate the stabilization of the filesystem code
for the next RHEL. That *never* happened since Josef Bacik left Red
Hat for Facebook years ago. Josef still works on Btrfs there, just for
Facebook instead of Red Hat.



-- 
真実はいつも一つ！/ 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

[Gerald B. Cox]

On Sat, Aug 5, 2017 at 9:58 AM, Neal Gompa  wrote:

>
> There are plenty of "clever" kernel modules that do bits and pieces of
> what Btrfs offers.

...there you can leverage all the benefits of Btrfs.
>
>
That's all fine and good but features mean nothing if you don't have faith
in the underlying filesystem.
People have been burnt by Btrfs and just don't trust it's design. BcacheFS
now has the best chance of
being the next great thing - but Redhat wants to provide something for
their customers now and is tired
of playing the "it's getting better, we promise" game.  Hence the Stratis
strategy.  It's a wise approach.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: heads up: poppler soname bump

[Tomasz Torcz]

On Sat, Aug 05, 2017 at 11:32:23AM -0400, Neal Gompa wrote:
> On Sat, Aug 5, 2017 at 10:49 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >> >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.
> >>
> >> And then, if test rebuild of such a big package like texlive against
> >> new poppler fails, poppler maintainer has to wait until texlive is
> >> to be ported into new poppler?
> >
> > Yes! That's how the new "no alphas" rawhide is supposed to
> > look. Maintainers are supposed to avoid a state where rawhide is
> > broken.
> >
> > poppler shouldn't be *blocked*, but it should be delayed a bit, so
> > that maintainers of the dependent packages are given a few days to
> > find a resolution.
> >
> 
> This is garbage. How the heck are we supposed to do crap like this
> when Koji itself isn't built to support this kind of thing freely? If
> anything, Koji (or something) should be doing the bloody rebuilds for
> us, automatically doing a scratch build and if that passes, do a "real
> build" with the bumped Release and changelog entry.

  Actually, we seem to have https://fedoraproject.org/wiki/Koschei for that.
Sadly, it does not work – I tried with it when I was upgrading 'owfs'
package (with soname change). Depentant 'collectd' wasn't rebuilt.

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

Fedora Rawhide-20170805.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Workstation live i386
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 23/137 (x86_64), 3/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170804.n.1):

ID: 126644  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/126644

Old failures (same test failed in Rawhide-20170804.n.1):

ID: 126638  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/126638
ID: 126645  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/126645
ID: 126658  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126658
ID: 126660  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126660
ID: 126671  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126671
ID: 126672  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/126672
ID: 126673  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/126673
ID: 126674  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126674
ID: 126675  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126675
ID: 126677  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126677
ID: 126688  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/126688
ID: 126690  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/126690
ID: 126692  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126692
ID: 126694  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126694
ID: 126726  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/126726
ID: 126728  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/126728
ID: 126730  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/126730
ID: 126731  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/126731
ID: 126733  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/126733
ID: 126735  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/126735
ID: 126736  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/126736
ID: 126770  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/126770
ID: 126771  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/126771
ID: 126786  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/126786
ID: 126787  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/126787
ID: 126788  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/126788

Soft failed openQA tests: 66/137 (x86_64), 13/18 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170804.n.1):

ID: 126701  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/126701
ID: 126702  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/126702
ID: 126708  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/126708
ID: 126720  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/126720
ID: 126727  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/126727
ID: 126756  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/126756

Old soft failures (same test soft failed in Rawhide-20170804.n.1):

ID: 126633  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126633
ID: 126634  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126634
ID: 126635  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126635
ID: 126636  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126636
ID: 126643  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: 

Re: BTRFS dropped by RedHat

[Richard W.M. Jones]

On Sat, Aug 05, 2017 at 12:58:15PM -0400, Neal Gompa wrote:
> On Sat, Aug 5, 2017 at 8:12 AM, Richard W.M. Jones  wrote:
> > On Fri, Aug 04, 2017 at 06:00:58PM +0200, František Zatloukal wrote:
> >> 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
> >
> > Stratis is a management tool that makes it a bit easier to manage all
> > the layers together.
> >
> > Another aspect which seems indicative of Red Hat's direction [I have
> > no inside information on strategy] is the recent acquisition of
> > Permabit (http://permabit.com/).  AIUI it's a device mapper module
> > which does some clever data deduplication and/or compression across LVs:
> >
> > https://www.theregister.co.uk/2016/06/29/permabit_offering_dedupe_to_linux_masses_almost/
> >
> 
> There are plenty of "clever" kernel modules that do bits and pieces of
> what Btrfs offers. For example, the place I work for created a kernel
> module that makes it possible to do VSS/CoW like snapshotting with
> *any* legacy file system (as long as it has a real block device)
> called dattobd:
> 
> https://github.com/datto/dattobd

That's actually something we could really use and the missing
piece I've been looking for, to do "live" virt-p2v :-/

> It can enable snapshotting for legacy file systems like ext4, xfs,
> jfs, etc. whether it's on LVM or not. It can also back up filesystems
> on things like LVM or mdraid.
> 
> That being said, I've been told that it's unlikely that such
> functionality will ever make it into the Linux kernel itself, and it's
> not as smooth as if the filesystem itself is able to do these things
> (like with Btrfs). The biggest pitfall of this approach? The
> filesystem has to be "frozen" for a small period of time while the
> snapshot is being taken. It's quite noticeable when you're using it on
> an hourly schedule, but it's minimized to the littlest effect possible
> without a filesystem like Btrfs.

I totally accept your point that it's better integrated in the
filesystem.

OTOH back to the P2V case, being able to snapshot arbitrary
filesystems (which as you say Windows can already do with VSS) is
brilliant.  Did they ever try to get this upstream?

> The effect is similar when using LVM snapshots. Stratis is even less
> useful than dattobd because it requires building the storage up in
> that way, whereas dattobd works with existing installations and Btrfs
> can be seeded from existing filesystems and from there you can
> leverage all the benefits of Btrfs.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Modularity]: Service levels and EOL expectations?

[Matthew Miller]

I'm looking at:

https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs
   
While not a part of the modulemd specification yet, modules will
eventually carry a Service Level (SL) value and an End of Life
(EOL) value.

The work in Changes/ArbitraryBranching will enable packagers to
select independent SLAs and EOLs for both their rpm branches as
well as their module branches. Both of these values are associated
with the branch in a dist-git repo, but not with the modulemd or
spec file contained therein.

Packagers will have to choose from a set of pre-defined SLs maintained by
Release Engineering. More info coming soon! 

Is there an active plan on figuring out these Service Levels? Is there
a ticket? Is there a specific person who owns this? I think we need at
least a preliminary understanding of what goes here for the F27 beta
(freeze on Sept. 9th, so... I guess by then?)

I'm assuming "Service Levels" will include options like:

* This module strives to be very stable and we will backport patches

* This module tries to be stable but occasionally we may make breaking
  changes with FESCo approval when it's the only option for a security
  update (this matches the current Fedora updates policy at 
  https://fedoraproject.org/wiki/Updates_Policy#Security_fixes)

* This module promises only a subset of functionality to remain the
  same. For example, it will include a certain command line program but
  doesn't promise that output of that program will aways be identical.

* This is a development-stream module which makes no promises! (E.g, it is
  Rawhide.)

Is that the kind of thing others are expecting? Or was this to be more
like "security", "security+bugfix", "security+bugfix+enhancements"?

*Or*, is it something like "best effort", "sig maintained", "core
critical path", "edition critical path", "spin critical path"?

I can see the first idea (the * points above) as most useful to
end-users. The third idea is more useful for *us*.

I'd also like to propose a policy for EOLs. I assume that some modules
will have undefined EOLs, and I think that's okay. There should be some
mechanism and rules for adding one (amount of notice expected, what to
do if we can't meet that expectation, how the tools will present the
addition of an EOL). When a specific EOL is given, though, I'd like a
rule which says that that EOL is aways a month after the planned
traditional Fedora release dates — so, June and November, basically.
(We could choose something like "The last Tuesday in June or November";
I don't care specifically.) Also, EOL should be treated as a "no sooner
than" date, so if we slip the corresponding release, we could add a
week or two to the upcoming module EOLs.

That way, users and admins aren't treated to an explosion of arbitrary
days where action is needed to stay on a current stream. Instead, they
can plan for annual upgrades as we do now. (I also expect the
"platform" module to follow the current Fedora release cycle, right?)

Perhaps there could be an exception made to this rule for modules with
the "development stream" Service Level. Or, maybe those would just have
no defined EOL — like Rawhide today.


-- 
Matthew Miller

Fedora Project Leader
___
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 Sat, Aug 5, 2017 at 8:12 AM, Richard W.M. Jones  wrote:
> On Fri, Aug 04, 2017 at 06:00:58PM +0200, František Zatloukal wrote:
>> 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
>
> Stratis is a management tool that makes it a bit easier to manage all
> the layers together.
>
> Another aspect which seems indicative of Red Hat's direction [I have
> no inside information on strategy] is the recent acquisition of
> Permabit (http://permabit.com/).  AIUI it's a device mapper module
> which does some clever data deduplication and/or compression across LVs:
>
> https://www.theregister.co.uk/2016/06/29/permabit_offering_dedupe_to_linux_masses_almost/
>

There are plenty of "clever" kernel modules that do bits and pieces of
what Btrfs offers. For example, the place I work for created a kernel
module that makes it possible to do VSS/CoW like snapshotting with
*any* legacy file system (as long as it has a real block device)
called dattobd:

https://github.com/datto/dattobd

It can enable snapshotting for legacy file systems like ext4, xfs,
jfs, etc. whether it's on LVM or not. It can also back up filesystems
on things like LVM or mdraid.

That being said, I've been told that it's unlikely that such
functionality will ever make it into the Linux kernel itself, and it's
not as smooth as if the filesystem itself is able to do these things
(like with Btrfs). The biggest pitfall of this approach? The
filesystem has to be "frozen" for a small period of time while the
snapshot is being taken. It's quite noticeable when you're using it on
an hourly schedule, but it's minimized to the littlest effect possible
without a filesystem like Btrfs.

The effect is similar when using LVM snapshots. Stratis is even less
useful than dattobd because it requires building the storage up in
that way, whereas dattobd works with existing installations and Btrfs
can be seeded from existing filesystems and from there you can
leverage all the benefits of Btrfs.


-- 
真実はいつも一つ！/ 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: heads up: poppler soname bump

[Björn 'besser82' Esser]

Am 05.08.2017 um 18:08 schrieb Zbigniew Jędrzejewski-Szmek:

On Fri, Aug 04, 2017 at 01:00:55PM -0700, Adam Williamson wrote:

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

In file included from /usr/include/poppler/PDFDoc.h:53:0,
  from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:
/usr/include/poppler/Form.h:353:32: warning: override controls (override/final) 
only available with -std=c++11 or -std=gnu++11
void fillChildrenSiblingsID () override;
 ^
In file included from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:0:
/usr/include/poppler/PDFDoc.h:295:153: error: 'nullptr' was not declared in 
this scope
void markPageObjects(Dict *pageDict, XRef *xRef, XRef *countRef, Guint numOffset, 
int oldRefNum, int newRefNum, std::set *alreadyMarkedDicts = nullptr);

It seem the new poppler requires c++11. I'm now starting a build of
texlive with -std=c++11 locally. On the off chance that it does work
like that, I can try to build it in rawhide too.

Zbyszek


It works.  Just tried to.  Will start the rebuild within a few mins…
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: heads up: poppler soname bump

[Björn 'besser82' Esser]

Am 05.08.2017 um 17:51 schrieb Adam Williamson:

On Sat, 2017-08-05 at 16:15 +0900, Mamoru TASAKA wrote:

Adam Williamson wrote on 08/05/2017 05:00 AM:

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,

Umm? Did you really check?
https://koji.fedoraproject.org/koji/builds?order=-completion_time=803

By 'this' I meant 'poppler and texlive' - I didn't check any others.


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.

And then, if test rebuild of such a big package like texlive against
new poppler fails, poppler maintainer has to wait until texlive is
to be ported into new poppler?

Yes. Yes, exactly that. We're building a distribution, we're not
running a Who Can Get A New Release Into The Repos The Fastest contest.
If something as important as texlive (which half the world depends on)
doesn't build against a new version of something, we don't want the new
version in our distribution yet.


The new version of poppler isn't compatible with pure C anymore; it 
*REQUIRES* to have a C++ compile, that at least support basic 
`-std=c++11` implementations like `nullptr`.


I fixed and rebuilt pdf2djvu as it was trivial.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: heads up: poppler soname bump

[Zbigniew Jędrzejewski-Szmek]

On Fri, Aug 04, 2017 at 01:00:55PM -0700, Adam Williamson wrote:
> 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

In file included from /usr/include/poppler/PDFDoc.h:53:0,
 from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:
/usr/include/poppler/Form.h:353:32: warning: override controls (override/final) 
only available with -std=c++11 or -std=gnu++11
   void fillChildrenSiblingsID () override;
^
In file included from ../../../texk/web2c/pdftexdir/pdftosrc.cc:52:0:
/usr/include/poppler/PDFDoc.h:295:153: error: 'nullptr' was not declared in 
this scope
   void markPageObjects(Dict *pageDict, XRef *xRef, XRef *countRef, Guint 
numOffset, int oldRefNum, int newRefNum, std::set *alreadyMarkedDicts = 
nullptr);

It seem the new poppler requires c++11. I'm now starting a build of
texlive with -std=c++11 locally. On the off chance that it does work
like that, I can try to build it in rawhide too.

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

Re: heads up: poppler soname bump

[Adam Williamson]

On Sat, 2017-08-05 at 11:32 -0400, Neal Gompa wrote:
> 
> This is garbage. How the heck are we supposed to do crap like this
> when Koji itself isn't built to support this kind of thing freely?

It's really not that difficult. You do a scratch build or build in
mock, then test building the dependencies in mock. Or you request a
Koji tag, or use COPR. Could tooling make it easier? Sure. Is the fact
that we don't have super nice tooling an excuse for breaking Rawhide?
No.

> We don't have a concept of projects in Koji where people can do these
> things without affecting the Rawhide package set,

Sure we do, it's called tags.

>  and COPR has no
> dependency tracking to indicate what depends on it in other
> repositories/linked projects,

How is this at all relevant to the purpose of using it to test
dependent rebuilds for something like a soname bump?

> We keep pushing for this stuff, but we're not even bothering to make
> it easier for packagers to keep up. What about the poor souls who
> aren't proven packagers? They're out of luck and they get blamed for
> "breaking Rawhide".

I'm not at all interested in blaming anyone for anything. I'm
interested in Rawhide not being broken. Note that you don't need commit
rights to do a scratch build, mock build or COPR build of something.
Note that I suggested the person doing the poppler build should have
*tested* that texlive built against it, which is something they do not
need any texlive commit rights to do.
-- 
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: heads up: poppler soname bump

[Adam Williamson]

On Sat, 2017-08-05 at 16:15 +0900, Mamoru TASAKA wrote:
> Adam Williamson wrote on 08/05/2017 05:00 AM:
> > 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, 
> 
> Umm? Did you really check?
> https://koji.fedoraproject.org/koji/builds?order=-completion_time=803

By 'this' I meant 'poppler and texlive' - I didn't check any others.

> > 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.
> 
> And then, if test rebuild of such a big package like texlive against
> new poppler fails, poppler maintainer has to wait until texlive is
> to be ported into new poppler?

Yes. Yes, exactly that. We're building a distribution, we're not
running a Who Can Get A New Release Into The Repos The Fastest contest.
If something as important as texlive (which half the world depends on)
doesn't build against a new version of something, we don't want the new
version in our distribution yet.
-- 
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: heads up: poppler soname bump

[Neal Gompa]

On Sat, Aug 5, 2017 at 10:49 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Sat, Aug 05, 2017 at 04:15:24PM +0900, Mamoru TASAKA wrote:
>> Adam Williamson wrote on 08/05/2017 05:00 AM:
>> >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,
>>
>> Umm? Did you really check?
>> https://koji.fedoraproject.org/koji/builds?order=-completion_time=803
>>
>> >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.
>>
>> And then, if test rebuild of such a big package like texlive against
>> new poppler fails, poppler maintainer has to wait until texlive is
>> to be ported into new poppler?
>
> Yes! That's how the new "no alphas" rawhide is supposed to
> look. Maintainers are supposed to avoid a state where rawhide is
> broken.
>
> poppler shouldn't be *blocked*, but it should be delayed a bit, so
> that maintainers of the dependent packages are given a few days to
> find a resolution.
>

This is garbage. How the heck are we supposed to do crap like this
when Koji itself isn't built to support this kind of thing freely? If
anything, Koji (or something) should be doing the bloody rebuilds for
us, automatically doing a scratch build and if that passes, do a "real
build" with the bumped Release and changelog entry.

We don't have a concept of projects in Koji where people can do these
things without affecting the Rawhide package set, and COPR has no
dependency tracking to indicate what depends on it in other
repositories/linked projects, much less auto-rebuilding.

For example, SUSE's OBS gives you this information on the package
detail page. For example:
https://build.opensuse.org/package/binary/openSUSE:Factory/rpm-python?arch=x86_64=rpm-python-4.13.0.1-5.1.x86_64.rpm=standard

(And of course, OBS automatically bumps packages and rebuilds for you,
so that you *don't* get stuck with stupid grunt work like this!)

We keep pushing for this stuff, but we're not even bothering to make
it easier for packagers to keep up. What about the poor souls who
aren't proven packagers? They're out of luck and they get blamed for
"breaking Rawhide".

I implore someone, please fix this before we keep going down this
path! I'm not against the "no more alphas" thing, but it seems like
everyone who is "for" this has forgotten that the overwhelming
majority of packagers are not actually capable of dealing with the
fallout of that kind of change.


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

Arbitrary Branching and solving the "Change Checkpoint? Better hit the gas!" problem

[Matthew Miller]

Our Change process has the basic assumption that if a Change isn't
working, we will be able to back out. But, in practice, when there are
problems, we often find it that it's easiest to shrug and go forward,
scrambling to fix problems in the change itself as well as any fallout.
I won't say this is a _failure_ exactly — with the Change process, at
least, we do have that checkpoint where we know the scramble is needed
rather than waiting until the very last minute. But, especially if we
are serious about a six-month schedule, it'd be _better_ if we could
simply decide at the Change Checkpoints whether to include the feature
at all.

Arbitrary branching and Modularity give us a way to do this. We can, at
any time, say "this release includes this set of modules" (see
https://docs.pagure.org/modularity/design/constructing/compose-distribution.html
and
https://docs.pagure.org/modularity/design/constructing/back-together.html).

I'm really liking what I'm seeing from the Boltron demo, questions
about how to actually manage modules as an end user notwithstanding. If
we can deliver this with minimal end-user disruption and yet give
ourselves capabilities like this, it's a huge success.

(Aside: This possibly involves what the Boltron walkthrough calls
"system profiles". Modularity team! This isn't in the docs yet. Can you
clarify?)



-- 
Matthew Miller

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

Re: heads up: poppler soname bump

[Zbigniew Jędrzejewski-Szmek]

On Sat, Aug 05, 2017 at 04:15:24PM +0900, Mamoru TASAKA wrote:
> Adam Williamson wrote on 08/05/2017 05:00 AM:
> >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,
> 
> Umm? Did you really check?
> https://koji.fedoraproject.org/koji/builds?order=-completion_time=803
> 
> >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.
> 
> And then, if test rebuild of such a big package like texlive against
> new poppler fails, poppler maintainer has to wait until texlive is
> to be ported into new poppler?

Yes! That's how the new "no alphas" rawhide is supposed to
look. Maintainers are supposed to avoid a state where rawhide is
broken.

poppler shouldn't be *blocked*, but it should be delayed a bit, so
that maintainers of the dependent packages are given a few days to
find a resolution.

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

Re: F27 and the short schedule [was Re: Fedora 27 Change Checkpoint: Completion deadline (testable)]

[Matthew Miller]

On Sat, Aug 05, 2017 at 01:10:44PM +0200, Kevin Kofler wrote:
> There seems to be a misunderstanding: I am not claiming that No-more-alphas 
> was invented specifically for the short F27 schedule. I am only pointing out 
> that the F27 schedule assumes No-more-alphas and that such a short schedule 
> is not possible without it. Fedora has never had such a short schedule 
> before.

Yes. This is all true, and not without risk.

-- 
Matthew Miller

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

Fedora Rawhide-20170804.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Workstation live i386
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 25/137 (x86_64), 3/18 (i386), 1/2 (arm)

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

ID: 126481  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/126481
ID: 126515  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/126515
ID: 126516  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/126516
ID: 126518  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126518
ID: 126520  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126520
ID: 126533  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/126533
ID: 126535  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126535
ID: 126570  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/126570

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

ID: 126488  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/126488
ID: 126501  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126501
ID: 126502  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126502
ID: 126503  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126503
ID: 126514  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126514
ID: 126517  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126517
ID: 126531  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/126531
ID: 126537  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126537
ID: 126569  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/126569
ID: 126571  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/126571
ID: 126573  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/126573
ID: 126574  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/126574
ID: 126576  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/126576
ID: 126578  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/126578
ID: 126579  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/126579
ID: 126599  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/126599
ID: 126613  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/126613
ID: 126614  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/126614
ID: 126629  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/126629
ID: 126630  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/126630
ID: 126631  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/126631

Soft failed openQA tests: 63/137 (x86_64), 15/18 (i386)
(Tests completed, but using a workaround for a known bug)

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

ID: 126487  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/126487
ID: 126496  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/126496
ID: 126547  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/126547
ID: 126582  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/126582
ID: 126600  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/126600
ID: 126603  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/126603

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

ID: 126476  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126476
ID: 126477  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126477
ID: 126478  Test: x86_64 Server-dvd-iso install_default_upload
URL: 

Re: BTRFS dropped by RedHat

[Richard W.M. Jones]

On Fri, Aug 04, 2017 at 06:00:58PM +0200, František Zatloukal wrote:
> 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

Stratis is a management tool that makes it a bit easier to manage all
the layers together.

Another aspect which seems indicative of Red Hat's direction [I have
no inside information on strategy] is the recent acquisition of
Permabit (http://permabit.com/).  AIUI it's a device mapper module
which does some clever data deduplication and/or compression across LVs:

https://www.theregister.co.uk/2016/06/29/permabit_offering_dedupe_to_linux_masses_almost/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 and the short schedule [was Re: Fedora 27 Change Checkpoint: Completion deadline (testable)]

[Kevin Kofler]

Jan Kurik wrote:
> This is going to follow the Change process, so if at certain point in
> time the Change will not be ready it will go to FESCo to review the
> progress and weight risks and benefits of the Change. It is then up to
> FESCo to decide. Anyone from the Fedora community can join FESCo
> meetings and express his/her concerns about any Change. You might see
> risks others do not see, so you can try to describe those concerns to
> FESCo providing them with broader information to make qualified
> decision then.

FESCo does not have a history of actually getting broken changes reverted, 
see the NetworkManager 0.9 fiasco in Fedora 15. (For those who do not 
remember: Fedora 15 shipped with a NM 0.9 prerelease despite the KDE tools 
not being ready for it, they ended up patching in a NM 0.8 compatibility API 
into it, but NM updates were alternating between breaking the new API and 
breaking the old API, and each time they went into stable very quickly 
because the users of the desktop that was fixed were very quickly giving +1 
votes. The KDE NM frontend then had to be updated to an NM 0.9 version when 
it was still under development upstream and had issues with migrating 
existing configurations, because the 0.8 compatibility API had just broken 
down completely in an NM update and was not getting fixed anymore. The NM 
0.8 compatibility API also only supported the exact feature set that that 
particular snapshot of the KDE NM frontend happened to use, so we were 
unable to upgrade to newer snapshots until the branch targeting NM 0.9 was 
created upstream.) So I do not think they will actually get those Changes 
withdrawn if they are broken, especially considering how they have been 
forced through so far.

> No-more-alphas is not forced by F27 schedule. It is a goal we were
> talking about for some time (there were realistic discussions at least
> from the time of F23 release). The infrastructure is getting ready for
> it step by step, i.e. development of new "pungi" allowing us to do
> nightly builds, the development and enhancement of automated CI
> pipeline (Taskotron, OpenQA) etc. were prerequisites for the
> No-more-alphas Change which were put in place before we decided to
> skip the Alpha. I see your point and I agree that due to slip of F26
> for five weeks we are in the pressure for F27, but it has nothing to
> do with the No-more-alphas Change. We were aiming to implement this
> Change for a long time.

There seems to be a misunderstanding: I am not claiming that No-more-alphas 
was invented specifically for the short F27 schedule. I am only pointing out 
that the F27 schedule assumes No-more-alphas and that such a short schedule 
is not possible without it. Fedora has never had such a short schedule 
before.

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

Re: Builds stuck in f27-pending

[Björn 'besser82' Esser]

Am 04.08.2017 um 11:47 schrieb 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


Looks like `libyui-3.3.3-1.fc27` is still stuck in f27-pending, where 
other packages like `poppler`, which have been built later, are already 
signed and tagged in `f27`…

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

Re: heads up: poppler soname bump

[Mamoru TASAKA]

Adam Williamson wrote on 08/05/2017 05:00 AM:

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, 


Umm? Did you really check?
https://koji.fedoraproject.org/koji/builds?order=-completion_time=803


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.


And then, if test rebuild of such a big package like texlive against
new poppler fails, poppler maintainer has to wait until texlive is
to be ported into new poppler?

Regards,
Mamoru

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