Orphaning pasystray, clipit, python-i3ipc, rnv

[Michael Šimáček]

Hi,

Due to lack of time and motivation I've just orphaned the following packages 
which are now free to take:
pasystray
clipit
python-i3ipc
rnv

Regards,
Michael Simacek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

xerces-j2 license correction

[Michael Šimáček]

xerces-j2 license tag has been corrected from:
ASL 2.0
to:
ASL 2.0 and W3C

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2E5OSBDFOUTANQQUV2LC5JYOKM5ZEUUI/

guava and guava20 license correction

[Michael Šimáček]

guava and guava20 packages' license tags have been corrected from:
ASL 2.0
to:
ASL 2.0 and CC0

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z5YP6DJJDUSRKAVVUWK3HDDKGH2HWRY7/

plexus-containers license correction

[Michael Šimáček]

plexus-containers package license tag has been corrected from:
ASL 2.0 and MIT
to:
ASL 2.0 and MIT and xpp

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F77RD2C5RB3MUFQVPEAFCCRQ65M22S4G/

scala license correction

[Michael Šimáček]

scala package license tag has been corrected from:
BSD
to:
BSD and CC0 and Public Domain

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5GZUFNEBJAJZOEULCK5KLUUUGN7DWDTA/

sisu license correction

[Michael Šimáček]

sisu license tag has been corrected from:
EPL-1.0
to:
EPL-1.0 and BSD
because of bundled objectweb-asm

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DKI36DYQNM23LXJXXGVG3L7UO5XSV7XA/

jdom2 license correction

[Michael Šimáček]

jdom2 license tag has been corrected from:
ASL 1.1 or BSD
to:
Saxpath

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EHWOASLGZIXL7T25XVM3DF7VRIKD6ENM/

maven license correction

[Michael Šimáček]

maven license tag has been changed from:
ASL 2.0
to:
ASL 2.0 and MIT
because of bundled slf4j-simple

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DOBP77P3QGTEU45BK2FCSAJ5H7RBGKTV/

maven2 license correction

[Michael Šimáček]

maven2 license tag has been changed from:
ASL 2.0 and MIT and BSD
to:
ASL 2.0
because there are no MIT or BSD licensed files

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XY2ZPHZVX5BLHVOWSQORHCCQ7RZKOIYE/

jaxen license correction

[Michael Šimáček]

jaxen license was corrected from:
BSD
to:
BSD and W3C

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JY6KO7NO6RMIL7NHUTILBCECLSNEJSUF/

orphaned sonar

[Michael Šimáček]

Hi,

I've orphaned sonar and related packages:
sonar
sonar-plugins-parent
sonar-runner
sonar-update-center

They used to be a dependency of gradle, but nothing depends on them now. 
They're severely outdated.


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

Re: Gating packages in Rawhide

[Michael Šimáček]

On 2018-03-12 12:19, Nicolas Mailhot wrote:

Le 2018-03-12 12:10, Pierre-Yves Chibon a écrit :

On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:

Hi,

On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
>
> * request a side tag
> * build a, wait for it to be added to the repo, build b, etc.
> You would not need to file overrides, just build them in the right
> order with wait-repo between them.

well, it's not better, it's worse. I could not just run one command and
let the computers do the task on their own, I just check from time to
time whether anything broken, but I'd be supposed to babysit whole
build process with the packages from the "chain-build"? That's truly
worse, needs more of my time, while the koji can do it on its own.
Computers are here to help people, right? :)


Tooling can be built no? Why do you assume we can't make chain-build 
work with

side-tags?


Also current chain-build is too primitive to handle complex chains

https://github.com/rpm-software-management/mock/issues/170



