Re: DNF 1.0.2 Released

[Vít Ondruch]

Dne 28.7.2015 v 08:48 Marcin Juszkiewicz napsal(a):
> W dniu 22.07.2015 o 10:49, Honza Šilhan pisze:
>
>> The resolution configuration hints are printed to the output and user
>> is notified which packages were skipped during update in case there
>> are conflicts.
> No information about skipped updates on my system (or I misunderstood
> how it is supposed to work):

https://bugzilla.redhat.com/show_bug.cgi?id=1210445#c19


Vít


>
> # dnf update --best
> Last metadata expiration check performed 0:03:19 ago on Tue Jul 28 08:41:56 
> 2015.
> Error: package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
> libpoppler.so.52()(64bit), but none of the providers can be installed.
> package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
> libpoppler.so.52()(64bit), but none of the providers can be installed.
> package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
> libpoppler.so.52()(64bit), but none of the providers can be installed.
> package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
> libpoppler.so.52()(64bit), but none of the providers can be installed.
> package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
> libpoppler.so.52()(64bit), but none of the providers can be installed.
> package libreoffice-pdfimport-1:5.0.0.3-1.fc23.x86_64 requires 
> libpoppler.so.52()(64bit), but none of the providers can be installed
>
> # dnf update
>
> Transaction Summary
> ==
> Install 15 Packages
> Upgrade 479 Packages
> Remove 5 Packages
>
> Total download size: 591 M
>
> # dnf --version
> 1.0.2
>   Installed: dnf-0:1.0.2-2.fc24.noarch at 2015-07-28 06:41
>   Built: Fedora Project at 2015-07-21 16:35
>
>   Installed: rpm-0:4.12.0.1-17.fc23.x86_64 at 2015-07-14 11:25
>   Built: Fedora Project at 2015-06-29 10:26

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Lubos Kardos]

Support in rpm is not enough but libsolv supports rich deps since the version
0.6.9 too thus rich deps work also in hawkey and dnf if the version 0.6.9 or
a newer version of libsolv is installed.

Lubos

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, July 27, 2015 5:36:45 PM
> Subject: Re: [HEADS UP] rpm-4.12.90 in rawhide
> 
> Dne 24.7.2015 v 15:49 Florian Festi napsal(a):
> >  * Boolean (aka rich) dependencies to support more complicated relation
> > between packages
> 
> Is this supported by dnf/hawkey/libsolv already or just RPM support is
> enough?
> 
> 
> Vít
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Peter Robinson]

On Tue, Jul 28, 2015 at 2:34 AM, Dan Callaghan  wrote:
> Excerpts from paulo.cesar.pereira.de.andrade's message of 2015-07-27 00:05 
> +10:00:
>> Should I make the doc packages arch specific?
>
> Rather than trying to make Sphinx spit out bitwise-identical output on
> every arch (which sounds like fighting a losing battle), could you just
> build the doc subpackage on only one arch?
>
> %ifarch x86_64
> %package doc
> BuildArch: noarch
> ...
> %endif
>
> I think Koji still counts this a regular noarch subpackage and it should
> therefore be included in the Fedora trees for all arches.

Dan,

This is completely NOT appropriate, it breaks on secondary arches
where they then end up with no documentation due to the lack of any
x86_64. Please DO NOT do this and please revert the change on any
packages you might have made this change.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Peter Robinson]

On Tue, Jul 28, 2015 at 4:37 AM, Paulo César Pereira de Andrade
 wrote:
> 2015-07-27 22:34 GMT-03:00 Dan Callaghan :
>> Excerpts from paulo.cesar.pereira.de.andrade's message of 2015-07-27 00:05 
>> +10:00:
>>> Should I make the doc packages arch specific?
>>
>> Rather than trying to make Sphinx spit out bitwise-identical output on
>> every arch (which sounds like fighting a losing battle), could you just
>> build the doc subpackage on only one arch?
>>
>> %ifarch x86_64
>> %package doc
>> BuildArch: noarch
>> ...
>> %endif
>
>   This looks like a very wise way of handling it. Actually, while debugging

It's not, it breaks all secondary architectures.

> it, I found that the translated documentation was not being properly
> generated, and after fixing it, it would take like 3 to 4 times longer
> to generate docs, and doc generation was already almost 80% of
> the package build time...

That tells me the process of generating docs is broken, or they're
very good docs and worth the wait!

>> I think Koji still counts this a regular noarch subpackage and it should
>> therefore be included in the Fedora trees for all arches.
>
>   In the worst case, it would generate -doc packages only for x86_64,
> where most users interested on reading it would be using.

And won't generate docs for any of the secondary arches which don't
have any x86_64 build capacity, please don't do this.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging with hidden strings

[Florian Weimer]

On 07/28/2015 07:33 AM, Jiří Konečný wrote:

> I have a theoretical question. Is it possible to a create package to
> Fedora which is using oauth2 authentication and that means there are
> app_id and secret_code strings generated by api provider? These strings
> are used in the program but can't be shipped in the code because
> everyone could then use these codes to look as this application.

No, this is not possible.  May be you could create a tool which
simplifies obtaining suitable API keys and ship that instead?

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Florian Weimer]

