Re: OpenSlide soname bump in Rawhide

openslide: https://koji.fedoraproject.org/koji/taskinfo?taskID=107428492 Thanks, Adam On Wed, Oct 11, 2023 at 6:23 PM Orion Poplawski wrote: > vtk build submitted: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=107377295 > > Orion > > On 10/11/23 16:17, Benjamin Gilbert wrote: > > Hi

Re: unresponsive maintainer: nss-mdns

> My FAS name is "agoode". > > > Thanks! This worked, thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: unresponsive maintainer: nss-mdns

> On Do, 08.03.18 16:51, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) > wrote: > > > Urks. That form doesn't support searching by real name. Adam, what's > you fedora user name? > My FAS name is "agoode". Thanks! ___ devel mailing list -- deve

Re: unresponsive maintainer: nss-mdns

> On Mon, Mar 05, 2018 at 06:45:35PM -0000, Adam Goode wrote: > > Hi, > > Lennart has the flu, so he'll probably wont' reply immediately. > I'll ping him, but you can expect that he will want to give the > package away. > Thanks,

Re: unresponsive maintainer: nss-mdns

> It looks like you'll be "it" if the maintainers don't respond. Do you > want to be a maintainer? Yes, I can be the maintainer. I'm currently the main upstream contributor: https://github.com/lathiat/nss-mdns/graphs/contributors ___ devel mailing list

unresponsive maintainer: nss-mdns

I am following the unresponsive maintainer policy: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1544608 Does anyone know how to reach the maintainer? Thanks, Adam ___ dev

Package review swap request -- golang-launchpad-go-xdg-v0

https://bugzilla.redhat.com/show_bug.cgi?id=1279660 This is a pre-req for packaging https://github.com/google/cups-connector Happy to take a package to review. Note that I am not a sponsor. Thanks, Adam -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/li

Packaging Google Cloud Print CUPS Connector

Hi, I am working on packaging Google Cloud Print CUPS Connector, which lets you share your CUPS printers with Chrome, Chrome OS, and Android. https://github.com/google/cups-connector This is a small binary that replaces the previous recommended solution of using Chrome in a headless mode. https:/

Re: packaging golang guidelines (like etcd, consul)

On Fri, Nov 06, 2015 at 10:11:08AM -0500, Jakub Cajka wrote: > - Original Message - > > From: "Adam Goode" > > To: devel at lists.fedoraproject.org > > Cc: "Matthew Miller" > > Sent: Friday, November 6, 2015 3:47:42 PM > > Subjec

Re: packaging golang guidelines (like etcd, consul)

On Mon, Nov 02, 2015 at 09:05:09AM -0500, Matthew Miller wrote: > On Sun, Nov 01, 2015 at 05:44:42PM +0100, Jan Chaloupka wrote: > > >are there some fedora guidelines for golang apps? > > >are there macros and helpers for rpm? > > https://fedoraproject.org/wiki/PackagingDrafts/Go > > This needs he

Re: Problems with Ghostscript license switched to AGPL?

> On Tue, 2014-07-29 at 22:40 -0400, Adam Goode wrote: >> I know this is old news, but Ghostscript switched to AGPL with version >> 9.07 (Feb 2013). I was not able to find any announcement of this on >> the Fedora lists. > > Here's the discussion fro

Problems with Ghostscript license switched to AGPL?

Hi, I know this is old news, but Ghostscript switched to AGPL with version 9.07 (Feb 2013). I was not able to find any announcement of this on the Fedora lists. Fedora 18 was the last release with the non-AGPL Ghostscript. This is a surprise, because since Fedora 19 we've possibly introduced a f

golang packaging guidelines

