Re: [gentoo-user] Network chip always comes up eth1 on 1-year-old Dell Inspiron 530
On Tue, 8 Jul 2008 23:21:22 -0400, [EMAIL PROTECTED] wrote: I finally stumbled across the *REAL* reason I couldn't get it working. I always tried configuring eth0 for it... silly me. Apparently, the chip *ALWAYS* comes up as eth1. Udev is doing this. If you have removed the second card, delete /etc/udev/rules.d/70-persistent-net.rules, otherwise edit the file to switch the assignments for the two NICs. -- Neil Bothwick Press any key to continue... click Except that one.. signature.asc Description: PGP signature
Re: [gentoo-user] on cdr{kit,tools} and licensing
Sascha Hlusiak [EMAIL PROTECTED] wrote: Am Dienstag 08 Juli 2008 16:12:43 schrieb Joerg Schilling: Mike Edenfield [EMAIL PROTECTED] wrote: The cdrtools tarball includes a file called Makefile in every directory. The cdrkit includes a file called CMakeList.txt in every directory. THAT FILE has a copyright and license terms attached to it, just like any other source file. In cdrtools, that file is covered by the CDDL. In cdrkit, that file is This is a definite lie! File RULES/rules.top, which is included in mkisofs/Makefile: # The contents of this file are subject to the terms of the # Common Development and Distribution License, Version 1.0 only. Please tell us now that it is NOT covered by the CDDL. That file is obviously a script to control the build process. Besides the fact that this is completely irrelevent (the GPL does _not_ require what they call the scripts to be under GPL), you are missinterpreting software and legal definitions! RULES/rules.top is part of a program that is a _separate_ project called the schily makefile system. It has been written in a language called make and it is much _older_ than and _independent_ from cdrtools. If the schily makefile system was under GPL, _then_ there was a problem because the GPL limits the freedom to use software. As the schily makefile system is under the more free CDDL that (in contrary to the GPL) does not limit the freedom to use software, there is no problem. mkisofs/Makefile is a derived work from the schily makefile system. The CDDL gives you the freedom to have a derived work under a license that is not the CDDL. the schily makefile system is _definitely_ _not_ a derived work from mkisofs/Makefile It seems that you still need to learn the difference between - the bucket contains water and - the water contains a bucket Come back after you learned this. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
Sebastian Günther [EMAIL PROTECTED] wrote: OK, now I finally got it right: It is about the scripts. What other people may call makefiles. The scripts and files bundled with your cdrtools to control the build process are under CDDL. E.g. RULES/i686-linux-gcc.rul: You did _not_ get it right. the file RULES/i686-linux-gcc.rul is part of a program that Debian replaced by cmake. This file is _not_ part of mkisofs and this file is _not_ part of the build scripts as it is part of the generic tool chain that is not required by the GPL to be part of the source. The program cmake is nothing than a less portable attempt o replace the features of the program called the schily makefile system. Both programs are not specific to a certain program but program independent. An interpretation of the GPL which I can follow. Well this is because you did oversee important facts in the GPL as many people do who claim to have read the GPL. As I did already explain the legal facts for using the program the schily makefile system (you should read it to reduce your confusion), let me explain why the GPL does not require the build scripts to be under GPL: If you _carefully_ read the GPL (lawyers do it, I did it but Debian doesn't), you will find the following important fact: The GPL uses the phrase under the terms of this License in all places except the place where it requires the scripts used to control compilation to be made available. It is obvious that this has been done intentionally. If you did understand the general intention of the GPL you would know that requiring these scripts to be under GPL would not be aligned with the basic idea of the GPL: you need to put everything under GPL that is a derived work of GPLd software. These scripts are obviously _not_ derived from the program. This is why they need to be available but not under GPL. As I wrote many times before: legal discussions are like programming. You do it wrong if you do not think all your ideas to it's logical end. If you forget to consider a fact when planning a program it will fail later. If you forget to consider a fact when you check your legal claims, they are not compatible with reality. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] emerge -avC cdrkit emerge -av cdrtools
Mark Kirkwood [EMAIL PROTECTED] wrote: Sorry Joerg, but again - just your opinion! If it was so obvious there would not *be* numerous discussions keeping you busy about this! Note that I may actually agree with your opinion about the intent of the GPL, but that would be just *my* opinion! These discussions only exist because the FSF published a wrong GPL FAQ (wrong because of obvious reasons I mentioned already and wrong because it is in conflict with many statements made by the Law Professor Eben Moglen) and of course because many people read only parts of the GPL without seeing all the text together as a whole. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
* Joerg Schilling ([EMAIL PROTECTED]) [09.07.08 11:22]: Sascha Hlusiak [EMAIL PROTECTED] wrote: Am Dienstag 08 Juli 2008 16:12:43 schrieb Joerg Schilling: Mike Edenfield [EMAIL PROTECTED] wrote: The cdrtools tarball includes a file called Makefile in every directory. The cdrkit includes a file called CMakeList.txt in every directory. THAT FILE has a copyright and license terms attached to it, just like any other source file. In cdrtools, that file is covered by the CDDL. In cdrkit, that file is This is a definite lie! File RULES/rules.top, which is included in mkisofs/Makefile: # The contents of this file are subject to the terms of the # Common Development and Distribution License, Version 1.0 only. Please tell us now that it is NOT covered by the CDDL. That file is obviously a script to control the build process. Besides the fact that this is completely irrelevent (the GPL does _not_ require what they call the scripts to be under GPL), you are missinterpreting software and legal definitions! This is *your* opinion of interpreting the GPL, the Debian People and also myself reading the GPL in the way that also the make script has to be under GPL, because if you distribute *binaries* you have to provide the make scripts and the source code under GPL. RULES/rules.top is part of a program that is a _separate_ project called the schily makefile system. It has been written in a language called make and it is much _older_ than and _independent_ from cdrtools. Since GNU make reads this files, it seems that they *are* needed to build the binary, thus s.a. If they are *not* needed, then strip them from a GPL conform distribution. BTW: Your interpretation of Makefiles as source code in a specific language is quite farfetched. If the schily makefile system was under GPL, _then_ there was a problem because the GPL limits the freedom to use software. As the schily makefile system is under the more free CDDL that (in contrary to the GPL) does not limit the freedom to use software, there is no problem. No, it would only prevent the usage of the schily makefile system in non-free and/or incompatibly licenced projects. This is maybe not what you want, but some other people like to *stay* on the free side of life. mkisofs/Makefile is a derived work from the schily makefile system. The CDDL gives you the freedom to have a derived work under a license that is not the CDDL. If this is true, than you could also say, that your are linking mkisofs/Makefile (under GPL) and some RULES/*.rul (under CDDL) together, with is illegal according to the FSF. I know that linking is not stated *literally* within the GPL, but the whole following paragraph of the GPL can and *is* interpreted to also cover linking: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Sebastian -- Religion ist das Opium des Volkes. Karl Marx [EMAIL PROTECTED]@N GÜNTHER mailto:[EMAIL PROTECTED] pgpN0dCBivc4Z.pgp Description: PGP signature
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
* Joerg Schilling ([EMAIL PROTECTED]) [09.07.08 11:57]: Well this is because you did oversee important facts in the GPL as many people do who claim to have read the GPL. As I did already explain the legal facts for using the program the schily makefile system (you should read it to reduce your confusion), let me explain why the GPL does not require the build scripts to be under GPL: If you _carefully_ read the GPL (lawyers do it, I did it but Debian doesn't), you will find the following important fact: The GPL uses the phrase under the terms of this License in all places except the place where it requires the scripts used to control compilation to be made available. 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. You refer to that clause? This clause defines what source code is under some conditions. It states that Makefiles *are* source code, if you do a *binary* distribution. Therefor they have to be under GPL, if you do a binary distribution. As for Gentoo there is no limitation, because it is a source distribution. It is obvious that this has been done intentionally. If you did understand the general intention of the GPL you would know that requiring these scripts to be under GPL would not be aligned with the basic idea of the GPL: you need to put everything under GPL that is a derived work of GPLd software. These scripts are obviously _not_ derived from the program. This is why they need to be available but not under GPL. And it is quite obvious, that is meant the way I see it, because the binary is a derrived work, and in this special case some important parts of the process to get this derived work, must also be free. Sebastian -- Religion ist das Opium des Volkes. Karl Marx [EMAIL PROTECTED]@N GÜNTHER mailto:[EMAIL PROTECTED] pgpS426XJwXlz.pgp Description: PGP signature
[gentoo-user] VFS: cannot open root device sda2 or unknown-block(2,0)
I am installing a new system with 2008.0 on an USB pendrive as the only disk in the machine, and at boot I get this error: VFS: cannot open root device sda2 or unknown-block(2,0) Please append a correct root= boot option; here are the available partitions: 0100 4096 ram0 (driver?) 0101 4096 ram1 (driver?) 0102 4096 ram2 (driver?) 0103 4096 ram3 (driver?) 0104 4096 ram4 (driver?) 0105 4096 ram5 (driver?) 0106 4096 ram6 (driver?) 0107 4096 ram7 (driver?) 0108 4096 ram8 (driver?) 0109 4096 ram9 (driver?) 010a 4096 ram10 (driver?) 010b 4096 ram11 (driver?) 010c 4096 ram12 (driver?) 010d 4096 ram13 (driver?) 010e 4096 ram14 (driver?) 010f 4096 ram15 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) My grub.conf contains: ,--- | default 0 | timeout 3 | | title Gentoo Linux 2.6.25-r6 | root (hd0,0) | kernel /boot/kernel-2.6.25-gentoo-r6 root=/dev/sda2 slowusb udev `--- There are two primary partitions on the stick, like this: Disk /dev/sda: 4127 MB, 4127195136 bytes 16 heads, 32 sectors/track, 15744 cylinders Units = cylinders of 512 * 512 = 262144 bytes Disk identifier: 0xe5e0db9e Device Boot Start End Blocks Id System /dev/sda1 * 1 123 31472 83 Linux /dev/sda2 124 15744 3998976 83 Linux I did not use genkernel, but compiled a monolythic kernel with menuconfig. Using genkernel was not possible, because this USB stick is a 4 GB pendrive, and genkernel compilation is so huge that it runs out of space! Of course I don't use the installer but do a manual installation with the fine handbook. I suspect I might have not marked something essenstial in menuconfig, but I somehow can't figure out what might be missing. Here is my .config pasted below, any clues? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-gentoo-r6 # Wed Jul 9 12:14:07 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_64_SMP=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y
Re: [gentoo-user] transcode dies on revdep-rebuild
On Tuesday 08 July 2008, Daniel Pielmeier wrote: 2008/7/8, Mick [EMAIL PROTECTED]: http://bugs.gentoo.org/show_bug.cgi?id=229953 Try media-video/transcode-1.0.4-r3! Thanks Daniel, the mirrors hadn't percolated yet. It just finished compiling now. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] VFS: cannot open root device sda2 or unknown-block(2,0)
On Wed, 9 Jul 2008 13:48:46 +0200 Miernik [EMAIL PROTECTED] wrote: I am installing a new system with 2008.0 on an USB pendrive as the only disk in the machine, and at boot I get this error: VFS: cannot open root device sda2 or unknown-block(2,0) Please append a correct root= boot option; here are the available partitions: My experience of USB drives is that they take about 20 seconds to come up, meaning a root device on one will fail with that error message. There are (at least) 2 working fixes that I am aware off. The first is us an initrd to delay the mounting root until the USB device is available. The second is to pass an argument to the kernel that does the same thing, IIRC sleep=30, but I have never used this particular trick, so you will want to check it. Either way, my money, based on my experience with using a USB hard-disk, is on it being a problem with /dev/sda2 not being available at mount. Rob -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
Sebastian Günther [EMAIL PROTECTED] wrote: If you _carefully_ read the GPL (lawyers do it, I did it but Debian doesn't), you will find the following important fact: The GPL uses the phrase under the terms of this License in all places except the place where it requires the scripts used to control compilation to be made available. 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. I get the impression that you have problems to understand even very obvious parts of the GPL, it seems that you would need to enhance your english. The GPL discriminates between the work (which needs to be under GPL) and the complete source which is a superset of the work and other parts that do not need to be under GPL. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
Sebastian Günther [EMAIL PROTECTED] wrote: Besides the fact that this is completely irrelevent (the GPL does _not_ require what they call the scripts to be under GPL), you are missinterpreting software and legal definitions! This is *your* opinion of interpreting the GPL, the Debian People and also myself reading the GPL in the way that also the make script has to be under GPL, because if you distribute *binaries* you have to provide the make scripts and the source code under GPL. You obviously missread the GPL. See your other mail that verifies that you did not understand the GPL correctly. RULES/rules.top is part of a program that is a _separate_ project called the schily makefile system. It has been written in a language called make and it is much _older_ than and _independent_ from cdrtools. Since GNU make reads this files, it seems that they *are* needed to build the binary, thus s.a. If they are *not* needed, then strip them from a GPL conform distribution. You look confused. the schily makefilesystem is a generic part of the toolchain. This piece of software does not need to be delivered at all. If your claim was made for serious, you would be also require to deliver e.g. the shell scripts true and false because they are read by the configure shell script. If the schily makefile system was under GPL, _then_ there was a problem because the GPL limits the freedom to use software. As the schily makefile system is under the more free CDDL that (in contrary to the GPL) does not limit the freedom to use software, there is no problem. No, it would only prevent the usage of the schily makefile system in non-free and/or incompatibly licenced projects. This is maybe not what you want, but some other people like to *stay* on the free side of life. You would need to learn the official meaning of the term free. The GPL in the specific case of the schily makefilesystem limits the freedom to use which is why the GPL is unacceptable for this kind of free software. mkisofs/Makefile is a derived work from the schily makefile system. The CDDL gives you the freedom to have a derived work under a license that is not the CDDL. If this is true, than you could also say, that your are linking mkisofs/Makefile (under GPL) and some RULES/*.rul (under CDDL) together, with is illegal according to the FSF. I know that linking is not stated *literally* within the GPL, but the whole following paragraph of the GPL can and *is* interpreted to also cover linking: These requirements apply to the modified work as a whole. If Let us stop here and continue after you managed to understand the difference between - the bucket contains water and - the water contains a bucket Come back after you learned this. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] problems building php
I noticed there was an update to php a couple days ago, so I went to build it for my system and I get this error: /var/tmp/portage/dev-lang/php-5.2.6-r2/work/php-5.2.6/ext/imap/php_imap.c: In function '_php_rfc822_write_address_len': /var/tmp/portage/dev-lang/php-5.2.6-r2/work/php-5.2.6/ext/imap/php_imap.c:3906: error: 'RFC822BUFFER' undeclared (first use in this function) /var/tmp/portage/dev-lang/php-5.2.6-r2/work/php-5.2.6/ext/imap/php_imap.c:3906: error: (Each undeclared identifier is reported only once /var/tmp/portage/dev-lang/php-5.2.6-r2/work/php-5.2.6/ext/imap/php_imap.c:3906: error: for each function it appears in.) /var/tmp/portage/dev-lang/php-5.2.6-r2/work/php-5.2.6/ext/imap/php_imap.c:3906: error: expected ';' before 'buf' /var/tmp/portage/dev-lang/php-5.2.6-r2/work/php-5.2.6/ext/imap/php_imap.c:3908: error: 'buf' undeclared (first use in this function) make: *** [ext/imap/php_imap.lo] Error 1 make: *** Waiting for unfinished jobs I've never run into trouble building PHP before, so this is new to me. I haven't found anything on the 'net that references an RFC822BUFFER. Has anyone else had this problem? -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
* Joerg Schilling ([EMAIL PROTECTED]) [09.07.08 15:14]: Sebastian Günther [EMAIL PROTECTED] wrote: If you _carefully_ read the GPL (lawyers do it, I did it but Debian doesn't), you will find the following important fact: The GPL uses the phrase under the terms of this License in all places except the place where it requires the scripts used to control compilation to be made available. 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. The GPL discriminates between the work (which needs to be under GPL) and the complete source which is a superset of the work and other parts that do not need to be under GPL. Nowhere in the whole GPL is stated that the complete source code is a superset of the work. The work is only used to refer ro projects which *use* the Program, which is the term used for the primary object of the licence. Jörg Read again yourself, brother Sebastian -- Religion ist das Opium des Volkes. Karl Marx [EMAIL PROTECTED]@N GÜNTHER mailto:[EMAIL PROTECTED] pgpqcqPzpYIJs.pgp Description: PGP signature
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
Sebastian Günther [EMAIL PROTECTED] wrote: The GPL discriminates between the work (which needs to be under GPL) and the complete source which is a superset of the work and other parts that do not need to be under GPL. Nowhere in the whole GPL is stated that the complete source code is a superset of the work. The work is only used to refer ro projects which *use* the Program, which is the term used for the primary object of the licence. You would need to reread the GPL until you understand this ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
On 9 Jul 2008, at 14:13, Joerg Schilling wrote: ... I get the impression that you have problems to understand even very obvious parts of the GPL, it seems that you would need to enhance your english. You frikkin' clown, Joerg. On 9 Jul 2008, at 10:56, Joerg Schilling wrote: ... Well this is because you did oversee important facts in the GPL as many people do who claim to have read the GPL. ... You demonstrate in this earlier message today that you don't know the difference between oversee and overlook, two quite different words with different meanings. You really are not in a position to chastise others' English - your English usage being quite clumsy at the *best* of times. In fact, this causes me to wonder if all your problems stem from a failure to understand the GPL. Perhaps it is YOU who has misread it? Certainly, when you speak in English, your own words cannot be trusted. Stroller. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
Stroller [EMAIL PROTECTED] wrote: You really are not in a position to chastise others' English - your English usage being quite clumsy at the *best* of times. Wenn Du glaubst Problmeme mit meinem Englisch zu haben, dann laß uns einfach die Diskusion in Deutsch weiterführen. Ich befürchte aber, das wird uns beide auch nicht weiterbringen weil Du bislang nichts wirklich Hilfreiches zur Diskusion beitragen konntest. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
* Joerg Schilling ([EMAIL PROTECTED]) [09.07.08 15:21]: Sebastian Günther [EMAIL PROTECTED] wrote: You obviously missread the GPL. See your other mail that verifies that you did not understand the GPL correctly. No, the only thing is that I don't apply to *your* *interpretation* of the GPL, and I'm not alone, Debian is with me. But remember your opinion and mine are just *opinions*, only a court of law could proove eitherof us wrong. RULES/rules.top is part of a program that is a _separate_ project called the schily makefile system. It has been written in a language called make and it is much _older_ than and _independent_ from cdrtools. Since GNU make reads this files, it seems that they *are* needed to build the binary, thus s.a. If they are *not* needed, then strip them from a GPL conform distribution. You look confused. the schily makefilesystem is a generic part of the toolchain. This piece of software does not need to be delivered at all. If your claim was made for serious, you would be also require to deliver e.g. the shell scripts true and false because they are read by the configure shell script. OK, Jörg, we agree on smake must not be included in the distribution, but can you build the binary without any of the files in RULES/ ? If the schily makefile system was under GPL, _then_ there was a problem because the GPL limits the freedom to use software. As the schily makefile system is under the more free CDDL that (in contrary to the GPL) does not limit the freedom to use software, there is no problem. No, it would only prevent the usage of the schily makefile system in non-free and/or incompatibly licenced projects. This is maybe not what you want, but some other people like to *stay* on the free side of life. You would need to learn the official meaning of the term free. The GPL in the specific case of the schily makefilesystem limits the freedom to use which is why the GPL is unacceptable for this kind of free software. There is no official meaning of free, nor will there ever be one. There are several agreements on what free means; that's why the FSF *states* their meaning of freedom as the first thing on their homepage. You have another opinion of what free means, that's fine, that's your lawful right. Go, take a Philosophy 101. mkisofs/Makefile is a derived work from the schily makefile system. The CDDL gives you the freedom to have a derived work under a license that is not the CDDL. If this is true, than you could also say, that your are linking mkisofs/Makefile (under GPL) and some RULES/*.rul (under CDDL) together, with is illegal according to the FSF. I know that linking is not stated *literally* within the GPL, but the whole following paragraph of the GPL can and *is* interpreted to also cover linking: These requirements apply to the modified work as a whole. If Let us stop here and continue after you managed to understand the difference between - the bucket contains water and - the water contains a bucket Ok in this special case: The bucket is the instructionsset to build cdrtools, and you put fire (CDDL Makefile) and water (GPL Makefile) in it. Won't work! The only solution is to make water to fire (not allowed, it is GPLed, and your are not the only author) or fire to water. So if your are using code, e.g. a library, which is GPLed, your whole project has to GPLed. That's it. That simple. Sebastian -- Religion ist das Opium des Volkes. Karl Marx [EMAIL PROTECTED]@N GÜNTHER mailto:[EMAIL PROTECTED] pgp8bCfDWvG14.pgp Description: PGP signature
Re: [gentoo-user] on cdr{kit,tools} and licensing
Sebastian Günther [EMAIL PROTECTED] wrote: Da mein Englisch hier von einem Engländer kritisiert wurde muß ich wohl in Deutsch antworten damit dieser Mensch mich besser versteht... You obviously missread the GPL. See your other mail that verifies that you did not understand the GPL correctly. No, the only thing is that I don't apply to *your* *interpretation* of the GPL, and I'm not alone, Debian is with me. Es gibt mehr als einen Geisterfahrer, das was Du vorbringst ist also kein Beweis, denn Gesiterfahler fahren nunmal falsch auch wenn es viele davon gibt. But remember your opinion and mine are just *opinions*, only a court of law could proove eitherof us wrong. Ich verwende die Auslegung die auch Anwälte verwenden. Das Problem ist, wie ich bereits erklärt habe daß Debian und andere Linux Distributoren bislang keinen Anwalt befragt haben. Für mich sind Aussagen von Anwälten aber deutlich glaubwürdiger als Aussagen von Laien die mich und meine Projekte zudem in aller Öffentlichkeit angreifen. You look confused. the schily makefilesystem is a generic part of the toolchain. This piece of software does not need to be delivered at all. If your claim was made for serious, you would be also require to deliver e.g. the shell scripts true and false because they are read by the configure shell script. OK, Jörg, we agree on smake must not be included in the distribution, but can you build the binary without any of the files in RULES/ ? Du kannst auch ohne C-Kompiler keine Kompilation durchführen. Du benötigst allerdings keinen bestimmten C-Kompiler. Genauso ist auch das separate Programmsystem Das Schily Makefilesystem einzustufen. Es ist nichts weiter als ein weiterer definitiv von den anderen Programmen in den cdrtools unabhängiger Baustein. Eine Kompilation ist teschnisch auch ohne die Dateien in RULES/ möglich. Let us stop here and continue after you managed to understand the difference between - the bucket contains water and - the water contains a bucket Ok in this special case: The bucket is the instructionsset to build cdrtools, and you put fire (CDDL Makefile) and water (GPL Makefile) in it. Won't work! Völlig daneben :-( Nochmal auf Deutsch, damit es jeder versteht: - In dem Eimer ist Wasser - Im Wasser ist ein Eimer sind nicht äquivalente Ausdrücke weil sie eine _Richtung_ enthalten. Die Bestimmungen in der GPL sind genauso: Sie beinhalten eine Richtung. Die GPL verbietet, daß GPL-Code durch nicht-GPL-Code verwendet wird. Die GPL verbietet aber _nicht_, daß GPL-Code nicht-GPL-Code verwendet. Die GPL will nichts als verhindern, dan GPL-Code in nicht GPL Programmen auftaucht. Wenn Du mal einen Vortrag von RMS gehört hast dann solltest Du wissen, daß das genau das ist was RMS verhindern will. Die Aussagen der FSF GPL und CDDL seien inkompatibel kann man nur als peinlich einstufen, weil die korrekte Aussage wäre: GPL und CDDL sind nicht beliebig mischbar. Die Fälle bei denen GPL Code nicht-GPL-Code verwendet sind sogar durch RMS _ausdrücklich_ gewünscht weil die GPL sonst heute völlig irrelevant wäre und von niemandem verwendet würde. Die Aussagen von der FSF und von Debian sind auch deshalb so peinlich, weil sie etwas äquivalentes zu Wasser und Eimer sind inkompatibel behaupten. Dabei ist Wasser im Eimer ausdrücklich erwünscht, nur ein Eimer im Wasser wird halt ungern gesehen. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
2008/7/9 Joerg Schilling [EMAIL PROTECTED]: Sebastian Günther [EMAIL PROTECTED] wrote: Da mein Englisch hier von einem Engländer kritisiert wurde muß ich wohl in Deutsch antworten damit dieser Mensch mich besser versteht... You obviously missread the GPL. See your other mail that verifies that you did not understand the GPL correctly. No, the only thing is that I don't apply to *your* *interpretation* of the GPL, and I'm not alone, Debian is with me. Es gibt mehr als einen Geisterfahrer, das was Du vorbringst ist also kein Beweis, denn Gesiterfahler fahren nunmal falsch auch wenn es viele davon gibt. But remember your opinion and mine are just *opinions*, only a court of law could proove eitherof us wrong. Ich verwende die Auslegung die auch Anwälte verwenden. Das Problem ist, wie ich bereits erklärt habe daß Debian und andere Linux Distributoren bislang keinen Anwalt befragt haben. Für mich sind Aussagen von Anwälten aber deutlich glaubwürdiger als Aussagen von Laien die mich und meine Projekte zudem in aller Öffentlichkeit angreifen. You look confused. the schily makefilesystem is a generic part of the toolchain. This piece of software does not need to be delivered at all. If your claim was made for serious, you would be also require to deliver e.g. the shell scripts true and false because they are read by the configure shell script. OK, Jörg, we agree on smake must not be included in the distribution, but can you build the binary without any of the files in RULES/ ? Du kannst auch ohne C-Kompiler keine Kompilation durchführen. Du benötigst allerdings keinen bestimmten C-Kompiler. Genauso ist auch das separate Programmsystem Das Schily Makefilesystem einzustufen. Es ist nichts weiter als ein weiterer definitiv von den anderen Programmen in den cdrtools unabhängiger Baustein. Eine Kompilation ist teschnisch auch ohne die Dateien in RULES/ möglich. Let us stop here and continue after you managed to understand the difference between - the bucket contains water and - the water contains a bucket Ok in this special case: The bucket is the instructionsset to build cdrtools, and you put fire (CDDL Makefile) and water (GPL Makefile) in it. Won't work! Völlig daneben :-( Nochmal auf Deutsch, damit es jeder versteht: - In dem Eimer ist Wasser - Im Wasser ist ein Eimer sind nicht äquivalente Ausdrücke weil sie eine _Richtung_ enthalten. Die Bestimmungen in der GPL sind genauso: Sie beinhalten eine Richtung. Die GPL verbietet, daß GPL-Code durch nicht-GPL-Code verwendet wird. Die GPL verbietet aber _nicht_, daß GPL-Code nicht-GPL-Code verwendet. Die GPL will nichts als verhindern, dan GPL-Code in nicht GPL Programmen auftaucht. Wenn Du mal einen Vortrag von RMS gehört hast dann solltest Du wissen, daß das genau das ist was RMS verhindern will. Die Aussagen der FSF GPL und CDDL seien inkompatibel kann man nur als peinlich einstufen, weil die korrekte Aussage wäre: GPL und CDDL sind nicht beliebig mischbar. Die Fälle bei denen GPL Code nicht-GPL-Code verwendet sind sogar durch RMS _ausdrücklich_ gewünscht weil die GPL sonst heute völlig irrelevant wäre und von niemandem verwendet würde. Die Aussagen von der FSF und von Debian sind auch deshalb so peinlich, weil sie etwas äquivalentes zu Wasser und Eimer sind inkompatibel behaupten. Dabei ist Wasser im Eimer ausdrücklich erwünscht, nur ein Eimer im Wasser wird halt ungern gesehen. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- gentoo-user@lists.gentoo.org mailing list It saddens me to see messages like these being sent on this mailing list. I haven't been around very long, but it seems that these kind of messages are repeatedly posted on this mailing list and I see no criticism of this on the list. I do not feel this discussion is relevent to gentoo. Can you please take you battles elsewhere. I do not wish to be your adience! This leads me to the question of whether this kind of conduct is accepted on the gentoo-user mailing list. If this is indeed the case I would accept that and deal with it in a way that I choose. I hope this sort of thing can stop, because I really learn a lot from the posts that are sent on this list. Regards Dirk ps. This message is not directed to a certain author of this thread, I feel that it is not a single person responsible for all the OT debate going on. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing (was: emerge -avC cdrkit emerge -av cdrtools)
On 9 Jul 2008, at 15:05, Joerg Schilling wrote: Stroller [EMAIL PROTECTED] wrote: You really are not in a position to chastise others' English - your English usage being quite clumsy at the *best* of times. Wenn Du glaubst Problmeme mit meinem Englisch zu haben, dann laß uns einfach die Diskusion in Deutsch weiterführen. Ich befürchte aber, das wird uns beide auch nicht weiterbringen weil Du bislang nichts wirklich Hilfreiches zur Diskusion beitragen konntest. I trust this indicates that in future you'll only be posting to gentoo-user-de http://archives.gentoo.org/gentoo-user-de/ Stroller. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] emerge -avC cdrkit emerge -av cdrtools
I'd say this has gone on quite long enough. There *were* some nuggets of information among Jörgs lunatic ravings, but I think it would be best if we ended the thread. Also, who would I have to contact to get Jörg removed from the list? Regards, Jan -- Four bits at a time www.thenybble.de -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] emerge -avC cdrkit emerge -av cdrtools
On Wed, 09 Jul 2008 17:32:34 +0200 Jan Seeger [EMAIL PROTECTED] wrote: I'd say this has gone on quite long enough. There *were* some nuggets of information among Jörgs lunatic ravings, but I think it would be best if we ended the thread. Also, who would I have to contact to get Jörg removed from the list? Userrel I believe, however there are issues involved in such a move as it (currently) goes against gentoo policy. Wait for the next council meeting, where permitting such measures is being debated would be my suggestion. Rob. P.S. I intend this post purely to be a reply based on my following the -dev mailing list and hence having a vague idea of what is going before council soon. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
On Wed, Jul 9, 2008 at 9:02 AM, Neil Bothwick [EMAIL PROTECTED] wrote: On Wed, 09 Jul 2008 16:51:28 +0200, Joerg Schilling wrote: Da ich es vorhin vergessen habe zu erwähnen: This is an English speaking list, if you want to converse in another language, please take it to private mail. -- Neil Bothwick I don't know what your problem is, but I'll bet it's hard to pronounce. Yeah, you're right, and I totally agree with you, but this latest set of messages have me rolling in the isles. The Bablefish translation for the line you copied (I assume randomly) is There I forgot to mention it a while ago I think this might be the closest thing to an apology we're going to see out of Joerg on this one. ;-) Thanks to you for that one Neil! These massive blow-ups are really amazing to us outsiders. Peace to all, Mark -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
Joerg Schilling wrote: Sascha Hlusiak [EMAIL PROTECTED] wrote: Am Dienstag 08 Juli 2008 16:12:43 schrieb Joerg Schilling: Mike Edenfield [EMAIL PROTECTED] wrote: [lots of stuff I regret] I apologize to everyone for making this mess go on any longer that it had to. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] emerge -avC cdrkit emerge -av cdrtools
On Mittwoch, 9. Juli 2008, Jan Seeger wrote: I'd say this has gone on quite long enough. There *were* some nuggets of information among Jörgs lunatic ravings, but I think it would be best if we ended the thread. Also, who would I have to contact to get Jörg removed from the list? why remove Jörg and not everybody who insisted in going on? Neil, Alan, Daniel, Sebastian, Stroller,... are all guilty of not just ignoring him. Everybody knows Jörg's position. He might be correct or not, he won't change it. No matter what. So just stop replying. EOT, everybody happy, no bans needed. -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] grub emerge make boot screen and others unreadable
The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? thanks, allan -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
Try add to grub.conf this line vga=0x31B This controls resolution and color depth of your framebuffer screen. You can read more about this at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=10 On Wed, Jul 9, 2008 at 10:02 PM, Allan Gottlieb [EMAIL PROTECTED] wrote: The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? thanks, allan -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Re: problems building php
On Wednesday 09 July 2008, Michael George wrote: Has anyone else had this problem? Can you compile without the imap flag? Maybe some underlying lib is missing... Ciao Francesco -- Linux Version 2.6.25-gentoo-r6, Compiled #1 PREEMPT Sat Jul 5 18:06:28 CEST 2008 One 1GHz AMD Athlon 64 Processor, 2GB RAM, 2004.03 Bogomips Total aemaeth -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
Andrew Tchernoivanov wrote: Try add to grub.conf this line vga=0x31B This controls resolution and color depth of your framebuffer screen. You can read more about this at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=10 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=10 On Wed, Jul 9, 2008 at 10:02 PM, Allan Gottlieb [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? thanks, allan -- gentoo-user@lists.gentoo.org mailto:gentoo-user@lists.gentoo.org mailing list splashimage has nothing to with the kernel. The kernel isn't even loaded at this point. It's very likely that the splashimage line is pointing to a nonexistent file. --Joshua Doll -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] DNS poisoning fix
Hi All, Have you seen this? http://uk.news.yahoo.com/afp/20080709/ttc-us-it-internet-software-crime-e0bba4a.html and this? http://www.doxpara.com/ Is it merely a matter of using the right version of bind (for those who run a bind daemon locally), or does it go further than that? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] grub emerge make boot screen and others unreadable
* Allan Gottlieb ([EMAIL PROTECTED]) [09.07.08 20:04]: The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? Your kernel is not even loaded, when this happens. So your kernel has nothing to do with it. This is the background picture of grub, which grub should display. This should not happen. But before filling a bug look at the open bugs for grub, if it isn't filed already. thanks, allan Sebastian -- Religion ist das Opium des Volkes. Karl Marx [EMAIL PROTECTED]@N GÜNTHER mailto:[EMAIL PROTECTED] pgpgO2NXNtW8B.pgp Description: PGP signature
Re: [gentoo-user] DNS poisoning fix
Mick schrieb: Hi All, Have you seen this? http://uk.news.yahoo.com/afp/20080709/ttc-us-it-internet-software-crime-e0bba4a.html and this? http://www.doxpara.com/ Is it merely a matter of using the right version of bind (for those who run a bind daemon locally), or does it go further than that? It was already announced on the planet [1] and there is already a bug [2]open about it. [1] http://planet.gentoo.org/ [2] https://bugs.gentoo.org/show_bug.cgi?id=231201 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] DNS poisoning fix
On Wednesday 09 July 2008, Mick wrote: Is it merely a matter of using the right version of bind (for those who run a bind daemon locally), or does it go further than that? I have no idea how far it goes. What I can tell you is that today I updated 3 name servers, a colleague did the other three, and not one of them was bind. Only once one replaces bind with something else does one realise how much of a pita it is to use :-) -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] SOLVED: grub emerge make boot screen and others unreadable
At Wed, 09 Jul 2008 21:33:21 +0200 Sebastian Günther [EMAIL PROTECTED] wrote: * Allan Gottlieb ([EMAIL PROTECTED]) [09.07.08 20:04]: The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? Your kernel is not even loaded, when this happens. So your kernel has nothing to do with it. Correct. Sorry for the noise. This is the background picture of grub, which grub should display. This should not happen. But before filling a bug look at the open bugs for grub, if it isn't filed already. There was a bug filed. The new emerge moved the location of the splash file and the msg printed by the ebuild was (at the very least) not clear. thanks for the good information. allan -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] emerge -avC cdrkit emerge -av cdrtools
On Wed, 9 Jul 2008 18:58:52 +0200, Volker Armin Hemmann wrote: Neil, Alan, Daniel, Sebastian, Stroller,... are all guilty of not just ignoring him. Mea culpa :( Yes, before anyone comments, I know that's not English :P -- Neil Bothwick Cross a tagline and a tribble? You get a full HD... signature.asc Description: PGP signature
Re: [gentoo-user] grub emerge make boot screen and others unreadable
On Wed, 09 Jul 2008 12:25:30 -0700, Joshua D Doll wrote: splashimage has nothing to with the kernel. The kernel isn't even loaded at this point. It's very likely that the splashimage line is pointing to a nonexistent file. Grub hangs if that's the case. -- Neil Bothwick A single fact can spoil a good argument. signature.asc Description: PGP signature
Re: [gentoo-user] grub emerge make boot screen and others unreadable
On Wed, 09 Jul 2008 14:02:59 -0400, Allan Gottlieb wrote: The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? The fact that the ebuild modifies grub.conf in any way should be considered a bug IMO. -- Neil Bothwick To boldly go where I surely don't belong. signature.asc Description: PGP signature
Re: [gentoo-user] grub emerge make boot screen and others unreadable
Neil Bothwick wrote: On Wed, 09 Jul 2008 12:25:30 -0700, Joshua D Doll wrote: splashimage has nothing to with the kernel. The kernel isn't even loaded at this point. It's very likely that the splashimage line is pointing to a nonexistent file. Grub hangs if that's the case. I've had exactly the same thing happen to me when I've had the path wrong for the splashimage. You get a highly unreadable screen, but it still works. --Joshua Doll -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Re: DNS poisoning fix
Mick wrote: Hi All, Have you seen this? http://uk.news.yahoo.com/afp/20080709/ttc-us-it-internet-software-crime-e0bba4a.html and this? http://www.doxpara.com/ Is it merely a matter of using the right version of bind (for those who run a bind daemon locally), or does it go further than that? This note from the author of maradns might help understand the issue. (FWIW, maradns is straightforward and simple if you want to try it on an interim basis 'til bind is fixed.) MaraDNS is immune to the new cache poisoning attack. MaraDNS has always been immune to this attack. Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago. The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun). - Sam -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
At Wed, 09 Jul 2008 13:20:43 -0700 Joshua D Doll [EMAIL PROTECTED] wrote: Neil Bothwick wrote: On Wed, 09 Jul 2008 12:25:30 -0700, Joshua D Doll wrote: splashimage has nothing to with the kernel. The kernel isn't even loaded at this point. It's very likely that the splashimage line is pointing to a nonexistent file. Grub hangs if that's the case. I've had exactly the same thing happen to me when I've had the path wrong for the splashimage. You get a highly unreadable screen, but it still works. I agree with joshua. That is what happened to me. allan -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
At Wed, 09 Jul 2008 21:15:16 +0100 Neil Bothwick [EMAIL PROTECTED] wrote: On Wed, 09 Jul 2008 14:02:59 -0400, Allan Gottlieb wrote: The latest stable emerge of grub decided to add splashimage=(hd0,2)/boot/grub/splash.xpm.gz to my grub.conf Since I do not have support for this in my kernel the screen was unreadable. Should I file this as a bug? The fact that the ebuild modifies grub.conf in any way should be considered a bug IMO. That was my error. The file grub.conf was not modified. Instead a file pointed to by grub.conf (the splash) was moved. sorry, allan -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
Thanks for this thread. I had a bunch of gibberish on the screen, too, after the most recent emerge and figured it was grub but didn't know why. Strangely, the splash image was missing from /boot/grub - is it not supposed to be in /boot or was this an ebuild error?? I found the splash image (splash.xpm.gz) under /usr/share/grub, and moving it to /boot/grub fixed this issue for me. Denis -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
On Wednesday 09 July 2008, Joerg Schilling wrote: If the schily makefile system was under GPL, _then_ there was a problem because the GPL limits the freedom to use software. As the schily makefile system is under the more free CDDL that (in contrary to the GPL) does not limit the freedom to use software, there is no problem. mkisofs/Makefile is a derived work from the schily makefile system. The CDDL gives you the freedom to have a derived work under a license that is not the CDDL. the schily makefile system is _definitely_ _not_ a derived work from mkisofs/Makefile As the GPL is a copyleft, and relies on copyright to be enforceable, it's prudent to consider what constitutes a derived work, and if a claimed derived work is indeed a derived work at all. SCO's claims about header files, and the bruha surrounding XFS when first merged into mainline are examples of how this can be a gray area. To my mind Makefiles make most sense when viewed as independent free standing works, or possibly as not copyrightable (if they are the only possible expression of a desired result). I'm not familiar enough with Joerg's build system to have much of a valid opinion, so a few technical questions that Joerg (the author) is best positioned to answer: 1. Are your Makefiles unique and peculiar to your build system, so that no other build system could conceivably use them? 2. Briefly, what would be involved to have cdrtools built by a different build system? And a few questions about your intentions for your code: 1. Do you permit users to modify and redistribute the Makefiles? 2. How do you feel about users or distros replacing your build system and Makefiles with a different system? Leaving aside their reasons for doing this, did you intend with the licensing for them to receive this right? 3. Would you be willing to dual-license the build system and/or Makefiles as CDDL/GPL? It seems to me you don't lose anything if you did this. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] on cdr{kit,tools} and licensing
On Wednesday 09 July 2008, Dirk Uys wrote: This leads me to the question of whether this kind of conduct is accepted on the gentoo-user mailing list. If this is indeed the case I would accept that and deal with it in a way that I choose. Very little is explicitly prohibited around here. Whoever runs the list lets the users discuss mostly whatever they want to. Moderation is best done with a custom procmail rule set on your local machine -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] emerge -avC cdrkit emerge -av cdrtools
On Wed, 9 Jul 2008 21:13:23 +0100 Neil Bothwick [EMAIL PROTECTED] wrote: On Wed, 9 Jul 2008 18:58:52 +0200, Volker Armin Hemmann wrote: Neil, Alan, Daniel, Sebastian, Stroller,... are all guilty of not just ignoring him. Mea culpa :( Yes, before anyone comments, I know that's not English :P Do we have a Gentoo latin list? -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
At Wed, 09 Jul 2008 17:30:12 -0400 Denis [EMAIL PROTECTED] wrote: Thanks for this thread. I had a bunch of gibberish on the screen, too, after the most recent emerge and figured it was grub but didn't know why. Strangely, the splash image was missing from /boot/grub - is it not supposed to be in /boot or was this an ebuild error?? I found the splash image (splash.xpm.gz) under /usr/share/grub, and moving it to /boot/grub fixed this issue for me. Indeed this is one thing in the bug http://bugs.gentoo.org/show_bug.cgi?id=231039 Apparently the ebuild recommendation about emerge --config grub was supposed to get the file copied over (and presumably it would). However the actual recommendation was for those who wish to install grub files to another device (like a usb stick) Since many like me had no desire to do this, we didn't run the configure and the moved splash file bit us. allan -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
On Wed, 09 Jul 2008 13:20:43 -0700, Joshua D Doll wrote: Grub hangs if that's the case. I've had exactly the same thing happen to me when I've had the path wrong for the splashimage. You get a highly unreadable screen, but it still works. Did the wrong path point to something? When I got it wrong, grub refused to load the menu.lst file at all. Mind you, that was a couple of years ago. Maybe handles things differently now, I haven't dared find out! -- Neil Bothwick Disinformation is not as good as datinformation. signature.asc Description: PGP signature
Re: [gentoo-user] grub emerge make boot screen and others unreadable
Neil Bothwick wrote: On Wed, 09 Jul 2008 13:20:43 -0700, Joshua D Doll wrote: Grub hangs if that's the case. I've had exactly the same thing happen to me when I've had the path wrong for the splashimage. You get a highly unreadable screen, but it still works. Did the wrong path point to something? When I got it wrong, grub refused to load the menu.lst file at all. Mind you, that was a couple of years ago. Maybe handles things differently now, I haven't dared find out! It pointed to nothing. I actually had the wrong drive and/or partition in the line. I say it worked but really the screen was so jacked it was useless. --Joshua Doll -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Symfony Framework update
Hi list, Did anyone use symfony php framework ? I've the last ebuild available (1.0.11), but, since the recent update of the framework to 1.1, I'm not sure how to upgrade my version, at leat I'll do emerge -C symfony and install it by hand, but I'm not familiar with svn and I've no need of PEAR, so I should hope some of you know how to upgrade mine without braking everything. thanks for reading ^^
Re: [gentoo-user] DVD and large files
Joerg Schilling wrote: Dale [EMAIL PROTECTED] wrote: I am having trouble burning a 4Gb tarball at the moment. Not sure what all the problem is but I had another DVD with one. This is the command I use and the error less the looong list of files: [EMAIL PROTECTED] / # tar -xvf /media/hdd/Data_2008.07.04-14.50.23_2.tar -C /backup/test/ data/Gentoo-stuff/livecd-i686-installer-2007.0.iso.bz2 tar: Skipping to next header SNIP tar: Error exit delayed from previous errors [EMAIL PROTECTED] / # ls of the file: -r--r--r-- 1 root root 4295060992 2008-07-04 19:07 Data_2008.07.04-14.50.23_2.tar Any idea what that is all about? There are many possible reasons: 1) A well known bug in GNU tar (self incompatibility to GNU tar archives). I recommend you to use star to check the archive for correctness. 2) You did not use a recent original mkisofs to create the image 3) There is a bug in your Linux kernel. You would first need to check with a tar implementation that is kown to work (star). Jörg Hi, Sorry so long to reply but me and k3b have been having discussions about burning a huge DVD. I emerged star but it may as well be Greek, no offense to the Greek. Just something I will have to sit down and read sometime. I got the DVD burned with a larger than 4Gb file. Konqueror as a user says: Could not enter folder /media/hdd/ and I hear glass breaking. I assume that is not good. Mount gives me this with regard to the DVD: /dev/hdd on /media/hdd type udf (rw,noexec,nosuid,nodev) I think this is a permissions issue. Konqueror as root works just fine. May need to beat on fstab or something with regards to that. More on that in a minute. I can however access the DVD as root on the command line. So, I just used tar and started to extract it. It seems to be doing fine at the moment. I will test further with larger files tho just to make sure. At least this time it unpacked the tarball with no errors. After all, what's the point of back-ups if you can't unpack them? For the record, here is the current settings: k3b: under the burn screen I selected custom and then level 3 ISO, selected all file systems, preserve file permissions. Now back to the permissions issue. fstab: /dev/hdc /media/hdc iso9660 noauto,users0 0 /dev/hdd/media/hddautonoauto,users0 0 Anybody see any reason why a non root user can't access the DVD? I have set the permissions on /media/hdd to root/users with both having r/w access. However after I insert a DVD, something changes it to this: d- 2 root root 116 2008-07-08 11:14 hdd This is how I set it up: drwxrwxr-x 2 root users 48 2008-07-04 14:21 hdd It also changes back to my settings after I eject the DVD. I *think* I got the tar part working. Any clues on the permissions issue? Udev doing this? I got something set wrong? Thanks Dale :-) :-) -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] grub emerge make boot screen and others unreadable
At Thu, 10 Jul 2008 00:03:01 +0100 Neil Bothwick [EMAIL PROTECTED] wrote: On Wed, 09 Jul 2008 13:20:43 -0700, Joshua D Doll wrote: Grub hangs if that's the case. I've had exactly the same thing happen to me when I've had the path wrong for the splashimage. You get a highly unreadable screen, but it still works. Did the wrong path point to something? No. In grub.conf I had and still have splashimage=(hd0,2)/boot/grub/splash.xpm.gz There used to be such a file. But the recent emerge removed it and put the file in /usr/share/grub. So the splashimage target didn't exist. When I got it wrong, grub refused to load the menu.lst file at all. Mind you, that was a couple of years ago. Maybe handles things differently now, I haven't dared find out! Grub did load and if left alone would successfully load the default target. However, 1. The menu grub normally displays (i.e. the grub.conf entries) was absent or at least the screen was dark. 2. When the kernel starting booting, the screen was nearly unreadable until the kernel set the console font, at which point ... ... poof--all was well. allan -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Re: VFS: cannot open root device sda2 or unknown-block(2,0)
Robert Bridge [EMAIL PROTECTED] wrote: The first is us an initrd to delay the mounting root until the USB device is available. Thanks, this fixed it. I mean did compile with genkernel --menuconfig to cut out some unneeded stuff and still get a initrd. The second is to pass an argument to the kernel that does the same thing, IIRC sleep=30, but I have never used this particular trick, so you will want to check it. Tried it - didn't work. -- Miernik http://miernik.name/ -- gentoo-user@lists.gentoo.org mailing list