Koji chain-builds and mockchain are unrelated (both are primitive, I 
don't disagree with that).


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

Re: Debugging mock error “Failed to synchronize cache for repo 'updates'”

[Michael Šimáček]

On 2018-03-09 17:47, Florian Weimer wrote:
I'm trying this, on a relatively up-to-date Fedora 27 machine 
(mock-1.4.9-1.fc27.noarch):


mock -r fedora-28-x86_64 --init

and get:

Start: dnf install
Error: Failed to synchronize cache for repo 'updates'
WARNING: Machine 00b000ffcd4543ddbe52926cee6d50d5 still running. Killing...
ERROR: Command failed:
  # /usr/bin/dnf --installroot /var/lib/mock/fedora-28-x86_64/root/ 
--releasever 28 --disableplugin=local --setopt=deltarpm=False install 
@buildsys-build

Error: Failed to synchronize cache for repo 'updates'

And that's it.   Adding -vv doesn't provide more information, e.g. which 
URL download is failing.


I tried --dnf-cmd, but the -vv for that is still processed by mock only, 
it seems.


Any suggestions?


The init step doesn't take dnf arguments, and --dnf-cmd executes the 
init step first (which fails). You can increase the dnf verbosity level 
in the configuration, e.g. change the debuglevel option in main section 
of "yum.conf" option of /etc/mock/fedora-28-x86_64.cfg


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

Re: Usefulness of `copr mock-config ` feature?

[Michael Šimáček]

On 2018-02-13 21:51, Michal Novotny wrote:

Hello,

On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msima...@redhat.com 
<mailto:msima...@redhat.com>> wrote:


On 2018-02-13 11:47, Pavel Raiskup wrote:

Sorry, I wanted to CC fedora devel before, forwarding.

Pavel

On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:

Because we are unable to find a consensus on implementation
details, it's
likely we'll drop this feature from copr API and it will be
probably a bit
more complicated to setup mock chroot for local tests in
future (you'll
need to have builder machine with copr-rpmbuild installed,
which brings a
lot more runtime dependencies at least).

  From user perspective, do you mind if we dropped `copr
mock-config` command?


I didn't know this command existed, but there were multiple times in
the past where I wished something like this had been available (It
didn't exist back then). It was usually situation like this: "Hi,
I'm trying to build $package in $copr and it fails because of
$build_tool that you maintain, can you help me?". And since I had no
idea how his copr was set up, it took me a lot of time before I was
able to reproduce the problem. So, I would find the feature useful,
especially in instances outside Fedora, which usually have more
complex configurations.
If it had to be dropped, I'd appreciate if copr could display the
configuration of given project for non-owners. That way it would be
easier to construct my own config, without trying to guess stuff
based on the logs.


First, thanks for your input. This is very useful information for us. 
Next, I would like to ask if it was ok to put all the functionality 
about build-testing and building itself into just a single package: 
copr-rpmbuild. I think having things on just one place can help us focus 
on doing them really well and as the copr-rpmbuild tool is already 
responsible for building, I think it would be a perfect place to add 
additional build-debugging functionality like printing-out/dumping mock 
configs, enablement to run just a part of the build process, possibility 
to enter the build environment interactively etc. Would this be alright?




Yes, that would work for me. I don't mind additional deps.

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

Re: Usefulness of `copr mock-config ` feature?

[Michael Šimáček]

On 2018-02-13 11:47, Pavel Raiskup wrote:

Sorry, I wanted to CC fedora devel before, forwarding.

Pavel

On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:

Because we are unable to find a consensus on implementation details, it's
likely we'll drop this feature from copr API and it will be probably a bit
more complicated to setup mock chroot for local tests in future (you'll
need to have builder machine with copr-rpmbuild installed, which brings a
lot more runtime dependencies at least).

 From user perspective, do you mind if we dropped `copr mock-config` command?



I didn't know this command existed, but there were multiple times in the 
past where I wished something like this had been available (It didn't 
exist back then). It was usually situation like this: "Hi, I'm trying to 
build $package in $copr and it fails because of $build_tool that you 
maintain, can you help me?". And since I had no idea how his copr was 
set up, it took me a lot of time before I was able to reproduce the 
problem. So, I would find the feature useful, especially in instances 
outside Fedora, which usually have more complex configurations.
If it had to be dropped, I'd appreciate if copr could display the 
configuration of given project for non-owners. That way it would be 
easier to construct my own config, without trying to guess stuff based 
on the logs.


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

Re: Packaging wiki: shortcoming in Github Source0 (?)

[Michael Šimáček]

On 2018-02-02 17:52, Jason L Tibbitts III wrote:

"PM" == Panu Matilainen  writes:


PM> Yes spectool was recommended by somebody else already, but
PM> ultimately only rpm itself can truly parse a spec, spectool is just
PM> a rough approximation (but usually does work in the more common
PM> cases, yes)

Actually the current spectool uses rpm to parse the spec (as it calls
rpmbuild -bp with a number of additional options).  It would probably be
simpler if it called rpmspec -P as my python rewrite of it from years
ago did, but right now it really should just work for everything that
rpm can parse.  And at least it seems to be able to handle expansions of
significant complexity without problems.



It currently doesn't work for everything that rpm can parse. For an 
example, see nasm [0].


msimacek ~/rpms/nasm (master) $ /usr/bin/spectool --debug -g nasm.spec
temp dir: /tmp/spectool_TU_klSJmj3
temp spec filename: /tmp/spectool_TU_klSJmj3/spec_hSY36atjuD
stderr filename: /tmp/spectool_TU_klSJmj3/stderr_2MEZDwuZkx
msimacek ~/rpms/nasm (master) $ cat 
/tmp/spectool_TU_klSJmj3/stderr_2MEZDwuZkx

error: line 68: Unclosed %if

So, I'd definitely appreciate if your rewrite went upstream.

[0] https://src.fedoraproject.org/rpms/nasm/blob/master/f/nasm.spec


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

Re: -z defs linker flag activated in Fedora rawhide

[Michael Šimáček]

On 2018-01-29 16:51, Richard Shaw wrote:
On Mon, Jan 29, 2018 at 8:37 AM, Florian Weimer > wrote:


I have reverted the -z defs change in rawhide.  A substantial number
of underlinked binaries are still shipped in rawhide after this
change, either due to explicit overrides or incomplete build flags
injection. This means that it is necessary to review built RPM
packages for incorrectly linked binaries even after the change. 
Considering that -z defs also causes a lot of spurious build

failures, it's probably not the way to go.

(The work to enable -z defs is not lost—even after the revert,
packages which have been fixed so far will remain fixed.)


Would it make sense (or be a lot of work) to include this in the Koschei 
integration?


Wouldn't that make it so packages with issues could be reported without 
creating a lot of FTBFS issues?




Making koschei builds use -z defs, while regular Fedora builds wouldn't 
use it, is not possible by design (koschei only requests the builds from 
koji, it cannot make changes to the spec and cannot alter the buildroot).
But if the build only produced a warning (as suggested in other part of 
this thread), then it would be possible for koschei to parse the build 
log and indicate this somehow.

But I think taskotron is a better place for such checks.

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

Re: koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide

[Michael Šimáček]

On 2018-01-23 20:06, R P Herrold wrote:

On Tue, 23 Jan 2018, Daniel P. Berrange wrote:


What needs to be done for this ?  I see my package "libvirt" present
in its UI

   https://apps.fedoraproject.org/koschei/package/libvirt

but it says

   "Package is currently ineligible for scheduling due to following reasons:


looking at the 'EPEL 7' tab, I see:

Base buildroot for EPEL 7 is not installable.

Dependency problems:
nothing provides requested redhat-release-everything

Hunh?



That's a bug in koschei, which will be fixed in the next release.

Michael Simacek


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


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

Re: Building of OkHttp 3.9.0 fails

[Michael Šimáček]

On 2017-11-01 15:45, Martin Gansser wrote:

Hi,

when trying to compile okhttp with the okhttp.spec file from [1] i get this 
error messages:

...
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:guide:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:simple-client:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:slack:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:sample-parent:pom:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
...
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) on 
project okhttp: Execution default-compile of goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile failed: Plugin 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1 or one of its dependencies 
could not be resolved: The following artifacts could not be resolved: 
org.codehaus.plexus:plexus-compiler-javac-errorprone:jar:2.8.1, 
com.google.errorprone:error_prone_core:jar:2.0.16: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.codehaus.plexus:plexus-compiler-javac-errorprone:jar:2.8.1 has not been 
downloaded from it before. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :okhttp

Is there any help to get okhttp compiling again



It is missing additional dependencies for the compiler plugin. You have 
two options: a) package them b) remove them. The dependencies are there 
for static analysis, which is useful for upstream, but redundant for 
Fedora packaging, so I'd just remove them. For that you need to remove 
the dependency declaration, and the part of configuration that 
references them. You can do that with:
%pom_xpath_remove 
'pom:plugin[pom:artifactId="maven-compiler-plugin"]//pom:compilerId'
%pom_xpath_remove 
'pom:plugin[pom:artifactId="maven-compiler-plugin"]/pom:dependencies'



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