On 07/26/2015 04:05 PM, Paulo César Pereira de Andrade wrote:

> Should I make the doc packages arch specific?

No, this is not a reason to make them arch-specific.  A lot of packages
give different results when built twice in a row, on the *same*
architecture.

There is an effort under way to change that, called “reproducible
builds”.  The hard part is any reproducibility at all, identical noarch
builds across architectures are likely just some additional work on top
of it.

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates push status - 20150725

[Ralf Corsepius]

On 07/28/2015 07:57 AM, Alexander Ploumistos wrote:

Has the issue been resolved? I have pushed three new packages to f22
and f21 updates-testing, but they have yet to appear in my usual local
mirrors.


I guess no.

I am waiting for my updates to get for weeks and am already withholding 
other followup updates.


Folks, please think about the implications this kind of unreliability 
has on Fedora.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/28/2015 09:43 AM, Lubos Kardos wrote:
> Support in rpm is not enough but libsolv supports rich deps since the version
> 0.6.9 too thus rich deps work also in hawkey and dnf if the version 0.6.9 or
> a newer version of libsolv is installed.

Right now only AND and OR is supported by libsolv. Implementation of IF
ELSE is still pending.

Also we still need to settle to a final syntax for the operators [1].
Unfortunately there is no consensus among the other packaging formats
what to use. Right now rpm accepts 3 different styles:
 * AND OR IF ELSE
 * & | ? :
 * && || ? :
But the final release will only support on of them. As soon as the alpha
stops eating babies that's a discussion we need to have.

So for now they are more a tech preview in Fedora but we want to get
them operational til the release. This still means that they are not
supposed to be used in F23 as they may only completely work very late.
Also there is still a lot of paper work to do for the packaging policy.

I expect that both Boolean Deps and File Triggers won't be introduced in
one go but there will be multiple Fedora Features introducing them one
use case at a time. E.g. one feature per file trigger replacing one kind
of scriptlets. Boolean dependencies being used for language packs being
one Feature/Package Policy section and other use cases being others.

This may start in the F24 time frame - especially for some urgent corner
cases - but my guess is that this will rather take multiple releases.

Florian

[1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies

-- 

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, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates push status - 20150725

[Kevin Fenzi]

On Tue, 28 Jul 2015 08:57:44 +0300
Alexander Ploumistos  wrote:

> Has the issue been resolved? I have pushed three new packages to f22
> and f21 updates-testing, but they have yet to appear in my usual local
> mirrors.

No. We continue to work on it. 

The current issue is some more issues with the f22-updates-testing
atomic compose. A non announced abi break in a dependent package was
found and we were hopeful that would solve things, but it didn't. 

The maintainer of rpm-ostree and bodhi have been working on it pretty
much non stop yesterday. 

Hopefully we can get it solved today.

kevin


pgpCQdFPQ06nx.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates push status - 20150725

[Alexander Ploumistos]

On Tue, Jul 28, 2015 at 12:46 PM, Kevin Fenzi  wrote:
> No. We continue to work on it.

Thanks for the information, I thought I had done something wrong in
the submission process.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging with hidden strings

[Jiří Konečný]

On Tue, 2015-07-28 at 10:50 +0200, Florian Weimer wrote:
> On 07/28/2015 07:33 AM, Jiří Konečný wrote:
> No, this is not possible.  May be you could create a tool which
> simplifies obtaining suitable API keys and ship that instead?
> 
> -- 
> Florian Weimer / Red Hat Product Security

Ok thank you for your answer Florian.


Jiri Konecny
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Neal Gompa]

On Tue, Jul 28, 2015 at 5:37 AM, Florian Festi  wrote:

> On 07/28/2015 09:43 AM, Lubos Kardos wrote:
> > Support in rpm is not enough but libsolv supports rich deps since the
> version
> > 0.6.9 too thus rich deps work also in hawkey and dnf if the version
> 0.6.9 or
> > a newer version of libsolv is installed.
>
> Right now only AND and OR is supported by libsolv. Implementation of IF
> ELSE is still pending.
>
> Also we still need to settle to a final syntax for the operators [1].
> Unfortunately there is no consensus among the other packaging formats
> what to use. Right now rpm accepts 3 different styles:
>  * AND OR IF ELSE
>  * & | ? :
>  * && || ? :
> But the final release will only support on of them. As soon as the alpha
> stops eating babies that's a discussion we need to have.
>
> So for now they are more a tech preview in Fedora but we want to get
> them operational til the release. This still means that they are not
> supposed to be used in F23 as they may only completely work very late.
> Also there is still a lot of paper work to do for the packaging policy.
>
> I expect that both Boolean Deps and File Triggers won't be introduced in
> one go but there will be multiple Fedora Features introducing them one
> use case at a time. E.g. one feature per file trigger replacing one kind
> of scriptlets. Boolean dependencies being used for language packs being
> one Feature/Package Policy section and other use cases being others.
>
> This may start in the F24 time frame - especially for some urgent corner
> cases - but my guess is that this will rather take multiple releases.
>
> Florian
>
> [1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies
>
> --
>
> 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, Charles Peters
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Is there a reason why we can't maintain all three kinds? Also, why in the
world are bitwise operation operators supported for logical operations? I'd
be okay with maintaining options 1 and 3, to be honest. ​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-23 Branched report: 20150728 changes

[Fedora Branched Report]

Compose started at Tue Jul 28 07:15:03 UTC 2015
Broken deps for armhfp
--
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[dpm-dsi]
dpm-dsi-1.9.5-5.fc23.armv7hl requires 
globus-gridftp-server-progs(armv7hl-32) = 0:7.26
[gammaray]
gammaray-qt5-2.2.1-10.fc23.armv7hl requires qt5-qtbase(armv7hl-32) = 
0:5.4.2
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-7.fc23.armv7hl requires 
ghc(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae)
ghc-hjsmin-devel-0.1.4.7-7.fc23.armv7hl requires 
ghc-devel(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae)
[gnome-python2]
gnome-python2-bonobo-2.28.1-16.fc23.armv7hl requires 
pyorbit(armv7hl-32) >= 0:2.0.1
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.11.0-0.3.gitc7ad79d3.fc23.armv7hl 
requires libgnome-desktop-3.so.10
[gtatool]
gtatool-hdr-2.1.0-7.fc23.armv7hl requires libpfs-1.2.so.0
[gtksourceview-sharp]
gtksourceview-sharp-2.0.12-24.fc23.armv7hl requires gtksourceview
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hawaii-shell]
hawaii-shell-0.3.0-3.fc22.armv7hl requires 
libqtaccountsservice-qt5.so.0.1.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[klavaro]
klavaro-3.01-0.pre1.1.fc23.1.armv7hl requires libgtkdataboks.so.0
[mariadb-galera]
1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera >= 
0:25.3.3
[mesos]
mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires libprotobuf.so.8
python-mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires 
libprotobuf.so.8
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[mule]
mule-module-builders-2.0.2.20080813-11.fc21.noarch requires 
tomcat-servlet-3.0-api
mule-transport-http-2.0.2.20080813-11.fc21.noarch requires 
tomcat-servlet-3.0-api
mule-transport-servlet-2.0.2.20080813-11.fc21.noarch requires 
tomcat-servlet-3.0-api
[ncbi-blast+]
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxformat.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxcleanup.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libvalid.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libpubmed.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmlacli.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmla.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmedlars.so
ncbi-blast+-2.2.31-1.fc23.armv7hl requires libgbseq.so
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Vít Ondruch]

Dne 28.7.2015 v 13:37 Neal Gompa napsal(a):
> On Tue, Jul 28, 2015 at 5:37 AM, Florian Festi  >wrote:
>
> On 07/28/2015 09:43 AM, Lubos Kardos wrote:
> > Support in rpm is not enough but libsolv supports rich deps
> since the version
> > 0.6.9 too thus rich deps work also in hawkey and dnf if the
> version 0.6.9 or
> > a newer version of libsolv is installed.
>

$ rpm -q libsolv
libsolv-0.6.11-1.fc22.x86_64

Sounds great ...

>
> Right now only AND and OR is supported by libsolv. Implementation
> of IF
> ELSE is still pending.
>
> Also we still need to settle to a final syntax for the operators [1].
> Unfortunately there is no consensus among the other packaging formats
> what to use. Right now rpm accepts 3 different styles:
>  * AND OR IF ELSE
>  * & | ? :
>  * && || ? :
> But the final release will only support on of them. As soon as the
> alpha
> stops eating babies that's a discussion we need to have.
>
> So for now they are more a tech preview in Fedora but we want to get
> them operational til the release.
>

Never thought about anything else than Rawhide ...

> This still means that they are not
> supposed to be used in F23 as they may only completely work very late.
> Also there is still a lot of paper work to do for the packaging
> policy.
>
> I expect that both Boolean Deps and File Triggers won't be
> introduced in
> one go but there will be multiple Fedora Features introducing them one
> use case at a time. E.g. one feature per file trigger replacing
> one kind
> of scriptlets. Boolean dependencies being used for language packs
> being
> one Feature/Package Policy section and other use cases being others.
>

Just out of curiosity, do you have already any candidates for File
Triggers? I suppose "/sbin/ldconfig" is one of them. Do you plan to have
some F24 feature to get rid of these?

>
> This may start in the F24 time frame - especially for some urgent
> corner
> cases - but my guess is that this will rather take multiple releases.
>
> Florian
>
> [1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies
>
> --
>
> 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, Charles Peters
> --
> devel mailing list
> devel@lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
> ​Is there a reason why we can't maintain all three kinds? Also, why in
> the world are bitwise operation operators supported for logical
> operations? I'd be okay with maintaining options 1 and 3, to be honest. ​

1 and 3 looks good to me.


Vít
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Michael Schroeder]

