Re: Wodim trouble
2009/11/3 Conrad Meyer ceme...@u.washington.edu In this case, upstream (wodim) is a fork of Joerg Schilling's project. Wodim was forked from cdrecord because Joerg is crazy. Joerg likes to call wodim the broken fork and cdrecord the original software. He visited all the booths of linux distributions at Chemnitzer Linux Tage and started some trouble. The ML and BZ of the Linuxdistros, which are using wodim is the outlet of Jörgs furious anger about the fork and the debian maintainer who is the upstream coder of wodim! There was already a 'wodim vs. cdrecord' discussion at fedora-legal-list. I have a big respect for Jörg, not for him as person, but for his attainments! -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Ankur Sinha sanjay.an...@gmail.com wrote: Looks like another thread going the wrong way. I just wanted to know if wodim is usable (i mean without wasting dvds like its doing currently for me). From the discussion, I feel it's still buggy and therefore I'm going to shift to another program (maybe growisofs). Well, people like you who try to use the fork know that it is just having too many bugs for being useful. Please note that growisofs is not the solution for a wider problem: growisofs of course needs mkisofs and redhat does not ship a working mkisofs bug the broken genisoimage. Growisofs is also known to have problems with some DVD drives where cdrecord has no problem. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Bastien Nocera bnoc...@redhat.com wrote: The person from the GNOME project just verified that he attacks people who are helpful. He does not seem to be important. The person being Olav Vitters, one of the GNOME bugmasters, and that was at my request, after you polluted the GNOME Bugzilla with rants about your inadequately licensed software. Pur-lease. Everybody can check the GNOME bugtracking system himself and verify that I have been banned for explaining the _technical_ background of a reported bug and for giving instructions on how to work around the problem. It is obvious that Olav Vitters (and ayou??) made a social attack against an author of OpenSource software. You are not very convincing... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: updating F11 GNOME release
Josephine Tannhäuser wrote: 2009/11/2 Matthias Clasen mcla...@redhat.com We don't do jumps to the next major GNOME version within a released Fedora, that would be incompatible with our understanding of a released product. I hope the KDE-sig will take up this stance on her own releasecycles. Uh, why? What's wrong with our updates (other than them being updates ;-) )? Any concrete complaints? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
libsndfile status?
https://admin.fedoraproject.org/pkgdb/packages/bugs/libsndfile What's up with libsndfile in Fedora and EPEL? There are open tickets about CVEs filed in March. There are additional tickets without any reply. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
King InuYasha wrote: The only thing I can figure out from this conversation is that the CDDL is supposed to be incompatible with the GPL. If that's the case, why not simply ask the original creator to kindly dual license it? We did, many times. He refuses to acknowledge there's any problem at all and insists that mixing the CDDL and the GPL is legal (despite the FSF and many others clearly saying it's not), citing some Sun lawyers (who clearly have an agenda to push the CDDL). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB2 In Fedora
2009/11/3 Liang Suilong liangsuil...@gmail.com: Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides more useful features to users. And it is more easy to add a new file system support. But I can not see Fedora has any plan for GRUB2. I read a feature page on Fedora wiki. There is no progress on grub2. Now Fedora official repo offers grub2 package. However the version is quite strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed from svn repo on Aug 27th, 2008. Also, maintainer adds some patches to fix the bug. But GNU released grub2-1.97 just now. In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is there a bug in grub2? -- urlhttp://www.liangsuilong.info/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list see: http://fedoraproject.org/wiki/Features/Grub2 as for the outdated version... feel free to open a bug ticket and request an update to the latest stable version of grub2. kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Julian Sikorski beleg...@gmail.com wrote: On 11/02/2009 03:47 PM, Denis Leroy wrote: On 11/02/2009 07:18 PM, Adam Jackson wrote: That may be true, but since cdrecord is not shippable, it's a pretty vacuous truth. Out of curiosity, was that just because of the GPL2-CDDL mix ? Or was there another reason ? Last I checked, only mkisofs is affected by that and the rest of cdrecord is pure CDDL. If we patched mkisofs away, would it be shippable ? ... opensuse are shipping cdrecord, maybe it would be worth checking what they changed, if at all? There is no legal problem with the original software, there is only a social problem caused by a hostile downstream (a Debian packager). See http://cdrecord.berlios.de/private/linux-dist.html for an overview. Let me give you some background on the legal situation: There are some people who claim that there is a legal problem with the original software but none of the persons who spread this claim (including people from redhat) did ever make a valid legal statement that could confirm a problem. As there are no valid legal arguments _against_ the situation in cdrtoools, there is obviously no way to discuss things and we need to rate the claims against cdrtools as libel. I even tried to discuss the social problem with some people from redhat but I was only given FUD instead of arguments. In return, I repeatedly asked for legal arguments that could be discussed, to no avail. So redhat also proves the same and it is obvious that there are no valid legal arguments that could confirm a problem with the original softare. Note that the GPL was designed to be compatible with all independently developed libraries under any license. This is a decision that was made in the late 1980s and I know the background of this diiscussion as I did take part in it. The GPL would have been completely unuaable if it was not made legally compatible with any independent library under any license. Even Eben Moglen confirmed that there is absolutely no problem with letting GPLd programs use CDDLs libs as this is of course no more then mere aggregation, and permitted by the GPL. On the other side, there is Sun. Sun is the biggest Donator of OSS and Sun definitely runs a legal review on _every_ piece of OSS that is going to make it into Sun's Solaris distribution. This is needed because Sun also is the biggest target for atacks and legal cases and Sun for this reason is extremely careful with distributing OSS. I can confirm that Sun lawyers are also very effective with detecting legal problems as they did themself find that libcdio creates a legal problem in GNOME. Sun immediately stopped shipping libcdio and we did create a replacement library that calls cdda2wav in order to avoid legal problems and in order to give better audio results. Sun did make a legal review on cdrtools im May 2006 already, but in order to be very sure, I asked Sun legal to repeat the legal review on cdrtools last autumn. After doing the review, Sun legal confirmed again that there is no problem with the original software. It seems that the people who claim legal problems do not like to get into a discussion as with a fact based discussion, it would be easy to prove that they are wrong. As we have trustworthy confirmations from several sides, I propose to asume that there is no legal problem dist distributing cdrtools as long as nobody gives valid legal arguments. Note that Suse already ships cdrtools again and that even Jörg Jaspert, the FTP master from Debian in a legally binding way agreed on distributing the original cdrtools again for Debian as soon as possible. See also: http://cdrecord.berlios.de/private/linux-dist.html#Sun It would be interesting to hear _arguments_ from redhat on why redhat still only ships a broken fork with legal problems instead of the working original software that has no known legal problems Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Dne 3.11.2009 05:22, Ankur Sinha napsal(a): I just wanted to know if wodim is usable (i mean without wasting dvds like its doing currently for me). From the discussion, I feel it's still buggy and therefore I'm going to shift to another program (maybe growisofs). Yes, wodim is perfect. Joerg is just spreading FUD. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Always make new mistakes -- Esther Dyson -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 20091030
On Mon, 2 Nov 2009 23:08:53 -0500, Jon wrote: * fluidsynth and PA (jds2001, 17:04:44) * LINK: http://markmail.org/message/bovdqb7na3zor2ck - without comment. (mjg59, 17:17:07) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=500087#c13 (jds2001, 17:19:22) * AGREED: PA backend for fluidsynth must be built. If the current maintainer refuses, Kevin_Kofler will take over as maintainer. (jds2001, 17:32:01) 17:18:45 skvidal the package is a leafnode 17:18:47 skvidal NOTHING requires 17:18:48 skvidal it Not true. See: repoquery --whatrequires fluidsynth-libs --alldeps Building with PA support would add a dependency also to the backend library package, not just to the console ui. -- Btw, note that it could be built also with additional PortAudio support. ;·) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
W dniu 03.11.2009 11:37, Matěj Cepl pisze: Dne 3.11.2009 05:22, Ankur Sinha napsal(a): I just wanted to know if wodim is usable (i mean without wasting dvds like its doing currently for me). From the discussion, I feel it's still buggy and therefore I'm going to shift to another program (maybe growisofs). Yes, wodim is perfect. Joerg is just spreading FUD. Matěj Ok, putting the ad personam arguments aside, there are two important facts: - cdrecord is still under active development, but there might be a problem with distributability (Sun lawyers say there is not, but I guess RH would like to make their own legal review to be on the safe side) - cdrkit is in sort of maintenance mode, and it does not support UDF filesystem for DVD discs correctly, and the situation is unlikely to improve - libburn is also developed actively, but it lacks UDF support as well [1] So, while waiting for libburn to improve, we could either take over cdrkit development, or do a(nother) legal review of cdrecord. It seems that the latter should be simpler, given that it's a one-time effort. Julian [1] http://libburnia-project.org/ticket/106 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, Nov 3, 2009 at 11:58 AM, Julian Sikorski beleg...@gmail.com wrote: So, while waiting for libburn to improve, we could either take over cdrkit development, or do a(nother) legal review of cdrecord. It seems that the latter should be simpler, given that it's a one-time effort. Already done around June: http://thread.gmane.org/gmane.linux.redhat.fedora.legal/473 -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Joerg Schilling wrote: There are some people who claim that there is a legal problem with the original software but none of the persons who spread this claim (including people from redhat) did ever make a valid legal statement that could confirm a problem. As there are no valid legal arguments _against_ the situation in cdrtoools, there is obviously no way to discuss things and we need to rate the claims against cdrtools as libel. They are making a very concrete claim: if one piece of some program is under the GPL, the ENTIRE program, including all its libraries, MUST be under the GPL or a compatible license. This is confirmed e.g. by the FSF: http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean http://www.gnu.org/licenses/gpl-faq.html#MereAggregation http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs I even tried to discuss the social problem with some people from redhat but I was only given FUD instead of arguments. In return, I repeatedly asked for legal arguments that could be discussed, to no avail. So redhat also proves the same and it is obvious that there are no valid legal arguments that could confirm a problem with the original softare. That's just false. You refused to take legal arguments from Fedora's legal contact (who is responsible for communication between RH Legal and the Fedora community) on the grounds that he's not a lawyer and demanded to speak directly to the lawyers. You ignored all the arguments he brought up, no matter how valid. Note that the GPL was designed to be compatible with all independently developed libraries under any license. This is a decision that was made in the late 1980s and I know the background of this diiscussion as I did take part in it. The GPL would have been completely unuaable if it was not made legally compatible with any independent library under any license. Then I have a breaking news for you: the GPL *is* completely unusable. Nevermind all those projects who can use it just fine while honoring these terms you refuse to accept. :-/ Even Eben Moglen confirmed that there is absolutely no problem with letting GPLd programs use CDDLs libs as this is of course no more then mere aggregation, and permitted by the GPL. You are misrepresenting Eben Moglen's position. The FSF's GPL FAQ, which he helped write, clearly says If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. So this is not mere aggregation. Sun did make a legal review on cdrtools im May 2006 already, but in order to be very sure, I asked Sun legal to repeat the legal review on cdrtools last autumn. After doing the review, Sun legal confirmed again that there is no problem with the original software. Red Hat, like pretty much any other company, cannot trust other companies' legal departments. The relevant opinion is going to be Red Hat Legal's, sorry. (And FWIW, I have no idea why Sun is coming to that conclusion which directly contradicts the FSF's opinion, see the GPL FAQ.) It seems that the people who claim legal problems do not like to get into a discussion as with a fact based discussion, it would be easy to prove that they are wrong. It is you who boycotted the fact-based discussion on ad hominem grounds (i.e. you're not a lawyer, I won't listen to you, nevermind that you aren't one either). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
King InuYasha ngomp...@gmail.com wrote: The only thing I can figure out from this conversation is that the CDDL is supposed to be incompatible with the GPL. If that's the case, why not simply ask the original creator to kindly dual license it? First, it is definitely wrong that the CDDL was made incompatible with the GPL. The person who brouhgt this claim into public is a former Sun Employee who was disappointed that the restrictions in the GPL made the GPL impossible for use with OpenSolaris. In fact, the GPL is incompatible to nearly all licenses around and this is definitely an intended feature from the authors of the GPL. For our discussion, it is important to know whether a possible _general_ incompatibility between two licenses could affect a _special_ situation in a collective work, so let us have a look at the GPL: The GPL forbids to mix GPL and non-GPL within _one_ _single_ work and the GPL forbids to create a derived work from a GPLd work if the derived work is not put under GPL. Let us look at the work mkisofs. This work is a _pure_ GPLd work. It does not mix GPL and non-GPL code in a single work. With mkisofs, there is also no derived work that has to be taken into account. The fact that mkisofs links against CDDLd libs does not create a derived work but ist only a permitted collective work. For a more detailed review, please have a look at this book from Lawrence Rosen: http://www.rosenlaw.com/Rosen_Ch06.pdf who is an independent lawyer who counsels the OpenSource initiative. The relevent parts for the mkisofs case are on page 128. People wo claim that mkisofs has a problem usually missinterpret GPL section 3, the paragraph that is past 3 c): This special exception was introduced because the GPL precursor did contain an illegal claim that forced distributors of binaries from GPLd programs to distribute the source of the GPLd program _plus_ the libc from the Operating System the binary was compiled for. As this is a claim that is in conflict with the permissions that have been given with the OS license, the GPL tried to enforce something that was impossible. In the late 1980s, the so called OS library exception was added in order to prevent distributors of binaries to be forced to do illegal things. This section is obviously absolutely not related to any special license compatibility grant. It just allows to avoid being forced to ship libc. The conclusion of all lawyers I did talk to, is that there is no legal problem with original source. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive-2009 man info
I'm trying texlive-2009 packages for f11. I see man and info pages get installed (not in standard system locations, but into texlive tree), but man and info search paths don't seem to be setup to find them. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Josephine Tannhäuser josephine.tannhau...@googlemail.com wrote: 2009/11/3 Conrad Meyer ceme...@u.washington.edu In this case, upstream (wodim) is a fork of Joerg Schilling's project. Wodim was forked from cdrecord because Joerg is crazy. Joerg likes to call wodim the broken fork and cdrecord the original software. He visited all the booths of linux distributions at Chemnitzer Linux Tage and started some trouble. It seems that you have not been there. I have a good relationship to Linux developers and projects and I did have nice conversations with many people in Chemnitz. Note that there was even a very good relationship with Debian _before_ Eduard Bloch became packetizer for cdrtools and started his attacks. It is obvious that the problems we are still wasting out time with is just one hostile person called Eduard Bloch. I hope that the OSS community finds a way to workaround the problems he created. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
On 11/02/2009 03:02 PM, Jesse Keating wrote:
On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote:
I'm not sure about this... Actually I like the fact we can define a
pseudo root other than '/'... which means you really want a live exported
directory with the fsid=0 option... If I am understanding what you are
saying...
No, that's not what he's saying. Even if you define a different psuedo
root other than /, it's likely more common to /not/ want that root
exported in whole, but rather smaller parts of it, just like you don't
want / exported in whole, you only want subdirectories exported.
Lets add some context to this since I *really* do want to understand
what you guys are saying...
/export *(ro,fsid=0)
/export/home *(rw)
With the above exports the only part of the server's real root ('/')
that is exposed is the /export directory. So when a client does a
'mount -o v4 server:/ /mnt'
The client will only be able to see /mnt/home (or the /export/home
export).
So as far as exposure, being able to define the root the client
will see, I think, is good thing since it will protect (or hide)
the rest of server's real root directories...
So this is why I'm understanding why the '/export' of the
'/export *(ro,fsid=0)' should not be a live export directory?
steved.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
2009/11/3, Joerg Schilling joerg.schill...@fokus.fraunhofer.de: Josephine Tannhäuser josephine.tannhau...@googlemail.com wrote: It seems that you have not been there. I was there and I was shocked about your behavior. -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Mat??j Cepl mc...@redhat.com wrote: Dne 3.11.2009 05:22, Ankur Sinha napsal(a): I just wanted to know if wodim is usable (i mean without wasting dvds like its doing currently for me). From the discussion, I feel it's still buggy and therefore I'm going to shift to another program (maybe growisofs). Yes, wodim is perfect. Joerg is just spreading FUD. And Earth is a disk. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Including windows-binary files for cross compiling into package
On Mon, Oct 26, 2009 at 07:42:56PM +0100, Joost van der Sluis wrote:
On Mon, 2009-10-26 at 11:15 -0700, Roland McGrath wrote:
If it's true cross support, then that should be a noarch package and the
file names it uses should not depend on %{_lib} that way.
Arguably it even belongs in %{_sharedir}, since it is fixed binary content
across all host machines.
Those files are not architecture independent. They are somewhat similar
to .o files. They contain the run time library for the language,
compiled to native windows object files. If you want to compile your own
program with them afterwards, they are linked together into a windows
executable.
You could argue that they should belong in a -devel package. But since
this package is a compiler, we decided not to split it up into a devel
package and a non-devel package. As that would be pointless, as one will
not work without the other.
Sorry, I'm late on this one. Yes the files *are* arch independent
from the point of view of the host, so they should be noarch. The
real problem is that RPM and the rest of the toolchain doesn't
understand the cross-compilation situation at all.
Anyway you may find the Fedora MinGW packaging guidelines to be
helpful, and it would be useful to make your package compatible with
the other ones, even if that deviates from upstream a little bit.
http://fedoraproject.org/wiki/Packaging/MinGW
http://fedoraproject.org/wiki/MinGW
http://fedoraproject.org/wiki/MinGW/Packaging_issues
We've also packaged some things, such as the OCaml cross-compiler,
which sound very similar to the Pascal case you describe.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Julian Sikorski beleg...@gmail.com wrote: Ok, putting the ad personam arguments aside, there are two important facts: - cdrecord is still under active development, but there might be a problem with distributability (Sun lawyers say there is not, but I guess There is no problem with distributibility as Sun would risk being sued if there legal department was wrong. I still do not understand why Companies like Redhat do not siply ask their lawyers for legal assistence. If they did, they would have better advise about cdrtools. RH would like to make their own legal review to be on the safe side) - cdrkit is in sort of maintenance mode, and it does not support UDF filesystem for DVD discs correctly, and the situation is unlikely to improve Cdrkit is unmaitained and has legal problems. Companies who distribute cdrkit ignore the legal problems and need to be aware of legal consequences. - libburn is also developed actively, but it lacks UDF support as well [1] So, while waiting for libburn to improve, we could either take over cdrkit development, or do a(nother) legal review of cdrecord. It seems that the latter should be simpler, given that it's a one-time effort. Libburn is based on a wrong asumption: libburn only works partly on Linux in non-root mode and the vast majority of other OS needs root permissions to burn. Creating a burn library (well it is non-portable) based on these constraints will result in GUI applications that are non-portable and would require root permissions on most platforms. Installing a GUI suid root is an absolute no-go as GUIs are so compley that it is hard to audit the code for security problems. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Kevin Kofler kevin.kof...@chello.at wrote: Joerg Schilling wrote: There are some people who claim that there is a legal problem with the original software but none of the persons who spread this claim (including people from redhat) did ever make a valid legal statement that could confirm a problem. As there are no valid legal arguments _against_ the situation in cdrtoools, there is obviously no way to discuss things and we need to rate the claims against cdrtools as libel. They are making a very concrete claim: if one piece of some program is under the GPL, the ENTIRE program, including all its libraries, MUST be under the GPL or a compatible license. This is confirmed e.g. by the FSF: http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean http://www.gnu.org/licenses/gpl-faq.html#MereAggregation http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs You seem to miss that the license mkisofs is using is called GPL and not GPL FAQ, so the quoting you mention do not apply. The GPL requires the entire work to be under GPL and the entire work mkisofs _is_ of course under GPL. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
2009/11/3 Joerg Schilling joerg.schill...@fokus.fraunhofer.de: if there legal department was wrong. I still do not understand why Companies like Redhat do not siply ask their lawyers for legal assistence. If they did, they would have better advise about cdrtools. Just a small thing that drives me crazy. The company name is Red Hat not Redhat. People don't write your name Joergschilling, do they? Thanks. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Josephine Tannhäuser josephine.tannhau...@googlemail.com wrote: 2009/11/3, Joerg Schilling joerg.schill...@fokus.fraunhofer.de: Josephine Tannhäuser josephine.tannhau...@googlemail.com wrote: It seems that you have not been there. I was there and I was shocked about your behavior. Fortunately, you are of limited relevance and other people did not behave hostile but friendly ;-) Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091103 changes
Compose started at Tue Nov 3 06:15:13 UTC 2009 New package calibre E-book converter and library management New package intrace Traceroute-like application for network reconnaisance New package perl-Makefile-Parser Simple parser for Makefiles New package python-tornado Scalable, non-blocking web server and tools New package rubygem-abstract Allows you to define an abstract method in Ruby Removed package DeviceKit Removed package sublib Updated Packages: CGAL-3.5-1.fc12 --- * Sun Oct 18 2009 laurent.rineau__fed...@normalesup.org - 3.5-1 - New upstream release: finale version of CGAL-3.5. DeviceKit-disks-009-1.fc12 -- * Mon Nov 02 2009 David Zeuthen dav...@redhat.com - 009-1.fc12 - Update to release 009 (bugfixes, #528874) PackageKit-0.5.4-0.1.20091029git.fc12 - * Thu Oct 29 2009 Richard Hughes rhug...@redhat.com - 0.5.4-0.1.20091029git - Update to a newer git snapshot from the 0.5.x series. - Check the language code exists before we search for it. - Add the missing InstallSignature role from the backend auto-detection. - Disable repos that are not contactable at backend start. - Don't allow double clicking SRPM and fix the cryptic message. - Fixes #529349, #531105, #530945, #531306 and #530264 PyQwt-5.2.0-2.fc12 -- * Wed Oct 28 2009 Tadej Janež tadej.ja...@tadej.hicsalta.si 5.2.0-2 - made qplt.py executable (to fix a rpmlint error) - removed html/.buildinfo from sphinx documentation (to fix a rpmlint error) - changed BuildRequires from numpy to numpy-f2py to cope with the numpy package split - temporarily removed qwt.py* files which conflict with the ones provided by the PyQt4 package anaconda-12.42-1.fc12 - * Fri Oct 30 2009 Chris Lumens clum...@redhat.com - 12.42-1 - Use the new anaconda image in fedora-logos (#529267). (jkeating) - Also mark the Back button as translatable (#526925). (clumens) - Call udev_trigger with change, not add, to populate udev db. (#531052) (dlehman) - Allow callers of udev_trigger to specify the action string. (dlehman) - Add the bcm5974 kernel module needed for some touchpads (#474225). (clumens) - Fix resize failed: 1 errors for ext2/ext3/ext4 (#517491). (dcantrell) - Put the icon back on the Back button on livecd installs (#526925). (clumens) - Use /dev/mapper/live-osimg-min instead of the old device node name (#526789). (clumens) asterisk-sounds-core-1.4.16-2.fc12 -- * Mon Nov 02 2009 Jeffrey C. Ollie j...@ocjtech.us - 1.4.16-2 - Remove fr/1.g729 as it's triggering an error in magic_file(3) (BZ#532489) * Mon Oct 05 2009 Jeffrey C. Ollie j...@ocjtech.us - 1.4.16-1 - Update to 1.4.16. at-spi-1.28.1-1.fc12 * Mon Oct 19 2009 Matthias Clasen mcla...@redhat.com - 1.28.1-1 - Update to 1.28.1 bluez-4.57-2.fc12 - * Mon Nov 02 2009 Bastien Nocera bnoc...@redhat.com 4.57-2 - Move the rfcomm.conf to the compat package, otherwise the comments at the top of it are confusing * Sun Nov 01 2009 Bastien Nocera bnoc...@redhat.com 4.57-1 - Update to 4.57 brltty-4.1-3.fc12 - * Sun Nov 01 2009 Stepan Kasal ska...@redhat.com - 4.1-3 - build the TTY driver (it was disabled since it first appered in 3.7.2-1) - build with speech-dispatcher, packed into a separate sub-package * Fri Oct 30 2009 Stepan Kasal ska...@redhat.com - 4.1-2 - move data-directory back to default: /etc/brltty - move brltty to /bin and /lib, so that it can be used to repair the system without /usr mounted (#276181) - move vstp and libbrlttybba.so to brlapi - brltty no longer requires brlapi - brlapi now requires brltty from the same build celt-0.7.0-1.fc12 - * Fri Oct 30 2009 Peter Robinson pbrobin...@gmail.com 0.7.0-1 - New 0.7.0 upstream release cernlib-2006-34.fc12 * Thu Oct 01 2009 Hans de Goede hdego...@redhat.com 2006-34 - Fix FTBFS * Fri Jul 24 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2006-33 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild dalston-0.1.11-1.fc12 - * Thu Oct 29 2009 Peter Robinson pbrobin...@gmail.com 0.1.11-1 - new upstream 0.1.11 release desktop-backgrounds-9.0.0-11 * Tue Nov 03 2009 Christoph Wickert cwick...@fedoraproject.org - 9.0.0-11 - Bump release for RC * Sun Nov 01 2009 Christoph Wickert cwick...@fedoraproject.org - 9.0.0-10 - Update for F12 constantine artwork eclipse-3.5.1-4.fc12 * Fri Oct 30 2009 Andrew Overholt overh...@redhat.com 1:3.5.1-4 - Make /usr/bin/eclipse a wrapper script due to rhbz#531675 (e.o#290395). * Wed Oct 28 2009 Alexander Kurtakov akurt...@redhat.com 1:3.5.1-2 - Don't install 2 desktop files. (rhbz #530450) eclipse-photran-5.0.0-0.2.200910081739.fc12 --- * Fri Oct 30 2009 Orion Poplawski
Re: Wodim trouble
Dne 3.11.2009 02:55, King InuYasha napsal(a): The only thing I can figure out from this conversation is that the CDDL is supposed to be incompatible with the GPL. If that's the case, why not simply ask the original creator to kindly dual license it? You must be new here :) Concerning legal issues with cdrkit, please, take a look at http://thread.gmane.org/gmane.linux.redhat.fedora.legal/473 and of course \|||/ (o o) |ooO~~(_)~~~| | Please| | don't feed the| | TROLLS ! | '~~Ooo~~' |__|__| || || ooO Ooo -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Faithful love is what people look for in a person; ... -- Proverbs 19:22 (NJB) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On 11/03/2009 03:08 PM, Joerg Schilling wrote: Josephine Tannhäuserjosephine.tannhau...@googlemail.com wrote: 2009/11/3, Joerg Schillingjoerg.schill...@fokus.fraunhofer.de: Josephine Tannhäuserjosephine.tannhau...@googlemail.com wrote: It seems that you have not been there. I was there and I was shocked about your behavior. Fortunately, you are of limited relevance and other people did not behave hostile but friendly ;-) Jörg Yeah, good way to expect any collaboration with that attitude. Keep up the good work. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC not getting __WORDSIZE set
On Mon, 2009-11-02 at 23:34 +0100, Jakub Jelinek wrote: On Mon, Nov 02, 2009 at 05:15:50PM -0500, Bryan Kearney wrote: Word of warning.. I am no too familiar with C across platforms. I am trying to package ruby-ffi (spec file is at [1]) and when I do a scratch build in Koji [2] it runs fine on x86 but is failing in ppc_64. It appears that __WORDSIZE is not being set [3]. I looked at the CFLags for the x86_64 and they are the same, so I assumed things would run fine. Can anyone point me at what to look at next? __WORDSIZE is a glibc internal macro, packages shouldn't be using it. Whether it is defined or not depends on whether any of the headers that are included needed to check that macro or not. You should be using __LP64__ or similar macros instead. atropine:~% : | cpp -dM | grep -c LP 0 What header defines __ILP32__ or __LP64__? Of course there's also: atropine:~% : | cpp -dM | grep SIZEOF #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 4 #define __SIZEOF_LONG__ 4 #define __SIZEOF_LONG_DOUBLE__ 12 #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WINT_T__ 4 #define __SIZEOF_PTRDIFF_T__ 4 #define __SIZEOF_FLOAT__ 4 #define __SIZEOF_SHORT__ 2 #define __SIZEOF_WCHAR_T__ 4 #define __SIZEOF_DOUBLE__ 8 #define __SIZEOF_LONG_LONG__ 8 - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC not getting __WORDSIZE set
On Tue, Nov 03, 2009 at 09:28:45AM -0500, Adam Jackson wrote: What header defines __ILP32__ or __LP64__? Nothing defines __ILP32__, only __LP64__: $ gcc -m64 -E -dD -xc /dev/null | grep LP64 #define _LP64 1 #define __LP64__ 1 $ gcc -m32 -E -dD -xc /dev/null | grep LP64 Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On 11/03/2009 09:13 AM, Matěj Cepl wrote: Dne 3.11.2009 02:55, King InuYasha napsal(a): The only thing I can figure out from this conversation is that the CDDL is supposed to be incompatible with the GPL. If that's the case, why not simply ask the original creator to kindly dual license it? You must be new here :) Concerning legal issues with cdrkit, please, take a look at http://thread.gmane.org/gmane.linux.redhat.fedora.legal/473 and of course \|||/ (o o) |ooO~~(_)~~~| | Please| | don't feed the| | TROLLS ! | '~~Ooo~~' |__|__| || || ooO Ooo Indeed. Specifically, the formal stance of the Fedora Project (and Red Hat Legal) is contained within my original reply to Mr. Schilling here: http://article.gmane.org/gmane.linux.redhat.fedora.legal/528 Since nothing has changed, please consider this thread closed. Continued postings will be handled under the moderation policies. Thanks, ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
2009/11/3, Joerg Schilling joerg.schill...@fokus.fraunhofer.de: Fortunately, you are of limited relevance and other people did not behave hostile but friendly ;-) Sorry Joerg, but Imho it isn't friendly to come to a booth, thump the table and say: Remove illegal software from fedora distribution, mature at the end of the year, or I will sue you. This isn't a friendly way. The booth-personnel and the bystanders didn't know with this action WHO you are or WHAT do you really want.. btw it's imho a little bit duffy to come with this request to a booth on an event like Chemnitzer Linux Tage. The quality of the content of your Messages sometimes extremly differs from your behavior, your way how you tell it. Perhaps it is me (as a woman) who is very sensitive in that case. Perhaps this is sometimes the reason that differs the pov of your counterpart you have the point from you are a troll. Think about it, perhaps twice! -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Tom \spot\ Callaway tcall...@redhat.com wrote: Since nothing has changed, please consider this thread closed. Continued postings will be handled under the moderation policies. So let us conclude: - Redhat continues to distribute cdrkit although there are known legal problems with it and Redhat has been informed more that once about this fact. - Redhat still does not like to distribute the legal original software. - Redhat still ignores the demands of the users that like to have usable software. Is this what redhat understands by living OpenSource? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Once upon a time, Joerg Schilling joerg.schill...@fokus.fraunhofer.de said: - Redhat continues to distribute cdrkit although there are known legal problems with it and Redhat has been informed more that once about this fact. it is Red Hat, not Redhat (and this is Fedora). You have refused to cite specific legal problems with cdrkit, so there are no known legal problems that anyone can see. The proper reporting method is bugzilla.redhat.com; can you point to where you reported them? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
On 11/03/2009 07:47 AM, Steve Dickson wrote:
On 11/02/2009 03:02 PM, Jesse Keating wrote:
On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote:
I'm not sure about this... Actually I like the fact we can define a
pseudo root other than '/'... which means you really want a live exported
directory with the fsid=0 option... If I am understanding what you are
saying...
No, that's not what he's saying. Even if you define a different psuedo
root other than /, it's likely more common to /not/ want that root
exported in whole, but rather smaller parts of it, just like you don't
want / exported in whole, you only want subdirectories exported.
Lets add some context to this since I *really* do want to understand
what you guys are saying...
/export *(ro,fsid=0)
/export/home *(rw)
With the above exports the only part of the server's real root ('/')
that is exposed is the /export directory. So when a client does a
'mount -o v4 server:/ /mnt'
The client will only be able to see /mnt/home (or the /export/home
export).
So as far as exposure, being able to define the root the client
will see, I think, is good thing since it will protect (or hide)
the rest of server's real root directories...
So this is why I'm understanding why the '/export' of the
'/export *(ro,fsid=0)' should not be a live export directory?
I understand that, what I'm saying is that the setting of the pseudo
root and the setting of an export *NEED* to be two different things. In
the past, any NFS export was always a real export and the only pseudo
root was always the / filesystem, *BUT* just because the / filesystem
was the pseudo root did *NOT* mean that the / filesystem itself was
mountable by clients unless it was exported in a separate export line
(get the distinction here: pseudo root existed, but wasn't exported).
Now you are telling us to create a pseudo root entry in the exports
file, and that entry is indicated by fsid=0, but you are also telling us
that simply the act of setting that entry will then add *both* a pseudo
root and a live export of the pseudo root to the world. There are many
situations I can imagine where I need the pseudo root to be something I
don't actually export, the most common and immediate case being that I
serve both NFSv4 and NFSv{3,2} where their pseudo root is always / and I
want both to have the same namespace and therefore I need v4 to have a /
pseudo root.
So, what should an exports file look like if I want to have a shared
v2/v3/v4 exports? Let's say I actually *do* want my / filesystem to be
ro mountable, then it should look like this:
/ *(ro,fsid=0) # this to set the pseudo root for v4
/ *(ro)# this to export /
/home *(rw)# you get the point
If, on the other hand, I have v2/v3/v4 enabled and I want them to have
the same mount points, and / is not one of those mount points, it should
look like this:
/ *(ro,fsid=0) # again, this should set the pseudo root *only*
/home *(rw)# now all versions see this mount, and this mount only
Now, are you saying that we should just leave out setting the pseudo
root if we don't want / to be exported in this case and that will get us
the same thing because the default pseudo root will be / anyway? If so,
that's broken behavior (that leaving the pseudo root to be a default
will set the root but not export it while setting the root will cause
the root to be exported).
As another scenario consider this: I serve out files to Windows, Mac,
and Linux computers. The files are all located under /srv. It would be
reasonable for me to define /srv as my pseudo root, especially as I have
multiple linux specific directories immediately under /srv (/srv/Linux,
/srv/Fedora, /srv/RHEL*, /srv/koji). However, I also have /srv/OS-X and
/srv/Windows. So let's say I create the exports file as such:
/srv *(ro,fsid=0)
/srv/Linux *(rw)
/srv/Fedora *(ro)
/srv/RHEL4 *(ro)
/srv/RHEL5 *(ro)
/srv/koji *(ro)
What I want out of this is on all of my clients, I want (expect) the
following command to fail:
mount server:/ /srv
I want the following command to succeed:
mount server:/Linux /srv/Linux
So, my point in all of this is that for the entire existence of the
pseudo root to date, it has always existed without also being exported
unless explicitly exported aside from being set. You can not now change
that so that setting the pseudo root also exports it. This would be a
massive regression. More importantly though, there are any number of
perfectly valid scenarios where one might want to set the pseudo root
without also exporting it. Forcing those two acts to be one and the
same more or less renders the whole feature so broken as to be
impractical to use, by design.
--
Doug Ledford dledf...@redhat.com
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP
Re: Wodim trouble
On 11/03/2009 09:52 AM, Chris Adams wrote: Once upon a time, Joerg Schilling joerg.schill...@fokus.fraunhofer.de said: -Redhat continues to distribute cdrkit although there are known legal problems with it and Redhat has been informed more that once about this fact. it is Red Hat, not Redhat (and this is Fedora). You have refused to cite specific legal problems with cdrkit, so there are no known legal problems that anyone can see. The proper reporting method is bugzilla.redhat.com; can you point to where you reported them? Guys, this is a friendly pre-warning. This thread is now covered under the hall-monitor policy. Feel free to take this discussion to fedora-legal, or preferrably, off-list. Future posts on this thread will receive a formal warning. See: https://fedoraproject.org/wiki/Hall_Monitor_Policy ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Chris Adams cmad...@hiwaay.net wrote: You have refused to cite specific legal problems with cdrkit, so there are no known legal problems that anyone can see. The proper reporting method is bugzilla.redhat.com; can you point to where you reported them? It seems that you did never check this as otherwise you did know the reports. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, 2009-11-03 at 12:58 +0100, Joerg Schilling wrote: The conclusion of all lawyers I did talk to, is that there is no legal problem with original source. There is no problem with the **source**, but the binary results most probably cannot be distributed, because they combine in a single work 2 incompatible licenses. Have you thought about using GPLv3 instead ? It may be more compatible with CDDL (needs to be run through real lawyers first of course). Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, 2009-11-03 at 15:43 +0100, Josephine Tannhäuser wrote: The quality of the content of your Messages sometimes extremly differs from your behavior, your way how you tell it. Perhaps it is me (as a woman) who is very sensitive in that case. Josephine, be reassured, it's definitely not you. Jörg is a known personality ... Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, Nov 3, 2009 at 8:53 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Chris Adams cmad...@hiwaay.net wrote: You have refused to cite specific legal problems with cdrkit, so there are no known legal problems that anyone can see. The proper reporting method is bugzilla.redhat.com; can you point to where you reported them? It seems that you did never check this as otherwise you did know the reports. Jörg Just with a quick search in the Red Hat Bugzilla, only though distro section Fedora, I found this: https://bugzilla.redhat.com/buglist.cgi?component=cdrkitproduct=Fedora https://bugzilla.redhat.com/buglist.cgi?component=cdrkitproduct=FedoraListed 39 bugs. A quick look shows a disturbing amount of WONTFIX (ignoring rhbz#472924). But I also see things have still been progressing. However, what I want to know is what prompted the relicense to CDDL in the first place? From what I can see, Jörg Schilling, you are the maintainer and creator of the original software cdrtools. Also, why are you so hostile to cdrkit? The implicitly permits forking via its redistribution clause. If you wanted to be able to mix with proprietary code and non-Linux systems, the LGPL would have been just as good. While it is true that the GPL permits linking to CDDL libraries, that is only in the case if the library is a system library, which is a library that is NECESSARY for working on a particular OS. This is usually how it is justified that GPL software can be built using Visual Studio on Windows, even if I personally don't like it. The runtime library in Windows is almost certainly not GPL compatible, as was the case for many other UNIX application runtime libraries at the time. That is what they built into the GPL, not a free for all library linking exception. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Simo Sorce sso...@redhat.com wrote: On Tue, 2009-11-03 at 12:58 +0100, Joerg Schilling wrote: The conclusion of all lawyers I did talk to, is that there is no legal problem with original source. There is no problem with the **source**, but the binary results most probably cannot be distributed, because they combine in a single work 2 incompatible licenses. Mkisofs is fully under GPL and there is no single work created that combines licenses. For this reason, there is no problem with the binaries. Note that Sun of course distributes binaries and that Sun legal checked whether distributing binaries from cdrtools could cause problems. Have you thought about using GPLv3 instead ? When the first GPLv3 draft was announced, the GPLv3 looked very interisting as GPLv3 was announced to be more permissive against OSS than GPLv2 but unfortunately, the final GPLv3 is a more restrictive license than GPLv2. It may be more compatible with CDDL (needs to be run through real lawyers first of course). While the GPLv2 gives explicit compatibility for GPLd programs to use any kind of independent library (as an independent library does not create a drived work from just linking against it), GPLv3 introduced a limitation against such combinations that is not in GPLv2. BTW: I am happy to see your post as this is the first post from a Red Hat person that looks respectful and interested in a solution. I hope we can find a solution for the current problem. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
King InuYasha ngomp...@gmail.com wrote: While it is true that the GPL permits linking to CDDL libraries, that is only in the case if the library is a system library, which is a library that is NECESSARY for working on a particular OS. This is usually how it is Please show me the exact place in the GPL text thatyou have in mind to prove your claim. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive-2009 breakage?
I had texlive* installed. After today's update, I no longer have any /usr/share/texlive directory! I'm guessing some install script removed it?? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
KDE-SIG weekly report (45/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 45/2009 Time: 2009-11-03 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-03 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.txt Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-11-03/fedora-meeting.2009-11-03-14.08.log.html -- = Participants = BenBoeckel JaroslavReznik KevinKofler RexDieter StevenParrish ThanNgo ThomasJanssen Ryan Rix -- = Agenda = * topics to discuss: o KDE-4.3.3 state o Fedora 12 looming soon, remaining issues/blockers? o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme? o VOIP meetings = Summary = o KDE-4.3.3 state * 4.3.3 is imported into devel/ branch * some remaining issues - kdebindings kde-l10n doesn't build ** Kevin_Kofler suggest mathstuff hint how to fix kdebindings ** rdieter will fix kde-l10n issues o Fedora 12 looming soon, remaining issues/blockers? * a lot of KDE SIG members are using Fedora 12 already * beta still had the install to hd link on desktop lacking execute permission problem * SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents). bug [1] added to Fedora 12 blockers tracker o constantine-kde-theme-extras, aka packaging Mosaico kdm/ksplash theme? * we agreed we don't want it, if someone is willing to fix issues, we're not blocking it * issues: ** KDM colors do not match latest wallpaper ** KSplash rectangles have bad looking shaddows * jreznik will import old Constantine to SVN o VOIP meetings * not for regular meetings (at least for now) * we try to set conference call from FUDCon -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-11-10 -- = Links = [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=529951 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
help debugging segfault with alienarena 7.32
I need to rebuild alienarena for all targets due to a security issue, so I decided to update to 7.32, but unfortunately, the 7.32 build segfaults immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output is at the bottom). Now, it is worth noting that the alienarena client does dlopen the openal-soft library by name: const char libopenal_name[] = libopenal.so.1.9.563; void *dynlib; dynlib = dlopen( libopenal_name, RTLD_LAZY | RTLD_GLOBAL ); However, I can't seem to find a breakpoint that gdb will hit before the app segfaults, and printfs never get triggered. Any and all help is appreciated, as I'd like to get this fixed before F-12. [s...@pterodactyl release]$ gdb ./crx GNU gdb (GDB) Fedora (7.0-3.fc12) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/spot/cvs/alienarena/F-12/alienarena-7.32/source/release/crx...done. (gdb) run Starting program: /home/spot/cvs/alienarena/F-12/alienarena-7.32/source/release/crx [Thread debugging using libthread_db enabled] [New Thread 0x7fffea1e0710 (LWP 18787)] [Thread 0x7fffea1e0710 (LWP 18787) exited] [New Thread 0x7fffea1e0710 (LWP 18788)] [Thread 0x7fffea1e0710 (LWP 18788) exited] [New Thread 0x7fffea1e0710 (LWP 18789)] [Thread 0x7fffea1e0710 (LWP 18789) exited] [New Thread 0x7fffea1e0710 (LWP 18790)] [Thread 0x7fffea1e0710 (LWP 18790) exited] [New Thread 0x7fffea1e0710 (LWP 18791)] Detaching after fork from child process 18792. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffea1e0710 (LWP 18791)] pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 170 LOCK Current language: auto The current source language is auto; currently asm. (gdb) info threads * 6 Thread 0x7fffea1e0710 (LWP 18791) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 1 Thread 0x77fb77e0 (LWP 18784) _dl_map_object (loader=0x77fcc4d0, name=0x7660574a libportaudio.so.2, preloaded=value optimized out, type=value optimized out, trace_mode=value optimized out, mode=-1879048190, nsid=0) at dl-load.c:1981 (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 #1 0x7fffeff883bb in ?? () #2 0x7fffea1e0710 in ?? () #3 0x74f8696a in start_thread (arg=value optimized out) at pthread_create.c:297 #4 0x75aaa8bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 0x77fb77e0 (LWP 18784))]#0 _dl_map_object (loader=0x77fcc4d0, name=0x7660574a libportaudio.so.2, preloaded=value optimized out, type=value optimized out, trace_mode=value optimized out, mode=-1879048190, nsid=0) at dl-load.c:1981 1981 if (__builtin_expect (l-l_soname_added, 1) Current language: auto The current source language is auto; currently c. (gdb) bt #0 _dl_map_object (loader=0x77fcc4d0, name=0x7660574a libportaudio.so.2, preloaded=value optimized out, type=value optimized out, trace_mode=value optimized out, mode=-1879048190, nsid=0) at dl-load.c:1981 #1 0x77df0299 in dl_open_worker (a=value optimized out) at dl-open.c:254 #2 0x77deb7c6 in _dl_catch_error (objname=value optimized out, errstring=value optimized out, mallocedp=value optimized out, operate=value optimized out, args=value optimized out) at dl-error.c:178 #3 0x77defca7 in _dl_open (file=0x7660574a libportaudio.so.2, mode=-2147483646, caller_dlopen=0x765ffaf1, nsid=-2, argc=1, argv=value optimized out, env=0x7fffe0c8) at dl-open.c:583 #4 0x77955f66 in dlopen_doit (a=value optimized out) at dlopen.c:67 #5 0x77deb7c6 in _dl_catch_error (objname=value optimized out, errstring=value optimized out, mallocedp=value optimized out, operate=value optimized out, args=value optimized out) at dl-error.c:178 #6 0x7795629c in _dlerror_run (operate=0x77955f00 dlopen_doit, args=0x7fffdeb0) at dlerror.c:164 #7 0x77955ee1 in __dlopen (file=value optimized out, mode=value optimized out) at dlopen.c:88 #8 0x765ffaf1 in pa_load () at /usr/src/debug/openal-soft/Alc/portaudio.c:66 #9 0x765ffee8 in alc_pa_probe (type=1) at /usr/src/debug/openal-soft/Alc/portaudio.c:289 #10 0x765e8bfe in alc_init () at /usr/src/debug/openal-soft/Alc/ALc.c:297 #11 0x76602556 in __do_global_ctors_aux () from /usr/lib64/libopenal.so.1 #12 0x765d8aeb in _init () from /usr/lib64/libopenal.so.1
Web page for distro life cycle stage
Hi, Is there a web-page or is it possible to have one that shows the Fedora distro release and its stage in the release cycle? For example, if a release such as Fedora 9, is not supported, one can have it shown with a red circle. If a release is in freeze, it can be in marked in an yellow circle, and when we can push packages to a release, it can be in a green circle, similar to traffic signal lights? While, we do receive e-mails on freeze updates, I thought it will be simpler to just check a web-page rather than having to go through mailing list archives? Suggestions welcome. SK -- Shakthi Kannan http://www.shakthimaan.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
On Tue, 2009-11-03 at 11:45 -0500, Tom spot Callaway wrote: I need to rebuild alienarena for all targets due to a security issue, so I decided to update to 7.32, but unfortunately, the 7.32 build segfaults immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output is at the bottom). FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before main starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? [snip] Hope this is helpful Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: libsndfile status?
On Tue, Nov 3, 2009 at 4:48 AM, Michael Schwendt wrote: https://admin.fedoraproject.org/pkgdb/packages/bugs/libsndfile What's up with libsndfile in Fedora and EPEL? There are open tickets about CVEs filed in March. There are additional tickets without any reply. Yeah, things go a little slow with libsndfile. Because of the old version we have in Fedora 12 we also are not able to update some of our audio packages. I requested for comaintainership to fix the bugs filed to Fedora. Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning (eol) gtk-qt-engine
Kevin Kofler wrote: Petrus de Calguarium wrote: By the way, colours on old kde3 apps doesn't work, either, despite enabling for non-kde4 applications in system settings (kftpgrabber) - I can see it already: file a bug report :-) There's already an ages-old bug report, the upstream KDE developers don't care. :-( ...or maybe the upstream developers don't know how to fix it. Help welcomed. (Actually, it's more accurate to say that I am not aware of anyone maintaining the 'export colors' functionality. Jeremy Whiting and I are - last I knew, anyway :-) - the nominal maintainers for color kcm stuff, and I certainly fix anything I can, but I know next to nothing about how the export colors stuff works. Ergo, I am not able to fix it.) FTR, exporting colors to GTK seems flaky also, but I'm not sure it's a KDE problem. I've noticed that after I force the export code to run (basically, make any change and apply it - even toggle a checkbox twice, you just need to be able to press 'apply'), the first app will be right, but the next one gets default colors. At least for Mozilla apps (FF, TB) and IIRC gitk. OTOH, Inkscape seems okay. I might try to fix this somehow. If you are able to help, that would be /much/ appreciated. Please don't hesitate to work upstream, I would very much like to see these issues resolved. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- HIPPOS feel unacknowledged. HIPPOS get angry. PRAISE HIPPOS HIPPOS seem somewhat placated. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
GPLv2: End of Section 3, middle of the paragraph right after clause 3c. GPLv3: Explicit separate definition in Section 1. GPLv2 Quote: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. GPLv3 Quote: The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. I hope this satisfies you. On Tue, Nov 3, 2009 at 9:19 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: King InuYasha ngomp...@gmail.com wrote: While it is true that the GPL permits linking to CDDL libraries, that is only in the case if the library is a system library, which is a library that is NECESSARY for working on a particular OS. This is usually how it is Please show me the exact place in the GPL text thatyou have in mind to prove your claim. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.deemail%3ajo...@schily.isdn.cs.tu-berlin.de(home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Joerg Schilling wrote: Libburn is based on a wrong asumption: libburn only works partly on Linux in non-root mode Actually, burning as non-root works just fine on GNU/Linux. and the vast majority of other OS needs root permissions to burn. Those OSes are broken and need to be fixed. Installing a GUI suid root is an absolute no-go as GUIs are so compley that it is hard to audit the code for security problems. We know this very well. All the Fedora system-config-* tools are being more or less rewritten to use PolicyKit to only do the parts as root which need to run as root instead of running the whole GUI config tool as root. The same is happening with KDE's System Settings and the KAuth framework (which is based on PolicyKit on GNU/Linux). But the point is that CD/DVD/BluRay burning does not and should not require root privileges at all! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
On 11/03/2009 12:16 PM, David Malcolm wrote: On Tue, 2009-11-03 at 11:45 -0500, Tom spot Callaway wrote: I need to rebuild alienarena for all targets due to a security issue, so I decided to update to 7.32, but unfortunately, the 7.32 build segfaults immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output is at the bottom). FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before main starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? It does, but it doesn't seem to be terribly useful in debugging, as it keeps hitting that breakpoint over and over and over. I admit to being reasonably clueless with gdb. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Claudio Tomasoni is now MIA
On Sun, 01 Nov 2009 02:45:10 +0100 Christoph Wickert christoph.wick...@googlemail.com wrote: This is a follow-up to my mail from October 9th [1] As per unresponsive package maintainer policy, Claudio is now officially considered missing in action and his packages [2] will be orphaned. I can ack this per the procedure as a FESCo member. I am going to orphan those packages now. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Claudio Tomasoni is now MIA
Kevin Fenzi wrote: On Sun, 01 Nov 2009 02:45:10 +0100 Christoph Wickert christoph.wick...@googlemail.com wrote: This is a follow-up to my mail from October 9th [1] As per unresponsive package maintainer policy, Claudio is now officially considered missing in action and his packages [2] will be orphaned. I can ack this per the procedure as a FESCo member. I am going to orphan those packages now. kevin Thanks. Tennix (and it's bug) taken. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, 3 Nov 2009, King InuYasha wrote: GPLv2: End of Section 3, middle of the paragraph right after clause 3c.GPLv3: Explicit separate definition in Section 1. GPLv2 Quote: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. GPLv3 Quote: The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. I hope this satisfies you. This thread is closed. please do not post any additional comments to it. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, 3 Nov 2009, Kevin Kofler wrote: Joerg Schilling wrote: You seem to miss that the license mkisofs is using is called GPL and not GPL FAQ, so the quoting you mention do not apply. The FAQ is the legal interpretation of the GPL given by the FSF, who are the folks who wrote the license, so why would you trust them less than Sun's lawyers? And Eben Moglen, whom you misquoted as agreeing with your bizarre position, was actually involved in writing both the GPL itself and the FAQ. The GPL requires the entire work to be under GPL and the entire work mkisofs _is_ of course under GPL. The entire work includes any code which is linked into the same executable, statically or dynamically. A program is not complete without its required libraries, it doesn't work at all without them. This thread is closed. Do not comment on it anymore. Sincerely, Your friendly neighborhood hall monitor. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Web page for distro life cycle stage
2009/11/3 Ikem Krueger ikem.krue...@googlemail.com: Web page for distro life cycle stage If a release is in freeze, it can be in marked in an yellow circle, and when we can push packages to a release, it can be in a green circle, similar to traffic signal lights I like this idea. :) Can't this be inferred from https://admin.fedoraproject.org/updates ? -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mesa 7.6.0 bugs
New mesa (7.6.0) is causing trouble for people using F-11/12 code (see bugs #524338 and #509528 for instance). Are there fixes available for these problems? Last time 7.6.0 packages were built was Sept 21, which is a month and a half ago and it seems that concerns from the above bugs are not being addressed. Is it too late to revert to 7.5.x, which used to work fine? -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
Joerg Schilling wrote: You seem to miss that the license mkisofs is using is called GPL and not GPL FAQ, so the quoting you mention do not apply. The FAQ is the legal interpretation of the GPL given by the FSF, who are the folks who wrote the license, so why would you trust them less than Sun's lawyers? And Eben Moglen, whom you misquoted as agreeing with your bizarre position, was actually involved in writing both the GPL itself and the FAQ. The GPL requires the entire work to be under GPL and the entire work mkisofs _is_ of course under GPL. The entire work includes any code which is linked into the same executable, statically or dynamically. A program is not complete without its required libraries, it doesn't work at all without them. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
On 11/03/2009 02:16 PM, Jerry James wrote: This seems to happen only when portaudio is installed. Uninstall portaudio and alienarena starts up. I'm not sure exactly what is going on here, but it seems that alienarena is both trying to dlopen libopenal, and is linked against it. Check it: ldd /usr/libexec/alienarena | grep -F openal My guess (and it is just a guess) is that this is triggering multiple initializations of portaudio. Try this patch: This gets me past the initial segfault, thanks! Of course, now the game won't actually start in single-player mode: CRX Initialized Received signal 11, exiting... Received signal 11, exiting... Received signal 11, exiting... Received signal 11, exiting... XIO: fatal IO error 0 (Success) on X server �o� after 2628 requests (2619 known processed) with 0 events remaining. AL lib: ALc.c:1641: exit(): closing 1 Device AL lib: ALc.c:1570: alcCloseDevice(): destroying 1 Context AL lib: ALc.c:1259: alcDestroyContext(): deleting 129 Source(s) --- Loading game.so --- AL lib: ALc.c:1579: alcCloseDevice(): deleting 256 Buffer(s) Running it again, I get: CRX Initialized Received signal 11, exiting... Received signal 11, exiting... XIO: fatal IO error 0 (Success) on X server P�% after 657 requests (654 known processed) with 0 events remaining. AL lib: ALc.c:1641: exit(): closing 1 Device AL lib: ALc.c:1570: alcCloseDevice(): destroying 1 Context Received signal 11, exiting... Received signal 11, exiting... *** glibc detected *** ./crx: free(): invalid pointer: 0x07263c00 *** Received signal 11, exiting... *** glibc detected *** ./crx: free(): invalid pointer: 0x07263c00 *** Segmentation fault Valgrind isn't much more help: ==22231== Process terminating with default action of signal 11 (SIGSEGV) ==22231== Bad permissions for mapped region at address 0xFA9CB20 ==22231==at 0xA1663E0: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:170) ==22231==by 0xF88B3BA: ??? (in /usr/lib64/libportaudio.so.2.0.0) The latest patched build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1786476 It does work in multi-player mode, just not single player. Any more ideas? :) ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
On Tue, Nov 3, 2009 at 9:45 AM, Tom spot Callaway tcall...@redhat.com wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffea1e0710 (LWP 18791)] pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 170 LOCK Current language: auto The current source language is auto; currently asm. (gdb) info threads * 6 Thread 0x7fffea1e0710 (LWP 18791) pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:170 1 Thread 0x77fb77e0 (LWP 18784) _dl_map_object (loader=0x77fcc4d0, name=0x7660574a libportaudio.so.2, preloaded=value optimized out, type=value optimized out, trace_mode=value optimized out, mode=-1879048190, nsid=0) at dl-load.c:1981 This seems to happen only when portaudio is installed. Uninstall portaudio and alienarena starts up. I'm not sure exactly what is going on here, but it seems that alienarena is both trying to dlopen libopenal, and is linked against it. Check it: ldd /usr/libexec/alienarena | grep -F openal My guess (and it is just a guess) is that this is triggering multiple initializations of portaudio. Try this patch: diff -dur alienarena-7.32.ORIG/source/Makefile alienarena-7.32/source/Makefile --- alienarena-7.32.ORIG/source/Makefile2009-11-02 19:01:01.0 -0700 +++ alienarena-7.32/source/Makefile 2009-11-03 12:05:38.283115734 -0700 @@ -266,7 +266,7 @@ $(BUILDDIR)/crx : $(CODERED_OBJS) $(SOUND_OPENAL_OBJS) $(REF_GL_OBJS) $(REF_GL_GLX_OBJS) - $(CC) $(CFLAGS) -o $@ $(CODERED_OBJS) $(LDFLAGS) $(REF_GL_OBJS) $(REF_GL_GLX_OBJS) $(GLXLDFLAGS) $(OPENALLDFLAGS) $(VORBISLDFLAGS) $(CURLLDFLAGS) $(JPEGLDFLAGS) + $(CC) $(CFLAGS) -o $@ $(CODERED_OBJS) $(LDFLAGS) $(REF_GL_OBJS) $(REF_GL_GLX_OBJS) $(GLXLDFLAGS) $(VORBISLDFLAGS) $(CURLLDFLAGS) $(JPEGLDFLAGS) $(BUILDDIR)/client/cl_ents.o :$(CLIENT_DIR)/cl_ents.c $(DO_CC) -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before main starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? It does, but it doesn't seem to be terribly useful in debugging, as it keeps hitting that breakpoint over and over and over. (gdb) set stop-on-solib-events 1 (gdb) run args... Stopped due to shared library event (gdb) info shared FromTo Syms Read Shared Object Library 0x00dc2830 0x00ddb27f Yes /lib/ld-linux.so.2 0x00ae4410 0x00ae45e8 Yes a.out (gdb) c Continuing. Stopped due to shared library event (gdb) info shared FromTo Syms Read Shared Object Library 0x00dc2830 0x00ddb27f Yes /lib/ld-linux.so.2 0x00ae4410 0x00ae45e8 Yes a.out 0x00e5a840 0x00f68c78 Yes /lib/libc.so.6 etc. You might run afoul of this years-old bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179072 Post the build, or a pointer to it, plus the needed environment? -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
texlive-2009 tlmgr
tlmgr Can't locate TeXLive/TLPOBJ.pm in @INC (@INC contains: /usr/share/texlive/tlpkg /usr/local/lib64/perl5/site_perl/5.10.0/x86_64- linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl .) at /usr/bin/tlmgr line 36. BEGIN failed--compilation aborted at /usr/bin/tlmgr line 36. sure enough, /usr/share/texlive/tlpkg dir exists, but is empty. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Web page for distro life cycle stage
Web page for distro life cycle stage If a release is in freeze, it can be in marked in an yellow circle, and when we can push packages to a release, it can be in a green circle, similar to traffic signal lights I like this idea. :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wodim trouble
On Tue, 3 Nov 2009, Kevin Kofler wrote: Joerg Schilling wrote: Libburn is based on a wrong asumption: libburn only works partly on Linux in non-root mode Actually, burning as non-root works just fine on GNU/Linux. and the vast majority of other OS needs root permissions to burn. Those OSes are broken and need to be fixed. Installing a GUI suid root is an absolute no-go as GUIs are so compley that it is hard to audit the code for security problems. We know this very well. All the Fedora system-config-* tools are being more or less rewritten to use PolicyKit to only do the parts as root which need to run as root instead of running the whole GUI config tool as root. The same is happening with KDE's System Settings and the KAuth framework (which is based on PolicyKit on GNU/Linux). But the point is that CD/DVD/BluRay burning does not and should not require root privileges at all! Kevin, please. Stop responding. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
A question about allow_unconfined_mmap_low in f11 amd selinux
For people running wine or Crossover and using MS Office 2003 and related codes it is necessary to do: # setsebool -P allow_unconfined_mmap_low 1 To prevent AVC denials. However there is recent publicity at http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ which highlights that there is still a vulnerability in the kernel if this is set. For people running f11 with this boolean set how can one run wine and still remain secure? i.e. what should an admin do to protect the system? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Tue, 2009-11-03 at 21:31 +, Mike Cloaked wrote: For people running wine or Crossover and using MS Office 2003 and related codes it is necessary to do: # setsebool -P allow_unconfined_mmap_low 1 To prevent AVC denials. However there is recent publicity at http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ which highlights that there is still a vulnerability in the kernel if this is set. For people running f11 with this boolean set how can one run wine and still remain secure? i.e. what should an admin do to protect the system? You can't. If I'm being slightly less flip: run wine in a kvm instance with selinux disabled, forward X to the host. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Web page for distro life cycle stage
Hi, --- On Wed, Nov 4, 2009 at 4:41 AM, Mat Booth fed...@matbooth.co.uk wrote: | Can't this be inferred from https://admin.fedoraproject.org/updates ? \-- I was looking at something with less text, and having a pictorial representation. Sometimes, a picture is a thousand words! SK -- Shakthi Kannan http://www.shakthimaan.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 522187] SWT crash (in theory in pango but more likely in GTK)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=522187 nh2 nh2-redhatbugzi...@deditus.de changed: What|Removed |Added CC||nh2-redhatbugzi...@deditus. ||de --- Comment #29 from nh2 nh2-redhatbugzi...@deditus.de 2009-11-03 08:03:16 EDT --- See Ubuntu Bug 445009 (https://bugs.launchpad.net/bug/445009) for a possible workaround (turn of Assistive Technologies). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 522187] SWT crash (in theory in pango but more likely in GTK)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=522187 --- Comment #30 from nh2 nh2-redhatbugzi...@deditus.de 2009-11-03 08:05:14 EDT --- Sorry, a typo. The URL is https://bugs.launchpad.net/bugs/445009. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 532231] Review Request: gdouros-akkadian-fonts - A font for Sumero-Akkadian cuneiform
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=532231 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added AssignedTo|nob...@fedoraproject.org|ozam...@flukkost.nu Flag||fedora-review+ --- Comment #1 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-11-03 14:27:04 EDT --- Nothing to say here, clean font and clean packaging ᚸᚸᚸ APPROVED ᚸᚸᚸ You can now continue from http://fedoraproject.org/wiki/Font_package_lifecycle#3.a Nice work. repo-font-audit notes the font could be extended easily to cover more scripts -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 532237] gedit defaults to bitmap fonts with kanji
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=532237 --- Comment #3 from Akira TAGOH ta...@redhat.com 2009-11-03 21:23:05 EDT --- Hmm, weird. so the suggestion from nim-nim on the package review was wrong and the priority on our fontconfig l10n template won't effects reversely? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 530880] Review Request: ns-tiza-fonts - A Slab-Serif Font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=530880 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added Flag||needinfo?(john.brown...@gma ||il.com) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 225617] Merge Review: bitmap-fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225617 Nicolas Mailhot nicolas.mail...@laposte.net changed: What|Removed |Added Flag||needinfo?(psatp...@redhat.c ||om) --- Comment #28 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-11-03 14:28:52 EDT --- Please lift the NEEDINFO when you're ready to pass to the next stage -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/gdouros-akkadian-fonts/F-11 gdouros-akkadian-fonts-fontconfig.conf, NONE, 1.1 gdouros-akkadian-fonts.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: ozamosi
Update of /cvs/pkgs/rpms/gdouros-akkadian-fonts/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv11450
Modified Files:
.cvsignore sources
Added Files:
gdouros-akkadian-fonts-fontconfig.conf
gdouros-akkadian-fonts.spec
Log Message:
Version 2.52
--- NEW FILE gdouros-akkadian-fonts-fontconfig.conf ---
?xml version=1.0?
!DOCTYPE fontconfig SYSTEM fonts.dtd
fontconfig
alias
familyfantasy/family
prefer
familyAkkadian/family
/prefer
/alias
alias
familyAkkadian/family
default
familyfantasy/family
/default
/alias
/fontconfig
--- NEW FILE gdouros-akkadian-fonts.spec ---
%global fontname gdouros-akkadian
%global fontconf 65-%{fontname}.conf
Name: %{fontname}-fonts
Version:2.52
Release:1%{?dist}
Summary:A font for Sumero-Akkadian cuneiform
Group: User Interface/X
License:Copyright only
URL:http://users.teilar.gr/~g1951d/
Source0:http://users.teilar.gr/~g1951d/Akkadian.zip
Source1:%{name}-fontconfig.conf
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildArch: noarch
BuildRequires: fontpackages-devel
Requires: fontpackages-filesystem
%description
Akkadian covers the following scripts and symbols supported by The Unicode
Standard 5.2: Basic Latin, Greek and Coptic, some Punctuation and other
Symbols, Cuneiform, Cuneiform Numbers and Punctuation.
It was created by George Douros.
%prep
%setup -q -c
%build
%install
rm -fr %{buildroot}
install -m 0755 -d %{buildroot}%{_fontdir}
install -m 0644 -p Akkadian.otf %{buildroot}%{_fontdir}
install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
%{buildroot}%{_fontconfig_confdir}
install -m 0644 -p %{SOURCE1} \
%{buildroot}%{_fontconfig_templatedir}/%{fontconf}
ln -s %{_fontconfig_templatedir}/%{fontconf} \
%{buildroot}%{_fontconfig_confdir}/%{fontconf}
%clean
rm -fr %{buildroot}
%_font_pkg -f %{fontconf} Akkadian.otf
%doc
%changelog
* Thu Oct 22 2009 Robin Sonefors ozam...@flukkost.nu - 2.52-1
- Initial packaging
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/gdouros-akkadian-fonts/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Nov 2009 21:53:46 - 1.1
+++ .cvsignore 4 Nov 2009 00:02:32 - 1.2
@@ -0,0 +1 @@
+Akkadian.zip
Index: sources
===
RCS file: /cvs/pkgs/rpms/gdouros-akkadian-fonts/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Nov 2009 21:53:46 - 1.1
+++ sources 4 Nov 2009 00:02:33 - 1.2
@@ -0,0 +1 @@
+dec2b1988c44b286199b7f7aed0e4119 Akkadian.zip
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 532816] Review Request: gdouros-alexander-fonts - A Greek typeface inspired by Alexander Wilson
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=532816 Robin Sonefors ozam...@flukkost.nu changed: What|Removed |Added CC||fedora-fonts-bugs-l...@redh ||at.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 530880] Review Request: ns-tiza-fonts - A Slab-Serif Font
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=530880
Nicolas Mailhot nicolas.mail...@laposte.net changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|nob...@fedoraproject.org|nicolas.mail...@laposte.net
Flag||fedora-review?
--- Comment #1 from Nicolas Mailhot nicolas.mail...@laposte.net 2009-11-03
15:12:57 EDT ---
Hi Edward,
1. You seem to have based your packaging on an old (pre-fedora-11) template.
Please rebase on the fonts template found in fontpackages-devel. It will
considerably simplify your packaging and do more things such as generating rpm
metadata for the font auto-installer
2. description:
inspired on ⇒ inspired by ?
accent marks ⇒ diacritics http://en.wikipedia.org/wiki/Diacritic
ASCII ⇒ basic latin http://www.unicode.org/charts/PDF/U.pdf
3. summary: you need to find a short statement that describes the font without
using its name (the font name is already included in the package name, and
every package manager will display the package name next to the summary)
4. repo-font-audit notes your rpm is not including font metadata (due to the
previously mentioned bad template choice) and that the font could be easily
extended to cover more scripts (to relay upstream)
af(1) { 0149 }
az-az(8) { 011e 011f 0130 0131 015e 015f 018f 0259 }
bin(6) { 0300 0301 1eb8 1eb9 1ecc 1ecd }
bm(8) { 014a 014b 0186 0190 019d 0254 025b 0272 }
ca(2) { 013f 0140 }
co(5) { 00c6 00e6 0152 0153 0178 }
crh(6) { 011e 011f 0130 0131 015e 015f }
csb(8) { 0104 0105 0141 0142 0143 0144 017b 017c }
da(2) { 00c6 00e6 }
de(1) { 00df }
et(4) { 0160 0161 017d 017e }
fi(4) { 0160 0161 017d 017e }
fo(3) { 00c6 00e6 00f0 }
fr(5) { 00c6 00e6 0152 0153 0178 }
fy(1) { 00df }
gn(4) { 0129 0169 1ebd 1ef9 }
ha(8) { 0181 018a 0198 0199 01b3 01b4 0253 0257 }
hu(4) { 0150 0151 0170 0171 }
hz(5) { 032f 1e12 1e13 1e4a 1e4b }
ig(6) { 1eca 1ecb 1ecc 1ecd 1ee4 1ee5 }
is(5) { 00c6 00de 00e6 00f0 00fe }
ki(4) { 0128 0129 0168 0169 }
kl(7) { 00c6 00e6 0128 0129 0138 0168 0169 }
kr(4) { 018e 01dd 024c 024d }
ku-tr(2) { 015e 015f }
lb(1) { 00df }
lg(2) { 014a 014b }
ln(9) { 011a 011b 0186 0190 0254 025b 0301 0302 030c }
mt(8) { 010a 010b 0120 0121 0126 0127 017b 017c }
na(2) { 0168 0169 }
nb(2) { 00c6 00e6 }
nds(1) { 00df }
nn(2) { 00c6 00e6 }
no(2) { 00c6 00e6 }
nso(2) { 0160 0161 }
ny(2) { 0174 0175 }
qu(1) { 02c8 }
ro(6) { 0102 0103 0218 0219 021a 021b }
sco(4) { 01b7 021c 021d 0292 }
shs(1) { 0313 }
sm(1) { 02bb }tig(221)
tk(6) { 0147 0148 015e 015f 017d 017e }
tn(2) { 0160 0161 }
to(1) { 02bb }
tr(6) { 011e 011f 0130 0131 015e 015f }vi(110) vo(0)
vot(4) { 0160 0161 017d 017e }
wo(2) { 014a 014b }
5. the OFL license joined to the file claims the author reserves the name as
Tiza Chalk, but the name the font declares is just Tiza, so maybe upstream
did a mistake here. It's very unusual to reserve a name different from the name
the font declares. If upstream decides the font is Tiza Chalk after all you'll
have to rename the package which is much easier to do before inclusion in
Fedora (also need to update the fontconfig rules, but this part is easy)
6. Please ask upstream to update the licensing info in the font file next time
they update it (the font file still claims its licensing is CC-By, not OFL)
7. It would probably also be a good idea to check fontlint, though its messages
are clear as mud as usual
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/gdouros-akkadian-fonts/devel gdouros-akkadian-fonts-fontconfig.conf, NONE, 1.1 gdouros-akkadian-fonts.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: ozamosi
Update of /cvs/pkgs/rpms/gdouros-akkadian-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv32277
Modified Files:
.cvsignore sources
Added Files:
gdouros-akkadian-fonts-fontconfig.conf
gdouros-akkadian-fonts.spec
Log Message:
Version 2.52
--- NEW FILE gdouros-akkadian-fonts-fontconfig.conf ---
?xml version=1.0?
!DOCTYPE fontconfig SYSTEM fonts.dtd
fontconfig
alias
familyfantasy/family
prefer
familyAkkadian/family
/prefer
/alias
alias
familyAkkadian/family
default
familyfantasy/family
/default
/alias
/fontconfig
--- NEW FILE gdouros-akkadian-fonts.spec ---
%global fontname gdouros-akkadian
%global fontconf 65-%{fontname}.conf
Name: %{fontname}-fonts
Version:2.52
Release:1%{?dist}
Summary:A font for Sumero-Akkadian cuneiform
Group: User Interface/X
License:Copyright only
URL:http://users.teilar.gr/~g1951d/
Source0:http://users.teilar.gr/~g1951d/Akkadian.zip
Source1:%{name}-fontconfig.conf
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
BuildArch: noarch
BuildRequires: fontpackages-devel
Requires: fontpackages-filesystem
%description
Akkadian covers the following scripts and symbols supported by The Unicode
Standard 5.2: Basic Latin, Greek and Coptic, some Punctuation and other
Symbols, Cuneiform, Cuneiform Numbers and Punctuation.
It was created by George Douros.
%prep
%setup -q -c
%build
%install
rm -fr %{buildroot}
install -m 0755 -d %{buildroot}%{_fontdir}
install -m 0644 -p Akkadian.otf %{buildroot}%{_fontdir}
install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
%{buildroot}%{_fontconfig_confdir}
install -m 0644 -p %{SOURCE1} \
%{buildroot}%{_fontconfig_templatedir}/%{fontconf}
ln -s %{_fontconfig_templatedir}/%{fontconf} \
%{buildroot}%{_fontconfig_confdir}/%{fontconf}
%clean
rm -fr %{buildroot}
%_font_pkg -f %{fontconf} Akkadian.otf
%doc
%changelog
* Thu Oct 22 2009 Robin Sonefors ozam...@flukkost.nu - 2.52-1
- Initial packaging
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/gdouros-akkadian-fonts/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Nov 2009 21:53:46 - 1.1
+++ .cvsignore 3 Nov 2009 23:03:04 - 1.2
@@ -0,0 +1 @@
+Akkadian.zip
Index: sources
===
RCS file: /cvs/pkgs/rpms/gdouros-akkadian-fonts/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Nov 2009 21:53:46 - 1.1
+++ sources 3 Nov 2009 23:03:05 - 1.2
@@ -0,0 +1 @@
+dec2b1988c44b286199b7f7aed0e4119 Akkadian.zip
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 225617] Merge Review: bitmap-fonts
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225617 Pravin Satpute psatp...@redhat.com changed: What|Removed |Added Flag|needinfo?(psatp...@redhat.c | |om) | --- Comment #29 from Pravin Satpute psatp...@redhat.com 2009-11-03 23:03:00 EDT --- i will resolve the above problem, will try to resolve it else will drop it. is anything to do more from my side? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 532231] Review Request: gdouros-akkadian-fonts - A font for Sumero-Akkadian cuneiform
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=532231 Robin Sonefors ozam...@flukkost.nu changed: What|Removed |Added Flag||fedora-cvs? --- Comment #2 from Robin Sonefors ozam...@flukkost.nu 2009-11-03 16:50:55 EDT --- New Package CVS Request === Package Name: gdouros-akkadian-fonts Short Description: A font for Sumero-Akkadian cuneiform Owners: ozamosi Branches: F11 F12 InitialCC: fonts-sig -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 532819] Review Request: gdouros-symbola-fonts - A symbol font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=532819 Robin Sonefors ozam...@flukkost.nu changed: What|Removed |Added CC||fedora-fonts-bugs-l...@redh ||at.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 532817] Review Request: gdouros-analecta-fonts - An eccleastic scripts font
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=532817 Robin Sonefors ozam...@flukkost.nu changed: What|Removed |Added CC||fedora-fonts-bugs-l...@redh ||at.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
rpms/cjkuni-fonts/devel cjkuni-fonts.spec,1.15,1.16
Author: petersen
Update of /cvs/pkgs/rpms/cjkuni-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4962
Modified Files:
cjkuni-fonts.spec
Log Message:
drop bitmap fontconfig .conf for now (#459680)
Index: cjkuni-fonts.spec
===
RCS file: /cvs/pkgs/rpms/cjkuni-fonts/devel/cjkuni-fonts.spec,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- cjkuni-fonts.spec 22 Oct 2009 01:36:57 - 1.15
+++ cjkuni-fonts.spec 4 Nov 2009 06:37:14 - 1.16
@@ -23,7 +23,7 @@ the CJK Unifonts project.
Name:%{fontname}-fonts
Version: 0.2.20080216.1
-Release: 29%{?dist}
+Release: 30%{?dist}
Summary: Chinese Unicode TrueType fonts in Ming and Kai face.
License: Arphic
Group: User Interface/X
@@ -215,6 +215,9 @@ do
done
cd ../
+# drop small bitmap rendering for now
+rm %{buildroot}%{_fontconfig_confdir}/25-ttf-arphic-uming-bitmaps.conf
+
# ghostscript
cd %{gsbuilddir}
%__install -m 0755 -d %{buildroot}%{gsdir}
@@ -245,13 +248,16 @@ cd ../
%__rm -fr %{buildroot}
%changelog
-* Thu Oct 22 2009 Caius 'kaio' Chance k at kaio.me - 0.2.20080216.1-29.fc13
+* Wed Nov 4 2009 Jens Petersen peter...@redhat.com - 0.2.20080216.1-30
+- drop bitmap fontconfig .conf for now (#459680)
+
+* Thu Oct 22 2009 Caius 'kaio' Chance ccha...@redhat.com -
0.2.20080216.1-29.fc13
- Rebuilt.
-* Thu Oct 22 2009 Caius 'kaio' Chance k at kaio.me - 0.2.20080216.1-28.fc13
+* Thu Oct 22 2009 Caius 'kaio' Chance ccha...@redhat.com -
0.2.20080216.1-28.fc13
- Resolves: 529975 - Make ghostscript address to be dynamic generated.
-* Mon Sep 21 2009 Caius 'kaio' Chance k at kaio.me - 0.2.20080216.1-27.fc12
+* Mon Sep 21 2009 Caius 'kaio' Chance ccha...@redhat.com -
0.2.20080216.1-27.fc12
- Merged from F-11 tree.
- Obsoleted cjkuni-fonts-common.
- Resolves: rhbz#507637 (using font.{dir,scale} from upstream source)
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 459680] qt/kde: font antialiasing was disabled by uming fontconfig file.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=459680 --- Comment #64 from Jens Petersen peter...@redhat.com 2009-11-04 01:40:29 EDT --- I removed the bitmap fontconfig in cjkuni-fonts-0.2.20080216.1-30.fc13. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
How do we link the auto-update of ssh banner with update of wiki page?
Hi, I found that if I update http://fedoraproject.org/wiki/Infrastructure/Server/publictest16, the welcome banner of pt16 changes too. How is it done? Looks interesting. Thanks. -- Regards, Susmit. = http://www.fedoraproject.org/wiki/user:susmit = ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Fedora-legal-list] XSkat license
On 11/02/2009 04:53 PM, Christian Krause wrote: Is this license acceptable for Fedora too and if yes, what should I put in RPM's License tag? If (and only if) clause 2.b is used instead of clause 2.a (the license explicitly gives you a choice), then the license is Free but GPL incompatible. I've added it to the list as XSkat, use that in the License tag. Do we have to handle the version in the rpm package differently or can we assume that our regular NVR is sufficient to fulfill 2.b? You do need to handle it differently. I suggest that you simply always add a .0 to the end of the upstream version in the RPM package. You need to do this, and not simply use the regular NVR to fulfill 2.b, because the license explicitly specifies the versioning schema x.y.z, which is different from how RPM displays it (x.y-z). Just add a dummy .0 to the end of the version then increment the Release field like any other package. The RPM changelog is sufficient to meet the other requirement of 2.b, to clearly state who last changed the program. The license page for XSkat also covers this, in case any other program uses this license (or code from XSkat). ~spot ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: [Fedora-legal-list] Hopefully simple GPL licensing question re Netomata
On 11/03/2009 04:25 PM, David Nalley wrote: So I started looking at packaging Netomata ( http://www.netomata.com/products/ncg ) and came across something that raises a flag. The author is also at a conference with me this week, so I figured the face time would be a good time to request a change if something is required. The question I have, is does the 'All Rights Reserved' in each source file conflict with the GPLv3 that they claim the package is released under, and is it a problem wrt Packaging Guidelines. Well, they really should drop the All Rights Reserved, it is no longer necessary (see: http://en.wikipedia.or/wiki/All_rights_reserved). It is a potential source of confusion, since the GPL grants some rights to the user which are normally only available to the copyright holder. However, strictly speaking, it is not a problem for Fedora in this case, since the all rights reserved, just means that the copyright holder hasn't waived those rights (and the GPLv3 doesn't actually waive any rights). It's a balancing act though, which is why I'd strongly recommend that they drop the All Rights Reserved wording to eliminate all confusion. ~spot ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:-Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :-Mobile Intel(R) Graphics Media Accelerator X4500M Yes, you should go for 64-bit if your hardware supports it, because only a 64-bit kernel will use that hardware at its full capacities. Google is your friend. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Samba with Windows XP client
On Tue, 2009-11-03 at 00:55 -0500, Jud Craft wrote: At the very least, it would be lovely if Fedora user desktops could reliably network with -themselves-. I use NFS for that, works brilliantly. I see no point in adding the foibles of Samba into my computer networking. Though, long ago when I did play with Samba, I noticed there were some additional features for making it work with other Linux boxes in a more Linux way (e.g. using Linux permissions normally). -- [...@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 01:34 PM, Aioanei Rares wrote: On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:-Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :-Mobile Intel(R) Graphics Media Accelerator X4500M Yes, you should go for 64-bit if your hardware supports it, because only a 64-bit kernel will use that hardware at its full capacities. Google is your friend. ok thank you for your kind reply one more question is there in my mind that will I see any significant improvements in speed related issue if I go with 64bit version of OS ?? -- °v° /(_)\ ^ ^ Jatin Khatri No MS -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 11:15 AM, Jatin K wrote: On 11/03/2009 01:34 PM, Aioanei Rares wrote: On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:-Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :-Mobile Intel(R) Graphics Media Accelerator X4500M Yes, you should go for 64-bit if your hardware supports it, because only a 64-bit kernel will use that hardware at its full capacities. Google is your friend. ok thank you for your kind reply one more question is there in my mind that will I see any significant improvements in speed related issue if I go with 64bit version of OS ?? Some people reported overall speed increases because of the reasons mentioned earlier; however, do you have a reason not to go 64-bit? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 02:55 PM, Aioanei Rares wrote: On 11/03/2009 11:15 AM, Jatin K wrote: On 11/03/2009 01:34 PM, Aioanei Rares wrote: On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:-Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :-Mobile Intel(R) Graphics Media Accelerator X4500M Yes, you should go for 64-bit if your hardware supports it, because only a 64-bit kernel will use that hardware at its full capacities. Google is your friend. ok thank you for your kind reply one more question is there in my mind that will I see any significant improvements in speed related issue if I go with 64bit version of OS ?? Some people reported overall speed increases because of the reasons mentioned earlier; however, do you have a reason not to go 64-bit? one I heard that adobe flash has some problems with 64bit kernel . and other 32bit software creates some problem ( I'm not instrumenting with you ... I just need suggestion from the list so please don't misunderstand me ) Regards -- °v° /(_)\ ^ ^ Jatin Khatri No MS -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 12:15 PM, Jatin K wrote: On 11/03/2009 02:55 PM, Aioanei Rares wrote: On 11/03/2009 11:15 AM, Jatin K wrote: On 11/03/2009 01:34 PM, Aioanei Rares wrote: On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:-Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :-Mobile Intel(R) Graphics Media Accelerator X4500M Yes, you should go for 64-bit if your hardware supports it, because only a 64-bit kernel will use that hardware at its full capacities. Google is your friend. ok thank you for your kind reply one more question is there in my mind that will I see any significant improvements in speed related issue if I go with 64bit version of OS ?? Some people reported overall speed increases because of the reasons mentioned earlier; however, do you have a reason not to go 64-bit? one I heard that adobe flash has some problems with 64bit kernel . and other 32bit software creates some problem ( I'm not instrumenting with you ... I just need suggestion from the list so please don't misunderstand me ) Regards My thinking is it's not safe to decide on what you've heard. Flash works like a charm on all my 64-bit systems; and what is that other software are you referring to? 64-bit Linux has also 32-bit libs if needed. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: package for basic examination of .dv video files?
On Mon, 2 Nov 2009, Patrick O'Callaghan wrote: On Mon, 2009-11-02 at 19:42 -0500, Robert P. J. Day wrote: On Mon, 2 Nov 2009, Patrick O'Callaghan wrote: On Mon, 2009-11-02 at 13:49 -0500, Robert P. J. Day wrote: is there a package of basic .dv video file utilities, particularly for just *examining* the properties of a .dv file? i've yum searched and nothing jumps out at me. i'm just after some command-line utilities that allow me to *inspect* the innards of various video file formats, not necessarily do any transformations. thanks. Try tcprobe (part of the transcode package). I don't know if it handles DV but it's easy to test. yup, that's a start, but i'm not sure how to parse the output: $ tcprobe -i sample.dv [tcprobe] Digital Video (NTSC) [tcprobe] summary for sample.dv, (*) = not default, 0 = not detected import frame size: -g 720x480 [720x576] (*) aspect ratio: 4:3 (*) frame rate: -f 29.970 [25.000] frc=4 (*) audio track: -a 0 [0] -e 32000,16,2 [48000,16,2] -n 0x1 [0x2000] (*) bitrate=1024 kbps $ i'm unfamiliar with the output format of tcprobe, so what's the deal with two different frame sizes being printed? and two different frame rates? how should i interpret that? thanks. Yes, I've often wondered that myself :-) The manual is silent on this subject. However a possible interpretation is that the bracketed numbers indicate defaults. Thus 720x480 is a 4x3 aspect ratio but the actual frame size is different so the video will be distorted. Transcode can crop, pad or rescale it to the correct ratio if required. i suspect this is getting a bit far afield from a fedora topic, so i'm going to look for a more appropriate forum -- a mailing list for people interested in linux video, methinks. but just to close this off, here's the results of my latest experimentation. i have two .dv files i grabbed off the net, but file clearly sees a difference: $ file *.dv pond.dv: data sample.dv: DIF (DV) movie file (NTSC) $ curiously, playdv (from the libdv-tools package) appears to play both just fine, but tcprobe definitely sees a difference: $ tcprobe -i sample.dv [tcprobe] Digital Video (NTSC) [tcprobe] summary for sample.dv, (*) = not default, 0 = not detected import frame size: -g 720x480 [720x576] (*) aspect ratio: 4:3 (*) frame rate: -f 29.970 [25.000] frc=4 (*) audio track: -a 0 [0] -e 32000,16,2 [48000,16,2] -n 0x1 [0x2000] (*) bitrate=1024 kbps $ tcprobe -i pond.dv [probe_ffmpeg.c] critical: unable to open 'pond.dv' (libavformat failure) [tcprobe] critical: failed to probe source [rpj...@localhost dv_files]$ now i'd like to test using the x264 utility to convert to raw h.264 format: $ x264 -o sample.264 sample.dv x264 [error]: Rawyuv input requires a resolution. $ ok, let's throw a resolution at it: $ x264 -o sample.264 sample.dv 720x480 x264 [info]: 720x480 @ 25.00 fps x264 [error]: no ratecontrol method specified x264 [error]: x264_encoder_open failed $ and, at this point, i think it's time to crack open a book on video and get familiar so i know what the diagnostics mean. what i was after was pulling together a collection of command-line utilities for examining and converting video files of various formats, that's all. apparently, i still have some research to do. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 03:58 PM, Aioanei Rares wrote: On 11/03/2009 12:15 PM, Jatin K wrote: On 11/03/2009 02:55 PM, Aioanei Rares wrote: On 11/03/2009 11:15 AM, Jatin K wrote: On 11/03/2009 01:34 PM, Aioanei Rares wrote: On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:-Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :-Mobile Intel(R) Graphics Media Accelerator X4500M Yes, you should go for 64-bit if your hardware supports it, because only a 64-bit kernel will use that hardware at its full capacities. Google is your friend. ok thank you for your kind reply one more question is there in my mind that will I see any significant improvements in speed related issue if I go with 64bit version of OS ?? Some people reported overall speed increases because of the reasons mentioned earlier; however, do you have a reason not to go 64-bit? one I heard that adobe flash has some problems with 64bit kernel . and other 32bit software creates some problem ( I'm not instrumenting with you ... I just need suggestion from the list so please don't misunderstand me ) Regards My thinking is it's not safe to decide on what you've heard. Flash works like a charm on all my 64-bit systems; and what is that other software are you referring to? 64-bit Linux has also 32-bit libs if needed. ok then I will go for 64bit .. thank you very much for kind information ... Regards -- °v° /(_)\ ^ ^ Jatin Khatri No MS -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[SOLVED]should I go for 64bit version of Fedora 11 ?
On 11/03/2009 03:58 PM, Aioanei Rares wrote:
On 11/03/2009 12:15 PM, Jatin K wrote:
On 11/03/2009 02:55 PM, Aioanei Rares wrote:
On 11/03/2009 11:15 AM, Jatin K wrote:
On 11/03/2009 01:34 PM, Aioanei Rares wrote:
On 11/03/2009 09:38 AM, Jatin K wrote:
Dear all
I've purchased a new Dell laptop Vostro 1520, major
configuration[1] , My question is should I go for FC 11 64bit
version ? is there any significant benefit if I use 64bit version ?
[1]
Model :- Dell Vostro 1520 P-series
Processor:- Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT
enabled )
RAM :- 3GB DDR2 800Mhz
Graphics :- Mobile Intel(R) Graphics Media Accelerator X4500M
My thinking is it's not safe to decide on what you've heard. Flash
works like a charm on all my 64-bit systems; and what is that other
software are you referring to? 64-bit Linux has also 32-bit libs if
needed.
Ok , I have find this [a] by googling
[a]
---
For 64-bit Ubuntu, finding the proper 32-bit support packages is a
simple matter of opening up the Synaptic Package Manager, and searching
for the string “ia32”. With 64-bit openSuSE, 32-bit support is already
built-in, so you don’t have to do anything. With Fedora, though, it’s a
whole different story. Not only are the 32-bit packages not already
installed, the Fedora folk don’t provide any documentation on how to
install them. The directions I found via Google were outdated, and
wouldn’t work. I finally resolved the problem by asking a Red Hat
employee in my local Linux Users Group.
*Add an “rpm” Macro*
This isn’t an absolute necessity, but it’s handy. Add the following line
to the “/etc/rpm/macros” file:
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
Now, when you query for information about rpm packages, you’ll be able
to see whether they’re 32-bit or 64-bit packages.
sudo rpm -q SDL
SDL-1.2.13-9.fc11.x86_64
*Add the Libraries*
Next, add the 32-bit libraries by copying the following list, and
pasting it into a text file. Save it as “Fedora-ia32.txt”.
arts.i586
audiofile.i586
bzip2-libs.i586
cairo.i586
compat-expat1-1.95.8-4.i586
compat-libstdc++-33-3.2.3-63.i586
compiz.i586
cyrus-sasl-lib.i586
dbus-libs.i586
directfb.i586
esound-libs.i586
fltk.i586
freeglut.i586
gphoto2.i586
gtk2.i586
hal-libs.i586
imlib.i586
jack-audio-connection-kit.1.i586
java.i586
lcms-libs.i586
lesstif.i586
libacl.i586
libaio-0.3.106-4.2.i586
libao.i586
libattr.i586
libcap.i586
libdrm.i586
libexif.i586
libgcrypt-1.4.0-3.i586
libgnomecanvas.i586
libICE.i586
libieee1284.i586
libsigc++20.i586
libSM.i586
libtool-ltdl.i586
libusb.i586
libwmf.i586
libwmf-lite.i586
libX11.i586
libXau.i586
libXaw.i586
libXcomposite.i586
libXdamage.i586
libXdmcp.i586
libXext.i586
libXfixes.i586
libxkbfile.i586
libxml2.i586
libXmu.i586
libXp.i586
libXpm.i586
libXScrnSaver.i586
libxslt.i586
libXt.i586
libXTrap.i586
libXtst.i586
libXv.i586
libXxf86vm.i586
lzo.i586
mesa-libGL.i586
mesa-libGLU.i586
nas-libs.i586
nss_ldap.i586
opencdk.i586
openldap.i586
pam.i586
popt.i586
pulseaudio-libs.i586
sane-backends-libs-gphoto2.i586
sane-backends-libs.i586
SDL.i586
svgalib.i586
unixODBC.i586
zlib.i586
Finally, “su” to a root shell, and run the following command:
# for i in $( Fedora-ia32.txt ); do yum -y install $i; done
When the process completes, you can verify that you have both 32-bit and
64-bit packages installed.
sudo rpm -q SDL
SDL-1.2.13-9.fc11.x86_64
SDL-1.2.13-9.fc11.i586
*A Caveat*
By having to use the entire package name, all the way up through the
arch designation, we open ourselves up to a slight problem. That is,
package version numbers are also part of the package names. So, by the
time you read this, the script may have been partially broken due to
Fedora packages having been updated to newer versions. Here’s the way
around that.
Go ahead and do the procedure as written. Then, as root, run the
following command:
for i in $( Fedora-ia32.txt ); do rpm -q rpm_results.txt $i; done
If package versions have changed, you’ll see a “not installed” error
message for it in the output file. Then, you can open Yum Extender, and
search for the update version to install.
*Conclusion*
The reason that the directions that I found via Google didn’t work, is
that the package list referenced the “i386” packages that were part of
Fedora 10. With Fedora 11, the “i386” packages have been replaced by
“i586” packages
--
°v°
/(_)\
^ ^ Jatin Khatri
No MS
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: package for basic examination of .dv video files?
On Tue, 3 Nov 2009 05:51:51 -0500 (EST) Robert P. J. Day wrote: what i was after was pulling together a collection of command-line utilities for examining and converting video files of various formats, that's all. apparently, i still have some research to do. Don't worry, the research will never stop :-), but I find the mplayer/mencoder stuff from rpmfusion the most complete as far as supporting weird video formats. The 32 bit version can even load and run windows codecs, but that rarely seems necessary lately. Of course, mencoder is also the most complete in terms of the number of command line options, you can spend weeks playing with them. There is also a midentify script that just prints info about the file in the same spirit as tcprobe (but totally different format, of course). -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [SOLVED]should I go for 64bit version of Fedora 11 ?
On 11/03/2009 02:16 PM, Jatin K wrote:
On 11/03/2009 03:58 PM, Aioanei Rares wrote:
On 11/03/2009 12:15 PM, Jatin K wrote:
On 11/03/2009 02:55 PM, Aioanei Rares wrote:
On 11/03/2009 11:15 AM, Jatin K wrote:
On 11/03/2009 01:34 PM, Aioanei Rares wrote:
On 11/03/2009 09:38 AM, Jatin K wrote:
Dear all
I've purchased a new Dell laptop Vostro 1520, major
configuration[1] , My question is should I go for FC 11 64bit
version ? is there any significant benefit if I use 64bit version ?
[1]
Model :- Dell Vostro 1520 P-series
Processor:- Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT
enabled )
RAM :- 3GB DDR2 800Mhz
Graphics :- Mobile Intel(R) Graphics Media Accelerator X4500M
My thinking is it's not safe to decide on what you've heard. Flash
works like a charm on all my 64-bit systems; and what is that other
software are you referring to? 64-bit Linux has also 32-bit libs if
needed.
Ok , I have find this [a] by googling
[a]
---
For 64-bit Ubuntu, finding the proper 32-bit support packages is a
simple matter of opening up the Synaptic Package Manager, and
searching for the string “ia32”. With 64-bit openSuSE, 32-bit support
is already built-in, so you don’t have to do anything. With Fedora,
though, it’s a whole different story. Not only are the 32-bit packages
not already installed, the Fedora folk don’t provide any documentation
on how to install them. The directions I found via Google were
outdated, and wouldn’t work. I finally resolved the problem by asking
a Red Hat employee in my local Linux Users Group.
*Add an “rpm” Macro*
This isn’t an absolute necessity, but it’s handy. Add the following
line to the “/etc/rpm/macros” file:
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
Now, when you query for information about rpm packages, you’ll be able
to see whether they’re 32-bit or 64-bit packages.
sudo rpm -q SDL
SDL-1.2.13-9.fc11.x86_64
*Add the Libraries*
Next, add the 32-bit libraries by copying the following list, and
pasting it into a text file. Save it as “Fedora-ia32.txt”.
arts.i586
audiofile.i586
bzip2-libs.i586
cairo.i586
compat-expat1-1.95.8-4.i586
compat-libstdc++-33-3.2.3-63.i586
compiz.i586
cyrus-sasl-lib.i586
dbus-libs.i586
directfb.i586
esound-libs.i586
fltk.i586
freeglut.i586
gphoto2.i586
gtk2.i586
hal-libs.i586
imlib.i586
jack-audio-connection-kit.1.i586
java.i586
lcms-libs.i586
lesstif.i586
libacl.i586
libaio-0.3.106-4.2.i586
libao.i586
libattr.i586
libcap.i586
libdrm.i586
libexif.i586
libgcrypt-1.4.0-3.i586
libgnomecanvas.i586
libICE.i586
libieee1284.i586
libsigc++20.i586
libSM.i586
libtool-ltdl.i586
libusb.i586
libwmf.i586
libwmf-lite.i586
libX11.i586
libXau.i586
libXaw.i586
libXcomposite.i586
libXdamage.i586
libXdmcp.i586
libXext.i586
libXfixes.i586
libxkbfile.i586
libxml2.i586
libXmu.i586
libXp.i586
libXpm.i586
libXScrnSaver.i586
libxslt.i586
libXt.i586
libXTrap.i586
libXtst.i586
libXv.i586
libXxf86vm.i586
lzo.i586
mesa-libGL.i586
mesa-libGLU.i586
nas-libs.i586
nss_ldap.i586
opencdk.i586
openldap.i586
pam.i586
popt.i586
pulseaudio-libs.i586
sane-backends-libs-gphoto2.i586
sane-backends-libs.i586
SDL.i586
svgalib.i586
unixODBC.i586
zlib.i586
Finally, “su” to a root shell, and run the following command:
# for i in $( Fedora-ia32.txt ); do yum -y install $i; done
When the process completes, you can verify that you have both 32-bit
and 64-bit packages installed.
sudo rpm -q SDL
SDL-1.2.13-9.fc11.x86_64
SDL-1.2.13-9.fc11.i586
*A Caveat*
By having to use the entire package name, all the way up through the
arch designation, we open ourselves up to a slight problem. That is,
package version numbers are also part of the package names. So, by the
time you read this, the script may have been partially broken due to
Fedora packages having been updated to newer versions. Here’s the way
around that.
Go ahead and do the procedure as written. Then, as root, run the
following command:
for i in $( Fedora-ia32.txt ); do rpm -q rpm_results.txt $i; done
If package versions have changed, you’ll see a “not installed” error
message for it in the output file. Then, you can open Yum Extender,
and search for the update version to install.
*Conclusion*
The reason that the directions that I found via Google didn’t work, is
that the package list referenced the “i386” packages that were part of
Fedora 10. With Fedora 11, the “i386” packages have been replaced by
“i586” packages
Well, what do you know? How about yum search SDL | grep i586 or sudo yum
install yumex ? :)
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 08:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? Depends on what you plan to use this notebook for. is there any significant benefit if I use 64bit version ? In theory, there are benefits to use the 64bit version. In practice, these benefits (esp. on a desktop notebook) are hardly measurable and can easily be outweighed by other factors attached to 64bit. So, my answer to your question: Provided how you ask, you likely don't have real uses for 64bit. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [SOLVED]should I go for 64bit version of Fedora 11 ?
On 11/03/2009 05:55 PM, Aioanei Rares wrote: On 11/03/2009 02:16 PM, Jatin K wrote: On 11/03/2009 03:58 PM, Aioanei Rares wrote: On 11/03/2009 12:15 PM, Jatin K wrote: On 11/03/2009 02:55 PM, Aioanei Rares wrote: On 11/03/2009 11:15 AM, Jatin K wrote: On 11/03/2009 01:34 PM, Aioanei Rares wrote: On 11/03/2009 09:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? is there any significant benefit if I use 64bit version ? [1] Model :- Dell Vostro 1520 P-series Processor:- Intel Core 2 Duo 2.53 P8700 1066Mhz FSB ( Intel VT enabled ) RAM :- 3GB DDR2 800Mhz Graphics :- Mobile Intel(R) Graphics Media Accelerator X4500M My thinking is it's not safe to decide on what you've heard. Flash works like a charm on all my 64-bit systems; and what is that other software are you referring to? 64-bit Linux has also 32-bit libs if needed. Well, what do you know? How about yum search SDL | grep i586 or sudo yum install yumex ? :) ;-) -- °v° /(_)\ ^ ^ Jatin Khatri No MS -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 02:32 PM, Ralf Corsepius wrote: On 11/03/2009 08:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? Depends on what you plan to use this notebook for. is there any significant benefit if I use 64bit version ? In theory, there are benefits to use the 64bit version. In practice, these benefits (esp. on a desktop notebook) are hardly measurable and can easily be outweighed by other factors attached to 64bit. So, my answer to your question: Provided how you ask, you likely don't have real uses for 64bit. Ralf I personally prefer to use the most out of my hardware, but Ralf's answer is a good one : it all depends on what you use it for. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
