packaging June 2007

packaging@lists.fedoraproject.org

33 participants
36 discussions

Re: [Fedora-packaging] License issue for all GIS related packages. [call for help]
by Tom Callaway 25 Jun '07

25 Jun '07

On Tue, 2007-06-26 at 00:35 +0200, Balint Cristian wrote: > Pardon me if i mistake here, a _non_ lawyer point of view: > > Here arised in my mind that epsg tables ar not similar as PCI ID > plain only database, a new entry in that database need certain > certification and probaly very precise technical mesurments before it > can > be validated and ratified. I dont think anyone can easy do this step, > like just PCI-ID ones. EPSG asummed this task to collect cand > ertificate those > constants and projections in the past. The process is not an easy one > as far > I understanded, but this is only the technical side. That could be > olso the strong > reason to not let those constants to be altered in some way. > > Please correct me if i mistakenly miss understood that EPSG > activity from > tech point of view. Just wanted make some comment over certain value > of > database. I think that there are several good parallels here, the most obvious seems to be that of the GNU Free Documentation License (GFDL), specifically section 4, which permits modification, but also describes what you must do as the end result of modification. Another good example is the Bitstream Font License. Bitstream wanted to make their Fonts available for the Free Software community, and to permit people to make derived fonts from Bitstream fonts, but they didn't want people selling the fonts standalone, or referring to any derived fonts as "Bitstream". Here is their license, in its entirety: ====================== Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license (“Fonts”) and associated documentation files (the “Font Software”), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions: The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces. The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words “Bitstream” or the word “Vera”. This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the “Bitstream Vera” names. The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. Except as contained in this notice, the names of Gnome, the Gnome Foundation, and Bitstream Inc., shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Font Software without prior written authorization from the Gnome Foundation or Bitstream Inc., respectively. For further information, contact: fonts at gnome dot org. ====================== So, to sum it up, here's what we would like to see: The license needs to permit people to create derived works of the EPSG dataset. Simply because we cannot fathom any possible derived works does not mean that the right should be withheld. This is at the very heart of open source and free software. However, it is perfectly acceptable to say that those derived works may not call themselves the EPSG dataset. If we can get that, we can include the EPSG dataset in Fedora. :) ~spot

3 2

License issue for all GIS related packages. [call for help]
by Balint Cristian 25 Jun '07

25 Jun '07

Hello folks, All GIS packages (from fedora-extras now fedora) suffer a missing of geodetic constants sets from www.epsg.org (very important for GIS otherwise) becouse of license issues. I personaly tried to add some packages to fedora and maintain those, but basicly some of tham are pure repack of tarballs and removal of some doubted piece of code. I am a GIS fan, i tryed my very best to shape and polish up all GIS related packages and its related libs: ogdi, gdal, grass, mapserver, but without geodetic constants is like in math trigonometry without PI constant ... Its very frustrating that tons of GIS code depends on a simple collection of 'constants' like PI one from math, in a simple excel like file ... The problem, more exactly, is with this dataset aviable at: http://www.epsg.org, (the organisation who collected datasets and made them aviable), under EPSG Version 6.12 Online Documentation there is an 'Use of data' section with the license, you can follow it to read. The hurting license text is: 3. The data may not be distributed for profit by any third party; After some mail excenge between OSSgeo (http://www.ossgeo.org) chairman who is olso very interested as open source party of GIS, me and other folks, EPSG proposed a draft and called OSgeo to review it. Fortunatley OSgeo has no lawyer they kindly pass this away with the reason that they are not lawyers too :) and the whole thing remain stalled. I would like if someone look into attached proposal from OSgeo, and if its OK i would like to invite him to help me out in a possible discuss with Roger Lott (chairman of EPSG) as per a good law technical one. I attach the new version of license draft proposed by EPSG itself, a preliminary verdict that validate its usability for open source scope would be fine , before start to talk with EPSG ... BTW, There is extremly nice and powerfull GIS software, like http://grass.itc.it/ wich can easy compete GIS software giant: http://www.esri.com. This would be great if happen :) /christian

2 2

Update to php-eaccelerator and how to make it "just work"
by Matthias Saou 25 Jun '07