On Tue, Jul 28, 2015 at 07:37:05AM -0400, Neal Gompa wrote:
> On Tue, Jul 28, 2015 at 5:37 AM, Florian Festi  wrote:
> > Unfortunately there is no consensus among the other packaging formats
> > what to use. Right now rpm accepts 3 different styles:
> >  * AND OR IF ELSE
> >  * & | ? :
> >  * && || ? :
> 
> ???Is there a reason why we can't maintain all three kinds? Also, why in the
> world are bitwise operation operators supported for logical operations? I'd
> be okay with maintaining options 1 and 3, to be honest. ???

I allowed '|' and '&' to be somewhat compatible to Debian, which
already uses '|' in the dependencies.

And there's IF and THEN/ELSE. IF is a postfix op, like in perl
and ruby:

Requires: a IF b

THEN/ELSE is the infix one:

Requires: b THEN a
Requires: b ? a
Requires: b THEN a ELSE c
Requires: b ? a : c

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Florian Festi]

On 07/28/2015 02:49 PM, Vít Ondruch wrote:
> Just out of curiosity, do you have already any candidates for File
> Triggers? I suppose "/sbin/ldconfig" is one of them. Do you plan to have
> some F24 feature to get rid of these?

Well, we do not yet have concrete plans with which scriptlets to start.
 https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Snippets is
full of possible candidates. I still have to figure out how much I want
to push this as the rpm upstream developer or how far I can leave this
to the Fedora community and just provide technical support. I guess I
will at least start with one and then see if people pick that up.

Florian

-- 

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, Charles Peters
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

python-ntplib license change

[Vratislav Podzimek]

With the new upstream release python-ntplib-0.3.3 the license was
changed from LGPLv2+ to the MIT license. The only package that requires
python-ntplib seems to be anaconda which is not affected by the change,
but I'm rather letting you guys know.

Thanks,

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Boost updated to 1.58.0 in rawhide and f23

[Jonathan Wakely]

On 27/07/15 19:35 -0700, Adam Williamson wrote:

On Mon, 2015-07-27 at 13:31 +0100, Jonathan Wakely wrote:

On 23/07/15 14:33 +0200, David Tardon wrote:
> Hi,
>
> On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote:
> > Hi,
> >
> > On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote:
> > > Any problems rebuilding either open a bug or feel free to email
> > > me or
> > > ping me on IRC (my freenode nick is 'redi') and I'll be happy
> > > to help.
> >
> > This is a work-in-progress list of FTBFS packages:
> >
> > * Build failures:
> >
> > - F23 + Rawhide
> >
> > ledger

This patch is needed to make Ledger compile with Boost 1.58.0


I submitted a build using the patch you submitted as an upstream PR -
https://github.com/ledger/ledger/pull/422 - but it still failed:

https://kojipkgs.fedoraproject.org//work/tasks/9527/10499527/build.log


Yes, as well as my patch for #422 you still need the second half of
the patch for the upstream #417 (which was not reverted), which I've
attached to this mail.

Thanks for doing these fixes.

>From 68c9d649caa2c7c7f222613efe86576c379a5a7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Johann=20Kl=C3=A4hn?= 
Date: Sun, 10 May 2015 13:41:26 +0200
Subject: [PATCH 2/2] fix build for boost 1.58

---
 src/filters.cc   | 2 +-
 src/iterators.cc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/filters.cc b/src/filters.cc
