Re: Removing deprecated %patch syntax from go-sig's packages
rpmlint 2.4.0 (in Fedora 39) does not currently support the "%patch -P1 -p1" syntax [1], and incorrectly reports that patches aren't applied. 2.5.0 has a fix for this [2]. There's a 2.5.0 update for F39 currently in testing [3]. [1] https://github.com/rpm-software-management/rpmlint/issues/461#issuecomment-1500993133 [2] https://github.com/rpm-software-management/rpmlint/commit/3631d5f12bf0c26f036e9cfd1bd289c109a09d79 [3] https://bodhi.fedoraproject.org/updates/FEDORA-2024-181fd77b29 Regards, Richard On Tue, 9 Jan 2024 at 17:31, Maxwell G wrote: > > Hi everyone, > > RPM has deprecated the `%patchN` syntax in favor of `%patch -PN` where > `N` is the patch number. See the RPM documentation for more information > [1]. In current RPM versions, this syntax only emits a deprecation > warning, but support for this syntax has been removed completely on the > rpm master branch [2]. Around 100 packages maintained by the go-sig > still use this syntax. > > Later this week/early next week, I will run this script [3] over the > affected go-sig packages [4] to update them to the modern patch syntax. > For example, the script will change: > > %patch0 -p1 -> %patch -P0 -p1 > %patch0005 -p2 -> %patch -P0005 -p2 > > If anyone has any objections or would like to exclude a package, please > let me know. > > ---Maxwell > > [1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 > [2] > https://github.com/rpm-software-management/rpm/commit/afd352481bacea521ce5ba01e989866478278532 > [3] > https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/new_patch_syntax.sh > [4] > https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/new_patch_syntax/packages > > -- > Maxwell G (@gotmax23) > Pronouns: He/They > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Richard Fearn richardfe...@gmail.com -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Strange maven build problem in jackson packages
> My theory is that there is a dependency that was updated in Rawhide, which is > problematic for my build, and that dep was recently updated in c9s and is now > causing the same problem for me there. Has anyone seen anything like this > before? How did you begin to investigate it? Or am I just being a side-tag > noob? I think your theory is correct - and the dependency that was updated is fasterxml-oss-parent: https://src.fedoraproject.org/rpms/fasterxml-oss-parent/c/ce8d84d5ac23d0218facd26a161641c9acba27d7?branch=rawhide * The parent of jackson-annotations is com.fasterxml.jackson:jackson-parent * The parent of jackson-parent is com.fasterxml:oss-parent * oss-parent no longer includes maven-bundle-plugin in its POM So I guess you could (a) add maven-bundle-plugin back into oss-parent, or (b) (as Jerry suggests) add it to jackson-annotations with %pom_add_plugin. (Not sure which is best...) As Jerry mentioned the patch is redundant because it's patching the build-helper-maven-plugin config, only for that plugin to later be removed from the POM with %pom_remove_plugin. It's maven-bundle-plugin that enables the "bundle" packaging type to be used, not build-helper-maven-plugin. Regards, Richard -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F34 Cloud Amazon AMIs unbootable after updates
There is an issue with Xen instances (e.g. t2.small) - see https://bugzilla.redhat.com/show_bug.cgi?id=2010058. What I saw was that it would hang for a couple of minutes waiting for the disk to appear, then give up and go into emergency mode. The workaround is to edit the Dracut script that decides which modules to include in the initramfs - to ensure that xen-blkfront is included. Your issue might be something else - I didn't see a panic, like in the screenshot. You could try and get more of the log as plain text by going to Actions → Monitor and troubleshoot → Get system log. Regards, Rich On Thu, 7 Oct 2021 at 08:19, Richard W.M. Jones wrote: > > On Thu, Oct 07, 2021 at 12:46:11AM -0400, Christopher wrote: > > Running on EC2, it's kinda hard to get good information from a system > > that won't boot. The machine won't boot to the point of being able to > > capture the system log, and the screenshot of the instance doesn't > > appear to be super helpful: https://imgur.com/a/4PWcRSg > > Can you hit shift + PgUp and capture as much of the preceeding output > as possible? > > Also it's apparently possible to connect a serial console: > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-serial-console.html > which would be the ideal way to debug this. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Flagged projects in Anitya
On Tue, 3 Aug 2021 at 19:51, Mikolaj Izdebski wrote: > > Thank you for bringing this up. > The flags are processed by admins of Anitya. > > I have just processed your ones. Thanks Mikolaj! Richard -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Flagged projects in Anitya
Hi, Does anyone know who looks after flagged projects in Anitya? I've flagged a couple of projects for deletion, but so far nothing has happened. Regards, Richard -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire - findbugs / findbugs-bcel / findbugs-contrib / eclipse-findbugs
> Note that your queries did not check for BuildRequires, since you did > not enable the foo-source repositories. > That would require "--enablerepo fedora-source --enablerepo > updates-source", or "--enablerepo rawhide-source" on rawhide. Thanks Fabio - I knew I would get something wrong with that query :-) > Since findbugs contains code quality checks, I suspect those three > packages could be built without those checks without problems, since > they do not require findbugs at install-/ or runtime. I expect so too - I doubt the packages need FindBugs in order to build. I'll take a look at those packages and contact the maintainers as necessary. Thanks, Rich -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Intent to retire - findbugs / findbugs-bcel / findbugs-contrib / eclipse-findbugs
Hi everyone, I'm writing to say that I intend to retire the following packages: * findbugs * findbugs-bcel * findbugs-contrib * eclipse-findbugs The rationale behind this is: * The last FindBugs release was in March 2015 [1]. * Upstream has been dead since 2016 [2]. * The project was forked in 2017 [3] as SpotBugs [4]. * FindBugs depends on an old snapshot of Apache Commons BCEL (packaged as findbugs-bcel). I don't think it's possible (or worthwhile) to get FindBugs to build against upstream BCEL. * It no longer builds against the latest rawhide versions of ASM and Hamcrest. * Trying to maintain FindBugs and keep it building/working against the latest versions of Java libraries isn't really a good use of anyone's time (and there is no upstream to contribute patches back to). * findbugs-contrib (known upstream as fb-contrib [5]) is a FindBugs plugin that provides additional detectors, and is of no use without FindBugs itself. * Likewise, eclipse-findbugs makes FindBugs available in the Eclipse IDE, and is of no use without FindBugs being available. As far as I can tell, nothing else depends on this set of packages: $ sudo dnf repoquery --recursive --whatrequires findbugs Last metadata expiration check: 1:11:19 ago on Sat 29 May 2021 23:00:52 BST. ant-findbugs-0:3.0.1-25.fc34.noarch eclipse-findbugs-0:3.0.1-23.fc34.noarch eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch findbugs-contrib-0:7.4.7-6.fc34.noarch findbugs-contrib-samples-0:7.4.7-6.fc34.noarch findbugs-tools-0:3.0.1-25.fc34.noarch $ sudo dnf repoquery --recursive --whatrequires findbugs-bcel Last metadata expiration check: 1:11:24 ago on Sat 29 May 2021 23:00:52 BST. ant-findbugs-0:3.0.1-25.fc34.noarch eclipse-findbugs-0:3.0.1-23.fc34.noarch eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch findbugs-0:3.0.1-25.fc34.noarch findbugs-contrib-0:7.4.7-6.fc34.noarch findbugs-contrib-samples-0:7.4.7-6.fc34.noarch findbugs-tools-0:3.0.1-25.fc34.noarch $ sudo dnf repoquery --recursive --whatrequires findbugs-contrib Last metadata expiration check: 1:11:31 ago on Sat 29 May 2021 23:00:52 BST. eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch findbugs-contrib-samples-0:7.4.7-6.fc34.noarch $ sudo dnf repoquery --recursive --whatrequires eclipse-findbugs Last metadata expiration check: 1:11:39 ago on Sat 29 May 2021 23:00:52 BST. eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch It's been interesting keeping FindBugs alive since I picked it up in 2010 (11 years ago... where has the time gone?!), but the world has moved on (to SpotBugs), and I think it's time to let it go. Regards, Rich [1] http://findbugs.sourceforge.net/ [2] https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html [3] https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2017-September/004383.html [4] https://spotbugs.github.io/ [5] https://github.com/mebigfatguy/fb-contrib -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packages webapp status
On Mon, 3 Feb 2020 at 17:03, Kevin Fenzi wrote: > > Thats... much more harsh than I would agree with. I still use it and > find some of its information helpfull. Sadly it does seem to have got a lot worse recently... I noticed last weekend that a few of the packages I maintain (e.g. clide, colordiff, perl-App-ccdiff, whowatch) can no longer found. I remember some tickets being created about this - I'll see if I can find them and comment there... Rich -- Richard Fearn richardfe...@gmail.com ___ 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: findbugs-contrib building on i686 builders despite ExcludeArch
Thanks, Jason and Vit, for your replies. Unfortunately it looks like many of findbugs-contrib's Java dependencies are being retired at the moment, so I need to decide what to do about that first... Rich -- Richard Fearn richardfe...@gmail.com ___ 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
findbugs-contrib building on i686 builders despite ExcludeArch
Hi, Due to a dependency on Eclipse, findbugs-contrib can no longer be built on non-64-bit architectures. According to https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures: > If a Fedora package does not successfully compile, build or work on an > architecture, then those architectures should be listed in the spec in > ExcludeArch. So I added ExcludeArch to the findbugs-contrib spec: https://src.fedoraproject.org/rpms/findbugs-contrib/c/35db66939b8d262a6c049421e666d380b920c8a4?branch=master which I based on a similar change for eclipse itself: https://src.fedoraproject.org/rpms/eclipse/c/1b7ea00088e02a126cf0f4031f91659a32d4?branch=master For some reason though, the findbugs-contrib build earlier today for the F31 mass rebuild was done on an i686 builder: https://koji.fedoraproject.org/koji/buildinfo?buildID=1323580 https://koji.fedoraproject.org/koji/taskinfo?taskID=36487003 and failed with an error: BUILDSTDERR: error: Architecture is excluded: i386 The same thing happened with a recent Koschei build: https://koji.fedoraproject.org/koji/taskinfo?taskID=36306707 Have I gone about this the wrong way? Rich -- Richard Fearn richardfe...@gmail.com ___ 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: New package not (yet) recognised by Bodhi
> Actually, Bodhi relies on Fedora Packages, which is experiencing > problems in updating its database: > > https://github.com/fedora-infra/fedora-packages/issues/410 Ah - yes I did notice that it wasn't coming up in https://apps.fedoraproject.org/packages/ either. That would explain why Bodhi doesn't know about it. Thanks! Rich -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New package not (yet) recognised by Bodhi
> Just type or paste the full build name. That worked - thanks! https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fec6d2d48 Still curious as to how long it might take for Bodhi to recognise it properly though... Rich -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New package not (yet) recognised by Bodhi
> It won't autocomplete the package name and build or it refuses to create the > update? It won't autocomplete. Rich -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
New package not (yet) recognised by Bodhi
Hi I had a new package approved yesterday (perl-App-ccdiff) and I've built packages for F29/rawhide. Bodhi doesn't know about the new package yet, though, so I can't submit a new package update for F29. How long does it normally take for Bodhi to start recognising a newly-created package? Thanks Rich -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
I've fixed disktype, ncdu, and whowatch in rawhide. Thanks for generating the list! Regards, Rich -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Wiki page subscription
> I also checked that mail to my fedoraproject.org address (to which the wiki > defaults) is forwarded to me. Changes/Fedora26CFlags is on my watchlist, > but I did not receive any change notification for it. The last change was > not even flagged as minor. Could it be because you haven't visited the "Changes/Fedora26CFlags" page since the last notification email about that page was sent to you? When I get emails about page changes, they say: > There will be no other notifications in case of further activity unless > you visit this page while logged in. You could also reset the > notification flags for all your watched pages on your watchlist. So if you got notified in the past, but haven't visited the page since then, you won't get further emails. Regards, Richard -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: More texlive woes in rawhide
Hi, > it seems right now I can't rebuild the rdkit package [1] due to this: > > pdflatex 'RDKit.tex' > This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) > (preloaded format=pdflatex) > restricted \write18 enabled. > kpathsea: Running mktexfmt pdflatex.fmt > mktexfmt: mktexfmt is using the following fmtutil.cnf files (in > precedence order): > mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing > changes: > mktexfmt: /builddir/.cache/texlive/texmf-config/web2c/fmtutil.cnf > mktexfmt [INFO]: writing formats under > /builddir/.cache/texlive/texmf-var/web2c > mktexfmt [INFO]: did not find entry for byfmt=pdflatex, skipped > mktexfmt [INFO]: Total formats: 0 > mktexfmt [INFO]: exiting with status 0 > I can't find the format file `pdflatex.fmt'! > > Anyone can give me a clue? I had the same problem with one of my packages. See: https://bugzilla.redhat.com/show_bug.cgi?id=1382447 spot said the problem should be fixed in the -8 build (http://koji.fedoraproject.org/koji/buildinfo?buildID=808434), which has completed. I see your failed build used the -7 packages, so perhaps you just need to try it again. Richard -- Richard Fearn richardfe...@gmail.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F24 mouse/touchpad natural scrolling
There's a separate natural scrolling setting for mouse and touchpad. Did you change the right one? Regards Richard On 5 Aug 2016 10:05 pm, "Roger Wells" wrote: > Hello, > > In the Mouse & Touchpad settings dialog where one can select/deselect > Natural Scrolling there is no difference between settings. The > view/window is moved around the contents, i.e. not "Natural Scrolling" > > The machine is a Thinkpad x240, OS is F24, just upgraded from F23 a day > or so ago. > > This setting worked as expected on F23 > > Actually, I just checked and none of the settings, "Mouse Speed", > "Primary Button" included has any effect. > > I did set the speed to high on F23 and thought it worked. Never messed > with the "Primary Button" though. > > uname -a: Linux rwells-x240 4.6.4-301.fc24.x86_64 #1 SMP Tue Jul 12 > 11:50:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > TIA > > -- > Roger Wells, P.E. > leidos > 221 Third St > Newport, RI 02840 > 401-847-4210 (voice) > 401-849-1585 (fax) > roger.k.we...@leidos.com > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
Hi, > https://github.com/fedora-infra/bodhi/issues/763 You beat me to it :) Thanks for doing that! And Luke seems to have fixed the problem already. Thanks Luke! Regards, Richard -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bodhi - new update obsoleted an older update that had been submitted for stable
Hi > The same thing happened to me with mozilla-noscript updates that > were submitted to stable and obsoleted by another set of updates > I submitted to testing today. Glad to hear it's not just me :) > It's not different. Both F23 and F22 updates are affected in the same > way. My 6.4.3 F22 update didn't obsolete my 6.4.0 F22 update. Regards, Richard -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
bodhi - new update obsoleted an older update that had been submitted for stable
Hi, Until yesterday I had two findbugs-contrib 6.4.0 updates in testing: findbugs-contrib-6.4.0-1.fc22 https://bodhi.fedoraproject.org/updates/FEDORA-2015-36b05c38b8 findbugs-contrib-6.4.0-1.fc23 https://bodhi.fedoraproject.org/updates/FEDORA-2015-1e04f3b5f5 I submitted the F22 update for stable at 12:02:54, and submitted the F23 update for stable at 12:03:00. A little while later I created new updates for testing, for version 6.4.3: findbugs-contrib-6.4.3-1.fc22 https://bodhi.fedoraproject.org/updates/FEDORA-2016-578a14be73 findbugs-contrib-6.4.3-1.fc23 https://bodhi.fedoraproject.org/updates/FEDORA-2016-670e467497 When I looked at the F23 6.4.3 update, I noticed it included all the notes from the 6.4.0 update. I thought I'd selected something incorrectly. So I edited it, unticked the "6.4.0 is available" bug, and removed the 6.4.0 details from the notes. (That's why the update was edited at 14:49:55.) Later I realised that the F23 6.4.3 update had obsoleted the F23 6.4.0 update - hence why it had inherited the 6.4.0 bug and notes. I was surprised that this happened :) I understand that I'd only *submitted* the 6.4.0 F23 update for stable; it hadn't actually been *pushed* to stable when I created the 6.4.3 update. But still, I have a couple of questions: 1) Is it sensible for an update, that has been submitted for stable, to then be obsoleted by a subsequent update? 2) Why was the F23 behaviour different to the F22 behaviour? I thought perhaps that I'd set up the F23 6.4.3 update incorrectly, but as far as I can tell, I only selected bug 1291027 (the bug about 6.4.3), and the findbugs-contrib-6.4.3-1.fc23 build. Regards, Richard -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
> eclipse-findbugs (richardfearn) Fixed - thanks! Richard -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: To someone with power to push packages on Fedora 21
> Nb. did bodhi2 stopped sending „your update reached 7 days in testing > and can be pushed to stable” emails? https://github.com/fedora-infra/bodhi/issues/298 Regards, Richard -- Richard Fearn richardfe...@gmail.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: Orphaned packages looking for new Point of Contact
> Huh. Does this always default to Source Mage, or does it have > heuristics which are misfiring? Neither. The Fedora package is built using `make logos-all`, which means that all available logos are compiled in. The `find` command is used to find the logos, and C code for building a linked list of them is written into load_logos.h before compilation. At runtime, linux_logo walks the linked list to find an appropriate logo, according to the settings that are in effect. Since `find` is used, the logos aren't in any particular order. Here's the build log for the F22 package: https://kojipkgs.fedoraproject.org//packages/linux_logo/5.11/10.fc22/data/logs/x86_64/build.log Towards the end you can see all the "Added logo..." lines, which show the order in which the logos were found at build time. You can also see the list by running `linux_logo -L list`, which also shows whether each logo is a "Banner" logo (text underneath the logo), or a "Classic" logo (text to the right of the logo): Available Built-in Logos: NumTypeAsciiNameDescription 1ClassicYesclassic-nodotsThe Classic Logo, No Periods 2ClassicYesclassicThe Default Classic Logo 3ClassicYesclassic-simpClassic No Dots Or Letters 4BannerYessourcemage_banSource Mage GNU/Linux banner ... Banner mode is the default, but the first three logos are "Classic" logos, so the Source Mage logo is used by default. For the latest F23 build (http://koji.fedoraproject.org/koji/buildinfo?buildID=652899), the order is different, so that build displays a Solaris logo by default :/ The "normal" way to build this only compiles in the two Linux logos shown on the linux_logo home page (http://www.deater.net/weave/vmwprod/linux_logo/), so not compiling in all logos would be one way to get more satisfactory default behaviour. Another possibility, if we really wanted the Fedora package to include all logos, would be to make sure the two Linux logos appear first in the logo_config file that contains the list of compiled-in logos. I just spent far too much time figuring out how this works :-) Since I've done that, I may as well file a bug... Richard -- Richard Fearn richardfe...@gmail.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't push update to stable
On 8 September 2015 at 18:36, Dave Love wrote: > I haven't had any messages saying that things could be pushed to stable > recently, though, which I had previously (to bodhi2?). Should that be > working? I wondered about this too. There is an open issue on GitHub: https://github.com/fedora-infra/bodhi/issues/298 Regards, Richard -- Richard Fearn richardfe...@gmail.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: libc-client
Hi, > https://koji.fedoraproject.org/koji/packageinfo?packageID=756 > libc-client-2004g-3 jkeating2007-04-10 19:46:55 > > and from where is "libc-client-2007f-9.fc21.x86_64" built? uw-imap: http://koji.fedoraproject.org/koji/buildinfo?buildID=567840 Regards, Rich -- Richard Fearn richardfe...@gmail.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 install just stops - no explanation
I've experienced the same problem with a F22 VM running in VirtualBox. (Is yours a VM?) Disabling IPv6 seemed to help a bit, but the problem never went away completely. There a few bugs that talk about similar issues, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1206878 https://bugzilla.redhat.com/show_bug.cgi?id=1214538 There are various ideas out there for how to fix this, e.g. `dnf clean all`, or using LIBREPO_DEBUG=1. But none of these worked definitively for my VM. Regards, Richard -- Richard Fearn richardfe...@gmail.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/F22 mass rebuild
> Odd. It seems like it commited to master fine, but for some reason the > build never happened. > > You should be able to just do a 'fedpkg build' in master and things > should be back on track. I thought so, and just did that, and it built fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=577111 Hopefully it's a one-off and not part of a bigger problem... Thanks, Richard -- Richard Fearn richardfe...@gmail.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
F21/F22 mass rebuild
Hi, I've got a question about the last mass rebuild: https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild For a couple of my packages: http://koji.fedoraproject.org/koji/packageinfo?packageID=6133 http://koji.fedoraproject.org/koji/packageinfo?packageID=4673 there was a rebuild for both F21 and F22. However for ncdu: http://koji.fedoraproject.org/koji/packageinfo?packageID=6127 there was only an F21 rebuild. Does that matter? It's a bit hard to tell, as the script linked from the wiki page is the one used for the F21 rebuild back in June; and the date after which maintainer builds count towards the latest rebuild is 2014-06-05, the same date as for the F21 mass rebuild (as opposed to some date in August). Thanks, Richard -- Richard Fearn richardfe...@gmail.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: Java headless bugs
I've been through my packages today and decided as follows: eclipse-findbugs - https://bugzilla.redhat.com/show_bug.cgi?id=1068044 - Eclipse plugin; continue to depend on java findbugs - https://bugzilla.redhat.com/show_bug.cgi?id=1068070 - Swing app; continue to depend on java findbugs-contrib - https://bugzilla.redhat.com/show_bug.cgi?id=1068072 - Plugin for FindBugs (Swing app); continue to depend on java findbugs-bcel - https://bugzilla.redhat.com/show_bug.cgi?id=1068071 jFormatString - https://bugzilla.redhat.com/show_bug.cgi?id=1068156 jcip-annotations - https://bugzilla.redhat.com/show_bug.cgi?id=1068255 - libraries - OK to change to java-headless Hope this is OK... Regards, Rich -- Richard Fearn richardfe...@gmail.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: Java headless bugs
>> 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. > If the requires is > generated automatically all the better but that's not the guidelines > scope IMO. It does seem to be generated automatically, so I followed fedora-review's advice at the weekend, and removed the jpackage-utils dependency from a few of my packages... Rich -- Richard Fearn richardfe...@gmail.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: guided/interactive/scripted tutorials
> You may have used this kind > of thing - it tells you 'click this next' and waits until you do. > As you might expect, googling for anything along these lines without > having a very precise set of keywords only returns pages of tutorials. > Any suggestions what to look for or, even better, tools in Fedora that > can already do this appreciated. Eclipse calls these "cheat sheets": http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-cheatsheets.htm&cp=0_4_4_3_1 Rich -- Richard Fearn richardfe...@gmail.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: Disabling ABRT?
On 29 December 2013 11:29, Brendan Jones wrote: > Thanks. I had tried this but still no core in the executing directory. Now > I'm not sure where they are going - certainly nowhere in $HOME. Could be a couple of things: 1. The core dump limit for the process could be 0 (i.e. don't write core dumps). 2. The core dumps are written to the cwd of the process at the point where it dies - not necessarily where you run it from. (If you know the PID you could check /proc//cwd.) Rich -- Richard Fearn richardfe...@gmail.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 changing symlink to directory with %pretrans scriptlet
[Sending to the right list this time] Hi Bruno, On 28 December 2013 16:43, Bruno Wolff III wrote: > https://fedoraproject.org/wiki/Packaging:Guidelines#The_.25pretrans_scriptlet > Notes that you need to use lua in pretrans scriptlets, not shell commands. Thanks. I've already seen that. It doesn't seem to make any difference whether it's a bash scriptlet or a lua scriptlet, though; irrespective of what language is used to delete the symlink, the problem still occurs. > I haven't found an example for you to copy, but note there are still some > cases where changing symlinks to directories or vise versa won't work with > rpm (https://bugzilla.redhat.com/show_bug.cgi?id=975909). I think deleting the symlink manually may be revealing a problem in rpm. It seems to treat /usr/share/javadoc/test-1/ hello (from the old package) and /usr/share/javadoc/test/hello (from the new package) as the same thing. Since the new package is installing /usr/share/javadoc/test/hello, it therefore decides to 'skip' the old 'hello' file, rather than 'erase' it. I'm not sure yet why these two paths are considered to be the same... Rich -- Richard Fearn richardfe...@gmail.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: Disabling ABRT?
Hi, On 28 December 2013 21:29, Brendan Jones wrote: > I'm doing some development at the moment and I want the coredumps to be > dropped somewhere sane (like the executing directory). How do I do it? I think you want to do: $ sudo systemctl stop abrt-ccpp Before: $ cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e i.e. send core dumps to abrt. After: $ cat /proc/sys/kernel/core_pattern core $ cat /proc/sys/kernel/core_uses_pid 1 i.e. write core dumps to files named core.xxx. Regards, Rich -- Richard Fearn richardfe...@gmail.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
Problem changing symlink to directory with %pretrans scriptlet
Hi all, I'm trying to change a symlink to a directory but it's not working. I've reduced the problem down to a simple test case. This package: http://richardfearn.fedorapeople.org/test/1-1/test.spec creates the following: * a directory /usr/share/javadoc/test-1 (named after the package version) * a file within the test-1 directory * /usr/share/javadoc/test, a symlink to test-1 In the next version: http://richardfearn.fedorapeople.org/test/1-2/test.spec the Javadoc directory is unversioned, so the 'test' symlink is now a directory (containing one file). As expected the 1-1 to 1-2 upgrade fails: file /usr/share/javadoc/test from install of test-1-2.fc20.noarch conflicts with file from package test-1-1.fc20.noarch So in the next version: http://richardfearn.fedorapeople.org/test/1-3/test.spec a %pretrans scriptlet deletes /usr/share/javadoc/test, if it's a symlink. However during the 1-1 to 1-3 upgrade, the old test-1 directory isn't deleted. The verbose rpm output from this upgrade: http://richardfearn.fedorapeople.org/test/1-3-upgrade.txt shows that rpm doesn't erase /usr/share/javadoc/test-1/hello. It does seem to try to erase the /usr/share/javadoc/test-1 directory, but can't because it still contains a file. Does anyone have any idea what's going on here? Regards, Rich -- Richard Fearn richardfe...@gmail.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
puppet update in F18 requires non-existent hiera package
Hi, Just tried updating an F18 machine and got this: $ sudo yum update Loaded plugins: changelog Resolving Dependencies --> Running transaction check [...] ---> Package puppet.noarch 0:2.7.18-1.fc18 will be updated ---> Package puppet.noarch 0:3.1.1-1.fc18 will be an update --> Processing Dependency: hiera >= 1.0.0 for package: puppet-3.1.1-1.fc18.noarch --> Finished Dependency Resolution Error: Package: puppet-3.1.1-1.fc18.noarch (updates) Requires: hiera >= 1.0.0 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest There doesn't seem to be a hiera package for F18 at all: $ sudo yum install hiera Loaded plugins: changelog No package hiera available. Error: Nothing to do It looks like the initial version of it is still in testing: https://admin.fedoraproject.org/updates/FEDORA-2012-15005/hiera-1.0.0-3.fc18 Regards, Rich -- Richard Fearn richardfe...@gmail.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: Mass rebuild for Fedora 18 Complete
> Please fix any packages you maintain that failed to rebuild. findbugs failed to build (http://koji.fedoraproject.org/koji/buildinfo?buildID=333451), but I've now fixed and rebuilt it (http://koji.fedoraproject.org/koji/buildinfo?buildID=344787). eclipse-findbugs rebuilt OK without any changes (http://koji.fedoraproject.org/koji/buildinfo?buildID=333103). Regards, Rich -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)
> Orphan notecase I think this one is being retired due to a FTBFS, which could easily be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=716193#c7 Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)
Hi, > Orphan whowatch I've taken this one. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting more info about updates on headless server
This: > yum install yum-security or possibly this: > ...there is also a changelog plugin/command is what I'm after. I'm going to have a look at those. Thanks James! (Thanks to Przemek and Seth, too - but I want information about all currently-available updates, not just a particular one.) Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Getting more info about updates on headless server
Hi, I have yum-updatesd installed on a headless Fedora server, so every so often I get the email saying there are updates available. The email itself doesn't tell me much about the updates (e.g. for iproute tonight it said it was a "bugfix"). Running yum update on the server doesn't tell me much either. In the past I modified yum-updatesd-helper to look in the package-announce list archives (http://lists.fedoraproject.org/pipermail/package-announce/) to find each update, and to build a bodhi search URL, using the package name/version. Then there were at least 1 or 2 links in the yum-updatesd email that I could click on to get some more information. Is there a more standard way of getting this info? (Not the links, but the information about the updates.) If not, I'll get my modified yum-updatesd-helper working on F13 (I upgraded from F11 the other day). Regards, Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
>> I just made a couple of tweaks to the "Join" page: >> >> https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainers&diff=186902&oldid=185877 >> https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainers&diff=186903&oldid=186902 >> >> which makes the two sections more consistent. There still seems to be >> unnecessary duplication, though: they both say that you should check >> that the package is new. I was thinking of getting rid of this >> duplication - can I go ahead and make this (fairly minor) change? > > Sounds fine to me. Now done: https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainers&diff=187036&oldid=186903 I also moved a couple of items up, as I think it makes sense to check retired packages and forbidden items at the same time as checking existing packages and those being reviewed. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Hi, >> One of the links on spot's "Package Review Process" page >> (https://fedoraproject.org/wiki/Package_Review_Process) doesn't work - >> the Review Tracker equivalent to "Packages Currently Under Review" (it >> links to REVIEW.html but that doesn't exist). > > Odd. it works fine here. > > Which exact link? > http://fedoraproject.org/PackageReviewStatus/REVIEW.html ? That's the one. > Oh, I see... it's not updating. Right. I get a 404 when accessing it. The page says "Sorry! We couldn't find that file". >> I was thinking of getting rid of this >> duplication - can I go ahead and make this (fairly minor) change? > > Sounds fine to me. OK, I'll do it. Regards, Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
Hi, > [richardfearn] findbugs-bcel: findbugs-bcel-javadoc-5.2-1.3.8.fc12.1.x86_64 findbugs-bcel and findbugs-bcel-javadoc can be installed independently, so I've added licence files to the -javadoc subpackage. Thanks for your work! Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
I'm a bit late joining this discussion, but did notice a couple of issues relating to review request links. One of the links on spot's "Package Review Process" page (https://fedoraproject.org/wiki/Package_Review_Process) doesn't work - the Review Tracker equivalent to "Packages Currently Under Review" (it links to REVIEW.html but that doesn't exist). I'm currently working on a txt2regex package, and that doesn't currently appear in any of the Review Tracker lists - because it's not NEW (someone has assigned it to themselves), I don't need a sponsor, and it's not a merge review. I realise there's a search box on the Review Tracker page, but now that the "Join the package collection maintainers" page has been changed to link to the Review Tracker (instead of linking to https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests), it might be good to get the REVIEW.html list working. (The search criteria in the two links on the ReviewRequests wiki page did seem, at least to me anyway, to give pretty good coverage of all review requests, whatever their state.) Perhaps someone with more power than me could get this REVIEW.html page working again :-) I just made a couple of tweaks to the "Join" page: https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainers&diff=186902&oldid=185877 https://fedoraproject.org/w/index.php?title=Join_the_package_collection_maintainers&diff=186903&oldid=186902 which makes the two sections more consistent. There still seems to be unnecessary duplication, though: they both say that you should check that the package is new. I was thinking of getting rid of this duplication - can I go ahead and make this (fairly minor) change? Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
> At present the script opens over 300 windows, which have to be closed > manually. I coudn't think of an automatic way of closing them; how does > AutoQA going to deal with the problem of testing GUI apps? I think wmctrl would help here. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
Hi, Thanks for this. Just a couple of points: The package name is converted to lower case. Should it be doing that? For example, the jFormatString opt-in files are in /srv/people/site/packages/j/jformatstring. Also autoqa-optin doesn't validate the package name: I missed it out at one point and ended up creating files in /srv/people/site/packages/d/devel. I've cleared them up now :-) Regards, Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remove of
Hi > it may be nice, if anyone can tell me since which kernel release > the file was removed. 2.6.32. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fc5377668c3d808e1d53c4aee152c836f55c3490 Regards Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comaintainers or maintainers sought
Hi, > I changed jobs about a year ago and, as a result, no longer use a > number of packages that I maintain. > eclipse-findbugs > findbugs > findbugs-bcel > findbugs-contrib (actually a separate project) > jFormatString (no activity since initial October 2008 release) > jcip-annotations (almost no activity since 2006) > jsr-305 I do use FindBugs, so I'd be happy to take over as maintainer of these seven. Regards Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