Re: mock or dnf or fedora-review tries to install a binary of a package it is test-building

[Michael Šimáček]

On 2017-08-22 16:22, Richard W.M. Jones wrote:

I don't know what component to file this bug under ...

When running ‘fedora-review -b 1477363’, it fails to test build the
package in mock.  The errors in root.log are peculiar:


DEBUG util.py:450:  Package ocaml-4.04.2-4.fc27.x86_64 is already installed, 
skipping.
DEBUG util.py:450:  Error:
DEBUG util.py:450:   Problem 1: cannot install both 
ocaml-runtime-4.05.0-2.fc27.x86_64 and ocaml-runtime-4.04.2-4.fc27.x86_64
DEBUG util.py:450:- package ocaml-4.05.0-2.fc27.x86_64 requires 
ocaml-runtime = 4.05.0-2.fc27, but none of the providers can be installed


Installing the higher version would be correct here, but ...


DEBUG util.py:450:- package ocaml-cmdliner-1.0.2-1.fc27.x86_64 requires 
ocaml(Array) = 83626447aa49c1fc006c752026de61fb, but none of the providers can 
be installed


... this dependency is wrong.  But on the other hand mock is supposed
to be *building* ocaml-cmdliner at this point, so there shouldn't even
be a binary package of this.


DEBUG util.py:450:- cannot install the best candidate for the job
DEBUG util.py:450:- problem with installed package 
ocaml-cmdliner-1.0.2-1.fc27.x86_64
DEBUG util.py:450:   Problem 2: cannot install both 
ocaml-runtime-4.05.0-2.fc27.x86_64 and ocaml-runtime-4.04.2-4.fc27.x86_64
DEBUG util.py:450:- package ocaml-cmdliner-1.0.2-1.fc27.x86_64 requires 
ocaml(Array) = 83626447aa49c1fc006c752026de61fb, but none of the providers can 
be installed
DEBUG util.py:450:- package ocaml-ocamlbuild-0.11.0-9.fc27.x86_64 requires 
ocaml(Pervasives) = 07ea9e20ae94d62c35cfecbe7d66d3ea, but none of the providers 
can be installed