index 2f97a0e..b6530c0 100644
--- a/src/filters.cc
+++ b/src/filters.cc
@@ -707,7 +707,7 @@ namespace {
 insert_prices_in_map(price_map_t& _all_prices)
   : all_prices(_all_prices) {}
 
-void operator()(datetime_t& date, const amount_t& price) {
+void operator()(const datetime_t& date, const amount_t& price) {
   all_prices.insert(price_map_t::value_type(date, price));
 }
   };
diff --git a/src/iterators.cc b/src/iterators.cc
index 21bec5d..0225e21 100644
--- a/src/iterators.cc
+++ b/src/iterators.cc
@@ -96,7 +96,7 @@ namespace {
   TRACE_DTOR(create_price_xact);
 }
 
-void operator()(datetime_t& date, const amount_t& price) {
+void operator()(const datetime_t& date, const amount_t& price) {
   xact_t * xact;
   string   symbol = price.commodity().symbol();
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Boost updated to 1.58.0 in rawhide and f23

[Jonathan Wakely]

On 28/07/15 14:48 +0100, Jonathan Wakely wrote:

On 27/07/15 19:35 -0700, Adam Williamson wrote:

On Mon, 2015-07-27 at 13:31 +0100, Jonathan Wakely wrote:

On 23/07/15 14:33 +0200, David Tardon wrote:

Hi,

On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote:
> Hi,
>
> On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote:
> > Any problems rebuilding either open a bug or feel free to email
> > me or
> > ping me on IRC (my freenode nick is 'redi') and I'll be happy
> > to help.
>
> This is a work-in-progress list of FTBFS packages:
>
> * Build failures:
>
> - F23 + Rawhide
>
> ledger


This patch is needed to make Ledger compile with Boost 1.58.0


I submitted a build using the patch you submitted as an upstream PR -
https://github.com/ledger/ledger/pull/422 - but it still failed:

https://kojipkgs.fedoraproject.org//work/tasks/9527/10499527/build.log


Yes, as well as my patch for #422 you still need the second half of
the patch for the upstream #417 (which was not reverted), which I've
attached to this mail.


Oh, and then it *still* fails because of unpackaged files, see
https://kojipkgs.fedoraproject.org//work/tasks/1167/10501167/build.log
which I did yesterday using the constness patch from my previous mail
and my upstream fix for #422.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20150728 changes

[Fedora Rawhide Report]

Compose started at Tue Jul 28 05:15:03 UTC 2015
Broken deps for i386
--
[abrt]
abrt-2.6.2-3.fc24.i686 requires librpmio.so.3
abrt-2.6.2-3.fc24.i686 requires librpm.so.3
abrt-atomic-2.6.2-3.fc24.i686 requires librpmio.so.3
abrt-atomic-2.6.2-3.fc24.i686 requires librpm.so.3
abrt-plugin-bodhi-2.6.2-3.fc24.i686 requires librpmio.so.3
abrt-plugin-bodhi-2.6.2-3.fc24.i686 requires librpm.so.3
[abrt-java-connector]
abrt-java-connector-1.1.0-4.fc23.i686 requires librpmio.so.3
abrt-java-connector-1.1.0-4.fc23.i686 requires librpm.so.3
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[apt]
apt-0.5.15lorg3.95-20.git522.fc23.i686 requires librpmio.so.3
apt-0.5.15lorg3.95-20.git522.fc23.i686 requires librpm.so.3
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[clean-extra-utils]
clean-extra-utils-0.1-9.fc23.i686 requires clean
[cyrus-imapd]
cyrus-imapd-2.4.17-11.fc23.i686 requires librpmio.so.3
cyrus-imapd-2.4.17-11.fc23.i686 requires librpm.so.3
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.i686 requires MySQL-python(x86-32)
[dpm-dsi]
dpm-dsi-1.9.5-5.fc23.i686 requires globus-gridftp-server-progs(x86-32) 
= 0:7.26
[foghorn]
foghorn-0.1.6-9.fc23.i686 requires librpmio.so.3
foghorn-0.1.6-9.fc23.i686 requires librpm.so.3
[gammaray]
gammaray-qt5-2.2.1-10.fc23.i686 requires qt5-qtbase(x86-32) = 0:5.4.2
[gazebo]
gazebo-5.1.0-2.fc23.i686 requires libgdal.so.1
gazebo-libs-5.1.0-2.fc23.i686 requires libgdal.so.1
player-gazebo-5.1.0-2.fc23.i686 requires libgdal.so.1
[gnatcoll]
gnatcoll-2014-4.fc23.i686 requires libgtkada-3.8.so.2
[gnome-python2]
gnome-python2-bonobo-2.28.1-16.fc23.i686 requires pyorbit(x86-32) >= 
0:2.0.1
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.11.0-0.3.gitc7ad79d3.fc23.i686 
requires libgnome-desktop-3.so.10
[golang-github-samalba-dockerclient]
golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch 
requires golang(github.com/docker/docker/utils)
golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch 
requires golang(github.com/docker/docker/pkg/timeutils)
golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch 
requires golang(github.com/docker/docker/pkg/stdcopy)
golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch 
requires golang(github.com/docker/docker/pkg/jsonlog)
[gqrx]
gqrx-2.3.2-7.fc23.i686 requires libgnuradio-runtime-3.7.7.so.0.0.0
gqrx-2.3.2-7.fc23.i686 requires libgnuradio-pmt-3.7.7.so.0.0.0
gqrx-2.3.2-7.fc23.i686 requires libgnuradio-filter-3.7.7.so.0.0.0
gqrx-2.3.2-7.fc23.i686 requires libgnuradio-fft-3.7.7.so.0.0.0
gqrx-2.3.2-7.fc23.i686 requires libgnuradio-blocks-3.7.7.so.0.0.0
gqrx-2.3.2-7.fc23.i686 requires libgnuradio-analog-3.7.7.so.0.0.0
[gr-air-modes]
gr-air-modes-0-0.33.20140312gitcc0fa180.fc23.i686 requires 
libgnuradio-runtime-3.7.7.so.0.0.0
gr-air-modes-0-0.33.20140312gitcc0fa180.fc23.i686 requires 
libgnuradio-pmt-3.7.7.so.0.0.0
[gr-fcdproplus]
gr-fcdproplus-0-0.11.20140920git1edbe523.fc23.i686 requires 
libgnuradio-runtime-3.7.7.so.0.0.0
gr-fcdproplus-0-0.11.20140920git1edbe523.fc23.i686 requires 
libgnuradio-blocks-3.7.7.so.0.0.0
gr-fcdproplus-0-0.11.20140920git1edbe523.fc23.i686 requires 
libgnuradio-audio-3.7.7.so.0.0.0
[gr-iqbal]
gr-iqbal-0.37.2-8.fc23.i686 requires libgnuradio-runtime-3.7.7.so.0.0.0
gr-iqbal-0.37.2-8.fc23.i686 requires libgnuradio-pmt-3.7.7.so.0.0.0
[gr-osmosdr]
gr-osmosdr-0.1.3-6.20141023git42c66fdd.fc23.i686 requires 
libgnuradio-uhd-3.7.7.so.0.0.0
gr-osmosdr-0.1.3-6.20141023git42c66fdd.fc23.i686 requires 
libgnuradio-runtime-3.7.7.so.0.0.0
gr-osmosdr-0.1.3-6.20141023git42c66fdd.fc23.i686 requires 
libgnuradio-pmt-3.7.7.so.0.0.0
gr-osmosdr-0.1.3-6.20141023git42c66fdd.fc23.i686 requires 
libgnuradio-fcd-3.7.7.so.0.0.0
gr-osmosdr-0.1.3-6.20141023git42c66fdd.fc23.i686 requires 
libgnuradio-blocks-3.7.7.so.0.0.0
[gr-rds]
gr-rds-0-0.9.20141117gitff1ca15.fc23.i686 requires 
libgnuradio-runtime-3.7.7.so.0.0.0
gr-rds-0-0.9.20141117gitff1ca15.fc23.i686 requires 
libgnuradio-pmt-3.7.7.so.0.0.0
[gtatool]
gtatool-gdal-2.1.0-7.fc23.i686 requires libgdal.so.1
gtatool-hdr-2.1.0-7.fc23.i686 requires libpfs-1.2.so.0
[gtksourceview-sharp]
gtksourceview-sharp-2.0.12-24.fc23.i686 requires gtksourceview
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-s

Re: pyorbit

[Michael Schwendt]

> http://pkgs.fedoraproject.org/cgit/pyorbit.git/plain/dead.package
> 
> > last user has been retired, package EOL
> 
> Error: nothing provides pyorbit(x86-64) >= 2.0.1 needed by 
> gnome-python2-bonobo-2.28.1-16.fc23.x86_64
> 
> What's the full story here? Where has this been discussed/announced?

I'm no longer interested in a response to this inquiry as I've dropped
ownership of SoundConverter (which depends on gnome-python2-bonobo and some
other gnome-python2-* packages).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

2015-07-28 5:58 GMT-03:00 Florian Weimer :
> On 07/26/2015 04:05 PM, Paulo César Pereira de Andrade wrote:
>
>> Should I make the doc packages arch specific?
>
> No, this is not a reason to make them arch-specific.  A lot of packages
> give different results when built twice in a row, on the *same*
> architecture.
>
> There is an effort under way to change that, called “reproducible
> builds”.  The hard part is any reproducibility at all, identical noarch
> builds across architectures are likely just some additional work on top
> of it.

  I believe that if there is a check for bit by bit identical noarch
packages, it would also be mandatory some way to tell that
any minor difference is ok and expected, and use the noarch
built on that arch...

> --
> Florian Weimer / Red Hat Product Security

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Paulo César Pereira de Andrade]

2015-07-28 5:03 GMT-03:00 Peter Robinson :

>>> %ifarch x86_64
>>> %package doc
>>> BuildArch: noarch
>>> ...
>>> %endif
>>
>>   This looks like a very wise way of handling it. Actually, while debugging
>
> It's not, it breaks all secondary architectures.
>
>> it, I found that the translated documentation was not being properly
>> generated, and after fixing it, it would take like 3 to 4 times longer
>> to generate docs, and doc generation was already almost 80% of
>> the package build time...
>
> That tells me the process of generating docs is broken, or they're
> very good docs and worth the wait!

  It is the later. It has its problems of course, but the documentation
is really very good and complete, documenting every single interface.
It is "live", once running the sagemath "notebook", one can modify
the examples, run with different input, etc.

Thanks,
Paulo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Matthias Clasen]

On Tue, 2015-07-28 at 14:49 +0200, Vít Ondruch wrote:

> Just out of curiosity, do you have already any candidates for File 
> Triggers? I suppose "/sbin/ldconfig" is one of them. Do you plan to 
> have some F24 feature to get rid of these?

Here is a list of candidates:

https://fedoraproject.org/wiki/Workstation/Tasklist#filetrigger
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Ralf Corsepius]

