any reason why "sdcc" package transforms pgms to non-standard names?
by Robert P. J. Day
i'm not sure if this question is too package-specific for this list,
but i'll take my chances.
for the sake of building "openwrt" on my f8 system, i installed the
"sdcc" (small device c compiler) package. and yet, when i try to
build openwrt, i get:
...
Checking 'sdcc'... failed.
firmwarehotplug: firmwarehotplug requires the SDCC Cross Compiler (sdcc).
...
a quick check of the pre-built tarballs at sdcc.sourceforge.net
shows that the binaries have names like sdcc, sdcpp and so on. but
note the names in the fedora package as installed by yum:
$ rpm -ql sdcc | grep bin
/usr/bin/sdcc-as-gbz80
/usr/bin/sdcc-as-hc08
/usr/bin/sdcc-as-z80
/usr/bin/sdcc-aslink
/usr/bin/sdcc-asx8051
/usr/bin/sdcc-link-gbz80
/usr/bin/sdcc-link-hc08
/usr/bin/sdcc-link-z80
/usr/bin/sdcc-makebin
/usr/bin/sdcc-packihx
/usr/bin/sdcc-s51
/usr/bin/sdcc-savr
/usr/bin/sdcc-sdcc
...
note the additional "sdcc-" prefix that's clearly(?) been added for
the sake of fedora packaging. i'm not sure if this was done to avoid
some sort of name conflict, but it obviously causes the openwrt build
error.
is this kind of transformation relatively common? the build from
the sdcc home page itself uses the regular names, so why is the fedora
packaging rewriting those? does this happen often?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
16 years, 1 month
Re: RFC: mass rebuild results
by Rex Dieter
Karsten Hopp wrote:
> In my opinion rebuilding packages outside of mock should give me packages
> with the same features than the original ones.
Not a 100% reasonable expectation, imo (esp when on a multilib'd buildhost).
That's part of the point of using the minimalist buildroots that mock
provides.
> Should I even bother to start filing the most obvious bugs
Yes(!), especially if your rebuilds highlights missing parts (functionality,
documentation, etc...).
-- Rex
16 years, 1 month
rpaths to libraries in non-standard locations (libperl.so in particular)
by Richard W.M. Jones
In one OCaml package:
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=434630
spec: http://www.annexia.org/tmp/ocaml/ocaml-perl4caml.spec
we link to libperl.so. libperl.so (the Perl runtime) lives in a
strange directory,
eg. /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
or /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
The normal, non-Fedora way to build this package is to include an
rpath in our library and programs so that they can always find
libperl.so at run time[1]. Obviously this rpath is stripped in the
current Fedora package.
So this forces the user of any perl4caml program to set
LD_LIBRARY_PATH explicitly to include the libperl.so directory[2].
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf409884...
My reading of the guidelines is that actually the Perl package is
wrong. It should include an /etc/ld.so.conf.d/perl.conf file giving
the correct path. On the other hand, maybe I should be allowed to
include an rpath in this situation because I really always want to be
linked to that particular libperl.so (not, say, a version from a
different Perl). Or yet another way to fix this would be for
libperl.so to go in a standard directory like %{_libdir}. That might
break Perl programs though.
What's the right way to solve this?
Rich.
*** Note [1] ***
# standard example from the package, as built by the package:
$ ldd examples/test.opt
linux-gate.so.1 => (0x00110000)
libperl.so => /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so (0x00968000)
libresolv.so.2 => /lib/libresolv.so.2 (0x008e3000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00905000)
libdl.so.2 => /lib/libdl.so.2 (0x0052a000)
libm.so.6 => /lib/libm.so.6 (0x004ff000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00249000)
libutil.so.1 => /lib/libutil.so.1 (0x04461000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00531000)
libc.so.6 => /lib/libc.so.6 (0x0038e000)
/lib/ld-linux.so.2 (0x0036b000)
# contains an rpath:
$ chrpath --list examples/test.opt
examples/test.opt: RPATH=/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE:/usr/local/lib
*** Note [2] ***
$ examples/test.bc
Fatal error: cannot load shared library dllperl4caml
Reason: libperl.so: cannot open shared object file: No such file or directory
# installed version of the library has had rpath removed:
$ ldd /usr/lib/ocaml/stublibs/dllperl4caml.so
linux-gate.so.1 => (0x00110000)
libperl.so => not found
libresolv.so.2 => /lib/libresolv.so.2 (0x0011b000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00130000)
libdl.so.2 => /lib/libdl.so.2 (0x0014a000)
libm.so.6 => /lib/libm.so.6 (0x0014f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00178000)
libutil.so.1 => /lib/libutil.so.1 (0x001ab000)
libpthread.so.0 => /lib/libpthread.so.0 (0x001af000)
libc.so.6 => /lib/libc.so.6 (0x001c9000)
/lib/ld-linux.so.2 (0x0036b000)
# so now you have to set LD_LIBRARY_PATH to run a program:
$ LD_LIBRARY_PATH=/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE examples/test.bc
this is loading the 'test.pl' script!
this is the 'return_one' function!
return_one returned 1
adder (3, 4) = 7
this is the 'return_array' function!
array returned: 1 2 3
this is the 'return_one' function!
return_one returned 1
closure returned 12
$a contains 3
TestClass.foo is 1
TestClass.foo is 2
sv_is_undef (undef) = true
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
16 years, 1 month
--excludedocs and packaging guidelines?
by Warren Togami
So a while back there seems to have been agreement that runtime
shouldn't depend on anything marked as %doc because it could be not
installed in cases where --excludedocs is used. For this reason for
example, we moved the RPM GPG keys out of %doc.
http://fedoraproject.org/wiki/Packaging/Guidelines
But I don't see any such rule or even a suggestion in the packaging
guidelines. Should it be in there?
Furthermore I wonder if there should be any rule or suggestion of how
install-info should be used within a %post scriptlet. I see some
packages redirect the output of install-info to /dev/null, and
install-info's man page also describes a --quiet option. Might we
recommend in guidelines the use of this to suppress the warning that
happens when a package is installed with --excludedocs?
Warren Togami
wtogami(a)redhat.com
Installing: info ##################### [ 61/354]
install-info: No such file or directory for /usr/share/info/info-stnd.info
Installing: readline ##################### [ 70/354]
install-info: No such file or directory for /usr/share/info/history.info.gz
install-info: No such file or directory for
/usr/share/info/rluserman.info.gz
Installing: findutils ##################### [ 76/354]
install-info: No such file or directory for /usr/share/info/find.info.gz
Installing: sed ##################### [ 77/354]
install-info: No such file or directory for /usr/share/info/sed.info.gz
Installing: libidn ##################### [ 78/354]
install-info: No such file or directory for /usr/share/info/libidn.info.gz
Installing: parted ##################### [ 80/354]
install-info: No such file or directory for /usr/share/info/parted.info.gz
Installing: cpio ##################### [ 82/354]
install-info: No such file or directory for /usr/share/info/cpio.info.gz
Installing: tar ##################### [ 91/354]
install-info: No such file or directory for /usr/share/info/tar.info.gz
Installing: pinentry ##################### [ 93/354]
install-info: No such file or directory for /usr/share/info/pinentry.info
Installing: which ##################### [ 94/354]
install-info: No such file or directory for /usr/share/info/which.info.gz
Installing: cpp ##################### [ 95/354]
install-info: No such file or directory for /usr/share/info/cpp.info.gz
Installing: diffutils ##################### [124/354]
install-info: No such file or directory for /usr/share/info/diff.info.gz
Installing: coreutils ##################### [165/354]
install-info: No such file or directory for /usr/share/info/coreutils.info
Installing: dirmngr ##################### [191/354]
install-info: No such file or directory for /usr/share/info/dirmngr.info.gz
Installing: gnupg2 ##################### [192/354]
install-info: No such file or directory for /usr/share/info/gnupg.info
Installing: gnash ##################### [217/354]
install-info: No such file or directory for /usr/share/info/gnash_ref.info
install-info: No such file or directory for /usr/share/info/gnash_user.info
16 years, 1 month
Blocking reviews on to be written guidelines?
by Hans de Goede
Hi All,
Yesterday I wrote a mail to the devel list asking to swap some reviews. One of
the persons who responded is Konrad Meyer. The 2 packages he wants me to review
in return are both java packages.
His message got a reply from Lubomir Kundrak, stating that he has a couple fo
java packages under review too, which are currently blocked on F-GUIDELINES,
because the java packaging guidelines are not finished.
I find this somewhat strange and leading to chicken and eggs problems. I find
the current situation with ocaml where with the initial pakage submissions some
draft guidelines (which I helped write a little) were written and then used
during review, moving forward with a best foot forward concept.
I find blocking packages waiting for guidelines counter productive, both in
general and esp. because often first more experience is needed to write
definitive guidelines.
The only important guideline to get right from the start is the naming rules,
as to avoid lots of renames later, which we did with ocaml.
So do we really want package reviews to be stalled waiting for guidelines
issues other then legal ones (which ofcourse must stall until resolved) ?
Esp, with java packages I find this strange as we already have lots of java
packages in the distro, giving plenty example how we currently do java things,
and this seems to work well.
Regards,
Hans
16 years, 1 month
UTF-8 package names
by Toshio Kuratomi
Today the Packaging Committee began a discussion of whether package
names should be allowed to contain the full range of Unicode characters
(encoded as UTF-8) or be restricted to the ASCii subset.
This is a bit of a contentious issue with the Packaging Committee
members split but not yet set in stone about how to proceed.
The main arguments seem to be:
Pro Unicode:
* Upstream knows best what name is most appropriate for their users.
For us to change it locally in Fedora doesn't make much sense.
* We allow Unicode in every other piece of the spec so why not in the
package name?
* We should be shaking out bugs in the handling of Unicode in our
software rather than hiding issues with it.
Pro ASCII:
* Hard to type unicode package names, therefore it is a usability problem.
* Is there a limit? Even if European letters are fine what about Kanji
or Sanskrit?
* Some pieces of software won't handle unicode package names and will
need to be fixed.
One package has been submitted for review with a unicode using package
name and has some applicable comments:
https://bugzilla.redhat.com/show_bug.cgi?id=261881
= Section of Packaging Committee Logs about Unicode Package Names =
(09:32:18 AM) racor: banning non-ascii chars from package names
(09:32:29 AM) spot: racor: eww. is someone actually doing that?
(09:32:39 AM) f13: somebody did a + in a version I thought
(09:32:40 AM) abadger1999: ivazquez sent something to the list. No
actual draft but it was very simple.
(09:32:47 AM) tibbs|h: spot: There's a review submitted.
(09:32:49 AM) svahl left the room (quit: ).
(09:32:51 AM) f13: but that doesn't count.
(09:32:51 AM) rdieter: f13: inkscape, yeah, but fixed now.
(09:32:59 AM) abadger1999: racor: What is the ratioinale?
(09:33:01 AM) f13: tibbs|h: I bet its from nim-nim isn't it?
(09:33:06 AM) racor: yes, there is a packaging under review ... <digging>
(09:33:07 AM) tibbs|h: Yes, some fonts thing.
(09:33:13 AM) spot: that seems like a no-brainer to me.
(09:33:19 AM) abadger1999: spot: Why?
(09:33:22 AM) tibbs|h:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=261881
(09:33:24 AM) buggbot: Bug 261881: medium, medium, ---, Nobody's working
on this, feel free to take it, NEW , Review Request:
écolier-court-fonts - Écolier court fonts
(09:33:37 AM) spot: because xchat rendered that two different ways for me?
(09:33:45 AM) spot: i don't even want to think about yum.
(09:34:02 AM) abadger1999: spot: yum does need a fix. There's an open bug.
(09:34:05 AM) f13: well, it would be good to test our infrastructure.
(09:34:08 AM) tibbs|h: I don't really have an issue with non-ascii
package names; we can't keep falling back on "our infrastructure sucks"
forever.
(09:34:11 AM) abadger1999: But I'm wondering why it's a bad thing.
(09:34:21 AM) abadger1999: Shouldn't we consider places where utf-8
fails to be bugs?
(09:34:44 AM) f13: non-ascii packages may have to be renamed if they
ever show up in RHEL
(09:34:53 AM) f13: I'm not sure how the RHN beast will handle it.
(09:35:07 AM) spot: well, that is RHEL's problem.
(09:35:10 AM) f13: yep
(09:35:17 AM) f13: I'm not saying it should have much bearing on our
decision
(09:35:27 AM) spot: racor: are you against it for aesthetic reasons or
technical ones?
(09:35:31 AM) racor: IMO, the technical issues are minor, the real issue
is usabilitsy
(09:35:44 AM) racor: spot: neither usability
(09:35:51 AM) tibbs|h: I always said that I won't review what I can't type.
(09:36:05 AM) tibbs|h: But my inability to type that is my dysfunction.
(09:36:11 AM) spot: well, i suppose that it would make it more difficult
for english typists to install/use a package
(09:36:23 AM) spot: but not impossible
(09:36:25 AM) racor: consider: 90% of US users are not even able to type
accented chars
(09:36:27 AM) tibbs|h: But is that a reason to ban something?
(09:36:47 AM) tibbs|h: I can't read German either, so let's kick out
German translations.
(09:36:53 AM) racor: 99.89% of Western folks are not able to type east
asian chars
(09:37:07 AM) f13: and 40% of all statistics are made up on the spot
(09:37:20 AM) spot: my concern is when people start naming packages in
kanji.
(09:37:40 AM) racor: tibbs: right type the char ß (this is not a beta
it's a sharp ss)
(09:37:46 AM) spot: we already mandate that the spec file must be
written in american english
(09:38:11 AM) tibbs|h: racor: I already said I can't type those
characters; I don't see what point your question serves.
(09:38:28 AM) rdieter: spot: +1, I think that covers the case here then, no?
(09:38:48 AM) tibbs|h: But I don't see the practical difference between
ideograms and accented vowels, either.
(09:38:57 AM) racor: tibbs: my point: anything outside of ascii not
universal enough
(09:38:59 AM) abadger1999: Yum bug:
https://bugzilla.redhat.com/show_bug.cgi?id=261961
(09:39:01 AM) buggbot: Bug 261961: low, medium, ---, Jeremy Katz, NEW ,
Yum does not like non-ascii package names
(09:39:14 AM) spot: well, technically we only say summary and description
(09:39:18 AM) spot: "Please put personal preferences aside and use
American English spelling in the summary and description."
(09:39:18 AM) tibbs|h: Either we say "ASCII" or "UTF-8"; there's no
point in anything in the middle.
(09:39:39 AM) tibbs|h: We do not mandate that the entire spec be in English.
(09:39:42 AM) f13: we already support non-ascii file names
(09:39:56 AM) f13: so lon gas they are UTF-8
(09:40:00 AM) tibbs|h: We permit translated descriptions.
(09:40:28 AM) rdieter: Can we at least agree that ASCII *SHOULD* be
used? Not sure if it warrants a MUST.
(09:40:40 AM) spot: yeah, i can support that ASCII should be used
(09:40:43 AM) abadger1999: rdieter: I'm not sure I would agree with that.
(09:40:51 AM) tibbs|h: I don't know if there's really a point.
(09:41:05 AM) racor: package names!!! descr, etc. are legacy, convenience,
(09:41:21 AM) tibbs|h: But we have rules about naming packages after
things like the upstream tarball.
(09:41:27 AM) abadger1999: I mean, nim-nim's point is also valid -- if
the upstream name is non-ascii who are we to differ from upstream?
(09:41:40 AM) rdieter: shrug, I'm ok with pushing the envelope here too.
(09:41:58 AM) spot: if only to encourage people not to be stupid and
spell things like this: ƁƎƗȂ
(09:42:11 AM) f13: can we try this package as a trial run and see what
all it breaks?
(09:42:18 AM) racor: abadger1999: would you say the same if the package
name was in cyrillian or turk?
(09:42:28 AM) ***spot is getting pulled away
(09:42:40 AM) spot: we'll have to pick this up next meeting
(09:42:41 AM) spot: sorry. :(
(09:42:52 AM) rdieter: f13: +1 :)
(09:42:53 AM) abadger1999: racor: What does the package do? Is it a
cyrillic font package? Is it something specific to Russian language
speakers?
(09:43:26 AM) abadger1999: spot: I think that needs to be addressed
upstream.
(09:43:35 AM) racor: abadger1999: not necessarily. Just author preference.
(09:44:09 AM) abadger1999: racor: So that's the gray line for me. I
think I'd say that we can try to influence upstream but it is an
upstream decision.
(09:44:09 AM) tibbs|h: We have a practical issue in any case, because
our infrastructure doesn't properly support non-ASCII package names
currently.
(09:44:27 AM) racor: I could call a package: bärensößchen ...
(09:44:33 AM) tibbs|h: Why not?
(09:45:00 AM) tibbs|h: Looks like as good a name as anything else.
(09:45:54 AM) racor: tibbs: except that most people would not be able to
type it .... yum install <package-name>
(09:46:09 AM) abadger1999: Copy and paste....
(09:46:19 AM) tibbs|h: Graphical interface.
(09:46:25 AM) tibbs|h: Tab completion.
(09:46:34 AM) tibbs|h: Learn to type German.
(09:47:06 AM) racor: abadger1999, tibbs: that's laughable.
(09:47:16 AM) tibbs|h: It's weird to see this argument backwards;
usually the Americans are arguing for "nothing I can't understand" while
the Europeans and Asians just laugh at the idiot luddites.
(09:47:46 AM) tibbs|h: "Nothing in Fedora should use the metric system."
(09:48:26 AM) racor: tibbs: learn to type Thai
(09:49:15 AM) tibbs|h: I personally have no interest in doing so.
(09:49:24 AM) tibbs|h: I don't see how that has any bearing on anything,
though.
-Toshio
16 years, 1 month
Re: [Fedora-packaging] Re: New draft packaging guidelines for OCaml
by Brad Bell
fedora-packaging-request(a)redhat.com wrote:
> Send Fedora-packaging mailing list submissions to
> fedora-packaging(a)redhat.com
>
.
.
.
>
> Tom "spot" Callaway wrote:
>
>> On Mon, 2008-03-03 at 16:53 +0000, Richard W.M. Jones wrote:
>>
>>
>>> - Clarify where documentation should go. Currently my practice has
>>> been to put just the license file (if any) in the main package's %doc,
>>> and the license file plus all other documentation & examples in
>>> the devel subpackage. This duplicates (only) the license file, but
>>> that seems acceptable since we shouldn't distribute software without
>>> its license.
>>>
>> -devel packages should Require the main package, thus, there really
>> isn't any need for the duplicate license copy.
>>
>>
The cppad package is totally C++ include files. There is a cppad-devel
and cppad-doc subpackage, but there is no main package. So the rule
above does not apply in this case.
16 years, 1 month