ocaml(Pervasives) = 07ea... is provided by
ocaml-runtime-4.05.0-2.fc27.x86_64


DEBUG util.py:450:- package ocaml-cmdliner-devel-1.0.2-1.fc27.x86_64 
requires ocaml-cmdliner = 1.0.2-1.fc27, but none of the providers can be 
installed
DEBUG util.py:450:- cannot install the best candidate for the job
DEBUG util.py:450:- problem with installed package 
ocaml-cmdliner-devel-1.0.2-1.fc27.x86_64


It seems as if a binary ocaml-cmdliner with incorrect dependencies is
appearing from somewhere ...



It might be in the dnf cache from a previous run. I recommend running 
mock --scrub all (which will delete the buildroot and caches) and trying 
again.


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

Re: F27 Self Contained Change: Decouple system java setting from java command setting

[Michael Šimáček]

On 2017-06-16 18:44, Dennis Gilmore wrote:

I would like to see some details on how this is going to be
implemented.

It all seem very vague and handwavy


I've just updated the proposal [1] to be more concrete and detailed. Let 
me know if there are still unclear points.


[1] 
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting


Michael



El jue, 08-06-2017 a las 15:55 +0200, Jan Kurik escribió:

= Proposed Self Contained Change: Decouple system java setting from
java command setting =
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_f
rom_java_command_setting

Change owner(s):
* Michael Simacek 
* Mikolaj Izdebski 

Alternatives can be used to specify which Java installation should be
the default for the system. Currently, changing the default java
command causes not only a change to the /usr/bin/java symlink, but
also affects the which runtime is used for system installed Java
applications. We propose introduction of separate setting for
system-wide java applications.


== Detailed Description ==
Fedora allows parallel installation of multiple Java runtime
environments and it uses alternatives mechanism to allow the user to
switch between them. JDK packages provide a set of alternatives
symlinks for it's executables. The java symlink is used to determine
the java command (/usr/bin/java), but also determines which runtime
environment is used to run system-wide Java applications installed
from RPMs, such as maven or eclipse. While in theory different Java
runtime environments are drop-in replacements for each other, in
practice some of the applications may stop working properly. Users
usually install alternative JDKs in order to run their own
applications and don't expect that changing the java command will
have
effect on the system applications. By introducing a separate setting
for system-wide java, we would avoid this problem. We propose
specifying default Java runtime for RPM-managed applications in
/etc/java/java.conf (this is already possible, but not currently
used). Administrators would still be able to override the system
default if they need to.


== Scope ==
* Proposal owners:
Adjust javapackages-tools to provide default Java setting in
/etc/java/java.conf

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/6831

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

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

Re: F27 Self Contained Change: Decouple system java setting from java command setting

[Michael Šimáček]

On 2017-06-20 20:07, nicolas.mail...@laposte.net wrote:

Hi,

Frankly, the proposed change seems a great way to accumulate technical debt at 
a rapid pace, by helping apps to specify various legacy or proprietary Java 
variants, and postponing taking into account openjdk changes indefinitely.


Why do you think so? The proposal doesn't say anything like that. It 
doesn't let apps specify their Java. The setting for Java applications 
will still be global.


Moreover, Fedora doesn't ship legacy or proprietary Java variants.



That's more or less what the proprietary unixes did till the whole house of 
cards collapsed under the weight of long overdue migration needs.

IIRC the whole alternative system already lets an app specify a specific java 
version and producer (at least it did in JPackage time). What it does not let 
people do is to pretend an app is java-version and java-producer agnostic when 
it isn't.

%jpackage_script generated launcher scripts don't let an app specify 
java version/provider and that will stay the same.


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

Re: [HEADS UP] %add_maven_depmap macro deprecated and moved to javapackages-local

[Michael Šimáček]

On 2017-06-08 19:28, Jason L Tibbitts III wrote:

"MŠ" == Michael Šimáček <msima...@redhat.com> writes:


MŠ> With upcoming version of javapackages-tools there will be changes to
MŠ> %add_maven_depmap macro:

I believe this would need to be reflected in the packaging guidelines.
At least %add_maven_depmap is mentioned twice, once as an alternative to
%mvn_install and once mentioning where to get the documentation for it.

I can trivially remove both of those, but it would be nice if someone
filed a ticket at https://pagure.io/packaging-committee



I didn't realize it's still referenced there. Thank you for pointing 
that out.


I filled: https://pagure.io/packaging-committee/issue/689

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

[HEADS UP] %add_maven_depmap macro deprecated and moved to javapackages-local

[Michael Šimáček]

With upcoming version of javapackages-tools there will be changes to 
%add_maven_depmap macro:


- It is considered deprecated. It was deprecated upstream long ago, but 
I think we've never sent an announcement. The replacement is 
%mvn_artifact + %mvn_install. For porting your specfiles, please refer 
to the guide at [1]. If you have any questions about porting, we'll be 
happy to answer them on #fedora-java (we = msimacek and mizdebsk) or via 
email.


