A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
--
You arent able to file bug reports against elfutils in http://bugzilla.redhat.com?
Rahul
On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote:
On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
--
You arent able to file bug reports against elfutils in http://bugzilla.redhat.com?
Oh, I can, but I can't move them out of the MODIFIED state and none of the default queries (i.e. My Bugs) include MODIFIED.
On Sat, 2006-05-27 at 00:30 -0700, Nicholas Miell wrote:
On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote:
On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
--
You arent able to file bug reports against elfutils in http://bugzilla.redhat.com?
Oh, I can, but I can't move them out of the MODIFIED state and none of the default queries (i.e. My Bugs) include MODIFIED.
What are you trying to do? Are you trying to query or change state of the reports? Which bugs?
Rahul
On Sat, 2006-05-27 at 15:03 +0530, Rahul Sundaram wrote:
On Sat, 2006-05-27 at 00:30 -0700, Nicholas Miell wrote:
On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote:
On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
--
You arent able to file bug reports against elfutils in http://bugzilla.redhat.com?
Oh, I can, but I can't move them out of the MODIFIED state and none of the default queries (i.e. My Bugs) include MODIFIED.
What are you trying to do? Are you trying to query or change state of the reports? Which bugs?
Well, I'd like to be able to just drop a line to the elfutils list saying "Any progress on this bug?", but no such list exists, so I'm reduced to bothering fedora-devel.
Bug 187618, was submitted, partially fixed, and moved into the MODIFIED state, which bugzilla describes as "Fix applied, please test" (or something like that). I've tested it, discovered that that the fix was incomplete, and now I can't move it back to NEW or ASSIGNED or whatever and (afaict), nobody ever sees MODIFIED bugs in the normal course of bugzilla usage.
On Sat, 2006-05-27 at 13:02 -0700, Nicholas Miell wrote:
On Sat, 2006-05-27 at 15:03 +0530, Rahul Sundaram wrote:
On Sat, 2006-05-27 at 00:30 -0700, Nicholas Miell wrote:
On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote:
On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
--
You arent able to file bug reports against elfutils in http://bugzilla.redhat.com?
Oh, I can, but I can't move them out of the MODIFIED state and none of the default queries (i.e. My Bugs) include MODIFIED.
What are you trying to do? Are you trying to query or change state of the reports? Which bugs?
Well, I'd like to be able to just drop a line to the elfutils list saying "Any progress on this bug?", but no such list exists, so I'm reduced to bothering fedora-devel.
If you want to ask an update on a reported bug, it is generally done within the bugzilla report as comments.
Bug 187618, was submitted, partially fixed, and moved into the MODIFIED state, which bugzilla describes as "Fix applied, please test" (or something like that). I've tested it, discovered that that the fix was incomplete, and now I can't move it back to NEW or ASSIGNED or whatever and (afaict), nobody ever sees MODIFIED bugs in the normal course of bugzilla usage.
Looks like you got an answer from the developer now. The default queries in RH bugzilla doesnt list bugs with MODIFIED status but the relevant maintainers would be still keeping tracking of it.
The larger point about having a project space setup and looking for alternatives still stands .
Rahul
Hello Nicholas,
On Fr, 26 Mai 2006, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. Both are also glibc developers or even maintainers (see /lib/libc.so.6).
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
Huh? Do you have other elfutils than me? GPL and OSL as far as I got from the elfutils spec file in Fedora Core and rest seems to be explained after reading the comments of elfutils-0.120/libdw/dwarf_attr.c for example.
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, that I'm not really able to get your problem...
Greetings, Robert
Robert Scheck wrote:
Hello Nicholas,
On Fr, 26 Mai 2006, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. Both are also glibc developers or even maintainers (see /lib/libc.so.6).
[snip]
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, that I'm not really able to get your problem...
Nicholas's observation about the status of elfutils, and Robert's reply, can be explained even more simply: elfutils is _not_ a Fedora project! elfutils is a Red Hat project, and so far Red Hat has not ceded control of elfutils to anyone, especially including the Fedora community. Also, so far Fedora has avoided calling attention to issues such as the ones raised by Nicholas.
On the other hand, there is substantial overlap between elfutils (eu-addr2line, eu-elflint, eu-findtextrel, eu-nm, eu-readelf, eu-size, eu-strip, etc.) and binutils (addr2line, nm, readelf, size, strip, objdump, etc.) so perhaps Fedora should drop elfutils entirely.
On Sat, 2006-05-27 at 08:04 -0700, John Reiser wrote:
Robert Scheck wrote:
Hello Nicholas,
On Fr, 26 Mai 2006, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. Both are also glibc developers or even maintainers (see /lib/libc.so.6).
[snip]
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, that I'm not really able to get your problem...
Nicholas's observation about the status of elfutils, and Robert's reply, can be explained even more simply: elfutils is _not_ a Fedora project! elfutils is a Red Hat project, and so far Red Hat has not ceded control of elfutils to anyone, especially including the Fedora community. Also, so far Fedora has avoided calling attention to issues such as the ones raised by Nicholas.
If you think there is any issues that needs to be discussed as part of Fedora development feel free to do so especially if you are willing to contribute towards resolving any such problems.
On the other hand, there is substantial overlap between elfutils (eu-addr2line, eu-elflint, eu-findtextrel, eu-nm, eu-readelf, eu-size, eu-strip, etc.) and binutils (addr2line, nm, readelf, size, strip, objdump, etc.) so perhaps Fedora should drop elfutils entirely.
--
Rahul
On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote:
Rahul Sundaram wrote:
If you think there is any issues that needs to be discussed as part of Fedora development feel free to do so especially if you are willing to contribute towards resolving any such problems.
Remove elfutils from Fedora Core.
So, you're saying that anything which isn't controlled by Fedora shouldn't be shipped in Fedora Core?
I guess we might as well stop trying to ship anything then as we don't have direct control over *most* of what is shipped.
Note that elfutils is directly required by a number of packages within Fedora Core and thus can't just be removed
Jeremy
Jeremy Katz wrote:
On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote:
Rahul Sundaram wrote:
If you think there is any issues that needs to be discussed as part of Fedora development feel free to do so especially if you are willing to contribute towards resolving any such problems.
Remove elfutils from Fedora Core.
So, you're saying that anything which isn't controlled by Fedora shouldn't be shipped in Fedora Core?
I guess we might as well stop trying to ship anything then as we don't have direct control over *most* of what is shipped.
Most of those projects have maintainers who respond in a somewhat timely fashion, and/or a public source tree (CVS, svn, etc.), and/or other forms of not-just-Red Hat participation. Certainly most Fedora projects have "upstream." That's fine. What is not fine is a project that just sits there like a bump on a log despite open Bugzilla issues and demonstrated interest from "downstream" Fedora.
Note that elfutils is directly required by a number of packages within Fedora Core and thus can't just be removed
According to "rpm -qR elfutils" they are [excluding self references]: libc.so.6 libdl.so.2 /sbin/ldconfig which are all part of glibc. So elfutils can be flushed just by merging it into glibc. Everybody else uses binutils. Not many developers have ever used the "eu-" versions of nm, strip, size, readelf, addr2line.
Hi.
John Reiser jreiser@BitWagon.com wrote:
merging it into glibc. Everybody else uses binutils. Not many developers have ever used the "eu-" versions of nm, strip, size, readelf, addr2line.
What exactly does elfutils do that binutils doesn't, anyway?
Dnia 28-05-2006, nie o godzinie 21:04 +0200, Ralf Ertzinger napisał(a):
Hi.
John Reiser jreiser@BitWagon.com wrote:
merging it into glibc. Everybody else uses binutils. Not many developers have ever used the "eu-" versions of nm, strip, size, readelf, addr2line.
What exactly does elfutils do that binutils doesn't, anyway?
Now ? nothing. Current binutils strip can handle output stipped data to separated file. Currently eu-strip is used only in /usr/lib/rpm/find-debuginfo.sh script and s/eu-strip/strip/ will allow drop elfutils.
kloczek
On Sun, 2006-05-28 at 11:46 -0700, John Reiser wrote:
Jeremy Katz wrote:
On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote:
Rahul Sundaram wrote:
If you think there is any issues that needs to be discussed as part of Fedora development feel free to do so especially if you are willing to contribute towards resolving any such problems.
Remove elfutils from Fedora Core.
I just want to jump in here and note that I'm not advocating this.
So, you're saying that anything which isn't controlled by Fedora shouldn't be shipped in Fedora Core?
I guess we might as well stop trying to ship anything then as we don't have direct control over *most* of what is shipped.
Most of those projects have maintainers who respond in a somewhat timely fashion, and/or a public source tree (CVS, svn, etc.), and/or other forms of not-just-Red Hat participation. Certainly most Fedora projects have "upstream." That's fine. What is not fine is a project that just sits there like a bump on a log despite open Bugzilla issues and demonstrated interest from "downstream" Fedora.
Note that elfutils is directly required by a number of packages within Fedora Core and thus can't just be removed
According to "rpm -qR elfutils" they are [excluding self references]: libc.so.6 libdl.so.2 /sbin/ldconfig which are all part of glibc. So elfutils can be flushed just by merging it into glibc. Everybody else uses binutils. Not many developers have ever used the "eu-" versions of nm, strip, size, readelf, addr2line.
ITYM: [root@entropy ~]# repoquery --whatrequires --alldeps --resolve "elfutils*" | sort -u | grep -v "^elfutils" ddd-0:3.3.11-5.2.x86_64 ltrace-0:0.3.36-4.2.i386 ltrace-0:0.3.36-4.2.x86_64 net-snmp-devel-0:5.3-4.2.x86_64 prelink-0:0.3.6-3.x86_64 rpm-0:4.4.2-15.2.x86_64 rpm-build-0:4.4.2-15.2.x86_64 rpm-devel-0:4.4.2-15.2.x86_64 rpm-libs-0:4.4.2-15.2.x86_64 rpm-python-0:4.4.2-15.2.x86_64 systemtap-0:0.5.4-2.2.x86_64
And, having looked at binutils compared to elfutils and the other libelfs out there, I'd much rather use libelf than libbfd.
On Sun, 2006-05-28 at 11:46 -0700, John Reiser wrote:
Jeremy Katz wrote:
On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote:
Rahul Sundaram wrote:
If you think there is any issues that needs to be discussed as part of Fedora development feel free to do so especially if you are willing to contribute towards resolving any such problems.
Remove elfutils from Fedora Core.
So, you're saying that anything which isn't controlled by Fedora shouldn't be shipped in Fedora Core?
I guess we might as well stop trying to ship anything then as we don't have direct control over *most* of what is shipped.
Most of those projects have maintainers who respond in a somewhat timely fashion, and/or a public source tree (CVS, svn, etc.), and/or other forms of not-just-Red Hat participation. Certainly most Fedora projects have "upstream." That's fine. What is not fine is a project that just sits there like a bump on a log despite open Bugzilla issues and demonstrated interest from "downstream" Fedora.
Note that elfutils is directly required by a number of packages within Fedora Core and thus can't just be removed
According to "rpm -qR elfutils" they are [excluding self references]: libc.so.6 libdl.so.2 /sbin/ldconfig which are all part of glibc. So elfutils can be flushed just by merging it into glibc. Everybody else uses binutils. Not many developers have ever used the "eu-" versions of nm, strip, size, readelf, addr2line.
I, for one, use eu-readelf and eu-nm very, very often. I suspect I'm not as alone as you assert.
Also note that eu-strip is required to make debuginfo packages.
Dnia 28-05-2006, nie o godzinie 16:32 -0400, Peter Jones napisał(a): [..]
Also note that eu-strip is required to make debuginfo packages.
$ grep eu-strip /usr/lib/rpm/* -r /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" || : /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" || :
kloczek
Dnia 28-05-2006, nie o godzinie 23:35 +0200, Tomasz Kłoczko napisał(a):
Dnia 28-05-2006, nie o godzinie 16:32 -0400, Peter Jones napisał(a): [..]
Also note that eu-strip is required to make debuginfo packages.
$ grep eu-strip /usr/lib/rpm/* -r /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" || : /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" || :
Sorry my fault. binutils stip does not have -f option :> Is porting handle -f option to binutils strip will be so hard ?
kloczek
If you don't want elfutils, don't install it. Your choice. But don't make judgments for which you don't have the information:
- there are no known problems in elfutils. At least none known to me and none in BZ (which aren't fixed).
- the tools in elfutils compared with binutils are a) smaller, b) faster (several times, usually), c) less buggy, d) more featureful
- there are several tools which are not available in binutils which are in (wide) use
- there are several more tools which use the elfutils libraries (systemtap, frysk, ...)
- there are more libraries part of elfutils which are not yet installed because they are not finished yet
- almost everybody who has ever worked on binutils will attest what a horrible mess it is. it deserves nothing but to die since you cannot salvage the disaster. Using an intermediate format which is not ELF not only adds overhead, it also means that there will always be cases when information is lost in one of the transformations. This all is especially true when it comes to DWARF handling.
- it is certainly is my goal to finish the last gap in the tools vs binutils. So at that time it would be a _possibility_ to drop binutils.
But I think this is not really the main resentment. People complained that there is no public CVS? Why should there, you have all the sources. Releases are made regularly after every major change (given the constraints of the package maintainer). Other complain there is no release as tarballs. Very simple, I consider tarballs to be the wrong form. To guarantee consistency one needs something like src.rpm. Another complain is that there is no mailing list. Well, you can create a mailing list whenever and wherever you want. But one way or another you cannot force me to take time to read all the extra traffic. I've no time for that. Bugs can be filed in BZ and will be handled if necessary and reasonable. And yes, we cannot except outside contributions. Still not. This is a problem with our legal department who still hasn't set up a mechanism which allows us to accept assignments. And that's necessary, the code is copyrighted by me and Red Hat.
Ulrich Drepper wrote:
If you don't want elfutils, don't install it. Your choice. But don't make judgments for which you don't have the information:
In this particular case, I have 7 years of more-than-casual experience in this area of software for Linux and have produced ELF utilities used by others (including elfvector, rtldi, tub, tunelfso), but have never invoked any eu-* utility directly "by hand" or by script which I wrote. I also have entered and tracked many BZ reports in related projects such as glibc and strace, projects which share maintainers with elfutils. So I believe that I have at least moderate information on the topic of object file utilities and Fedora.
- there are no known problems in elfutils. At least none known to me
and none in BZ (which aren't fixed).
Oh, but there are. Part of Nicholas Miell's reason for posting was that one of the BZ entries was fixed incompletely. He has the evidence, tried to get it considered through the BZ process, and felt stymied because that process is not as open as he felt it should be.
- the tools in elfutils compared with binutils are a) smaller, b) faster
(several times, usually), c) less buggy, d) more featureful
Those conclusions are important to state explicitly. [Where is the data?]
- there are several tools which are not available in binutils which are
in (wide) use
It always helps to give two or three specific examples. Then others who are interested can increase their knowledge of both elfutils and binutils, which might lead to improvements in both packages. Besides "eu-strip -f" for creating separate .debuginfo packages, what else is available in elfutils but not binutils?
- there are several more tools which use the elfutils libraries
(systemtap, frysk, ...)
- there are more libraries part of elfutils which are not yet installed
because they are not finished yet
Would now be a good time for input [of all kinds, including even code] from a larger community?
- almost everybody who has ever worked on binutils will attest what a
horrible mess it is. it deserves nothing but to die since you cannot salvage the disaster.
I agree that binutils is extremely poor software. However, binutils does cover more than the 10 architectures covered by elfutils [alpha, arm, i386, ia64, mips, ppc, ppc64, sh, sparc, x86_64.] Elfutils certainly covers the most important archs, but not every one; for instance: m68k.
Using an intermediate format which is not ELF not only adds overhead, it also means that there will always be cases when information is lost in one of the transformations. This all is especially true when it comes to DWARF handling.
- it is certainly is my goal to finish the last gap in the tools vs
binutils. So at that time it would be a _possibility_ to drop binutils.
But I think this is not really the main resentment. People complained that there is no public CVS? Why should there, you have all the sources. Releases are made regularly after every major change (given the constraints of the package maintainer). Other complain there is no release as tarballs. Very simple, I consider tarballs to be the wrong form. To guarantee consistency one needs something like src.rpm. Another complain is that there is no mailing list. Well, you can create a mailing list whenever and wherever you want. But one way or another you cannot force me to take time to read all the extra traffic. I've no time for that. Bugs can be filed in BZ and will be handled if necessary and reasonable. And yes, we cannot except outside contributions. Still not. This is a problem with our legal department who still hasn't set up a mechanism which allows us to accept assignments. And that's necessary, the code is copyrighted by me and Red Hat.
Part of my reason for entering and prolonging this thread is to increase the documentation for elfutils. Eliciting Ulrich Drepper's remark:
- the tools in elfutils compared with binutils are a) smaller, b) faster
(several times, usually), c) less buggy, d) more featureful
counts as a success, which would be even more signficant if accompanied by some data to substantiate claims. I even made a deliberate mistake in using "rpm -qR" which Nicholas Miell pointed out should have been "--whatrequires" instead. I believe that the output (which indicates uses by rpm and rpm-python), and Ulrich Drepper's remarks about Red Hat legal department and copyrights, reveal significant new information to the Fedora community about the reasons why elfutils is the way it is. Elfutils is effectively part of RPM. Elfutils is a part of the Red Hat "crown jewels," which confers special status on elfutils.
On Sun, 2006-05-28 at 20:33 -0700, John Reiser wrote:
Part of my reason for entering and prolonging this thread is to increase the documentation for elfutils. Eliciting Ulrich Drepper's remark:
- the tools in elfutils compared with binutils are a) smaller, b) faster
(several times, usually), c) less buggy, d) more featureful
counts as a success, which would be even more signficant if accompanied by some data to substantiate claims. I even made a deliberate mistake in using "rpm -qR" which Nicholas Miell pointed out should have been "--whatrequires" instead. I believe that the output (which indicates uses by rpm and rpm-python), and Ulrich Drepper's remarks about Red Hat legal department and copyrights, reveal significant new information to the Fedora community about the reasons why elfutils is the way it is. Elfutils is effectively part of RPM. Elfutils is a part of the Red Hat "crown jewels," which confers special status on elfutils.
I don't know what drugs you're on, but please stop dragging me into your paranoid delusions.
Some people say that Fedora needs mp3 because you can't download music in ogg format -- despite the name,
lets you download music in ogg format, at attractive prices: you decide the format and the bitrate you want, and they charge you by the megabyte. It costs me about $2.50 to download a typical album at 200 kb/s ogg, which is much better quality than you get from iTunes.
Now, I'm a command-line guy (I've been into UNIX ever since my wardialer found a machine that belonged to the phone company in the mid 80's), so I find it really easy to do
$ cd music $ cd Jefferson-Starship $ cd Red-Octopus $ ogg123 *.ogg
particularly when bash helps me out with command line completion. Still, I've been impressed with the GUI in FC5, so let's try playing music with the GUI...
I click on an ogg file and it plays in Helix player; that works great.
Next I click on "File/Open" and notice that I can only select one file at a time. That's not good.
I spend most of my workday in front of a Windows machine that mostly works as a VNC terminal for an RHEL 4 machine in the basement. I listen to music at work with both the Yahoo Music Engine (nice UI, but it screws up all the time) and Winamp (limited UI, but it works consistently). When you hit the "eject" button on Winamp, it comes up with a standard Windows file selector. Honestly I can't remember what does what, but you can use Shift+click and Ctrl+click to either select a range of files or to select individual files. (My unconcious mind knows, so I can do this effortless) You can go to the directory that an album is in, select all the files, and listen to the whole album.
Winamp is screwy, because the files play in the opposite order that they should play -- if you drag down from the top, the album will play backwards, but if you drag up from the bottom, the album plays forwards. This is the opposite of the intuitive behavior, but once you get used to it, it's easy to listen to a whole album in Winamp.
Helix on FC isn't like that -- shift+click, ctrl+click doesn't do anything different from 'click', so I have to play a whole album at a time. I can't say I know what GUI toolkit that Helix is using to generate it's file selector... I think it's gnome, but it's not like any documentation exists for this stuff... But it's little things like this that make the difference between a GUI that's useful, and a GUI that's not.
On Sun, 2006-05-28 at 23:51 -0400, Paul A Houle wrote:
Helix on FC isn't like that -- shift+click, ctrl+click doesn't doanything different from 'click', so I have to play a whole album at a time. I can't say I know what GUI toolkit that Helix is using to generate it's file selector... I think it's gnome, but it's not like any documentation exists for this stuff... But it's little things like this that make the difference between a GUI that's useful, and a GUI that's not.
The GTK+ file selector supports multiple selection (try gedit, say); the application is, however, responsible for turning that on ... it doesn't make sense in all cases.
You might want to file an upstream bug report against helix.
I personally find rhythmbox a whole lot nicer for playing local music, but tastes vary.
Owen
On Sat, 2006-05-27 at 13:43 +0200, Robert Scheck wrote:
Hello Nicholas,
On Fr, 26 Mai 2006, Nicholas Miell wrote:
A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list.
did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. Both are also glibc developers or even maintainers (see /lib/libc.so.6).
Yes, I am aware of this. Does this mean I email them personally with all elfutils questions/discussions/patches? Shouldn't that be done on a public list?
Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available?
Huh? Do you have other elfutils than me? GPL and OSL as far as I got from the elfutils spec file in Fedora Core and rest seems to be explained after reading the comments of elfutils-0.120/libdw/dwarf_attr.c for example.
elfutils is licensed under the GPL for all the tools (which I'm perfectly OK with), and the GPL and/or something unintelligible for the libraries. AFAICT, the "something unitelligible" says that it can also be used by any OSI sufficienty viral OSI license, but I haven't paid a lawyer to explain it to me.
The choice of GPL and/or viral OSI license for a library that reimplements a common API used by most (all?) ELF Unixen is strange, considering that better APIs could probably be developed if portable application compatibility is not a goal of the project, and that seems to be the case based on the licensing choice and comments by Mr. Drepper.
And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.)
Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, that I'm not really able to get your problem...
This is being discussed elsewhere in this thread, so I'm not going to repeat myself here.
-
Jeremy Katz -
John Reiser -
Kłoczko Tomasz -
Nicholas Miell -
Owen Taylor -
Paul A Houle -
Peter Jones -
Rahul Sundaram -
Ralf Ertzinger -
Robert Scheck -
Ulrich Drepper