On 07/28/2015 10:58 AM, Florian Weimer wrote:

On 07/26/2015 04:05 PM, Paulo César Pereira de Andrade wrote:


Should I make the doc packages arch specific?


No, this is not a reason to make them arch-specific.  A lot of packages
give different results when built twice in a row, on the *same*
architecture.

There is an effort under way to change that, called “reproducible
builds”.


Actually, reproducable builds wrt. docs have been subject to Fedora 
Packaging since Fedora day #1 and repeatedly have been subject to 
discussions of details (e.g. doxygen repeatedly had introduced docs 
breakages)


Packages which do not comply to this rule are broken.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

and legacy software Re: pyorbit

[Sérgio Basto]

On Ter, 2015-07-28 at 16:48 +0200, Michael Schwendt wrote:
> > http://pkgs.fedoraproject.org/cgit/pyorbit.git/plain/dead.package
> > 
> > > last user has been retired, package EOL
> > 
> > Error: nothing provides pyorbit(x86-64) >= 2.0.1 needed by 
> > gnome-python2-bonobo-2.28.1-16.fc23.x86_64
> > 
> > What's the full story here? Where has this been discussed/announced?
> 
> I'm no longer interested in a response to this inquiry as I've dropped
> ownership of SoundConverter (which depends on gnome-python2-bonobo and some
> other gnome-python2-* packages).
> 