- It will still be available for few months, but was moved to 
javapackages-local subpackage. If you don't want to port just yet, 
you'll need to make sure that you have BuildRequires: javapackages-local 
in your spec. If you already have BR: maven-local or ivy-local or 
gradle-local, you don't need to do anything as those pull in 
javapackages-local as a dependency. The reason for the move was 
reduction of dependencies (mainly python) of the main package, which 
gets installed as a runtime dependency of all java packages.


- This will be for rawhide only and won't go to <=f26.

[1] https://fedora-java.github.io/howto/latest/#_add_maven_depmap_macro


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

Re: Intent to orphan netty package

[Michael Šimáček]

On 2017-03-10 14:40, Severin Gehwolf wrote:

Hi,

I'm going to orphan the netty package in Fedora next week since I no
longer using it. Please let me know if you are interested in
maintaining it.

Here is a list of packages that depend on netty (it's probably
incomplete):

artemis-commons
artemis-core-client
artemis-maven-plugin
artemis-rest
artemis-server
cassandra-java-driver
cassandra-java-libs
cxf-rt
hadoop-hdfs
hadoop-tests
hornetq-commons
hornetq-core-client
hornetq-rest
hornetq-server
infinispan
jython
littleproxy
mongo-java-driver
netty-xnio-transport
qpid-jms-client
wildfly-lib
xchange

Hopefully some maintainer of those packages will step up and take
netty. I'm going to orphan it next week. At that point it'll be up for
grabs :)



I can (co)maintain it as well.

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

jline license tag change

[Michael Šimáček]

jline license has been changed from BSD and ASL 2.0 to BSD
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Maven downgrade to 3.3.9 in rawhide

[Michael Šimáček]

Hi fellow packagers,

In the beginning of this year, maven upstream announced [1] they dropped 
3.4.0 release and reverted the changes made. We already had 3.4.0 
snapshot in Fedora Rawhide, so this means we have to revert maven 
package back to version 3.3.9.


[1] 
https://mail-archives.apache.org/mod_mbox/maven-announce/201701.mbox/%3CCA%2BnPnMzNjwTi3A7LoB3whNXyrz%3DS7gbROHOd-oyciu6f0EbPLA%40mail.gmail.com%3E


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

bsh-2.0-1.b6.fc26 license change

[Michael Šimáček]

bsh-2.0-1.b6.fc26 license was changed from "(SPL or LGPLv2+) and Public 
Domain" to "ASL 2.0 and BSD and Public Domain"

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

Re: DNF skipping packages with conflicts in koji

[Michael Šimáček]

On 2016-09-22 11:12, Dan Horák wrote:

On Thu, 22 Sep 2016 11:01:56 +0200
Michael Šimáček <msima...@redhat.com> wrote:


Hi,

I recently got a few failed build alerts with suspicious errors about
missing commands/libs in the buildroot, despite the builddep step had
succeeded. The root.log always contains "Skipping packages with
conflicts" listing packages that weren't installed. So DNF now
silently skips installation of some packages in koji. That's a
problem - there are packages (usually using autoconf) that
enable/disable features based on what they see in the environment, so
silently skipping package installations may result in sucessful build
of package that is missing functionality.

IMO this should be fixed, but I don't know whether it's a
regression/feature of DNF or just misconfiguration in koji/mock.
Where should I report it?


AFAIK the "conflicts" are result of weak deps being disabled for
builds in koji



Ah, ok. If that's the case, I'll fill a bugreport on DNF to report them 
correctly (not as conflicts).


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

DNF skipping packages with conflicts in koji

[Michael Šimáček]

Hi,

I recently got a few failed build alerts with suspicious errors about 
missing commands/libs in the buildroot, despite the builddep step had 
succeeded. The root.log always contains "Skipping packages with 
conflicts" listing packages that weren't installed. So DNF now silently 
skips installation of some packages in koji. That's a problem - there 
are packages (usually using autoconf) that enable/disable features based 
on what they see in the environment, so silently skipping package 
installations may result in sucessful build of package that is missing 
functionality.


IMO this should be fixed, but I don't know whether it's a 
regression/feature of DNF or just misconfiguration in koji/mock. Where 
should I report it?


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

Re: Packages up for grabs

[Michael Šimáček]

On 2016-07-04 00:11, Hans de Goede wrote:

Hi All,

Between my $dayjob, other foss projects and last but not
least spending time with my wife and children I'm way too busy
lately.

So I'm trying to find a new home for the packages I maintain
pretty much anything on the point of contact list here is fair game:

https://admin.fedoraproject.org/pkgdb/packager/jwrdegoede/

If you want to take some packages over please let me know which
ones and what your fas login is then I'll "give" them to you in
pkgdb.


As a member of Java-SIG, I'd like to take dom4j.
FAS: msimacek

Thanks,
Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

httpcomponents-core license change

[Michael Šimáček]

