From jkeating at redhat.com Mon May 1 17:09:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 01 May 2006 13:09:35 -0400 Subject: [Fedora-packaging] License Review Message-ID: <1146503375.810.67.camel@dhcp83-49.boston.redhat.com> IANAL, so I need somebody to help me review this license to see if we can include software licensed by this. I'm going to put up a package review request for metasploit version 2.5, as the 2.x tree is licensed with Perl Artistic/GPL, however the developmental branch, metasploit 3.0 is licensed with a new license to try and protect themselves from the difficulties recently experienced by nessus and snort. Can you look over http://www.metasploit.com/projects/Framework/msf3/download.html?Release=alpha-r3 for The Metasploit Framework License v1.0 ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Mon May 1 18:19:12 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 1 May 2006 14:19:12 -0400 Subject: [Fedora-packaging] License Review In-Reply-To: <1146503375.810.67.camel@dhcp83-49.boston.redhat.com> References: <1146503375.810.67.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060501181912.GA7099@jadzia.bu.edu> On Mon, May 01, 2006 at 01:09:35PM -0400, Jesse Keating wrote: > Can you look over > http://www.metasploit.com/projects/Framework/msf3/download.html?Release=alpha-r3 for The Metasploit Framework License v1.0 ? Without going into legal technicalities, that license clearly has the following problems: - Commercial use restricted (2b) -- Can't be used in any commercial application or product. - Anti-forking clause (4) -- Modifications must be distributed separately, as patches -- no forking. Technically, that's what good RPMs do anyway, but this doesn't meet the normal standards for Free or Open Source software. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Mon May 1 18:22:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 01 May 2006 13:22:07 -0500 Subject: [Fedora-packaging] License Review In-Reply-To: <20060501181912.GA7099@jadzia.bu.edu> References: <1146503375.810.67.camel@dhcp83-49.boston.redhat.com> <20060501181912.GA7099@jadzia.bu.edu> Message-ID: <445651CF.60506@math.unl.edu> Matthew Miller wrote: > On Mon, May 01, 2006 at 01:09:35PM -0400, Jesse Keating wrote: > >>Can you look over >>http://www.metasploit.com/projects/Framework/msf3/download.html?Release=alpha-r3 for The Metasploit Framework License v1.0 ? > Without going into legal technicalities, that license clearly has the > following problems: > - Commercial use restricted (2b) -- Can't be used in any commercial application or > product. Yep. This one is a deal-breaker for inclusion in Fedora. -- Rex From jkeating at j2solutions.net Mon May 1 18:28:47 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 01 May 2006 14:28:47 -0400 Subject: [Fedora-packaging] License Review In-Reply-To: <445651CF.60506@math.unl.edu> References: <1146503375.810.67.camel@dhcp83-49.boston.redhat.com> <20060501181912.GA7099@jadzia.bu.edu> <445651CF.60506@math.unl.edu> Message-ID: <1146508127.810.88.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-01 at 13:22 -0500, Rex Dieter wrote: > > Without going into legal technicalities, that license clearly has the > > following problems: > > - Commercial use restricted (2b) -- Can't be used in any commercial application or > > product. > > Yep. This one is a deal-breaker for inclusion in Fedora. Ok, they were afraid of that, but knew it was a possibility. However they really want to prevent incorporation of the framework into a commercial product. They really just don't want people to sell it, even if they contribute back. Oh well, the 2.5 tree is usable and has an acceptable license. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Mon May 1 18:37:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 01 May 2006 13:37:13 -0500 Subject: [Fedora-packaging] License Review In-Reply-To: <1146508127.810.88.camel@dhcp83-49.boston.redhat.com> References: <1146503375.810.67.camel@dhcp83-49.boston.redhat.com> <20060501181912.GA7099@jadzia.bu.edu> <445651CF.60506@math.unl.edu> <1146508127.810.88.camel@dhcp83-49.boston.redhat.com> Message-ID: <44565559.6070700@math.unl.edu> Jesse Keating wrote: > On Mon, 2006-05-01 at 13:22 -0500, Rex Dieter wrote: > >>>Without going into legal technicalities, that license clearly has the >>>following problems: >>>- Commercial use restricted (2b) -- Can't be used in any commercial application or >>> product. >> >>Yep. This one is a deal-breaker for inclusion in Fedora. > > > Ok, they were afraid of that, but knew it was a possibility. However > they really want to prevent incorporation of the framework into a > commercial product. That's unfortunate. It's #1 on the opensource criteria on opensource.org: http://www.opensource.org/docs/definition.php 1. Free Redistribution The license shall not restrict any party from selling or giving away the software... -- Rex From Axel.Thimm at ATrpms.net Thu May 4 08:34:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 May 2006 10:34:45 +0200 Subject: [Fedora-packaging] Re: xorg-x11- packaging prefix In-Reply-To: <1146718221.4263.10.camel@thl.ct.heise.de> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> <1146718221.4263.10.camel@thl.ct.heise.de> Message-ID: <20060504083445.GC22088@neu.nirvana> On Thu, May 04, 2006 at 06:50:21AM +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 04.05.2006, 02:52 +0200 schrieb Axel Thimm: > > On Thu, May 04, 2006 at 02:39:42AM +0200, Axel Thimm wrote: > > > On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian H?gsberg wrote: > > > > Axel Thimm wrote: > > > > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > > > > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > > > > >>>Axel Thimm wrote: > > > > >>>>Should packages with source from outside of the xorg-x11 tree carry > > > > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > > > >>>>often used "for " or is it a cendor prefix, e.g. "by > > > > >>>>"? > > > > >>>> > > > > >>>>How would a 3rd party driver package be best named? > > > > >>>>xorg-x11-drv- or <3rd-party-vendor>-drv-? > > > > >>>> > > > > >>>I would say use > > > > >>> > > > > >>>xorg-x11-drv- > > > > >>> > > > > >>>the second one only confuses users. > > > > >>but xorg-x11 is the name of the upstream vendor, and probably > > > > >>trademarked or close to that. So I would suggest to not do that; even if > > > > >>it's not a legal trademark, it makes sure that users realize where it > > > > >>comes from (and thus where to report bugs ;) > > > > > > > > > >Which brings us back to the question, does the prefix really imply "by > > > > >" or "for ". Usually in packaging practice > > > > >"-foo" means foo built for , e.g. the miriads of > > > > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > > > > >other module- or plugin-type packages. > > > > >I don't mind either way, I just want to hear a clear statement from > > > > >the X11 packaging folks. Personally I tend to hear the sound of the > > > > >vendor in it, but I see many folks suggesting to use it as a domain > > > > >prefix. That's why I'm bringing it up. > > > > It's used in a 'by' sense, notice that we have other out of tree drivers > > > > in the distribution already: synaptics and linuxwacom. > > > OK, thanks, that was what I was looking for. So oot drivers have free > > > nomenclature (e.g. following the project's name), and when (if) they > > > enter xorg-x11 they become canonicalized to xorg-x11-drv-foo. > > > Maybe I should toss it to fedoraproject.org's wiki somehwere. > > I've added an entry to > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > > > "Addon Packages (x11 drivers)" > > No offense, but I removed it again. Changes to these kind of documents > are best (read "best" -- not "have to be") discussed with FESCo, on > fedora-packaging and/or with spot, the original author and maintainer of > this document and the Packaging Guidelines in general. No problem, discuss it in FESCo and then add it again. :) I've added fedora-packaging and spot in the Cc. > BTW: Shortly before FC5 was released there was a irc-discussion > regarding the package naming of the proprietary nvidia and fglrx > drivers. It was on #fedora-extras (spot was involved in that discussion, > too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg > drivers". And that's what livna did for FC5 then. > > We should probably discuss this during the next FESCo-Meeting with spot. We know that Fedora Extras and Fedora Core don't yet have identical packaging rules, but they are converging. Wrt new packaging rules one should discuss it with both sides, e.g. ask the x11 maintainers at FC who introduced that prefix what the purpose of the prefix is like done in this thread. Creating new divergent views isn't helpful, I'd say either convince FC's x11 folks to change their mind or follow along. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Thu May 4 12:40:01 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 04 May 2006 08:40:01 -0400 Subject: [Fedora-packaging] Re: xorg-x11- packaging prefix In-Reply-To: <20060504083445.GC22088@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> <1146718221.4263.10.camel@thl.ct.heise.de> <20060504083445.GC22088@neu.nirvana> Message-ID: <1146746401.1323.42.camel@yoda.loki.me> On Thu, 2006-05-04 at 10:34 +0200, Axel Thimm wrote: > We know that Fedora Extras and Fedora Core don't yet have identical > packaging rules, but they are converging. For new packages, the rules are exactly the same. In fact, I altered the rules slightly to remove references to "extras" or "core" so that they are generic Fedora Packaging Guidelines that can apply to any sub-project that so chooses. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Wed May 17 21:01:34 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 17 May 2006 15:01:34 -0600 Subject: [Fedora-packaging] Non standard locations for man pages Message-ID: <446B8F2E.5020908@cora.nwra.com> In an effort to package up multiple MPI libraries (LAM-MPI, Open-MPI, and MPICH2), we're running into a number of issues with file conflicts. The current strategy is to move many things into /usr/share/%{name}. However, man pages put in /usr/share/%{name}/man are not compressed. Should I just file a bug against /usr/lib/rpm/brp-compress (rpm-build) to add that pattern? Current list is: for d in ./usr/man/man* ./usr/man/*/man* ./usr/info \ ./usr/share/man/man* ./usr/share/man/*/man* ./usr/share/info \ ./usr/kerberos/man ./usr/X11R6/man/man* ./usr/lib/perl5/man/man* \ ./usr/share/doc/*/man/man* ./usr/lib/*/man/man* Or should the man pages go elsewhere? Anything I should do in the meantime to compress the man pages manually if this is the right location until rpm-build is fixed? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From Axel.Thimm at ATrpms.net Wed May 17 21:47:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 17 May 2006 23:47:24 +0200 Subject: [Fedora-packaging] Re: Non standard locations for man pages In-Reply-To: <446B8F2E.5020908@cora.nwra.com> References: <446B8F2E.5020908@cora.nwra.com> Message-ID: <20060517214724.GD17312@neu.nirvana> On Wed, May 17, 2006 at 03:01:34PM -0600, Orion Poplawski wrote: > In an effort to package up multiple MPI libraries (LAM-MPI, Open-MPI, > and MPICH2), we're running into a number of issues with file conflicts. > The current strategy is to move many things into /usr/share/%{name}. > However, man pages put in /usr/share/%{name}/man are not compressed. What about /usr/share/doc/*/man/man* (from the list below)? > Should I just file a bug against /usr/lib/rpm/brp-compress (rpm-build) > to add that pattern? Current list is: > > for d in ./usr/man/man* ./usr/man/*/man* ./usr/info \ > ./usr/share/man/man* ./usr/share/man/*/man* ./usr/share/info \ > ./usr/kerberos/man ./usr/X11R6/man/man* ./usr/lib/perl5/man/man* \ > ./usr/share/doc/*/man/man* ./usr/lib/*/man/man* > > Or should the man pages go elsewhere? > > Anything I should do in the meantime to compress the man pages manually > if this is the right location until rpm-build is fixed? > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu May 18 15:03:23 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 18 May 2006 10:03:23 -0500 Subject: [Fedora-packaging] Non standard locations for man pages In-Reply-To: <446B8F2E.5020908@cora.nwra.com> References: <446B8F2E.5020908@cora.nwra.com> Message-ID: <1147964603.20451.45.camel@localhost.localdomain> On Wed, 2006-05-17 at 15:01 -0600, Orion Poplawski wrote: > In an effort to package up multiple MPI libraries (LAM-MPI, Open-MPI, > and MPICH2), we're running into a number of issues with file conflicts. > The current strategy is to move many things into /usr/share/%{name}. > However, man pages put in /usr/share/%{name}/man are not compressed. > > Should I just file a bug against /usr/lib/rpm/brp-compress (rpm-build) > to add that pattern? Current list is: > > for d in ./usr/man/man* ./usr/man/*/man* ./usr/info \ > ./usr/share/man/man* ./usr/share/man/*/man* ./usr/share/info \ > ./usr/kerberos/man ./usr/X11R6/man/man* ./usr/lib/perl5/man/man* \ > ./usr/share/doc/*/man/man* ./usr/lib/*/man/man* > > Or should the man pages go elsewhere? > > Anything I should do in the meantime to compress the man pages manually > if this is the right location until rpm-build is fixed? Well, keep in mind that man won't look in /usr/share/*/man as configured in the fedora man package. (Look in /etc/man.config for confirmation of this). This will need to be fixed at the same time as /usr/lib/rpm/bmp-compress. It also won't look in /usr/share/doc/*/man (but rpm is configured for it). I don't care which one we use, but either one will require changes to the man package configuration. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From orion at cora.nwra.com Thu May 18 15:59:57 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 18 May 2006 09:59:57 -0600 Subject: [Fedora-packaging] %doc and docdir conflicts Message-ID: <446C99FD.1030401@cora.nwra.com> Where is the appropriate place to put documentation that a package will install during %install in the location specified by --docdir? I've tried using %{_docdir}/%{name}-%{version}, but the %doc macro will clean out that directory before copying over any files listed, wiping out anything installed during %install. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rdieter at math.unl.edu Thu May 18 16:07:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 May 2006 11:07:01 -0500 Subject: [Fedora-packaging] %doc and docdir conflicts In-Reply-To: <446C99FD.1030401@cora.nwra.com> References: <446C99FD.1030401@cora.nwra.com> Message-ID: <446C9BA5.6070302@math.unl.edu> Orion Poplawski wrote: > Where is the appropriate place to put documentation that a package will > install during %install in the location specified by --docdir? I've > tried using %{_docdir}/%{name}-%{version}, but the %doc macro will clean > out that directory before copying over any files listed, wiping out > anything installed during %install. It's an either/or thing. You either let %install put the stuff in %{_docdir}/%{name}-%{version} *or* you do it manually with %doc. If you want/need stuff done in %install, you need to put it somewhere else. -- Rex From ville.skytta at iki.fi Sat May 20 09:07:08 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 20 May 2006 12:07:08 +0300 Subject: [Fedora-packaging] Debuginfo packages Message-ID: <1148116028.2765.64.camel@localhost.localdomain> FYI, I wrote a packager info blurb about debuginfo packages, see http://fedoraproject.org/wiki/Packaging/Debuginfo Potential problem cases, see roughly < 10kB files at: http://mirrors.kernel.org/fedora/core/development/i386/debug/?C=S;O=A http://mirrors.kernel.org/fedora/extras/development/i386/debug/?C=S;O=A (download.fedora.redhat.com's dir indexes aren't sortable) I've reported bugs against a bunch of Extras packages lately and some of have been already fixed. Sanity checking debuginfo packages would also be an useful addition to the packaging/reviewing guidelines IMO, so I added it to Packaging/GuidelinesTodo in Wiki. The next upstream version of rpmlint (> 0.76) will also have a check for empty debuginfo packages. From fedora at leemhuis.info Sat May 20 10:11:06 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 20 May 2006 12:11:06 +0200 Subject: [Fedora-packaging] Debuginfo packages In-Reply-To: <1148116028.2765.64.camel@localhost.localdomain> References: <1148116028.2765.64.camel@localhost.localdomain> Message-ID: <1148119866.2289.10.camel@localhost.localdomain> Am Samstag, den 20.05.2006, 12:07 +0300 schrieb Ville Skytt?: > FYI, I wrote a packager info blurb about debuginfo packages, see > http://fedoraproject.org/wiki/Packaging/Debuginfo thx >[...] > I've reported bugs against a bunch of Extras packages lately and some of > have been already fixed. Sanity checking debuginfo packages would also > be an useful addition to the packaging/reviewing guidelines IMO, so I > added it to Packaging/GuidelinesTodo in Wiki. Yeah, probably. /me hopes that the list doesn't get longer and longer over time. > The next upstream version > of rpmlint (> 0.76) will also have a check for empty debuginfo packages. We should probably work towards a solution where we run rpmlint or other checks (rpath) automatically in the buildsystem (or on a separate machine). CU thl -- Thorsten Leemhuis From rc040203 at freenet.de Sat May 20 11:37:48 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 20 May 2006 13:37:48 +0200 Subject: [Fedora-packaging] Debuginfo packages In-Reply-To: <1148116028.2765.64.camel@localhost.localdomain> References: <1148116028.2765.64.camel@localhost.localdomain> Message-ID: <1148125068.882.96.camel@mccallum.corsepiu.local> On Sat, 2006-05-20 at 12:07 +0300, Ville Skytt? wrote: > FYI, I wrote a packager info blurb about debuginfo packages, see > http://fedoraproject.org/wiki/Packaging/Debuginfo > > Potential problem cases, see roughly < 10kB files at: > http://mirrors.kernel.org/fedora/core/development/i386/debug/?C=S;O=A > http://mirrors.kernel.org/fedora/extras/development/i386/debug/?C=S;O=A > (download.fedora.redhat.com's dir indexes aren't sortable) You might want to add https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422 Toshio is dead right, rpmbuild doesn't generate debuginfos if %build is missing. So far all of my local RPMs which exposed this issue were lacking %build. > I've reported bugs against a bunch of Extras packages lately and some of > have been already fixed. Sanity checking debuginfo packages would also > be an useful addition to the packaging/reviewing guidelines IMO, so I > added it to Packaging/GuidelinesTodo in Wiki. The next upstream version > of rpmlint (> 0.76) will also have a check for empty debuginfo packages. You could consider to add a check for missing %build Ralf From Matt_Domsch at dell.com Sat May 20 14:54:20 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 20 May 2006 09:54:20 -0500 Subject: [Fedora-packaging] Debuginfo packages In-Reply-To: <1148119866.2289.10.camel@localhost.localdomain> References: <1148116028.2765.64.camel@localhost.localdomain> <1148119866.2289.10.camel@localhost.localdomain> Message-ID: <20060520145420.GD27962@lists.us.dell.com> On Sat, May 20, 2006 at 12:11:06PM +0200, Thorsten Leemhuis wrote: > We should probably work towards a solution where we run rpmlint or other > checks (rpath) automatically in the buildsystem (or on a separate > machine). agreed. I'm running both rpmlint and rpmdiff against all packages as part of the "rebuild core in mock" project. http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Each package has an 'rpmlint.log' and an 'rpmdiff.log' (against Red Hat buildsystem-made packages) file in its result/ directory. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From mpeters at mac.com Wed May 24 07:20:59 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 24 May 2006 00:20:59 -0700 Subject: [Fedora-packaging] teTeX is EOL Message-ID: <1148455260.16995.29.camel@atlantis.mpeters.local> tetex has been EOL'd by upstream. I don't know what the Red Hat maintainer intends to do for FC6 - but clearly at some point the bit rot is going to demand moving to something else, probably texlive (which is what Debian is doing). I'm assuming this means a namespace change for tetex packages. I personally would suggest a namespace that is tex distribution neutral. The TDS is pretty much what all modern open source tex implementations follow and are going to follow, so it makes sense (to me anyway) to use a neutral namespace, like maybe texmf or something. thoughts? From tcallawa at redhat.com Wed May 24 13:18:45 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 24 May 2006 08:18:45 -0500 Subject: [Fedora-packaging] teTeX is EOL In-Reply-To: <1148455260.16995.29.camel@atlantis.mpeters.local> References: <1148455260.16995.29.camel@atlantis.mpeters.local> Message-ID: <1148476725.10606.22.camel@localhost.localdomain> On Wed, 2006-05-24 at 00:20 -0700, Michael A. Peters wrote: > tetex has been EOL'd by upstream. > > I don't know what the Red Hat maintainer intends to do for FC6 - but > clearly at some point the bit rot is going to demand moving to something > else, probably texlive (which is what Debian is doing). > > I'm assuming this means a namespace change for tetex packages. > > I personally would suggest a namespace that is tex distribution neutral. > The TDS is pretty much what all modern open source tex implementations > follow and are going to follow, so it makes sense (to me anyway) to use > a neutral namespace, like maybe texmf or something. > > thoughts? Either texmf- or just tex- seem ok to me. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From Axel.Thimm at ATrpms.net Thu May 25 23:34:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 26 May 2006 01:34:59 +0200 Subject: [Fedora-packaging] Re: teTeX is EOL In-Reply-To: <1148476725.10606.22.camel@localhost.localdomain> References: <1148455260.16995.29.camel@atlantis.mpeters.local> <1148476725.10606.22.camel@localhost.localdomain> Message-ID: <20060525233459.GA8389@neu.nirvana> On Wed, May 24, 2006 at 08:18:45AM -0500, Tom 'spot' Callaway wrote: > On Wed, 2006-05-24 at 00:20 -0700, Michael A. Peters wrote: > > tetex has been EOL'd by upstream. > > > > I don't know what the Red Hat maintainer intends to do for FC6 - but > > clearly at some point the bit rot is going to demand moving to something > > else, probably texlive (which is what Debian is doing). > > > > I'm assuming this means a namespace change for tetex packages. > > > > I personally would suggest a namespace that is tex distribution neutral. > > The TDS is pretty much what all modern open source tex implementations > > follow and are going to follow, so it makes sense (to me anyway) to use > > a neutral namespace, like maybe texmf or something. > > > > thoughts? > > Either texmf- or just tex- seem ok to me. I'd drop the namespace on the binaries and have texmf- on the texmf tree components. That's closest to upstream conventions and "upstream distribution" neutral. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri May 26 15:35:24 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 26 May 2006 10:35:24 -0500 Subject: [Fedora-packaging] Re: teTeX is EOL In-Reply-To: <20060525233459.GA8389@neu.nirvana> References: <1148455260.16995.29.camel@atlantis.mpeters.local> <1148476725.10606.22.camel@localhost.localdomain> <20060525233459.GA8389@neu.nirvana> Message-ID: <4477203C.7010908@math.unl.edu> Axel Thimm wrote: > On Wed, May 24, 2006 at 08:18:45AM -0500, Tom 'spot' Callaway wrote: >> On Wed, 2006-05-24 at 00:20 -0700, Michael A. Peters wrote: >>> I personally would suggest a namespace that is tex distribution neutral. >>> The TDS is pretty much what all modern open source tex implementations >>> follow and are going to follow, so it makes sense (to me anyway) to use >>> a neutral namespace, like maybe texmf or something. >>> thoughts? >> Either texmf- or just tex- seem ok to me. > I'd drop the namespace on the binaries and have texmf- on the texmf > tree components. That's closest to upstream conventions and "upstream > distribution" neutral. +1 -- Rex From hanke at brailcom.org Sun May 28 12:22:29 2006 From: hanke at brailcom.org (Hynek Hanke) Date: Sun, 28 May 2006 14:22:29 +0200 Subject: [Fedora-packaging] Accessibility packages (speech-dispatcher + speechd-up) Message-ID: <1148818949.4100.41.camel@chopin> Hello, I'm a part of a group of developers of accessibility for blind and visually impaired. We are working under the project www.freebsoft.org and collaborating basically with all other projects in Free Software accessibility. We are seeking help with RPM packaging of several software components which are now widely used by the handicaped community. Basically, we have a package called Speech Dispatcher which provides access to sound synthesizers via a high-level socket interface SSIP (Speech Synthesis Interface Protocol). There are several tools (clients of speech-dispatcher) already developed and being used: speechd-el (accessibility to Emacs), speechd-up (interface for the Speakup screen reader to software synthesis), driver for Gnome Speech (Gnome accessibility technologies). Also, KDE is planning to migrate its speech services to Speech Dispatcher (via KTTSD) for the KDE4 release. Especially the combination speech-dispatcher/speechd-up/Speakup is used quite a lot by Fedora Core users. Today, Speakup together with Emacspeak are the most widely used accessibility tools for blind people on Free Software. This is the only combination which allows users to use Speakup with software speech synthesis (otherwise many users are using hardware devices too). Already there are available Speakup patched kernel packages for Fedora (Speakup, the console screen reader, works in the kernel). Many users have problems with compiling Speech Dispatcher and SpeechD-Up from source code, but even more with setting up the rc scripts and init.d startup (both packages are meant to be run as system services). I believe the task of creating the packages is not difficult for someone with knowledge of Fedora, our resources are however very limited in accessibility and we are not using Fedora on our machines, so we do not have the necessary experience here in Free-B-Soft. Is there please somebody who would be kind enough to help us and the users of our accessibility tools by creating and maintaining at least these two packages? I can provide all the support and guidance as a developer of these two packages. I'm sorry if this is not the right place to ask. In such case, please tell me where it would be more appropriate. More information about Speech Dispatcher http://www.freebsoft.org/speechd and SpeechD-Up http://www.freebsoft.org/speechd-up as well as other accessibility tools from Free-B-Soft http://www.freebsoft.org/projects More information about the SpeakUp screen reader http://www.linux-speakup.org/ Thank you, Hynek Hanke