As I have thought for some time,  I think we should have a team to keep
packages and make migrations like gtk2 to gkt3, libgnome2, pyorbit,
gnome-python2, pyhton2 to python3 , qt3 etc etc

A team that take care of legacy software, preferably that update it,  I
got some in my own gdesklets , rawstudio, gmameui ,  flumontion ,
gtetrinet ... 

In the other day, thread "Investigation of the F23 mass rebuild" "that
nearly 4% of our binary packages haven't rebuilt in F23, is quite
worrisome" , but my question is, should we need rebuild all that is
legacy software ? We have do something or helping project migrate
software or make a group of legacy software, that could be not part of
base of Fedora and mass rebuilds , the mummified software .

Looking for dependencies of pyorbit :
repoquery --repoid=rawhide --whatrequires pyorbit\*
gnome-python2-bonobo
repoquery --repoid=rawhide --whatrequires gnome-python2\*| wc -l 
76

Looks to me, gnome-python2 is deprecated and all software that depends
on should be migrated . 

Other example /usr/share/gnome/help , things for gnome-doc-utils,  this
is documentation for Gnome2 ?  this isn't used anymore ? isn't ? .
 
Anyway, we should look for this classes of software and decide what
todo , instead leaving them without a plan .


Best regards,
-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Boost updated to 1.58.0 in rawhide and f23

[Adam Williamson]

On Mon, 2015-07-27 at 17:35 +0100, Jonathan Wakely wrote:
> On 23/07/15 14:33 +0200, David Tardon wrote:
> > Hi,
> > 
> > On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote:
> > > Hi,
> > > 
> > > On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote:
> > > > Any problems rebuilding either open a bug or feel free to email 
> > > > me or
> > > > ping me on IRC (my freenode nick is 'redi') and I'll be happy 
> > > > to help.
> > > 
> > > This is a work-in-progress list of FTBFS packages:
> > > 
> > > * Build failures:
> > > 
> > > - Rawhide only
> > > 
> > > pion-net
> 
> The attached patch is needed to fix pion-net's %check step, due to a
> breaking change in Boost.Variant in 1.58.0, documented at
> http://www.boost.org/users/history/version_1_58_0.html and
> http://www.boost.org/doc/libs/1_58_0/doc/html/boost/get_idp295310448.
> html
> 
> Also I noticed that the URL in the pion-net.spec file no longer 
> works,
> I guess the project was hosted at Google Code which is gone now. The
> new home seems to be https://github.com/splunk/pion although that
> doesn't have any releases before 5.0.1 (Fedora uses 4.0.9).

Again, it seems absurd to keep reanimating the zombified corpse of an
ancient release, so instead I bumped this to 5.0.7. It should really be
renamed pion, but I'm damned if I'm doing a rename review request.

I have builds going through now.

For the record, both this and roboptim don't seem to have any other
packages in the repos that require them, so nothing else should need
rebuilding. I did check, and I'm pretty sure neither of this was stuck
on an old version for some genuine reason, they both just seem to have
become neglected by their maintainers.
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Wednesday's FESCo Meeting (2015-07-29)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 18:00UTC (1:00pm EST) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic ticket #1427 List of release blocking deliverables
.fesco 1427

#topic ticket #1455 F23 System Wide Change: Standardized Passphrase Policy
.fesco 1455

#topic ticket #1463 upgrades for F23 and beyond
.fesco 1463

#topic ticket #1466 non-responsive maintainer exception process for skottler
.fesco 1466

= New business =

none

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.


pgpD3UmJ53kq4.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

[Dan Callaghan]

Excerpts from Peter Robinson's message of 2015-07-28 18:01 +10:00:
> This is completely NOT appropriate, it breaks on secondary arches
> where they then end up with no documentation due to the lack of any
> x86_64. Please DO NOT do this and please revert the change on any
> packages you might have made this change.

I haven't used that hack on any of my packages but I learnt about it 
from the ipxe package which uses it to produce noarch subpackages 
containing boot images. I guess ipxe is broken on secondary arches as 
well, but it's acceptable for that package because the only alternative 
would be to make it x86-only?

-- 
Dan Callaghan 
Senior Software Engineer, Products & Technologies Operations
Red Hat, Inc.


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Boost updated to 1.58.0 in rawhide and f23

[Adam Williamson]