httpcomponents-core changes license from (ASL 2.0 and CC-BY) to (ASL 2.0)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Autogenerating Koschei groups's contents

[Michael Šimáček]

On 2016-05-23 13:59, Jan Pokorný wrote:

On 23/05/16 10:22 +0200, Michael Šimáček wrote:

few people who have groups defined in Koschei have asked whether they could
automate maintentance of the package list with something like repoquery
rule


Are you talking about "Global groups" or "Your groups" kind of groups?
Or are these the same?


They are the same internally (they only have different namespace).

Michael
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Autogenerating Koschei groups's contents

[Michael Šimáček]

Hi,

few people who have groups defined in Koschei have asked whether they 
could automate maintentance of the package list with something like 
repoquery rule. We've implemented this functionality in koschei 1.7. But 
there is no web UI for it yet, so if you'd like to have a rule for your 
group contents autogeneration, reply to this email off-list with a dnf 
repoquery snippet that would output the package list you'd like to have 
and I'll add it to production.


Regards,
Michael Simacek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Michael Šimáček]

On 2016-01-15 09:42, Dan Horák wrote:

On Fri, 15 Jan 2016 09:24:36 +0100
Tomáš Smetana  wrote:


On Wed, 13 Jan 2016 14:38:08 +0100
Florian Festi  wrote:


On 01/13/2016 02:36 PM, Reindl Harald wrote:



Am 13.01.2016 um 14:30 schrieb Richard Hughes:

On 13 January 2016 at 13:13, Reindl Harald
 wrote:

so there is no justification to declare one need to install
from scratch just because rpm which works for many years fine
changes it's storage format


I don't think anyone said there was a need to reinstall from
scratch


so how do you translate "clearly not forward compatible"?


"forward compatible" means the old version of a program being able
to read/process newer version data.

The current rpm versions will not be able to read the new database
format.


I tend to use systemd-nspawn containers for building rpms. So for
example, I have a Fedora 24 system and use its dnf to create e.g.
Centos 7 container root and then build Centos rpms from within that
container.  If I understand the change correctly, this is going to
break since the Centos 7 rpm-build will not be able to read the
database created by the Fedora 24 dnf.

I know more people using dnf/rpm to "manage" the containers and this
is somewhat a regression for us.  I'm not sure there is a way to
prevent this breakage... So just FYI. :)


won't regular mock chroot have the same problem?



Mock uses --nodeps when running rpmbuild, because such incompatibilities 
already exist - for example when building EL 6 packages on F23 (i.e. RPM 
from EL6 cannot read the rpmdb in buildroot)


Michael
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pmd license correction

[Michael Šimáček]

pmd license has been changed from "BSD" to "BSD and ASL 2.0 and LGPLv3+"

Michael
--
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: Build root prepared by DNF is way larger

[Michael Šimáček]

On 2015-08-18 16:32, Vít Ondruch wrote:

Dne 18.8.2015 v 16:26 Vít Ondruch napsal(a):

Hi all,

Today, I noticed that mock build root prepared by DNF is significantly
larger then prepared by YUM (see attached logs). Owners of packages
installed into minimal buildroot probably wants to review their
dependency chain.

I also reported the issue against DNF [1] in case DNF guys wants to
improve this situation.


Vít



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



Sorry, I attached wrong yum.log ... but you can find the correct one in
the bug referenced above.


Vít



The cause might be soft dependencies. dnf installs Recommends, while yum 
ignores them. I think some packages in base buildroot are already using 
them (gdb).


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

Intent to retire hamcrest12

[Michael Šimáček]

Hi,

hamcrest12 is a compat package that doesn't seem to be used by anything 
anymore. It currently fails to build in rawhide due to update of qdox. 
This action will have no effect on the non-compat hamcrest package.


Michael Simacek
--
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: need rpm help (nothing provides /bin/python)

[Michael Šimáček]

On 2015-06-23 13:21, Neal Becker wrote:

I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.