Now that golang is packaged (https://bugzilla.redhat.com/show_bug.cgi?id=950281), we might want to have some packaging guidelines. I have never done this, does anyone want to give it a try? renich has started this but it is quite preliminary: https://fedoraproject.org/wiki/User:Renich/Go_Packagin

Is Raspberry Pi firmware still unsuitable for Fedora?

Is the Raspberry Pi firmware now ok to be packaged in Fedora proper? It looks like the Fedora guidelines for firmware can now include RPi stuff. https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware https://github.com/raspberrypi/firmware/blob/master/boot/LICENCE.broadcom Yes? No? This

Review request for golang

Hi, I have a review request for the "golang" package, which obsoletes the old stale "go" package request. This package compliments the existing gccgo implementation already in Fedora. Someone interested in having the go-based go toolchain in Fedora should review it! https://bugzilla.redhat.com/sh

orphaning xmms-modplug

I'm orphaning xmms-modplug. Free to anyone to take. Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

orphaning fvwm and libstroke

Hi, I am orphaning fvwm and libstroke. It's been fun! Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

releasing ownership of coda stack

Hi, I have not used Coda in some time, so I am going to release ownership of items in the coda stack. The only concern is that EPEL packages won't have an owner, but Coda itself isn't supported there because of the missing kernel module. Adam -- devel mailing list devel@lists.fedoraproject.org

wanting to orphan htmldoc

Hi, I'd like to give up ownership for htmldoc. Please, if anyone is interested, take it. Here are the packages that depend on it: htmldoc-0:1.8.27-13.fc12.src LabPlot-0:1.6.0.2-8.fc12.src diveintopython-0:5.4-18.fc15.src mathomatic-0:15.5.0-1.fc15.src mlton-0:20100608-3.fc15.src (my packa

leaving packages "python-gdata" and "googlecl"

I don't have time to maintain python-gdata nor googlecl. python-gdata seems well covered, so I will just remove myself. googlecl has a single other maintainer for all but EPEL. I will remove myself there as well, but it would be good if others could take maintainership, especially for EPEL. Than

removing myself from debootstrap

Hi, I don't have time to help with debootstrap, and it looks like others are doing a great job already, so I'm removing myself from the ACLs. Adam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gcc -ffunction-sections -Wl,--gc-sections

On Thu, Mar 24, 2011 at 12:06, Adam Jackson wrote: > On Thu, 2011-03-24 at 15:00 +0100, Jan Kratochvil wrote: >> Hi, >> >> just tried -ffunction-sections -Wl,--gc-sections on F15 xulrunner and got >> libxul.so 24947928 -> 23631640 (5.28% gain) and it still works. >> >> ld.gold --icf is a different

Re: [ACTION REQUIRED] orphaned packages in F-14

On 08/04/2010 12:32 PM, Bill Nottingham wrote: > Each release, we undergo the effort to track down owners for orphaned > packages in the release, and block those orphaned packages where > necessary. It's that time again for Fedora 14. > minirpc was orphaned because development has stopped upstrea

Re: RCS keywords rewritten in dist-git conversion?

On 08/02/2010 01:19 PM, Jesse Keating wrote: > On 8/2/10 7:59 AM, Adam Goode wrote: >> Does this warrant re-converting the package? Or I can fix up the patches >> myself. > > I suspect parsecvs got confused by the contents of the file having RCS > keywords. I could try re

RCS keywords rewritten in dist-git conversion?

Hi, In the package jai-imageio-core, my patches contain RCS keywords that are part of the patch or context. These include $RCSfile$, $Date$, etc. After the dist-git conversion, my patches are now different. It seems that keyword substitution was in effect though it never happened before. The patc

Re: ACLs working with dist-git?

On 08/02/2010 12:22 AM, Kevin Fenzi wrote: > On Sun, 01 Aug 2010 22:04:08 -0400 > Adam Goode wrote: > >> On 08/01/2010 09:32 PM, Kevin Fenzi wrote: >>> rpm -q fedora-packager >>> >>> Are you using a version older than 0.5.0 ? >>> >>&

Re: ACLs working with dist-git?

On 08/01/2010 09:32 PM, Kevin Fenzi wrote: > On Sun, 01 Aug 2010 20:18:38 -0400 > Adam Goode wrote: > >> On 08/01/2010 08:12 PM, Adam Goode wrote: >>> >>> Those were added recently, because I needed to do a bodhi commit. >>> But I definitely was abl

Re: ACLs working with dist-git?

On 08/01/2010 08:12 PM, Adam Goode wrote: > > Those were added recently, because I needed to do a bodhi commit. But I > definitely was able to push even without those ACLs. I could try > revoking my commit ACL (but not ACL ACL) and see what happens. I just revoked my el5 commit ACL,

Re: ACLs working with dist-git?

On 08/01/2010 01:54 PM, Jesse Keating wrote: > On 07/31/2010 05:05 PM, Adam Goode wrote: >> Hi, > >> I only have commit ACLs on el6 and el5 for python-gdata, but it seems I >> am able to push to all branches. Is this correct? My username is "agoode&

ACLs working with dist-git?

Hi, I only have commit ACLs on el6 and el5 for python-gdata, but it seems I am able to push to all branches. Is this correct? My username is "agoode". Thanks, Adam signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapr

orphaning minirpc

I am orphaning minirpc, it is declared deprecated upstream: http://minirpc.cs.cmu.edu/ and we at CMU are not using it anymore for our projects. It also has some never-fixed bugs occasionally triggered by its test suite, related to threading and (probably) use-after-free. Because of this, the test

Re: xmms-modplug orphaned

On 06/23/2010 12:02 PM, Ville Skyttä wrote: > Hello, > > I've just orphaned xmms-modplug. Now that modplugtools is in (#600835) and > ships modplugplay, I have no need for xmms-modplug. Go grab it if you want > it. > I took it. Adam signature.asc Description: OpenPGP digital signature

Re: libjpeg for F14

On 05/25/2010 10:09 AM, Richard W.M. Jones wrote: > Why couldn't we just replace libjpeg with the libjpeg-turbo upstream? > (For the primary architectures anyway). > I think this is a great idea, libjpeg is the bottleneck for a lot of my code. One issue: are there C fallbacks for all the arch-sp

Re: Change to DSO-linking semantics of the compiler

On 01/11/2010 01:45 PM, Charley Wang wrote: > The change will force explicit declaration of links rather than implicitly > detecting links. More detailed info is here: > It would be nice if libtool were also updated to not explicitly link all dependent libraries transitively. rpmlint complains ab