Re: Hadoop javadoc problem (FTBFS)
On 07/09/2015 11:45 PM, Christopher wrote: > Regarding https://bugzilla.redhat.com/show_bug.cgi?id=1239555 > > Hadoop seems to have a problem due to javadocs. It seems to be > affecting rawhide, and maybe earlier versions, but I haven't verified. > Aside from patching the upstream javadoc bug, is there a way to get > the build to proceed in a way that's more tolerant to javadoc > problems? My guess without looking at the package: try to remove javadoc plugin invocation from POMs: %pom_remove_plugin -r :maven-javadoc-plugin See: https://lists.fedoraproject.org/pipermail/java-devel/2015-June/005617.html -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Is %autosetup another unwanted baby of Fedora?
On 07/13/2015 02:39 PM, Marcin Juszkiewicz wrote: > When I moved to Fedora after years of doing Debian packages I noticed > that there is no such thing as patch management when it comes to Fedora > packages. Everyone is using %patch macro with files of random patchlevel > (some even use reverse patches). > > %autosetup was created to handle that but probably less than 5% of > packages use it. Why? > > Is it because no one told that it exists? Or maybe because > implementation has some issues which no one wants to fix? Or other (I > exclude laziness of package maintainers)? I also like how Debian patches their packages (stardardization: quilt, DEP-3, patch tracker web app, ...) and I was initially quite eager about %autosetup/%autopatch, but it turned out to be unusable for me. I maintain most of patches as commits in private branches of upstream git repos and generate them with "git format-patch ". %autosetup and %autopatch don't work with patches generated this way, while %patch does. Another (lesser) reason is increased difficulty of backporting spec files to work with older rpm-build, such as when creating software collections for older OS. I use %autopatch in one of my packages (eclipse-m2e-core) so that I don't forget how it works (or doesn't work :) -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Is %autosetup another unwanted baby of Fedora?
On 07/14/2015 06:19 PM, Haïkel wrote: >> I maintain most of patches as commits in private branches of upstream >> git repos and generate them with "git format-patch >> ". %autosetup and %autopatch don't work with patches >> generated this way, while %patch does. >> >> > Works for me, you need to tell %autosetup that you're using git with the > option -S git Yes, but that means adding explicit BuildRequires on git to every package. I don't want to do that. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Improving our processes for new contributors.
On 07/16/2015 07:53 PM, Zbigniew Jędrzejewski-Szmek wrote:
> One thing which I find very annoying when creating new packages is the
> need to use bare rpmbuild commands. I find the split between
> ~/rpmbuild/{SPECS,SOURCES} anachronistic (*), and much prefer the
> fedpkg / distgit approach of having everything in one directory.
> I now usually use the single directory approach from the beginning:
> - git init new-package && cd new-pagkage
> - emacs new-package.spec &
> - spectool -g *spec
> - md5sum ... | tee sources
> - git add new-package.spec sources && git commit -m 'Initial version'
> - git remote add ssh://pkgs.fedoraproject.org/new-package.git
> - fedpkg --dist master {srpm,mockbuild,etc}
>
> Without the fake remote fedpkg fails. I am wondering if there is a way
> to achieve this in a simpler way, or if not, if it would be possible to
> modify fedpkg to support packages which are not part of Fedora out of the
> box. IMHO this would make the process easier and more consistent for
> new (or existing) contributors.
I use simillar workflow of creating new packages, but I have a shell
function which I use to init git repos for new packages.
# Usage: newpkg
newpkg()
{
cd ~/newpkg
git clone g...@github.com:mizdebsk/newpkg.git $1
cd ./$1
git push -u origin master:$1
touch $1.spec
git add $1.spec
}
After initializing new git repo this way all important fedpkg commands
should work, except for uploading sources. I simply don't bother
creating "sources" files as sources will need to be uploaded later
during import.
So my workflow is as simple as:
newpkg foo
emacs foo.spec
spectool -g *.spec
fedpkg --dist master srpm
mock ... foo*.src.rpm
fedpkg commit -c
git push
Pros:
1) workflow uses fedpkg, without rpmbuild or manual md5sum
2) no need to upload spec/srpm to fedorapeople for review - you can use
github and koji URLs, respectively, as seen in [1].
3) future co-maintainers can easily collaborate (open pull requests)
before the package is accepted
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1242328
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
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
On 07/28/2015 11: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. I think that C-style operators (&, &&) are better than verbose COBOL-style ones because they are consistent with relation operators (>, >= and so on) already used by rpm. Secondly, they don't introduce conflict with existing meaning - "Requires: foo AND bar" is valid syntax in rpm <= 4.12, equivalent to requiring three packages separately. From C-style operators I would prefer single-character ones for two reasons: 1) Two-character operators may suggest short-circuit evaluation - "Requires: foo || bar" can be misunderstood as "require foo, or bar if and only if foo is not available", which is not how that works. There is no such problem with single-character operators. In other words, "|" and "&" operators are commutative, but "||" and "&&" are not. 2) Debian uses single-character operators. Cross-distro consistency and less confusion for people working on both Fedora and Debian is a plus. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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 Graylog2/unpackaged jar dependencies
On 08/24/2015 05:38 AM, W. Michael Petullo wrote: > I am interested in packaging the Graylog2 log analysis platform for > Fedora. I have created a number of Fedora packages in the past, but I > am a novice when it comes to packaging Java. Java packaging HOWTO [1] may be useful. For specific questions you can write to java-devel mailing list or ask on #fedora-java. > When I try to build my Graylog2 package, rpmbuild warns me that a number > of dependencies are missing from the package specification (see below). > > I can build Graylog2 by hand using Maven, but of course this downloads > the requisite files to ~/.m2. In Fedora we use a Maven extension (XMvn) which, among other things, tells Maven to use packaged dependencies instead of downloading them from remote repositories. > There is also at least one case of a package in Fedora which is > incompatible with the API version Graylog2 expects (okhttp). Isn't this > API-versioning mess common in Java? I vaguely recall there are a number > of tools to help manage this. How does Fedora expect package managers > to deal with this? In short: - update library to latest version - port dependant packages to newer versions of API if needed - send patches upstream - if patching is not feasible, create compat package > Is there a way to include these JAR files in the package, or is it > necessary to get each of these included as a Fedora package? Currently all dependencies must be packaged as RPMs and available in Fedora. [1] https://fedorahosted.org/released/javapackages/doc/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Removing packages that have broken dependencies in F23 tree
On 09/24/2015 07:12 PM, Christopher wrote: > I don't really understand what's going on with the netbeans-platform > package, or why accumulo would be affected. Upstream accumulo doesn't have > any dependencies on netbeans. Before I try to dive in and figure out what's > breaking, does anybody have any insight into what's going on with this, and > what it's providing that is breaking so many java packages? Accumulo depends on Hadoop, which is not installable in F23+: https://bugzilla.redhat.com/show_bug.cgi?id=1196209 Hadoop maintainer said he didn't have much time for maintaining the package and requested comaintainers, but without much response: https://lists.fedoraproject.org/pipermail/java-devel/2015-March/005503.html -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Koschei update
I would like to announce that Koschei [1], a continous intagration system for Fedora packages, has just been updated to a new version, which includes several new features and fixes multiple bugs. Summary of most important user-visible changes follows. Group management has been improved. Users can now create personal package groups, visible only for them and for people that know group URL. Groups can have multiple maintainers - people that can edit group content. Any personal group can be promoted to global group (visible for everyone) by Koschei admins - to request that you can file a ticket at infrastructure Trac [2]. List of packages which are monitored by Koschei is now managed by Fedora Package Database (PkgDB). Packagers can change whether Koschei will track given package or not by using newly-introduced "Koschei integration" switch in PkgDB Web UI at [3], or by using pkgdb-cli tool (requires packagedb-cli >= 2.9): $ pkgdb-cli koschei [1] https://fedoraproject.org/wiki/Koschei [2] https://fedorahosted.org/fedora-infrastructure/ [3] https://admin.fedoraproject.org/pkgdb/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Trouble retiring package on F21 branch
On 07/26/2014 03:09 PM, Gerard Ryan wrote: > Hi, > > We're trying to retire package eclipse-wtp-common on F21 and Rawhide. My > understanding is that this should be done F21 first, then Rawhide. F21 > has proven problematic so far. AFAIK maintainers can retire packages only in rawhide. For F21 you need a releng ticket. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: FESCo #1263 question (optional javadocs)
On 08/20/2014 07:14 PM, Christopher wrote:
> As a hypothetical, I was mainly concerned about backporting a new F21 java
> package as a F20 update to make it available to users still on that
> version, and whether that would require javadocs. Just in case, I've added
> a "%if 0%{fedora} < 21" condition for javadocs, and the appropriate
> Obsoletes line when the condition fails (>=20), but that's more to maintain
> in the specfile, and it'd be much simpler to just not declare any
> subpackaging for javadocs.
Then you can provide javadocs in all Fedora versions.
javadoc subpackages are still nice thing to have. Most of Java libraries
keep installing them in F21+ and there are no plans of dropping them.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
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: Orphaning json_simple
On 09/15/2014 05:16 PM, Peter MacKinnon wrote: > On 09/15/2014 10:48 AM, Steve Traylen wrote: >> Excerpts from Josh Boyer's message of 2014-09-15 16:39:53 +0200: >>> On Sep 15, 2014 10:37 AM, "Steve Traylen" wrote: >>>> Hi, >>>> >>>> I am orphaning json_simple >>> Why? >> It's the only piece of java in my packaging life and the packaging >> became hard where I need to learn all the maven macro stuff to fix >> bugs. Happy to maintain while trivial though can't justify more. Thanks for letting us know. >> >> Steve. >> >>> josh > > I will take this please. I've taken this package in Fedora (not EPEL) and added pmackinn as comaintainer. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Is there another Java Mass Rebuild scheduled for Fedora 21?
On 09/23/2014 04:41 PM, Robert Rati wrote: > I noticed that some updates to java packages have moved the jar file > locations or changed the jar name, which has broken symlinks in > dependent packages. I know log4j12 changed the location of the jar and > org.eclipse.osgi_3.10.0.v20140731-1655.jar changed versions to > org.eclipse.osgi_3.10.0.v20140918-0803.jar. For Equinox (org.eclipse.osgi_*.jar) you should use /usr/share/java/eclipse/osgi.jar symlink, which is always up-to-date and points to lib/ or lib64/ depending on system arch (noarch packages can have symlinks to osgi.jar, but not org.eclipse.osgi_*.jar). For log4j12, I don't see any problem. Can you provide more details? > Is there a plan to do another mass rebuild of the java bits? If not, > can we schedule one? We're already after Alpha release, I don't think we can or should have any mass rebuild. Instead we should focus on finding and fixing bugs in individual packages. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Is there another Java Mass Rebuild scheduled for Fedora 21?
On 09/23/2014 05:08 PM, Robert Rati wrote: > On 09/23/2014 10:49 AM, Mikolaj Izdebski wrote: >> For log4j12, I don't see any problem. Can you provide more details? > > A bug was fixed in log4j12 that moved the jar from _jnidir to _javadir, > thus breaking the symlinks in packages built before the change. I see. This probably should be fixed in log4j12. Can you file a bug? >>> Is there a plan to do another mass rebuild of the java bits? If not, >>> can we schedule one? >> >> We're already after Alpha release, I don't think we can or should have >> any mass rebuild. Instead we should focus on finding and fixing bugs in >> individual packages. > > The fix for me is easy as a simple rebuild fixes my problem. It doesn't > help solve the problem for any other packages that might have the same > problems or others dependencies that aren't affecting my package. The > list of affected packages is potentially pretty long for these two > issues so that's why I suggested a mass rebuild. Is there another > option other than having all affected package maintainers inspect their > packages and rebuild if necessary? You can identify packages with broken symlinks and file bug reports. Once fixed we can submit updates through bodhi. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning plotutils
I took plotutils by mistake a few months ago as part of large package reassignment. I am orphaning it now as I never intended to maintain the package. Feel free to adopt it if you wish. -- Mikolaj Izdebski IRC: mizdebsk -- 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: mock-1.2 released (new features)
On 10/14/2014 01:31 PM, Florian Weimer wrote: > On 10/14/2014 01:00 PM, Michael Simacek wrote: > FYI, the “nosync" functionality existed already in the form of > libeatmydata. As I understand, libeatmydata is under GPL and cannot be linked with free software under GPL incompatible licenses. I figured out it would be easier to reimplement the same functionality in clean room than convincing upstream to relicense. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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
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. [1] http://dnf.readthedocs.org/en/latest/conf_ref.html#keepcache-label -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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
On 03/16/2015 12:32 PM, Michael Šimáček wrote: > 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. Right. This is quite new change in mock and I didn't know about it because I don't use default configs. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning maven-changes-plugin
I'm orphaning maven-changes-plugin in Fedora 23. The reason is that I've been unable to update the package to newer upstream version for over 2 years (bug #919544) due to Apache CXF being outdated (bug #1007206). Packages that build-require maven-changes-plugin: Package maintainers --- ini4j omajid mybatis-generator gil, slaanesh xml-maven-pluginke4qqq, arg -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Continuous integration for Fedora
On 04/09/2015 12:32 PM, Sergio Pascual wrote: > I have recently heard of Debian Continuous Integration, i.e, automated self > tests are run for packages whenever its dependencies are updated. > > http://ci.debian.net/ > > Are there any plans to have something similar for Fedora? Koschei [1] can be used to rebuild package after dependency change or time elapse. Koschei runs tests enabled during package build. Taskotron [2] can be used to run other automated test cases (this is not yet possible in production instance AFAIK). [1] http://koschei.cloud.fedoraproject.org/ [2] http://taskotron.fedoraproject.org/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Continuous integration for Fedora
On 04/11/2015 11:10 PM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 09 April 2015 at 13:18, Remi Collet wrote: >> Le 09/04/2015 12:41, Mikolaj Izdebski a écrit : >>> Koschei [1] can be used to rebuild package after dependency change or >>> time elapse. Koschei runs tests enabled during package build. >> >> Among other thing, Koschei is already used to monitor changes in the PHP >> stack >> >> http://koschei.cloud.fedoraproject.org/groups/php?order_by=state%2C-started%2Cname >> >> Very useful tool which already allow us to detect and fix some regression. > > Out of curiosity, how do you add a new group? I can think of several > useful groups off the top of my head. Only admins can manipulate groups. Eventually users will be able to request new groups by filing infrastructure ticket, but for now you can contact admins (mizdebsk and msimacek) directly by email or IRC. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: koschei - cannot add packages
On 04/18/2015 02:21 AM, Orion Poplawski wrote: > I'm not sure where to post issues with koschei - the website itself does > not specify. So here goes - whenever I try to add some packages now I > get a 500 Internal Server Error. Thanks for pointing this out. I will add contact information to the webapp. Koschei is in the process of becoming official Fedora application. Once that process completes, contact target will be the same as for other infrastructure apps (#fedora-admin, fedora-infrastructure trac or infrastructure mailing list). Until that happens you can contact Koschei admins (mizdebsk, msimacek) directly by email or on IRC. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Differences between Koji and mock buildroots
For your information: Yesterday gdb package introduced "Remommends: dnf-plugins-core" in rawhide [1]. gdb is required by rpm-build, which is a default package in Koji f23 build group. As a consequence minimal f23-build buildroot installed with DNF (default mock config for rawhide) contains 22 additional packages compared to buildroot installed with YUM (mock config used by Fedora Koji). The list of extra packages is included below. This may cause unexpected results or subtle differences between local builds on packager machines and builds on Koji, so keep that in mind. The list of extra packages: bash-completion deltarpm dnf-conf dnf-plugins-core gpgme hawkey libcomps librepo libreport-filesystem libsolv python3-chardet python3-dnf python3-dnf-plugins-core python3-hawkey python3-iniparse python3-libcomps python3-librepo python3-pygpgme python3-requests python3-urllib3 rpm-plugin-systemd-inhibit rpm-python3 [1] http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=6d1599f359431c5eb6593a0a0bd1f51a5090550a -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
jna license fixed
License field of "jna" package in rawhide has been corrected from "LGPLv2+" to "LGPLv2 or ASL 2.0" to match upstream licensing terms. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: jna license fixed
On 06/10/2015 10:39 AM, Mikolaj Izdebski wrote: > License field of "jna" package in rawhide has been corrected from > "LGPLv2+" to "LGPLv2 or ASL 2.0" to match upstream licensing terms. Further investigation showed that the actual license is: jna: ASL 2.0 and (LGPLv2 or ASL 2.0) jna-javadoc: ASL 2.0 and (LGPLv2 or ASL 2.0) jna-contrib: LGPLv2 or ASL 2.0 Reasoning: Most of code is dual-licensed under either LGPL 2.1 only or Apache License 2.0. WeakIdentityHashMap.java was taken from Apache CXF, which is under pure Apache License 2.0. References: https://bugzilla.redhat.com/show_bug.cgi?id=988808 https://github.com/twall/jna/issues/252 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Koschei migration (outage)
For your information: In the next few days we'll be migrating Koschei server and database to different machines. During that time you may experience ocassional Koschei unavailability. Additionally, Koschei will be working in read-only mode (no new builds will be submitted) and any changes made in the web interface (such as adding new packages) may be lost after the migration. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Koschei - new Fedora infrastructure service
I'm glad to announce that as of yesterday Koschei production instance has been moved Fedora infrastructure and now it can be considered as officially-supported Fedora service. Koschei is a continuous integration service for Fedora packages. Koschei is aimed at helping Fedora developers by detecting problems as soon as they appear in rawhide - it tries to detect package FTBFS in rawhide by scratch-building them in Koji. More information can be found at Fedora Wiki [1]. Interested parties can be automatically notified when Koschei detects change in package FTBFS status. In order to subscribe to email or IRC notifications you can follow instructions at [2]. At the time of writing, Koschei monitors about 20 % of all Fedora packages, but anyone with FAS account can add packages they are interested in. See [3] for details how to add packages to Koschei. I would like to thank everybody who helped to make Koschei at Fedora infrastructure possible, especially Kevin Fenzi, who sponsored Koschei request for resources and assisted us with the migration. [1] https://fedoraproject.org/wiki/Koschei [2] https://fedoraproject.org/wiki/Koschei#Notifications [3] https://fedoraproject.org/wiki/Koschei#Adding_packages -- Mikolaj Izdebski ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: Koschei - new Fedora infrastructure service
On 06/25/2015 06:41 PM, Przemek Klosowski wrote: > On 06/25/2015 09:41 AM, Mikolaj Izdebski wrote: >> Koschei is a continuous integration service for Fedora packages. >> .. >> [1] https://fedoraproject.org/wiki/Koschei > Cool project! > Tiny heads-up: the link for the presentation returns 404: > http://mizdebsk.fedorapeople.org/koschei/koschei-pp-20140711.pdf > Thanks, the link should be already fixed. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Koschei - new Fedora infrastructure service
On 06/25/2015 05:21 PM, Remi Collet wrote: > Small idea: it will be nice to have a "Add to/Remove from Koschei" in > pkgdb like the one we have for upstream monitoring. Thanks for mentioning that. This feature request is currently being discussed at [1]. [1] https://github.com/msimacek/koschei/issues/13 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Orphaned Packages in rawhide (2015-06-30)
On 06/30/2015 09:12 AM, opensou...@till.name wrote: > netty31 orphan 2 weeks ago As far as I can tell only one package directly depended on netty31: gradle. That dependency was actually a bug (gradle should build-require netty3 instead of netty31) and it is fixed [1] in rawhide. [1] http://pkgs.fedoraproject.org/cgit/gradle.git/commit/?id=6102b02 -- 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: Query about package versioning
On 02/20/2014 05:16 PM, Vivek Goyal wrote: > So instead of increasing release number on released branches, why don't > we append additional number after dist and bump that up in released > branch. So FC21 releases will look like. > > kexec-tools-2.0.4-24.fc21.1 > kexec-tools-2.0.4-24.fc21.2 > ... > ... > kexec-tools-2.0.4-23.fc21.10 > > That way we clearly know that FC21 was forked off master release .24. And > upgradability of package will be maintained without any change of older > release versions getting ahead of newer release versions. IMO it's best to do fast-forward merges between branches when possible. In particular merging mass rebuild commits is OK. In case FF merge is impossible I agree with the procedure you described. You need to increase release tag in a way that assures upgrade path and one way to do that is adding .1 after dist tag. -- Mikolaj Izdebski IRC: mizdebsk -- 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: Query about package versioning
On 02/20/2014 05:28 PM, Marcin Juszkiewicz wrote: > W dniu 20.02.2014 17:16, Vivek Goyal pisze: > >> So instead of increasing release number on released branches, why don't >> we append additional number after dist and bump that up in released >> branch. So FC21 releases will look like. >> >> kexec-tools-2.0.4-24.fc21.1 >> kexec-tools-2.0.4-24.fc21.2 >> ... >> ... >> kexec-tools-2.0.4-23.fc21.10 >> >> That way we clearly know that FC21 was forked off master release .24. And >> upgradability of package will be maintained without any change of older >> release versions getting ahead of newer release versions. > > %dist should be at the end. > > So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of > fc21 package after distribution release. That won't work if both branches already have the same release number and you need to bump release in older branch. That can happen for example if you were fast-forwarding commits from f21 to f20 and at some point you need to add a bugfix only for f20. Adding .1 after dist-tag will work in this case. -- Mikolaj Izdebski IRC: mizdebsk -- 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: Packages with missing %check
On 02/25/2014 11:45 AM, Alexander Todorov wrote: > Hi guys, > I have identified 551 packages on the Fedora 20 source DVD which are > missing a %check section in their spec files but are very likely to have > a test suite. See > https://github.com/atodorov/fedora-scripts/blob/master/sample-data/fedora-20/srpms-with-tests-WITHOUT-check-in-fedora-20-dvd I can see a lot of Java packages on that list. Most Java packages run their test suites in %build and don't have %check section at all, so they would be false-positives. > 1) Do we consider this a bug and if yes what priority do you give it? > From last week discussions it looks like most people prefer to have > tests executed in %check. If upstream includes test suite but it is not ran without any comment then I consider this as a bug. If some tests cannot be ran because of missing dependencies or because they require network access etc. then I try to disable these test cases and run all others. > 2) Last week Alexander Kurtakov brought up the issue of packages > executing their test suite during build. How to detect such packages? > OTOH we can have some false negatives (also see 3). For packages using Maven (most common Java build system) you can use heuristic implemented in the following script: http://mizdebsk.fedorapeople.org/scripts/wr-testsuitecheck I used it to review my 250+ packages I maintain and it has low false-positive ratio. > 3) Another proposal (sorry don't remember who proposed it) was to have > %check with a comment why the test suite is not executed (e.g. requires > network) or why it is executed in %build. Commenting why tests are skipped is a very good thing, but I don't like the idea of adding empty %check sections to my 250+ packages just for the sake of documenting that tests are ran in %build "because that's what we do in Java world". -- Mikolaj Izdebski IRC: mizdebsk -- 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: F21 System Wide Change: Java 8
On 03/22/2014 06:15 AM, Miloslav Trmač wrote: > Given the known large number of failures (OptionalJavadocs says "80% build > failure rate" without saying that all are JavaDoc-related), we really > should do a mass rebuild to identify which packages fail to build *and* to > file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and > then scrambling to fix dozens/hundreds of build failures in to avoid > slipping the schedule. We don't necessarily need an official one, perhaps > only in a never-to-be-merged side tag (or even scratch builds?) Agreed. To do a rebuild in Koji Java 8 must land in there first. That can could be a separate tag, but rel-eng is quite reluctant to provide them. Copr could be a better place to do the rebuild. One big advantage is that it doesn't use any ARM builders, but on the other hand it has quite limited capacity (AFAIK 10 builders only). Besides that, there is already one approved change [1] which requires rebuilding most of Java packages. We didn't do a mass rebuild for it yet because we wanted to sync with Java 8 rebuild. -- Mikolaj Izdebski [1] https://fedoraproject.org/wiki/Changes/HeadlessJava -- 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: F21 System Wide Change: Java 8
On 03/24/2014 04:49 PM, Peter Robinson wrote: > On Mon, Mar 24, 2014 at 3:41 PM, Mikolaj Izdebski wrote: >> On 03/22/2014 06:15 AM, Miloslav Trmač wrote: >>> Given the known large number of failures (OptionalJavadocs says "80% build >>> failure rate" without saying that all are JavaDoc-related), we really >>> should do a mass rebuild to identify which packages fail to build *and* to >>> file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and >>> then scrambling to fix dozens/hundreds of build failures in to avoid >>> slipping the schedule. We don't necessarily need an official one, perhaps >>> only in a never-to-be-merged side tag (or even scratch builds?) >> >> Agreed. >> >> To do a rebuild in Koji Java 8 must land in there first. That can could >> be a separate tag, but rel-eng is quite reluctant to provide them. > > java 8 is already in the main repos and had been there since F-19. > It's just not providing things like java-devel and hence isn't used by > default in the build process. That's exactly the problem. We need to use a modified version of java-1.8.0-openjdk with extra provides and adjusted priorities for alternatives. Blocking java-1.7.0-oepnjdk may also be required. This makes it impossible to scratch-build Java packages using f21-build target in current state. > >> Copr could be a better place to do the rebuild. One big advantage is >> that it doesn't use any ARM builders, but on the other hand it has quite >> limited capacity (AFAIK 10 builders only). > > That's not an advantage, building ARM packages is a requirement of > something in primary architecture. Also you can't tag copr builds in > Fedora. You need to use a koji f21 side tag. I was talking talking about doing scratch builds to identify packages failing to build with Java 8. Java 8 change does *not* require mass rebuild in Fedora. Great majority of packages will work with Java 8 with no change. > >> Besides that, there is already one approved change [1] which requires >> rebuilding most of Java packages. We didn't do a mass rebuild for it >> yet because we wanted to sync with Java 8 rebuild. > > Well there will also be a mass rebuild in general for gcc 4.9 so you > should coordinate with rel-eng to minimise builds in general. > > Peter -- Mikolaj Izdebski -- 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: F21 System Wide Change: Java 8
On 03/25/2014 06:45 PM, Omair Majid wrote: > * Mikolaj Izdebski [2014-03-24 11:41]: >> On 03/22/2014 06:15 AM, Miloslav Trmač wrote: >>> Given the known large number of failures (OptionalJavadocs says "80% build >>> failure rate" without saying that all are JavaDoc-related), we really >>> should do a mass rebuild to identify which packages fail to build *and* to >>> file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and >>> then scrambling to fix dozens/hundreds of build failures in to avoid >>> slipping the schedule. We don't necessarily need an official one, perhaps >>> only in a never-to-be-merged side tag (or even scratch builds?) >> >> Agreed. > > Should I update the proposal to clarify that a mass rebuild is required, > then? I don't think that a mass rebuild is *required* for this feature. Packages built with Java 7 should still work with Java 8. What I said is that it may be nice to do scratch builds of some packages because they may start failing to build with Java 8. Some of our CI efforts already caught a few FTBFS caused by switching to Java 8, for example hadoop[1] or maven-doxia[2]. The earlier we do the scratch builds the more time we'll have to fix any failures before system-wide mass rebuild comes. [1] https://lists.fedoraproject.org/pipermail/bigdata/2014-March/000391.html [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=6674018 -- Mikolaj Izdebski -- 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: F21 System Wide Change: Java 8
On 03/25/2014 08:07 PM, Omair Majid wrote: > * Mikolaj Izdebski [2014-03-24 11:55]: >> Blocking java-1.7.0-oepnjdk may also be required. This >> makes it impossible to scratch-build Java packages using f21-build >> target in current state. > > Is there anything I can/should do here? Shall I file a rel-eng ticket to > block java-1.7.0-openjdk? Would it be worth waiting a little while to > ensure that there are no show-stopper bugs in java-1.8.0-openjdk? Thank you for making OpenJDK 8 default Java in rawhide. Blocking Java 7 would make things a bit easier, but it is not absolutely required. I agree with others that keeping it for a (short) while is probably a good thing. -- Mikolaj Izdebski -- 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: F21 System Wide Change: Java 8
On 03/26/2014 05:52 PM, Stanislav Ochotnicky wrote: > On Wed 26 Mar 2014 05:29:55 PM CET Christopher wrote: > >> On Wed, Mar 26, 2014 at 9:31 AM, Deepak Bhole wrote: >>> * Christopher [2014-03-25 19:59]: >>>> I also would like to see 1.7.0 stick around for awhile. Not >>>> necessarily as the default, but at least available in the repos. As it >>>> stands, it's difficult to use a modern Fedora on projects that are >>>> still developing against JDK 1.6. >>>> >>> >>> Unfortunately, OpenJDK7 will be EOLd in April 2015[1], which is within >>> the support time-frame of the F21. This is one the reasons why we would >>> like to be able to switch over to OpenJDK8 asap for F21. >>> >>> 1: http://www.oracle.com/technetwork/java/eol-135779.html >> >> I don't see how Oracle tentatively dropping long-term public support >> for 7 means that Fedora needs can no longer provide OpenJDK7 in its >> repos (not as default, of course), with or without additional updates, >> for developers who want to use a modern Fedora, but need to develop >> for applications/hardware that requires strict 7 compatibility. >> >> The alternative is Fedora fans will be forced to use an older version >> of Fedora, use a different Linux distro, or find some hackish >> workaround (yum --releasever=20 ...; which is problematic, because >> every version 8 update will obsolete 7, just like 7 currently does >> with 6 packages), or download untrusted 3rd party packages. >> >> It seems to me that support in Fedora would be pretty easy: just make >> sure it doesn't cause a packaging conflict and recommend the newer >> JDK8. Maybe call it -compat? But, I defer to the experts on Fedora >> packaging/support policies and decisions. I'm just a user, and don't >> know all the implications for trying to include it. I just think it'd >> be nice to keep around. > > It's not a question if we can have multiple parallel JDKs (we already > can, you can install 7 and 8 at the same time). > > What we *can't* have in Fedora is a high-profile package which doesn't > receive security updates upstream and there is nobody in Fedora willing > and capable of doing that. > > What's the big deal with using '--target 1.7' anyway? That covers 99% of > use cases, and any possible problems will have to be caught by CI > running whatever you'd be deploying on anyway. Even with --target 1.7 you can still use some Java 8 features provided by standard library, which are not available in Java 7. That's the reason tools like animal-sniffer were created. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 08:03 PM, Bill Nottingham wrote: > Jaroslav Reznik (jrez...@redhat.com) said: >> = Proposed System Wide Change: lbzip2 as default bzip2 implementation = >> https://fedoraproject.org/wiki/Changes/lbzip2 >> >> Change owner(s): Mikolaj Izdebski >> >> This change aims at making lbzip2 [1] default bzip2 implementation used in >> Fedora. >> >> == Detailed Description == >> lbzip2 is an independent implementation of bzip2 compression tool. It >> provides >> interface strictly compatible with bzip2, but also adds several new features >> and improvements, such as: >> >> * multi-threaded operation for both compression and decompression, with >> almost >> linear scalability, >> * improved performance, even on single-core systems, >> * improved extra utilities (bzdiff, bzless, bzip2recover, etc.), >> * improved compatibility with gzip. >> >> lbzip2 is a mature project and it has been used in production for years. It >> is >> already packaged for Fedora and it is also available in EPEL. > > A quick check shows lbzip2 doesn't provide a library interface, much less > one compatible with libbz2. Is that ever intended? That was once intended (in 2007-2010), but for now I decided to provide bzip2-compatible commands only. If there is demand I will reconsider providing a library with bzip2-compatible API/ABI. > If it's not, saying lbzip2 is the default bzip2 *implementation* may be a > bit of a stretch. Perhaps s/implementation/command/. You're right, the title and description may be ambiguous. In this sentence "bzip2" means bzip2 command. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 08:10 PM, Tom Hughes wrote: > On 02/04/14 18:24, Jaroslav Reznik wrote: > >> == Detailed Description == >> lbzip2 is an independent implementation of bzip2 compression tool. It >> provides >> interface strictly compatible with bzip2, but also adds several new >> features >> and improvements, such as: >> >> * multi-threaded operation for both compression and decompression, >> with almost >> linear scalability, > > Does that mean that it creates multiple streams in the compressed file? > > If it does then be aware that some bzip2 decoders (notable the Java one) > will not be able to decompress the result. lbzip2 creates only *one* stream per compressed file, even when using multiple threads. Such files can be decompressed with all versions of bzip2, libbz2 and other tools, such as Apache Commons Compress. This is a difference between lbzip2 and pbzip2, which creates multiple streams. Files created with pbzip2 cannot be decompressed by some software, such as libbzip2 (all versions), bzip2 older than version 0.9.0, Apache Commons Compress. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
> On 04/02/2014 11:33 AM, Reindl Harald wrote: > > packages using the library (output of yum remove > > bzip2-libs-1.0.6-9.fc20.x86_64) > > Try: repoquery --whatrequires 'libbz2.so.1()(64bit)' > > We'll certainly need to keep the library around. Yes, but we can have /usr/bin/bzip2 (and other commands) pointing to lbzip2 binary and at the same time applications can keep using libbz2. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
> > ** possibly adjust spec files to require or build-require lbzip2 instead of > > bzip2. > Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 > or something so that updating all those packages is not necessary, > and also that people who prefer normal bzip2 can still use it? You could do that, but then two packages would have the same virtual provide and it wouldn't be well defined which one would be installed. In such cases YUM seems to choose packages with shorter names, so it would prefer bzip2 over lbzip2. At least one package somewhere low in the system has to require lbzip2 explicitly. I think that package maintainers who want to use lbzip2 should declare it as explicit dependency. Assuming that packages are calling standard bzip2 command names (bzip2, bzcat and so on) users will still be able to switch implementations as they want by configuring alternatives, even if package has requires on lbzip2. We don't need to migrate all packages to Require lbzip2. If lbzip2 has highest priority in alternatives then it will be used as long as it is installed. It doesn't even need to Provide bzip2. It should be enough to include lbzip2 in minimal installation and add is a dependency of @buildsys-build to effectively make it default implementation. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
> On 2 April 2014 21:46, drago01 wrote: > > On Wed, Apr 2, 2014 at 10:27 PM, Zbigniew Jędrzejewski-Szmek > > wrote: > >>> ** possibly adjust spec files to require or build-require lbzip2 instead > >>> of > >>> bzip2. > >> Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 > >> or something so that updating all those packages is not necessary, > >> and also that people who prefer normal bzip2 can still use it? > > > > Why would people prefer it? If it is the same but slower? > > Yes, if it's interface compatible then it's pretty nice. Multithreaded > compression is handy from time to time. Pity about no library > interface (lbzip2 might be an unfortunate name choice...), > particularly for things like perl and python. I suppose from the pov > of minimal systems it might be nice to not have to have both if you > need to fulfil both a bzip2 library requirement and a bzip2 > requirement, but that's a very particular case for a few kB saving. It shouldn't be difficult to provide library interface. In fact I considered planned it from the very beginning, but then lacked motivation. I'm sure that accepting this Change will be a motivator good enough for me to finally do this. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
> This implementation has been built and extensively tested using the > current release of the real bzip2 library. Substituting a completely > different library implementation without going through extensive and > explicit validating and testing is risky and unreasonable. At best, it > would complicate problem reporting, reproduction, analysis and > correction. lbzip2 does not (at least not yet) provide interfaces of libbz2 library, only command line tools. This Change does *not* affect users of libbz2. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
> On Wed, Apr 2, 2014 at 11:39 PM, Chris Adams wrote: > > Once upon a time, Mikolaj Izdebski said: > >> lbzip2 does not (at least not yet) provide interfaces of libbz2 library, > >> only command line tools. This Change does *not* affect users of libbz2. > > > > Is there enough of a gain to the system to only partially replace a core > > program like this (especially with alternatives)? This seems like a > > case where either we get a "new and improved and replaces the old" > > version (where the new one just obsoletes the old one, such as the > > jpeg-turbo change), or just leave it alone. Eventually lbzip2 may replace bzip2, but I don't want to make any drastic changes. Using alternatives allows us to have a nice contingency plan in case something goes unexpected. Once lbzip2 is used by default, further chnages will be just a metter of agreement between maintainers. > > Please understand, I don't mean to "attack" you or your code. I just > > think adding a second implementation of a core utility like bzip2 is a > > bad idea unless there is a significant gain. If there's a point where > > lbzip2 can fully replace bzip2 (so all CLI and API uses), and there are > > good benefits, then Fedora should just replace the old implementation > > with a new one. I believe there is a signifficant gain, see below. > Well the change says " multi-threaded operation for both compression > and decompression, with almost linear scalability" linear scalability > means speed ups on the range of 2-8x on current desktop / laptop > systems. > Which I'd call a "significant gain" ;) I don't have any recent benchmark comparing performance of lbzip2 with bzip2 because doing them doesn't make much sense for me -- lbzip2 is so much faster. I compare only different versions to make sure there are no performance regressions. However I have one *old* benchmark made just after lbzip2 2.0 release 2 and half years ago (current version is 2.5). But since then lbzip2 was improved. https://github.com/kjn/lbzip2/wiki/Benchmark:-Opteron-24 I will prepare more benchmarks of recent lbzip2 version for desktop (1, 2, 4, 8 cores) and bigger multicore server systems. A test of scalability (pretty old too) is available at: http://archive.lbzip2.org/scaling/scaling.html I hope that's convincing enough for now. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
> This clarification is significant. The change proposal text needs to > be updated to reflect this. I will add a clarification tomorrow. > > As long as the encoding is guaranteed to be byte-for-byte identical to > that produced by the original bzip2 (and libbz2) implementation, the > risks are lowered. No, encoding is almost never bytewise identical to bzip2, but it doesn't have to be as long as the resulting bz2 file has correct format. bzip2 itself changed encoding between versions without any impact on users. Even the same version of bzip2 can produce different compressed files for the same input with and with the same block size. lbzip2 uses improved algorithms, which are not only faster, but allow for slighty better compression ratio, for example: $ echo test | bzip2 | wc -c 45 $ echo test | lbzip2 | wc -c 43 > Scenarios affected by this substitution are those with direct > invocation of the command (from the command prompt, a shell script, or > system() type call). That's true. And even in the unlikely case that something goes wrong, developers (or even users themselves) have possibility to easily switch back to bzip2. -- Mikolaj Izdebski -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/03/2014 03:47 AM, Chris Adams wrote: > Many of the common users (such as rpm) are linked > against the library and don't use the command, so they won't be > impacted. rpm does use bzip2 *command* and it would be impacted by this change. rpm uses libbz2 only for compression and decompression of rpm package payloads. Since Fedora uses LZMA compression, libbz2 is used only when installing some older third-party packages which happen to be compressed with bzip2. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: RPM-4.12
On 04/02/2014 07:47 PM, Jaroslav Reznik wrote: > * Support for weak dependencies Does this mean that rpm-build will be able to create packages with weak dependencies? Will Fedora packages be allowed to declare weak dependencies? Is dependency generator interface going to be extended so that we can generate auto-recommends and auto-suggests for packages? > * Support for packaging files > 4GB > * Support for real package reinstallation > * New API for accessing files and file contents > * New tool for converting rpm packages to tar files > * Internal plugin interface Are there any details abuout this interface available somewhere? Will packages be able to provide plugins, like for example they can install RPM macros now? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/03/2014 06:08 PM, Miloslav Trmač wrote: > Looking at http://lbzip2.org/news , lbzip2 is still fixing crashes during > compression and decompression. That's rather troubling: we need the bzip2 > implementation to be roughly as stable as file system*.* They say that every non-trivial piece of software has at least one bug. bzip2 also has bugs, myself I am aware of a few of them. > The Change page > implies that bzip2 is not actively maintained; that may be true but looking > at bugzilla.redhat.com, there has AFAICT never been a bug reporting that > something can't be compressed or decompressed--that's a *very* high bar to > match. (I do appreciate that assertion failure and silent miscompression > are not the same thing.) Neither was for lbzip2. And as a matter of fact, bzip2 is compiled with most of assertions disabled. But I understand the point. It may be true that bzip2 is more stable, but that's because it has been given a chance being included in popular operating systems and after initial bugs were fixed it has been there without any changes for years. I care about lbzip2 quality very much. I run a test suite consisting of over 320,000 automated test cases, I compile it with all possible warnings enabled I test it with multiple static analysis tools. Any bugs that may be found during testing in Fedora will be taken care of with high priority. I believe that lbzip2 deserves to be given a chance and if for some reason it turns out not to be ready, the Change can be reverted very easily with a single spec file modification. > Having the library implementation and the command-line implementation > completely separate may frustrate debugging efforts when using an > application-builtin compression and saving uncompressed and compressing > manually may give different results. That's not a deal-breaker but having > a single implementation would certainly simplify things. Users will still be able to run bzip2 explicitly if needed or configure alternatives to used it as implementation of /usr/bin/bzip2 on their systems. Besides that I am willing to provide a library interface for lbzip2 in future if there is demand. > Ultimately the easiest way to make this implementation change happen, not > only in Fedora but in all distributions, would be for the improvements to > be integrated into the upstream bzip2 codebase; has that possibility been > explored at all? lbzip2 as it is now is a merger of 2 projects -- a parallel bzip2-like tool using libbz2 by Laszlo Ersek (started in 2008) and improved low-level bzip2 library by me (started in 2007). The 2 projects were merged in 2010 and since then I took maintenance of lbzip2. While I would like the improvements and new features of lbzip2 to be included in bzip2, I lost my hopes of this ever happening. Both Laszlo me and tried contacting Julian Seward (the author or bzip2) and contributing to bzip2, but without any success. Initially Julian admited that it would be desirable to parallelise bzip2. The plan was to evaluate existing implementations and decide which one to integrate with bzip2, or start the work from scratch. But nothing of that happened. The last conversation about improving bzip2 took place in 2009 and only a single patch was included in bzip2 since then -- a fix for important security bug which I discovered (CVE-2010-0405 [1], it took it 6 months to be applied in bzip2). That said, I am still willing to cooperate with Julian and discuss possibilities of merging some code or improving bzip2 in any way. [1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0405 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
As I promised, I prepared a benchmark of lbzip2 and bzip2. I also added pbzip2 for comparison. Basic information = Test date: 2014-04-04 Tester:Mikolaj Izdebski Test subjects: lbzip2 2.5 bzip2 1.0.6 pbzip2 1.1.6 Test purpose: compare performance, memory usage and compression ratio of lbzip2, bzip2 and pbzip2 in Fedora CPU: Haswell B0, Genuine Intel(R) CPU @ 2.20GHz bogomips: 4389.60 Processors:56 NUMA Nodes:2 Memory:31966 MB System:Fedora release 20 (Heisenbug) Arch: x86_64 Inst. method: anaconda 20.25.15-1 (kickstart) File system: tmpfs (/dev/shm) Methodology === Compress and decompress different payloads: - Linux kernel sources. - tarball created from /usr Linux source tarball was chosen because it is a quite big bz2 file which can be easily downloaded from the Internet to reproduce test results. MD5 sums are provided for reproducibility. linux-3.12.6.tar 544061440 02d8601f28c519a9d4d0a2ae99bb597a linux-3.12.6.tar.bz2 91104346 2e1e42cf9c164d8c24bc1e33bb3c7b2b Tarball created by running "tar cf payload.tar /usr" was chosen because it contains different types of data: text files, executables, uncompressible files, while it should still allow to reproduce the results quite easily. payload.tar 1463183360 payload.tar.bz2 424518771 Each compression and decompression was ran three times. The run with median of real time (wall clock) was chosen, other two were rejected. Times and memory usage were measured using GNU time utility. Results === real- elapsed real time (wall clock, seconds) user- elapsed user time (seconds) sys - elapsed system time (seconds) memory - maximum resident set size (kbytes) compr. size - size of resulting compressed file (bytes) Decompression of linux-3.12.6.tar.bz2 - command| real | user | sys | memory ---+++--+--- lbzip2 | 0.79 | 30.72 | 1.70 | 448804 lbzip2 -u | 5.85 | 18.62 | 1.83 | 80992 pbzip2 | 24.48 | 24.27 | 0.61 | 98444 bzip2 | 23.95 | 23.46 | 0.44 | 4212 Compression of linux-3.12.6.tar --- command| real | user | sys | memory | compr. size ---+++--++ lbzip2 | 1.30 | 61.45 | 2.35 | 360280 | 91383535 lbzip2 -u | 2.51 | 44.11 | 1.43 | 211456 | 91084544 pbzip2 | 2.69 | 105.79 | 4.11 | 488840 | 91411005 bzip2 | 66.16 | 65.82 | 0.22 | 7996 | 91104346 Decompression of payload.tar.bz2 command| real | user | sys | memory ---+++--+--- lbzip2 | 2.19 | 95.16 | 3.81 | 750548 lbzip2 -u | 23.34 | 60.31 | 5.04 | 120140 pbzip2 | 69.55 | 69.07 | 1.92 | 139060 bzip2 | 68.30 | 66.93 | 1.27 | 4216 Compression of payload.tar -- command| real | user | sys | memory | compr. size ---+++--++ lbzip2 | 3.36 | 170.07 | 6.38 | 380448 | 424676188 lbzip2 -u | 6.45 | 123.14 | 3.80 | 255524 | 424518771 pbzip2 | 6.78 | 288.33 | 8.90 | 491644 | 425213134 bzip2 | 176.68 | 175.76 | 0.67 | 8000 | 425108407 Conclusions === Memory usage depended on number of threads used. Difference of memory usage between parallel and non-parallel runs can be ignored as even parallel tools can be run in non-parallel mode. "lbzip2" was the fastest compressor and decompressor in all tests. It the best command for interactive use. "lbzip2 -u" always produced smallest files (even smaller than bzip2) while consuming the least amount of resources (CPU power and memory). This directly translates to lowest bills in cloud, which makes "lbzip2 -u" the best choice here. "pbzip2" did not allow parallel decompression. During compression it was always the slowest, used highest amounts of memory and offered the worst compression ratio. You don't have to believe this report, you are free to try lbzip2 and see for yourself. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/02/2014 08:03 PM, Bill Nottingham wrote: > A quick check shows lbzip2 doesn't provide a library interface, much less > one compatible with libbz2. Is that ever intended? > > If it's not, saying lbzip2 is the default bzip2 *implementation* may be a > bit of a stretch. Perhaps s/implementation/command/. I have clarified that in the change proposal by explicitly stating that this change replaces bzip2 tool only and that libbzip2 is not affected. http://fedoraproject.org/w/index.php?title=Changes/lbzip2&diff=375469&oldid=375468 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/04/2014 05:16 PM, Michal Schmidt wrote: > On 04/04/2014 04:15 PM, Mikolaj Izdebski wrote: >> Compression of payload.tar >> -- >> >> command| real | user | sys | memory | compr. size >> ---+++--++ >> lbzip2 | 3.36 | 170.07 | 6.38 | 380448 | 424676188 >> lbzip2 -u | 6.45 | 123.14 | 3.80 | 255524 | 424518771 >> pbzip2 | 6.78 | 288.33 | 8.90 | 491644 | 425213134 >> bzip2 | 176.68 | 175.76 | 0.67 | 8000 | 425108407 >> >> >> Conclusions >> === >> [...] >> "lbzip2 -u" always produced smallest files (even smaller than bzip2) >> while consuming the least amount of resources (CPU power and memory). > > The table above says it needs about 30 times *more* memory than bzip2. No, it shows that it *used* that much memory. The system had 32 GB of RAM, lbzip2 using all 56 CPUs used less than 1.2 % of available memory. That is *very* conservative. Memory usage can be limited by lowering number of threads used (-n) or by specifying explicit memory limit (-m, undocumented for now, it will be fully supported in future version of lbzip2 after it gets enough testing). -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/04/2014 05:26 PM, Mikolaj Izdebski wrote:
> On 04/04/2014 05:16 PM, Michal Schmidt wrote:
>> On 04/04/2014 04:15 PM, Mikolaj Izdebski wrote:
>>> Compression of payload.tar
>>> --
>>>
>>> command| real | user | sys | memory | compr. size
>>> ---+++--++
>>> lbzip2 | 3.36 | 170.07 | 6.38 | 380448 | 424676188
>>> lbzip2 -u | 6.45 | 123.14 | 3.80 | 255524 | 424518771
>>> pbzip2 | 6.78 | 288.33 | 8.90 | 491644 | 425213134
>>> bzip2 | 176.68 | 175.76 | 0.67 | 8000 | 425108407
>>>
>>>
>>> Conclusions
>>> ===
>>> [...]
>>> "lbzip2 -u" always produced smallest files (even smaller than bzip2)
>>> while consuming the least amount of resources (CPU power and memory).
>>
>> The table above says it needs about 30 times *more* memory than bzip2.
>
> No, it shows that it *used* that much memory.
>
> The system had 32 GB of RAM, lbzip2 using all 56 CPUs used less than 1.2
> % of available memory. That is *very* conservative.
>
> Memory usage can be limited by lowering number of threads used (-n) or
> by specifying explicit memory limit (-m, undocumented for now, it will
> be fully supported in future version of lbzip2 after it gets enough
> testing).
lbzip2 can use less memory than bzip2 while still being much faster.
Example results:
Command being timed: "bzip2 -kf linux-3.12.6.tar"
User time (seconds): 47.70
System time (seconds): 0.20
Percent of CPU this job got: 95%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:49.92
Maximum resident set size (kbytes): 7884
Command being timed: "lbzip2 -kfusn1 linux-3.12.6.tar"
User time (seconds): 31.77
System time (seconds): 0.89
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:32.96
Maximum resident set size (kbytes): 7704
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
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: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/04/2014 07:01 PM, Susi Lehtola wrote: > On Fri, 4 Apr 2014 12:49:25 -0400 > Matthew Miller wrote: >> On Fri, Apr 04, 2014 at 04:15:59PM +0200, Mikolaj Izdebski wrote: >>> "lbzip2 -u" always produced smallest files (even smaller than bzip2) >>> while consuming the least amount of resources (CPU power and memory). >>> This directly translates to lowest bills in cloud, which makes "lbzip2 >>> -u" the best choice here. >> >> But... the size difference in your test cases appear to be 0.1% and >> 0.02%. Am I reading that right? And, compressing linux-3.12.6.tar with xz >> instead of bzip2 gives a 15.6%, or with xz -9, 19.7%. Of course, that's very >> slow, and the other resource factors are important too. (And lbzip2 is >> impressively fast.) > > Well, looking at the table, I calculate size differences of -0.10% and > -0.14% for lbzip2 and lbzip2 -u, respectively, compared to bzip2 for > compression of payload.tar. In general lbzip2 has compression ratio very close to bzip2. lbzip2 -u almost always produces marginally smaller files than bzip2. Without -u it varies. Sometimes lbzip2 produces marginally bigger, sometimes smaller bz2 files. About xz... For some types of data bz2 compression works better than xz. Examples: sparse disk images containing lots of zeroes, or genome DNA sequences. $ dd if=/dev/zero of=zero bs=100 count=100 $ lbzip2 -ku zero $ xz -k zero -rw-rw-r--. 1 1 Apr 4 19:17 zero -rw-rw-r--. 1 113 Apr 4 19:17 zero.bz2 -rw-rw-r--. 1 14676 Apr 4 19:17 zero.xz xz doesn't allow parallel decompression in general. When restoring backups you are under time pressure and fast decompression can come very handy. When xz file is damaged then all data succeeding the point of damage is lost. But lbzrecover tool from lbzip2-utils allows easy recovery of data from undamaged parts of any bz2 file. Personally, for above reasons I recommend people to use lbzip2 for backups rather than xz. But I admit xz is a better format for some use cases. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: rawhide report: 20140404 changes
On 04/04/2014 07:14 PM, Matthew Miller wrote: > [snip] > > Is it useful for these messages to go to the devel (or test, for that > matter) lists? They seem mostly to just raise the noise. It is definitely useful, but I wish there was some way of excluding long-standing problems that no one cares to fix. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Orphaning java-1.5.0-gcj
> > Ok the patch worked fine for building on my F20, which I did as a test, > > however it failed the build in rawhide. > > > > The only clue I can get is this: > > configure: WARNING: unable to include > > > What's in the configure log file regarding this? This is solved now, AFAIK. The configure script had some custom code to detect Java version by parsing output of "java -version", which didn't work because OpenJDK >= 8 has slightly different output format. An analogous change was needed in javapackages: https://github.com/mizdebsk/javapackages/commit/494fea0 -- Mikolaj -- 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: java-1.8.0-openjdk i686 and x86_64 rpms
On 04/23/2014 12:07 PM, Michael Schwendt wrote: > On Wed, 23 Apr 2014 11:51:21 +0200, Severin Gehwolf wrote: > >> I can only guess, but i386 updates being pushed to a x86_64 repo sounds >> like a bug to me. > > No, it's a pretty normal thing the mash multilib compose strategy does. > http://pkgs.fedoraproject.org/cgit/mash.git/tree/\ No, Java is exempt from multilib, see: https://fedorahosted.org/fesco/ticket/961 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: java-1.8.0-openjdk i686 and x86_64 rpms
On 04/23/2014 12:54 AM, Arun SAG wrote: > Hi, > > I see openjdk-1.8.0 got built and pushed as an update for fedora 19 > http://koji.fedoraproject.org/koji/buildinfo?buildID=505651 . > > > In the past the i686 rpms of openjdk were pushed into release x86_64 > repo of fedora 19 > (http://mirrors.kernel.org/fedora-enchilada/linux/releases/19/Everything/x86_64/os/Packages/j/) > , But with this particular update the i686 rpm never got pushed into > x86_64 repository > http://mirrors.kernel.org/fedora-enchilada/linux/updates/19/x86_64/ > > Any reason why it is not happening? Java packages don't support multilib for several reasons. Because of that Java has been granted an multibib exemption by FESCo [1]. 32-bit JVMs not appearing in 64-bit repos is an expected thing. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk [1] https://fedorahosted.org/fesco/ticket/961 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
log4j update in f21
Next week I am going to update log4j in rawhide from version 1.2 to version 2.0-rc1 [2]. 2.0 ships with a module providing limited 1.2 compatibility. For more info see [1]. List of 105 components which require or build-require log4j (and therefore are possibly affected by this update) follows. [1] http://logging.apache.org/log4j/2.x/manual/migration.html [2] http://bugzilla.redhat.com/982541 acegisecurity ambari amplab-tachyon ant apache-commons-configuration apache-commons-logging apacheds apacheds-shared apache-log4j-extras apache-mime4j apache-poi avalon-framework avalon-logkit axis axis2 azureus bookkeeper cas-client cobertura codenarc cxf eclipse-linuxtools eclipse-swtbot eclipse-wtp-sourceediting eclipse-wtp-webservices eucalyptus ezmorph findbugs-contrib freemarker freemind gemini-blueprint glite-lb-client-java gmetrics hadoop hawtbuf hawtdb hawtjni hbase hibernate hive infinispan jamonapi jasperreports java-uuid-generator jboss-logging jboss-logmanager-log4j jbossws-common-tools jbossws-cxf jdom2 jenkins jericho-html jets3t jexcelapi jglobus jgroups jgroups212 jilter json-lib littleproxy log4j-jboss-logmanager logback maven-doxia maven-javadoc-plugin mchange-commons mercury metrics mule mx4j mybatis narayana netty not-yet-commons-ssl oat olfs openid4java openjpa openshift-java-client ovirt-engine-sdk-java owasp-esapi-java pax-logging plexus-graph protostream proxool quartz seam-solder slf4j snmp4j solr spark springframework springframework-batch springframework-retry spring-ldap spymemcached thrift tomcat uima-addons velocity wise woden ws-jaxme xbean xml-security zanata-client zookeeper -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: log4j update in f21
On 05/05/2014 02:11 PM, punto...@libero.it wrote: > Il 05/05/2014 13:41, Mikolaj Izdebski ha scritto: >> Next week I am going to update log4j in rawhide from version 1.2 to >> version 2.0-rc1 [2]. >> >> 2.0 ships with a module providing limited 1.2 compatibility. >> For more info see [1]. >> >> List of 105 components which require or build-require log4j (and >> therefore are possibly affected by this update) follows. >> >> [1] http://logging.apache.org/log4j/2.x/manual/migration.html >> [2] http://bugzilla.redhat.com/982541 > hi > close my https://bugzilla.redhat.com/show_bug.cgi?id=1091036 log4j2 ? > some required build deps such as > org.eclipse.persistence:javax.persistence:2.1.0 JSR 338 (2.0.5 is JSR 317) > org.eclipse.persistence:org.eclipse.persistence.jpa:2.5.0 > broken compatibility with other libraries (e.g. springframework) I would suggest closing the review request and contributing to existing log4j package - help is always welcome. I would prefer to have version 2.0 as log4j and (if needed) we can create a compat package log4j12. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: [fedora-java] Mass-bug filing for removed OpenJDK 9 internal APIs
On 05/06/2014 02:00 PM, Florian Weimer wrote: > I plan to file bugs against packages which contain hard (i.e. not > reflection-based) references to internal OpenJDK classes and methods > which have been removed from OpenJDK 9. The total number of affected > packages is around 40. The bug reports will mention the recommended > replacements in the public API. > > This does not affect features like the support for pointer arithmetic > and arbitrary memory access, at least not until they are removed upstream. > > Comments? IMO go ahead, but please add them to some tracking bug. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: log4j update in f21
On 05/15/2014 06:30 PM, Florian Weimer wrote: > On 05/15/2014 06:14 PM, Michael Simacek wrote: >> I've updated log4j in rawhide today. >> >> The packages that are known to be broken by this update are: > > Have you rebuilt axis and slf4j? They take classes from log4j and copy > them into their RPMs. If they do then it's unintended. Can you report it with more details? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: log4j update in f21
On 05/16/2014 09:10 AM, Florian Weimer wrote: > On 05/16/2014 07:16 AM, Mikolaj Izdebski wrote: >> On 05/15/2014 06:30 PM, Florian Weimer wrote: >>> On 05/15/2014 06:14 PM, Michael Simacek wrote: >>>> I've updated log4j in rawhide today. >>>> >>>> The packages that are known to be broken by this update are: >>> >>> Have you rebuilt axis and slf4j? They take classes from log4j and copy >>> them into their RPMs. >> >> If they do then it's unintended. Can you report it with more details? > > I have filed bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=1098253 > https://bugzilla.redhat.com/show_bug.cgi?id=1098410 > Great, thank you. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Self Introduction: Christopher Tubbs
On 05/19/2014 07:51 PM, Christopher wrote: > Hi, > > My name is Christopher Tubbs. I'm a long-time user of Fedora and > Linux, and a big fan of free (as in speech) software. I love bigdata > and scientific computing, and consider myself a seasoned Java > developer and Maven user. Welcome! > I'm currently working on Apache Accumulo as my first package for > Fedora (https://fedoraproject.org/wiki/Changes/ApacheAccumulo). I'm > also an upstream developer for Accumulo project, which helps, because > there's a lot of patches I need to make to get it to build with the > dependency versions available in Fedora. > > I'm not yet in the package maintainers group, but my FAS account is > ctubbsii and I'm seeking a mentor (preferably one familiar with the > Hadoop ecosystem and Java packaging) to help me get all the kinks > worked out of my package. I'm still very new to the whole packaging > environment in Fedora, and trying to get a handle on understanding all > the infrastructure at Fedora needed to get things done. I definitely > need a mentor to help me understand the packaging process and tools in > the Fedora infrastructure (cgit, bugzilla, koji, etc.). If you need help feel free to ask on IRC (#fedora-java or #fedora-bigdata) or ping me directly. (I am usually the one people come to with Maven-related packaging questions.) For formal sponsorship into packager group just submit a rewiew request. I can sponsor you if no one else does. > My draft packaging is not yet done, but in progress here: > https://github.com/ctubbsii/accumulo-fedora (temporary) I had a quick look at the package and it looks good. There are some things that could be improved, but it's more a matter of style and best practices rather than correctness. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: [fedora-java] Hadoop + log4j2 = fullstop
On 05/21/2014 08:06 PM, Robert Rati wrote: > So, who needed log4j2? It is massively incompatible with log4j1.2 and > isn't a simple port job. I would argue if log4j2 was actually needed, > it should have been introduced as a separate log4j2 package and allow > projects to port to it as they have time/need. This update log4j to an > incompatible version with no compat package provided at the same time is > not the way to handle such an upgrade. Giving advanced notice that the > world will come crumbling down and you'll have to deal with it is not > enough. 1. This change was announced [1] in advance and I didn't hear any concerns from anyone until the change was implemented. hadoop and all other packages were mentioned in the announcement as possibly being affected by the update. 2. The original announcement [1] and follow-up messages contain some of the reasons for updating to 2.0. But there are other reasons as well -- log4j 2.0 was blocking mybatis package update [3]. 3. As I already said on IRC multiple times, I am going to introduce a compat package log4j12 before 6 Jun 2014. If that's too late then feel free to package it yourself. 4. I shared my general opinions about Java compat packages and update procedures on java-devel [2] and I didn't hear any concerns about them. Recent log4j update follows the procedure and best practices I presented there, like keeping the name log4j instead using log4j2. [1] https://lists.fedoraproject.org/pipermail/devel/2014-May/198934.html [2] https://lists.fedoraproject.org/pipermail/java-devel/2013-October/005000.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=1091042 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Rebuilds for Boost 1.55 mostly done
On 05/26/2014 05:11 PM, Petr Machata wrote: > * Maven-related: > > 6879292 bookkeeper > 6879822 zookeeper These look like missing BuildRequires on 'mvn(org.slf4j:slf4j-log4j12)' aka slf4j-log4j12. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Fedora 21 Mass rebuild update
On 06/09/2014 08:31 PM, Jerry James wrote: > Another source of Java build failures may be that the > javapackages-tools package is not self-consistent about where maven > dep fragments should live; see > https://bugzilla.redhat.com/show_bug.cgi?id=1106919. I believe that this is a documentation bug, not a defect in javapackages-tools code. I'll make sure that this is cleared up ASAP. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: F22 System Wide Change: Replace Yum With DNF
On 06/17/2014 09:40 PM, Dennis Gilmore wrote: > I am not away of any work to make mock use dnf. As part of GSoC Michael Simacek is working on improving mock. Among other features, DNF support is already implemented and working. More information can be found on his blog [1] (part of Fedora Planet). The code is hosted on [2], RPMs for latest development version can be found on Fedora Jenkins [3] (the RPM is renamed to xmock to allow parallel installation with mock from Fedora repos). [1] http://xpath-of-light.blogspot.cz/ [2] http://github.com/msimacek/mock [3] http://jenkins.cloud.fedoraproject.org/job/mock/ws/RPMS/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Fedora 21 Mass rebuild update
On 06/09/2014 09:03 PM, Mikolaj Izdebski wrote:
> On 06/09/2014 08:31 PM, Jerry James wrote:
>> Another source of Java build failures may be that the
>> javapackages-tools package is not self-consistent about where maven
>> dep fragments should live; see
>> https://bugzilla.redhat.com/show_bug.cgi?id=1106919.
>
> I believe that this is a documentation bug, not a defect in
> javapackages-tools code. I'll make sure that this is cleared up ASAP.
It turned out that our release script wasn't uploading the documentation
due to a problem with group permissions at fedorahosted.org [1], which
has just been fixed.
I have uploaded the new documentation. It contains a section [2]
describing migration from the legacy %{_mavendepmapfragdir} directory.
[1] https://fedorahosted.org/fedora-infrastructure/ticket/4410
[2]
https://fedorahosted.org/released/javapackages/doc/#_add_maven_depmap_macro_2
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
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: COPR down?
On 06/20/2014 02:11 PM, Heiko Adams wrote: > Hi, > just a short question: Is http://copr.fedoraproject.org/ down? Yes it is - planned outage. https://fedorahosted.org/fedora-infrastructure/ticket/4416 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Looking for co-maintainers
On 06/27/2014 09:45 AM, Simone Caronni wrote: > Hello, > > I'm looking for co-maintainers for the Guacamole [1] stack packages. It is > an HTML 5 plugin-less remote desktop for VNC, RDP, SSH, Telnet and Spice > (WIP). Upstream is really responsive, software is updated frequently and > it's really amazing. > > I've been able to throw a bunch of Citrix XenApp servers, Terminal servers > and all the corollary tools away with it. > > The software is split in the native server (guacamole-server) with relevant > plugins and a Java web application (guacamole-client) for the main > interface. > > The software is fantastic, but the Java part gives me a lof of headaches > everytime there is a Java packaging guidelines change or a Maven bug. If > any Java guru would like to step in as co-maintainer of Guacamole it's > really welcome. I already have too many packages, so I can't take any more. If you have any problems with Maven or feel free to ask on mailing list on or IRC. > Currently guacamole-client is in FTBFS in rawhide [2] and I couldn't find > any help for fixing it due to a Maven bug [3], that requires a specific > Fedora workaround that I frankly don't understand [4]. On RHEL 7, and > Fedora 19/20 the same packages build fine. I told you what to do on the mailing list. I've just tried the workaround and it worked. It's my mistake that I didn't reply to your second email, I probably missed it or forgot. In this case please just ping me, I'm always happy to help! The fix for the FTBFS was commited and it should be fixed soon. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?
On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote: > On 2014-06-26 11:17, Richard Hughes wrote: >> On 26 June 2014 17:02, Simone Caronni wrote: >>> +1 from me! >> >> If it's a trivial patch then I think it makes sense to just do it. >> From someone that touches hundreds of different projects every month, >> I've found it's better to ask forgiveness than permission :) > > As previously stated, that only works if you are a provenpackager. The > question is for those of us who are not, but are trying to help. There's always an option of finding a provenpackager willing to apply the patch. Example: In March Michael Simacek prepared over 400 patches and sent them to me in bulk. After review I applied them all. You can see the commits at [1] (look for "Use Requires: java-headless rebuild" threads). > As a newcomer to Fedora development, is there something else I should > doing to get these patches reviewed and committed? I offered you on IRC applying any patches for Java packages, as this is my area of expertise. I suggested either emailing them in bulk or following the procedure I use [2]. Have you considered this? [1] https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140324/thread.html [2] https://fedoraproject.org/wiki/User:Mizdebsk/HowToSubmitPatches -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Patches for trivial bugs sitting in bugzilla -> trivial patch policy?
On 06/27/2014 09:39 PM, Yaakov Selkowitz wrote: > On 2014-06-27 07:09, Mikolaj Izdebski wrote: >> On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote: >>> As a newcomer to Fedora development, is there something else I should >>> doing to get these patches reviewed and committed? >> >> I offered you on IRC applying any patches for Java packages, as this is >> my area of expertise. I suggested either emailing them in bulk or >> following the procedure I use [2]. Have you considered this? > > Thanks, I have Keyworded and CCd you on the Java bugs. I've reviewed all the patches, but only two of them were OK for me to apply. In case the patch was inappropriate or not good enough I have replied to the bug with the reason. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: how set InitialCC in pkgdb2 for new package
On 10/08/2015 06:11 PM, Pierre-Yves Chibon wrote: > On Thu, Oct 08, 2015 at 04:57:27PM +0200, Vít Ondruch wrote: >> Dne 8.10.2015 v 16:44 gil napsal(a): >>> hi >>> i missing somethings... >>> how can set InitialCC with java-sig in pkgdb for a new package? >>> regards >>> thanks in advance >>> gil >>> https://admin.fedoraproject.org/pkgdb/package/requests/476 >>> https://admin.fedoraproject.org/pkgdb/package/requests/477 >>> https://admin.fedoraproject.org/pkgdb/package/requests/479 >> >> https://github.com/fedora-infra/pkgdb2/issues/192 > > So the short answer is that it's not currently implemented because adding > another user/group once the package is in pkgdb, the basic steps are: > 1. Go to one of your package > 2. Click on: Manage the `committers/watchers/admins` any of these > 3. There is then an ``Add someone`` button you can use That's a lot of manual steps, especially if you need to add 3 or 4 users to all new packages you create, like in my case. But this can be easily scripted using pkgdb2 API (or with packagedb-cli tool). To make the whole process of adding new package scriptable, please consider implementing API for requesting new packages too: https://github.com/fedora-infra/pkgdb2/issues/239 > > There is currently a bug that's preventing pseudo-user (such as java-sig) from > being added to a package, but I already have the fix and it'll be > reviewed/merged/released asap :) FWIW, I successfully added java-sig to two of my packages yesterday using web UI: https://admin.fedoraproject.org/pkgdb/acl/$package/give/ -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Eclipse fedorapackager plugin and it's future
On 10/08/2015 02:24 PM, Aleksandar Kurtakov wrote: > Hi everyone, > Fedorapackager eclipse plugin has been neglected for quite some time and > updates are broken after the Bodhi2 update. > So are there any users left? Is anyone interested in maintaining it? > Enhancing it? > Any feedback is more than welcome as it might be time to let it rest in peace > if no interest. I don't regularly use eclipse-fedorapackager, but I have a few enhancements on my TODO list (and as always, lacking time to actually implement them). Most important feature I have in mind - support for Copr. Java API is already included in Copr upstream at [1]. Michael Simacek is (or was) working on the GUI part. I think that this feature could help new contributors who are not familiar with packaging tools, but want to create or customize packages and publish them in Copr. (This would be integrated with DevAssistant too.) [1] https://git.fedorahosted.org/cgit/copr.git/tree/java (Personally I don't care about Bodhi2 support too much - I submit updates only like once a month or so.) > > Alexander Kurtakov > Red Hat Eclipse team > -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Ownership of /usr/lib/rpm/fileattrs
On 10/30/2015 12:24 PM, Florian Festi wrote: > I moved the directory over in rawhide (rpm-4.13.0-0.rc1.8.fc24). It is > probably a bit late for F23. Shall I clone the bug for > javapackages-tools, rpm-mpi-hooks, supermin-devel to get them adjusted > or can you take care of them on your own? I have just fixed javapackages-tools upstream [1] by adding missing directory ownership. The change will propagate to rawhide with next upstream release. [1] https://github.com/mizdebsk/javapackages/commit/4cfed9e -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Ownership of /usr/lib/rpm/fileattrs
On 11/02/2015 11:43 PM, Orion Poplawski wrote: > On 11/02/2015 03:23 PM, Mikolaj Izdebski wrote: >> On 10/30/2015 12:24 PM, Florian Festi wrote: >>> I moved the directory over in rawhide (rpm-4.13.0-0.rc1.8.fc24). It is >>> probably a bit late for F23. Shall I clone the bug for >>> javapackages-tools, rpm-mpi-hooks, supermin-devel to get them adjusted >>> or can you take care of them on your own? >> >> I have just fixed javapackages-tools upstream [1] by adding missing >> directory ownership. The change will propagate to rawhide with next >> upstream release. >> >> [1] https://github.com/mizdebsk/javapackages/commit/4cfed9e >> > > I think you missed a bit of the point. There is no need to require rpm since > *everything* implicitly requires rpm, so there is no need to own those > directories. Initially I assumed so -- that's why javapackages-tools didn't own these directories. It only owned fileattrs directory, which was installed by rpm-build. Now I re-read packaging guidelines part about directory ownership [1], which implies that package installing file to directory not owned by filesystem or man packages should own the directory, unless it requires package owning the directory. I didn't find anything about implicit dependency on rpm. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Gradle Packaging
On 12/02/2015 09:16 PM, Dennis Chen wrote: > There are a couple of Java libraries that are built using the Gradle > system, which should have been incorporated in the F22 release. What is > the status of the use of Gradle in building packages for Fedora? It > seems that there are no macros specific to Gradle, and the Java > distribution guidelines rather outdated. For documentation how to use Gradle for packaging see: https://fedorahosted.org/released/javapackages/doc/#gradle (I've just updated it to reflect current state.) Note that Gradle packaging macros have been improved signifficantly in Fedora 23 and 24, and that the above documentation generally targets rawhide. The same documentation for released Fedoras can be found in /usr/share/doc/javapackages-tools-doc/index.html provided by javapackages-tools-doc package. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Automatically generating needed requires for julia
On 01/11/2016 11:48 PM, Orion Poplawski wrote:
> The julia language loads libraries at run time by using the .so filename. We
> work around this in the julia package by symlinking the needed sonames into
> %{_libdir}/julia/, e.g.:
>
> for lib in arpack cholmod dSFMT git2 fftw3_threads gmp mprf openlibm
> openspecfun pcr2-8 umfpack
> do
> soname=$(objdump -p %{_libdir}/lib${lib}.so | awk '$1 == "SONAME" { print
> $2}')
> ln -s ../${soname} %{buildroot}%{_libdir}/julia/lib${lib}.so
> done
>
> Now we want to automatically generate the needed rpm requires, e.g.:
>
> libarpack.so.2()(64bit)
>
> What I came up with is a rpm-julia-hooks package that julia would BR that
> would use rpm fileattrs to generate these. This feels a bit klunky having a
> separate package just to do this task.
>
> Does anyone else have any ideas?
Looks like you are trying to use a custom dependency generator in
addition to internal one. If it's for use in a single package then the
following solution should work:
%global _use_internal_dependency_generator 0
%global __find_requires %{SOURCE666} %{_rpmconfigdir}/find-requires
Source666: %{name}-find-requires.sh
Where julia-find-requires.sh should be a script that generates custom
requires (prints them to stdout) and then calls internal RPM dependency
generator (passed as $1).
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf dependency information for koji builds
On 01/25/2016 11:37 AM, Michael Schroeder wrote: > On Sat, Jan 23, 2016 at 04:26:43PM +0100, Dan Horák wrote: >> On Sat, 23 Jan 2016 08:14:44 -0700 >> Orion Poplawski wrote: >> >>> It would be very helpful to have information on what packages are >>> pulling in what dependencies in the root.log of koji builds. Is this >>> possible with dnf? >> >> I'm worried it's similar to the issue discussed in >> https://bugzilla.redhat.com/show_bug.cgi?id=1148627 where libsolv >> provides only the top level result. > > It's not libsolv that only provides the top level result. libsolv provides > all the needed data, it's dnf/hawkey that only displays the top level. > > Regarding the pulled in dependencies, libsolv also provides that, but > hawkey doesn't have an API for it (yet?). It is possible to reconstruct dependency graph from hawkey sack. (Koschei does that to compute "dependency distance" - minimal number of edges you need to traverse in order to get from SRPM to given build-dependency package. [1]) [1] https://github.com/msimacek/koschei/blob/fd48addd9f401889916dc7e58893bc563dcca909/koschei/util.py#L312 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: dnf dependency information for koji builds
On 01/23/2016 04:14 PM, Orion Poplawski wrote: > It would be very helpful to have information on what packages are > pulling in what dependencies in the root.log of koji builds. Is this > possible with dnf? I've quickly hacked a proof-of-concept script to do that: https://gist.github.com/mizdebsk/21e5fd776aa4ba577582 The script is ran with taskId of buildArch Koji task as argument. It should print on stdout list of packages in buildroot with dependency information. Each line of output is in form: A: B, C, D which means that package A pulled in packages B, C and D. The script can be easily adjusted to do more interesting stuff. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Xulrunner - intent to remove from Fedora 24
On 01/26/2016 01:59 PM, Josh Boyer wrote: > On Tue, Jan 26, 2016 at 7:51 AM, Martin Stransky wrote: >> Hi, >> >> does anyone use the xulrunner package? (and gecko-devel actually). Mozilla >> does not maintain it any more and the XUL as technology is going to be >> removed/deprecated. I'd like to remove the package from Fedora 24. > > A quick repoquery on rawhide (and f23) shows the following packages > require xulrunner: > > chatzilla-0:0.9.87-10.1450hg.fc23.noarch > chmsee-0:2.0.2-23.gitd40ff7da.fc24.x86_64 > esc-0:1.1.0-24.fc21.x86_64 > gecko-sharp2-0:0.13-29.fc23.x86_64 > nss-gui-0:0.3.10-20.fc24.x86_64 > pencil-0:2.0.5-3.fc23.noarch FWIW, my repoquery shows a few more packages requiring xulrunner in f24: chatzilla chmsee esc freewrl gecko-sharp2 gnash icedtea-web mediatomb nss-gui PackageKit pencil spice-xpi -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Rename Review Request swap
On 07/21/2013 04:00 PM, Simone Caronni wrote: > Anyone willing to review these 2 packages? > > https://bugzilla.redhat.com/show_bug.cgi?id=985818 > https://bugzilla.redhat.com/show_bug.cgi?id=985814 For Java-related reviews you are welcome to block Java SIG tracker bug (FE-JAVASIG, rhbz #652183). This way members of Java SIG can easily see that there is a new review and take care of it. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mesos Packaging
On 07/19/2013 09:14 PM, Tim St Clair wrote: > For folks who are watching, we are assisting the upstream Mesos > project(https://issues.apache.org/jira/browse/MESOS-543) and there is > interest from multiple parties to get the package and it's dependencies into > the Fedora &| EPEL channels. > > If you are interested, please feel free to ping me and we can coordinate, as > there is a fair amount to be done. If you need any help with the Java parts, feel free to contact me. There is no Maven in EPEL so the Java parts would need to be disabled in EPEL or built with a different build system (like Ant). -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphan cpptasks
On 08/10/2013 10:53 AM, punto...@libero.it wrote: > Il 10/08/2013 00:48, D Haley ha scritto: >> Dear List, >> >> I would like to orphan the cpptasks package, which is currently in use >> by gluegen and gluegen2. I do not have the time to maintain the >> package in its current state. >> >> cpptasks is currently affected by a FTBFS : >> https://bugzilla.redhat.com/show_bug.cgi?id=992092 >> >> The FTBFS is due to the deprecation of org.apache.xml.serialize. >> >> >> Thanks. > hi > rebuilt cpptask with XMvn > [INFO] --- xmvn-mojo:0.5.0:builddep (default-cli) @ cpptasks --- > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 13.176s > [INFO] Finished at: Sat Aug 10 10:51:48 CEST 2013 > [INFO] Final Memory: 63M/340M > [INFO] > > > strange which xerces-j2 version is available in rawhide, is the same in > f19? That FTBFS was probably caused by a bug [1] in ant, which should be fixed now, so now the build succeeds. [1] https://bugzilla.redhat.com/show_bug.cgi?id=994556 -- Mikolaj Izdebski IRC: mizdebsk -- 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: [Java package] add_to_maven_depmap macro issue
On 08/18/2013 07:03 AM, Ankur Sinha wrote: > Hi, > > One of my packages: dcm4che-test fails to build for rawhide currently. > There's a bug filed here[1]. The build.log seems to fail on the > "add_to_maven_depmap" macro. I think it doesn't find it at all[2]. Could > someone please tell me if I'm missing a BR or if the macros have > changed[3]? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=992114 > [2] http://ankursinha.fedorapeople.org/dcm4che-build.log > [3] > http://fedoraproject.org/wiki/Java/JPPMavenReadme#Packages_adding_their_own_depmaps %add_to_maven_depmap has been obsolete for long time and it was recently removed. See my announcements on java-devel [1,2]. -- Mikolaj Izdebski IRC: mizdebsk [1] https://lists.fedoraproject.org/pipermail/java-devel/2013-July/004834.html [2] https://lists.fedoraproject.org/pipermail/java-devel/2013-July/004863.html -- 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: Comps Cleanup
On 08/25/2013 01:17 AM, Till Maas wrote: > It seems that the following packages are stil mentioned in f20 or > f21 comps (I do not know which I checked) but are not in the i686 repo. > At least some of these packages are arch specific: > > ant-scripts ant-scripts fixed. Thanks, -- Mikolaj Izdebski -- 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: Corrupt repos and broken mockbuild ?
On 09/03/2013 09:38 AM, Krzysztof Daniel wrote: > Hello, > > while trying to build a rawhide package with fedpkg mockbuild I get: > [...] > Finishing delta rebuilds of 10 package(s) (3.4 M) > Some delta RPMs failed to download or rebuild. Retrying.. > http://ftp.ps.pl/pub/Linux/fedora-linux/development/rawhide/x86_64/os/Packages/a/acl-2.2.52-3.fc20.x86_64.rpm: > [Errno -1] Package does not match intended download. Suggestion: run yum > --enablerepo=fedora clean metadata > Trying other mirror. > [...] > > and then later > > Error downloading packages: > qrencode-libs-3.4.2-1.fc20.x86_64: [Errno 256] No more mirrors to try. > [...] > > yum clean all does not help. How can I get it working again? > You can try: # rm -rf /var/cache/mock This usually helps me in such cases. -- Mikolaj Izdebski IRC: mizdebsk -- 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: how to build a scratch build of an older version of my package ?
On 09/17/2013 09:30 PM, David Timms wrote: > In trying to track down when a bug began showing up, I'd like to build > an earlier version of my package eg from 9 months ago (hence earlier > upstream release and different spec/patches). How can that be achieved > on the builder ? koji build --scratch 'git://pkgs.fedoraproject.org/?#' You just need to substitute Koji target you want to build for, component (source package) name and git commit hash that you want to build. For example: koji build --scratch f19-candidate 'git://pkgs.fedoraproject.org/javapackages-tools?#4a755d42fa884cacdb373ac05c8b3b9e62751994' > Does the build system keep the build logs of old packages, ie that shows > what build requires-version was installed, and which gcc compiler > version was used ? Unreferenced builds are garbage collected, which means build logs will eventually be removed. -- Mikolaj Izdebski IRC: mizdebsk -- 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: gradle problem in f{19,20}
> groovy 2.x series (and other libraries) require gradle for build, but > with gradle there is a problem I tried to solve without success in f19 > and f20 (in f18 work fine :( ). > (the same happen when rebuild gradle in non bootstrap mode) > > gradle --debug jar javadoc -g > /builddir/build/BUILD/hibernate-release-4.1.7.Final/gradlehome -b > /builddir/build/BUILD/hibernate-release-4.1.7.Final/buildSrc/build.gradle > 10:28:52.228 [DEBUG] > [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished > configuring with level: DEBUG, configurers: > [org.gradle.logging.internal.OutputEventRenderer@14bd4d1, > org.gradle.logging.internal.slf4j.Slf4jLoggingConfigurer@180fd99, > org.gradle.logging.internal.JavaUtilLoggingConfigurer@18955ea] > 10:28:52.282 [ERROR] [org.gradle.BuildExceptionReporter] > 10:28:52.284 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build > aborted because of an internal error. > 10:28:52.287 [ERROR] [org.gradle.BuildExceptionReporter] > 10:28:52.288 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong: > 10:28:52.290 [ERROR] [org.gradle.BuildExceptionReporter] Build aborted > because of an unexpected internal error. Please file an issue at: > http://forums.gradle.org > the same using -S (--full-stacktrace) parameter. > any ideas? My ideas are: 1) Run gradle in a debugger and try to investigate what exactly is causing the problem; "unexpected internal error" is not helping much. 2) Check if the problem persists after replacing all dependencies with binary JARs used by upstream. If the issue is solved this way then you can try bisection method (replace half of dependencies, then quarter and so on, narrowing the possible cause of the problem). 3) Talk to the upstream. They surely know more about gradle internals and hopefully they will give you some advice how to fix the problem. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gradle problem in f{19,20}
On 04/22/2013 10:16 AM, gil wrote: >> 1) Run gradle in a debugger and try to investigate what exactly is >> causing the problem; "unexpected internal error" is not helping much. > already done And? Any results? >> 2) Check if the problem persists after replacing all dependencies with >> binary JARs used by upstream. If the issue is solved this way then you >> can try bisection method (replace half of dependencies, then quarter and >> so on, narrowing the possible cause of the problem). > i use f18 And what is your point? Does using F18 prevent you from trying the bisection method? It helped me solve several difficult cases. Besides that the message title says you are using F19/F20, so I'm a bit confused now. >> 3) Talk to the upstream. They surely know more about gradle internals >> and hopefully they will give you some advice how to fix the problem. >> > i applied a patch (#31) as suggested by A. Murdoc, gradle developer [1] > http://pkgs.fedoraproject.org/cgit/gradle.git/tree/gradle-1.0-printStackTrace.patch > > but dont work ... probably did something wrong ... Try changing the patch to print the stack trace even when failure is not instance of GradleException (i.e. uncomment line 13). -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-19 Branched report: 20130425 changes
On 04/25/2013 11:03 PM, Tom Callaway wrote: >> [gooddata-cl] >> gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java gdata-java has ben retired. Maintainer of ovirt-engine (lkundrak) is non-responsive. >> [kawa] >> 1:kawa-1.11-5.fc19.x86_64 requires servlet25 > > Java stuff. Not going to try to fix it, will let the Java SIG experts > handle this. Leaf package. Bug report (#819551) is open for 1 year, no response from maintainer. IMO candidate for removal. >> [maven-dependency-plugin] >> maven-dependency-plugin-2.7-1.fc19.noarch requires >> mvn(org.apache.commons:commons-io) > > Java stuff. Not going to try to fix it, will let the Java SIG experts > handle this. This has already been fixed in FEDORA-2013-6255 (currently still in testing). >> [ooo2gd] >> ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java Leaf package, orphaned. IMO candidate for removal. >> [ovirt-engine] >> ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires >> classpathx-mail Leaf package. This is a known issue (bug #914235), No response from maintainer. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Planning to retire java-service-wrapper
On 06/25/2013 04:59 PM, Miroslav Suchý wrote: > I plan to retire java-service-wrapper. I do not use it anymore. And it > need some time, which I do not have. > If you want to take over this package let me know. But rather then > taking over java-service-wrapper, it would be better to package > http://yajsw.sourceforge.net/ instead. java-service-wrapper is still used by other package. It's in dependency chain of JBoss AS. I can take the ownership. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koschei update
On 05/21/2016 12:28 AM, Kevin Fenzi wrote: > On Fri, 20 May 2016 09:10:58 -0600 > Orion Poplawski wrote: >> In some sense I think it's more important to be run for branched. >> Are the branched builds run against updates-testing? or only updates >> + overrides? I'm thinking it would be better if it was the former. > > I'm not sure koschei can do things differently here without additional > build targets. I think it has to do scratch builds against > base+stable+buildroot overrides just like any other build there would > do. Currently Koschei has to use a Koji build target, so unless a custom target is added, it is what Kevin said. But we are working on integration with Copr, which would allow things like that. You would create your own Copr project, add any repos you want and ask Koschei to run some builds there. You could build potentially-breaking builds in Copr first and have them tested, it would be possible to automatically test builds from upstream monitoring and so on. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unresponsive maintainer: asaf
On 05/30/2016 10:01 AM, gil wrote: > But until now I have not had any response from the maintainer, asaf > (Asaf Shakarchi a...@redhat.com ) . This email address seems to be inactive. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaning xmlrpc-c (critpath)
I don't have time to maintain xmlrpc-c, so I'm going to orphan it within next few weeks, unless someone volunteers to take it. Note that as a transitive dependency of Anaconda, xmlrpc-c is a "critical path package". -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning xmlrpc-c (critpath)
On 06/13/2016 10:35 AM, Igor Gnatenko wrote: > I will take it. Feel free to make me point of contact. Thanks, I've re-assigned the package in pkgdb. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: introduction toogley | packaging intellij idea
Hi Tobias, Welcome to Fedora. On 06/22/2016 05:21 PM, toog...@mailbox.org wrote: > * Are there some important documents I should additionally read? > > * Do you have some tips for starting packaging, or dealing with the legacy > status of the package? Java Packaging HOWTO mentioned by others is a good starting point. I would recommend you joining Java SIG [1], where you can find help with packaging, reviews, bugfixes etc. We have IRC channel and mailing list where you can communicate with us. [1] https://fedoraproject.org/wiki/SIGs/Java > * I'm used to gpg-sign my git commits/tags by default. Should I continue this > practice while packaging? I've read somewhere that some people don't want > that, therefore my question. We generally don't do that in Fedora. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Injecting perl-devel and perl-generators build-requires
On 06/23/2016 03:09 PM, Petr Pisar wrote: > Hello, > > per Build Root Without Perl Fedora 25 change > <https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl>, I'm ready to > implement the most visible part of this change. Good to to hear that. I've been using Perl-less buildroot in my personal mock config on daily basis for two years, no problems found. > I'm going to inject perl-devel and perl-generators build-requires into Fedora > specification files tomorrow. That's necessary not to break building the > packages when Perl will have been removed from the build root. Note that once perl-generators are removed from minimal bulidroot, Perl packages will start to fail in Koschei. This is because Koschei rebuilds package from latest SRPM, not from SCM. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Roman Vais
On 07/11/2016 10:35 AM, Roman Vais wrote: > Hello, > my name is Roman Vais and I am a new intern in the Java component > maintenance team > at Red Hat in Brno, Czech Republic. I'm 23, student at the Faculty of > Information Technologies > at Brno technical university. I am apologize for that my introduction comes > with tiny delay. > Looking forward to work with you all. Welcome to Fedora! I've just sponsored you. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Improvements of Fedora Sponsorship process
On 08/05/2016 10:31 AM, Parag Nemade wrote: >> b) fedora-review is run automatically by some bot/script just after review >> have been submitted. > > Can a new utility be written for this as I don't think that long > fedora-review output is helpful? Most checks have no markings in them. > How can it be helpful to package submitter? You can configure which fedora-review checks are ran, for example exclude any non-automated checks. >> c) Create wiki page with list of sponsors willing to accept new sponsoree. >> And list area of expertise of sponsors (e.g. java, python, IoT...). This >> will make for sponsoree easier to find right sponsor. Because we have some >> sponsors, who are active but are not willing to accept new sponsoree right >> now. > > This can be in addition to above, Why not run a script frequently and > check bugzilla and based on common naming CC the related SIG group? > e.g. if a package review is submitted whose name contains python then > add cc python SIG group that will notify actual group people and > someone can find interest and review the package. I know this is in > general suggestion but I suppose every SIG is also having some > Sponsors who can sponsor new contributor packages. This won't work for all SIGs. For example, Java packages don't have any common naming scheme. If you just search for "Java" in review requests, almost all results will be false-positives (eg. from "JavaScript") and you won't find most of relevant reviews this way. I think that wiki page could work for this purpose. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