25 Jun '07

Hi, I'm currently cleaning up the php-eaccelerator package. It has been in Fedora since the very beginning and I'm pretty sure it never went through any review (straight from freshrpms). The major change I have to do is "fix" the version : "5.2.3_0.9.5.1" has to become plain "0.9.5.1" ...so I'll have to introduce and epoch :-( The problem is historical, as the module had to track the main php package's version quite closely, back when the zend_abi version wasn't provided by the php package, and this ugly trick was an easy way for end users to know if the package was the correct one. Anyway, I'll be doing that unless someone objects ;-) The next issue is that the cache files created by the module are stored in /var/cache/php-eaccelerator/ and the ownership of that directory is hardcoded to apache:apache in the package. This is a problem when using php with another web server, lighttpd for instance (which I do a lot). It's even worse when using multiple web servers on the same machine... I'd like the find a clean solution for this. The only one I can think of is to have php-eaccelerator create its own group in which it'll put apache, lighttpd and eventually others, and have the cache directory owned by "root:eacceler" (it's better with only 8 chars, right?) and set g+S. This way, all web servers should be able to write and read cache files. I was also thinking of adding the web server users to the group by using triggers in the php-eaccelerator package. Does this seem sane to do? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.72 0.81 0.81

4 6

Hardlinking *.pyc and *.pyo
by Ville Skyttä 19 Jun '07

19 Jun '07

Hello, Related to recent space saving discussions, I came across PLD's rpm-build-macros package recently, and found that they hardlink identical *.pyc and *.pyo. In a lot of cases, they're the same, and there's some potential for saving some MB "for free", on my FC6 x86_64 box: $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 Would save 11116544 The PLD implementation looks like this: # Hardlink binary identical .pyc and .pyo files # (idea by glen <at> pld-linux <dot> org) %__spec_install_post_py_hardlink {\ %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ if cmp -s "$a" "$b"; then \ ln -f "$a" "$b"; \ fi; \ done \ }; __spec_install_post_py_hardlink } } The use of "cmp" would require diffutils installed. Or the above could be converted to use hardlink instead (which would have to be made sure to be around) or maybe sha1sum (in coreutils, pretty much always around in buildroots). I suppose something like the above could be easily added to redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile or run after it in %__os_install_post. Worth it? Other comments?

5 7

Proposal: Allow upstream VCS commit ID in alphatag
by Jason L Tibbitts III 18 Jun '07

18 Jun '07

I have drafted http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs and added it to the schedule. The proposal is simply to add the following text to the naming guidelines to the "Snapshot packages" section: If the upstream revision control system provides some sort of unique commit identifier, it may be appended to the `%{alphatag}`: {{{ YYYYMMDDsvn12345 YYYYMMDDgit5aef11739b }}} This has been in use for a while in a few instances, so it would be good to consider it officially. - J<

1 0

Possible UsersAndGroupsDraft
by Tom Callaway 15 Jun '07

15 Jun '07

I'm not quite sure I'm ready to bring this to the FPC for a vote, but I've been working on a modified version of Ville's draft: http://fedoraproject.org/wiki/TomCallaway/UsersAndGroupsDraft While this is more complicated, I think it more adequately covers the corner cases of adding users and groups. Thoughts? ~spot

9 32

ocaml signature hashing: really neccessary?
by Axel Thimm 15 Jun '07

15 Jun '07

I wonder whether this is maybe overdesigned. AFAIU this signature hashing was made because ocaml is not considered stable enough to carry over signatures from release to release. Same could be told about hundreds of C libraries, wouldn't the neccessity in ocaml then imply a neccessity to hash C-library APIs as well? Maybe it's something we will consider to do someday, but the order would be to cater for C/C++/Fortran/etc libraries first and then for niche languages like ocaml. I think it's a bit too much, or did I miss something important (I'm not a real ocaml user, there is just this one application that even justifies ocaml's existance ;) -- Axel.Thimm at ATrpms.net

2 2

Re: native code incompatibilities vs byte code incompatibilities
by Richard Jones 15 Jun '07

15 Jun '07