On Tue, 2015-07-28 at 14:49 +0100, Jonathan Wakely wrote:
> On 28/07/15 14:48 +0100, Jonathan Wakely wrote:
> > On 27/07/15 19:35 -0700, Adam Williamson wrote:
> > > On Mon, 2015-07-27 at 13:31 +0100, Jonathan Wakely wrote:
> > > > On 23/07/15 14:33 +0200, David Tardon wrote:
> > > > > Hi,
> > > > > 
> > > > > On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely 
> > > > > > wrote:
> > > > > > > Any problems rebuilding either open a bug or feel free to 
> > > > > > > email
> > > > > > > me or
> > > > > > > ping me on IRC (my freenode nick is 'redi') and I'll be 
> > > > > > > happy
> > > > > > > to help.
> > > > > > 
> > > > > > This is a work-in-progress list of FTBFS packages:
> > > > > > 
> > > > > > * Build failures:
> > > > > > 
> > > > > > - F23 + Rawhide
> > > > > > 
> > > > > > ledger
> > > > 
> > > > This patch is needed to make Ledger compile with Boost 1.58.0
> > > 
> > > I submitted a build using the patch you submitted as an upstream 
> > > PR -
> > > https://github.com/ledger/ledger/pull/422 - but it still failed:
> > > 
> > > https://kojipkgs.fedoraproject.org//work/tasks/9527/10499527/buil
> > > d.log
> > 
> > Yes, as well as my patch for #422 you still need the second half of
> > the patch for the upstream #417 (which was not reverted), which 
> > I've
> > attached to this mail.
> 
> Oh, and then it *still* fails because of unpackaged files, see
> https://kojipkgs.fedoraproject.org//work/tasks/1167/10501167/build.lo
> g
> which I did yesterday using the constness patch from my previous mail
> and my upstream fix for #422.

For the record - with many thanks to nirik - this appears to be due to
some shenanigans with RPM's handling of %doc:

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

in Ye Olde Olde Days, %doc ANY_RELATIVE_PATH would wipe %_pkgdocdir
before installing the listed files to it - so if you wanted to keep
stuff installed there during %install you couldn't use %doc in that
way, you had to do it yourself.

In Ye Somewhat Less Olde Days - between 2011 and four days ago - %doc
didn't do that any more, and would happily include any files that were
put in %_pkgdocdir during %install, without them needing to be listed
in %files.

For Rawhide, since four days ago (downstream - the change, I think,
arrived in rpm-4.12.90-1.fc24; it landed on upstream master in April),
we have a sort of happy medium apparently, where %doc does not clean
%_pkgdocdir but the 'unpackaged files' check does apply to it - so if
%install puts files there, you either have to delete them or list them
in %files. And that's what broke the build here; the package's %install
installs various things to %_pkgdocdir , but the %files section doesn't
list them. I'll fix that.
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Boost updated to 1.58.0 in rawhide and f23

[Adam Williamson]

On Fri, 2015-07-24 at 19:26 +0100, Jonathan Wakely wrote:
> >> condor
> 
> Another BuildRequires failure with libpoppler.so

In fact you managed to get an attempt through which failed in
compilation:

https://kojipkgs.fedoraproject.org//work/tasks/8134/10448134/build.log

I've been figuring that one out and marvelling at the insanity that is
this 'globus' project, which has a website with more links than
wikipedia but doesn't manage to link to their SCM anywhere I could
spot, which I just found via google (
https://github.com/globus/globus-toolkit - I mean, for pete's sake, if
you're on github just freaking well say so). They also appear to have
shipped an update to globus-gsi-credential which changes its interfaces
(which is what's causing this problem) without documenting its
*existence* at all - show me where you see globus_gsi_credential-7.9 
onhttp://toolkit.globus.org/toolkit/advisories.html ? Anyone? Nope.

Oh well, I'll deal with it.
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates push status - 20150725

[Kevin Fenzi]

On Tue, 28 Jul 2015 13:05:30 +0300
Alexander Ploumistos  wrote:

> On Tue, Jul 28, 2015 at 12:46 PM, Kevin Fenzi  wrote:
> > No. We continue to work on it.
> 
> Thanks for the information, I thought I had done something wrong in
> the submission process.

Nope. ;) Sorry for the confusion... 

We _finally_ have the updates push that started last thursday going out
now. 

We are going to enable bodhi for fedora 23 after that finishes, do a
f23-updates-testing push (should be very quick since it should only
have a few packages in it), and then fire off a new 21/22 push. 

Hopefully tomorrow we can be back to normal. 

kevin


pgpziGGGnHv9W.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Boost updated to 1.58.0 in rawhide and f23

[Adam Williamson]

On Fri, 2015-07-24 at 19:26 +0100, Jonathan Wakely wrote:
> >> fityk
> 
> Not Boost related:
> 
> app.cpp:12:2: error: #error "Not everything is working with wxGTK3.  
> Use default wxGTK instead, " "based on GTK+2. If you want to test it, 
> just remove this #error."

So this one does exactly what it says on the tin, basically. nonamedotc
changed fityk to build against wxGTK 3 when bumping it to 1.2.9. In
1.3.0 this warning/error was added upstream:

https://github.com/wojdyr/fityk/commit/365cc0f8748d36788f46a81461c717d8
27363e89

to me that strongly suggests we should revert and build fityk against
wxGTK 2, but I didn't want to just go ahead and do that, I thought it'd
be best to see what nonamedotc wants to do. Mukundan, can you please
decide whether you want to:

i) patch out the #error and keep building against wxGTK 3 against
upstream's advice
ii) revert to building against wxGTK 2

and then make the necessary changes and submit builds for the f23-boost
and f24-boost targets (as explained in the first post in this thread),
please? 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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct