Re: Fedora 33 is available now!
Yeah we could have that done before the release, but that just means we'd have to update container build instructions in several places (and then remember to keep them updated after next Fedora releases or risk pulling old/EOL fedora images etc). Anyway - it was just a note that the image tags are not up to date now. On Tue 27 Oct 2020 11:21:05 AM -04 James Cassell wrote: > Latest still points to 32, but you can say 33 explicitly and get GA bits. > > On Tue, Oct 27, 2020, at 11:15 AM, Stanislav Ochotnicky wrote: >> On Tue 27 Oct 2020 09:57:40 AM -04 Matthew Miller wrote: >> > I'm happy to announce that Fedora 33 is here. Thank you to the >> > thousands of people who worked on this release in some way, and to all >> > of our community. Fedora 33 is made of bits, but the Fedora Project is >> > made of people, and you are all awesome. >> > >> > Read the official announcement at: >> > >> > * https://fedoramagazine.org/announcing-fedora-33/ >> > >> > or just go ahead and grab it from: >> > >> > * https://getfedora.org/ >> >> Seems that container images have not been updated yet? >> >> $ podman run --pull always -it registry.fedoraproject.org/fedora:latest >> Trying to pull registry.fedoraproject.org/fedora:latest... >> Getting image source signatures >> Copying blob 22cef3226003 [--] 0.0b / >> 0.0b >> Copying config e6b57c0d9f done >> Writing manifest to image destination >> Storing signatures >> [root@fb0f4ab6985f /]# cat /etc/fedora-release >> Fedora release 32 (Thirty Two) >> >> >> -- >> Stanislav Ochotnicky >> Software Engineer, Red Hat Product Security DevOps >> >> PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241 >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Stanislav Ochotnicky Software Engineer, Red Hat Product Security DevOps PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 is available now!
On Tue 27 Oct 2020 09:57:40 AM -04 Matthew Miller wrote: > I'm happy to announce that Fedora 33 is here. Thank you to the > thousands of people who worked on this release in some way, and to all > of our community. Fedora 33 is made of bits, but the Fedora Project is > made of people, and you are all awesome. > > Read the official announcement at: > > * https://fedoramagazine.org/announcing-fedora-33/ > > or just go ahead and grab it from: > > * https://getfedora.org/ Seems that container images have not been updated yet? $ podman run --pull always -it registry.fedoraproject.org/fedora:latest Trying to pull registry.fedoraproject.org/fedora:latest... Getting image source signatures Copying blob 22cef3226003 [--] 0.0b / 0.0b Copying config e6b57c0d9f done Writing manifest to image destination Storing signatures [root@fb0f4ab6985f /]# cat /etc/fedora-release Fedora release 32 (Thirty Two) -- Stanislav Ochotnicky Software Engineer, Red Hat Product Security DevOps PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote: > So you think having to send a request to a web service instead of just > parsing a string locally with one line of code is a good trade-off for > allowing dashes? This has been mentioned several times in this thread and I think there's a misunderstanding around this. So: When your tool/whatever works with modules it will have to have module metadata available in some form. In most client-side tools, I'd guess that will be modulemd metadata in dnf repositories that will get synced locally (just like rpm/yum repodata). Or it really might be you'll query koji for the metadata if needed on a system without local dnf metadata. But if you're working on top of module repositories - metadata will be there. RPMs *in* modules still use "N-V-R.A" strings and you can keep parsing them. That is not changing. But the module that contains them uses different strategy that allows maintainers more flexibility. And there does not have to be exact match between module/stream etc name and NVRs of rpms inside as others have mentioned. -- Stanislav Ochotnicky <sochotni...@redhat.com> Software Engineer, PnT DevOps - Brno PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241 Red Hat Inc. http://www.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for spec A producing package B
On Wed 20 Jul 2016 06:09:18 PM CEST Pete Zaitcev <zait...@redhat.com> wrote: > Greetings: > > I ended up trying to make a source package foo produce foo-server and > python-foo, and it's not working: no matter what I do, some files are > left unpackaged. So, does anyone know of a package doing this? > > The longer story is that we have openstack-swift (although it's moved > to RDO now, it's principally a Fedora package). It produced > openstack-swift (the main package with most of the code), > openstack-swift-proxy, openstack-swift-account, and other. At a certain > point, Haikel asked me to make it so the code is in python-swift. It is > a style of packaging that many OpenStack packages observe, e.g. you get > python-manila, python-nova, etc. However, there's a difference. All of > them have functional "main package", too, such as openstack-manila in case > of Manila. But in Swift, the main package ends empty. Literally, no > files, no Requires. So, I was trying to get rid of openstack-swift, > and it's failing. > > I guess I'd be okay with an explanation why it's not allowed and why > I have to leave a stub RPM with the same name as the spec/SRPM. But it > would be the best if someone has an example that I can steal. First a working example: http://pkgs.fedoraproject.org/cgit/rpms/python-beanbag.git/tree/python-beanbag.spec Basically no %files section without "-n ". That means no "main rpm" will get created. And explanation: It's not about allowing something - if you are not packaging something you installed in the buildroot then rpmbuild will yell. Either put it in that python-swift package *or* do not put it in the buildroot. -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: licensecheck split-off from devscripts-minimal
On Tue 05 Jul 2016 09:12:19 AM CEST Sandro Mani <manisan...@gmail.com> wrote: > On 05.07.2016 03:30, Dennis Gilmore wrote: >> Hey Sandro, >> >> What exactly does licensecheck do? and how is it different to the procject at >> https://sourceforge.net/projects/oslc/ I ask because I would like to have us >> implement something to check licensing when people upload tarballs to >> lookaside cache and report when licenses change. >> >> Dennis > Hi Dennis > licensecheck simply scans files for license headers and prints out the > detected license for each file (it is used by fedora-review for > instance). I suppose the perl library introduced with the new > licensecheck package offers some flexibility for third-party use. I > don't know oslc, but it doesn't seem to be actively maintained? Nah, I'd summarize it differently: licensecheck is a glorified grep oslc (and https://pagure.io/muster) use proper algorithms and a "database" of full license texts and headers to provide much better matching accuracy. -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bugzilla "Fedora Components" group
On Thu 25 Feb 2016 08:04:44 PM CET "Richard W.M. Jones" <rjo...@redhat.com> wrote: > On Thu, Feb 25, 2016 at 07:54:57PM +0100, Stanislav Ochotnicky wrote: >> On Thu 25 Feb 2016 06:22:26 PM CET Kevin Fenzi <ke...@scrye.com> wrote: >> > On Thu, 25 Feb 2016 18:00:09 +0100 >> > Stanislav Ochotnicky <sochotni...@redhat.com> wrote: >> > >> >> On Thu 25 Feb 2016 04:42:34 PM CET Kevin Fenzi wrote: >> >> > On Thu, 25 Feb 2016 15:35:55 + >> >> > "Richard W.M. Jones" <rjo...@redhat.com> wrote: >> >> > >> >> >> Kevin, do you have a reference to this ticket? This still hasn't >> >> >> been resolved and at this rate I'm going to have to clone the bug >> >> >> to get rid of the unwanted group. >> >> > >> >> > I'll mail you privately. They closed my ticket wontfix. ;( >> >> >> >> Well it wasn't exactly won't fix - seems like a misunderstanding/lost >> >> in translation thing. I'll escalate and get it resolved ASAP >> > >> > Yeah, might be I didn't explain things well enough. >> > >> > Anyhow, many thanks for taking care of this. :) >> >> This is now resolved, the group was removed (and at least I can see the >> bug). Do let me know if this is still an issue though. > > Yes it's fixed now, thanks! > > Rich. We've also identified a root cause - misconfigured Bugzilla groups that were not supposed to be visible/available to be set for bugs. Folks in our team will have a look so this doesn't happen again. -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bugzilla "Fedora Components" group
On Thu 25 Feb 2016 06:22:26 PM CET Kevin Fenzi <ke...@scrye.com> wrote: > On Thu, 25 Feb 2016 18:00:09 +0100 > Stanislav Ochotnicky <sochotni...@redhat.com> wrote: > >> On Thu 25 Feb 2016 04:42:34 PM CET Kevin Fenzi wrote: >> > On Thu, 25 Feb 2016 15:35:55 + >> > "Richard W.M. Jones" <rjo...@redhat.com> wrote: >> > >> >> Kevin, do you have a reference to this ticket? This still hasn't >> >> been resolved and at this rate I'm going to have to clone the bug >> >> to get rid of the unwanted group. >> > >> > I'll mail you privately. They closed my ticket wontfix. ;( >> >> Well it wasn't exactly won't fix - seems like a misunderstanding/lost >> in translation thing. I'll escalate and get it resolved ASAP > > Yeah, might be I didn't explain things well enough. > > Anyhow, many thanks for taking care of this. :) This is now resolved, the group was removed (and at least I can see the bug). Do let me know if this is still an issue though. -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bugzilla "Fedora Components" group
On Thu 25 Feb 2016 04:42:34 PM CET Kevin Fenzi wrote: > On Thu, 25 Feb 2016 15:35:55 + > "Richard W.M. Jones" <rjo...@redhat.com> wrote: > >> Kevin, do you have a reference to this ticket? This still hasn't been >> resolved and at this rate I'm going to have to clone the bug to get >> rid of the unwanted group. > > I'll mail you privately. They closed my ticket wontfix. ;( Well it wasn't exactly won't fix - seems like a misunderstanding/lost in translation thing. I'll escalate and get it resolved ASAP -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: In A World Where...TCs don't exist?
On Fri 29 Jan 2016 02:51:31 PM CET Richard W.M. Jones wrote: > On Fri, Jan 29, 2016 at 04:33:19AM -0800, Adam Williamson wrote: >> Hi, folks! I thought this might be about the appropriate time to throw >> this out there. >> >> There hasn't been a big news press on this, but some of you may know >> that releng is fairly close to switching over to Pungi 4 for composes. >> For those of you who don't know: >> >> releng is fairly close to switching over to Pungi 4 for composes. > [...] > > Any chance you can publish metadata for these releases? ie. this 2 > year old request: > > https://fedorahosted.org/rel-eng/ticket/5805 > > We're in the awkward situation now where OpenSUSE and Ubuntu publish > machine-readable metadata, but Fedora does not (or if it now does, > please point me to it so we can start using it). > > Many people would test the cloud images and test their software on > cloud images if they could do: > > $ virt-builder fedora-rawhide > $ virt-builder fedora-nightly-MMDD > > or whatever to get them. I think you might be looking for something like this? https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-/compose/metadata/ See the files in the directory for details, be aware the rpm one is huge though :-) -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF is completly unable to act with local packages
On Sat 07 Nov 2015 10:18:14 AM EST Panu Matilainen <pmati...@laiskiainen.org> wrote: > Frankly I didn't even realize the 0.rc1.X scheme was against the > guidelines since to me this is the (obviously) correct way to do it with > predictable pre-release names (its predictable when you're the one doing > the upstream tarballs), where the versioning goes like this: > > 0.beta1.1 > 0.beta1.2 > 0.beta1.3 > 0.beta2.1 > 0.beta2.2 > 0.rc1.1 > 0.rc1.2 > [...] > 0.rc1.5 > 0.rc2.1 > 1 (for the final) Above relies on rpm to sort b before r. It also assumes as others have mentioned that you don't have an emergency situation where you need to do one-off in the middle. > The scheme in guidelines of course works no matter what wacko > names-of-pet-ponies versions upstream tarballs may have, but to me its > "wrong" in the sense the release number doesn't get reset between > version changes. By "version" you are talking the upstream beta/rc etc labels right? Because you certainly can and should reset the release number on version changes. > Not that I'm defending going against the guidelines or > arguing for changing it (I'm way too old to get involved in THAT again), > just explaining where this particular offense in case of rpm probably > originates from. Feel free to consider it as an apology for setting a > bad example. Meh, you are not the first nor the last. It's just that we (rightfully?) hold package managers to higher standards -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: [RFC] DistGit Container Image namespacing for Layered Image Build Service
On Fri 13 Nov 2015 06:34:21 PM EST Adam Miller <maxamill...@fedoraproject.org> wrote: >> 4. package level docker files are maintained by the same people who maintain >> the package. >> > > This certainly makes sense if we end up going the package:container 1:1 route. This assumption is not correct IMO. One docker image generally provides some functionality that can be used in different ways. It might be OK for basic httpd/mysql/postgres setup but I think inevitably you'll have people who will want to provide more usable/complete docker image which will have all of them integrated without need of involving Kubernetes or similar technologies. -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: redhat bugzilla probs
tl;dr: bz is back up and root cause has been identified and fixed (for this outage type at least) Update from admin team: Bugzilla has been brought back up. OOM crashes in the database have been traced to a specific query which was thought to be causing problems in previous incidents due to a missing table. The removal of that data error allowed this query to run and was causing the services to fault. The data error has been reintroduced as a blocking mechanism to restore service. On Tue 29 Sep 2015 04:33:42 AM CEST Ralf Corsepius <rc040...@freenet.de> wrote: > On 09/21/2015 03:38 PM, Ralf Corsepius wrote: >> Hi, >> >> When trying to file a BZ, bugzilla just greeter me with this: >> >> >> Proxy Error >> >> The proxy server received an invalid response from an upstream server. >> The proxy server could not handle the request POST /post_bug.cgi. >> >> Reason: Error reading from remote server >> >> Apache Server at bugzilla.redhat.com Port 443 >> > > Right now, it is happening, again - Same error as last week: > > > Proxy Error > > The proxy server received an invalid response from an upstream server. > The proxy server could not handle the request POST /show_bug.cgi. > > Reason: Error reading from remote server > > Apache Server at bugzilla.redhat.com Port 443 > > > Ralf > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: redhat bugzilla probs
People are already looking into it. Standby On Mon 21 Sep 2015 03:49:03 PM CEST Sandro Bonazzola wrote: > On Mon, Sep 21, 2015 at 3:38 PM, Ralf Corsepius <rc040...@freenet.de> wrote: > >> Hi, >> >> When trying to file a BZ, bugzilla just greeter me with this: >> >> >> Proxy Error >> >> The proxy server received an invalid response from an upstream server. >> The proxy server could not handle the request POST /post_bug.cgi. >> >> Reason: Error reading from remote server >> >> Apache Server at bugzilla.redhat.com Port 443 >> >> >> > Same here > > >> Ralf >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stanislav Ochotnicky <sochotni...@redhat.com> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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-legal-list] [RFC] Switching to SPDX in license tags
On Thu 09 Jul 2015 03:36:54 PM CEST Richard Fontana wrote: On Thu, Jul 09, 2015 at 03:22:41PM +0200, Haïkel wrote: 2015-07-09 15:17 GMT+02:00 Miro Hrončok mhron...@redhat.com: On 9.7.2015 14:48, Haïkel wrote: * mass changing all specs = could be automated Actually, openSUSE has a tool for this: https://github.com/openSUSE/spec-cleaner It can convert their old license abbrevs to SPDX, I don't know if we are using the same ones, but the data set can be changed of course. The point I made earlier (wasn't posted to devel@) was that the SPDX abbreviations are not equivalents of the abbreviations in use by Fedora. MIT is used in Fedora and in SPDX, but they do not mean the same thing. MPLv1.1 in Fedora is not equivalent to MPL-1.0 or whatever in SPDX. So what is the point of adopting a different abbreviation system if the meaning of the underlying referenced things or concepts is not the same? Can you elaborate a bit on the MIT(Fedora) != MIT(SPDX)? Is the SPDX text of MIT different from what we'd consider MIT in Fedora? One difference I can see is that SPDX defines canonical text of the license where Fedora lumps several texts[1] into 1 short name. Without looking too much into SPDX license list - would some of the licenses we currently consider MIT fall under different license name under SPDX? [1] https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Issue with fedora-packager, mock and python
Please update to latest version On Fri 23 Jan 2015 03:33:51 PM CET Carlos Morel-Riquelme wrote: Hi folks, i try to run fedora packager over spec and src.rpm files before created, but i always have this error: [empateinfinito@localhost review]$ fedora-review --mock-config fedora-rawhide-x86_64 -n ssr INFO: Processing local files: ssr INFO: Getting .spec and .srpm Urls from : Local files in /home/empateinfinito/review INFO: -- SRPM url: file:///home/empateinfinito/review/ssr-0.3.2-1.fc21.src.rpm INFO: -- Spec url: file:///home/empateinfinito/review/ssr.spec INFO: Using review directory: /home/empateinfinito/review/review-ssr RPM version 4.12.0.1 Copyright (C) 1998-2002 - Red Hat, Inc. This program may be freely redistributed under the terms of the GNU GPL Usage: rpm [-afgpcdLlsiv?] [-a|--all] [-f|--file] [-g|--group] [-p|--package] [--pkgid] [--hdrid] [--triggeredby] [--whatrequires] [--whatprovides] [--nomanifest] [-c|--configfiles] [-d|--docfiles] [-L|--licensefiles] [--dump] [-l|--list] [--queryformat=QUERYFORMAT] [-s|--state] [--nofiledigest] [--nofiles] [--nodeps] [--noscript] [--allfiles] [--allmatches] [--badreloc] [-e|--erase=package+] [--excludedocs] [--excludepath=path] [--force] [-F|--freshen=packagefile+] [-h|--hash] [--ignorearch] [--ignoreos] [--ignoresize] [-i|--install] [--justdb] [--nodeps] [--nofiledigest] [--nocontexts] [--noorder] [--noscripts] [--notriggers] [--oldpackage] [--percent] [--prefix=dir] [--relocate=old=new] [--replacefiles] [--replacepkgs] [--test] [-U|--upgrade=packagefile+] [--reinstall=packagefile+] [-D|--define='MACRO EXPR'] [--undefine=MACRO] [-E|--eval='EXPR'] [--macros=FILE:...] [--noplugins] [--nodigest] [--nosignature] [--rcfile=FILE:...] [-r|--root=ROOT] [--dbpath=DIRECTORY] [--querytags] [--showrc] [--quiet] [-v|--verbose] [--version] [-?|--help] [--usage] [--scripts] [--setperms] [--setugids] [--conflicts] [--obsoletes] [--provides] [--requires] [--recommends] [--suggests] [--supplements] [--enhances] [--info] [--changelog] [--xml] [--triggers] [--last] [--dupes] [--filesbypkg] [--fileclass] [--filecolor] [--fscontext] [--fileprovide] [--filerequire] [--filecaps] ERROR: Exception down the road...(logs in /home/empateinfinito/.cache/fedora-review.log) [empateinfinito@localhost review]$ I try with this commands but the error it's the same. - fedora-review -n foo - fedora-review --mock-config fedora-rawhide-x86_64 -n foo - fedora-review --rpm-spec -n path/foo.src.rpm the fedora-review.log is here http://fpaste.org/173567/23391142/ And info app [empateinfinito@localhost review]$ rpm -qa |grep -i fedora-review fedora-review-0.5.2-1.fc21.noarch [empateinfinito@localhost review]$ rpm -qa |grep -i mock mock-1.2.4-1.fc21.noarch [empateinfinito@localhost review]$ I hope this info can be usefull, Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services (HSS) PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Remove gcc, gcc-c++ and make from minimal build root
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote: Vít Ondruch wrote: I'd like to collect some feedback about the $SUBJECT, i.e. making minimal build root really minimal, explicitly specifying build dependencies, etc. -1, all the serious software requires gcc, gcc-c++ and make to build. I actually think that cmake should be added to the minimal build root, instead of removing stuff. Almost all the packages I work on BuildRequire cmake (which also implies that they need make to build, and gcc-c++ is the typical implementation language). Yes good idea. I worked on Java packages. Let's put Maven in minimal buildroot. I am sure everyone will enjoy it. Sorry for the sarcasm. Couldn't resist :-) Seriously though what's a problem with listing your package's real build requires? -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services (HSS) PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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 vs yum
On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote: Hi On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote: Yes, switch the defaults ASAP. Thanks FWIW, there is still considerable work left is switching over to dnf completely. Filtering out some minor details (based on my system), Bodhi-client, fedpkg, python-meh, libreport-python, yum-utils depends on yum and yum-utils itself is a dependency for fedora-review, lpf and mock. FWIW fedora-review only requires yum-utils and that's only for repoquery. Based on a quick glance at dnf repoquery module there are a few things missing that we are using with repoquery: * -C (use cache only) * --resolve (resolves to packages that provide required symbols) We also run 'yum makecache' so before all actual repoquery commands (that's why we then use cache). This might not be needed with dnf since it usually caches yum metadata and doesn't redownload on every query. Dnf repoquery also behaves differently than yum-utils repoquery. For example: $ repoquery --requires python libc.so.6(GLIBC_2.0) libdl.so.2 libm.so.6 libpthread.so.0 libpython2.7.so.1.0 libutil.so.1 python-libs(x86-32) = 2.7.5-14.fc20 rtld(GNU_HASH) libc.so.6(GLIBC_2.2.5)(64bit) libdl.so.2()(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libpython2.7.so.1.0()(64bit) libutil.so.1()(64bit) python-libs(x86-64) = 2.7.5-14.fc20 rtld(GNU_HASH) $ dnf repoquery --requires python rtld(GNU_HASH) libm.so.6 libpthread.so.0 libdl.so.2 libutil.so.1 libpython2.7.so.1.0 libc.so.6(GLIBC_2.0) python-libs(x86-32) = 2.7.5-9.fc20 rtld(GNU_HASH) libm.so.6()(64bit) libpthread.so.0()(64bit) libdl.so.2()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libpython2.7.so.1.0()(64bit) libutil.so.1()(64bit) python-libs(x86-64) = 2.7.5-9.fc20 rtld(GNU_HASH) libm.so.6 libpthread.so.0 libdl.so.2 libutil.so.1 libpython2.7.so.1.0 libc.so.6(GLIBC_2.0) python-libs(x86-32) = 2.7.5-14.fc20 rtld(GNU_HASH) libm.so.6()(64bit) libpthread.so.0()(64bit) libdl.so.2()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libutil.so.1()(64bit) libpython2.7.so.1.0()(64bit) python-libs(x86-64) = 2.7.5-14.fc20 No idea why it's this way though. -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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 vs yum
On Fri 24 Oct 2014 04:27:37 PM CEST Tim Lauridsen wrote: On Fri Oct 24 2014 at 4:01:20 PM Stanislav Ochotnicky sochotni...@redhat.com wrote: On Fri 24 Oct 2014 02:26:37 PM CEST Rahul Sundaram wrote: Hi On Fri, Oct 24, 2014 at 7:58 AM, Vít Ondruch wrote: Yes, switch the defaults ASAP. Thanks FWIW, there is still considerable work left is switching over to dnf completely. Filtering out some minor details (based on my system), Bodhi-client, fedpkg, python-meh, libreport-python, yum-utils depends on yum and yum-utils itself is a dependency for fedora-review, lpf and mock. FWIW fedora-review only requires yum-utils and that's only for repoquery. Based on a quick glance at dnf repoquery module there are a few things missing that we are using with repoquery: * -C (use cache only) dnf repoquery can use standard dnf cmd option, so -C/--cacheonly can be used. Ah, right my bad. But really...this will likely not be needed. * --resolve (resolves to packages that provide required symbols) Not implemented in dnf repoquery yet, please open an RFE against dnf-plugins-core, with your usecase and I will look into it. https://bugzilla.redhat.com/show_bug.cgi?id=1156487 Thought we should really switch to actually use dnf api instead. Things get complicated for us when we want to support EL6 then...Maybe we should just drop EPEL6 support. We also run 'yum makecache' so before all actual repoquery commands (that's why we then use cache). This might not be needed with dnf since it usually caches yum metadata and doesn't redownload on every query. Dnf repoquery also behaves differently than yum-utils repoquery. For example: $ repoquery --requires python libc.so.6(GLIBC_2.0) libdl.so.2 libm.so.6 libpthread.so.0 libpython2.7.so.1.0 libutil.so.1 python-libs(x86-32) = 2.7.5-14.fc20 rtld(GNU_HASH) libc.so.6(GLIBC_2.2.5)(64bit) libdl.so.2()(64bit) libm.so.6()(64bit) libpthread.so.0()(64bit) libpython2.7.so.1.0()(64bit) libutil.so.1()(64bit) python-libs(x86-64) = 2.7.5-14.fc20 rtld(GNU_HASH) $ dnf repoquery --requires python rtld(GNU_HASH) libm.so.6 libpthread.so.0 libdl.so.2 libutil.so.1 libpython2.7.so.1.0 libc.so.6(GLIBC_2.0) python-libs(x86-32) = 2.7.5-9.fc20 rtld(GNU_HASH) libm.so.6()(64bit) libpthread.so.0()(64bit) libdl.so.2()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libpython2.7.so.1.0()(64bit) libutil.so.1()(64bit) python-libs(x86-64) = 2.7.5-9.fc20 rtld(GNU_HASH) libm.so.6 libpthread.so.0 libdl.so.2 libutil.so.1 libpython2.7.so.1.0 libc.so.6(GLIBC_2.0) python-libs(x86-32) = 2.7.5-14.fc20 rtld(GNU_HASH) libm.so.6()(64bit) libpthread.so.0()(64bit) libdl.so.2()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libutil.so.1()(64bit) libpython2.7.so.1.0()(64bit) python-libs(x86-64) = 2.7.5-14.fc20 Can reproduce this repoquery and dnf repoquery show the same for me https://docs.google.com/spreadsheets/d/1WwlO3Is0psbBuJrIY_fVOjWeF5Pi5PI5Ekiy1raUjbs/edit?usp=sharing For me 2.7.5-9.fc20 is from fedora/20 repo and python-2.7.5-14.fc20 is from updates/20. F21 doesn't have updates so maybe that's the reason why your results look OK? -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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 vs yum
On Fri 24 Oct 2014 05:35:00 PM CEST Matthew Miller wrote: On Fri, Oct 24, 2014 at 04:56:20PM +0200, Stanislav Ochotnicky wrote: Thought we should really switch to actually use dnf api instead. Things get complicated for us when we want to support EL6 then...Maybe we should just drop EPEL6 support. Drop as in use yum for that, but dnf for the new versions? That sounds reasonable. Well reality is f-r is mostly for checking *current* Fedora guidelines that in some cases apply only to rawhide. If someone is running f-r on a system from 4 years ago to verify current packaging guidelines I'd question their knowledge of the guidelines :-) It's not impossible to do...I just wonder about cost/value proposition of keeping the support and spending even more time on it. -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: [pkgdb] Call for beta-testers for group maintainership
On Tue 07 Oct 2014 01:50:46 PM CEST Pierre-Yves Chibon wrote: On Mon, Oct 06, 2014 at 04:43:53PM -0400, Rich Mattes wrote: On Mon, Oct 6, 2014 at 12:04 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: Dear all, A long desired and awaited feature for pkgdb2 is the possibility to have FAS groups maintain packages. Hooray!A Thanks for this, I'm going to start testing it with the robotics-sig FAS group and some of my packages. Awesome! I put together some instructions on the requirements and steps: http://pkgdb2.readthedocs.org/en/latest/groups.html I followed the above instructions to update the FAS group, but I have a question about one of the requirements.A The instructions say that the mailing list for the group needs to have a rhbz account.A As far as I know bugzilla sends a confirmation email during the account creation process.A This seems kind of iffy when the email address is for a public list: should I just create the account and try to be the first list subscriber to click the confirmation link?A Or is there another way to create a bugzilla account for SIG mailing lists? That's a good question. I guess I approached with the idea that the list would be new as well. So eventually, you would be the only one subscribed to it and thus the question is simple(r) to answer. But for the case of an existing list, I wonder if we can do better than what you describe. @Kevin any thoughts on this? This is normally done by sending an email to bugzilla-reque...@redhat.com and requesting creation of pseudo user with email being the mailing list. Of course there would be no real control over this pseudo user. -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Attempting to contact two unresponsive maintainers - dajt and jpacner
On Thu 04 Sep 2014 01:35:53 PM CEST Pierre-Yves Chibon wrote: On Thu, Sep 04, 2014 at 11:38:52AM +0200, Tomasz Torcz wrote: On Thu, Sep 04, 2014 at 11:35:43AM +0200, Johannes Lips wrote: On Wed, Sep 3, 2014 at 10:44 PM, Kevin Fenzi ke...@scrye.com wrote: Greetings, we've been told that the email addresses for two package maintainers are no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. Hi all, wouldn't it make sense to integrate a check into the processes, when people leave Redhat, that the packages in fedora are properly orphaned or get a new owner? Why would even someone's employment status matter? Fedora is a community project. And much like anyone else, people come and go. The difference is that here, when they leave, we know about it before emails start to bounce. Indeed. I have forwarded this thread to colleagues working on processes when people are leaving RH to make sure we do necessary checks/cleanups. Note that we don't want to automatically orphan packages when people from RH leave (that would be rude) since people actually do work on stuff outside of their work... -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: problem with koji
On Wed 13 Aug 2014 01:46:53 PM CEST Stefan Ringel wrote: Am 13.08.2014 um 13:42 schrieb Dan Horák: On Wed, 13 Aug 2014 13:33:27 +0200 Stefan Ringel linu...@stefanringel.de wrote: Am 13.08.2014 um 10:43 schrieb Tomasz Torcz: On Wed, Aug 13, 2014 at 10:36:18AM +0200, Stefan Ringel wrote: Can anybody help me? I have: ActionNotAllowed: policy violation (build_from_srpm) IIRC, only --scratch build are allowed from SRPMs. other problem: koji -d add-pkg --owner=stefanringel rawhide gstreamer1-rtsp-server successfully connected to hub Traceback (most recent call last): File /usr/bin/koji, line 6245, in module rv = locals()[command].__call__(options, session, args) File /usr/bin/koji, line 791, in handle_add_pkg session.packageListAdd(tag,package,options.owner,**opts) File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1555, in __call__ return self.__func(self.__name,args,opts) File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1917, in _callMethod raise err koji.ActionNotAllowed: policy violation (package_list) release engineering maintains the list of packages based on the finished package reviews, why are you trying to add a package? Dan because that a package is required (gstreamer1-rtsp-server version =1.4.0) for build gnome-dvb-daemon version 0.2.90 . Have you other ideas? Uhmmm...how about this: http://fedoraproject.org/wiki/Package_Review_Process Or more probably this: https://fedoraproject.org/wiki/PackageMaintainers/Join -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpmSiIB9uMJz.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Call for testers for FMN
On Thu 17 Jul 2014 04:22:59 PM CEST Pierre-Yves Chibon wrote: There are several advantages to FMN, among them: * a central place to get/manage your notifications for all the Fedora systems (bodhi, badges, pkgdb...) * the possibility to choose which notifications to get where, for example - IRC notification upon successful build on koji - Email notification for failed build on koji - Some day, push to android devices * the possibility to send the notifications as batch, for example: - wait 10 minutes after the first pkgdb action and then send me all the pkgdb notifications This way if someone asks for 3 ACLs on 2 packages within 10 minutes, you will only receive one notification * from an infrastructure developer point of view: less code duplication I already shared my views on FMN during devconf but basically this is the best thing since sliced bread. Thank you Ralph, Pierre whoever else was involved in making it a reality. It's one of those things that just makes me thing: Why the hell haven't we done this ages ago? :-) -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpe07IZmFOLe.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Cross-distro fossology instance?
I was wondering if anyone was considering cross-distribution fossology[1] instance where we could share burden of license review with other distros. I know at least Debian does comprehensive license reviews and we could possibly deduplicate a lot of review time this way. Note that I am not talking about doing whole package reviews in fossology, just hooking up the license checking part there. It's likely we'd need to clean up fossology a bit to be universally usable for this use case, but it should be doable. Opinions, suggestions...all welcome. [1] http://fossology.org/ -- Stanislav Ochotnicky sochotni...@redhat.com Business System Analyst, Hosted and Shared Services PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Make fails with fedora build options set
On Thu 01 May 2014 01:34:43 PM CEST Jon Kent wrote:
Hi,
I'm trying to get a GnuBatch package into Fedora, which is currently
being reviewed. One of the points raised in the review was that I was
running make without any Fedora options. I've added these as requested
so the make line now looks like:
make %{?_smp_mflags} CFLAGS=%{optflags} BINDIR=%{_bindir}
This expands out to :
make -j4 CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic BINDIR=/usr/bin
However with these options the build is now failing where is was working
fine before using just make. The errors are related to being unable to
find the header files (i.e. config.h). I've tried added -I option
pointing to the header directory but this did not help.
What I don't understand is why this worked before, where as with these
make options set the build now fails. Any pointers much appreciated as
I'm just going in circles here trying to resolve this problem.
The below is an part of the output I get when this fails:
make[4]: Entering directory
`/home/jon/rpmbuild/BUILD/gnubatch-1.10/util'
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -c -o helpparse.o helpparse.c
helpparse.c:18:20: fatal error: config.h: No such file or directory
#include config.h
Another (relatively common) problem is the parallelization (-j4)
tripping the makefile up. I.e. dependencies for some targets are
incomplete and config.h is not yet generated when they execute.
--
Stanislav Ochotnicky sochotni...@redhat.com
Business System Analyst, Hosted and Shared Services
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
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 and Playground plugin part of dnf-plugins-core?
On Fri 25 Apr 2014 06:47:10 AM CEST Tim Lauridsen wrote: I have started a new dnf-utils project for commuty plugins/addons there is not maintain by the core dnf team https://github.com/timlau/dnf-utils copr / playground is welcome here is the core dnf developers, think its dont fit into dnf-plugins.core It is not submitted as a fedora package yet, but that will happen soon Tim Pretty please no. There's currently yum-utils package that contains various utilities (such as repoquery and more). I assume eventually dnf will get official dnf-utils containing ported versions of these tools. Unless you aim to provide dnf-compatible tools from yum-utils please rename the project. (not a DNF dev, but it seems quite obvious this is a bad idea long-term) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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 most of my packages
I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * plotutils * python-gudev * python-icalendar * python-webdav-library * freemind -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpos11L87hEO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
[snip] I know little to nothing about java bindings so if it is
substantial work I will just remove the java binding and ask rel eng to
pull the subpackage.
You can't just pull packages. You'll have to properly Obsoletes:
lasso-java it. I am attaching a patch which worked for me (including a
scratchbuild with openjdk). I haven't actually tested the code, but I
guess it should work (it's JNI though so...meh)
A side note: I believe we generally start release numbering at 1 instead
of 0, but of course it doesn't hurt anything...
pgp5kMEDIZEET.pgp
Description: PGP signature
From ef5fd12e46974858b25c2aa032e943514a0bf921 Mon Sep 17 00:00:00 2001
From: Stanislav Ochotnicky sochotni...@redhat.com
Date: Mon, 14 Apr 2014 09:42:19 +0200
Subject: [PATCH] Use OpenJDK instead of GCJ for java bindings
---
lasso.spec | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lasso.spec b/lasso.spec
index e96e39b..d060cf0 100644
--- a/lasso.spec
+++ b/lasso.spec
@@ -11,7 +11,7 @@
Summary: Liberty Alliance Single Sign On
Name: lasso
Version: 2.4.0
-Release: 0%{?dist}
+Release: 1%{?dist}
License: GPLv2+
Group: System Environment/Libraries
Source: https://dev.entrouvert.org/attachments/download/3874/lasso-2.4.0.tar.gz
@@ -55,8 +55,10 @@ Perl language bindings for the lasso (Liberty Alliance Single Sign On) library.
%package java
Summary: Liberty Alliance Single Sign On (lasso) Java bindings
Group: Development/Libraries
-BuildRequires: java-devel, jpackage-utils
-Requires: jre-gcj, jpackage-utils
+BuildRequires: java-devel
+BuildRequires: jpackage-utils
+Requires: java
+Requires: jpackage-utils
Requires: %{name}%{?_isa} = %{version}-%{release}
%description java
@@ -197,6 +199,9 @@ rm -fr %{buildroot}%{_defaultdocdir}/%{name}
%endif
%changelog
+* Mon Apr 14 2014 Stanislav Ochotnicky sochotni...@redhat.com - 2.4.0-1
+- Use OpenJDK instead of GCJ for java bindings
+
* Sat Jan 11 2014 Simo Sorce s...@redhat.com 2.4.0-0
- Update to final 2.4.0 version
- Drop all patches, they are now included in 2.4.0
--
1.9.0
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
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
On Mon 14 Apr 2014 10:24:46 AM CEST Mat Booth wrote: On 14 April 2014 08:44, Stanislav Ochotnicky sochotni...@redhat.com wrote: On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote: [snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage. You can't just pull packages. You'll have to properly Obsoletes: lasso-java it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh) Not Requires: java-headless ? Haha, you are right. I am violating guidelines I myself proposed :-) A -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpJ2aJH7ilE7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Java 8
On Wed 26 Mar 2014 05:29:55 PM CET Christopher wrote: On Wed, Mar 26, 2014 at 9:31 AM, Deepak Bhole dbh...@redhat.com wrote: * Christopher ctubb...@apache.org [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. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpkSBGT2nF57.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Java 8
On Wed 26 Mar 2014 01:19:52 PM CET Matthew Miller wrote: On Tue, Mar 25, 2014 at 07:59:13PM -0400, Christopher wrote: 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. This sounds like a situation where a Software Collection might be useful. Doesn't make sense IMO, JDKs can already live in parallel as they are. That's not to say that SCLs could not be used, but traditionally we have different solution and migrating to SCLs would likely bring its own set of problems. Actually as far as runtime is concerned, JDK is one of the most backward-compat tested software on Earth (most likely). The only applications that break are the ones that use internal implementation details or some *really* weird approaches. For building, you can still generate code for older JVMs with JDK8. Of course those JVMs will likely not be able to run at least part of our Java stack but that's another thing... If Atlassian suite breaks: it's most likely their bug. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpRreTU1USjl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Optional Javadocs
On Tue 18 Mar 2014 07:03:31 PM CET Miloslav Trmač wrote: 2014-03-18 15:31 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: Optional Javadocs = https://fedoraproject.org/wiki/Changes/OptionalJavadocs I suppose shipping API documentation for end-user applications really doesn't make sense. Any reasonably-widely-used library should contain off-line documentation, if at all possible, IMHO. Well as-of-this-moment-current guidelines actually mandate API documentation even for end-user apps so there's room for improvement :-) Release Notes Javadoc subpackages have been made optional. Made optional is true from the packaging guidelines' point of view; for the users, some subpackages have simply been *removed*, and there's nothing optional about that. You have a point, I'll rephrase that -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpB8lkBISoS3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Optional Javadocs
On Tue 18 Mar 2014 04:07:40 PM CET Omair Majid oma...@redhat.com wrote: * Jaroslav Reznik jrez...@redhat.com [2014-03-18 10:38]: Initial testing showed 80% build failure rate due to OpenJDK 8 update. This is caused by a change in the default doclint settings used by OpenJDK 8. Think '-Wall -Werror' for those more familiar with gcc. We can patch OpenJDK 8 in Fedora to change the default to be more lenient. This would be a deviation from upstream (and people might be surprised when proprietary builds of Java exhibit different behaviour). If this is the main/driving motivation behind this Change (and not slow ARM boxes) please consider that fixing OpenJDK 8 is an option. Lint is not the only reason really. Building javadocs is *really* painful on arm (where most java builds end up these days). It's more in the line of effort/gain calculation. There are very few javadoc users (most people will just look up documentation online). Quite important thing is our javadocs were never top-notch in the first place. There is missing interlinking, sometimes javadoc builds didn't finish (due to OOM) but builds succeeded and nobody actually noticed. We also ship API for end-user applications (freemind) which really *doesn't* make sense. This change really has two goals: * Give maintainers option to decide if javadocs make sense (from their POV) for their package * Communicate this change to users -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpOL1Va9OgGo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: java headless
On Thu 06 Mar 2014 12:58:46 AM CET Sérgio Basto wrote: Hi , is java-headless, jre (Java Runtime Environment) ? if not, what is the difference ? . Headless is a subset of full JRE without support for some graphical operations, sound etc (i.e. desktop features that are usually useless on servers or other headless machines). -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpbAUvYY9l2j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages with missing %check
On Wed 05 Mar 2014 11:23:23 AM CET Alexander Todorov wrote: На 4.03.2014 20:36, Mat Booth написа: On 25 February 2014 11:19, Mikolaj Izdebski mizde...@redhat.com wrote: On 02/25/2014 11:45 AM, Alexander Todorov wrote: 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. Agreed, it seems like busy work to me that adds very little value to anyone familiar with Java packages. You are forgetting everyone that is not so familiar with Java. Why are you filing bugs (with patches) you don't understand then? Have you asked *anybody* to help you out with exclusions? Have you gotten in touch with Java|Perl|PythonX|Y|Z SIG and ask for their assistance in better identification of testsuites and if they are being run? You are putting cart before the horse rushing the whole mass bug filing process without understanding consequences. You are going to be ignored. Your bugs are going to get closed/wontfix. You are going to get annoyed. You are not going to achieve much (if anything). Also I didn't ask you (as a package owner) to do it explicitly, I've asked you to accept a patch which should be much more easier. Patch which contains text which you haven't verified is correct. Quoting: +%check +# tests are executed during %build + How do *you* *know* they are executed during build? Do you even know how to recognize a difference between following: ant dist test javadoc ant dist javadoc ant jar %mvn_build %mvn_build -f %mvn_build -Dtestnotmatchpattern=\* %mvn_build -- -Dmaven.test.skip=true mvn-rpmbuild -Dmaven.test.failure.ignore=true ... Hint: Except %mvn_build and ant dist test javadoc these executions most likely don't run tests or if they do they ignore the failures Wouldn't it be easier to change the whatever tool is generating this report to accommodate for this? If package invokes %mvn_build then don't expect there to be a %check section seems like a reasonable heuristic to me. See https://bugzilla.redhat.com/show_bug.cgi?id=1072417#c4 to avoid repeating myself. Even if the tool uses heuristics to exclude some groups of packages it will not be obvious why there's no %check section. It could be because tests are executed in %build, because they need root or network access and are disabled, because the test framework used is not available (see DHCP) or anything else. Right, so your patches are basically worthless and you are planning to file possibly hundreds of bugs where maintainers will most likely manually close as WONTFIX/NOTABUG because it's clear to anyone working in their respective SIG what's happening there. A small comment makes it much more clear and straight forward. I want my packages to run tests. If there are tests upstream but I am not running them, sure there should be a comment or even better a FutureFeature bug to fix the testsuite. We are mostly doing all of this in Java SIG packages. Adding useless comment to spec files is not the way to improve things. If you want to improve stuff then focus on identifying packages which should run tests but don't. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgp2sQjD4Apqb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages with missing %check
On Wed 05 Mar 2014 03:57:17 PM CET Alexander Todorov wrote: На 5.03.2014 14:12, Stanislav Ochotnicky написа: Why are you filing bugs (with patches) you don't understand then? This is a foolish statement to make without knowing what I do and don't know or understand. That's the whole point though. Several people from Java SIG feel the same way about those patches... Patch which contains text which you haven't verified is correct. Quoting: +%check +# tests are executed during %build + How do *you* *know* they are executed during build? FYI, first I got a list of possible packages which have their tests run in %build from mizdebsk, then I inspected them and built them *by hand* to verify that was indeed correct (e.g. apache-commons-codec, apache-comons-logging, python-blivet, python-urlgrabber, etc.) So you are filing bugs for components which *are* running tests. Is it so weird that we consider that a non-issue while we have possibly hundreds of packages which are not running tests at all? If you find a patch which is incorrect (that is not running the test suite properly or stating an invalid comment) point me to it and I will work to update it. Every single patch is incorrect due to one problem: $ rpmlint apache-commons-codec.spec apache-commons-codec.spec:58: W: macro-in-comment %build 0 packages and 1 specfiles checked; 0 errors, 1 warnings. Sure it's a minor thing, but I'd hope as a QA guy you might appreciate the irony. Putting that aside, I've always worked with one though when working on Java packaging (quoting Exupéry) [snip] perfection is attained not when there is nothing more to add, but when there is nothing more to remove. I am yet to see a convincing argument for empty %check sections improving Fedora either for users or developers. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgptGz_tNt3hs.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Java headless bugs
Ville Skyttä ville.sky...@iki.fi writes: On Tue, Feb 25, 2014 at 10:59 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Since javadoc subpackages put files in /usr/share/javadoc they must require package that provides this directory. In my opinion all javadocs should be crosslinked with local JDK's javadocs (+ others as appropriate) and have a dependency on java-javadoc. The JDK -javadoc packages could either own the /usr/share/javadoc or have a dependency on a package providing it. Two problems solved... Actually we are strongly considering getting rid of javadocs completely[1] mostly due to Java 8 problems. We might be able to leave them be perhaps, but it's just a lot of work with uncertain benefits/users and it's slowing down builds considerably. Email on java-devel explains this in more detail. [1] https://lists.fedoraproject.org/pipermail/java-devel/2014-February/005133.html -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpiO_3R_Kmdb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages with missing %check
Adam Williamson awill...@redhat.com writes: On Tue, 2014-02-25 at 18:35 -0800, Andrew Lutomirski wrote: Just to mention: there are probably many packages where the equivalent of %check can't be run without access to a source tree, so Taskotron can't usefully replace %check. I maintain a package like that. How do you get from that premise to that conclusion? We know where the source tree is... Because unit tests are designed to be run as part of the build process. It's not impossible to run them *after* the build, but good luck making it work reliably across all packages without manual work. As I see it: * %check (or equivalent) is for unit testing * taskotron (or equivalent) is integration testing Each has its own value -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpLEfxjTmhYR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages with missing %check
On Wed 26 Feb 2014 01:41:36 PM CET Colin Walters wrote: On Wed, Feb 26, 2014 at 5:01 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Because unit tests are designed to be run as part of the build process. It's not impossible to run them *after* the build, but good luck making it work reliably across all packages without manual work. The https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests initative, as implemented by gnome-continuous, takes these unit tests as you call them and runs them as what you call integration tests. I didn't name them. I used standard names for different testing levels as defined by software engineering bodies. Quoting from SWEBOK: Software testing is usually performed at different levels along the development and maintenance processes. That is to say, the target of the test can vary: a single module, a group of such modules (related by purpose, use, behavior, or structure), or a whole system. Three big test stages can be conceptually distinguished, namely Unit, Integration, and System. No process model is implied, nor are any of those three stages assumed to have greater importance than the other two. (Personally, I think distinguishing them is a broken idea. No one runs just one bit of software, they run a tree - a complete system) Your personal opinion goes against what best practices of software engineering have been for at least past decade. Perhaps you'll not hold it against me if I am going to dismissive about your personal opinion in this case. For example, after glib changes, I rerun the *gtk* tests. After gtk changes, I rerun *application* tests. During making glib changes you should run glib unit tests to have some basic level of assurance you didn't introduce regressions or unwanted changes. After that you can run integration/system tests to ensure that gtk or application tests still pass. Simply put unit, integration and system tests are run during different phases of development or maintenance. This simple change of taking existing valuable tests that were run at once most per build and turning them into something run 50 or more times a day made them much more valuable. It also revealed many of them were full of race conditions... It's great that your change helped with discovering issues but perhaps your original testsuite was mixing different levels of testing in the same code. Unit tests are supposed to be quick, dirty solutions using mock objects and other hacks to allow of testing with small granularity. I could probably go on but this would quickly become off topic for fedora-devel and there's tons of literature on introduction to software testing. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpn6rJr9Pjhx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Java headless bugs
Richard Fearn richardfe...@gmail.com writes: Slightly off-topic: fedora-review is telling packagers NOT to add Requires: jpackage-utils to javadoc subpackages because that is added automatically, but I see no mention of this on https://fedoraproject.org/wiki/Packaging:Java. Guidelines state that package must have R: jpackage-utils because it contains filesystem (/usr/share/javadoc directory). Where does it say that? I can see this bit: Java binary packages or their dependencies MUST have Requires (generated by RPM or manual) on: * java-headless or java-headless = 1:minimal_required_version * jpackage-utils but that doesn't seem to apply to -javadoc subpackages. It's actually part of generic guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership Quoting: Packages must own all directories they put files in, except for:[snip] Since javadoc subpackages put files in /usr/share/javadoc they must require package that provides this directory. I guess it wouldn't hurt to repeat this in Java guidelines separately. Next guideline iteration I guess... -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpdaktdZCY35.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Java headless bugs
Jerry James loganje...@gmail.com writes: I've got a few comments and questions about the recently filed bugs asking us to switch from Requires: java to Requires: java-headless. First, the bugs list some web pages to view for more information. Number two on that list is this: https://fedoraproject.org/wiki/Packaging:Java\#BuildRequires_and_Requires which has a really unfortunate backslash in it. People clicking on that link get a sorry, no such page message from the web server. It should have been this: https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires Yup, my bad. I guess this was added automatically when I was copy-pasting from wiki where I was preparing the message. The tracking bug has correct link at least... Second, the bugs talk about this as a proposed guidelines change, yet https://fedoraproject.org/wiki/Packaging:Java now talks about it. Doesn't that mean that this is an official guideline, not a proposed change to the official gudelines? I believe you misread it: See tracking bug #1067528 or Headless Java change proposal[1] and Java Packaging guidelines[2] for more details about this change. The work proposal was wrt Headless Java change. Fedora doesn't usually require immediate change to all packages in repositories with each guideline change. However for Headless Java change to have any effect most packages have to migrate. I re-read the bugs and I don't see how it could be read as proposed guidelines change. I had a few people read the messages before filing the bug and it seemed to be OK as well. In any case, yes the official guideline is prefer java-headless if your library/app can use it. Sorry for the confusion. Third, developers are offered two options in those bugs: (1) don't do anything and an automatic tool will make the change for you on or after March 17, or (2) make the change to java-headless yourself. I have one package for which I need a third option: tell the automated tool that this bug was filed in error, the package really doesn't work with java-headless, and don't touch the package. I realize that I can mark the bug as assigned and leave it open indefinitely, but I'd rather have some option for closing the bug, please. Quoting from the bugreport: Automated tool will not touch bugs that are not in NEW state. If you close the bug (whatever reason) the automated tool will not touch your package(s). I guess I should have added close as valid way to avoid it. Slightly off-topic: fedora-review is telling packagers NOT to add Requires: jpackage-utils to javadoc subpackages because that is added automatically, but I see no mention of this on https://fedoraproject.org/wiki/Packaging:Java. Guidelines state that package must have R: jpackage-utils because it contains filesystem (/usr/share/javadoc directory). If the requires is generated automatically all the better but that's not the guidelines scope IMO. I don't see this as much of a problem. Guidelines are there to ensure packages have proper requires. Tooling can improve faster than guidelines. It's not breaking anything and f-r is a guidance tool. It's not guaranteed to comply with guidelines 100%, maintainers should know guidelines in any case and behave appropriately :-) Basically it boils down to understanding why some f-r check fails. We try to point out potential improvements/fixes and sometimes the suggestions might be incorrect. For example if you wanted to keep the same package on EPEL6 and Fedora where EPEL6 wouldn't generate the jpackage-utils requires. Hope this clears up everything, if not drop by #fedora-java IRC -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpxle4fqp5VR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software
Petr Pisar ppi...@redhat.com writes: On 2014-02-12, Michael Scherer m...@zarb.org wrote: Le mercredi 12 février 2014 à 07:11 -0500, Matthew Miller a écrit : On Wed, Feb 12, 2014 at 12:08:20PM +, Petr Pisar wrote: Are there any existing packages that already do that? vim advertises ICCF to make a donation for children in Uganda. Even leaving aside the whole charity / good cause vs. selling consumer goods aspect, I think a message about donations buried in the help is also a completely different case. On Fedora, it is in the help. On Debian, it is directly on the start when you open a empty file. So I am not sure which one is the default, there is no obvious patchs to enable or disable it in our packages and on Debian side. Maybe out-dated localization. I can see the text at welcome screen in cs_CZ.UTF-8 locale in Fedora, although there is nothing like that in en_US.UTF-8 locale. It's actually a bit more fun. Part of welcome screen is randomized :-) Alternating text: 1. Become a registered Vim user! 2. Sponsor Vim development! 3. Help poor children in Uganda! With pointers for each alternative -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpZ7rPN7eiJZ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
Miroslav Suchý msu...@redhat.com writes: On 02/05/2014 11:40 AM, Richard Hughes wrote: For stuff like this, I think just getting a provenpackager to fix up the packages is the best thing to do. It's obviously correct and a simple change. Usually yes. But e.g. in rhn-client-tools this path is used in code and the change is non-trivial. It was similar in javapackages-tools. It included a change in documentation which would have most likely been missed by eager provenpackager and maintainers could just ignore a closed bug so this wouldn't have been fixed... Generally filing those 42 (yay, what a nice number) bugs would have been better IMO, but if you are willing to re-run that repoquery in a few months and file bugs for remaining packages I see no harm. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpXDPd_2OdUR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
Ville Skyttä ville.sky...@iki.fi writes: sochotni javapackages-tools java-sig,mizdebsk,msimacek,msrb Fixed in upstream git, will be in next release -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpf3tZnV3NGT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nightly builds of DNF available
Radek Holy rh...@redhat.com writes: I have just added the metadata creation. Good point, thank you. Another thing worth mentioning: The release tags of those rpms are incorrect. Instead of: dnf-0.4.12-1.git3584018.fc20 It should be: dnf-0.4.12-0.1.git3584018.fc20 That way when 0.4.12 is actually released the dnf-0.4.12-1 will be higher than those older nightlies. By that time the nightlies should have higher version so no problems there either. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpID_W4jIXHS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Another questionable dependency chain -- libreoffice-writer installs log4j-chainsaw
Aleksandar Kurtakov akurt...@redhat.com writes: - Original Message - From: Richard Hughes hughsi...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, January 30, 2014 1:28:12 PM Subject: Re: Another questionable dependency chain -- libreoffice-writer installs log4j-chainsaw On 30 January 2014 11:17, Aleksandar Kurtakov akurt...@redhat.com wrote: Clarification the actual chain is java-headless-rhino-jline-jansi-hawtjni-xbean-avalon-framework-log4j Ahh, thanks for working that one out. Java isn't my area of expertise. It's time to prune such things out of the distro. So what can we prune for F21? Does xbean actually require avalon-framework -- or does hawtjni actually need xbean? etc.. Second thought - Fedora 21 makes OpenJDK 1.8 default which should have nashorn as a replacement for rhino and we can get rid of rhino from the openjdk deps. Mikolaj has been testing JDK 8 these past few weeks and the results don't seem encouraging for us. There are *a ton* of compilation failures, mostly in javadocs. I am not saying this is not doable, but it will involve *a lot* of work in any case. One blasphemous suggestion was to just get rid of javadoc generation :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpzbWfEUR5Bu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20: Puppet depchain pulls in Java
Bill Nottingham nott...@redhat.com writes: Martin Langhoff (martin.langh...@gmail.com) said: Puppet (the client side, at least) should be installable with relatively thin deps, so it can manage lightweight hosts... I am having trouble disentangling which deps to file a bug against; maybe virt-what ? You need to make sure your transaction is pulling in classic ruby rather than jruby. # repoquery -q --whatprovides ruby(runtime_executable) jruby-0:1.7.2-5.fc20.noarch ruby-0:2.0.0.353-16.fc20.i686 ruby-0:2.0.0.353-16.fc20.x86_64 I am pretty sure this bug is related: https://bugzilla.redhat.com/show_bug.cgi?id=910093 Yes, filed almost a year ago. Yes there was no single reply except automated one. The problem is the resolver. Let's say there are 2 packages: Package A has Provides: ruby = 1.9 Package B has Provides: ruby = 2.0 You are installing package C, some dependency has Requires: ruby so the resolver pulls in Package A because it provides that dependency. Then it goes deeper in the dependency tree and something else has Requires: ruby = 2.0 so the resolver pull in Package B. Now you have both installed even though only Package B is needed. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgp9SmqDrr7UP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 18 End of Life
Matthew Miller mat...@fedoraproject.org writes: On Thu, Jan 16, 2014 at 09:16:44AM +0100, Miroslav Suchy wrote: While the last option is probably best, I'm not sure if this is worth the effort. How many people will appreciate having archived old repos? If someone else uses GPLed binaries from a COPR repo and fulfills their source obligations by pointing to the repository we host, it's technically their problem if our repository goes away, but it would be a friendly gesture to at least keep the source RPMs around. The thing is those copr repos will likely depend on EOLed Fedora repos. Do we keep *those* around? I guess the answer will be different for each mirror. Some will keep those repos for longer, some shorter. But as you say, source RPMs might be nice to have at least. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpDE4LnU8mmf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mechanism to retain system library versions
Quoting Neal Becker (2013-12-18 14:06:23) During the past few months, I've switched from building my software against a bundled version of boost libraries, to building against the system boost libs. On updating to f20, all of my software became broken, because the library versions it was linked with were removed. So I had to race to rebuild all my software, and hope nothing broke when rebuilt. I think this situation is unfortunate. We do have library versioning, so different versions could coexist. How do others solve this problem, or can anyone think of a solution? So what would you have us (Fedora maintainers) do? Keep a separate version of library for each API version? How many versions? Which libraries? When do we clean up old versions? How do we clean them up? If you package your software in RPM you will get errors about missing requires immediately during update. If you don't ... well you are not following best practices for software management for your platform so all bets are off. It would be possible to write a tool that would check library versions in some repos and scan current system for binaries that would be broken by updating to that repo. With my Fedora hat on, I personally don't care much about software that is not packaged (at least in RPM if not Fedora) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: really stop really commits (really!)
Quoting Lukas Zapletal (2013-12-17 11:41:29) On Mon, Dec 16, 2013 at 03:10:08AM -0700, T.C. Hollingsworth wrote: I do commit locally although I probably don't want push the snapshot sources, because I update them later, when time comes. +1 This should happen rarely enough that having to use `git commit --no-verify` to bypass it wouldn't be too much trouble? I am all for these kinds of checks and I appreciate your effort. These are all good ideas, but please let's do not do this on the git level. This is not appropriate place when we already have a nice layer for this kinds of tests: fedpkg. I am sure I won't be the only one who doesn't use fedpkg for git manipulation (commit, push, pull etc). So higher level will not work because by the time I get to fedpkg build it's already too late. Every time a maintainer want to build a package using fedpkg, we can add this kind of hooks and verify what is necessary in the similar form you recommend (with the option to skip). Let's build a new command fedpkg check to do explicit checks as well which can help when fixing those mistakes. Just out of curiosity: How many times have you run fedpkg lint? Zero? Once to see what it does? The whole point of the hook was so that you wouldn't forget to run appropriate commands. Adding another will make the problem worse, not better We do not want to get to the state when packages being committed are automatically being built in koji (using git hooks). Because what you recommend here effectively leads to this happy ending - you might unintentionally seed this kind of approach. I was already there and believe me - this is not what we want to do. :) Hold your horses -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fedora-review 0.5.1 released
This is mostly a bugfix release, solving issues with mock in F20 (bz#1028332) and several other check problems. Thanks goes again to Alec for tirelessly working on improving f-r. Feel free to test the updates[1,2,3,4] News: - Added framework for moving plugins out of the fedora-review source tree; the java plugin is now external. This feature is still experimental. - Hide some tests when they are not applicable (#229). - Fix a bug in make_dist (#228). - Added stub plugins for Ocaml and Haskell allowing static linkage (#220, #221). - Add a fonts plugin running repo-fonts-audit (#215). - Enhance systemd config files handling (#214, #193). - Update CheckStaticLibs to current GL (#222). - CheckStaticLibs: fix typo causing false positives (bz 1012873). - Added new XML report designed for batch testing( #197). - Fixed a bad bug where deprecations was honored in non-applicable shell tests (498fa464b). - Make paths in licensecheck.txt relative to source dir (ee29d7e). - Handle inconsistent yum caches (bz #1028332). - Fix some EPEL5 glitches (bz #1040353, bz #1040369). - Add command line option to koji-download-scratch (bz #1027616). fedora-review developers maintainers [1] https://admin.fedoraproject.org/updates/FEDORA-2013-23402 (F18) [2] https://admin.fedoraproject.org/updates/FEDORA-2013-23423 (F19) [3] https://admin.fedoraproject.org/updates/FEDORA-2013-23340 (F20) [4] https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12371 (EL6) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide report: 20131126 changes - papi auto builds
Quoting Lukas Berk (2013-11-28 16:51:37) Hey, * Orion Poplawski or...@cora.nwra.com [2013-11-27 11:28]: On 11/26/2013 03:13 AM, Fedora Rawhide Report wrote: Compose started at Tue Nov 26 05:15:08 UTC 2013 Broken deps for i386 -- [openmpi] openmpi-1.7.3-1.fc21.i686 requires libpapi.so.5.2.0.0 Broken deps for x86_64 -- [openmpi] openmpi-1.7.3-1.fc21.i686 requires libpapi.so.5.2.0.0 openmpi-1.7.3-1.fc21.x86_64 requires libpapi.so.5.2.0.0()(64bit) papi-5.2.0-2.1.gff3e15d.fc21 * Mon Nov 25 2013 Lukas Berk lb...@redhat.com - 5.2.0-2.1.gff3e15d - Automated weekly rawhide release This strikes me as not a very good idea. We've now apparently tripped into early 5.3.0 territory without any warning. Provides libpapi.so.5.3.0.0()(64bit) Please don't. Sorry about the unintended breakage. I'm pushing a fix back to 5.2 in rawhide now. In the future, how would you like to coordinate future papi releases when the so version does need to be bumped? Generally, following Updates Policy[1] should be enough I'd say [1] https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Toshio Kuratomi (2013-11-20 22:46:32) On Wed, Nov 20, 2013 at 01:39:48PM -0500, Aleksandar Kurtakov wrote: The thing is this is pointless. If the people that would do most of this auditing (Java SIG) do not agree with such scenario the result would be that old Require:java will be kept whenever full java jvm is used as this keeps compatibility, ease of cooperation with other distros and so on. Angle 2) Reduce the benefits of the second virtual provide - Propose alternate means of tracking what packages have been audited and found to actually need full java. - If the target is mainly new maintainers of the package in question, then Requiring that Requires: java have a comment in the spec file to say that the package really does need the graphical portions of java to be installed may be sufficient. - If the target is to keep an updated list of what packages are yet to be audited, propose something like Virtual Provide in the packages that depend on java. So if you have java-foo that Requires: java and you have audited the package to know that the requirement is real, add Provides: java-x11-needed to the package. Then scripts can take the set of packages that Require java and do not Provide java-x11-needed to generate an up to date list. As Alex said, nobody is going to audit 800 packages if maintainers don't care enough to verify. In theory your let's audit 800 packages is good idea. In practice it's not going to happen because we have to pick our battles. If you want to pick this battle then I ask you to commit to providing 2 weeks+ of your time to auditing (or whatever time you'll need to audit 100 packages). Do a few java package reviews first to get in the zone[1]. I can easily create a cron job that would run once a week and report any non-whitelisted package that has Requires: java to java-devel@. We use something similar for duplicate provides. But even that is mostly unneeded because whatever new packages are added they will most likely be leaf packages or create their own branch (so they won't affect rest of the ecosystem). Plus the package review should certainly stop those packaging from getting in in the first place (or have a comment in the spec file why it's needed - if it's not obvious) [1] https://bugzilla.redhat.com/show_bug.cgi?id=FE-JAVASIG -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Miloslav Trmač (2013-11-21 20:57:38) But if you want a simpler guide: * Install your app with headless Java * Run it * Did it crash? These two steps make it rather non-simple; one would also determine which parts of the code base have not been exercised. The crash will be noticeable in the same way that unsetting DISPLAY variable is for any other GUI app. Maybe there's a console app that creates X window only in some cases (batik comes to mind as a possible candidate here). But that's not normal modus operandi even in Java world. And Mirek's question bears repeating: if software can't figure this out reliably, how do you expect us fallible humans to do so? Software can't reliably detect licenses in packages, yet we routinely do license review manually as part of Package Review process. It's really not that uncommon for people to be better than computers at fuzzy tasks. This is not really that kind of a fuzzy question, and getting licenses wrong has a potentially much higher cost. Call me silly but I expect maintainers to know what their packages actually do. Call me silly but I expect computers to do routine tasks, not people. (... under the assumption that somebody really wants to do a comprehensive conversion and get this applied to all future Java packages; I understand that this may not actually be what $you really want to achieve and spend time on.) As if I spent 3 years making Java packaging more manual... Apparently it is not as easy as if your software uses these packages and/or classes, it needs full java, otherwise java-headless is enough. Why not? What else could cause a dependency on full java? It is as easy as if your software uses these packages and/or classes but it's almost impossible to say if your software uses them due to nature of Java/JVM itself. There's too many ways to use parts of JVM. Interfaces, intermediate libraries, various classloading tricks. Intermediate libraries would carry the non-headless dependency themselves, so their users wouldn't have to, would they? In most cases, but I can imagine cases where a genric toolkit library with support for multiple backends didn't want to force-pull full java for a specific use case. Nobody is going to write a reliable detection if it should be headless requires or not. I suppose this will show how hopelessly naive I am, but wouldn't byte code refers to any class from $list or contains a string constant that starts with any class name from $list be sufficently accurate? Not provably correct, certainly, but if it got us from 30 unknown false positives to 1-2 unknown false positives _and_ eliminated a manual packaging/review step... I don't even dare guess how many false positives you'd get by doing that. Oh and let's see how fast we can make this. Otherwise autorequires generator is going to waste a lot of developer time in by doing bytecode analysis on each single class file. Regardless..what I meant to say: Nobody - as in I don't see anyone jumping up and down and volunteering to do the work and maintain the code, provide ways to workaround those inevitable false positives etc. I have asked and received a clear no from people who actually work on OpenJDK codebase. If anybody things they are smarted go ahead: prove them wrong -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Jerry James (2013-11-21 17:01:07) On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač m...@volny.cz wrote: (IIRC somewhere in the thread it's been suggested that software can't know which one to use: how would the maintainers know then?) Yes, I raised that question early on in this thread. The response I got was to read this: http://www.oracle.com/technetwork/articles/javase/headless-136834.html which is a 7 year old article about setting up a headless system with Java 6, and doesn't mention audio anywhere. I am willing to do the work to figure out which of my packages need full java and which can get by with java-headless, but I need a very clear set of criteria to work from. I don't think this article qualifies, nor have I yet seen such a clear set of criteria. I linked to that article because it's relevant. If you read it you know that: * java.awt. classes are a problem for headless (except Canvas, Panel and Image as mentioned in the article) Other than that a simple grep for one of following will give you a smoking gun: * import javax.sound. But if you want a simpler guide: * Install your app with headless Java * Run it * Did it crash? - No? - good! you can probably use headless - Yes? - not good! use full Java VM * Did you get any backtraces when running the app that are not normally there? - No? - good! you can use headless - Yes? - not good! use full Java VM For obvious reasons this is not something we'll be turning into a separate project. Autorequires/provides don't work on source code but bytecode. And Mirek's question bears repeating: if software can't figure this out reliably, how do you expect us fallible humans to do so? Software can't reliably detect licenses in packages, yet we routinely do license review manually as part of Package Review process. It's really not that uncommon for people to be better than computers at fuzzy tasks. Call me silly but I expect maintainers to know what their packages actually do. Seriously though if you really can't figure it out, just ask on java-devel@ (or #fedora-java on freenode). You can't have more than a handful of Java packages. Apparently it is not as easy as if your software uses these packages and/or classes, it needs full java, otherwise java-headless is enough. Why not? What else could cause a dependency on full java? It is as easy as if your software uses these packages and/or classes but it's almost impossible to say if your software uses them due to nature of Java/JVM itself. There's too many ways to use parts of JVM. Interfaces, intermediate libraries, various classloading tricks. Nobody is going to write a reliable detection if it should be headless requires or not. Much less integrate it into all different Java build systems so that it actually makes sense to spend time on. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Miloslav Trmač (2013-11-21 13:48:51) On Thu, Nov 21, 2013 at 1:31 PM, Aleksandar Kurtakov akurt...@redhat.com wrote: I agree with you that the current Features/Changes system is useless as is now. It was supposed to be a way to collect information for Release notes nothing more AFAIK. From the FESCo side, IMHO collecting information for Release Notes was fairly useless; the current system allows every affected maintainer to be aware of changes and raise concerns, and this has led several times to significantly altering the proposal for the better. Discussions, decisions, changes and so on happen in whatever way the parties doing the work think is better for them. The parties doing the work proposed to: (optional) Mass-change spec files that have Requires: java to Requires: java-headless I.e. mass-break non-headless packages, and to ask Other developers to clean up after the Change owners breaking their packages. That's may actually be the right thing to do (I'm uncertain), but at the very least the affected maintainers should have an opportunity to speak up whether they are willing to do it or not, and that's the reason the Change process is imposing a public discussion. In the thread you and others have suggested that there in fact there are no or few Other developers, and this is all a Java SIG internal thing; I don't know whether it's true (and I don't currently care to collect the data); the proposal certainly hasn't been written that way. From my perspective as Change owner, I proposed it for two reasons: * Release notes and just wider audience for the change (as Alex mentioned) * Get feedback on *serious* problems with the proposal I agree that *affected maintainers* should have an opportunity to speak up. Based on their input in the thread I believe noone objected to mass filing bug, waiting a bit for maintainers to either look themselves or fix it up automatically. *That* kind of input was constructive and helped flesh out the process for rolling out the change for users/maintainers. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Miloslav Trmač (2013-11-21 13:48:51) In the thread you and others have suggested that there in fact there are no or few Other developers, and this is all a Java SIG internal thing; I don't know whether it's true (and I don't currently care to collect the data); the proposal certainly hasn't been written that way. For your enjoyment, top 20 java package owners: 145 gil 67 goldmann 44 mbooth 38 sochotni 36 msrb 30 mizdebsk 21 jhernand 19 jcapik 19 galileo 17 orion 16 spike 16 omajid 16 huwang 14 caolanm 13 mmorsi 13 madsa 11 akurtakov 9 ricardo 8 fnasser 7 pahuang Funnily enough none of these people complain about current change proposal. And these people own ~550 packages out of those 800. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
a metapackage or x11 subpackage that would outweight the inevitable disadvantages? If you *really* feel I misunderstood these two ideas we can start an etherpad or something so we can ping-pong more effectively on specific issues. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Nicolas Mailhot (2013-11-20 16:20:34) Le Mer 20 novembre 2013 15:04, Stanislav Ochotnicky a écrit : Can we actually list good reasons to have a metapackage or x11 subpackage that would outweight the inevitable disadvantages? If you *really* feel I misunderstood these two ideas we can start an etherpad or something so we can ping-pong more effectively on specific issues. What will you do when wayland arrives and you'll need to make the x11 parts optional even for gui apps? Wayland has and for foreseeable future will have an X11 compat layer. As far as I am aware there is nobody working on native Wayland support in OpenJDK. So the answer to your question is: I will do nothing because OpenJDK will need X11 libraries. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Jerry James (2013-11-18 16:54:28) On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: I believe OpenJDK maintainers will agree that automatically detecting if java or java-headless is supposed to be required is not really feasible. There's too many variables at play. Then how are we maintainers supposed to determine if our packages require full java, or just java-headless? Needs X or audio is too vague. Is there a list of packages and/or classes that are present in full java but not in java-headless? Or some kind of explicit set of guidelines I can use to examine my packages to see which they need? You can use following Oracle article as a starting point[1]. But maybe OpenJDK maintainers can provide better alternative. Generally though there are *very* few packages in Fedora that would require full java. [1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Toshio Kuratomi (2013-11-19 10:49:57) On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky wrote: Quoting Toshio Kuratomi (2013-11-18 17:08:12) On Nov 15, 2013 4:09 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jaroslav Reznik (2013-11-15 12:28:11) * (optional) Mass-change spec files that have Requires: java to Requires: java-headless Other developers: * Modify spec files to have Requires: java-headless instead of Requires: java Could you say a few words about why a java-headless package was chosen instead of java-x11 (as an example name)? I believe the term was chosen because it's widely used term in Java world. Oracle uses that term in official documentation as well[1]. Last but not least, Debian uses that term as well and I see no reason to be different just for the sake of it. I mean (and sorry that I wasn't clear), why the choice to make java-headless the special case? Especially if (as it appears from the reply to Jerry James), most packages in Fedora will only need the headless version. (So the headless version would be the java package, The version with the gui nevironmen deps would be java-x11 or similar). If someone wanted to install just OpenJDK for their own in-house Java application they would have to know to request full -x11 version. I would wager we'd be receiving a lot of bugs if we went this way. If someone needs headless they will be actively looking for it. If they want java they will not consider that they might get incomplete version. Not to mention possible 3rd party RPMs that might exist -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Ville Skyttä (2013-11-15 18:30:33) On Fri, Nov 15, 2013 at 3:22 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b Ugh. Why did you have to do that? Huh, wow, that's not at all the response I was expecting. What did you expect to achieve with it? Yeah, I guess I should have omitted that first sentence. My apologies. I consider the rest still valid though Anyway, I'll bite: the primary reason is because I've seen earlier specfile mass modifications (automated as well as done by non-maintainer humans) happen in a way I don't want to see happen to packages I maintain. And it's already been a long time since the availability of java-headless was announced. See also below. It's been 3 weeks and even in that announcement thread I explicitly mentioned guidelines not being fixed yet. But you are right, you are entitled to your own style in your own packages (to a degree). So an opt-out system for automated changes is probably needed. Waiting until their dependency chain gets fixed would have been grossly inefficient; there was no reason to wait for that, and still isn't. There's a difference between deps being fixed and fixing all packages at once in the same way. That commit changed nothing because all the dependencies still have Requires: java. And what do you think will happen when the dependencies get fixed to depend on java-headless? Oh, these packages don't need any action, java-headless goodness just is suddenly available with them. So it did change something after all, no? Progress needs to start somewhere, and I helped by doing the bits applicable to my packages. I don't know what ticked me off. Perhaps because you went seemingly ahead without any regard for coordinated effort. If you wanted to speed it up, I'd welcome if *you* created the change proposal and drove it. If you think that 800 packages are going to get fixed by a miracle when some maintainers don't even fix their packages that break dependent packages you are mistaken. If everyone just fixed their packages to Requires: java-headless at their own discretion I'll tell you when we'd actually notice the change: never. I'd like to think that maintainers of those 800 packages are going to actually make an effort but I know better from past experience. Unless their own package is broken in serious way they won't care. It's the same in your case really, you fixed your package so you don't care. But I care about all of those 800 packages. I just start to question why... -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Jaroslav Reznik (2013-11-15 12:28:11) * (optional) Mass-change spec files that have Requires: java to Requires: java-headless Other developers: * Modify spec files to have Requires: java-headless instead of Requires: java * (note) JavaSIG has several proven packages that could assist with this change Release engineering: * mass rebuild is not necessary but it would simplify things I would like to point out that all of the above could be simply automated. We have done similar change when we migrated packages from BuildRequires: maven to BuildRequires: maven-local and it worked without issues. It will save precious developer/rel-eng time and ultimately will only break minimal amount of packages (with simple workarounds and fixes). -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Headless Java
Quoting Ville Skyttä (2013-11-15 14:11:37) On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jaroslav Reznik (2013-11-15 12:28:11) * (optional) Mass-change spec files that have Requires: java to Requires: java-headless Other developers: * Modify spec files to have Requires: java-headless instead of Requires: java * (note) JavaSIG has several proven packages that could assist with this change Release engineering: * mass rebuild is not necessary but it would simplify things I would like to point out that all of the above could be simply automated. If you do that, please make sure to not touch packages that have already been converted -- properly finding out what's already done will probably require using repoquery, for example due to possible conditionals in specfiles that make them backwards compatible, e.g. http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b Ugh. Why did you have to do that? That commit changed nothing because all the dependencies still have Requires: java. Technically speaking you also made a change which is against packaging guidelines[1], but that's not really an issue in this case Unnecessary complications... [1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Can we have better ssh fingerprint collision messages?
Quoting valent.turko...@gmail.com (2013-11-12 08:42:06) I work a lot with different kind of routers, openwrt and other embedded systems, and they all usually use same address - 192.168.1.1, so Ubuntu message is quite useful because gives me simple command that I just copy/paste so I can get rid of old finderprint and I can connect to new device with same IP but obviously different ssh fingerprint. 1. Don't top-post 2. I hope I'll never be at mercy of administrators like you who copy-paste commands because that's what they are told to. 3. The message appears whenever there is a change in ssh host key for given address. On Fedora as well. If you can't reproduce, you didn't change the host key or you are really connecting to a different host -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Discontinued Packing of NetBeans IDE
Quoting Rahul Sundaram (2013-11-05 17:46:55) Hi On Tue, Nov 5, 2013 at 11:45 AM, Manuel Faux wrote: Is it correct that the NetBeans IDE is currently not packed for Fedora? I checked the netbeans package, which was last built for fc17. Is there any technical or license reason for this or is just nobody packing it right now? Someone from Sun used to be the maintainer and noone is doing it right now. No technical or licensing issues if anyone is interested in packaging it afaik. More specifically look at: https://lists.fedoraproject.org/pipermail/java-devel/2010-November/003980.html Reason nobody picked it up is that is has relatively big dependency chain and there was nobody interested enough (from maintainer perspective). Most Java packages are in Fedora because they are dependencies of following packages: * Tomcat * Maven * Eclipse * WildFly * (new) Big Data SIG stuff * and of course a few more apps here and there -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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 have proxy word.
Quoting Zbigniew Jędrzejewski-Szmek (2013-11-01 13:52:31) On Fri, Nov 01, 2013 at 12:09:03PM +, Daniel P. Berrange wrote: On Fri, Nov 01, 2013 at 02:07:22AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Nov 01, 2013 at 01:08:33AM +0200, مصعب الزعبي wrote: بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. I think you'll have to use a... proxy to work around this problem. Or maybe it'll be enough to use a https connection to the mirror. NB, US export restrictions that Fedora is subject to mean users from Syria should not be downloading Fedora at all[1], via a proxy or not. Let's consider how likely this export restriction is to prevent a member of the Syrian government or military from obtaining a copy of Fedora? Not very likely. How likely this export restriction is to hurt a random person, e.g. trying to install open source to avoid restrictions imposed by their government? The first is a joke, the second is high enough to keep this restriction in the same contempt as the Syrian government's ban on proxy. You are walking on thin ice and should stop immediately You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise subject to these restrictions. CCing fedora-legal for good measure -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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] Headless JRE in Fedora
Quoting Florian Weimer (2013-10-28 14:42:47) On 10/24/2013 04:19 PM, Stanislav Ochotnicky wrote: Quoting Fernando Nasser (2013-10-24 16:06:27) Also, will this change be ackported into the Java packages of RHEL_5 and RHEL-6? Doesn't matter. Fedora != RHEL I think we need a solution for EPEL, though. Either we can ship the non-split packages with adequate provides in RHEL, or there should be some RPM macro that expands to the proper dependency. It's probably not a good idea to have every package to cook up its own solution. EPEL contains small number of Java packages. I believe complicating hundreds of packages in Fedora for something like this would be an extremely bad idea. If we have to live with small incompatibility for a few years, so be it. But long term, we'll have a nice clean Java packaging. Moreover It only affects rpms/specs from F21+ that would like to be installed on EL5/6 For what it's worth even most current Java packages are not compatible even with EL6 due to automatic requires handling and other changes. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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] Headless JRE in Fedora
Quoting Jiri Vanek (2013-10-21 18:45:46) Hi all! With https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc20 beeing stable, would like to make this more visible: The jdk in Fedora, being inspired in Debian, now supports headless version. During the life of F20 (as in f21 all expected packages should be correctly headless)i would like to recommend all java packages maintainers, who do not need audio, or X or whatever (this is still on QA on our side) to swap theirs dependence to java-headless. Alos, maintainers, please do not forget, that when you update your package, also packages you are depending on must become just hedless dependent. Anyway - all libraries should be jut java-headless :) I would like to suggest especially wildFly and tomcat to try to migrate asap, as this change was designed for them :) They can't. Several reasons: * Packaging guidelines clearly state BR/R: java * Maven packages have automatically generated requires on java (or java-devel) To *really* make use of java-headless few things need to happen: * guidelines have to be updated * java-packages have to be changed to R: java-headless by default * Maven packages are rebuilt * packages not built with maven are migrated manually * leaf applications make sure they have R: java Btw - the update above is now somehow stuck - it not in testing, nor in updates. Maybe the relengs can help. If you need to get in touch with rel-engs file a ticket[1], don't CC their ML or it's going to get lost [1] https://fedorahosted.org/rel-eng/ -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Headless JRE in Fedora
Quoting Fernando Nasser (2013-10-24 16:06:27) Also, will this change be ackported into the Java packages of RHEL_5 and RHEL-6? Doesn't matter. Fedora != RHEL Our products use only one spec file, we'll have to add lots of %if osversion in our spec files (and we have 300+ of them). Well then you can still require java and not make use of this split in your products. You will be pulling in a lot of unneeded cruft but it's going to work just like it has worked for years... -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)
Quoting punto...@libero.it (2013-10-21 23:32:47) any ideas? thanks regards Messaggio originale Oggetto:Broken dependencies: tika Data: Mon, 21 Oct 2013 21:01:15 + (UTC) Mittente: build...@fedoraproject.org A: tika-ow...@fedoraproject.org tika has broken dependencies in the rawhide tree: On x86_64: tika-parsers-1.4-2.fc21.noarch requires mvn(org.bouncycastle:bcprov-jdk16:1.46) tika-parsers-1.4-2.fc21.noarch requires mvn(org.bouncycastle:bcmail-jdk16:1.46) On i386: tika-parsers-1.4-2.fc21.noarch requires mvn(org.bouncycastle:bcprov-jdk16:1.46) tika-parsers-1.4-2.fc21.noarch requires mvn(org.bouncycastle:bcmail-jdk16:1.46) On armhfp: tika-parsers-1.4-2.fc21.noarch requires mvn(org.bouncycastle:bcprov-jdk16:1.46) tika-parsers-1.4-2.fc21.noarch requires mvn(org.bouncycastle:bcmail-jdk16:1.46) Please resolve this as soon as possible. This is a bug in bouncycastle, it should not have versioned jar symlinks unless it's a compat package. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: The trouble with metadata-extractor
Ugh, what a mess.. Quoting Andrea Musuruane (2013-10-20 23:37:54) Hi all, last April the following bug report was opened: https://bugzilla.redhat.com/show_bug.cgi?id=947457 As I stated on bugzilla, metadata-extractor was just needed by JOSM. Updating metadata-extractor would break JOSM. Anyway I suggested to patch JOSM to use a newer version of metadata-extractor if he really needed it. I had no response at all. BTW, I am metadata-extractor maintainer, and not JOSM maintainer. Sorry but it is your responsibility as maintainer to keep the package up to date as much as possible. If JOSM required older version you should work with JOSM maintainer and upstream to update it to latest (providing patches/testing etc.) Why are you even maintaining metadata-extractor if you have no use for it? It only makese sense for JOSM maintainer to maintain metadata-extractor in the first place since he's the only user of the library This evening the submitter emailed me privately and I discovered that meanwhile, a new review request for a newer version of metadata-extractor was approved and now it is part of Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1004563 I don't like the naming of the package, both are metadata-extractor 2.x. If anything new package should have been metadata-extractor26. Technically the review was OK, the packages do not conflict in any way, but they are helluva confusing. All in all, even if JOSM couldn't be ported it would have been better to package metadata-extractor-compat solely for JOSM and then just update extractor to latest upstream. As I understand now, newer metadata-extractor is required by Apache Sorl and Apache Tika, which are not yet part of Fedora. Already are as was mentioned He asked me to exchange our repository to simplify some build with maven. And with that I presume that he would like to have his package called metadata-extractor because he has troubles to build sorl and tika. Frankly...I'd rather ask for clarification. I have trouble understanding some people I think all this have been handled very badly. He could have told why he needed a more recent version of metadata-extractor in the first place, the reviewer of #1004563 could have checked if the package followed the naming guidelines and/or have checked if the package was already in Fedora. The review was technically OK, there was one question from reviewer missing: Why cannot you use version already in Fedora and what have you done to fix that? Other than that the packages don't really conflict or cause any issues to each other AFAIK. I still think that my original plan (i.e. patching JOSM). was more sensible. Agreed What to do now? What do you think? Ideally? I'd say: 1. Update metadata-extractor to latest upstream, add maven metadata, shell script in /usr/bin/ etc. Basically overwrite metadata-extractor with current metadata-extractor2 2. Sort out JSOM breakage afterwards. Either package metadata-extractor-compat, or patch JSOM (ideally going to upstream with the patch afterwards) 3. Obsolete/deprecate metadata-extractor2 4. Wham someone with a cluestick If it helps, if it makes things easier, I can release the ownership of metadata-extractor and someone else can have good care. I just packaged it because, as an openstreetmap mapper, I longed to have JOSM in Fedora Libraries should be generally maintained by people who are actually using them in some application. But it's up to you after all said and done if you want to keep maintaining it. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: python-urlgrabber, yum: blatant disregard for packaging guidelines and common sense
Quoting tim.laurid...@gmail.com (2013-10-09 16:48:31) the original urlgrabber maintainer left long time ago, but the yum team adopted the code, because it was critical to yum, so this is cause why there has been no upstream release. yum shold make upstream releases in more frequently, instead of adding very large patches to latest git HEAD. yum-utils releases was made by me, but I have not had so much time to spend on yum-utils, so there has not been any releases for a long time. My beef was mostly with python-urlgrabber (since that's used by more tools than just yum), but Zdenek managed to get permissions to do upstream releases so current F20/rawhide has been updated and is mostly fine. There's few minor problems and obsolete parts but that can be worked out later... dnf is not in a state to replace yum yet, and it will take awhile to get there, a lot of tool uses yum api and dnf has no stable api yet, so yum will properly stay here for years to come so there is no excuses to not make upstream releases more frequent :) I really like relase-early-release-often but for that you need a nice testuite so you don't screw up too badly :-) Now I am wondering how dnf is going to approach testing, regressions etc. It sure would be nice to have a big testuite for such a component. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
python-urlgrabber, yum: blatant disregard for packaging guidelines and common sense
I was looking for examples of nice packages for upcoming packaging workshop we
are doing in Brno. I made the terrible mistake of doing fedpkg clone
python-urlgrabber.
If there was some normal packaging issue I'd most likely just file a bug in
bugzilla, but this made my blood boil. This is one of our core components!
snippet from spec:
Source0: urlgrabber-%{version}.tar.gz
Patch1: urlgrabber-HEAD.patch
Guess what? The patch is 100k big. The tarball is actually smaller! Of course
the package does not even follow post-release versioning guidelines[1]. The only
good thing is that the tarball sha actually matches upstream released version
from 2009.
Now I *get* that yum uses new features of urlgrabber. But package maintainer is
also upstream developer. Just do the damn release ffs! Oh fun fact: yum is
actually in the same boat.
[1] http://pkgs.fedoraproject.org/cgit/python-urlgrabber.git/
[2]
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post-Release_packages
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
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: Red Hat and Fedora Working Groups
Quoting Jóhann B. Guðmundsson (2013-10-05 05:29:57) Shall we talk about how Red Hat employees have been granted all kinds of privileges within our community without as even bother to introduce themselves to the community even to the extent that fesco is now judging people if they are socially ready for proven packagers while Red Hat employees walk around and are granted those privileges freely? Your vitriol is not appreciated I want you to point out the person who got provenpackager privileges without going through normal provenpackager process. I have personally seen (and voted against) a few colleagues who wanted to get provenpackager (or sponsor) permissions but didn't have enough experience IMO. As far as I know they are not provenpackagers/sponsors. If this really was a problem I know a lot of Red Hat employees would be as unhappy about this inequality as you seem to be. But it's not... You are actually insulting and attacking integrity of every sponsor (i.e. people who actually vote for/against new provenpackagers). I like Simon Phipps's quote Corporations are not people. If you have a problem with specific action taken by specific Red Hat employees: point it out! Do not be generic or people will most likely write you off as another troll. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fedora-review 0.5.0 released
Codename: Thursday Release fedora-review devs proudly announce new release with tons of bugfixes and new features. Kudos to our latest contributors: - Pavel Raiskup (autotools checks) - Josef Stribny (update of ruby checks) Gentle reminder for PHP reviewers: you should install php-pci package to get static code analysis during review (split off due to big dependency chain). New stuff = - Removing the only php test which is outdated (5addbb4). - Add checks for autotools obsolete macro usage (#206). - Update ruby macro usage (#212). - Automate several directory ownership checks (#187). - Support display and modification of active plugins, initiated by discussion in bz 989946. Adds plugin and flag feedback to template. New --display-plugins and --plugins options. - New DISTTAG flag used when disttag can't be deduced from prebuilt packages (09304f2). - Add hint if package has ExclusiveArch in deps (#166). - Don't use and require mock when using --prebuilt (#208). - Fix macro usage test which was misleading and plain wrong (#227). - Fix bug for packages with a '++' in their name (bz 971977). - Fix bug for check-desktop-database (#127, bz 952593). - Preserve modification times when unpacking srpm and rpms (bz 982101). - Don't flag remove %buildroot/path as error (bz 972672) - Run rpmlint also on srpm (bz 981977) - Support display and modification of active plugins, initiated by discussion in bz 989946. Adds plugin and flag feedback to template. - New --display-plugins and --plugins options. - Stability tested on 12000 packages. Fixes: + Corner case .desktop files (544eca2, 18cc82f). + Macros in %files line (7566e91). + Subpackages with version base package (4a6597a). + CheckDisttag: many fixes (ee87f44). + Look in %post/%postun for update-mime-database (7e73f89). + Clean up check-large-data output (8a37267). + Don't require R:rubygems on -doc, -devel and -fonts (#224). + Update check for static libs to current GL (#222). + Corner case checking desktop-file-validate w bash variabLe (#223). + Handle upstream rpm bug making %check test in ruby hard (#225). - Fix URL for gtk-query-immodules (bz 980308). -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Running a command in spec file?
Quoting Dave Johansen (2013-08-28 21:58:38)
On Wed, Aug 28, 2013 at 9:13 AM, Remi Collet fed...@famillecollet.com wrote:
Le 28/08/2013 18:09, Dave Johansen a écrit :
I'm trying to make a spec file that uses the devtoolset in RHEL 5/6 (
rhn.redhat.com/errata/RHEA-2013-0175.html ) but I haven't been able
to figure out how to enable devtoolset in the spec file. If I run 'scl
enable devtoolset-1.1 bash' before doing rpmbuild it works, but how do
I run a command like that in the spec file?
In %build:
. /opt/rh/devtoolset-or-sclname/enable
The enable script wasn't executable, but sourcing it worked like a charm.
Technically, yes...the above works but doesn't ensure it will keep working. I
believe normally this convoluted way is proper way to execute some commands in
an SCL within spec file:
%{?scl:scl enable %{scl} }
# this is a shell
command 1
command 2
...
%{?scl:}
This way you can use the same spec file as SCL and out of SCL.
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
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 of freemind and all my remaining Java packages
Quoting Johannes Lips (2013-08-29 09:00:28) On Sat, Aug 24, 2013 at 11:43 AM, Johannes Lips johannes.l...@gmail.comwrote: Hi all, I finally came to the conclusion, that I no longer want to invest time and effort in keeping all my Java packages in good shape. I don't have the time anymore to unbundle all the bundled libraries and keep a dozen downstream patches to make it work. freemind is close to a 1.0.0 release and I provided packages for that already in a small side repo [1]. There are also some review requests for additional libraries [2],[3]. So I will orphan the packages next week and will block them if no one applies for taking them over. - freemind - SimplyHTML - jansi - jansi-native - jarbundler - jibx - xpp3 Ok, so I am going to orphan the remaining packages: - SimplyHTML - freemind Perhaps someone is willing to pick them up. I don't have that much time to spend on them at the moment, but I took freemind and simplyHTML. Co-maintainers welcome -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: Overall fedora-review test results.
Quoting Michael Schwendt (2013-08-22 19:20:51) On Thu, 22 Aug 2013 15:27:47 +0200, Alec Leamas wrote: The overall results with some comments are at http://ur1.ca/f5xxw . The CheckSoFiles results might be .so plug-in libs (extension modules), which are stored in private paths, i.e. outside run-time linker's search. Or even non-versioned shared libs ending with .so, but being ordinary run-time libs (and no build-time libs for optional -devel packages). Fedora-review actually makes a difference between unversioned *so files in libdir and *so files in subdirectory under libdir. It will issue an error for the former and warning for the latter(making check pending - i.e. manual review needed). I've checked a few of the problems found and all of them were packaging bugs IMO. I have personally filed several bugs related to unversioned files (also discovered by f-r). Some of them are files that should be in -devel subpackage, some are plugins that should be in private subdirectory...and some are weird exceptions that no tool can automatically know about. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: default applications in Fedora
Quoting Petr Hracek (2013-08-13 12:28:05) Hi folks, I have just a short question regarding default applications in Fedora. Let's say the I have install Fedora 19 (w/o upgrade) and I would like to know what is default PDF viewer, etc. Is there any command in Fedora which returns me default application? Thank you in advance Usually xdg-mime command should return correct results. For example: For your case you first need to know mime type of file in question. Assuming you don't know what that is: $ xdg-mime query filetype abcd.pdf application/pdf And then you can do: $ xdg-mime query default application/pdf evince.desktop xdg-mime can be used to change the default as well. Then it just depends on applications if they honor xdg or not. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- 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: replacing folders with symlinks (pre vs pretrans)
Quoting Panu Matilainen (2012-09-21 10:17:27)
A directory (empty or not) can't be automatically replaced by anything
else (symlink or otherwise) in the existing rpm versions. If absolutely
necessary, it can be accomplished by doing the necessary renames and
symlinks in %pretrans -p lua scriptlet, but that should be only seen
as the last resort as its not exactly a safe operation.
This used to work in %pre scriptlet as well. It seems like RPM is now doing some
additional checks and it will not even get to the point of %pre scriptlet. As
far as I can see for F17/F18 %pre scriptlet will work, but F19+ %pretrans has to
be used, correct?
Since I *knew* we used %pre for this exact problem before, I have used it and
it broke upgrade paths[1]. I assume just rewriting %pre[2] into following
%pretrans will work:
for key, dir in pairs({boot, conf}) do
path = %{_datadir}/%{name}/ .. dir
if posix.readlink(path) then
os.remove(path)
end
end:
It certainly seemed to work now, but I wonder if I am just missing something
else.
[1] https://admin.fedoraproject.org/updates/FEDORA-2013-9207/xmvn-0.5.0-2.fc19
[2] http://pkgs.fedoraproject.org/cgit/xmvn.git/tree/xmvn.spec#n117
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Daily package ownership changes?
Quoting Rahul Sundaram (2013-05-15 19:55:17) On 05/15/2013 01:22 PM, Pierre-Yves Chibon wrote: As you can see from the output at the end of my email, not everyone does it ;-) Yeah. I am not surprised at all. Automating as much as possible is the only efficient way to handle it To play the devil's advocate a bit, if we automate it without requiring announce we end up without any additional info about reasons why package was orphaned. So I'd say announce mail could probably go from MUST to Nice to have. I.e. please explain to prospective new maintainers what to be aware of. Anyway, I am a fan of automation so +1 to this whole thing at least as a test run. It's not visible from your example output, but if the owner just changed from person A to person B instead to orphan, it would be 1 change instead of A-orphan, orphan-B correct? I would probably say daily reports would be overkill. Weekly could be perhaps too long? If I think about it I'd probably invent some crazy complicated stuff so...just pick some schedule and be prepared to change if people complain :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora-review 0.4.1 release
We have a new fedora-review release with quite a lot of bugfixes and update for current Java guidelines. Excerpt from NEWS file: - Updated and improved Java checks for latest packaging guidelines * Automate buildarch check * Do CheckNoArch per subpackage instead of buildarch * Add check for new style Maven packaging * Update CheckTestSkip for mvn-build * Maven packages don't need to BR/R jpackage-utils check - Fix attachment name for 'MD5-sum check' (bz 861716) - Fix %files section handling for font-packages (#209) - Handle %20 in source URLs correctly (bz 920376) - Fix CheckLicenseField for multiple files without license (#205) - Don't write licenses in random order - Fix several bugs in koji-download-scratch script - Output ANSI color sequences only on color terminals (bz 955719) - Compress legend of report - Fix problem with subpackages being ignored/missed - Add 'Copyright' to illegal tags check Update links: https://admin.fedoraproject.org/updates/fedora-review-0.4.1-1.fc17 https://admin.fedoraproject.org/updates/fedora-review-0.4.1-1.fc18 https://admin.fedoraproject.org/updates/fedora-review-0.4.1-1.fc19 https://admin.fedoraproject.org/updates/fedora-review-0.4.1-1.el6 Authors of changes for this release (commits): - Jakub Filak (1) - Ralph Bean (1) - Alec Leamas (15) - Stanislav Ochotnicky (23 because of Java stuff and merge commits :-)) Enjoy, -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tomcat6 unresponsive maintainer deprecation
Tomcat6 package in Fedora is old, has several problematic bugs (including 4 security) and most importantly there's a replacement: tomcat-7.x I believe it is in our (developers as well as users) best interest to get rid of it. I have sent similar email to java-devel on February 26th[1], created another tomcat6 bugreport a week ago[2] but I wasn't successful in reaching David Knox (primary maintainer). Note that we already had a bugreport to migrate packages to tomcat-7[3] and we almost succeeded, but then new packages started creeping in with dependency on tomcat6. We need to get rid of it ASAP or we'll be fighting neverending battle. Even as comaintainer/provenpackager I cannot deprecate package that I do not own. I consider this point 4 of unresponsive maintainer process[4]. However due to security issues, and package being effectively dead I wouldn't mind speeding up the process. I might try to bring this up with FESCO, but process doesn't seem to include any wiggle room there. [1] http://lists.fedoraproject.org/pipermail/java-devel/2013-February/004698.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=918010 [3] https://bugzilla.redhat.com/show_bug.cgi?id=819505 [4] http://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_maintainer_is_absent -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://www.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomcat6 unresponsive maintainer deprecation
Quoting Kevin Fenzi (2013-03-12 15:53:56) On Tue, 12 Mar 2013 13:49:22 +0100 Stanislav Ochotnicky sochotni...@redhat.com wrote: Tomcat6 package in Fedora is old, has several problematic bugs (including 4 security) and most importantly there's a replacement: tomcat-7.x I believe it is in our (developers as well as users) best interest to get rid of it. I have sent similar email to java-devel on February 26th[1], created another tomcat6 bugreport a week ago[2] but I wasn't successful in reaching David Knox (primary maintainer). Note that we already had a bugreport to migrate packages to tomcat-7[3] and we almost succeeded, but then new packages started creeping in with dependency on tomcat6. We need to get rid of it ASAP or we'll be fighting neverending battle. Even as comaintainer/provenpackager I cannot deprecate package that I do not own. I consider this point 4 of unresponsive maintainer process[4]. However due to security issues, and package being effectively dead I wouldn't mind speeding up the process. I might try to bring this up with FESCO, but process doesn't seem to include any wiggle room there. Feel free to file a fesco ticket and explain whats going on. Thanks, filed https://fedorahosted.org/fesco/ticket/1094 I believe the emails/bugzilla provides enough context but I'll also try to attend the FESCO meeting to answer any questions. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomcat6 unresponsive maintainer deprecation
Quoting Dan Mashal (2013-03-12 18:11:06) On Tue, Mar 12, 2013 at 10:06 AM, yersinia yersinia.spi...@gmail.com wrote: On Tue, Mar 12, 2013 at 6:05 PM, devzero2000 pinto.e...@gmail.com wrote: On Tue, Mar 12, 2013 at 4:28 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Kevin Fenzi (2013-03-12 15:53:56) On Tue, 12 Mar 2013 13:49:22 +0100 Stanislav Ochotnicky sochotni...@redhat.com wrote: Tomcat6 package in Fedora is old, has several problematic bugs (including 4 security) and most importantly there's a replacement: tomcat-7.x I believe it is in our (developers as well as users) best interest to get rid of it. I have sent similar email to java-devel on February 26th[1], created another tomcat6 bugreport a week ago[2] but I wasn't successful in reaching David Knox (primary maintainer). Note that we already had a bugreport to migrate packages to tomcat-7[3] and we almost succeeded, but then new packages started creeping in with dependency on tomcat6. We need to get rid of it ASAP or we'll be fighting neverending battle. Even as comaintainer/provenpackager I cannot deprecate package that I do not own. I consider this point 4 of unresponsive maintainer process[4]. However due to security issues, and package being effectively dead I wouldn't mind speeding up the process. I might try to bring this up with FESCO, but process doesn't seem to include any wiggle room there. Feel free to file a fesco ticket and explain whats going on. Thanks, filed https://fedorahosted.org/fesco/ticket/1094 I believe the emails/bugzilla provides enough context but I'll also try to attend the FESCO meeting to answer any questions. I have received this today http://www.exploitthis.com/2013/03/rhsa-20130623-1-important-tomcat6-security-update.html. Dunno if useful. Best -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I actually tried to install tomcat6 last night on RHEL6.4 and was having issues. Funny. Don't know if Fedora has the same release (haven't checked), but this is pretty important as I use tomcat at work. Could a proven packager take a look at it as well, (ASAP if it's a security issue?). There's more of them (bugs), but please for the love of all that is holy...don't use tomcat6. Every single supported Fedora release has tomcat-7.x where Ivan Afonichev is doing pretty great work with updates/bugfixing (kudos). Use it. Forget tomcat6. Situation is different on RHEL of course, there the tomcat6 is still being actively maintained (and will be for whole life of the given release). -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AsciiDoc update and split coming in rawhide
I've taken over maintainership of AsciiDoc and prepared an update in rawhide to 8.6.8. I'm bcc-ing maintainers in case they don't read devel. I will tag the build on Monday barring any major issues/complaints. For now you can play with it by downloading from koji[1]. I am considering update in F18 as well if there won't be major issues. I believe users would appreciate the update and in worst case packagers could just disable asciidoc generation for single release. Any problems with that, let me know. Changes between versions are substantial so it's possible some packages will FTBFS. I've also split 3 additional subpackages: -doc: documentation, examples etc -music: support for music notation (pulls in lilypond) -latex: support for latex generation (pulls in dblatex) If your package used latex/music processing you should probably update your BuildRequires. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=400964 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-19 mass rebuild failures
Quoting Peter Robinson (2013-02-16 20:22:54) Hello All, If you receive a failure email from the mass rebuild please remember you need to fix your broken packages. If you're unsure if you're package is broken or unsure check out the failure list here to see if you're package is on on the list and needs attention. http://ausil.fedorapeople.org/f19-failures.html Since I prefer bugzilla for tracking work I've prepared a bug-filing script on top of releng repo[1]. Could someone have a look, review the code and run it? Theoretically I could file those bugs myself, but I don't want to step on anyone's toes :-) [1] https://fedorahosted.org/rel-eng/ticket/5474 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps for Node.js stuff
Quoting Jamie Nguyen (2013-02-08 10:12:12) On 07/02/13 21:33, Stephen Gallagher wrote: On Thu 07 Feb 2013 02:26:48 PM EST, Jamie Nguyen wrote: On 07/02/13 19:24, Jamie Nguyen wrote: Now that I'm a bit more familiar with node.js packaging (ie, never even looked at node.js before this week...), I'll take it. I don't currently have any packages for you to review, so you get off scot-free. Well, for now at least ;) Oops, looks like Stephen beat me to it by 30 minutes :) I took care of the high-priority one, but by all means, please dig into the nodejs-tap dependency chain. As T.C. says, that will make it easier to test and validate future reviews. Will do. I'm currently packaging a tonne of deps for buddycloud, so many review swaps may be imminent! Ah, buddycloud in Fedora? Cool. I'll have to try it out one day :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning xfig
I am orphaning xfig. Inkscape supports its file format and it's IMO much better
alternative for current machines. For some reason gstreamer{,1} buildrequires
it. Xfig has a 2 comaintainers, but I am not sure how much time they really have
currently. There are 2 bugs open.
I am ccing gstreamer owners as well.
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changing 500 packages BR:maven to BR:maven-local - TOMORROW(ish)
Quoting Stephen Gallagher (2013-02-04 16:26:40) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon 04 Feb 2013 04:56:23 AM EST, Stanislav Ochotnicky wrote: Now that I have your attention... Fedora Maven package is currently a mix of upstream release and our changes that we need for building RPMs. We can clean it up, but we need to move packages from BR: maven to BR:maven-local. That will enable users to install Maven package without installing a lot of other stuff they don't necessarily need. This change will not affect buildroots because maven-local pulls in maven package. The only issue is: there's mass rebuild scheduled for 8.2. I would like to rebuild Maven packages before that. We have a modified mass-rebuild script that can do the change of maven - maven-local automatically. Strictly speaking this change is also breaking current Java guidelines, but I believe for the better (change proposal should be up today/tomorrow, with SIG meeting following). I am looking for a blessing from a community to do this change tomorrow/Wednesday so that F19 is even more awesome :-) Is there anyone who feels strongly against this change? I realize this is very short-notice, but I believe disruption this change will cause is nil. If this change is in violation of policy, PLEASE refrain from performing it until such time as the FPC reviews the proposed changes. Also, if this is going to impact a large number of packages, it should either be coordinated with the existing mass-rebuild plan or else performed in a private branch and then merged in. If something goes wrong with your mass-rebuild, it will be difficult to address in Rawhide with some packages updated and some not. I've filed an FPC ticket[1]. The reason I was planning to do it shortly before mass rebuild is exactly because mass rebuild checks last build that was done on package and if it was done recently - doesn't perform the mass rebuild. I hope we'll manage an agreement on Wednesday so I'll be able to do a nice rebuild in coordination with rel-engs and not pollute repos too much. Thanks for speaking up, [1] https://fedorahosted.org/fpc/ticket/251 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mass changing 500 packages BR:maven to BR:maven-local - TOMORROW(ish)
Now that I have your attention... Fedora Maven package is currently a mix of upstream release and our changes that we need for building RPMs. We can clean it up, but we need to move packages from BR: maven to BR:maven-local. That will enable users to install Maven package without installing a lot of other stuff they don't necessarily need. This change will not affect buildroots because maven-local pulls in maven package. The only issue is: there's mass rebuild scheduled for 8.2. I would like to rebuild Maven packages before that. We have a modified mass-rebuild script that can do the change of maven - maven-local automatically. Strictly speaking this change is also breaking current Java guidelines, but I believe for the better (change proposal should be up today/tomorrow, with SIG meeting following). I am looking for a blessing from a community to do this change tomorrow/Wednesday so that F19 is even more awesome :-) Is there anyone who feels strongly against this change? I realize this is very short-notice, but I believe disruption this change will cause is nil. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn
Quoting Toshio Kuratomi (2013-01-28 23:52:30) On Mon, Jan 28, 2013 at 09:51:42AM +, Jaroslav Reznik wrote: Goal of this feature is to migrate all packages to use XMvn instead of mvn- rpmbuild script. Several packages have already been converted as part of initial testing: http://pkgs.fedoraproject.org/cgit/maven-surefire.git/tree/maven- surefire.spec http://pkgs.fedoraproject.org/cgit/maven-doxia.git/tree/maven-doxia.spec http://pkgs.fedoraproject.org/cgit/slf4j.git/tree/slf4j.spec http://pkgs.fedoraproject.org/cgit/apache-commons- compress.git/tree/apache-commons-compress.spec From a quick look at one of these specs, this Feature will need a packaging guidelines update. But also from that quick look, the packaging guidelines update doesn't look like it will be too hard or controversial. Yes that is part of the plan. I just need to think of nice way to do it so we don't create unnecessary mess of current guidelines and allow for transition period. I don't want to force anyone to migrate who isn't (yet) convinced. I'll update the wiki with this info in a bit -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn
Quoting Bill Nottingham (2013-01-28 20:21:21) Jaroslav Reznik (jrez...@redhat.com) said: = Features/XMvn = https://fedoraproject.org/wiki/Features/XMvn Feature owner(s): Stanislav Ochotnicky sochotni...@redhat.com Introduce new Maven packaging tooling with new macros, automated install section and more. I would assume that, even with approval, there's no way to stage these changes before the mass rebuild? There's too many packages I guess. It's likely we won't be able to transition *all* packages. If we manage to convert core let's say 300-400 I'll be happy and consider this all a success since that will mean we'll test the code in most possible situations. Some simple packages could be converted automatically, but verification might actually ake longer than just doing it manually :-) Does this also allow for automating/autogenerating a list of build provides? We do have scripts that can scan the source code and generate BuildRequires snippets. But they are not (and can never be) 100%, plus rpm doesn't make generating buildrequires during build any easier :-) We might do some tricks, but it's still a hack IMO. At this point I'm happy with automatic requires (which will likely keep us occupied to make sure unnecessary stuff doesn't creep in everywhere) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn
Quoting Bill Nottingham (2013-01-28 20:51:04) Stanislav Ochotnicky (sochotni...@redhat.com) said: I would assume that, even with approval, there's no way to stage these changes before the mass rebuild? There's too many packages I guess. It's likely we won't be able to transition *all* packages. If we manage to convert core let's say 300-400 I'll be happy and consider this all a success since that will mean we'll test the code in most possible situations. Some simple packages could be converted automatically, but verification might actually ake longer than just doing it manually :-) OK. Do we have an examples of 'common things you might need to know to migrate your packages', 'how to verify your migrated package', etc? (Then again, if it's just going to be a few people in the Java SIG doing most of the migrations, it may not be necessary.) I am not sure if Mikolaj (author of XMvn) aimed for it originally, but I'd love it if this solution became more widespread in Linux/Java world. We'll have a talk about it during FOSDEM this Saturday. We have some semi-automatically generated documentation: http://mizdebsk.fedorapeople.org/xmvn/cookbook/ It's not finished yet, and could definitely use some polishing and fixes. Besides the cookbook I'd like to document common pitfalls and things to check. Mainly regarding automatic requires generation, file ownership and compatibility symlinks. At this point I'm happy with automatic requires (which will likely keep us occupied to make sure unnecessary stuff doesn't creep in everywhere) Nah, that never happens! :) Indeed, Freemind in Fedora doesn't pull in whole Eclipse[1] :-) [1] https://bugzilla.redhat.com/show_bug.cgi?id=904177 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase request on a project
Quoting Stephen Gallagher (2013-01-18 15:27:30) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri 18 Jan 2013 06:55:26 AM EST, Paulo César Pereira de Andrade wrote: Sorry if this is a dumb question, but I cannot find any information. I would like to have git rebase master on f16, f17, and f18 branches of http://pkgs.fedoraproject.org/cgit/megaglest.git I once messed it a bit by adding a commit only to branches and later merging master, now I cannot merge without a merge master commit, and am not allowed to push myself a git rebase master branch. Rebases like that are not permitted in Fedora because they rewrite history (and therefore mean we wouldn't be able to exactly recreate an older build if we needed to). You're going to have to do the merge and manage the merge conflicts appropriately (either via 'git merge' or by starting from the tarball and working your way up again without a merge commit). If I understood Paulo correctly, he merely wanted to linearize his history so he can continue doing fast-forward merges again. I've cross-merged branches so that they are now again on the same hash. Content of all branches (f16+) was the same so they were all without conflicts. For future, please do everything in master first :-) Enjoy, -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Removing Publican and fop from EPEL5
Quoting Eric H. Christensen (2012-12-10 22:51:11) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The last week or so has seen a couple of patches going into fop in the Fedora repositories. I recently became a co-maintainer of fop in EPEL5 and was trying to bring fop into current there. Unfortunately there are many dependency failures there that it's going to be a lot of work to bring it up to where we need it. The actual need, from my point of view, is to get Publican working properly. fop provides the engine for creating PDFs in Publican and is a necessary function for the Fedora Docs project. That said, the current version of Publican in EPEL5 is very old and outdated. Near current version of Publican is already in EPEL6 and I believe fop is in RHEL6 repositories. I say all that to ask this: Is anyone currently using fop or Publican in EPEL5 or can we get rid of those bits? I have no problem working to bring fop upto speed in EPEL5 if someone needs it but I'd hate to do all the work if no one is using it. Regardless of fop being out of date in EPEL I believe EPEL guidelines[1] strongly discourage big updates from flowing in. Quoting: The packages in the repository should, if possible, be maintained in similar ways to the Enterprise Packages they were built against. In other words: have a mostly stable set of packages that normally to not change at all and only changes if there are good reasons for it -- so no hey, there is a new version, it builds, let's ship it mentality. So I'd say: don't rebase fop at all. It's against the guidelines in the first place [1] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
Quoting Adam Williamson (2012-12-06 16:06:04) On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. Actually, most of current Java ecosystem is sane when Maven is being used. We can automate Maven into oblivion. We are short time from making Maven packages be as simple as: ... %build %mvn_build %install %mvn_install ... As a bonus, Maven in principle discourages bundling because it's trivial to add new dependencies properly so that's making stuff easier for us overall. There are issues with the ecosystem, but they have been mostly caused by CLASSPATH handling in JVM. This will hopefully go away with new JVMs, but I won't hold my breath for it (but there is some traction there so who knows). What I am most afraid of is (in descending order): 1. Too much focus on backward compat (a lot of upstreams are still trying to support JVM 1.4) 2. Constant reinventing of wheel (tens of XML libraries still being used) 3. Going backwards - gradle build system which takes worst things from ant, and scons and combines them in one ugly package I am quite optimistic though, -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum Package Remove Order
Quoting Mark Bidewell (2012-11-30 16:21:20)
On Fri, Nov 30, 2012 at 9:47 AM, Fernando Nasser fnas...@redhat.com wrote:
Hi,
Why are you creating these directories in %post in the firs place?
If you create them in %install (empty) and own them regularly in %file and
do the same on
the other packages that install thins on it, they will be properly removed
when the last
RPM that owns them go away.
Regards,
Fernando
I was not aware of %install(empty) where can I find some documentation?
rant: ugh, mixing top/bottom posting
Anyway, what Fernando meant probably:
-
%install
mkdir %{buildroot}/opt/companydirs
...
%file
...
%dif /opt/companydirs
Done...
--
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-java] broken compatibility from jna-3.4.0 to 3.5.0
Quoting Ismael Olea (2012-11-27 16:24:26) We have seen such problems many times in many packages. Usually adding a dummy method just to satisfy the signature is enough though in this case it might not be. I see. Please report it to svnkit developers too. Done: http://issues.tmatesoft.com/issue/SVNKIT-329 Ccing devel so that audience is bigger (I believe this deserves it) Just for future reference. What you have written in upstream bugreport is basically: I have tried to build your software in unsupported way (ant vs gradle) and used different versions of your dependencies and it failed. I've done it because other project has some silly rules. Can you fix it?. Upstream might or might not realize what you are asking for is a simple dependency bump with API fix (most likely). And they can get annoyed by your request (some upstreams definitely would). To be precise, this situation is not a bug in upstream at all, but it is caused by us (Fedora as a distribution). Therefore it's more of a RFE as far as upstream is concerned. RFEs written as bugreports can be hard to sell. This is not just for your benefit. I've seen several such bugreports from Fedora contributors. They can sometimes make dealing with upstreams difficult, so please be careful with the wording. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