On Fri, Jun 15, 2007 at 11:19:30AM +0100, Stefano Zacchiroli wrote: > On Fri, Jun 15, 2007 at 11:02:31AM +0100, Richard Jones wrote: > > OK, I see the point now. I had assumed -- wrongly -- that the hash of > > a.cmo would change in this case, but it does not. So we need a > > version of ocamlobjinfo which can handle *.cmx files as well. > > Right, that's our issue to. Maybe now we are two different large > distribution we have more power to go and ask INRIA for this? > > Julien: can you refresh our memory about the tool (IIRC) you spotted in > the OCaml sources able to extract info from *.cmx files? > > > There is another problem with ocamlobjinfo too. See: > > http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en& > > > > In Fedora we have avoided this by having a list of modules in the > > standard library which we just ignore (Asttypes, Outcometree and > > Cmo_format so far). > > Ok, maybe we can keep it on a shared wiki page to ease of maintenance? Yup, I don't mind. Rich. -- Richard Jones Red Hat

1 0

Re: native code incompatibilities vs byte code incompatibilities
by Richard Jones 15 Jun '07

15 Jun '07

On Fri, Jun 15, 2007 at 10:04:44AM +0100, Stefano Zacchiroli wrote: > On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote: > > > > Still, native code objects can break link time compatibility with > > > > compatible .cmis. > > > I don't understand - why is this? > > I'll try to reproduce the problem in a sandbox... > > Ok, here is an example and an explanation: > > $ cat a.ml b.ml main.ml > (* a.ml *) > let foo () = 1 > (* b.ml *) > let bar () = A.foo () + 1 > (* main.ml *) > print_int (B.bar ()) > $ # let's build in bytecode and nativecode (with inlining) > $ ocamlc -c a.ml > $ ocamlc -c b.ml > $ ocamlc -o a.byte a.cmo b.cmo main.ml > $ ocamlopt -inline 100 -c a.ml > $ ocamlopt -inline 100 -c b.ml > $ ocamlopt -o a.native a.cmx b.cmx main.ml > $ # now let's change the *implementation* of module A and recompile that module only > $ sed -i s/1/2/ a.ml > $ ocamlc -c a.ml > $ # relinking in bytecode work, i.e. assumptions over interfaces are respected > $ ocamlc -o a.byte a.cmo b.cmo main.ml > $ # relinking in nativecode fails, i.e. assumptions over implementations are not respected > $ ocamlopt -inline 100 -c a.ml > $ ocamlopt -o a.native a.cmx b.cmx main.ml > Files b.cmx and a.cmx make inconsistent assumptions over implementation A > > The rationale is that with inlining enabled, ocamlopt when building > module B has embedded in it implementations coming from module A. If > that is changed module B needs to be rebuilt as well. > > Now: do you have a way to inspect native code objects for extracting > assumptions related to module implementations? Cause we have been so far > able only to extract assumption about interfaces... OK, I see the point now. I had assumed -- wrongly -- that the hash of a.cmo would change in this case, but it does not. So we need a version of ocamlobjinfo which can handle *.cmx files as well. There is another problem with ocamlobjinfo too. See: http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en& In Fedora we have avoided this by having a list of modules in the standard library which we just ignore (Asttypes, Outcometree and Cmo_format so far). Rich. -- Richard Jones Red Hat

1 0

Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones 15 Jun '07

15 Jun '07

On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote: > On Fri, Jun 15, 2007 at 08:34:54AM +0100, Richard Jones wrote: > > > Still, native code objects can break link time compatibility with > > > compatible .cmis. > > I don't understand - why is this? > > Out of the box I don't know how to reproduce it, but we have been beaten > by this in the past. IIRC md5sum information stored in native code > objects are not only about interfaces but also about the actual module > implementations. Given that they are not inspectable (ocamlobjinfo only > work on bytecode objects) you have no way to check them. I think we've dealt with this one by depending on the name-version-release of ocaml itself. This makes it an all-or-nothing thing: as on Debian we need to upgrade every OCaml package at the same time. This is causing a problem at the moment because I can't get PXP & CDuce compiled. CDuce upstream have released a full version for OCaml 3.10, but PXP (on which CDuce depends) haven't done so yet. Rich. -- Richard Jones Red Hat

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2007