Now I tried a local build, and tried to locally install, but I got:
  sudo dnf install x86_64/*3.4.1*
[sudo] password for nbecker:
Last metadata expiration check performed 0:22:21 ago on Tue Jun 23 06:57:18
2015.
Error: nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64.
nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64

Anyone see how to fix this?

Also, can someone please confirm that I correctly took care of
obsoleting the mercurial-emacs{-el} as per:

https://fedoraproject.org/wiki/Packaging:Emacs



DNF cannot resolve provides that look like file path:
https://bugzilla.redhat.com/show_bug.cgi?id=1223478

Koji still uses Yum, that's why it works there.

Michael Simacek
--
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: Build-essential packages

[Michael Šimáček]

On 2015-06-12 22:32, Dennis Gilmore wrote:

On Friday, June 12, 2015 02:21:14 PM Carlos O'Donell wrote:

On 06/12/2015 12:11 PM, Dennis Gilmore wrote:

On Thursday, June 11, 2015 08:36:38 AM Florian Weimer wrote:

On 05/21/2015 10:11 PM, Jason L Tibbitts III wrote:

The BuildRequires section of the guidelines has been revised; the
exceptions list is gone.  The release engineering folks are free to
define the buildroot and rpm is free to change its dependency list.

  * https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2
  *
  https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelinesdiff
  =
  413629oldid=409506 * https://fedorahosted.org/fpc/ticket/497


Can we get a build-essential package instead that requires everything
that is needed to get a working C and C++ compiler, and run most
autoconf/automake/libtool-generated scripts (but not the autotools
themselves)?


Can you please help me to understand the problem you are trying to solve?
what is different to dnf install @buildsys-build other than a package
vs a comps group


The recent policy changes mean that developers have to take action to fix
broken spec files. Comments like those above are essentially a request,
and the request from our developers is going to be:

Now that the buildroot can contain almost nothing, what do I need to
require in order to build C or C++ applications?

Do I have to figure out every possible command that autoconf might call
and include it in my BuildRequires or is there some magic meta prodives
I can use?

To answer this question for C and C++ development I have filed this FPC:

https://fedorahosted.org/fpc/ticket/540

And while the pedantic answer is BuildRequire and Require on whatever
you need, that is in my opinion insufficient guidance for Fedora packagers.


Okay thanks, with my releng hat on I had no idea this was coming and would
have suggested to the FPC to not change anything, at the least giving releng a
heads up saying that they were going to make us the gatekeepers would have
been appreciated. There is certainly no immediate plan to change anything from
status quo. I guess this was triggered by the request recently to remove c,
c++, and make from the minimal buildroot.

in my mind metapackages while they could serve a useful purpose could quite
easily be abused and lead to buildroot bloat.

koji list-groups f23-build shows us currently pulling in
build  [f23]
   bash: None, default  [f23]
   bzip2: None, default  [f23]
   coreutils: None, default  [f23]
   cpio: None, default  [f23]
   diffutils: None, default  [f23]
   fedora-release: None, default  [f23]
   findutils: None, default  [f23]
   gawk: None, default  [f23]
   gcc: None, default  [f23]
   gcc-c++: None, default  [f23]
   grep: None, default  [f23]
   gzip: None, default  [f23]
   info: None, default  [f23]
   make: None, default  [f23]
   patch: None, default  [f23]
   redhat-rpm-config: None, default  [f23]
   rpm-build: None, default  [f23]
   sed: None, default  [f23]
   shadow-utils: None, default  [f23]
   tar: None, default  [f23]
   unzip: None, default  [f23]
   util-linux: None, default  [f23]
   which: None, default  [f23]
   xz: None, default  [f23]

of those the only things I think we would consider removing are gcc and gcc-
c++ I think make is wide enough used that it should not be removed.  I would
also proposed that there would be no random changes to what is installed in
the minimal buildroot during a releases life. so the earliest that there would
be any change is in rawhide when we branch f23 off.  so what builds today in
rawhide will not have the buildroot changed under it for the life of f23.  but
once we branch and rawhide targets f24 as part of the branching process would
be the only time we change the package set used for the minimal buildroot.  it
would require that we coordinate the changes with comps, so that you can test
locally.


In my opinion, it is a bad use of developer time to track what programs
exactly are called from ./configure, and how these programs match
sed/grep/coreutils.  It would also  give us a central place where we can
fix breakage due to missing packages in build roots because a
significant fraction of packages got a build-required package through an
indirect dependency.


can you describe the issues and breakages you are talking about, or point
me at some examples.  the buildroot does not often break.  but in the
scenario you are talking about fixing may be difficult without being able
to build the package that has the fix.


At present there is no breakage, but as proactive Fedora packagers Florian
and I have kicked off the conversation to say What will happen? What do
packagers need to do to keep their spec files building?


Okay that is not at all a bad thing. I think that we will need to be really
careful and as part of when we announce that the branch event has happened we
list any changes to the minimal buildroot.  would that be sufficient to allay
your fears?

Re: dnf replacing yum and dnf-yum

[Michael Šimáček]

On 2015-04-08 11:17, Marcin Juszkiewicz wrote:

W dniu 08.04.2015 o 11:05, drago01 pisze:

We do have dep solvers otherwise no one would notice that a dep is
broken ever. (like libsolv + hawkey).
So what bodhi should do is to ask has this package all dependencies
satisfied with base + updates + other packages in this push for every
package in the push.
If the answer is no for a package cancel the push; remove it;
restart and only push the once that has satisfied deps.
Report the failed once to the maintainers so that they can fix it.


When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks and
one of them in my setup was once built, install all resulting packages.

This way as a developer I could check are results usable. Not found
something like that in mock.



Curent mock has such option:
--postinstall
Try to install built packages in the same buildroot right after build.

Michael Simacek
--
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: Should a failed arch cancel other arch builds in koji?

[Michael Šimáček]

On 2015-04-09 01:51, Sérgio Basto wrote:

On Qua, 2015-04-08 at 12:20 -0600, Orion Poplawski wrote:

Should a failed arch cancel other arch builds in koji?  I can understand the
resource saving argument, but I'm finding it increasingly useful to know if a
build failure is arch specific or not and this makes it impossible to tell.



Sorry hijack this thread, a different question , can we force a noarch
package be build in an specific arch ?


When submitting a scratch build you can use arch-override. But not for 
non-scratch builds.




We got this problem [1] with debhelper.noach fails to build on arm
builders and I'm getting notifications time to time like this :
 debhelper's builds started to fail in f23
 http://koschei.cloud.fedoraproject.org/package/debhelper


For koschei, you can set the arch-override in the package detail (the 
link you have in the notification). You need to be logged in.


Michael Simacek
--
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: dnf replacing yum and dnf-yum

[Michael Šimáček]

On 2015-04-03 21:18, Adam Williamson wrote:

On Fri, 2015-04-03 at 12:18 -0300, Paulo César Pereira de Andrade wrote:

2015-04-03 12:04 GMT-03:00 Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com:

2015-04-03 11:24 GMT-03:00 Miroslav Suchý msu...@redhat.com:

On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:

DEBUG util.py:388:  No such command: builddep. Please use
/usr/bin/dnf --help
DEBUG util.py:388:  It could be a DNF plugin command.

I will review using a release other than rawhide.


Just install dnf-plugins-core.


   It should have been installed in an update, e.g. as a dependency
of any packagers tool.

   It is also not available in any repo, for rhel7 (I would expect
it
in epel). I run mock frequently in rhel7, but usually just as a
simple
way to create a rawhide, f22 or f21 chroot.


Nevermind, I thought dnf-plugins-core would be something that would
fix mock chroot generation with fedora-review, it is just
documentation,
not related to mock.


mock should be adapted to dnf or changed to call yum-deprecated on F22
and F23.


Mock is adapted to dnf, you just have to tell it to use it in the config 
and it is the default on rawhide.




the 'resolvedep' command was already marked as deprecated *in yum*:

 * resolvedep dep1 [dep2] [...]
(maintained  for  legacy  reasons  only - use repoquery or
yum pro‐
vides)

so mock really should've been ported off it a while back. If there
isn't a bug on mock for this already, we should file


This is only called when mock is using yum and yum still maintains the 
command. When mock uses dnf it's not necessary to call it in the first 
place, as it was there only to avoid yum skipping missing dependencies, 
which dnf builddep doesn't do. If you configure mock to use dnf, it will 
work. What doesn't work is when you have it configured to use yum and 
yum is a wrapper around dnf, because dnf-yum doesn't provide 
yum-builddep (it fails earlier due to resolvedep, but that's not the 
real problem, we can get rid of resolvedep, but we need builddep). As 
the two package managers don't provide the same command (builddep) under 
the same name (yum-builddep vs dnf builddep), mock needs to know which 
one it's dealing with, you need to tell it in the config that it's dnf.
The reason why mock exists is to provide reproducible builds. If the 
used package manager is dependent on the distro version, it goes agains 
the principle. So I think it would be better keep this explicit 
configuration instead of using /usr/bin/yum that may point anywhere. 
Setting the non-rawhide (target we build for) config default to 
yum-deprecated for f22 (distro mock is running on) looks like a 
reasonable solution to me, provided that yum-deprecated works with 
yum-builddep.


Michael Simacek
--
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: DNF and mock

[Michael Šimáček]

On 2015-03-16 06:43, Mikolaj Izdebski wrote:

On 03/15/2015 02:38 PM, Michael Schwendt wrote:

On Thu, 22 Jan 2015 15:15:48 +0100, Miroslav Suchý wrote:


I just spoke with two members of DNF team about default usage of DNF in mock. I 
would like to share outcomes of this
meeting.

First I would like to state that you can already optionally use DNF in your 
mock by setting:
   config_opts['package_manager'] = 'dnf'


I've switched back to Yum for now.


I expect that we will be building Fedora 22- always by yum due to short Fedora 
life cycle. Yum will be still present in
Fedora 24 for sure.


Is DNF within Mock a fully compatible replacement for Yum yet?
It seems builds take much longer now since something's downloading
(or redownloading?) lots of data for each build job before setting
up the buildroot. I don't have much time to look into it, bug shouldn't
Mock's buildroot cache files be fresh enough to avoid redownloading
packages, for example?


Redownloading packages is DNF default setting [1], which you can adjust
in mock config. I personally use caching proxy to avoid this problem and
share packages between multiple chroots.


Configurations shipped with current mock have keepcache=1 by default, so 
the redownloading shouldn't happen if you have yum_cache enabled. But if 
you use different configs than the default ones, you'll need to adjust 
the config manually.


Technically, yum_cache wans't ported to dnf, but due to the similarity 
of the two package managers, if the cachedir is set to /var/cache/yum 
(which it is in the shipped configs), it should work without changes.


Michael Simacek



[1] http://dnf.readthedocs.org/en/latest/conf_ref.html#keepcache-label


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